You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My main use-case for Pico is to run docker-compose up -d for config changes. However, if a container dies for some reason, bringing it back is done in two ways:
manually ssh into the machine, cd into its target directory and manually run compose (ew!) - this is really annoying/insecure when the container depends on a bunch of secrets from Vault - you have to copy those into the command line or .env file (and risk forgetting to remove it after)
push an empty commit to the config repo to trigger pico - the slightly safer option, but clutters your history and is a bit of a hack
One of the goals of the web UI (#10) is to provide a way to do this with a click instead of an ssh.
One of the goals of using an event bus (#27) is to allow multiple trigger sources for command execution.
It would make sense to introduce another provider (I guess we're calling event sources "providers" now?) that's based on periodic automated events (cron-tab style) alongside the Git events. So a target will react to Git pushes, but also run its command every now and then anyway.
At first, this felt like feature creep. I didn't really want to move towards a kubeapplier style reconcillation system because that would be very Docker-specific (but maybe...). I gave it some thought and realised this could be a useful solution that applies outside of Docker use-cases (periodically run a container, or a webhook, or any process, all configured via Git instead of via crontab where it gets buried in machine-specific config)
The text was updated successfully, but these errors were encountered:
My main use-case for Pico is to run
docker-compose up -d
for config changes. However, if a container dies for some reason, bringing it back is done in two ways:One of the goals of the web UI (#10) is to provide a way to do this with a click instead of an ssh.
One of the goals of using an event bus (#27) is to allow multiple trigger sources for command execution.
It would make sense to introduce another provider (I guess we're calling event sources "providers" now?) that's based on periodic automated events (cron-tab style) alongside the Git events. So a target will react to Git pushes, but also run its command every now and then anyway.
At first, this felt like feature creep. I didn't really want to move towards a kubeapplier style reconcillation system because that would be very Docker-specific (but maybe...). I gave it some thought and realised this could be a useful solution that applies outside of Docker use-cases (periodically run a container, or a webhook, or any process, all configured via Git instead of via crontab where it gets buried in machine-specific config)
The text was updated successfully, but these errors were encountered: