Git repo and stacks

[cvalcke958]

I have all my compose files organized in one repo. I was able to get a stack going with Komodo pulling everything in /etc/k../stacks/mystack, all good. I'm confused as building another stack will pull the full repo again in /etc/k../stacks/my2stack.
Is recommended practice instead to pull the repo once (with cron updates) and use the "file on server" option to locate the compose files?

[mbecker20]

Stacks in repo mode will clone the entire repo for each Stack, and is designed more with single stack repos in mind, not monorepos.
Usually repos are only needed for stacks if they require config files as well, otherwise many stacks are better off UI Defined, and synced to git in a ResourceSync. Also with single Stack repos, you can trigger a deploy of the stack easily on every commit via adding the git webhook.

But you can also use the Repo resource to clone the repo, and make a Procedure which first Pull Repo, then Batch Deploy Stack If Changed all stacks on the repo (target all Stacks using *). Then you point a git webhook to this Procedure to run on every commit. It will only redeploy stacks which compose files have changed since the last deploy. Note that it won't redeploy if config file changes, only the compose file.

[lnlyssg]

I'm also struggling to get my head round this.... I currently have one GitHub repo with a similar setup as the OP and I've managed to get all my stacks into Komodo fine pointing to this repo. I now want to try and get more automation in place but I'm struggling. I defined a repo in Komodo which has worked OK but how can I re-point/update each stack to use the "local" repo and then use the Procedure you outline? The repo is just on one server so when I try and update or set-up a new stack on another server it can't see the files. Am I missing a step?

[TerrifiedBug]

I'm also experiencing this problem when migrating from Portainer. My GitHub homelab repo is a monorepo setup with 30-40 stacks, which means Komodo would clone my entire homelab repo 30-40 times, creating significant redundancy and resource waste.

I'm wondering if there could be another option when doing git stacks where you can reference an already cloned repo that you setup centrally like the git accounts etc and you reference the sub folder as normal but it's working out of the one cloned repo instead.

For now, I think I'm going to setup gitea internally and convert my monorepo into individual repos and create a job to push/mirror gitea changes into my GitHub monorepo.

[ChrispyBacon-dev]

sorry to necro an old post. But I'm in the process of migrating over from portainer and I don't want to reinvent the wheel. I have as well everything in one repository but what is the best practice? Any examples available? The documentation is quite simple.

[lnlyssg]

Have a look at https://blog.foxxmd.dev/posts/migrating-to-komodo/

[porochickenrye]

That's a great article but I think most newcomers are after is clear IaC monorepo setup and Gitops examples. It would be great if someone like @FoxxMD could write one.

[FoxxMD]

@porochickenrye I've considered doing that to accompany the article but the issue is that Komodo is a moderately state-ful application. Even if I setup a git repo with sample stacks, sync resource, and included a copy of a demo db/mongo file anyone trying to use it who would want the full features of komodo (writing back to stack from ui) would still need to:

• reconfigure the provided git credentials in komodo (can't use mine)
• fork my repo and reconfigure each stack to point to the new repo
• reconfigure the provided demo Server setup in the ui, or be stuck using periphery container (should be using systemd)

so...they'd be going through the majority of the steps outlined in the article anyways or skipping crucial steps for learning how komodo works. It wouldn't be terribly helpful.

If someone wants to see komodo fully in action + gitops tied to it they'd be better off checking out the komodo demo (https://demo.komo.do user/pw komodo/komodo) and gitea instance https://git.komo.do/explore/repos