Docker Support

Nomenclature¶

In a multi-container deployment, each container "class" has a name. More than one container may be run in a class, for scalability reasons.

Assuming a simplified Pulp deployment running in Docker, I will need:

• one rabbitmq container
• one mongo container
• one apache (front-end) container
• one resource-manager container (probably running celerybeat here too, but that is not very relevant)
• one or more pulp worker containers

I will have one image name for each of the classes above. Let's assume the names are:

• rabbitmq
• mongodb
• front-end
• resource-manager
• worker

I will create a Docker image for each of the classes, named as above.

I may iterate over the images several times, creating multiple versions of them, distinguished by Docker tags.

From a Docker perspective, the resource identifier (string passed to docker pull) could look like:

• registry.example.com:443/pulp-2/rabbitmq:3.6.10-1 :latest
• registry.example.com:443/pulp-2/mongodb:3.2.12-1 :latest
• registry.example.com:443/pulp-2/httpd:2.4.27-3 :latest
• registry.example.com:443/pulp-2/resource-manager:2.14.2-1 :latest
• registry.example.com:443/pulp-2/worker:2.14.2-1 :latest

On pulp.example.com (which produces the content for crane that is being served from registry.example.com) I have a pulp-2 Pulp repository.

I can use pulp-admin to upload the images to that pulp instance, and I will tag them with the following tags:

• rabbitmq:3.6.10-1, rabbitmq:latest
• mongodb:3.2.12-1, mongodb:latest
• httpd:2.4.27-3, httpd:latest
• resource-manager:2.14.2-1, resource-manager:latest
• worker:2.14.2-1, worker:latest

Later, when Pulp 2.15 is released, I can upload new resource-manager and worker images, tag them with :2.15.0 and :latest (effectively removing the previous :latest tag for each).

Current implementation¶

As currently implemented, pulp-docker requires 5 repositories. The list below would describe potential Pulp repository names and the distributor's repo-registry-id config option for each, that would achieve the setup described above:

Proposed implementation¶

We could add a configuration option to the distributor to allow for more than one image. By default, that option would be off.
Tags are currently very free-form (too much so, see #3127). We could change that to allow for zero or one colon in the tag.
If the configuration option is turned on, then tags with no colon in them could be ignored. Tags with colon in them could be interpreted as <image-name>:<tag>.

Impact on crane¶

If the json files are properly constructed, there may be no impact on crane.