2

I'm setting up a pipeline that compiles and builds new docker images, and then deploys those images to testing kubernetes cluster.

I'm using a shell runner.

I need to setup my kubectl client to point to the testing kubernetes cluster. (ie. setting the cluster and context).

As I understand it - I should only need to run this once. Is there a way to get this to run once, as defined in the .gitlab-ci.yaml? Or should I just repeat the set up steps everytime in before_script?

3
  • 1
    It widely depend on how you want to configure kubectl, I'd go with env vars and keep it in a before script, this would be idempotent and allow a move to containers later also
    – Tensibai
    Apr 15 '18 at 10:11
  • @dwjohnston what did you try? Please add the .gitlab-ci.yaml.
    – 030
    Apr 15 '18 at 21:25
  • Why is defining it in the before_script not sufficient?
    – 030
    Apr 16 '18 at 11:47
3
+25

I dealt with the same issue. Some people recommended using the Gitlab group "secrets" and using before_script. Since I knew I was also going to deploy and would need other tools on my runner like "helm", I made my own docker container. I still keep my config for my clusters in a base64 encoded group secret but I set it like this in the dockerfile.

ENV kube_config=$kube_config
RUN echo -n ${kube_config} | base64 -d > ~/.kube/config

Now just set an environment variable for your gitlab runner to point to your new image.

KUBERNETES_IMAGE: registry.gitlab.com/MY_USERNAME/MY_REPO_NAME/MY_IMAGE_NAME:latest

Don't forget to test your new container!

stages:
  - build
  - test
  - release

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:$CI_COMMIT_REF_NAME
  CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:latest

before_script:
  - apt-get update && apt-get install docker.io -y
  - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY

Build Image:
  stage: build
  script:
    - docker build --build-arg kube_config=${kube_config} -t ${CONTAINER_TEST_IMAGE} .
    - docker push ${CONTAINER_TEST_IMAGE}
  except:
    - master

Test Kubectl:
  stage: test
  script:
    - docker pull ${CONTAINER_TEST_IMAGE}
    - docker run --rm ${CONTAINER_TEST_IMAGE} kubectl get deployments -n kube-system
  except:
    - master

Test Helm:
  stage: test
  script:
    - docker pull ${CONTAINER_TEST_IMAGE}
    - docker run --rm ${CONTAINER_TEST_IMAGE} helm ls
  except:
    - master

Test Docker:
  stage: test
  script:
    - docker pull ${CONTAINER_TEST_IMAGE}
    - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ${CONTAINER_TEST_IMAGE} docker images
  except:
    - master

release-image:
  stage: release
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
    - docker push $CONTAINER_RELEASE_IMAGE
  only:
    - master

Edit: Missed this part.. I'm using a shell runner.

So post of what I said is probably not relevant. How ever I do think there is some advantages to building and deploying with a gitlab runner directly on a cluster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.