Set up a CI/CD pipeline with IBM Cloud Hyper Protect Virtual Server as the target

Modern-day DevOps practices involve continuous development, continuous testing, continuous integration (CI), continuous deployment (CD), and continuous monitoring of software applications throughout the development lifecycle. This path from developer to server where the code gets deployed for use is called the CI/CD pipeline, and it forms the backbone of current DevOps operations.

Here is a schematic of a typical CI/CD pipeline:

CI/CD process

This tutorial goes into the details of setting up a CI/CD pipeline with an IBM Cloud Hyper Protect Virtual Server (HPVS) as the target. The Hyper Protect Virtual Server, with its EAL4 isolation capabilities, prevents operators/Site Reliability Engineers (SREs) from accessing customer-HPVS-instances to dump memory, thus locking the environment from unauthorized access.

This figure illustrates the isolation capabilities of the Hyper Protect Virtual Server platform built on IBM LinuxONE:

HPVS on Secure Service Container

Prerequisites

  • A Code-Repository MY-GH-TEST-REPO with 2 branches:
    • Master branch: MY-GH-TEST-REPO/Master
    • Develop branch: MY-GH-TEST-REPO/Develop
  • A Container-Repository — You will use Docker Hub; create a Docker Hub account if you don’t have one
  • An Application-Server for the Hyper Protect Virtual Server Instance that runs on the IBMZ/s390x platform. You will use s390x/nginx, a very lightweight option for hosting a simple static website
  • A CI/CD tool — You will use CI; sign in or sign up with your GitHub ID

Estimated time

Assuming all prerequisites are met, it should take no more than 1 hour to complete this tutorial.

Steps

Step 1: Identify various parts of the development environment

First, you’ll need to identify the various components of the CI/CD pipeline. Typically, developers work on the Develop branch. Once the changes are tested/verified on the Dev-Server, changes are promoted/merged into the Master branch. There may be other branches that merge up to the Develop branch.

Team GitHub branch Server environment
Operations Master Prod-Server
Core development team Develop Dev-Server
UI team (optional) UI-branch Dev-Server
Content team (optional) Content-branch Dev-Server

Step 2: Provision the required Hyper Protect Virtual Server instances

For each branch, you should have a sandbox-server environment where all the changes are tested, as close to the developer as possible. For this tutorial, only 2 environments are being considered:

  • Production environment — supported by the Master branch of the GitHub Repo (MY-GH-TEST-REPO/master)
  • Development environment — supported by the Develop branch of the GitHub Repo (MY-GH-TEST-REPO/develop)

Provision an instance of Hyper Protect Virtual Server with the required T-shirt size using the Hyper Protect Virtual Server entry in the IBM Cloud Services Catalog.

  • You’ll need to specify a my-PUBLIC-SSH-key.
  • Make a note of the public IP address for the Hyper Protect Virtual Server instances that will be used for this tutorial.

Step 3: Install pre-reqs on the Hyper Protect Virtual Server instances

Hyper Protect Virtual Servers are provisioned as vanilla Ubuntu instances, so some pre-req packages will have to be installed:

  • Connect to your Hyper Protect Virtual Server instances:

     ssh -i <my-PRIVATE-SSH-key> root@<public-ip-address>
    
  • Install Docker run time on your Hyper Protect Virtual Server:

     sudo apt install docker.io
     sudo systemctl start docker
     sudo systemctl enable docker
    

Step 4: Configure Travis CI for your GitHub repo

Travis CI is an easy-to-use CI/CD tool that is a available as a service at travis-ci.com. Production pipelines usually require enterprise-grade tools like Jenkins, which require extensive setup.

  • Login at travis-ci.com with your GitHub ID and add MY-GH-TEST-REPO to Travis CI.
  • Add a webhook to your Github repo to send events to Travis CI:
  • Check to see if MY-GH-TEST-REPO shows up in the My Repositories section of your Travis CI dashboard.
  • Add environment variables in your Travis CI account to enable login to your Docker Hub account:
    • Navigate to the repo settings: MY-GH-TEST-REPO/settings.
    • Add the environment variables REGISTRY_USER and REGISTRY_PASS (your user ID and password) for your Docker Hub account.

