Add restart:always to the docker-compose

[Razikus]

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

[dfunckt]

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?

[Razikus]

https://docs.docker.com/config/containers/start-containers-automatically/

[maggie44]

+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.

[maggie44]

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

[florisvdk]

@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.

[dfunckt]

@florisvdk I’ve already replied why we won’t default to automatically starting the containers in a comment to the PR: #84 (comment) 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.

[maggie44]

In addition to a more production ready restart policy, the issue of the production_mode flag has been raised too: #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

[p0thi]

@Maggie0002 what do you mean by "flatten compose file with script"? Can you provide a script for that?
Thanks!

[maggie44]

@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

[bartversluijs]

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.

[ab77]

#84 (comment)