Dockerized Builds

How can we use docker and extend to our build environment ? What is the benefit of doing so ? This article discusses on the use of docker to create images for our build environment and what is the other use case from the build and release point of view.

The sections which we will discuss here are:

  • Overview of docker
  • Build environment using docker and the steps therein
  • Other use case of Docker from the Build and Release perspective

What is docker ?

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. In simpler terms, to package an application as a self contained box that includes everything needed to run the application  Benefits of docker include that they are smaller than VMs and have an improved performance.  Applications are secure and isolated from other activites of the host system and can effortlessly be deployed and run in multiple environments.

A few of the docker terms are necessary to be understood to enter the build arena for any product:

  • Image: a image inside a docker is a read-only template which in turn is used to create containers
  • Container: started from images, they are directories to contain everything needed to run an application
  • Registry:It is similar to a store to contain images which can be either public or private
  • Dockerfile: a text document containing commands to build a docker image

How to use a docker container:

  • Pull a docker image from a public or private repository
  • Create a container of your own based on the image that is pulled
  • Push the docker image to a private repository

How did we build using docker ?

Used docker to build Symantec product on rhel6 image on a host which is rhel7.That is the beauty of using docker. The hostmachine can be of any OS and can be used to run/build applications of a different OS.

  • On a rhel7 host machine, install the extra rpms required using , wget http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm
  •  If on a RHEL7 machine with partner subscription, we can follow the official instructions https://access.redhat.com/articles/881893#get. Install the epel-release rpm .
  • rpm -ivh epel-release-7-0.2.noarch.rpm, if epel rpm is obtained
  • yum install docker-io
  • #systemctl start docker (This is to start the docker on the host machine)
  • #docker images (Listing so, the command displays all images present under the docker repository)
  • #docker pull <image>(Assuming we have a image already stored and our private repository is 10.xx.xx.xxx, we pull out the image <image>. This operation of pulling the image takes time according to the weight of the image minutes and voila we have the image on our system)
  • #docker run -t -i <image> /bin/bash (This command starts the bash prompt of the image that we downloaded)

what is inside the <image> ?

  • source already checked out for module we wish to build
  • environment file to export the global variables
  • script to run the build

If we would like a build that uses various kernel configurations, then there are 2 ways to do so:

  • Mount the kernels from the host machine to the container using "-v" option like "docker run -i -t -v /linux/kernelsSmiley Surprisedpt/needed <image> /bin/bash"
  • Copy the required kernel images to the containers.

What are the other use cases from the build release perspective ?

Generally when an escalation is recieved, the support engineer or the escalation engineer working on the case needs to search out the sanpshot, kernels used, configurations, dependencies and any other needed information about the release. Why not store the entire GA build area into a docker image ? By doing so, the build environment is readily available for the engineer to use with all the needed dependencies.

Some benefits pointed out:

  • Production build machines setup, multiple build machines as of today to support all available platforms, flavors
  • Everyone needs a separate account
  • All active users share the hardware resources on the build machines
  • Need to configure the build environment for different products

whereas using docker:

  • Ready to use image
  • Less time (7 steps as above) for a new engineer for build setup
  • No need of account on build machine for build purposes
  • Multiple containers can be accessed at the same time, that is multiple images can be accessed at the same time

 Limitations of using docker as of now is that we cannot use it on rhel5 or any non-linux platform.

The only 2 things that anybody needs to start a build:

  • A Linux or a MAC book
  • IP of a private repository.