Command detach

[Szubie]

Currently, if executing a command that does not exit bravetools will wait indefinitely for the completion of the command. The usual ways of running a shell command in the background don't seem to work when using bravetools. For example, using sh -c ... & does not detach, nor do various uses of nohup ... &. If the program does not provide a flag to run as a daemon process it cannot be used from bravetools without freezing the build/deploy.

Instances of programs that don't exit may include web-servers etc. that are designed to be run in the background. This means that something like starting a web-server using a post-deploy command would not work if it has no --daemon flag, like Flask.

Adding a new field to the Bravefile run command, "detach" would enable bravetools to handle such cases and any other where running programs in the background is desired. For certain scenarios this could greatly simplify deployment and make it feel less like you are fighting bravetools to get it to do something that would have been easy with a shell script.

Here's what the new field would like like:

run:
  - command: flask
    args:
      - run
    detach: true

[adrozdovbering]

Hi Ben. I can see the value of this feature. However the use case with starting a web server from Bravetools, I think, is not exactly where this should be used. Bravetools is a deployment tool. Starting processes (web servers, etc) inside containers should be handled by tools as supervisor. In other words, services should be starting as container starts. Otherwise we can get a situation were after container re-start service won't start. This is a useful feature, but we need to find a use case for it (unless I am missing something here)

[idroz]

Hi Ben. I can see the value of this feature. However the use case with starting a web server from Bravetools, I think, is not exactly where this should be used. Bravetools is a deployment tool. Starting processes (web servers, etc) inside containers should be handled by tools as supervisor. In other words, services should be starting as container starts. Otherwise we can get a situation were after container re-start service won't start. This is a useful feature, but we need to find a use case for it (unless I am missing something here)

We had a few in-depth discussions around this. Important to note that this is not a replacement for supervisor. The rationale to include it is:

1. Creation of unit tests for service-like apps without the overkill of writing a fully-fledged supervisor config
2. Further expose existing LXD exec API to bravetools

In the near (hopefully) future, we are thinking of daemnising services in a declarative way by using something like https://github.com/ochinchina/supervisord un the hood, but that is a larger project.

[adrozdovbering]

This sounds OK. I am still not entirely convinced. There are similar discussions in Docker community. Just one: https://forums.docker.com/t/how-to-start-a-process-within-a-container-via-dockerfile/108117

1. Creation of unit tests for service-like apps without the overkill of writing a fully-fledged supervisor config

Shouldn't processes be managed in conventional Linux way and be a part of internal container behaviour? Supervisor is not the only tool to manage processes.

2. Further expose existing LXD exec API to bravetools

This where it might be useful. However, what particular use cases are?

The most important that processes should be able to start/restart automatically after container restarted or application crashed. It should be a good reason to control them from Bravefile.