Step 5: Copy the required configuration files to your GitHub repo

Pipeline configuration with Travis CI requires a few configuration files — use the sample configuration files provided here:

  • .travis.yml — master branch to MY-GH-TEST-REPO/master/.travis.yml

    • Travis CI triggers the website build when a pull request is merged on the master branch.
    • Travis CI publishes the container image to Docker with the latest tag.
    • The Prod-HPVS-server runs a Docker image with the latest tag.
  • .travis.yml — develop branch to MY-GH-TEST-REPO/develop/.travis.yml

    • Travis CI triggers the website build when a pull request is merged on the develop branch.
    • Travis CI publishes the container image to Docker with the dev01 tag.
    • The DEV-HPVS-server runs a Docker image with the dev01 tag.
  • .gitignore — develop branch to MY-GH-TEST-REPO/develop/.gitignore

    • This file is used to exclude files from merging from the develop to the master branch.
  • Dockerfile — develop branch to MY-GH-TEST-REPO/develop/Dockerfile

    • This file is used to build the Docker image with the dev01 tag for the DEV-HPVS-server.
  • Dockerfile — master branch to MY-GH-TEST-REPO/master/Dockerfile

    • This file is used to build the Docker image with latest tag for the Prod-HPVS-server.
  • .dockerignore — master branch to MY-GH-TEST-REPO/master/.dockerignore

    • This file is used to list the files that should or should not be part of the Docker image.

Step 6: Create the CI/CD pipeline

Here’s what the CI/CD pipeline for this tutorial looks like:

CI/CD GitHub setup

Development phase

  1. Developers create pull requests for their updates to be pushed up.
  2. The integration team reviews and merges the pull requests on the Develop branch.
  3. The merge triggers travis-ci to initiate a Ruby/Jekyll build that creates the Docker image embedded with the updated files.
    • You can monitor progress on the travis-ci dashboard.
  4. If the build is successful, travis-ci pushes the Docker image to docker-hub:<your-docker-id>/<your-repository>:dev01 with the dev01 tag.
  5. On your Dev-HPVS instance, run the following command to PULL the docker-image of the website and host it:
    docker container run -it -d --name nginxcontainer -p 9081:80 <your-docker-id>/<your-repository>:dev01
    
    • To view the website that you just created, navigate to http://<external-ip-address-of-hpvs-instance>:9081/index.html.

Deployment phase

  1. Once the Dev-website has been successfully built, a pull request is created to push the changes up to the Master branch.
  2. The operations team reviews and merges the pull requests on theMaster` branch.
  3. The merge triggers travis-ci to initiate a Ruby/Jekyll build that creates the Docker image embedded with the updated files.
  4. If the build is successful, travis-ci pushes the Docker image to docker-hub:<your-docker-id>/<your-repository>:latest with the latest tag.
  5. On your Prod-HPVS instance, run the following command to PULL the Docker image of the website and host it:
    docker container run -it -d --name nginxcontainer -p 8081:80 <your-docker-id>/<your-repository>:dev01
    
    • To view the website that you just created, navigate to http://<external-ip-address-of-hpvs-instance>:8081/index.html.

Continue with updates

  1. Go back to follow the CI/CD pipeline above.
  2. The final step in the CI/CD pipeline picks up the updates and serves the pages through the Docker-Hub image.

Summary

The CI/CD pipeline created in this tutorial contains only two branches of code. For a typical enterprise application with several branches and teams, it’s important to configure the pipelines with role-based access control (RBAC) so that only authorized members of the teams have access to merge and deploy code. This helps prevent unauthorized injection of unsolicited code.

Next steps

To further fortify the pipeline, the Hyper Protect Virtual Server can be used to deploy a Secure Build Server which uses Docker Content Trust (DCT) to establish trust for the images that are pushed and pulled / run from Docker registry.

To introduce build-audit capabilities into the pipeline, have the auditor digitally sign an image in DCT using something like docker trust sign. Before hosting an image pulled from Docker Hub, check to see if the Docker image has been signed by an auditor using something like docker trust inspect.

To learn more about the concepts presented here, see the links in the Resources section in the upper right-hand column.