Linuxkit YAML配置文件参考

2019独角兽企业重金招聘Python工程师标准>>>

Linuxkit YAML配置文件参考

 moby 工具组装一系列容器化的组件到系统镜像之中。最简单的镜像就是一个 tar 文件 (可用于调试)，但更有用的输出是添加一个 Dockerfile 来构建一个容器。 也可以构建一个完整的磁盘镜像。可以启动linuxKit 为一个虚拟机。最主要的应用场景是组装一个包含 containerd 的镜像来运行一系列容器，但是这个工具本身是完全通用的。

配置文件 yaml 指明了构建一个 image 需要的组件。所有的组件在构建时自动下载，构建出的 image 是容器化、自我包含的、不可更改的，因此可以被持续交付、可靠地测试。

配置文件处理的顺序是 kernel, init, onboot, onshutdown, services, files. 每一段都会添加文件到root file system。 Sections是可以减省的。

每一个指定容器都会被分配唯一的 uid 和 gid ，在如果希望运行为隔离的用户（独立用户空间）时有用。任何地方指定 uid 或 gid 域时都是数字ID，当使用name时，都将引用该名称容器所分配的ID。

services:
  - name: redis
    image: redis:latest
    uid: redis
    gid: redis
    binds:
     - /etc/redis:/etc/redis
files:
  - path: /etc/redis/redis.conf
    contents: "..."
    uid: redis
    gid: redis
    mode: "0600"

kernel

kernel 段是启动一个VM的唯一要求。文件将会放入 boot/ 目录, 用于创建可启动的镜像。    

kernel 段定义了 kernel 的配置。 image 域指定了Docker image, 应该包含 kernel 文件能够用于启动 (如 bzImage for amd64) 和一个文件 kernel.tar ，该文件是一个tar文件展开到root，应该通常包含一个kernel modules 目录。 cmdline 指定  kernel 的命令行选项，如果需要的话。

为了覆盖名称，你可以指定 kernel image 名称为 binary: bzImage 以及 tar image 为 tar: kernel.tar 或者空字符串或者 none ，如果完全不想使用 tarball的话。

init

init 段是images列表，用于 init system，并且直接展开到root filesystem。这将运行 containerd，启动system和daemon容器, 以及设置基本的文件系统挂载。在LinuxKit system，为了易于修改 runc 和 containerd images, 只包含基本的运行程序。

onboot

onboot 段是images列表，在任何其它的images之前运行。顺序执行，而且下一个执行之前上一个必须退出。这些 images可以用于配置设置，查看 Image specification 了解支持的配置参数域。

onshutdown

是images列表，在退出时执行清理工作，如保存状态。需要注意，你不能完全依靠这些，因为机器可能被强制断电，因而没有时间来执行这些操作。如果添加这些服务，你需要测试哪些情况下有效，在哪些情况下无效。

services

services 段是images列表，一直运行，由 containerd来进行管理。启动的顺序是不确定的，因此容器应该等待任何需要的资源可用, 如网络。查看 Image specification 获取更详细的支持域信息。

files

files 段用于添加多个文件，可能位于config的内嵌, 或者来自于外部文件。

files:
  - path: dir
    directory: true
    mode: "0777"
  - path: dir/name1
    source: "/some/path/on/local/filesystem"
    mode: "0666"
  - path: dir/name2
    source: "/some/path/that/it/is/ok/to/omit"
    optional: true
    mode: "0666"
  - path: dir/name3
    contents: "orange"
    mode: "0644"
    uid: 100
    gid: 100

指定 mode 是可选的, 缺省为 0600. 前导目录如果没有被指定，将会创建。可以在 source 使用 ~/path 指定相对目录。

除此之外，metadata 选项将会创建文件。目前支持的值只有 "yaml" ，将输出 yaml 用于创建镜像到特定的文件。

  - path: etc/linuxkit.yml
    metadata: yaml

缺省情况下，因为一个 tmpfs 挂载到 /var, /run, 和 /tmp ， 这个 tmpfs 将映射任何在 files 段中指定的目录。

trust

