Início / server / Perguntas / 1074981
Accepted
Jonas
Asked: 2021-08-19 13:07:01 +0800 CST

Como iniciar o etcd no docker a partir do systemd?

  • 772

Eu quero iniciar o etcd (nó único) no docker do systemd, mas algo parece dar errado - ele é encerrado cerca de 30 segundos após o início.

Parece que o serviço inicia no status "ativando" , mas é encerrado após cerca de 30 segundos sem atingir o status "ativo" . Talvez haja alguma sinalização ausente entre o contêiner do docker e o systemd?

Atualização (veja a parte inferior do post): o status do serviço systemd atinge failed (Result: timeout)- quando removo a Restart=on-failureinstrução.

Quando verifico o status do serviço etcd após a inicialização, recebo este resultado:

$ sudo systemctl status etcd● etcd.service - etcd   Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Wed 2021-08-18 20:13:30 UTC; 4s ago
  Process: 2971 ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd0 --advertise-client-urls http://10.0.0.11:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://10.0.0.11:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster etcd0=http://10.0.0.11:2380 (code=exited, status=125)
 Main PID: 2971 (code=exited, status=125)

Eu executo isso em uma máquina Amazon Linux 2, com um script de dados do usuário para ser executado na inicialização. Eu confirmei isso docker.servicee docker_ecr_login.serviceexecutei com sucesso.

E logo após o lançamento da máquina, posso ver que o etcd está em execução:

 sudo systemctl status etcd
● etcd.service - etcd
   Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: disabled)
   Active: activating (start) since Wed 2021-08-18 20:30:07 UTC; 1min 20s ago
 Main PID: 1573 (docker)
    Tasks: 9
   Memory: 24.3M
   CGroup: /system.slice/etcd.service
           └─1573 /usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr.eu-north-1.amazonaws.com...

Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.690Z","logger":"raft","caller":"...rm 2"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.691Z","caller":"etcdserver/serve..."3.5"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.693Z","caller":"membership/clust..."3.5"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.693Z","caller":"etcdserver/server.go:2...
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.693Z","caller":"api/capability.g..."3.5"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.693Z","caller":"etcdserver/serve..."3.5"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.693Z","caller":"embed/serve.go:9...ests"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.695Z","caller":"etcdmain/main.go...emon"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.695Z","caller":"etcdmain/main.go...emon"}
Aug 18 20:30:17 ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20:30:17.702Z","caller":"embed/serve.go:1...2379"}
Hint: Some lines were ellipsized, use -l to show in full.

Eu recebo o mesmo comportamento se o etcd escuta o IP do nó (10.0.0.11) ou 127.0.0.1.

Eu posso executar o etcd localmente, iniciado na linha de comando ( e não termina após 30 segundos ), com:

sudo docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd-local \
my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 \
/usr/local/bin/etcd --data-dir=/etcd-data \
--name etcd0 \
--advertise-client-urls http://127.0.0.1:2379 \
--listen-client-urls http://0.0.0.0:2379 \
--initial-advertise-peer-urls http://127.0.0.1:2380 \
--listen-peer-urls http://0.0.0.0:2380 \
--initial-cluster etcd0=http://127.0.0.1:2380

Os parâmetros para etcd são semelhantes à documentação Executando um único nó etcd - ectd 3.5 .

Esta é a parte relevante do script de inicialização que se destina a iniciar o etcd:

sudo docker volume create --name etcd-data

cat <<EOF | sudo tee /etc/systemd/system/etcd.service
[Unit]
Description=etcd
After=docker_ecr_login.service

[Service]
Type=notify
ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data \
 --name etcd my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 \
 /usr/local/bin/etcd --data-dir=/etcd-data \
 --name etcd0 \
 --advertise-client-urls http://10.0.0.11:2379 \
 --listen-client-urls http://0.0.0.0:2379 \
 --initial-advertise-peer-urls http://10.0.0.11:2380 \
 --listen-peer-urls http://0.0.0.0:2380 \
 --initial-cluster etcd0=http://10.0.0.11:2380
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable etcd
sudo systemctl start etcd

Ao listar todos os containers da máquina, vejo que está rodando:

sudo docker ps -a
CONTAINER ID   IMAGE                                                       COMMAND                  CREATED          STATUS                      PORTS                          NAMES
a744aed0beb1   my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0   "/usr/local/bin/etcd…"   25 minutes ago   Exited (0) 24 minutes ago                          etcd

mas suspeito que não possa ser reiniciado, pois o nome do contêiner já existe.

Por que o contêiner etcd é encerrado após ~ 30 segundos, quando iniciado a partir do systemd? Parece que foi iniciado com sucesso, mas o systemd só o mostra no status "ativando", mas nunca no status "ativo" e parece ser encerrado após cerca de 30 segundos. Há alguma sinalização ausente do contêiner do docker etcd para o systemd? Em caso afirmativo, como faço para obter essa sinalização correta?

ATUALIZAR:

Depois de remover a Restart=on-failureinstrução no arquivo da unidade de serviço, agora recebo status: failed (Result: timeout) :

