azure - 在 azure 上创建 ejbca docker 容器时出现 containerd 错误 "failed to find user by uid"

Question

当我尝试为 EJBCA-ce 创建 Azure 容器实例时我收到一个错误，看不到任何日志。
我期待以下结果:

但我收到以下错误:
Failed to start container my-azure-container-resource-name, Error response: to create containerd task: failed to create container e9e48a_________ffba97: guest RPC failure: failed to find user by uid: 10001: expected exactly 1 user matched '0': unknown一些背景:
我在 azure 云容器实例上运行容器
我试过

来自ARM模板

来自 Azure 门户。

已安装文件共享

带有数据库环境变量

没有任何环境变量

它使用相同的环境变量(数据库配置)在本地运行良好。
几周前，它曾经以相同的配置运行。
以下是我从 az cli 附加容器组时得到的一些日志。

(count: 1) (last timestamp: 2020-11-03 16:04:32+00:00) pulling image "primekey/ejbca-ce:6.15.2.3"
(count: 1) (last timestamp: 2020-11-03 16:04:37+00:00) Successfully pulled image "primekey/ejbca-ce:6.15.2.3"
(count: 28) (last timestamp: 2020-11-03 16:27:52+00:00) Error: Failed to start container aci-pulsy-ccm-ejbca-snd, Error response: to create containerd task: failed to create container e9e48a06807fba124dc29633dab10f6229fdc5583a95eb2b79467fe7cdffba97: guest RPC failure: failed to find user by uid: 10001: expected exactly 1 user matched '0': unknown

the dockerfile from dockerhub 的摘录
我怀疑该问题可能与命令 USER 0 有关和 USER 10001我们在 dockerfile 中发现了几次。

