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.