CoreOSでの起動時にDockerデーモンが起動しない

23

CoreOS（835.9.0）の標準インストールがありますが、起動時にdockerデーモンが起動しません。SSHで起動してから起動するだけdocker psです。

システムの起動時にdockerデーモンを自動的に起動するにはどうすればよいですか？

ドッカーデーモンと言うと、ps -ef | grep dockerやるまでプロセスが表示されないdocker ps

boot docker coreos

— クリス
ソース

40

sudo systemctl enable docker トリックをしました。

— クリス
ソース

2

おかげで、私はDockerのドキュメントを読んで、何も助けることができませんでした-再起動ポリシーについて多くのことを見つけましたが、もちろんdockerデーモンが起動した後にのみ適用されます。

— クリス

6

背景：これは、DockerがCoreOSでアクティブ化されるソケットであるためです。つまり、ブートチェーンをブロックしません。初期のバージョンのdockerは、ディスク上に多くのコンテナがあると起動に時間がかかり、Dockerに依存するすべてのものがすぐに起動しなくなり、興味深い障害が発生しました。

— ロブ

4

良さ。これは私を怒らせた。私がこれについて言及しているドキュメントはありません。そのため、AWS AMIを支持してCoreOSをほぼ誓約しました。（AWS AMIはデフォルトでDockerデーモンを自動的に起動します）。

— Nostalg.io

2

CoreOSが専用のDocker OSであり、起動中にdockerを起動していないことを考えると、CoreOSがこのように動作することは非常に珍しいでしょうか？

— typelogic

3

これは非常に重要な情報です。CoreOSのドキュメントでは、Docker（またはその他のコンテナーランタイム）を有効にする必要があることについては何も言及していません。裸のCoreOSでdockerコンテナーを起動することが可能であるため（およびCoreOSがコンテナーを実行するようになっているため）、デフォルトの印象を受けていました。最初の更新トリガーのリブートでコンテナーが起動しなかったときにのみ、自分の間違いに気付きました。

— フロリアンフォンストシュ

6

これはもう少し古いですが、私はすべての新しいサーバーでこれを行うためにcloud-initを使用し始めました。すべてのサーバーに使用する保存済みのcloud-initスクリプトがあります。その一部が含まれています：

#cloud-config
coreos:
  units:
    - name: "docker.service"
      command: "start"
      enable: true

これにより、Dockerサービスが有効になり、最初に起動するたびに起動されます。

— キャプテンクレイグ
ソース

2

Robによるこのコメントで既に説明したように、Dockerはソケットによってアクティブ化されます。つまり、呼び出されない限り、デーモンは起動しません。ここでの既存の回答は機能しますが、CoreOSは別のアプローチを推奨します。

CoreOSのドキュメントによると、これを行うための推奨される方法は、Dockerサービスを必要とする独自のアプリのサービスを作成することです。

/etc/systemd/system/myapp.service：

[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "trap 'exit 0' INT TERM; while true; do echo Hello World; sleep 1; done"

[Install]
WantedBy=multi-user.target

代わりにそのサービスを自動的に開始します：

$ sudo systemctl enable /etc/systemd/system/myapp.service
$ sudo systemctl start hello.service

ユースケースの例は、サービスが開始されるとコンテナーを最新バージョンに更新することであり、高度な例ではetcdにサービスも登録します。背景情報の詳細については、CoreOSのドキュメントを参照してください。

— Neograph734
ソース

それはCoreOSの「最新」ですか？Dockerには何年もの間再起動ポリシーがあり、このアプローチはもはや必要ではなく、望ましくもありません。決して望ましいことではありませんでしたが、コンテナ自体の再起動に対するDockerのサポートの欠如（の非常に古いバージョン）の回避策でした。CoreOS、私は推測する...使用を停止するのに長い過去の時間

— マイケル・ハンプトン

@MichaelHampton Restartポリシーは、コンテナが別の理由でクラッシュした場合にも適用されるため、あるものが別のものに置き換わるものではありません。その上、再起動ポリシーでは、起動時などにコンテナを更新することはできません。どちらが良いかはわかりませんが、この方法でもう少し制御できると思います。

— Neograph734

1

そのような制御が必要になり始めると、通常、オーケストレーションサービスによって提供される他の多くのビットも必要になります。単純な最後のdocker-composeからKubernetesまでです。

— マイケルハンプトン

1

私はDocker Swarmを使用しているため、systemdが特定のアプリを担当する必要はありません...起動時に起動するにはdockerが必要です。これが私が解決した解決策です。

これを入れてください/etc/systemd/system/poke-docker.service：

[Unit]
After=default.target

[Service]
Type=oneshot
ExecStart=/usr/bin/docker version
RemainAfterExit=yes

[Install]
WantedBy=default.target

そしてsystemctl enable poke-docker、起動シーケンスの終わり近くで、各ブートでトリガーするようにセットアップするだけです。このdocker versionコマンドは、Dockerデーモンと通信して、ソケットをトリガーし、Dockerサービス自体を開始します。

私systemctl enable dockerは他の答えでトリックを試しましたが、最初はうまくいきましたが、ドッカーが明らかに多くのことをしようとして悲惨に失敗するような雷の群れの状況を引き起こしたようです。これは、コメントに記載されている「ブートチェーンのブロック」動作であると思われます。

— コリン・ダンクラウ
ソース

群れでgitlab-runnerを実行する同じユースケースがありました。これは間違いなくデーモンを呼び起こします。systemdドロップインを点火ファイルに追加できますcoreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn