The goal of CentOS Container Pipeline project is to let any open-source project build container images on the CentOS Linux and additionally provide them with:

• Dockerfile lint report
• Container scanner reports that:
  • Scan the image for RPM updates
  • Scan the image’s RUN label for capabilities that resulting container might have when started
  • Scan the image to verify installed RPM packages
  • Scan the image for possible updates to third party packages installed via npm, pip or gem
• Cause of build whenever an image is built/rebuilt.

In this article we’d like to summarize the features provided by the Pipeline and current state of the project. To get an idea of container images already available via registry.centos.org, please check the wiki page of Container Pipeline.

How does the CentOS Container Pipeline work?

Let’s say you have an open-source project that you’d like to containerize on CentOS platform. The source code is hosted on one of the various web-based Git version control repositories like GitHub, Bitbucket, GitLab, etc accessible over the Internet. You have a Dockerfile that uses CentOS base image to build the container (we can help you here if your existing Dockerfile is based on Alpine, Debian, Ubuntu, etc.)

Now all you need to do is create cccp.yml file in the repo at same location as your Dockerfile and open a pull request on CentOS/container-index repository to get started (more on the yaml file and how to open PR later in the post.) The generated container image can then be pulled via:

$ docker pull registry.centos.org/<app-id>/<job-id>:<desired_tag>

The cccp.yml or cccp.yaml, that’s required in your Git repository, must contain value for job-id at the very least. This is generally the name of the image like httpd for an Apache web server image or nginx for an NGINX image, so on and so forth.

 

For the pull request to be opened on CentOS/container-index, you’ll need to:

• Fork the repository under your GitHub username
• Clone it onto your system
• Add a yml entry under `index.d` directory. Name of this yml file is recommended to be same as appid that you want in the aforementioned `docker pull` command.
• Contents of this yaml file should be like the example below:

  Projects
      - id: 1
        app-id: centos
        job-id: centos
        git-url: https://github.com/CentOS/sig-cloud-instance-images
        git-branch: CentOS-7
        git-path: docker
        target-file: Dockerfile
        desired-tag: latest
        notify-email: you@example.com
        depends-on: null

  id should be an integer and shouldn’t repeat in the yml file.
  app-id is the namespace of your container images. This should be same as filename
  job-id is the name you want for your container image
  git-url is the complete URL to your Git repo
  git-branch is the branch within your repo. Default is `master`
  target-file is the name of Dockerfile to be used to build container image
  desired-tag is the tag you’d like to apply to resulting container image
  notify-email is the email address you’d like to be notified upon
  depends-on is the container image that your resulting image is dependent on. Generally the one used in FROM statement in Dockerfile. Image mentioned here must exist in the container-index.

  For more info on the yml file, we recommend you refer its dedicated section in README. For more examples on writing the yml file, we recommend you refer the index.d directory which contains yml files for various open-source projects as well as individual users.

Once the pull request is merged, Container Pipeline Service hosted on CentOS infrastructure picks it up and lints the Dockerfile, builds the container image, tests it, scans it using various atomic scanners and sends the result of these processes to email address you mentioned as `notify-email`. If it detects any issue at any of the above stages, it’ll stop right there and send you an email along with logs.

Once the image is built for the first time, every time you push a change to the Git repository’s (`git-url` variable) branch being tracked via the container-index (`git-branch` variable), a new image is built and lint-build-test-scan processes are re-executed. This provides the developer with a feedback on the changes (s)he pushed.

Weekly image scanning, RPM tracking and parent image update

Besides the one-time image scanning that happens when the image is built for the first time, CentOS Container Pipeline service does a weekly scanning and sends the results to the developer. This email only contains the information generated by the atomic scanners, albeit from a fresh run.

The Pipeline service also tracks the RPM repositories enabled in the container image. It checks these repositories once everyday to find if there’s any update available from any of the repos. If it finds an update, the container images which have those repositories enabled, will be re-built and re-scanned.

If the parent image of the project (`depends-on` variable) is updated, the child image automatically gets re-built and re-scanned.

Work in Progress features

Besides the features mentioned above, we are working on providing the ability to build images for aarch64 architecture.

We are also working on saving data-points that will store state of the Pipeline to database and help us churn useful metrics out of it. One thing where we'll be able to use it is to generate a real-time view of the build process.

Feature to let user know what is the current status of their build.

We are working on providing a brief summary of errors/warnings that scanners found in the container image.

Known issues

There are a few issues we’re working on right now and hope to get them fixed soon

• Monitoring the overall service is in its nascent stages and we need to improve it to know of an issue before the users point them towards it. We use Sentry for monitoring the Pipeline service
• Although we have a UI for the registry at https://registry.centos.org/, we need to tweak it to be more useful for the end-user to:
  • Have a quick look at the Dockerfile used to build the image
  • Access the logs for historic builds
• RPM tracking issues wherein a project removed/updated from CentOS/container-index doesn’t get deleted/modified in the underlying database and hence triggers rebuild for incorrect image when it finds any of the various enabled repositories updated.

Have questions or suggestions?

We are always looking forward to community participation and community feedback. The project is open-source from day one. If you have any queries around how to get started or, why certain things works in certain way or, you would like to see a feature or, anything else, feel free to ping us on #centos-devel IRC channel on Freenode network.

Dharmit Shah ( dharmit on irc )