Various container build services offer developers to build their image with a git push and scan the container for known CVEs (as a paid service). What they don't provide is Dockerfile linting; scanners that would scan for available package updates (rpm, pip, npm, gem); a build process that rebuilds an image not only on git push but also when there's RPM update in its enabled repo or when its base image is updated. Welcome to CentOS Container Pipeline project. It provides all these and more, out of the box, free of cost, on CentOS infra, and with focus on open source developers. All it needs is link to git repo containing the Dockerfile. And also email address to provide all that helpful information. ;)

1. git push to build, test and scan
your containers
Dharmit Shah ( @dharm1t )

2. नम तेHello :)

3. Imagine... ● You are maintaining 10 images
● All images are based on same image

4. Life is good… right?

5. Imagine...
● Meltdown / Spectre hits the world!
● CentOS base image gets updated
● Manually update all your images!

6. What if there’s
about 100 images?

7. This sucks!

8. CentOS Community
Container Pipeline

9. Why yet another pipeline?
● No solution to lint, build, scan images on regular basis
● No triggers other than code push to git repo
● Limited scanning capabilities; available for a cost
● No regular scan reports on all the images
● No dependency between images (parent-child relationship)
● No open source solution to do all of these!

11. Flow explained ● PR on container-index (one-time)
● Pre Build
● Lint
● Build
● Test
● Scan
● Deliver (Push) and Notify

12. PR on
container-index
● Create a yml entry in container-index
● Job is created and we trigger the build

13. Example yml file

14. Pre Build ● Generate binaries/artifacts
● Use the artifact(s) to create image

15. Lint ● Lint the Dockerfile
● Point out common errors and warnings
○ Running privileged container
○ Lack of yum clean all
○ Lack of labels
○ Lack of CMD/EXPOSE commands

16. Build ● Build the container image
● Build through custom build context

17. Test ● Removed from the scope after CFP :-(
● Different types of testing
○ Code testing (unit, functional, etc.)
○ Container testing
○ Volume mounts
● Users will have to rely on CI

18. Scan ● Package update scanner
○ rpm
○ npm
○ pip
○ gem
● Container capabilities
● RPM verification

19. Deliver (Push) ● Deliver the image to registry.centos.org
● Tag the image with user’s desired tag
● User is notified on their email with
○ Cause of build
○ Linter results
○ Build logs
○ Scanner reports

20. What else?

21. Weekly scan,
Repo update
tracking,
automated build
trigger
● Scanners run on weekly basis
● Scanner reports emailed to the user
● Automatically rebuild for RPM updates
● Rebuild images when:
○ base image gets updated
○ git push
● Custom build context

22. ● Dockerfile Lint → Project Atomic
Dockerfile Lint
● Build → OpenShift Build Config
● Scan → Atomic Scanner
● Registry → Docker distribution
● CI → CentOS CI (https://ci.centos.org/)
Toolchain

23. Quick Notes ● Canonical source of truth for images
maintained by the CentOS team
● SCLo images - nodejs, python, etc.
● Eclipse Che stacks
● Language stacks (go, python, java)

24. What’s next?

25. Plan ● Major updates in UI
○ Logs, reports, etc.
○ Go-to place for getting started
● “On-demand” build for an image
● OpenShift cluster
● Test images on
○ RHEL
○ CentOS
○ Atomic Host

26. Resources
● https://github.com/CentOS/container-pipeline-service/
● https://github.com/CentOS/container-index/
● #centos-devel on Freenode
● centos-devel@centos.org

27. Thank you!