如何在容器中对镜像进行操作

Docker VS Podman

由于只需要对镜像进行 pull、tag、push 操作,因此不需要全套的 Docker 服务,这里选择了 Podman。Podman 有一个子命令就是 buildah,它主要负责镜像相关的操作,这样会更加精简。

问题描述

在镜像中添加完 buildah 的依赖后,在容器中运行 buildah 时,报如下错误:

现象

解决方案

此问题的其中一个解决方案为:在宿主机中,修改 /proc/sys/user/max_user_namespaces 文件里面的值。但若采取此种方案,会导致线上环境 K8S 所在的宿主机,可能也要修改,这样的操作是不太可行的。

同事的踩坑经验:可以在 k8s 的 yaml 配置中,为 pod 开启特权模式,这样可以避免使用 user namespace。在 pod 定义处,添加配置,修改如下:

securityContext: 
    privileged: true

修改后,buildah 在容器中不再报错。但对上面的修改,一方面持有安全疑虑,另一方面不太明白其中的原理。

为什么

为什么在本地的 K8S 环境中 rosco 执行没有问题?

图片

为什么将 pod 设置成特权模式之后便能正常执行 buildah?

  • 一篇比较具有参考价值的相关 issue。通过上述 issue 得知,即使使用 root 启动 buildah ,还是需要 user namespace 来获取相应的 capabilities
  • privileged 参数应该是会添加所有的 capabilities 到容器中(参考Docker文档)。

如何改进

只给 buildah 所需的 Linux capabilities,初步验证在 testing 运行 ok。

securityContext: 
  # privileged: true
  capabilities:
    add:
      - "SYS_ADMIN"

其中 CAP_SYS_ADMIN 的作用是:允许执行系统管理任务,如加载或卸载文件系统、设置磁盘配额等。

Read more

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd