#4386 [RFE] "Official" docker container for pagure
Opened 3 months ago by jcpunk. Modified 3 months ago

It might help aid deployment/adoption of pagure if there was an "official" container (perhaps under the fedora or fedoraqa namespace?) that could be used to deploy pagure.

There are instructions on how to build your own container for testing, but having a 'this should probably just work' container could be very handy.


I'm not a pagure expert but I guess the main difficulty behind this is that pagure is composed of a couple of services:
https://pagure.io/pagure/blob/master/f/dev/docker-compose.yml

So pagure environment need to be orchestrated to be deployed and providing containers doesn't really simplify the deployment and the adoption due to this fact.

I guess a more simple way can be to package pagure at .rpm .deb etc... formats.

With container the problem stay entire while we need to orchestrate deployment and launch.

Packaging pagure by using .rpm (by example) can orchestrate deployment and launching.

ThoughtS?

I've been looking at the idea of making an "official" container for Pagure based on Fedora for a while. There's just been a lot of other things going on too...

And with all the components that can be added for a pagure deployments, you have to think about all those cases ..
Like, do you need/rely on repospanner ? so you need that in your container lists, etc ..
And same even just for the "base" pagure container : it would need to embed all the possible plugins in case one need those ? Just thinking about the mqtt notification plugin, requiring some packages then to be installed , etc ..

If we go on "1 services 1 container", the proper way would be to build a lot of different ones: api, worker, ev, webhook, docs, logcom, sshd at least.

@arrfab To be honest, I would probably not include repoSpanner because it is not even available in the Fedora repositories and requires a modified libgit2 (since the changes aren't upstreamed yet).

But yes, there's some degree of complexity here.

@jlanda The "one service per container" thing doesn't necessarily require multiple container images, just the ability to pass an argument to it to instantiate it as a different aspect of the system.

Yeah, almost alll off them could be the same container with differrent running entrypoint/command

Login to comment on this ticket.

Metadata