docker-library / docs

Documentation for Docker Official Images in docker-library
https://github.com/docker-library/official-images
MIT License
5.08k stars 2.2k forks source link

Plone: Add info about Plone 6 Docker images #2479

Open avoinea opened 3 months ago

tianon commented 3 months ago

I have to admit I'm a little confused -- does this mean the https://hub.docker.com/_/plone image is effectively deprecated and won't be getting 6.x+? :sweat_smile:

(If so, we should make this change a little differently, especially with a deprecated.md so the note shows up at the top of the image description.)

stevepiercy commented 3 months ago

Apparently my suggestion to add a section did not get saved in my review. I'll try again, now that I have permission.

avoinea commented 3 months ago

I have to admit I'm a little confused -- does this mean the https://hub.docker.com/_/plone image is effectively deprecated and won't be getting 6.x+? 😅

@tianon As Plone 6 is not a monolith app anymore and it comes with a decoupled React front-end we don't have a consensus in the Plone Community on what we should do with this image, yet :see_no_evil:

I can see there are other apps that tries to put everything in a all-in-one-docker-image like https://github.com/nextcloud/all-in-one?tab=readme-ov-file#nextcloud-all-in-one but I'm not sure what is the best way to handle this situation for the Official Docker Images. Maybe you can point out to some good examples / practices.

(If so, we should make this change a little differently, especially with a deprecated.md so the note shows up at the top of the image description.)

Meanwhile, until we have a decision, I added the deprecated.md file pointing to the officially supported Plone 6 images.

stevepiercy commented 3 months ago

FYI, I'll be back from vacation tonight, and I'll look into how these docs are auto-generated from their counterparts in the Plone GitHub repos, and work on PRs there. From my quick glance of Docker's docs, it looks like the PRs will go under Plone first, then will get generated in Docker repos.

tianon commented 3 months ago

Ah, interesting! I would definitely not recommend doing something like an all-in-one, because I have yet to see a truly reliable (and still minimal) "process supervisor" to help manage multiple processes in one container. Two images is perfectly reasonable, especially if the documentation describes how to run them (something like plone:6-frontend + plone:6-backend is what I'd personally suggest, but plone:frontend-6 and plone:backend-6 would be pretty reasonable too, however the latter to me personally suggests that the versioning between frontend and backend might not stay in sync over time, where the former makes it clear that each are individual components from the "6" release).

stevepiercy commented 3 months ago

Closes https://github.com/plone/plone.docker/issues/179.

stevepiercy commented 3 months ago

I don't have merge permission. Who does?

After this PR is merged, then I can start work on promoting plone-backend and plone-frontend as official Docker images. I'll merge the docs files from this PR with those from the other repos, then open a pull request for each image.

When Plone 5.x exits security support, then I think we should remove just plone from the official images. See https://hub.docker.com/search?q=plone&image_filter=official.

stevepiercy commented 2 months ago

Ready for another run of workflows.

stevepiercy commented 2 months ago

I missed a couple of details, and I think I finally got them all this time. Ready for one more run.

I didn't realize I could run the CI check locally with ./update.sh plone followed by ./markdownfmt.sh -d plone. Sorry for the noise.

whalelines commented 2 months ago

Just to make sure we all have the same understanding, the intention is to deprecate the plone DOI entirely and only move forward with plone/plone-backend and plone/plone-frontend, i.e., to not provide two variants in the plone DOI, plone:6-frontend and plone:6-backend, as @tianon suggested?

stevepiercy commented 2 months ago

@whalelines, I don't understand what you mean by two variants. @tianon said:

Two images is perfectly reasonable


Are the docs in this PR technically approved? I've been waiting for that piece before I start. If approved, then I can start today on the frontend and backend images' docs in separate PRs. Please let me know. Thank you!

whalelines commented 2 months ago

There are currently three repositories serving Plone container images.

  1. plone: the Docker Official Image repository for Plone that has images for versions 4 and 5
  2. plone/plone-backend: the Docker-Sponsored Open Source repository for the backend image for Plone 6
  3. plone/plone-frontend: the Docker-Sponsored Open Source repository for the front image for Plone 6

Currently, this PR for updating the documentation for the plone DOI effectively deprecates the entire plone DOI repository, suggesting people get the latest Plone container images from the two Plone DSOS repositories.

What @tianon suggested was that the plone DOI repository can provide both the backend and frontend images for Plone 6. In contrast to how the Plone DSOS repositories are set up, the frontend and backend variants could both be available in the single plone DOI repository by using separate tags for each variant, e.g., plone:6-backend and plone:6-frontend. Lots of DOI repositories provide multiple image variants, e.g., leveraging different base images, language runtimes, or use cases.

I just want to make sure your intention is to deprecate the plone DOI entirely as this PR suggests.

stevepiercy commented 2 months ago

@whalelines thanks for the explanation and taking care. Can you point me to docs about how to do this, and an example project in the DOI repo? I'm not sure exactly what to search for.

@mauritsvanrees @avoinea I'm available to chat in Discord to discuss how to move forward, and come up with a plan. This turned into something bigger than mere changes to docs that I expected.

whalelines commented 2 months ago

Currently the plone bashbrew file has a single stanza. You would just add a distinct stanza for each variant, e.g., aerospike, arangodb, backdrop, etc.