Task #5060
closedTask #5069: Build pulp 3 containers
Rework 4 existing container images into 1 image with 4 different entrypoints
100%
Description
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-api
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:
/usr/bin/entrypoint-pulp-api
/usr/bin/entrypoint-pulp-content
/usr/bin/entrypoint-pulp-resource-manager
/usr/bin/entrypoint-pulp-worker
Updated by mdepaulo@redhat.com over 5 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.
https://github.com/mikedep333/pulpcore/tree/1-image-to-rule-them-all
Updated by mdepaulo@redhat.com over 5 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:
pulp-api
pulp-content
pulp-resource-manager
pulp-worker
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
Updated by ipanova@redhat.com over 5 years ago
- Status changed from NEW to ASSIGNED
Added by Mike DePaulo over 5 years ago
Updated by Anonymous over 5 years ago
- Status changed from ASSIGNED to MODIFIED
- % Done changed from 50 to 100
Applied in changeset pulpcore|82c56514d66b3e77a9aaca46bb98d3f242f54c8f.
Updated by mdepaulo@redhat.com over 5 years ago
- Status changed from MODIFIED to 5
Updated by mdepaulo@redhat.com about 5 years ago
- Status changed from 5 to CLOSED - COMPLETE
Collapse 4 container images into 1.
They will be used as 4+ different containers by specifying different commands.
Fixes #5060