Document how to create recipes based on your own image and compose file #435

New Issue

2023-03-22T13:01:33Z

moritz commented

2023-03-22 13:01:33 +00:00

I want to start a general discussion about maintaining our own docker images.
As docker wants open source projects pay for hosting their images ( https://blog.alexellis.io/docker-is-deleting-open-source-images/ ) a consequence would be to use the gitea image registry for all our images.
If we host our images anyway we could also maintain our own Dockerfiles.
The docs mention that a recipe can also be created by writing your own image and compose file from scratch, but there is now explanation how to do it.

A Dockerfile could still build up on the upstream image if available and we should also try to bring our patches upstream if possible.
The advantage is that it is easier to do some modification, as per docker-compose.
We could also fix some urgent security issues and update outdated packages.
The disadvantage is that it might come with more maintenance and some upstream changes might break it.
But this is similar with docker-compose files with custom entrypoints or other extensive modifications.

What do you think about this topic?

I want to start a general discussion about maintaining our own docker images. As docker wants open source projects pay for hosting their images ( https://blog.alexellis.io/docker-is-deleting-open-source-images/ ) a consequence would be to use the gitea image registry for all our images. If we host our images anyway we could also maintain our own Dockerfiles. The [docs](https://docs.coopcloud.tech/maintainers/tutorial/) mention that a recipe can also be created by writing your own image and compose file from scratch, but there is now explanation how to do it. A Dockerfile could still build up on the upstream image if available and we should also try to bring our patches upstream if possible. The advantage is that it is easier to do some modification, as per docker-compose. We could also fix some urgent security issues and update outdated packages. The disadvantage is that it might come with more maintenance and some upstream changes might break it. But this is similar with docker-compose files with custom entrypoints or other extensive modifications. What do you think about this topic?

decentral1se added the question label 2023-03-24 08:25:34 +00:00

decentral1se commented

2023-03-24 08:35:26 +00:00

@moritz Thanks for opening up this discussion.

One of the core ideas of this project was to work with upstream. So I'd rather discuss plans about how to get the gitea/nextcloud/mediawiki etc. developers to support publishing images to a hub.coopcloud.tech alongside their other CI/CD workflows.

I think we need to double-down on our organising of maintainers taking responsibility for specific recipes so that these people can start to build better bridges with the upstream developers. That way, security stuff can be fixed faster without having to work around them.

The entrypoint hacks remain hacks for me, temporary work-arounds and not a stepping stone towards our own image publishing infrastructure that doesn't include upstream in the plans. I don't think it will be sustainable and we might reproduce the failure points of Cloudron.

We could organise between the cracks as we usually do and implement a custom Github Action and petition projects to support this new registry. We could publish a blog post about how corporate registries are doomed and please join the revolution. It wouldn't be fast but I think it would have a greater chance of expanding the co-operation.

We already have a general registry packaged btw https://git.coopcloud.tech/coop-cloud/distribution. The reason I favour this over Gitea is because it might be good to have a separation between what publishers want to do and what recipe maintainers want to do.

This is all pretty idealistic ofc but we are several years into this project with 30k+ of public funding behind us and that tells me we should continue to demand the impossible 😃

@moritz Thanks for opening up this discussion. One of the core ideas of this project was to work with upstream. So I'd rather discuss plans about how to get the gitea/nextcloud/mediawiki etc. developers to support publishing images to a `hub.coopcloud.tech` alongside their other CI/CD workflows. I think we need to double-down on our organising of maintainers taking responsibility for specific recipes so that these people can start to build better bridges with the upstream developers. That way, security stuff can be fixed faster without having to work around them. The entrypoint hacks remain hacks for me, temporary work-arounds and not a stepping stone towards our own image publishing infrastructure that doesn't include upstream in the plans. I don't think it will be sustainable and we might reproduce the failure points of Cloudron. We could organise between the cracks as we usually do and implement a custom Github Action and petition projects to support this new registry. We could publish a blog post about how corporate registries are doomed and please join the revolution. It wouldn't be fast but I think it would have a greater chance of expanding the co-operation. We already have a general registry packaged btw https://git.coopcloud.tech/coop-cloud/distribution. The reason I favour this over Gitea is because it might be good to have a separation between what publishers want to do and what recipe maintainers want to do. This is all pretty idealistic ofc but we are several years into this project with 30k+ of public funding behind us and that tells me we should continue to demand the impossible 😃

👍 1

decentral1se commented

2023-03-25 10:38:28 +00:00

Lol https://www.docker.com/blog/no-longer-sunsetting-the-free-team-plan/

But let's still try to out-organise them.

Lol https://www.docker.com/blog/no-longer-sunsetting-the-free-team-plan/ But let's still try to out-organise them.

3wordchant commented

2024-03-30 19:30:28 +00:00

@moritz would you be open to this issue being re-titled to focus on this part?

The docs mention that a recipe can also be created by writing your own image and compose file from scratch, but there is now explanation how to do it.

I fully support @decentral1se's point:

The entrypoint hacks remain hacks for me, temporary work-arounds and not a stepping stone towards our own image publishing infrastructure that doesn't include upstream in the plans. I don't think it will be sustainable and we might reproduce the failure points of Cloudron.

So I would really like to avoid moving towards custom Co-op Cloud images for as long as humanly possible.

But I definitely think improving documentation for using Gitea to build and publish an image, and making a Co-op Cloud recipe for it (even potentially within the same recipe, like backup-bot-two) would be great.

@moritz would you be open to this issue being re-titled to focus on this part? > The docs mention that a recipe can also be created by writing your own image and compose file from scratch, but there is now explanation how to do it. I fully support @decentral1se's point: > The entrypoint hacks remain hacks for me, temporary work-arounds and not a stepping stone towards our own image publishing infrastructure that doesn't include upstream in the plans. I don't think it will be sustainable and we might reproduce the failure points of Cloudron. So I would really like to avoid moving towards custom Co-op Cloud images for as long as humanly possible. But I definitely think improving documentation for using Gitea to build and publish an image, and making a Co-op Cloud recipe for it (even potentially within the same recipe, like `backup-bot-two`) would be great.

👍 1

moritz changed title from ~~Upstream Images vs Maintining our own Dockerfiles~~ to Document how to create recipes based on your own image and compose file

2024-04-01 08:32:09 +00:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#435