Story #6205
closed
[Epic] As a user, I have a single container with all Pulp services
Status:
CLOSED - CURRENTRELEASE
Description
Motivation¶
A Pulp user has a requirement where they want to launch Pulp's in each datacenter to sync content around the world daily. They specifically can only launch 1 docker container (their requirement). This is because there are too many individuals at various sites with equipment/networking differences to make deploying multiple containers feasible.
Solution¶
He proposed that we do what Gitlab does and use a userspace process launcher like s6-overlay to have all the services in that one container.
What's in the image?¶
- All GA's plugins would be in the image.
- S6 would start the postgresql and apply the migrations
- Then S6 starts redis, gunicorn (api), gunicorn (content app), nginx, resource manager, and two workers.
Building it¶
We'll build it nightly on Travis similar to how we build our other containers nightly.
Shipping it¶
We'll ship it through the pulp account on quay
Advertising it¶
We should put it on the homepage of https://pulpproject.org/
- Description updated (diff)
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
Don't forget to think about how to handle updates in this single-container case
ggainey wrote:
Don't forget to think about how to handle updates in this single-container case
I was thinking updates will be handled by migrations application, which will happen each time the container is started. It's connected to the long-living filesystem backing the database and filesystem so each time it's started it can upgrade from the files it finds then.
As mentioned on the Mailing list (correction: accidentally replied to Tania individually):
if we do pursue this, we should at least consider using something else with less duplicate code to accomplish this, like our ansible-pulp roles with ansible-bender, or adapting our existing CI's ansible-pulp molecule container w/ systemd (normally a temporary artifact.)
Also:
We have the insta-demo already for a dead simple deployment. This use case covers a simple (but less simple) deployment for people with existing small-scale container infrastructure.
We have to be concerned with postgres & rq also
We have to account for persistent data in volume mount(s). And upgrading it over time.
#5394 Separate out building the pulpcore container image from building a plugin image, and an overall strategy for building container images with different sets of plugins, is still relevant.
- Status changed from NEW to ASSIGNED
- Assignee set to dkliban@redhat.com
- Sprint set to Sprint 67
- Sprint changed from Sprint 67 to Sprint 68
- Sprint changed from Sprint 68 to Sprint 69
- Sprint changed from Sprint 69 to Sprint 70
- Sprint changed from Sprint 70 to Sprint 71
- Sprint changed from Sprint 71 to Sprint 72
- Sprint changed from Sprint 72 to Sprint 73
- Sprint changed from Sprint 73 to Sprint 74
- Sprint changed from Sprint 74 to Sprint 75
- Sprint changed from Sprint 75 to Sprint 76
- Sprint changed from Sprint 76 to Sprint 77
I believe we can close this issue
- Sprint changed from Sprint 77 to Sprint 78
- Sprint changed from Sprint 78 to Sprint 79
- Sprint changed from Sprint 79 to Sprint 80
- Sprint changed from Sprint 80 to Sprint 81
- Sprint changed from Sprint 81 to Sprint 82
- Status changed from ASSIGNED to CLOSED - CURRENTRELEASE
Also available in: Atom
PDF
.