TA #4 — Deploy docker image to Cloud Run using Jenkins

[TA] — Test Automation article series

This guide explains how to build docker image in dockerized Jenkins, push image to Google Container Registry and deploy it to Cloud Run.

Automate build image using Jenkins and deploy it to Cloud Run

Agenda

1. Set up Jenkins with docker in docker
2. Install gcloud SDK to container
3. Write Jenkins pipeline for building image from GitLab repo and deploy it to Cloud Run
4. Recap: why should we deploy the application to Cloud Run

Set up Jenkins with docker in docker

1. In Google Cloud Platform create Debian VM instance in Compute Engine and install Docker (https://docs.docker.com/install/linux/docker-ce/debian/)

2. Connect to VM and run

docker run -d -p 8099:8080 -v /var/run/docker.sock:/var/run/docker.sock -v jenkins:/var/jenkins_home khimin1719/jenkins:v1

where himin1719/jenkins:v1image represents a docker file with Jenkins and installed docker.

Snippet of docker file: https://gist.github.com/naz1719/18160eb988ce27dc35f65a416998a2e1

3. Navigate to <server_ip>:8099 and install suggested plugin and so on

Install gcloud SDK to container

1. Step into sh of container

docker exec -it <container_id> sh

2. Follow steps of:

• https://cloud.google.com/sdk/docs#deb
• https://cloud.google.com/container-registry/docs/pushing-and-pulling

Write Jenkins pipeline for building image from GitLab repo and deploy it to Cloud Run

1. Jenkins -> Creadentials -> Add Credentials -> chose Username and password and enter GitLab cred if you are using GitLab

Jenkins, Add credentials

2. New Item -> Pipeline Project and use this pipeline

#!groovy
pipeline {
    agent any
    environment {
        IMAGE_VERSION = "${env.BUILD_NUMBER}"
        LAST_CLOUD_RUN_REVISION = "back-end-${currentBuild.previousBuild.getNumber()}"
        IMAGE_NAME = "gcr.io/<GOOGLE_CLOUD_PROJECT_ID>/back-end:v1.1.${IMAGE_VERSION}"
        PREVIOUS_IMAGE_NAME = "gcr.io/<GOOGLE_CLOUD_PROJECT_ID>/back-end:v1.1.${currentBuild.previousBuild.getNumber()}"
    }
    stages {
        stage('Git checkout') {
            steps{
                git (
                        credentialsId: '<JENKINS_CREDENTIALS_ID>',
                        url: '<GIT_URL>',
                        branch : 'develop'
                )
            }
        }
        stage ("Remove last docker image"){
            steps{
                catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                    sh "docker rmi -f ${PREVIOUS_IMAGE_NAME}"
                }
            }
        }
        stage("Build new docker image"){
            steps{
                sh "docker build --tag=${IMAGE_NAME} . --file=docker/Dockerfile"
            }
        }
        stage("Push to Google Container Registry"){
            steps{
                sh "docker push ${IMAGE_NAME}"
            }
        }
        stage("Delete last image from Container Registry"){
            steps{
                catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                    sh "gcloud container images delete ${PREVIOUS_IMAGE_NAME}"
                }
            }
        }
        stage("Deploy new image to Cloud Run"){
            steps{
                sh "gcloud run deploy back-end --image  ${IMAGE_NAME} --platform=managed --region=us-central1 --port=8080 --revision-suffix=${IMAGE_VERSION}"
            }
        }
        stage("Delete last Cloud Run revision"){
            steps{
                catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                    sh "yes | gcloud run revisions delete ${LAST_CLOUD_RUN_REVISION} --platform=managed --region=us-central1"
                }
            }
        }
    }
}

As a result we have such pipeline:

P.S

Allow run docker as not root user, because with sudo you can’t push image to Google Container Registry.

Recap: why should we deploy the application to Cloud Run

Intro: Cloud Run allowing you to run any stateless http container in a fully managed environment, paying only for the exact resources you use.

Cons:

• Automatic HTTPS URL
• Integrated logging & monitoring
• Fast autoscaling
• Usage of Docker container
• Knative compatible
• Custom domain names
• Abstract away all infrastructure management

Pros:

1. Doesn’t have huge community
2. raw product, not allow a lot of customization