介绍
CoreOS引入了许多有趣的技术，使构建分布式系统变得容易。 然而，这些工具对于新用户可能是不熟悉的并且具有它们自己的偏心。 其中一个主要问题是在工作中有很多层抽象，并且很难确定问题发生的地方。
在本指南中，我们将讨论使用CoreOS主机，它们运行的Docker容器以及将一些不同部分组合在一起的服务管理工具的一些基本故障排除过程。
调试Cloud-Config文件
当集群无法正确启动时，新的和经验丰富的CoreOS用户遇到的最常见的问题之一是无效的云配置文件。
CoreOS要求在创建时将cloud-config文件传递到服务器。 它使用此文件中包含的信息来引导自身并启动或加入现有集群。 它还启动基本服务，并可以配置系统基本知识，例如用户和组。
一些事情要检查您的云配置文件：
- ？每一个云-config文件传递必须以“＃云配置”独站在第一行开始： 它以“＃云配置”开始 。 虽然这通常是YAML中忽略的注释，在这种情况下，此行用于向云初始系统发送信号，其中包含配置数据。
- 请问您的文件包含有效YAML：云配置文件都写在YAML，侧重于可读性数据序列化格式。 如果您有问题，粘贴您的云配置到在线YAML验证 。 您的文件应该不包含错误。 CoreOS提供了一个有用的工具，它可以检查你的云-config文件的语法， 云配置验证 。
- 您是否使用了新的发现令牌：发现地址，跟踪您的机器的数据，即使整个群集关闭。 当您使用旧令牌启动时，发现注册将失败，特别是如果您以前已注册过相同的IP地址。 每次启动集群时都使用一个新的发现令牌，以避免此问题。
- 你开始Fleet和ETCD服务：两个服务，这样才能保证您的群集正常工作的启动
fleet和etcd。 你应该看看我们的指南过得好DigitalOcean运行CoreOS集群为满足这些最低要求基本的云配置文件。
您只能在创建计算机时传入cloud-config文件，因此如果您犯了错误，请销毁服务器实例并重新启动（在大多数情况下使用新令牌）。
一旦你确定cloud-config文件本身是正确的，下一步是登录主机，以确保文件被正确处理。
这在大多数情况下应该很容易，因为在DigitalOcean上，您需要在创建过程中向服务器添加ssh密钥。 这意味着您通常可以ssh进入服务器进行故障排除没有问题。
通过DigitalOcean控制面板登录
但是，有些时候，您的云配置可能实际上影响您的服务器的网络可用性一旦启动。 在这种情况下，您必须通过DigitalOcean控制面板登录。 这提出了一个问题，因为默认情况下没有在CoreOS映像上设置密码，出于安全原因。
要解决此问题，必须重新创建与包含密码输入一个新的云-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"'
一旦你有一个哈希值，你可以添加一个新的部分，将云配置（以下简称“coreos”部分外），称为users放置这样的信息：
#cloud-config
users:
- name: core
passwd: hashed_password
coreos:
. . .
验证您的YAML语法 ，然后重新创建服务器时，使用这个新的云配置。 然后，您应该能够使用您选择的密码通过DigitalOcean控制面板登录。
检查个别主机
一旦你登录，有几件事情你应该检查，看看你的云配置是否正确处理。
检查基本服务中的错误
一个简单的方法，开始是问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处理云的配置文件，它会生成存根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被赋予了云配置一些元数据信息。 这可以用于在创建服务单元文件时进行调度。
检查元数据服务的访问权限
当使用DigitalOcean创建CoreOS服务器时给出的实际云配置文件是使用元数据服务存储的。 如果您在服务器上找不到任何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以获取有关您的服务器的信息。 您可以探索这里的每个条目附加卷曲的命令，而是包含云的配置文件中的一个是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
如果您可以从此位置读取您的云配置，这意味着您的服务器有能力读取云配置数据，并应在启动服务器时实施其说明。
疑难解答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-]三倍快。 你将被放回到主机的shell会话中。
从任何主机对服务进行故障排除
您可能需要进行故障排除的另一个方面是您正在运行的实际服务。 因为我们有fleet和fleetctl来管理我们的服务集群范围内，我们的第一个步骤，可以在任何在我们的集群中的服务器进行预制。
我们应该让你的服务的健康想法开始，无论是从的角度来看fleet ，并从已分配给运行每个服务的各个主机。 该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知道。 这个输出有一些非常重要的信息。 让我们来看看。
- 单元 ：这是单元的名称。 在我们的例子中，前六名的服务是所有的实例单位（找到更多有关模板和实例这里）和底部似乎是一个静态实例。 这些是我们可以用来发出影响这些服务的命令的名称。
- HASH：这是用来控制这个服务单位文件的哈希值。 正如你所看到的，所有的
apache-discovery实例从同一个模板文件产生了。 在apache情况下，都是从另外一个衍生。 这可以用于查看您的任何服务是否通过使用过期的单元文件来呈现奇怪的行为。 - 状态DState：这是单元的期望状态。 当你发出一个命令
fleetctl改变单元的状态，此列的变化，以反映该单位所需的状态。 - 状态 ：这是单位的实际状态，如众所周知的
fleet。 如果这不同于DSTATE，可能意味着操作失败。 - 目标 ：已计划运行此服务的计算机。 当一个单元被启动或加载时，这将是可用的。 它包含机器的机器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还）。
发出这些命令时可能遇到的一个错误是：
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
这将允许您正在访问的计算机使用您的凭据连接到集群中的其他计算机。 是什么让你阅读systemd从远程群集成员的信息。 它还允许你直接ssh到其他成员。
从运行服务的主机对容器进行故障排除
虽然你可以使用只能得到许多伟大的信息片段fleetctl ，有时你必须去那个负责运行排查服务的主机。
如上所述，当您在连接时转发SSH信息时，这很容易。 从主机连接你的话，你可以“跳”到用其他机器fleetctl 。 您可以指定机器ID，或只是服务名称。 该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
我们可以看到，目前有一个容器正在运行。 突出显示的容器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
要查看上次启动的容器中，无论其状态如何，您可以使用-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标志和一个shell会话），整个会议将在日志中可用。
您可以通过键入以下内容获取活动的任何容器的正在运行的进程的列表：
docker top container_id
在容器内产生Shell会话
最有用的步骤之一是实际上在正在运行的容器上打开一个shell会话，以查看从内部发生了什么。 要做到这一点，CoreOS附带了一个工具，叫做nsenter 。
Docker容器通过设置内核命名空间来工作，这个工具可以在这些环境中启动会话。 第一步是获取您想要输入的容器的PID：
PID=$(docker inspect --format {{.State.Pid}} container_id)
现在，您可以通过键入以下内容在该容器环境中打开一个shell会话：
sudo nsenter -t $PID -m -u -i -n -p
您将在容器环境中获得一个shell会话。 从这里，您可以查看日志或执行任何其他必要的故障排除。
根据构建容器的方式，你可能会得到一个消息，说bash没有被发现。 在这种情况下，你将不得不使用通用sh通过追加在你命令的末尾外壳：
sudo nsenter -t $PID -m -u -i -n -p /bin/sh
结论
这些只是可用于排除CoreOS集群问题的几个过程。 这些应用程序将帮助您跟踪您可能与您的云配置文件的问题，并解决您的机器的集群和正确启动服务的能力。 跟踪Docker容器和服务本身的问题是我们覆盖的另一个领域。
要记住的一个最重要的事情是，调试变得更容易更多的你有关于你的系统的信息。 有助于牢牢掌握每个组件的作用以及它们如何交互以帮助系统功能。 如果您在尝试跟踪问题时发现自己失去了，可能会对CoreOS基础知识有所帮助。
