Stack in git repo

[GeirMydland]

As the subject says could we have the functionality to point my stack root to some git url maybe even with ref branch? Any new stack would trigger a commit to branch/repo

[GeirMydland]

On the other hand you could also just clone a remote repo to the local my stack and just have some kind of git add . and commit to remote.

[BadCo-NZ]

I'm also keen on a stack git back end.

[ankushg]

Also interested in this!

Would love some sort of bidirectional sync so changes in git would get pulled (via polling or maybe even a webhook), and changes from dockge would get pushed :)

[kasek61]

+1 to this as well, being able to house my compose files in something like gitea and deploy a stack that way is one of the major portainer features I use.

[snapshotleisure]

Also support this

[almereyda]

For supporting push-based, PaaS-style "GitOps" with Compose files, there is antoniomika/pcompose, from which bits of logic could be ported or taken inspiration from.

Pull-based syncing involves a lot of repository handling, from what I can tell from experiences with ArgoCD, esp. around authentication and secrets management.

[nightly-brew]

Just found this discussion, and I feel it's so similar to something I have in mind, that another request would be unnecessary.

On my end, I would love to have the ability to

• clone a git repo
• pull updates for a previously configured git repo

For the clone action, one could theoretically specify the repo url and provide credentials in some way (if needed), which would be then archived for later use.

For the pull action, the credentials could be reused.
If between pulls one was to change some stack settings, thus changing the local repo, there could be a dockge setting/variable specifying how to react on next pull:

• ask the user
• discard changes and pull
• sync both ways

I, for one, wouldn't want to have changes pushed to git, so something like this would allow the behaviour to be pretty customizable.
Maybe a suitable default would be "ask the user".

For supporting push-based, PaaS-style "GitOps" with Compose files, there is antoniomika/pcompose, from which bits of logic could be ported or taken inspiration from.

Pull-based syncing involves a lot of repository handling, from what I can tell from experiences with ArgoCD, esp. around authentication and secrets management.

What if the standard git binary was used? Dockge already manages stacks by invoking docker-compose, from what I can tell.

[ebaldebo]

Probably not quite what you're looking for but I missed the GitOps functionality when switching from Portainer. I have no compose files locally, they're all in git. Basically polling the repo and updating my stacks if there are change is all I need.

Wrote a simple container that I run together with the Dockge one to handle this. Note that the functionality is very limited but it does enough for me to completely replace Portainer with Dockge. It will ignore your local changes though and replace them if there are changes in the git repo.

ebaldebo/dockge-gitops

[nightly-brew]

Good idea, thanks for sharing!

Still, this would work only on a single host.
Would be good to have this functionality working on multiple hosts, if agents are defined and connected.

For example, my setup consists of 3 vms, each with its set of containers.
Some of them bind mount config files and other resources, which are tracked in the same repo that contains the compose files, as in

Thinking about it now, maybe git-added stacks should have a "scope".
It could be possible to define which hosts "receive" a particular stacks repo, but I think this one is going more towards the direction of "host groups" and should get a separated discussion maybe?

What do you think?

[ebaldebo]

Got a few other things in my backlog(using go-git instead of adding git to the container etc), but can look into this and see if I can get something working.

Like you mentioned though I also feel like it will diverge a bit from its original purpose. Wish my typescript/js knowledge was better so I could make PRs towards the main repo instead.

[knuurr]

It would be really cool.

Maybe instead of handling entire git repo (which would be ideal, especially if I could point to individual paths on that repo) let's start with simple wget from fixed endpoint?

That is: for given stack, dockge pulls every n minuts/hours/whatever from particular endpoint. It could check updates based on checksuming what's locally in stack vs what's received (I think compute power for this wouldn's be too much, but not sure) if there's difference, replace local file (if not read only) and redeploy.

I know it doesn't take into consideraiton rollbacks, newer commits etc. but sounds really simple in implementation. And if something you can always roll back on branch itself.

[zoop-btc]

I also would love to see some kind of gitops functionality. This would be a killer feature.