CoreOSサーバーで一般的な問題をトラブルシューティングする方法
序章
CoreOSは、分散システムの構築を容易にするいくつかの興味深いテクノロジーを導入しています。 ただし、これらのツールは、新しいユーザーにはなじみがなく、独自の風変わりなものになる可能性があります。 主な問題の1つは、抽象化の多くの層が機能しており、問題が発生している場所を特定するのが難しい場合があることです。
このガイドでは、CoreOSホスト、それらが実行するDockerコンテナー、およびいくつかの異なる部分をまとめるサービス管理ツールを操作するためのいくつかの基本的なトラブルシューティング手順について説明します。
Cloud-Configファイルのデバッグ
クラスターが正しく起動しないときに、新規および経験豊富なCoreOSユーザーが遭遇する最も一般的な問題の1つは、無効なcloud-configファイルです。
CoreOSでは、作成時にcloud-configファイルをサーバーに渡す必要があります。 このファイルに含まれる情報を使用して、それ自体をブートストラップし、既存のクラスターを開始または参加します。 また、重要なサービスを開始し、ユーザーやグループなどのシステムの基本を構成できます。
cloud-configファイルで確認するいくつかの事項:
- 「#cloud-config」で始まりますか?:渡されるすべてのcloud-configファイルは、最初の行で「#cloud-config」が単独で始まる必要があります。 これは通常YAMLでは無視されるコメントですが、この場合、この行は、これに構成データが含まれていることをクラウドinitシステムに通知するために使用されます。
- ファイルに有効なYAMLが含まれていますか?:Cloud-configファイルは、読みやすさに重点を置いたデータシリアル化形式であるYAMLで記述されています。 問題が発生した場合は、cloud-configをオンラインのYAMLバリデーターに貼り付けてください。 ファイルにエラーが含まれていてはなりません。 CoreOSは、cloud-configファイルの構文 Cloud-ConfigValidatorをチェックできる便利なツールを提供します。
- 新しい検出トークンを使用していますか?:検出アドレスは、クラスター全体がダウンしている場合でも、マシンのデータを追跡します。 古いトークンで起動すると、特に以前に同じIPアドレスをすでに登録している場合は、検出登録が失敗します。 この問題を回避するために、クラスターを開始するたびに新しい検出トークンを使用してください。
- フリートおよびetcdサービスを開始していますか?:クラスターが正しく機能するために開始する必要がある2つのサービスは、
fleet
とetcd
です。 これらの最小要件を満たす基本的なcloud-configファイルについては、DigitalOceanで実行されるCoreOSクラスターの取得に関するガイドを参照してください。
cloud-configファイルを渡すことができるのは、マシンが作成されたときだけです。そのため、間違えた場合は、サーバーインスタンスを破棄して、(ほとんどの場合、新しいトークンを使用して)再起動します。
cloud-configファイル自体が正しいことをかなり確信したら、次のステップは、ファイルが正しく処理されたことを確認するためにホストにログインすることです。
DigitalOceanでは、作成中にサーバーにsshキーを追加する必要があるため、これはほとんどの場合簡単です。 これは、通常、サーバーにSSH接続して、問題なくトラブルシューティングできることを意味します。
DigitalOceanコントロールパネルからログインする
ただし、クラウド構成が起動後にサーバーのネットワーク可用性に実際に影響を与える場合があります。 この場合、DigitalOceanコントロールパネルからログインする必要があります。 セキュリティ上の理由から、デフォルトではCoreOSイメージにパスワードが設定されていないため、これには問題があります。
これを回避するには、core
ユーザーのパスワードエントリを含む新しいcloud-configファイルを使用してサーバーを再作成する必要があります。 レクリエーションの要件があるため、これはおそらく、この問題を常に確認していて、より多くの情報を取得したい場合にのみ役立ちます。 トラブルシューティングを行うために、一般的な方法として、すべてのcloud-configファイルにパスワード情報を追加することをお勧めします。 接続を確認した後、手動でパスワードの設定を解除できます。
パスワードはハッシュ形式である必要があります。 使用可能なソフトウェアに応じて、これらのいくつかの異なる方法を生成できます。 次のいずれかが機能するため、最適なオプションを使用してください。
mkpasswd --method=SHA-512 --rounds=4096 openssl passwd -1 python -c "import crypt, getpass, pwd; print crypt.crypt('password', '\$6\$SALT\$')" perl -e 'print crypt("password","\$6\$SALT\$") . "\n"'
ハッシュを取得したら、users
という新しいセクションをcloud-config(「coreos」セクションの外)に追加して、次の情報を配置できます。
#cloud-config users: - name: core passwd: hashed_password coreos: . . .
YAML構文を検証し、サーバーを再度作成するときにこの新しいcloud-configを使用します。 これで、選択したパスワードを使用して、DigitalOceanコントロールパネルからログインできるようになります。
個々のホストを確認する
ログインしたら、cloud-configが正しく処理されたかどうかを確認するために確認する必要のあることがいくつかあります。
エッセンシャルサービスのエラーをチェックする
開始する簡単な方法は、fleetctl
にどのマシンについて知っているかを尋ねることです。 これがエラーなしで返される場合は、fleet
およびetcd
が正しく開始され、他のホストと通信していることを意味します。
fleetctl list-machines
ここでエラーが発生した場合は、注意すべき点がいくつかあります。 一般的なエラーは次のようになります。
2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused 2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 100ms 2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused 2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 200ms
これは、さまざまなコンポーネントの積み重ねを表しているため、トップレベルから始めて、下に向かっていきましょう。 fleet
サービスをチェックして、どのようなエラーが発生するかを確認してください。
systemctl status -l fleet
● fleet.service - fleet daemon Loaded: loaded (/usr/lib64/systemd/system/fleet.service; static) Drop-In: /run/systemd/system/fleet.service.d └─20-cloudinit.conf Active: active (running) since Thu 2014-09-18 17:10:50 UTC; 2min 26s ago Main PID: 634 (fleetd) CGroup: /system.slice/fleet.service └─634 /usr/bin/fleetd Sep 18 17:13:07 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused Sep 18 17:13:07 dumb1 fleetd[634]: ERROR client.go:200: Unable to get result for {Update /_coreos.com/fleet/machines/795de101bcd24a3a96aa698f770f0074/object}, retrying in 800ms Sep 18 17:13:08 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused
ご覧のとおり、サービスは実行されていますが、etcd
ポートであるポート4001
に接続できません。 これは、問題がetcd
にある可能性があることを示しています。
重要なサービスごとに、ステータスとログを確認する必要があります。 これを行う一般的な方法は次のとおりです。
systemctl status -l service journalctl -b -u service
「status」コマンドは、サービスの状態と最後の数行のログを提供します。 journalコマンドを使用すると、完全なログにアクセスできます。
次にetcd
でこれらを試してみると、この場合はetcd
サービスが実行されていないことがわかります。
systemctl status -l etcd
● etcd.service - etcd Loaded: loaded (/usr/lib64/systemd/system/etcd.service; static) Drop-In: /run/systemd/system/etcd.service.d └─20-cloudinit.conf Active: activating (auto-restart) (Result: exit-code) since Thu 2014-09-18 17:17:03 UTC; 9s ago Process: 938 ExecStart=/usr/bin/etcd (code=exited, status=1/FAILURE) Main PID: 938 (code=exited, status=1/FAILURE) Sep 18 17:17:03 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE Sep 18 17:17:03 dumb1 systemd[1]: Unit etcd.service entered failed state.
etcd
ログを確認すると、次のようになります。
journalctl -b -u etcd
Sep 18 17:21:27 dumb1 systemd[1]: Starting etcd... Sep 18 17:21:27 dumb1 systemd[1]: Started etcd. Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.966 INFO | The path /var/lib/etcd/log is in btrfs Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO | Set NOCOW to path /var/lib/etcd/log succeeded Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO | Discovery via https://discovery.etcd.io using prefix /. Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.422 WARNING | Discovery encountered an error: invalid character 'p' after top-level value Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 WARNING | 795de101bcd24a3a96aa698f770f0074 failed to connect discovery service[https://discovery.etcd.io/]: invalid character 'p' after top-level value Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 CRITICAL | 795de101bcd24a3a96aa698f770f0074, the new instance, must register itself to discovery service as required Sep 18 17:21:28 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE Sep 18 17:21:28 dumb1 systemd[1]: Unit etcd.service entered failed state.
強調表示された行は、この特定のインスタンスに検出トークンがなかったことを示しています。
ファイルシステムをチェックして、Cloud-Configによって生成された構成ファイルを確認します
次に確認するのは、cloud-configによって生成されたサービスファイルです。
CoreOSマシンがcloud-configファイルを処理すると、fleet
およびetcd
の起動に使用するスタブsystemd
ユニットファイルが生成されます。 作成され、サービスの開始に使用されているsystemd
構成ファイルを確認するには、それらが削除されたディレクトリに移動します。
cd /run/systemd/system ls -F
etcd.service.d/ fleet.service.d/ oem-cloudinit.service
CoreOSによって自動的に処理される一般化されたoem-cloudinit.service
ファイルと、サービス情報が含まれているディレクトリを確認できます。 次のように入力すると、etcd
サービスが起動している情報を確認できます。
cat etcd.servicd.d/20-cloudinit.conf
[Service] Environment="ETCD_ADDR=10.132.247.162:4001" Environment="ETCD_DISCOVERY=https://discovery.etcd.io/" Environment="ETCD_NAME=795de101bcd24a3a96aa698f770f0074" Environment="ETCD_PEER_ADDR=10.132.247.162:7001"
これは、サービスの開始時にサービスに追加情報を追加するために使用されるスタブsystemd
ユニットファイルです。 ここでわかるように、ETCD_DISCOVERY
アドレスは、ログで見つかったエラーと一致します。最後に検出トークンが追加されていません。 有効な検出トークンを使用してcloud-configを使用してマシンを再作成する必要があります。
次のように入力すると、fleet
に関する同様の情報を取得できます。
cat fleet.service.d/20-cloudinit.conf
[Service] Environment="FLEET_METADATA=region=nyc,public_ip=104.131.1.89" Environment="FLEET_PUBLIC_IP=10.132.247.162"
ここでは、fleet
にcloud-configでいくつかのメタデータ情報が与えられていることがわかります。 これは、サービスユニットファイルを作成する際のスケジューリングに使用できます。
メタデータサービスへのアクセスの確認
CoreOSサーバーがDigitalOceanで作成されたときに提供される実際のcloud-configファイルは、メタデータサービスを使用して保存されます。 サーバー上でcloud-configの証拠が見つからなかった場合は、DigitalOceanメタデータサービスから情報を取得できなかった可能性があります。
ホストマシン内から、次のように入力します。
curl -L 169.254.169.254/metadata/v1
id hostname user-data vendor-data public-keys region interfaces/ dns/
リダイレクトを追跡するには、-L
を含める必要があります。 169.254.169.254
アドレスはすべてのサーバーに使用されるため、このアドレスは変更しないでください。 これにより、サーバーに関する情報を含むメタデータフィールドとディレクトリが表示されます。 DigitalOcean CoreOSサーバー内からこれに到達できない場合は、サポートチケットを開く必要がある場合があります。
サーバーに関する情報については、このURLを照会できます。 追加のcurlコマンドを使用して、ここで各エントリを調べることができますが、cloud-configファイルを含むのはuser-data
フィールドです。
curl -L 169.254.169.254/metadata/v1/user-data
#cloud-config users: - name: core passwd: $6$CeKTMyfClO/CPSHB$02scg00.FnwlEYdq/oXiXoohzvvlY6ykUck1enMod7VKJrzyGRAtZGziZh48LNcECu/mtgPZpY6aGCoj.h4bV1 coreos: etcd: # generated token from https://discovery.etcd.io/new discovery: https://discovery.etcd.io/ # multi-region and multi-cloud deployments need to use $public_ipv4 addr: $private_ipv4:4001 peer-addr: $private_ipv4:7001 fleet: public-ip: $private_ipv4 metadata: region=nyc,public_ip=$public_ipv4 units: - name: etcd.service command: start - name: fleet.service command: start
この場所からcloud-configを読み取ることができる場合は、サーバーにcloud-configデータを読み取る機能があり、サーバーの起動時にその指示を実装する必要があることを意味します。
CoreOSホストマシンに関するその他の問題のトラブルシューティング
さらにデバッグを行う必要がある場合は、CoreOSに最小限の基本インストールが含まれていることがすぐにわかります。 すべてのソフトウェアがコンテナで実行されることを想定しているため、最も基本的なユーティリティプログラムの一部も含まれていません。
幸い、CoreOS開発者は、この問題に対する洗練されたソリューションを提供します。 各ホストに含まれている「ツールボックス」スクリプトを使用することで、ホストシステムにアクセスできるFedoraコンテナーを起動できます。 このコンテナの内部から、ホストのデバッグに必要なユーティリティをインストールできます。
起動するには、toolbox
コマンドを使用します。
toolbox
これにより、最新のFedoraイメージがプルダウンされ、コンテナー内のコマンドラインにドロップされます。 簡単なチェックを行うと、ホストシステムのネットワークにアクセスできることがわかります。
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 04:01:28:7c:39:01 brd ff:ff:ff:ff:ff:ff inet 169.254.180.43/16 brd 169.254.255.255 scope link eth0 valid_lft forever preferred_lft forever . . .
また、ホストのプロセスへのフルアクセスもあります。
ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 106024 4912 ? Ss 17:10 0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 19 root 2 0.0 0.0 0 0 ? S 17:10 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 17:10 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S< 17:10 0:00 [kworker/0:0H] root 6 0.0 0.0 0 0 ? S 17:10 0:00 [kworker/u4:0] root 7 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_sched] root 8 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_bh] . . .
この環境内に必要なツールをインストールできます。 たとえば、Fedoraパッケージマネージャーを使用して、追加機能を備えたトップクローンであるhtop
をインストールできます。
yum install htop -y && htop
これにより、ホストのすべてのプロセスがロードされたプロセスモニターが表示されます。
コンテナ環境を終了するには、「exit」と入力するか、CTRL-]
を3回速く押します。 ホストのシェルセッションに戻ります。
任意のホストからのサービスのトラブルシューティング
トラブルシューティングが必要になる可能性のあるもう1つの領域は、実行している実際のサービスです。 クラスタ全体でサービスを管理するためのfleet
とfleetctl
があるため、最初のステップはクラスタ内の任意のサーバーで実行できます。
まず、fleet
の観点と、各サービスの実行に割り当てられている個々のホストの両方の観点から、サービスの状態を把握する必要があります。 fleetctl
ツールは、この情報を簡単に取得するためのコマンドを提供します。
まず、次のように入力して、fleet
がサービス状態をどのように確認するかを理解します。
fleetctl list-unit-files
UNIT HASH DSTATE STATE TARGET [email protected] 06d78fb loaded loaded 04856ec4.../10.132.249.212 [email protected] 06d78fb loaded loaded 197a1662.../10.132.249.206 [email protected] 06d78fb loaded loaded e3ca8fd3.../10.132.252.37 [email protected] 0f7f53b launched launched 04856ec4.../10.132.249.212 [email protected] 0f7f53b launched launched 197a1662.../10.132.249.206 [email protected] 0f7f53b launched launched e3ca8fd3.../10.132.252.37 nginx_lb.service c8541af launched launched 96ec72cf.../10.132.248.177
これにより、fleet
が認識しているすべてのサービスの概要がわかります。 この出力には、いくつかの非常に重要な情報が含まれています。 見てみましょう。
- UNIT :これはユニットの名前です。 この場合、上位6つのサービスはすべてインスタンスユニットであり(テンプレートとインスタンスの詳細についてはこちらをご覧ください)、下位は静的インスタンスのようです。 これらは、これらの各サービスに影響を与えるコマンドを発行するために使用できる名前です。
- HASH :これはこのサービスを制御するために使用されるユニットファイルのハッシュです。 ご覧のとおり、すべての
apache-discovery
インスタンスは同じテンプレートファイルから生成されます。apache
インスタンスはすべて別のインスタンスから生成されます。 これは、古いユニットファイルを使用して、サービスのいずれかが奇妙な動作を示しているかどうかを確認するのに役立ちます。 - DSTATE :これはユニットの望ましい状態です。
fleetctl
にコマンドを発行してユニットの状態を変更すると、この列が変更され、そのユニットの目的の状態が反映されます。 - STATE :これは、
fleet
に知られている、ユニットの実際の状態です。 これがDSTATEと異なる場合は、操作が失敗したことを意味している可能性があります。 - TARGET :このサービスを実行するようにスケジュールされているマシン。 これは、ユニットが起動またはロードされたときに使用可能になります。 これには、マシンIDとマシンのIPアドレスが含まれています。
ご覧のとおり、問題のデバッグに役立つ情報がかなりあります。
ただし、これだけが重要なチェック場所ではありません。 fleet
がサービスの状態に関してマシンのローカルsystemd
インスタンスと一致しない場合があることを理解することが重要です。 これは、あるユニットが別のユニットを内部で開始または停止した場合など、さまざまな理由で発生する可能性があります。
そのサービスを実行しているホストのsystemd
インスタンスから取得した各サービスの状態に関する情報を取得するには、代わりにlist-units
コマンドを使用します。
fleetctl list-units
UNIT MACHINE ACTIVE SUB [email protected] 04856ec4.../10.132.249.212 active running [email protected] 197a1662.../10.132.249.206 active running [email protected] e3ca8fd3.../10.132.252.37 active running [email protected] 04856ec4.../10.132.249.212 active running [email protected] 197a1662.../10.132.249.206 active running [email protected] e3ca8fd3.../10.132.252.37 active running nginx_lb.service 96ec72cf.../10.132.248.177 active running
ここでは、すべてのサービスが実行中としてリストされていることがわかります。 これは、list-unit-files
が示す情報とは一致しません。 これは、各apache
サービスが、fleet
に通知せずに、関連するapache-discovery
サービスを起動するためです。 これはエラーではありませんが、サービスの実際の状態について混乱を引き起こす可能性があります。
いずれかのサービスに関する詳細情報を取得するには、fleetctl
を使用して、ホストシステムのsystemctl status
およびjournalctl -u
情報にアクセスできます。 次のように入力するだけです。
fleetctl status service_name
● [email protected] - Apache web server service on port 4444 Loaded: loaded (/run/fleet/units/[email protected]; linked-runtime) Active: active (running) since Thu 2014-09-18 18:50:00 UTC; 7min ago Process: 3535 ExecStartPre=/usr/bin/docker pull imchairmanm/apache (code=exited, status=0/SUCCESS) Process: 3526 ExecStartPre=/usr/bin/docker rm apache.%i (code=exited, status=0/SUCCESS) Process: 3518 ExecStartPre=/usr/bin/docker kill apache.%i (code=exited, status=0/SUCCESS) Main PID: 3543 (docker) CGroup: /system.slice/system-apache.slice/[email protected] └─3543 /usr/bin/docker run -t --name apache.4444 -p 10.132.249.212:4444:80 imchairmanm/apache /usr/sbin/apache2ctl -D FOREGROUND
または、次のように入力してジャーナルを読みます。
fleetctl journal service_name
-- Logs begin at Mon 2014-09-15 14:54:12 UTC, end at Thu 2014-09-18 18:57:51 UTC. -- Sep 17 14:33:20 lala2 systemd[1]: Started Apache web server service on port 4444. Sep 17 14:33:20 lala2 docker[21045]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message Sep 18 18:49:29 lala2 systemd[1]: Stopping Apache web server service on port 4444... Sep 18 18:49:39 lala2 docker[3500]: apache.4444 Sep 18 18:49:39 lala2 systemd[1]: Stopped Apache web server service on port 4444. Sep 18 18:49:58 lala2 systemd[1]: Starting Apache web server service on port 4444... Sep 18 18:49:58 lala2 docker[3518]: apache.4444 Sep 18 18:49:58 lala2 docker[3526]: apache.4444 Sep 18 18:49:58 lala2 docker[3535]: Pulling repository imchairmanm/apache Sep 18 18:50:00 lala2 systemd[1]: Started Apache web server service on port 4444.
これにより、サービスが失敗する理由に関するいくつかの良い情報が得られます。 たとえば、ユニットファイルが使用できない依存関係を宣言した場合、それはここに表示されます(これは、依存関係がfleet
にまだロードされていない場合に発生する可能性があります)。
これらのコマンドのいくつかを発行しているときに遭遇する可能性のあるエラーの1つは次のとおりです。
Error running remote command: SSH_ AUTH _SOCK environment variable is not set. Verify ssh-agent is running. See https://github.com/coreos/fleet/blob/master/Documentation/using-the-client.md for help.
これは、このホストに接続したときにsshユーザーエージェントを転送しなかったことを示しています。 fleet
がクラスター内の他のマシンに関する情報を取得するために、ローカルコンピューターに保持されているSSHクレデンシャルを使用して接続します。
これを行うには、ローカルコンピューターでsshエージェントを実行し、秘密鍵を追加する必要があります。 次のように入力して、ローカルコンピューターでこれを行うことができます。
eval $(ssh-agent) ssh-add
Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)
sshエージェントに秘密鍵へのアクセスが許可されたら、-A
オプションを使用してCoreOSホストに接続し、次の情報を転送する必要があります。
ssh -A core@coreos_host
これにより、SSH接続しているマシンが、資格情報を使用してクラスター内の他のマシンに接続できるようになります。 これにより、リモートクラスターメンバーからsystemd
情報を読み取ることができます。 また、他のメンバーに直接sshすることもできます。
サービスを実行しているホストからのコンテナのトラブルシューティング
fleetctl
だけを使用して多くの優れた情報を取得できますが、トラブルシューティングのためにサービスの実行を担当するホストに移動する必要がある場合があります。
上で述べたように、接続時にSSH情報を転送した場合、これは簡単です。 接続したホストから、fleetctl
を使用して他のマシンに「ホップ」できます。 マシンIDを指定することも、単にサービス名を指定することもできます。 fleetctl
プロセスは、参照しているホストを知るのに十分賢いです。
fleetctl ssh service_name
これにより、そのサービスを実行するために割り当てられたホストへのssh接続が提供されます。 これが機能するには、サービスが「ロード済み」または「起動済み」の状態である必要があります。
ここから、すべてのローカルトラブルシューティングツールにアクセスできます。 たとえば、fleetctl journal
コマンドでは使用できない可能性のあるjournalctl
フラグのより完全なセットにアクセスできます。
journalctl -b --no-pager -u apache@4444
この時点で、Dockerの問題のトラブルシューティングを行うことをお勧めします。 実行中のコンテナのリストを表示するには、次のように入力します。
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 30 minutes ago Up 30 minutes 10.132.249.212:4444->80/tcp apache.4444
現在、1つのコンテナが実行されていることがわかります。 強調表示されたコンテナIDは、さらに多くのDocker操作に役立ちます。
サービスの開始に失敗した場合、コンテナは実行されません。 終了/失敗したコンテナを含むすべてのコンテナのリストを表示するには、-a
フラグを渡します。
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 31 minutes ago Up 31 minutes 10.132.249.212:4444->80/tcp apache.4444 4389108bff1a imchairmanm/apache:latest "/usr/sbin/apache2ct 28 hours ago Exited (-1) 28 hours ago apache.8888 5af6e4f95642 imchairmanm/lalala:latest "/usr/sbin/apache2ct 3 days ago Exited (-1) 3 days ago apache.7777
開始されたlastコンテナーを、その状態に関係なく表示するには、代わりに-l
フラグを使用できます。
docker ps -l
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 33 minutes ago Up 33 minutes 10.132.249.212:4444->80/tcp apache.4444
探しているコンテナのコンテナIDを取得したら、Dockerレベルで調査を開始できます。 まず、ログを表示できます。
docker logs container_id
これにより、コンテナから収集できるログ情報が得られます。 これは、コンテナが実行されているかどうかに関係なく機能するはずです。 コンテナがインタラクティブに実行された場合(-i
および-t
フラグとシェルセッションを使用)、セッション全体がログで利用可能になります。
次のように入力すると、アクティブなコンテナの実行中のプロセスのリストを取得できます。
docker top container_id
コンテナ内にシェルセッションを生成する
最も便利な手順の1つは、実行中のコンテナでシェルセッションを実際に開いて、内部から何が起こっているかを確認することです。 これを行うために、CoreOSにはnsenter
というユーティリティが付属しています。
Dockerコンテナーは、カーネルネームスペースを設定することで機能し、このツールはこれらの環境内でセッションを開始できます。 最初のステップは、入力するコンテナーのPIDを取得することです。
PID=$(docker inspect --format {{.State.Pid}} container_id)
これで、次のように入力して、そのコンテナ環境内でシェルセッションを開くことができます。
sudo nsenter -t $PID -m -u -i -n -p
コンテナ環境内でシェルセッションが提供されます。 ここから、ログを表示したり、必要なその他のトラブルシューティングを実行したりできます。
コンテナの作成方法によっては、bash
が見つからなかったというメッセージが表示される場合があります。 この場合、コマンドの最後に追加して、汎用のsh
シェルを使用する必要があります。
sudo nsenter -t $PID -m -u -i -n -p /bin/sh
結論
これらは、CoreOSクラスターの問題をトラブルシューティングするために使用できる手順のほんの一部です。 これらは、cloud-configファイルで発生する可能性のある問題を追跡し、サービスを正しくクラスター化して開始するマシンの機能のトラブルシューティングに役立ちます。 Dockerコンテナーとサービス自体の問題を追跡することは、私たちがカバーしたもう1つの領域です。
覚えておくべき最も重要なことの1つは、システムに関する情報が多いほど、デバッグがはるかに簡単になることです。 各コンポーネントの役割と、システムが機能するためにそれらがどのように相互作用するかをしっかりと把握しておくと役立ちます。 問題を追跡しようとしたときに迷子になった場合は、CoreOSの基本を復習しておくと役立つ場合があります。