序章
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イメージにパスワードが設定されていないため、これには問題があります。
これを回避するには、次のパスワードエントリを含む新しい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
それが知っているマシン。 これがエラーなしで返される場合、それは 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 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
起動に使用するユニットファイル fleet
と etcd
. を見るには 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つの領域は、実行している実際のサービスです。 私たちが持っているので fleet
と fleetctl
クラスタ全体でサービスを管理するために、最初のステップはクラスタ内の任意のサーバーで実行できます。
まず、サービスの健全性について、両方の観点から把握することから始めます。 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
知っている。 この出力には、いくつかの非常に重要な情報が含まれています。 見てみましょう。
- UNIT :これはユニットの名前です。 この場合、上位6つのサービスはすべてインスタンスユニットであり(テンプレートとインスタンスの詳細についてはこちらをご覧ください)、下位は静的インスタンスのようです。 これらは、これらの各サービスに影響を与えるコマンドを発行するために使用できる名前です。
- HASH :これはこのサービスを制御するために使用されるユニットファイルのハッシュです。 ご覧のとおり、
apache-discovery
インスタンスは同じテンプレートファイルから生成されます。 Theapache
インスタンスはすべて別のインスタンスから生成されます。 これは、古いユニットファイルを使用して、サービスのいずれかが奇妙な動作を示しているかどうかを確認するのに役立ちます。 - DSTATE :これはユニットの望ましい状態です。 次のコマンドを発行すると
fleetctl
ユニットの状態を変更するには、この列が変更され、そのユニットの目的の状態が反映されます。 - STATE :これはユニットの実際の状態であり、
fleet
. これがDSTATEと異なる場合は、操作が失敗したことを意味している可能性があります。 - TARGET :このサービスを実行するようにスケジュールされているマシン。 これは、ユニットが起動またはロードされたときに使用可能になります。 これには、マシンIDとマシンのIPアドレスが含まれています。
ご覧のとおり、問題のデバッグに役立つ情報がかなりあります。
ただし、これだけが重要なチェック場所ではありません。 時々あることを認識することが重要です 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 status
と journalctl -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の基本を復習しておくと役立つ場合があります。