trust 段指定那些build组件将会被加密验证，该操作使用 Docker Content Trust ，进行镜像拉取之前进行。 Trust在任何构建系统都是都是中心化的操作，LinuxKit也不例外: Docker Content Trust 提供 authenticity, integrity, 和 freshness guarantees，对组件进行验证。LinuxKit maintainers 应该负责对 linuxkit 组件进行签名，协作者可以使用 Docker Content Trust 或者 Notary对自己的镜像进行签名、验证。

• image 列出强制需要 Docker Content Trust验证才拉取的镜像。image name可以包含tag或者 digest，but the matching also succeeds if the base image name is the same.
• org 列出Docker Content Trust 应用于所有镜像的组织机构，如 linuxkit 是 org for linuxkit/kernel

Image 属性域

在 onboot 和 services 段指定OCI image 和选项。缺省值可以通过使用 org.mobyproject.config image label指定，更多的细节参考 OCI specification。

如果 org.mobylinux.config label 在 image中设置, 指明那些在yaml文件未设置的缺省值。你可以设置这些值予以覆盖，或者指定为空值来清除缺省值。

如果你需要 OCI option 但是在这里没有说明，请发起一个 issue 或者 pull request ，因为这个列表目前还没有完成。

缺省情况下，containers 运行在宿主机的 net, ipc 和 uts namespaces, 这是通常的要求; 在大部分情况下，行为类似于Kubernetes的pods。Mount points 必须已经存在, file 或 directory 必须绑定挂载到container。

• name 程序执行的唯一名称, 如同 containerd id。
• image Docker image，用于root filesystem。缺省command, path 和 environment从这里提取。
• capabilities Linux capabilities 要求, 例如 CAP_SYS_ADMIN。如果为 all 则所有都添加。
• ambient Linux ambient capabilities (capabilities 传递给非 root users) 。
• mounts 指定挂载的完整形式, 要求 type, source, destination 和 options 列表。如果一个域缺失，缺省值将自动应用。例如，如果 type 是 dev 被假定，那么缺省的挂载就是 /dev. 这个缺省的挂载和其选项可以通指定新的选项被覆盖。
• binds 是指定bind mounts的简单接口, 接受 /src:/dest:opt1,opt2 参数，与Docker中 -v 选项的挂载类似。
• tmpfs 是挂载 tmpfs的简单接口，类似Docker的 --tmpfs , 参数形式 /dest:opt1,opt2。
• command 将覆盖镜像的command 和 entrypoint，以 commands列表形式给出。
• env 将覆盖镜像的环境变量，通过新的环境变量列表给出，指定变量格式为 VAR=value。
• cwd 设定当前工作目录, 缺省为 /.
• net 设定network namespace, either to a path, or if none or new is specified it will use a new namespace.
• ipc 设定 ipc namespace, either to a path, 如果为 new 将使用新的 namespace。
• uts 设定 uts namespace, either to a path, 如果为 new 将使用新的 namespace。
• pid 设定 pid namespace, either to a path, 如果为 new 将使用新的 host namespace。
• readonly 设定root filesystem 为只读, 并且改变其他的缺省文件系统为只读。
• maskedPaths 设定将被隐藏的路径。
• readonlyPaths 设定只读的路径。
• uid 设定该进程的user id 。
• gid 设定该进程的group id。
• additionalGids 设定该进程的 a list of additional groups。
• noNewPrivileges 设为 true 意味着没有更多的capabilities可以被acquired，以及 suid binaries do not work.
• hostname 设定 image 里的主机名。
• oomScoreAdj 改变 OOM score。
• rootfsPropagation 设置 rootfs propagation, 如 shared, slave 或 (default) private.
• cgroupsPath 设置 path for cgroups.
• resources 设置 cgroup resource limits as per the OCI spec.
• sysctl 设置 a list of sysctl key value pairs that are set inside the container namespace.
• rmlimits 设置 a list of rlimit values in the form name,soft,hard, eg nofile,100,200. You can use unlimited as a value too.

