Uma boa solução para esse problema é ter o daemon do Docker (rodando na instância system do systemd) usando a ativação do soquete.
Dessa forma, quando você iniciar um comando docker (digamos de uma unidade systemd usuário ), ele terá um soquete para se conectar, mas bloqueará até que o daemon do Docker esteja realmente pronto para servir isso.
A ideia básica de ativação de soquete para elidir dependências explícitas é descrita em este artigo no blog do systemd , que fala sobre quatro serviços que tradicionalmente têm sido manipulados por meio de dependências explícitas, mas com a ativação de soquete não precisam mais que eles sejam configurados. Aqui está um trecho (é longo, mas realmente faz o ponto):
Socket activation makes it possible to start all four services completely simultaneously, without any kind of ordering. Since the creation of the listening sockets is moved outside of the daemons themselves we can start them all at the same time, and they are able to connect to each other's sockets right-away. I.e. in a single step the
/dev/logand/run/dbus/system_bus_socketsockets are created, and in the next step all four services are spawned simultaneously. When D-Bus then wants to log to syslog, it just writes its messages to/dev/log. As long as the socket buffer does not run full it can go on immediately with what else it wants to do for initialization. As soon as the syslog service catches up it will process the queued messages. And if the socket buffer runs full then the client logging will temporarily block until the socket is writable again, and continue the moment it can write its log messages. That means the scheduling of our services is entirely done by the kernel: from the userspace perspective all services are run at the same time, and when one service cannot keep up the others needing it will temporarily block on their request but go on as soon as these requests are dispatched. All of this is completely automatic and invisible to userspace. Socket activation hence allows us to drastically parallelize start-up, enabling simultaneous start-up of services which previously were thought to strictly require serialization. Most Linux services use sockets as communication channel. Socket activation allows starting of clients and servers of these channels at the same time.
O daemon do Docker suporta a ativação de sockets desde , por isso é provável que a versão que você está usando já suporte .
Verifique se sua distribuição envia uma unidade docker.socket . Nesse caso, tudo o que você precisa fazer é ativá-la.
Se o daemon do Docker oferecer suporte à ativação de soquete, mas sua distribuição não incluir uma unidade docker.socket , dê uma olhada em este tutorial para instruções sobre como configurá-lo.
Mais uma alternativa a considerar é mudar do Docker para o podman .
O Podman tenta ser um substituto compatível com o Docker (assim, você pode usar as mesmas linhas de comando, simplesmente substituindo docker por podman .)
A principal diferença entre eles é que o podman não precisa de um daemon, então você não precisa esperar que um esteja pronto antes de iniciar um contêiner. O Podman está disponível como um pacote nas versões mais recentes das distribuições do Linux. Isso e o fato de que você pode usá-lo da mesma maneira que usa docker hoje deve facilitar a introdução.