$ sudo systemctl status etcd
● etcd.service - etcd
   Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: disabled)
   Active: failed (Result: timeout) since Wed 2021-08-18 21:35:54 UTC; 5min ago
  Process: 1567 ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd0 --advertise-client-urls http://127.0.0.1:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://127.0.0.1:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster etcd0=http://127.0.0.1:2380 (code=exited, status=0/SUCCESS)
 Main PID: 1567 (code=exited, status=0/SUCCESS)

Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.332Z","caller":"osutil/interrupt...ated"}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.333Z","caller":"embed/etcd.go:36...379"]}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: WARNING: 2021/08/18 21:35:54 [core] grpc: addrConn.createTransport failed ...ing...
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.335Z","caller":"etcdserver/serve...6a6c"}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.337Z","caller":"embed/etcd.go:56...2380"}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.338Z","caller":"embed/etcd.go:56...2380"}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21:35:54.339Z","caller":"embed/etcd.go:36...379"]}
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: Failed to start etcd.
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: Unit etcd.service entered failed state.
Aug 18 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: etcd.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
linux docker systemd amazon-linux-2 etcd

1 respostas

  1. Best Answer

    Atualização: Postando dados de teste e integrando atualizações com base nos comentários recebidos. docker -d não é necessário para integração com o systemd, como se pensava originalmente. A configuração Type= como Michael indicou parece ser na minha experiência, mais importante do que descarregar o status daemonizado de um serviço para o docker. O problema do OP parecia à primeira vista ser um efeito colateral de não ter um plano de fundo, como expliquei originalmente. Esse pano de fundo parece irrelevante depois de testá-lo ainda mais.

    Observe que a imagem da Amazon AWS usada no OP não é algo que eu possa testar ou solucionar problemas diretamente. Um exemplo contrastante para etcd e systemd é mostrado aqui para ajudar na configuração do sistema de endpoint de forma semelhante ao meu. Detalhes do sistema:

    • Ubuntu 20.04 LTS
    • janela de encaixe 20.10.7
    • etc 3.5.0

    configuração do sistema

    Acabei com o seguinte arquivo de serviço systemd. Observe que Tipo=simples, devido à sugestão de Michael para esclarecer esse ponto na resposta (e, aparentemente, minha própria compreensão dessa peça do quebra-cabeça). Você pode aprender mais sobre os tipos de systemd aqui:

    https://www.freedesktop.org/software/systemd/man/systemd.service.html

    Tipo importa; Mais ao ponto, meu entendimento original de simples como tipo, foi míope focado na falta de comunicação de volta ao systemd, o que me fez ignorar o comportamento aplicável do que a configuração de tipo faz em reação às respostas do aplicativo chamado (neste caso estiva).

    A remoção do tipo ou a adição do tipo ao simples resultará no mesmo comportamento independentemente. A configuração a seguir no meu teste funcionou de forma confiável, assim como -d estar presente ou não no comando docker run:

    [Unit]
Description=Docker container-etcd.service
Documentation=man:docker
Requires=docker.service
Wants=network.target
After=network-online.target

[Service]
ExecStartPre=- /usr/bin/docker stop etcd
ExecStartPre=- /usr/bin/docker rm etcd
ExecStart=docker run --rm -d -p 2379:2379 -p 2380:2380 --volume=/home/user/etcd-data:/etcd-data --name etcd quay.io/coreos/etcd:v3.5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd --initial-advertise-peer-urls http://10.4.4.132:2380 --listen-peer-urls http://0.0.0.0:2380 --advertise-client-urls http://10.4.4.132:2379 --listen-client-urls http://0.0.0.0:2379 --initial-cluster etcd=http://10.4.4.132:2380
ExecStop=/usr/bin/docker stop etcd -t 10
ExecRestart=/usr/bin/docker restart etcd
KillMode=none
RemainAfterExit=1
Restart=on-failure
Type=simple

[Install]
WantedBy=multi-user.target default.target

    Notas

    • RemainAfterExit adicionado, pois o systemd considerará o serviço encerrado após o início, se não estiver presente; A falta deste booleano cria uma situação aparentemente errônea onde docker psmostra o container rodando, mas se systemctl status container-etcdmostrava encerrado e inativo.
    • O arquivo de unidade systemd está sintaticamente incorreto. %n é normalmente usado para que as linhas Exec se refiram ao nome do serviço (como em ...docker restart %n); Eu não queria introduzir mais confusão ao tentar resolver o problema do OP. Sem mencionar que fui com etcd como o nome do contêiner docker, versus container-etcd, como o nome do serviço da unidade.
    • ExecStart foi reduzido a um comando de uma linha. \ sintaxe padrão não funcionou para mim, nem citando o comando de chamada etcd para o contêiner. Meus testes de ontem pareciam ter funcionado bem, mas a configuração de hoje não se comportou da mesma forma que ontem. Então refiz o teste e as configurações para encontrar o que parecia ser mais estável para mim.
    • Obviamente, se você for usar o docker rm a qualquer momento, deve ou deve usar montagens de ligação, conforme declarado no OP e aqui com --volume. Pessoalmente, uso locais de caminho completo, todos armazenados em /srv e, em seguida, vinculo a montagem no contêiner. Dessa forma tenho uma pasta para fazer backup, e o estado dos containers, presentes ou não, é irrelevante.

    Confirmação

    Depois de atualizar o arquivo de serviço do systemd, fazer um daemon-reload, etc., executei no contêiner e executei um comando de teste no etcd:

    • docker exec -it etcd sh
    • etcdctl --endpoints=http://10.4.4.132:2379 member list

    Resultado

    9a552f9b95628384, started, etcd, http://10.4.4.132:2380, http://10.4.4.132:2379, false
    • 1

relate perguntas