COPY dir:89ead00b20d79e0110fefa4ac30a827722309baa7d7d74bf99910b35c665d200 in /
/bin/sh -c rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
CMD ["/bin/bash"]
USER 0
COPY dir:893e424bc63d1872ee580dfed4125a0bef1fa452b8ae89aa267d83063ce36025 in /opt/primekey
COPY dir:756f0fe274b13cf418a2e3222e3f6c2e676b174f747ac059a95711db0097f283 in /licenses
USER 10001
CMD ["/opt/primekey/wildfly-14.0.1.Final/bin/standalone.sh" "-b" "0.0.0.0"
MAINTAINER PrimeKey Solutions AB
ARG releaseTag
ARG releaseEdition

ARM模板

{
      "type": "Microsoft.ContainerInstance/containerGroups",
      "apiVersion": "2019-12-01",
      "name": "[variables('ejbcaContainerGroupName')]",
      "location": "[parameters('location')]",
      "tags": "[variables('tags')]",
      "dependsOn": [
        "[resourceId('Microsoft.DBforMariaDB/servers', variables('ejbcaMariadbServerName'))]",
        "[resourceId('Microsoft.DBforMariaDB/servers/databases', variables('ejbcaMariadbServerName'), variables('ejbcaMariadbDatabaseName'))]"
      ],
      "properties": {
        "sku": "Standard",
        "containers": [
          {
            "name": "[variables('ejbcaContainerName')]",
            "properties": {
              "image": "primekey/ejbca-ce:6.15.2.3",
              "ports": [
                {
                  "protocol": "TCP",
                  "port": 443
                },
                {
                  "protocol": "TCP",
                  "port": 8443
                }
              ],
              "environmentVariables": [

                {
                  "name": "DATABASE_USER",
                  "value": "[concat(parameters('mariadbUser'),'@', variables('ejbcaMariadbServerName'))]"
                },
                {
                  "name": "DATABASE_JDBC_URL",
                  "value": "[variables('ejbcaEnvVariableJdbcUrl')]"
                },
                {
                  "name": "DATABASE_PASSWORD",
                  "secureValue": "[parameters('mariadbAdminPassword')]"
                }
              ],
              "resources": {
                "requests": {
                  "memoryInGB": 1.5,
                  "cpu": 2
                }
              }
              ,
               "volumeMounts": [
                 {
                   "name": "certificates",
                   "mountPath": "/mnt/external/secrets"
                 }
               ]
            }
          }
        ],
        "initContainers": [],
        "restartPolicy": "OnFailure",
        "ipAddress": {
          "ports": [
                {
                  "protocol": "TCP",
                  "port": 443
                },
                {
                  "protocol": "TCP",
                  "port": 8443
                }
          ],
          "type": "Public",
          "dnsNameLabel": "[parameters('ejbcaContainerGroupDNSLabel')]"
        },
        "osType": "Linux",
         "volumes": [
           {
             "name": "certificates",
             "azureFile": {
               "shareName": "[parameters('ejbcaCertsFileShareName')]",
               "storageAccountName": "[parameters('ejbcaStorageAccountName')]",
               "storageAccountKey": "[parameters('ejbcaStorageAccountKey')]"
             }
           }
         ]
      }
    }

它在我的本地机器上的 linux (ubuntu 20.04) 上运行良好

docker run -it --rm -p 8080:8080 -p 8443:8443 -h localhost -e DATABASE_USER="mymaridbuser@my-db" -e DATABASE_JDBC_URL="jdbc:mariadb://my-azure-domain.mariadb.database.azure.com:3306/ejbca?useSSL=true" -e DATABASE_PASSWORD="my-pwd" primekey/ejbca-ce:6.15.2.3

Answer 1

在 EJBCA-ce 容器镜像中，我认为他们试图提供一个不同于 root 的用户。运行 EJBCA 服务器。根据Docker documentation :

The USER instruction sets the user name (or UID) and optionally the user group (or GID) to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile

在 Dockerfile他们引用了两个用户， root , 对应 UID 0 ，以及另一个，UID 10001 .
通常，在 Linux 和 UNIX 系统中，UID 可以按不同的范围组织:它很大程度上取决于具体的操作系统和用户管理实践，但很有可能在 linux 系统中创建的第一个用户帐户将分配给 UID 1001或 10001 ，就像在这种情况下。请参阅例如 UID entry in wikipedia或 this article .
AFAIK， USER指示不需要存在于您的容器中以正确运行它:事实上，如果您在本地运行它，它将毫无问题地启动。
具有 UID 的用户 10001将通过在 CMD 中运行的脚本在您的容器中实际设置在 Dockerfile 中定义, /opt/primekey/bin/start.sh ，通过这个代码片段:

if ! whoami &> /dev/null; then
  if [ -w /etc/passwd ]; then
    echo "${APPLICATION_NAME}:x:$(id -u):0:${APPLICATION_NAME} user:/opt:/sbin/nologin" >> /etc/passwd
  fi
fi

请注意， APPLICATION_NAME在这种情况下，取值 ejbca以及运行此脚本的用户，如 Dockerfile 中所示, 是 10001 .这将是命令 id -u 提供的值在这段代码中。
如果您在本地运行容器，则可以验证它:

docker run -it -p 8080:8080 -p 8443:8443 -h localhost primekey/ejbca-ce:6.15.2.3

并发起 bash进去:

 docker exec -it container_name /bin/bash

如果您运行 whoami ，它会告诉你 ejbca .
如果您运行 id它将为您提供以下输出:

uid=10001(ejbca) gid=0(root) groups=0(root)

您可以在 /etc/passwd 中验证用户是否存在还有:

bash-4.2$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
ejbca:x:10001:0:ejbca user:/opt:/sbin/nologin

Pierre 没有得到这个输出的原因是因为他运行容器覆盖了提供的 CMD因此，不执行 start.sh如上所述，负责创建用户的脚本。
出于任何原因，这就是我的知识失败的地方，当 Azure 尝试运行您的容器时，它失败了，因为 USER 10001在 Dockerfile 中确定不存在。
我认为这可能与 containerd 的使用有关。而不是 docker .
Azure 报告的错误似乎与微软项目 opengcs 有关.
他们说这个项目:

Open Guest Compute Service is a Linux open source project to further the development of a production quality implementation of Linux Hyper-V container on Windows (LCOW). It's designed to run inside a custom Linux OS for supporting Linux container payload.

和:

The focus of LCOW v2 as a replacement of LCOW v1 is through the coordination and work that has gone into containerd/containerd and its Runtime V2 interface. To see our containerd hostside shim please look here Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1.

您在控制台中看到的错误是 raised由 spec.go您可以在他们的代码库中找到的文件，当他们尝试建立代表应该运行容器进程的用户时:

func setUserID(spec *oci.Spec, uid int) error {
    u, err := getUser(spec, func(u user.User) bool {
        return u.Uid == uid
    })
    if err != nil {
        return errors.Wrapf(err, "failed to find user by uid: %d", uid)
    }
    spec.Process.User.UID, spec.Process.User.GID = uint32(u.Uid), uint32(u.Gid)
    return nil
}

此代码由其他代码片段执行 - 您可以看到 full function code here :

parts := strings.Split(userstr, ":")
switch len(parts) {
case 1:
    v, err := strconv.Atoi(parts[0])
    if err != nil {
        // evaluate username to uid/gid
        return setUsername(spec, userstr)
    }
    return setUserID(spec, int(v))

和 getUser 功能:

func getUser(spec *oci.Spec, filter func(user.User) bool) (user.User, error) {
    users, err := user.ParsePasswdFileFilter(filepath.Join(spec.Root.Path, "/etc/passwd"), filter)
    if err != nil {
        return user.User{}, err
    }
    if len(users) != 1 {
        return user.User{}, errors.Errorf("expected exactly 1 user matched '%d'", len(users))
    }
    return users[0], nil
}

如您所见，这些正是 Azure 报告给您的错误。
总之，我认为他们提供了符合 OCI Image Format Specification 的 Windows LCOW 解决方案。适合使用 containerd 运行容器.
正如您所指出的，它是否曾经在几周前以相同的配置运行，我最好的客人是，也许，他们从纯 Linux 切换了您的容器 containerd基于 Windows 和上述软件的运行时实现，这就是容器现在失败的原因。
一种可能的解决方法是基于 PrimeKey 提供的官方创建自定义图像并创建用户 10001 ，正如皮埃尔指出的那样。
要完成此任务，首先，创建一个新的自定义 Dockerfile .例如，您可以尝试:

FROM primekey/ejbca-ce:6.15.2.3

USER 0

RUN echo "ejbca:x:10001:0:ejbca user:/opt:/sbin/nologin" >> /etc/passwd

USER 10001

请注意，您可能需要从官方 EJBCA 镜像中定义一些环境变量。
有了这个 Dockerfile您可以使用 docker 构建您的图像或 docker compose 与一个适当的 docker-compose.yaml文件，类似于:

version: "3"

services:
  ejbca:
    image: <your repository>/ejbca
    build: .
    ports:
      - "8080:8080"
      - "8443:8443"

请按照您认为合适的方式对其进行自定义。
通过这种设置，新容器仍将在本地环境中以与原始容器相同的方式正常运行:我希望在 Azure 中也是如此。