Rolling out a new backend version + Kubernetes + Gitlab CI + Google Cloud

12/2/2018

I don't know how to update my backend workload on my Kubernetes cluster. My Gitlab Pipeline is running without errors. My active revision is still on my first push, so how can I update the revision to call the rolling update action? Can I integrate an automatic rollout into the Gitlab Ci?

.gitlab-ci

image: docker:latest
    services:
      - docker:dind

    variables:
      DOCKER_DRIVER: overlay
      SPRING_PROFILES_ACTIVE: gitlab-ci

    stages:
      - build
      - package
      - deploy

    maven-build:
      image: maven:3-jdk-8
      stage: build
      script: "mvn package -B"
      artifacts:
        paths:
          - target/*.jar

    docker-build:
      stage: package
      script:
      - docker build -t registry.gitlab.com/projectX/ft-backend .
      - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
      - docker push registry.gitlab.com/projectX/ft-backend

    k8s-deploy:
      image: google/cloud-sdk
      stage: deploy
      script:
      - echo "$GOOGLE_KEY" > key.json
      - gcloud auth activate-service-account --key-file key.json
      - gcloud config set compute/zone europe-west3-a
      - gcloud config set project projectX
      - gcloud config unset container/use_client_certificate
      - gcloud container clusters get-credentials development --zone europe-west3-a --project projectX
      - kubectl delete secret registry.gitlab.com
      - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=MYNAME --docker-password=$REGISTRY_PASSWD --docker-email=MYMAIL
      - kubectl apply -f deployment.yml

deployment.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ft-backend
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: ft-backend
    spec:
      containers:
      - name: ft-backend
        image: registry.gitlab.com/projectX/ft-backend
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
      imagePullSecrets:
        - name: registry.gitlab.com

Google Cloud Workload enter image description here

-- laprof
docker
google-cloud-platform
google-kubernetes-engine
kubernetes

2 Answers

12/2/2018

Like Clorichel mentioned in the comments, you'd need to modify your deployment to trigger a rollout. You could use something like Gitflow and Semantic Versioning (if you're not already) to tag your container image. For example, in the .gitlab-ci you could add the Git tag to your container image:

script:
  - docker build -t registry.gitlab.com/projectX/ft-backend:$CI_COMMIT_TAG .
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
  - docker push registry.gitlab.com/projectX/ft-backend:$CI_COMMIT_TAG

In the deployment.yml you would reference the new version:

spec:
  containers:
  - name: ft-backend
    image: registry.gitlab.com/projectX/ft-backend:YOUR_NEW_GIT_TAG
    imagePullPolicy: Always
    ports:
    - containerPort: 8080
-- Jason Lock
Source: StackOverflow

12/2/2018

As discussed in comments, you have to update your Deployment .spec.template to trigger a rollout. An easy way for you to do it is to tag your image upon release.

In your .gitlab-ci.yml file you can use the CI_COMMIT_SHA variable:

# in your docker-build job, update build and push:
- docker build -t registry.gitlab.com/projectX/ft-backend:${CI_COMMIT_SHA} .
- docker push registry.gitlab.com/projectX/ft-backend:${CI_COMMIT_SHA}

# in your k8s-deploy job add this:
- kubectl set image deployment/ft-backend ft-backend=registry.gitlab.com/projectX/ft-backend:${CI_COMMIT_SHA}

That would both version your image on your GitLab project registry, and trigger a rollout.

-- Clorichel
Source: StackOverflow