序章

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つのサービスは、fleetetcdです。 これらの最小要件を満たす基本的な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つの領域は、実行している実際のサービスです。 クラスタ全体でサービスを管理するためのfleetfleetctlがあるため、最初のステップはクラスタ内の任意のサーバーで実行できます。

まず、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 [email protected]coreos_host

これにより、SSH接続しているマシンが、資格情報を使用してクラスター内の他のマシンに接続できるようになります。 これにより、リモートクラスターメンバーからsystemd情報を読み取ることができます。 また、他のメンバーに直接sshすることもできます。

サービスを実行しているホストからのコンテナのトラブルシューティング

fleetctlだけを使用して多くの優れた情報を取得できますが、トラブルシューティングのためにサービスの実行を担当するホストに移動する必要がある場合があります。

上で述べたように、接続時にSSH情報を転送した場合、これは簡単です。 接続したホストから、fleetctlを使用して他のマシンに「ホップ」できます。 マシンIDを指定することも、単にサービス名を指定することもできます。 fleetctlプロセスは、参照しているホストを知るのに十分賢いです。

fleetctl ssh service_name

これにより、そのサービスを実行するために割り当てられたホストへのssh接続が提供されます。 これが機能するには、サービスが「ロード済み」または「起動済み」の状態である必要があります。

ここから、すべてのローカルトラブルシューティングツールにアクセスできます。 たとえば、fleetctl journalコマンドでは使用できない可能性のあるjournalctlフラグのより完全なセットにアクセスできます。

journalctl -b --no-pager -u [email protected]

この時点で、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の基本を復習しておくと役立つ場合があります。