Hi,
One of the Katello's main goals is to provide a life-cycle management
around the content in the infrastructure, a.k.a are my hosts
up-to-date? No? Make it so!
As part of a Adam Ruzicka's bachelor’s thesis, we are looking into adding a
possibility to introduce Katello's patch management into the docker
containers.
As we've got into a point, where we have something that can be shown [1],
as well as looking for feedback and input for further direction,
we would like to invite you for a short demo of the current
status with Q&A and further discussion if needed.
The event will be tomorrow 14:30 GMT via
https://plus.google.com/u/0/events/chpovibe252hpu0d68sj9po6dj0
Some background info:
···
---------------------The core of the functionality is build based on content views: one can
select the content view and environment or an activation key, a git repository containing the Dockerfile to build and the base image to be used.
When the build is triggered, the container is set up to consume content from Katello using subscription-manager.
Also, the original FROM image is (optionally) replaced by the one specified in the
build configuration: this gives us the ability to have full control over the
image. One could take the base image (let’s say a CentOS)
and move that through the dev->test->production lifecycle and
base the rest of the images on the production version
of the base image. We then also know, that when the base image
is updated, what are the other images that need rebuilding as well.
Once the image is produced, we can push the metadata about the
installed images back to the Katello and let Pulp compute the
applicable updates later, as we do that already for the traditional
hosts.
For the build service itself. we’ve initially taken an approach of
building images inside a container. The core of it is the project
Dock [1], which provides a build container with pluggable architecture
(with setting the content view repositories, or pushing the images
back to Katello as plugins).
The reasons for this are:
- from it’s nature, we can expect that the compute resource providing
a docker runtime is already available - other projects (such as OpenShift) takes the same approach so that
we can share common code (as we already did with [2] - with further Kubernetes integration, we should get the scale-out
functionality for free. (fire-and-forget tasks seem as a perfect
match for the technology as the Docker is) - ability to easily test the builds on a local infra with minimum
dependencies.
Current status
We went thought the initial stage, where we are now able to get the
data about the build from the user, trigger the docker container to
build the image based on this data, track the progress of the build
and collect the metadata (as the list of installed images) afterwards.
This will be shown as part of the deep-dive.
The next steps are:
- mapping the Pulp consumer to the images and sending the image
package profiles to the Pulp - the UI/API around the updates applicability of the images next to
the standard content hosts - bulk updates of the images, a.k.a shellshock!!!
- ability to rebuild the images without Dockerfile provided (just yum
update or something like that)
We would like to use the deep-dive to help us moving the project the
right direction.
[1] - https://github.com/adamruzicka/dockerro
[2] - https://github.com/DBuildService/
– Ivan