open-balena
open-balena copied to clipboard
balena-io
Add restart:always to the docker-compose
Hi i would like to make a little feature request here - add the restart:always to the docker-compose specification
Today i restarted my server, and after that i forgot to start openbalena again
Little thing but will make a life easier
That's something that needs to be handled by your init system -- ie. start the openBalena containers at server startup. Do I miss your point?
+1. Docker handles it's own starting and stopping, it is its own init system, another shouldn't be required. Agree that the init system makes sense for the included OpenBalena entry point script (although would suggest not using the script at all would be better for starting in production otherwise we are layering init systems), but when flattening docker-compose.yml a restart-unless-stopped would make sense. These can be added manually, but I would suggest they are the default otherwise future updates could mean the new compose flatten overwrites changes, or the compose files end up out of sync.
Update over on the Balena forums that has helped me resolve this: https://forums.balena.io/t/automatically-restarting-open-balena-after-reboot/205006/15
@dfunckt Why would you implement a new init system when docker has one built-in. For those that do not want to use the docker init an flag could be added to not add the restart-unless-stopped.
The current way of having to make your own init script is just dumb.
@florisvdk I’ve already replied why we won’t default to automatically starting the containers in a comment to the PR: https://github.com/balena-io/open-balena/pull/84#issuecomment-672796784 and offered a way to achieve that for those that need it. Pasting here for posterity:
to have Docker start the containers at startup (and having the init system invoke it is not an option you like) you can still add the restart flag by extending the service definitions in your project's docker-compose file in config/docker-compose.yml.
Also, please keep your tone down.
In addition to a more production ready restart policy, the issue of the production_mode flag has been raised too: https://github.com/balena-io/open-balena/issues/111
My docker-compose.override.ymlnow looks like this (see https://forums.balena.io/t/automatically-restarting-open-balena-after-reboot/205006/15 for more info on the override approach):
services:
api:
restart: unless-stopped
environment:
PRODUCTION_MODE: "true"
cert-provider:
restart: unless-stopped
db:
restart: unless-stopped
haproxy:
restart: unless-stopped
redis:
restart: unless-stopped
registry:
restart: unless-stopped
s3:
restart: unless-stopped
vpn:
restart: unless-stopped
environment:
PRODUCTION_MODE: "true"
How about including a file like this in the repository? Could be a docker-compose.prod.yml file, and then for production use could be started with docker-compose -f docker-compose.yml -f docker-compose.prod.yml up as per the official Docker documentation: https://docs.docker.com/compose/extends/#multiple-compose-files
By default, starting would then be in development mode, as it is now, so wouldn't be a breaking change for users. Starting by default in development mode (i.e. no restart) is fairly expected. But would provide a clear production workflow. The documentation could then be updated accordingly.
Assuming wanting to avoid a larger overhaul of the workflow, production mode would be:
Flatten compose file with script -> start using docker-compose -f docker-compose.yml -f docker-compose.prod.yml up
Updates would be:
Pull latest updates -> flatten compose file with script -> docker-compose build -> docker-compose -f docker-compose.yml -f docker-compose.prod.yml up
docker-compose.prod.yml could then be maintained in this repo, so additional containers in the future, or production mode variables will be synced on the git pull.
I wouldn't advise anyone to run in production mode by executing a script that executes Docker-Compose, through a systemd or any other init system, so think this would be a solid alternative rather than additional workflow. For development mode, as before, it can remain the same using the compose script.
Would probably add docker-compose.prod.yml into ./compose alongside the other compose files and to avoid confusion with there being a docker-compose prod in the root. Command would then be: docker-compose -f docker-compose.yml -f ./compose/docker-compose.prod.yml up
@maggie0002 what do you mean by "flatten compose file with script"? Can you provide a script for that? Thanks!
@maggie0002 what do you mean by "flatten compose file with script"? Can you provide a script for that? Thanks!
- To create a single, flat, docker-compose.yml file, run:
./scripts/compose config > docker-compose.yml
As this isn't going to be implemented by default, but there's a workaround for it, shouldn't this issue be closed? Same goes for PR #84.
