In the previous blog post we’ve described how to spin up a kubernetes cluster on Nectar. Around the same time, I also got to know that University of Melbourne has a self-hosted gitlab. To my delight, I found out that GitLab has Kubernetes integration.

This means that, if you are in UniMelb (or have a self-hosted gitlab), you can run CI/CD using Nectar cloud, without having to set up any infrastructure!

Spin up cluster

  1. Spin up a kubernetes (k8s) cluster and create the config directory. Instructions.

  2. Run the following
    kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin
    --user=admin --user=kubelet --group=system:serviceaccounts
    
  3. Get the default secret name (in format default-token-xxxx)
    kubectl get secrets
    
  4. Get the token for this secret
    kubectl describe secrets/default-token-xxxx
    
  5. Get the API URL.
    cat $KUBECONFIG
    

    Look for the line like

    clusters:
    - cluster:
     server: https://192.168.1.1:6443
    
  6. Get the CA cert. In the directory where $KUBECONFIG is stored, do
    cat ca.pem
    

Configure Repo

  1. In the GitLab repo, navigate to Operations - Kubernetes

  2. Fill in the cluster details that you got from the previous steps.

  3. In the list of Applications, install the following in order:
    1. Helm Tiller
    2. GitLab Runner
  4. Create a .gitlab-ci.yml file. For example, if I want to run yamllint on my code, an example file will look like:

     before_script:
       - apt-get update
       - apt-get install -y python yamllint
       - apt-get install -y python3-pkg-resources python3-setuptools
       - python --version
       - which python
     yaml-lint:
       script:
         - find . -type f -iname "*.yaml" -o -iname "*.eyaml" | xargs yamllint
    
  5. Commit and push the change. When the change is pushed to GitLab, a runner will start up and run the job specified by .gitlab-ci.yml. Jobs can be viewed from the CI/CD tab.

Limitations

At this point in time, GitLab CE integration can only do one kubernetes cluster per repo. No ability to do dev/test/prod clusters per repo.

Also, it does not support RBAC, so it means that the integration will have full permissions to the cluster. So you really want to dedicate 1 k8s cluster to 1 repo, and not have any other containers running on that cluster.