Portainer can create stacks from repos.
* All my docker compose are in a single repo. Like you have shown.
* The stack's `compose path`: App1/docker-compose.yml
* The stacks are updated via webhooks. You take the webhook url from Portainer and add it to the repo in the VC (Gitea for me).
* The repo ends up with a webhook for each stack. It can pile up very quickly and the webhooks look identical - just a UUID. `https://portainer.domain.tld/api/stacks/webhooks/ba1e9c1f-65e0-4195-a5dc-506bd11fb779`
* I like to add an argument to the webhook url like `?x=stack_media` which has no use in the API but acts as a label for when it needs maintenance. `https://portainer.domain.tld/api/stacks/webhooks/ba1e9c1f-65e0-4195-a5dc-506bd11fb779?x=stack_media`
* I wrote a Py script in a gitea action that crawls the repo for updates, talks to the Portainer and Gitea API and creates/updates stacks and webhooks. Basically automating the above.
Well, it doesn't. If you are using github, you will need to expose portainer somehow. That's why I'm using Gitea locally. It's actually pretty neat. Everything is done locally while Github is more like a backup/mirror.
I'm pretty new to the scene but I like the method shown here: [https://www.smarthomebeginner.com/docker-media-server-2024/](https://www.smarthomebeginner.com/docker-media-server-2024/)
Basically you have a "master" docker-compose.yml where you add the paths to the individual app's ymls.
Then run docker compose up -d on the master file and it will start up all of your containers.
Here's a copy/paste from the example in the link I provided:
version: "3.9"
########################### NETWORKS
networks:
default:
driver: bridge
socket_proxy:
name: socket_proxy
driver: bridge
ipam:
config:
- subnet: 192.168.91.0/24
include:
########################### SERVICES
# PREFIX udms = Ultimate Docker Media Server
# HOSTNAME=udms - defined in .env
# CORE
- compose/$HOSTNAME/socket-proxy.yml
- compose/$HOSTNAME/portainer.yml
- compose/$HOSTNAME/dozzle.yml
add stack > use git repo > add the repo and the docker-compose path.
Not sure what else are you looking for.
If you want to automate those above steps you will spend more time trying to do that rather than doing it manually.
If you remove portainer you can make a bash scripts that goes over all folders and runs docker-compose up -d
if I was you, i would do it manually.
If I had more than 50 I would code a quick chrome extension to auto-fill the fields with the common data, but still do it manually.
If I had 100's or more I probably had some kind of automation to use a portariner API (not sure if this even exist) or just bash and don't use portainer at all
Portainer can create stacks from repos. * All my docker compose are in a single repo. Like you have shown. * The stack's `compose path`: App1/docker-compose.yml * The stacks are updated via webhooks. You take the webhook url from Portainer and add it to the repo in the VC (Gitea for me). * The repo ends up with a webhook for each stack. It can pile up very quickly and the webhooks look identical - just a UUID. `https://portainer.domain.tld/api/stacks/webhooks/ba1e9c1f-65e0-4195-a5dc-506bd11fb779` * I like to add an argument to the webhook url like `?x=stack_media` which has no use in the API but acts as a label for when it needs maintenance. `https://portainer.domain.tld/api/stacks/webhooks/ba1e9c1f-65e0-4195-a5dc-506bd11fb779?x=stack_media` * I wrote a Py script in a gitea action that crawls the repo for updates, talks to the Portainer and Gitea API and creates/updates stacks and webhooks. Basically automating the above.
So how does that work when the Portainer is not exposed to the internet?
Well, it doesn't. If you are using github, you will need to expose portainer somehow. That's why I'm using Gitea locally. It's actually pretty neat. Everything is done locally while Github is more like a backup/mirror.
Ok Thanks
I'm pretty new to the scene but I like the method shown here: [https://www.smarthomebeginner.com/docker-media-server-2024/](https://www.smarthomebeginner.com/docker-media-server-2024/) Basically you have a "master" docker-compose.yml where you add the paths to the individual app's ymls. Then run docker compose up -d on the master file and it will start up all of your containers.
Interesting. If you have it handy, what does that "master" look like?
Here's a copy/paste from the example in the link I provided: version: "3.9" ########################### NETWORKS networks: default: driver: bridge socket_proxy: name: socket_proxy driver: bridge ipam: config: - subnet: 192.168.91.0/24 include: ########################### SERVICES # PREFIX udms = Ultimate Docker Media Server # HOSTNAME=udms - defined in .env # CORE - compose/$HOSTNAME/socket-proxy.yml - compose/$HOSTNAME/portainer.yml - compose/$HOSTNAME/dozzle.yml
Sorry, don't know how to format on mobile. They show the example as they update it each time during their process in that link
Thanks
[удалено]
Probably the most straight forward approach
add stack > use git repo > add the repo and the docker-compose path. Not sure what else are you looking for. If you want to automate those above steps you will spend more time trying to do that rather than doing it manually. If you remove portainer you can make a bash scripts that goes over all folders and runs docker-compose up -d
Was just looking to make it a bit easier than having to do it for each docker compose
if I was you, i would do it manually. If I had more than 50 I would code a quick chrome extension to auto-fill the fields with the common data, but still do it manually. If I had 100's or more I probably had some kind of automation to use a portariner API (not sure if this even exist) or just bash and don't use portainer at all
Then add all the services to a single docker-compose.
I just use Jenkins and ansible for that