这里还有实验状态的 userns, uidMappings 和 gidMappings 选项，针对 user namespaces 但是还没有支持，如果使用的话可能会有 permissions issues 。

除了上面创建 OCI spec的参数之外, 这里还有 runtime 段在 image specification，指定在容器被启动时会有哪些行为将采取。

• cgroups 是cgroups的列表，在容器运行之前创建。
• mounts 是mount specifications (source, destination, type, options) 的列表，在容器创建之前挂载到 root namespace。将尝试创建任何缺失的目标目录。
• mkdir 在运行时创建的目录的列表, 在root mount namespace。在 container 启动后创建, 因此可用于创建bind mount的目录，例如在 /tmp 或 /run ，要不将是空值。
• interface 定义一系列动作，在network interface上执行：
  • name 指定interface 名称。如果该名称的interface已经存在，将被移到  container's network namespace。
  • add 指定所要创建 interface的类型，以指定的名称在containers namespace中创建。
  • createInRoot 是 boolean型，指定 interface 是否首先创建在root namespace, 然后移动。这对 wireguard interfaces是需要的。
  • peer 当创建一个 veth interface时指定对端的名称。 这将保留在root namespace, 再次被 attached到bridge。指定通过 add: veth。
• bindNS 指定namespace type 和path，该path是容器被创建和将要绑定的 namespace from the 。这将允许namespace 在 onboot container被设定, 然后使用 net: path 为 service container 提供服务。

一个使用 runtime 配置的例子。使用 wireguard 配置network namespace，然后运行 nginx 在那个namespace，如下：

onboot:
  - name: dhcpcd
    image: linuxkit/dhcpcd:<hash>
    command: ["/sbin/dhcpcd", "--nobackground", "-f", "/dhcpcd.conf", "-1"]
  - name: wg
    image: linuxkit/ip:<hash>
    net: new
    binds:
      - /etc/wireguard:/etc/wireguard
    command: ["sh", "-c", "ip link set dev wg0 up; ip address add dev wg0 192.168.2.1 peer 192.168.2.2; wg setconf wg0 /etc/wireguard/wg0.conf; wg show wg0"]
    runtime:
      interfaces:
        - name: wg0
          add: wireguard
          createInRoot: true
      bindNS:
        net: /run/netns/wg
services:
  - name: nginx
    image: nginx:alpine
    net: /run/netns/wg
    capabilities:
     - CAP_NET_BIND_SERVICE
     - CAP_CHOWN
     - CAP_SETUID
     - CAP_SETGID
     - CAP_DAC_OVERRIDE

Mount 选项

当挂载 filesystem paths 到container - 无论作为 onboot 或者 services 的一部分- 这里有几个选项你必须知道。为了容器的正常发挥作用，正确地使用是必须的。

对于大部分containers-如nginx甚至docker-这些选项不是都需要的。简单地如下设置就能工作的很好：

binds:
 - /var:/some/var/path

请注意， binds 并不增加挂载点, 但是 replaces 它们。你可以检查 Dockerfile 中的这些组件(尤其是,  org.mobyproject.config 标签的binds ) 获得已存在的 binds的完整列表。

但是, 在某些情况下你可能需要额外的options。这些选项主要用于在容器内部需要对挂载点作出改变，而在容器外面可见。譬如，你想要在容器中挂载一个外部磁盘，但是容器外面也可以看见。

为了在容器中的新的挂载被传播，需要在容器设置：

1. rootfsPropagation: shared
2. 在容器下的挂载点必须标为 rshared,rbind。实践中, 这是 /var (或者 /var的子目录), 因为这是 文件系统读写区唯一的可以挂载的地方。

如此, 如果你有一个只是读写的通用container，按照如下设置：

binds:
 - /var:/some/var/path

从另一方面来讲，如果你有一个容器即将创建新的挂载，并且希望该挂载在容器外可以看见，使用：

binds:
 - /var:/var:rshared,rbind
rootfsPropagation: shared

• 转请注明来源：https://my.oschina.net/u/2306127/blog/1600526

转载于:https://my.oschina.net/u/2306127/blog/1600526