開発者ドキュメント

CoreOSサーバーで一般的な問題をトラブルシューティングする方法

序章

CoreOSは、分散システムの構築を容易にするいくつかの興味深いテクノロジーを導入しています。 ただし、これらのツールは、新しいユーザーにはなじみがなく、独自の風変わりなものになる可能性があります。 主な問題の1つは、抽象化の多くの層が機能しており、問題が発生している場所を特定するのが難しい場合があることです。

このガイドでは、CoreOSホスト、それらが実行するDockerコンテナー、およびいくつかの異なる部分をまとめるサービス管理ツールを操作するためのいくつかの基本的なトラブルシューティング手順について説明します。

Cloud-Configファイルのデバッグ

クラスターが正しく起動しないときに、新規および経験豊富なCoreOSユーザーが遭遇する最も一般的な問題の1つは、無効なcloud-configファイルです。

CoreOSでは、作成時にcloud-configファイルをサーバーに渡す必要があります。 このファイルに含まれる情報を使用して、それ自体をブートストラップし、既存のクラスターを開始または参加します。 また、重要なサービスを開始し、ユーザーやグループなどのシステムの基本を構成できます。

cloud-configファイルで確認するいくつかの事項:

cloud-configファイルを渡すことができるのは、マシンが作成されたときだけです。そのため、間違えた場合は、サーバーインスタンスを破棄して、(ほとんどの場合、新しいトークンを使用して)再起動します。

cloud-configファイル自体が正しいことをかなり確信したら、次のステップは、ファイルが正しく処理されたことを確認するためにホストにログインすることです。

DigitalOceanでは、作成中にサーバーにsshキーを追加する必要があるため、これはほとんどの場合簡単です。 これは、通常、サーバーにSSH接続して、問題なくトラブルシューティングできることを意味します。

DigitalOceanコントロールパネルからログインする

ただし、クラウド構成が起動後にサーバーのネットワーク可用性に実際に影響を与える場合があります。 この場合、DigitalOceanコントロールパネルからログインする必要があります。 セキュリティ上の理由から、デフォルトではCoreOSイメージにパスワードが設定されていないため、これには問題があります。

これを回避するには、次のパスワードエントリを含む新しいcloud-configファイルを使用してサーバーを再作成する必要があります。 core ユーザー。 レクリエーションの要件があるため、これはおそらく、この問題を常に確認していて、より多くの情報を取得したい場合にのみ役立ちます。 トラブルシューティングを行うために、一般的な方法として、すべての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"'

ハッシュを取得したら、cloud-configに(「coreos」セクションの外に)次のような新しいセクションを追加できます。 users この情報を配置するには:

#cloud-config
users:
  - name: core
    passwd: hashed_password
coreos:
  . . .

YAML構文を検証し、サーバーを再度作成するときにこの新しいcloud-configを使用します。 これで、選択したパスワードを使用して、DigitalOceanコントロールパネルからログインできるようになります。

個々のホストを確認する

ログインしたら、cloud-configが正しく処理されたかどうかを確認するために確認する必要のあることがいくつかあります。

エッセンシャルサービスのエラーをチェックする

始める簡単な方法は尋ねることです fleetctl それが知っているマシン。 これがエラーなしで返される場合、それは fleetetcd 正しく開始され、他のホストと通信していること。

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 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ファイルを処理すると、スタブが生成されます systemd 起動に使用するユニットファイル fleetetcd. を見るには systemd 作成され、サービスの開始に使用されている構成ファイルを、ドロップされたディレクトリに移動します。

cd /run/systemd/system
ls -F
etcd.service.d/  fleet.service.d/  oem-cloudinit.service

あなたは一般化されたものを見ることができます oem-cloudinit.service CoreOSによって自動的に処理されるファイル、およびサービス情報が含まれるディレクトリ。 私たちはどのような情報を見ることができます 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 リダイレクトをフォローします。 The 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]
. . .

この環境内に必要なツールをインストールできます。 たとえば、インストールできます htop、Fedoraパッケージマネージャーを使用した、追加機能を備えたトップクローン:

