Update the docker image for a service

The goal of this section is to show how you can update the docker image for a service, after you have built that image.

Example Workflow

This example makes some assumptions:

• Your workflow already has a build job - we created one in the previous section

deploy:
  stage: deploy
  image:
    name: duplocloud/duploctl:v0.2.27
    entrypoint: [""]
  # this will have DUPLO_HOST and DUPLO_TOKEN
  environment:
    name: $TIER/$DUPLO_TENANT
    url: ${MYAPPS_URL}
  rules:
  # run when a new tag is pushed
  - if: $CI_COMMIT_TAG && $CI_PIPELINE_SOURCE == "pipeline"
    when: always
  variables:
    # build your image here
    CI_IMAGE: ${IMAGE_REGISTRY}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}:${CI_COMMIT_TAG}
    GIT_STRATEGY: none # no need to pull the repo
  needs:
  - job: publish_image
    optional: true
  before_script:
  - echo "Updating service ${CI_PROJECT_NAME} with image ${CI_IMAGE}"
  script: duploctl service update_image $CI_PROJECT_NAME $CI_IMAGE

References

• Duploctl Service Resource

• Duplocloud Services

Case: Build and Push to DockerHub

The goal of this section is to show how you can build a docker image and push it to DockerHub.

It does three basic things:

• Logs in to DockerHub

• Builds and tags your docker image, with the tag based on the git commit SHA.

• Pushes your docker image

Example Workflow

Here is an example gitlab workflow that builds a docker image and pushes it to DockerHub.

To use it you will need to change:

• DOCKERHUB_USERNAMEvariable

• DOCKERHUB_REPOvariable

• DUPLO_HOSTvariable

• DUPLO_SERVICE_NAMEvariable

• TENANT_NAMEvariable

variables:
  DOCKERHUB_USERNAME: duplocloud               # CHANGE ME!
  DOCKERHUB_REPO: mydockerhubid/myrepo         # CHANGE ME!
  DUPLO_HOST: https://mysystem.duplocloud.net  # CHANGE ME!
  DUPLO_SERVICE_NAME: myservice                # CHANGE ME!
  TENANT_NAME: mytenant                        # CHANGE ME!

docker-build:
  # Use the official docker image.
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker login -u "$DOCKERHUB_USERNAME" -p "$DOCKERHUB_PASSWORD"
  script:
    - |
      tag=":$CI_COMMIT_SHA"
      echo "Running on branch '$CI_COMMIT_BRANCH': tag = $tag"
    - docker build --pull -t "$DOCKERHUB_REPO${tag}" .
    - docker push "$DOCKERHUB_REPO${tag}"
  # Run this job in a branch where a Dockerfile exists
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - Dockerfile

Case: Build and Push to Amazon ECR (Elastic Container Registry)

The goal of this section is to show how you can build a docker image and push it to Amazon ECR.

It does three basic things:

• Logs in to Amazon ECR

• Builds and tags your docker image, with the tag based on the GitLab CI Pipeline execution id.

• Pushes your docker image to ECR

Prerequisite - A repository in ECR must have been created before proceeding with the next steps.

This process uses DuploCloud API Token (refer DuploCloud API Token) to gain access to AWS ECR.

Go to GitLab > Settings > CI CD > Variables > Expand and ensure that DUPLO_TOKEN variable is set and has correct value. Check the Protect Variable and Masked options for security purposes. You can refer to Configuring GitLab for the steps to setup a service account and to create a token for the newly configured account. The service account must have admin role.

The script uses amazon/aws-cli image as the base running image and uses Docker-in-Docker (docker/dind) to run the Docker commands. It uses duplo_utils.sh script from DuploCloud to get configuration from the DuploCloud instance.

Example Workflow

Here is an example gitlab workflow that builds a docker image and pushes it to DockerHub.

To use it you will need to change:

• DOCKER_REGISTRYvariable

• DOCKER_REPO variable

• DUPLO_HOST variable

• DUPLO_SERVICE_NAME variable

• TENANT_NAME variable

• AWS_DEFAULT_REGIONvariable

• APP_NAMEvariable

variables:
  DOCKER_REGISTRY: <xxxxxxxxxxx>.dkr.ecr.<ecr repo region>.amazonaws.com
  DOCKER_REPO: <xxxxxxxxxxx>.dkr.ecr.<ecr repo region>.amazonaws.com/xxx-yyy
  AWS_DEFAULT_REGION: <duplo master aws region>
  AWS_ECR_REGION: <ECR region>
  APP_NAME: <repo name>
  DUPLO_HOST: https://<instance>.duplocloud.net  
  DUPLO_SERVICE_NAME: <duplo service name>
  TENANT_NAME: <Tenant Name>
  DOCKER_HOST: tcp://docker:2375

stages:
  - build
  - deploy

build-and-push-job:
  stage: build
  image:
    name: amazon/aws-cli
    entrypoint: [""]
  services:
    - docker:dind
  before_script:
    - yum install -y wget jq
    - amazon-linux-extras install docker
    - wget https://raw.githubusercontent.com/duplocloud/demo-npm-service/master/.circleci/duplo_utils.sh
    - chmod +x duplo_utils.sh
    - source duplo_utils.sh
    - with_aws>tmp.txt  #Get secrets using with_aws script from source duplo_utils.sh
    - cat tmp.txt
    - cat tmp.txt|grep -i AWS_>tmp1.txt
    - cat tmp1.txt
    - source tmp1.txt
    - export $(cut -d= -f1 tmp1.txt)
    - aws ecr get-login-password --region $AWS_ECR_REGION | docker login --username AWS --password-stdin $DOCKER_REGISTRY
    - rm tmp.txt tmp1.txt   #remove the secrets from the runner
  script:
    - |
      tag="$CI_PIPELINE_IID"
      echo "Running on branch '$CI_COMMIT_BRANCH': tag = $tag"
    - docker build -t "$DOCKER_REGISTRY/$APP_NAME:${tag}" ./nginx/
    - docker push "$DOCKER_REGISTRY/$APP_NAME:${tag}"
    - docker logout #For security

DuploCloud uses cURL commands to support Continuous Integration and Deployment (CI/CD) in GitLab

Prerequisites

To interact with your Duplocloud Portal from GitLab CI/CD, you need to follow these steps.

1. Create Service Account

First you need a service account in your portal which has the needed permissions.

2. Save The Variables

Now we can save the information about the service account within the Gitlab CI/CD Environment variables. You mainly need to set DUPLO_HOST and DUPLO_TOKEN variables.

Limit Level Scope

Gitlab does have the option to set these variables at a variety of level scopes; organization, group, project. For example, you can set variables at the organization level and then all projects would be able to interact with your portal.

Limit Environment Scope

Gitlab has a unique feature to scope variables into tiers as well. This is very useful when you have many instances of an app within some tiers like dev, stage, prod. With this you can scope a variable like this dev/* which means any Gitlab Environment with that prefix will inherit this variable. This means you can make all dev environments share the DUPLO_HOST variable. This can group tenants under namespace as well, so you can rename your dev01 tenant to be a dev/dev01 to be an environment under a tier in Gitlab CI. This is particularly useful with multiple Duplocloud Portals.

References

• Gitlab CI/CD Docs

• Using Gitlab Environments

• Create Duplocloud Users