Understanding git integration and volumes

[lordraiden]

I have my stack files (compose and env) in a private github repo.
Right now I have a script to sync the files with a local folder and I run the compose stack from those files.

I'm trying to integrate or at least use Komodo in the best way possible.

So in the Komodo container what is the purpose of this volumes?

    volumes:
      ## Core cache for repos for latest commit hash / contents 
      - ${dockerdir}/komodo:/repo-cache
      ## Store sync files on server
      - ${dockerdir}/docker-compose:/syncs

repo-cache: what kind of files will be stored here? is this a internal cache folder of komodo so I just have to map it to an empty folder?
syncs: what is the purpose? what kind of files are syncing?, from where? it is for this? https://komo.do/docs/sync-resources and https://komo.do/docs/procedures ?

periphery container

    volumes:
      ## manage repos in a docker volume, 
      ## or change it to an accessible host directory.
      - ${dockerdir}/docker-compose-git:/etc/komodo/repos
      ## manage stack files in a docker volume, 
      ## or change it to an accessible host directory.
      - ${dockerdir}/docker-compose:/etc/komodo/stacks
      ## Optionally mount a path to store compose files
       - /path/to/compose:/host/compose

/etc/komodo/repos: should I map this to a folder with a git clone of my github? can I integrate Komodo directly with github?

/etc/komodo/stacks: If I do the above do I need to use this one? I guess this would be to map the stack files without the need of being a git repo, right?

/host/compose: What is the purpose of this?

I don't plan to build images, I just have my compose and env files in github

[mbecker20]

Komodo Core

The repo-cache directory is attached to Core container because Core will also clone the repo for the latest commit hash, to provide information on it compared the the actual repo which is cloned on your server. This directory doesn't need to be persisted, in fact it doesn't need to be mounted to at all. But I make default mounted because if you have many repo, it will have to clone them all again when you re-create Komodo Core container on eg version upgrade. While if you mount the repo-cache, Core doesn't have to clone them all again as they are persisted, it can just pull. But nothing will break either, just a bit more efficient to use a persistent mounted cache.

The syncs directory is for Resource sync files. This is useful if you use "Files on Server" Resource Syncs, and avoid the overhead of having to put Sync files in repo. Its actually the same three options for Resource Syncs (commonly just called Syncs) - UI Defined, Files on Server, or Git Repo. But for Resource Sync, it is always Komodo Core handling Sync files and performing the Syncs. While for Stacks, it is Komodo Periphery agent (deployed on each connected Server) doing this. That is why the Stack directory is mounted to Komodo Periphery agent, while Sync directory is mounted to Komodo Core.

Komodo Periphery Agent

Its easier to understand first considering you are running Periphery outside of docker container (eg systemd deployment), so you don't also deal with the container file system separation, re #220.

There are two folders, one is .../stacks and the other is .../repos (where ... is your custom location). These are used by two distinct Komodo Resource types, Stack and Repo. You can read about all the Resource types here: https://komo.do/docs/resources. You may only need the Stack resource type if all you plan to do it deploy docker compose files, so the .../repos folder may go unused. All Stacks (including git repo mode Stacks) store their files in .../stacks.

The folder can be empty when first starting, and Komodo will clone git repos under the configured .../stacks directory, and then deploy the compose files from there (in the case of Stacks). The only reason they wouldn't be empty is if you prefer to use VsCode SSH and write compose files on your host manually. In this case you can use Stack in "Files on Server" mode, pointing to the folder.

By default, Komodo uses .../stacks/${name} as the Run Directory for the stack, ie it will cd ${run_directory} && docker compose -f ... up -d ....

Komodo Periphery agent (container)

If you must run in container, you need to mount these folders. The current documented compose has a problem with relative mounts working as described in #180, so I have fix to the compose files in the next release. You can find the updated compose files in the new branch for now, they will also work with current 1.16.12 release too: https://github.com/mbecker20/komodo/blob/1.17.0/compose/mongo.compose.yaml#L63

[lordraiden]

Thanks for the detailed response, maybe it would be interesting to add this to the documentation.
Anyway I have been testing Komodo and it's amanzing better than Portainer BE

Another question in the env file
The "KOMODO_JWT_SECRET" ask for a fix random key, but them there is an expiration for the key "KOMODO_JWT_TTL="1-day""
What is the correct aproach? leave it empty? put a random key?

## Used to generate jwt. Alt: KOMODO_JWT_SECRET_FILE
KOMODO_JWT_SECRET=""

## Enable login with username + password.
KOMODO_LOCAL_AUTH=true
## Disable new user signups.
KOMODO_DISABLE_USER_REGISTRATION=false
## All new logins are auto enabled
KOMODO_ENABLE_NEW_USERS=true
## Disable non-admins from creating new resources.
KOMODO_DISABLE_NON_ADMIN_CREATE=false
## Allows all users to have Read level access to all resources.
KOMODO_TRANSPARENT_MODE=false

## Time to live for jwt tokens.
## Options: 1-hr, 12-hr, 1-day, 3-day, 1-wk, 2-wk
KOMODO_JWT_TTL="1-day"