devops-promotion.adoc

Application Promotion Between Environments

In this lab you will learn about application promotion between deployment environment and promote services from Dev environment to the Prod environment.

Background

The CI/CD pipelines we created so far operate solely in the Dev environment. In this lab, you will extend the pipeline to promote the Cart service to the Production environment where it runs alongside other services that together build the CoolStore online shop. It is essential to build the application and the container image only once and use the same container image throughout the pipeline to guarantee that the same container image is tested and verified to be of acceptable quality for deploying in the Prod environment.

Creating the Production Environment

Go to project list in OpenShift and click on New Project for the Prod deployment environment for the CoolStore application:

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

Now you should see the Dev and Prod projects in the OpenShift Web Console, as well as via CLI:

$ oc get projects

CoolStore Webshop in Production Environment

You can use an OpenShift template to deploy the CoolStore application services in the Prod environment. An {{OPENSHIFT_DOCS_BASE}}/dev_guide/templates.html[OpenShift template] describes how to build, configure and deploy a set of contains in a reproducible manner. Note that normally, the container images for Web UI, Coolstore GW, Catalog and Inventory services are already built by respective teams and are available in the OpenShift integrated container registry. The CoolStore template would then just pull these images and deploys and configures them in the Prod environment.

In this lab, however, you are the whole team! Therefore you should build the images for once so that you can use them for the rest of the lab and deploy them in the production environment.

Install the following template so that you can deploy the production images from the registry.

$ oc project prod-{{PROJECT_SUFFIX}}
$ oc create -f https://raw.githubusercontent.com/openshift-labs/devops-labs/ocp-3.11/openshift/coolstore-deployment-template.yaml

You can go ahead and deploy the CoolStore application in production. In the Prod project, click on Add to project and Select from Project. Choose the CoolStore Deployments template and then Next and again Next.

If you remember, the Cart route hostname was generated for you in the Cart Dev project with the format: cart-dev-{{PROJECT_SUFFIX}}.<HOSTNAME>. Specify the Hostname Suffix in the form by replacing cart-dev-{{PROJECT_SUFFIX}} in that generated format with prod-{{PROJECT_SUFFIX}}, so that the value of Hostname Suffix would be prod-{{PROJECT_SUFFIX}}.<HOSTNAME>

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

Click on Create, and then on Continue to overview. You will notice that all services, including Cart are deployed in Prod environment.

Let’s promote Cart container image that is running in the Dev environment to Prod environment. The reason for doing so is to guarantee that the container image that runs in Prod environment is the same image that is running and has been tested in the Dev environment.

You can use the oc tag CLI command for promoting images between environments.

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

$ oc tag dev-{{PROJECT_SUFFIX}}/cart:latest prod-{{PROJECT_SUFFIX}}/cart:prod

Tag cart:prod set to dev-{{PROJECT_SUFFIX}}/cart@sha256:ee898ec51ab7bbce53ff41425683a3e5db98a4fe835a30ca1452b6a6d59ea1bd.

The above command promotes the cart:latest container image which is the latest image build of the Cart service in the Dev environment, to the Prod environment and names it cart:prod. As soon as the cart image is promoted to the Prod environment, the Cart container gets automatically deployed. As new Cart service container images are built, the Prod environment remains intact until you promote the new image builds to the Prod environment after sufficient testing.

When the Cart service is ready, click on the Web UI route url and verify that CoolStore online shop is working correctly. If the product list is not displayed correctly, refresh the page a few times.

Automated Application Promotion

Now that you are familiar with the concept of application promotion between environments, let’s automate the promotion process via the CI/CD pipeline you created in previous labs. Furthermore, deployment in Prod environment is a critical step that not all organizations are ready to automate yet. Therefore, you can introduce a manual step in the pipeline to allow a release manager to manually approve or reject a Prod deployment. The following diagram shows the updated pipeline stages:

Open the Jenkinsfile you added to the pipelines Git repository and add the following stages for manual approval and promotion to Prod environment after the Component Test stage in the pipeline:

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

