如何解决CoreOS服务器的常见问题

介绍

CoreOS 引入了许多有趣的技术，使构建分布式系统变得容易。但是，这些工具对于新用户来说可能并不熟悉，并且有自己的怪癖。主要问题之一是工作中有许多抽象层，很难确定问题发生在哪里。

在本指南中，我们将介绍使用 CoreOS 主机、它们运行的 Docker 容器以及将一些不同部分组合在一起的服务管理工具的一些基本故障排除过程。

调试您的 Cloud-Config 文件

当集群无法正确启动时，CoreOS 新用户和有经验的用户遇到的最常见问题之一是无效的云配置文件。

CoreOS 要求在创建时将云配置文件传递到您的服务器。它使用此文件中包含的信息来引导自身并启动或加入现有集群。它还启动基本服务，并可以配置系统基础知识，例如用户和组。

需要检查您的 cloud-config 文件的一些事项：

是否以“#cloud-config”开头？：传入的每个cloud-config文件都必须以“#cloud-config”开头，单独位于第一行。虽然这通常是 YAML 中被忽略的注释，但在这种情况下，此行用于向云初始化系统发出信号，表明它包含配置数据。
您的文件是否包含有效的 YAML？：云配置文件是用 YAML 编写的，这是一种注重可读性的数据序列化格式。如果您遇到问题，请将您的云配置粘贴到在线 YAML 验证器中。您的文件不应包含任何错误。 CoreOS 提供了一个有用的工具，可以检查您的 cloud-config 文件的语法，Cloud-Config Validator。
Are you Using a fresh discovery token？：即使整个集群宕机，发现地址也会跟踪你机器的数据。当您使用旧令牌启动时，发现注册将失败，特别是如果您之前已经注册了相同的 IP 地址。每次启动集群时使用新的发现令牌以避免此问题。
您是否正在启动队列和 etcd 服务？：为了使您的集群正常运行，必须启动两个服务是 fleet 和 etcd。您应该查看我们关于获取在 DigitalOcean 上运行的 CoreOS 集群的指南，以获得满足这些最低要求的基本云配置文件。

您只能在创建机器时传入 cloud-config 文件，因此如果您犯了错误，请销毁服务器实例并重新启动（大多数情况下使用新令牌）。

一旦您相当确定 cloud-config 文件本身是正确的，下一步就是登录主机以确保文件得到正确处理。

在大多数情况下，这应该很容易，因为在 DigitalOcean 上，您需要在创建期间将 ssh 密钥添加到服务器。这意味着您通常可以通过 ssh 进入服务器进行故障排除而不会出现问题。

通过 DigitalOcean 控制面板登录

但是，在某些时候，您的云配置实际上可能会在启动后影响服务器的网络可用性。在这种情况下，您必须通过 DigitalOcean 控制面板登录。这带来了一个问题，因为出于安全原因，默认情况下没有在 CoreOS 映像上设置密码。

要解决此问题，您必须使用新的 cloud-config 文件重新创建服务器，该文件包含 core 用户的密码条目。由于娱乐要求，这可能仅在您一直看到此问题并希望获得更多信息时才有用。作为常规做法，您可能希望将密码信息添加到所有云配置文件中，以便进行故障排除。您可以在验证连接后手动取消设置密码。

密码必须采用哈希的形式。您可以根据可用的软件以几种不同的方式生成这些。以下任何一项都可以使用，因此请使用最适合您的选项：

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 机器处理 cloud-config 文件时，它会生成存根 systemd 单元文件，用于启动 fleet 和 etcd。要查看已创建并用于启动服务的 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 地址与我们在日志中发现的错误相匹配：末尾没有附加发现令牌。我们需要使用具有有效发现令牌的云配置来改造我们的机器。

您可以通过键入以下内容获得有关 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 中被赋予了一些元数据信息。这可用于在您创建服务单元文件时进行调度。

检查对元数据服务的访问

使用 DigitalOcean 创建 CoreOS 服务器时给出的实际云配置文件是使用元数据服务存储的。如果您无法在您的服务器上找到您的云配置的任何证据，则它可能无法从 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 地址将用于 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

如果您可以从该位置读取您的云配置，则意味着您的服务器具有读取云配置数据的能力，并且应该在启动服务器时执行其指令。

对 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-]。您将被退回到主机的 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 知道的所有服务。这个输出有一些非常重要的信息。让我们来看看。

UNIT：这是单位的名称。在我们的例子中，前六个服务都是实例单元（在此处找到有关模板和实例的更多信息），底部似乎是一个静态实例。这些是我们可以用来发出影响这些服务的命令的名称。
HASH：这是用于控制此服务的单元文件的哈希值。如您所见，所有 apache-discovery 实例都是从同一个模板文件中生成的。 apache 实例都是从另一个实例中产生的。这对于通过使用过期的单元文件来查看您的任何服务是否表现出奇怪的行为很有用。
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 服务都会在不让 fleet 知道的情况下启动关联的 apache-discovery 服务。这不是错误，但可能会导致对服务的实际状态产生混淆。

要获取有关任何服务的更多信息，您可以使用 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 代理被授予访问您的私钥的权限，您应该使用 -A 选项连接到您的 CoreOS 主机，以 forward 此信息：

ssh -A core@coreos_host

这将允许您通过 ssh 连接的机器使用您的凭据连接到集群中的其他机器。它允许您从远程集群成员读取 systemd 信息。它还允许您直接 ssh 到其他成员。

从运行服务的主机排查容器问题

尽管仅使用 fleetctl 可以获得许多重要信息，但有时您必须前往负责运行该服务的主机进行故障排除。

如上所述，当您在连接时转发了 SSH 信息时，这很容易。从您连接的主机，您可以使用 fleetctl “跳”到其他机器。您可以指定机器 ID，也可以只指定服务名称。 fleetctl 进程足够聪明，可以知道您指的是哪个主机：

fleetctl ssh service_name

这将为您提供与分配给运行该服务的主机的 ssh 连接。服务必须处于“加载”或“启动”状态才能正常工作。

从这里，您将可以访问所有本地故障排除工具。例如，您可以通过 fleetctl journal 命令访问更完整的 journalctl 标志集：

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

要查看已启动的 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 标志和 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 shell，方法是在命令末尾附加：

sudo nsenter -t $PID -m -u -i -n -p /bin/sh

结论

这些只是可用于解决 CoreOS 集群问题的几个过程。这些应该可以帮助您跟踪您的云配置文件可能遇到的问题，并解决您的机器集群和正确启动服务的能力。跟踪 Docker 容器和服务本身的问题是我们涵盖的另一个领域。

要记住的最重要的事情之一是，您对系统的了解越多，调试就越容易。牢牢掌握每个组件的作用以及它们如何交互以帮助系统运行会很有帮助。如果您在尝试追查问题时发现自己迷失了方向，那么让自己复习一下 CoreOS 基础知识可能会有所帮助。