Task #5060

Task #5069: Build pulp 3 containers

Rework 4 existing container images into 1 image with 4 different entrypoints

Added by over 2 years ago. Updated about 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:
Sprint 55


In order to avoid container image layering sprawl, especially when building the container images with different sets of plugins, we need to go from 4 container images:
pulp-content (based on pulp-api)
pulp-worker (based on pulp-api)
pulp-resource-manager (based on pulp-api)

To just one image.
(Name will depend on whether plugins are installed, and which ones).

It will be the responsbility of the operator/script to call the 4 different entrypoints, 1 for each service/container.

The image will need to provide commands (with stable paths) that encapsulate all that I need to be done for each service/container. Right now it may only be a command with a symlink, but later on it may be a script. For example:

Associated revisions

Revision 82c56514 View on GitHub
Added by Mike DePaulo over 2 years ago

Collapse 4 container images into 1.

They will be used as 4+ different containers by specifying different commands.

Fixes #5060


#1 Updated by daviddavis over 2 years ago

  • Parent task changed from #5004 to #5069

#2 Updated by over 2 years ago

  • % Done changed from 0 to 50

I reworked them, but still need to figure out naming conventions and stable interfaces for CMDs/ENTRYPOINTs.

#3 Updated by over 2 years ago

Status Update:

I've done more research, including discussion with #podman on Freenode.

I've decided to keep the current common entrypoint in the Dockerfile, and use the commands that we're currently using, but with the /usr/bin/ dropped:

These are the same as the systemd service names.

The entrypoint can always take special steps based on the command passed to it.

Alternatives considered:
1. Use a label like ROLE=pulp-api (This has the disadvantage of being less straightforward than specifying the command. The command is still like a role.)
2. Use a podman runlabel (No Docker support, and would only work for a single container/process/service anyway.)
3. `podman play kube` (No docker support, and the stable command API would be valuable for users that never see updated kube .yml file, but run the "latest" image. Still, I might use this instead of a script to launch all 4 containers.)
4. `docker compose` (Same as above, except Docker proprietary.)
5. All processes in 1 container - Not how containers are supposed to be used, and prevents auto-scaling done by K8s.

TODO: Update pulp-operator for this

#4 Updated by over 2 years ago

  • Status changed from NEW to ASSIGNED

#5 Updated by Anonymous over 2 years ago

  • Status changed from ASSIGNED to MODIFIED
  • % Done changed from 50 to 100

#6 Updated by over 2 years ago

  • Status changed from MODIFIED to 5

#7 Updated by about 2 years ago

  • Status changed from 5 to CLOSED - COMPLETE

Please register to edit this issue

Also available in: Atom PDF