前書き
CoreOSは、分散システムの構築を容易にする多くの興味深いテクノロジーを導入しています。 ただし、これらのツールは新規ユーザーには馴染みがなく、独自のエキセントリック性があります。 主な問題の1つは、抽象化の層が多数機能していることであり、問題が発生している場所を特定するのが難しい場合があります。
このガイドでは、CoreOSホスト、それらが実行するDockerコンテナー、およびさまざまな部分をまとめるサービス管理ツールを操作するための基本的なトラブルシューティング手順について説明します。
Cloud-Configファイルのデバッグ
新規および経験豊富なCoreOSユーザーがクラスターが正常に起動しないときに遭遇する最も一般的な問題の1つは、無効なcloud-configファイルです。
CoreOSでは、作成時にcloud-configファイルをサーバーに渡す必要があります。 このファイルに含まれる情報を使用して、自身をブートストラップし、既存のクラスターを開始または参加します。 また、重要なサービスを開始し、ユーザーやグループなどのシステムの基本を構成できます。
cloud-configファイルで確認するいくつかの事項：
-
*「＃cloud-config」で始まりますか？ これは通常、YAMLで無視されるコメントですが、このインスタンスでは、この行を使用して、構成データが含まれていることをクラウド初期化システムに通知します。
-
ファイルに有効なYAMLが含まれていますか？：Cloud-configファイルは、読みやすさに重点を置いたデータシリアル化形式であるYAMLで記述されています。 問題がある場合は、cloud-configをオンラインのhttp://codebeautify.org/yaml-validator[YAMLバリデーター]に貼り付けてください。 ファイルにエラーが含まれていてはなりません。 CoreOSは、cloud-configファイルの構文をチェックできる便利なツールhttps://coreos.com/validate/[Cloud-Config Validator]を提供します。
-
新しい発見トークンを使用していますか：発見アドレスは、クラスター全体がダウンしている場合でも、マシンのデータを追跡します。 特に以前に同じIPアドレスをすでに登録している場合は特に、古いトークンで起動すると、ディスカバリ登録は失敗します。 この問題を回避するには、クラスターを起動するたびに新しい発見トークンを使用します。
-
フリートとetcdサービスを開始していますか？：クラスターが正しく機能するために開始する必要がある2つのサービスは、「+ fleet 」と「 etcd +」です。 基本については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean [DigitalOceanで実行中のCoreOSクラスターの取得]のガイドをご覧ください。これらの最小要件を満たすcloud-configファイル。
マシンの作成時にのみcloud-configファイルを渡すことができます。そのため、間違えた場合は、サーバーインスタンスを破棄し、（ほとんどの場合、新しいトークンで）再起動します。
cloud-configファイル自体が正しいことを確認したら、次のステップはホストにログインしてファイルが正しく処理されたことを確認することです。
DigitalOceanでは、作成中にsshキーをサーバーに追加する必要があるため、これはほとんどの場合簡単です。 これは、通常、サーバーにsshして問題なくトラブルシューティングできることを意味します。
DigitalOceanコントロールパネルからのログイン
ただし、cloud-configが起動後、サーバーのネットワーク可用性に実際に影響を与える場合があります。 この場合、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 +」という新しいセクションを「config」に追加して、この情報を配置できます：
#cloud-config
users:
- name: core
passwd:
coreos:
. . .YAML構文の検証を実行し、サーバーを再度作成するときにこの新しいcloud-configを使用します。 その後、選択したパスワードを使用して、DigitalOceanコントロールパネルからログインできるようになります。
個々のホストの確認
ログインしたら、cloud-configが正しく処理されたかどうかを確認するためにいくつか確認する必要があります。
Essential Servicesでエラーを確認する
開始する簡単な方法は、どのマシンについて知っているかを「+ 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ご覧のとおり、サービスは実行されていますが、ポート + 4001 +（ `+ etcd `ポート）に接続できません。 これは、問題が ` etcd +`にある可能性があることを示しています。
重要な各サービスについて、ステータスとログを確認する必要があります。 これを行う一般的な方法は次のとおりです。
systemctl status -l
journalctl -b -u「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 etcdSep 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 |
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ファイルを処理するとき、スタブ `+ systemd `ユニットファイルを生成し、これを使用して ` fleet `および ` etcd `を起動します。 作成され、サービスの開始に使用されている ` systemd +`設定ファイルを確認するには、それらが削除されたディレクトリに移動します。
cd /run/systemd/system
ls -Fetcd.service.d/ fleet.service.d/ oem-cloudinit.serviceCoreOSによって自動的に処理される一般化された `+ 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/v1id
hostname
user-data
vendor-data
public-keys
region
interfaces/
dns/リダイレクトを追跡するには、「-L +」を含める必要があります。 ` 169.254.169.254 +`アドレスは_every_サーバーに使用されるため、このアドレスを変更しないでください。 これにより、サーバーに関する情報を含むメタデータフィールドとディレクトリが表示されます。 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 show1: 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 auxUSER 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回すばやく押します。 ホストのシェルセッションに戻ります。
任意のホストからのサービスのトラブルシューティング
トラブルシューティングが必要な別の領域は、実行している実際のサービスです。 サービスをクラスタ全体で管理するための `+ fleet `と ` fleetctl +`があるため、最初の手順はクラスタ内の任意のサーバーで実行できます。
「+ fleet 」の観点から、および各サービスを実行するように割り当てられた個々のホストの両方から、サービスの健全性を把握することから始めます。 ` fleetctl +`ツールは、この情報を簡単に取得するためのコマンドを提供します。
まず、次のように入力して、「+ fleet +」がサービスの状態をどのように認識するかを理解します。
fleetctl list-unit-filesUNIT 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つのサービスはすべてインスタンスユニットです（https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with-の詳細をご覧ください） fleet-unit-files [テンプレートとインスタンス]））下部は静的インスタンスのようです。 これらは、これらの各サービスに影響するコマンドを発行するために使用できる名前です。
-
* HASH *：これは、このサービスを制御するために使用されるユニットファイルのハッシュです。 ご覧のとおり、すべての `+ apache-discovery `インスタンスは同じテンプレートファイルから生成されます。 ` apache`インスタンスはすべて別のものから生成されます。 これは、古いユニットファイルを使用して、サービスのいずれかが異常な動作を示しているかどうかを確認するのに役立ちます。
-
* DSTATE *：これはユニットの望ましい状態です。 コマンドを「+ fleetctl +」に発行してユニットの状態を変更すると、この列はそのユニットに必要な状態を反映するように変更されます。
-
* STATE *：これは、ユニットの_actual_状態であり、 `+ fleet +`に知られています。 これがDSTATEと異なる場合、操作が失敗したことを意味する場合があります。
-
* TARGET *：このサービスを実行するようにスケジュールされているマシン。 これは、ユニットが起動またはロードされるときに使用可能になります。 マシンIDとマシンのIPアドレスが含まれています。
ご覧のとおり、問題のデバッグに役立つ情報は非常に多くあります。
ただし、これは確認する唯一の重要な場所ではありません。 サービスの状態について、「+ fleet 」がマシンのローカル「 systemd +」インスタンスに同意しない場合があることを認識することが重要です。 これは、1つのユニットが別のユニットを内部で起動または停止する場合など、さまざまな理由で発生する可能性があります。
そのサービスを実行しているホストの `+ systemd `インスタンスから取得した各サービスの状態に関する情報を取得するには、代わりに ` list-units +`コマンドを使用します。
fleetctl list-unitsUNIT 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● [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-- 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-addIdentity added: /home//.ssh/id_rsa (/home//.ssh/id_rsa)sshエージェントにプライベートキーへのアクセスが許可されたら、次の情報を転送するための `+ -A +`オプションを使用してCoreOSホストに接続する必要があります。
ssh -A core@これにより、ssh-inしているマシンが資格情報を使用してクラスター内の他のマシンに接続できるようになります。 これにより、リモートクラスタメンバーから「+ systemd +」情報を読み取ることができます。 また、他のメンバーに直接sshすることもできます。
サービスを実行しているホストからのコンテナのトラブルシューティング
`+ fleetctl +`のみを使用して多くのすばらしい情報を取得できますが、トラブルシューティングのためにサービスの実行を担当するホストに移動する必要がある場合があります。
上で述べたように、接続時にSSH情報を転送した場合、これは簡単です。 接続したホストから、 `+ fleetctl `を使用して他のマシンに「ホップ」できます。 マシンIDまたは単にサービス名を指定できます。 ` fleetctl +`プロセスは、どのホストを参照しているかを知るのに十分賢いです：
fleetctl sshこれにより、そのサービスを実行するために割り当てられたホストへのssh接続が提供されます。 これが機能するには、サービスが「ロード済み」または「起動済み」状態である必要があります。
ここから、すべてのローカルトラブルシューティングツールにアクセスできます。 たとえば、 `+ fleetctl journal `コマンドでは利用できないかもしれない ` journalctl +`フラグのより完全なセットにアクセスできます。
journalctl -b --no-pager -u apache@4444この時点で、Dockerの問題のトラブルシューティングを行うことができます。 実行中のコンテナのリストを表示するには、次を入力します。
docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
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 -aCONTAINER 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 -lCONTAINER 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これにより、コンテナから収集できるログ情報が得られます。 これは、コンテナが実行されているかどうかに関係なく機能するはずです。 コンテナがインタラクティブに（ `+ -i `および ` -t +`フラグとシェルセッションで）実行された場合、セッション全体がログで利用可能になります。
次のように入力することにより、アクティブなコンテナで実行中のプロセスのリストを取得できます。
docker topコンテナ内でのシェルセッションの生成
最も有用な手順の1つは、実行中のコンテナでシェルセッションを実際に開いて、内部から何が起こっているかを確認することです。 これを行うために、CoreOSには `+ nsenter +`というユーティリティが付属しています。
Dockerコンテナは、カーネルの名前空間を設定することで機能し、このツールはこれらの環境内でセッションを開始できます。 最初のステップは、入力するコンテナのPIDを取得することです。
PID=$(docker inspect --format {{.State.Pid}} )これで、次のように入力して、そのコンテナ環境内でシェルセッションを開くことができます。
sudo nsenter -t $PID -m -u -i -n -pコンテナ環境内でシェルセッションが提供されます。 ここから、ログを表示したり、その他の必要なトラブルシューティングを行うことができます。
コンテナの構築方法によっては、「+ bash 」が見つからなかったというメッセージが表示される場合があります。 この場合、コマンドの最後に追加することにより、一般的な ` sh +`シェルを使用する必要があります。
sudo nsenter -t $PID -m -u -i -n -p /bin/sh結論
これらは、CoreOSクラスターの問題のトラブルシューティングに使用できる手順のほんの一部です。 これらは、クラウド構成ファイルで発生する可能性のある問題を追跡し、サービスを正しくクラスター化して開始するマシンの機能のトラブルシューティングに役立ちます。 Dockerコンテナおよびサービス自体の問題を追跡することも、対象の別の領域です。
念頭に置いておくべき最も重要なことの1つは、システムに関する情報が多くなればなるほど、デバッグがはるかに簡単になることです。 各コンポーネントの役割と、それらがどのように相互作用してシステムが機能するのかをしっかりと把握しておくと役立ちます。 問題を突き止めようとして迷子になった場合は、CoreOSの基本について復習してください。