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:
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:
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: firstname.lastname@example.org 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.
There are a few issues we’re working on right now and hope to get them fixed soon
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 )