yum install htop -y && htop

これにより、ホストのすべてのプロセスがロードされたプロセスモニターが表示されます。

コンテナ環境を終了するには、「exit」と入力するか、 CTRL-] 3倍速い。 ホストのシェルセッションに戻ります。

任意のホストからのサービスのトラブルシューティング

トラブルシューティングが必要になる可能性のあるもう1つの領域は、実行している実際のサービスです。 私たちが持っているので fleetfleetctl クラスタ全体でサービスを管理するために、最初のステップはクラスタ内の任意のサーバーで実行できます。

まず、サービスの健全性について、両方の観点から把握することから始めます。 fleet、および各サービスを実行するために割り当てられた個々のホストから。 The fleetctl ツールは、この情報を簡単に取得するためのコマンドを提供します。

まず、どのようにアイデアを得る fleet 次のように入力して、サービスの状態を確認します。

fleetctl list-unit-files
UNIT				HASH	DSTATE		STATE		TARGET
apache-discovery@4444.service	06d78fb	loaded		loaded		04856ec4.../10.132.249.212
apache-discovery@7777.service	06d78fb	loaded		loaded		197a1662.../10.132.249.206
apache-discovery@8888.service	06d78fb	loaded		loaded		e3ca8fd3.../10.132.252.37
apache@4444.service		0f7f53b	launched	launched	04856ec4.../10.132.249.212
apache@7777.service		0f7f53b	launched	launched	197a1662.../10.132.249.206
apache@8888.service		0f7f53b	launched	launched	e3ca8fd3.../10.132.252.37
nginx_lb.service		c8541af	launched	launched	96ec72cf.../10.132.248.177

これにより、すべてのサービスの概要がわかります。 fleet 知っている。 この出力には、いくつかの非常に重要な情報が含まれています。 見てみましょう。

ご覧のとおり、問題のデバッグに役立つ情報がかなりあります。

ただし、これだけが重要なチェック場所ではありません。 時々あることを認識することが重要です fleet マシンのローカルに同意しません systemd サービスの状態に関するインスタンス。 これは、あるユニットが別のユニットを内部で開始または停止した場合など、さまざまな理由で発生する可能性があります。

各サービスの状態に関する情報を取得するには、 systemd そのサービスを実行しているホストのインスタンス、 list-units 代わりにコマンド:

fleetctl list-units
UNIT				MACHINE				ACTIVE	SUB
apache-discovery@4444.service	04856ec4.../10.132.249.212	active	running
apache-discovery@7777.service	197a1662.../10.132.249.206	active	running
apache-discovery@8888.service	e3ca8fd3.../10.132.252.37	active	running
apache@4444.service		04856ec4.../10.132.249.212	active	running
apache@7777.service		197a1662.../10.132.249.206	active	running
apache@8888.service		e3ca8fd3.../10.132.252.37	active	running
nginx_lb.service		96ec72cf.../10.132.248.177	active	running

ここでは、すべてのサービスが実行中としてリストされていることがわかります。 これは、次の情報と一致しません list-unit-files ショー。 それは、それぞれが apache サービスは関連するを起動します apache-discovery させずにサービス fleet 知る。 これはエラーではありませんが、サービスの実際の状態について混乱を引き起こす可能性があります。

いずれかのサービスに関する詳細情報を取得するには、次を使用できます。 fleetctl ホストシステムにアクセスするには systemctl statusjournalctl -u 情報。 次のように入力するだけです。

fleetctl status service_name
● apache@4444.service - Apache web server service on port 4444
   Loaded: loaded (/run/fleet/units/apache@4444.service; 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/apache@4444.service
           └─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エージェントに秘密鍵へのアクセスが許可されたら、次のコマンドを使用してCoreOSホストに接続する必要があります。 -A この情報を転送するオプション:

ssh -A core@coreos_host

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

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

だけでたくさんの素晴らしい情報を得ることができますが fleetctl、場合によっては、トラブルシューティングのためにサービスの実行を担当するホストに移動する必要があります。

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

fleetctl ssh service_name

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

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

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

モバイルバージョンを終了