🎉 restart core containers if they fail automatically

[jrhizor]

see https://docs.docker.com/compose/compose-file/compose-file-v3/#restart for docs on restart

This adds restarts for all long-running containers. I allowed unless-stopped instead of always so we can still manually control services.

We've seen a couple of issues on Slack where users were confused because some container (like temporal or the server) died and never restarted. This should fix that problem.

Manual Testing
I tested this by running docker-compose up in one window, and in the other running this sequence of commands:

→ docker exec -it airbyte-server /bin/bash
root@9365322a100e:/app# apt-get install ps
...
root@9365322a100e:/app# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  7.2  8.1 3392784 250900 ?      Ssl  18:38   0:16 /usr/local/open
root        63  0.0  0.1   5624  3576 pts/0    Ss   18:41   0:00 /bin/bash
root       391  0.0  0.0   9396  2988 pts/0    R+   18:42   0:00 ps aux
root@9365322a100e:/app# kill 1
root@9365322a100e:/app# %

which killed the server. Then I could see it restarted successfully in the docker-compose logs/UI interactions.

[michel-tricot]

cool!

[marcosmarxm]

@jrhizor just curious, This won't resolve the problem when the scheduler cannot connect to temporal because temporal starts after the scheduler. Can we use the option depends_on: airbyte-temporal to impose starting the scheduler only after the airbyte-temporal is ready?

[marcosmarxm]

awesome!

[jrhizor]

@marcosmarxm

We had depends_on at some point but removed it because it was misleading.

According to https://docs.docker.com/compose/compose-file/compose-file-v3/#depends_on, depends_on doesn't actually wait for the dependency to become ready; it only waits until it starts, which isn't enough to be useful on first launch in 99% of cases.

Since we have overhead for starting that isn't related to the dependency, starting that process gets us a slight jump on overall startup latency.