stage('Promote to Prod') {
  steps {
    timeout(time:15, unit:'MINUTES') {
        input message: "Approve Promotion to Prod?", ok: "Promote"
    }
    script {
      openshift.withCluster() {
        openshift.tag("dev-{{PROJECT_SUFFIX}}/cart:latest", "prod-{{PROJECT_SUFFIX}}/cart:prod")
      }
    }
  }
}

Note that the manual approval process is usually integrated into the existing IT workflow management systems such as ServiceNow, JIRA Service Desk, BMC Remedy, etc so that authorized roles can approve the deployments to Prod environment from their own dashboards. In this lab, you will use Jenkins UI directly for approving the image promotion.

Push the modified Jenkinsfile to the Git repository and enter your Git username and password if asked:

• Username: {{GIT_USER}}

• Password: {{GIT_PASSWORD}}

$ cd ~/cart-service
$ git add Jenkinsfile
$ git commit -m "Added image promotion to the pipeline"
$ git push origin master

The Cart pipeline now spans over multiple projects and performs actions in both Dev and Prod environments. When a person performs an action in OpenShift such as creating a build or deploying a container, they have to first authenticate to OpenShift using their credentials. However, when an application or container e.g. Jenkins server wants to perform actions on OpenShift, there are no regular user credentials to be used for authentication. Service Accounts in OpenShift provide a flexible way to control access without sharing a regular user’s credentials in those scenarios. Every container requires a service account to run on OpenShift and unless specified otherwise by default they run with the project-scoped default service account which is created and assigned automatically to each container when they get deployed.

Although most containers use the default service account in their projects, the Jenkins template used to deploy Jenkins server creates and uses a service account with the name jenkins (instead of default) to simplify controlling Jenkins server access to resources without impacting the permissions of other containers.

Just like regular accounts, every service account has a name which follows a specific format: system:serviceaccount:<project>:<name>. <project> is the project name in which the service account is created and <name> is the name of the service account. Given the above, the name of the service account used to run the Jenkins container is system:serviceaccount:dev-{{PROJECT_SUFFIX}}:jenkins.

The very same way that roles are assigned to regular user accounts, they can be assigned to service accounts to authorize an application or a container to give them access to other projects. Since the Jenkins server now tags an image in the Prod environment, you should give permissions to the Jenkins service account to perform that action.

Use the OpenShift CLI to assign the Dev project’s Jenkins service account the edit role in the Prod project:

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

$ oc policy add-role-to-user edit system:serviceaccount:dev-{{PROJECT_SUFFIX}}:jenkins -n prod-{{PROJECT_SUFFIX}}

Alternatively you can use the OpenShift Web Console by clicking on Resources → Membership on the left sidebar menu in the Prod project. Click on Service Accounts tab and then on Edit Membership. Fill the text fields and then click on Add and then Done Editing.

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

• Name: jenkins

• Project: dev-{{PROJECT_SUFFIX}}

• Role: edit

You are all set to run the new pipeline. In the Dev project, click on Builds → Pipelines on the left sidebar menu and then click on Start Pipeline button on the right side of cart-pipeline-git. A new instance of the cart-pipeline-git starts running using the updated Jenkinsfile in the Git repository.

Manual Approval

The pipeline builds and deploys the Cart service in the Dev project and then pauses at the manual approval stage to allow controlling the deployment flow into the Prod environment.

Since use of ServiceNow or other IT Workflow systems is out of the scope of this lab, you will Jenkins to approve the production deployment. Click on Input Required which takes you to the Jenkins login page which is integrated with OpenShift OAuth authorization server. Login with your OpenShift credentials.

Caution

Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.

• Username: {{OPENSHIFT_USER}}

• Password: {{OPENSHIFT_PASSWORD}}

Click on Promote to approve promoting the Cart container image from Dev environment to production environment.

Upon approval, the pipeline continues and promotes the Cart container image from the Dev environment to the Prod environment and deploys it in the Prod environment.

Congratulations! You have now an end-to-end pipeline that tests, builds and deploys every change that successfully finishes the pipeline into the Prod environment after being approved by the release manager.