容器/Docker要点记录

开发日常都会接触到容器和docker，以下作记录：

实现原理

• 资源控制(CPU/Memory/IO等)：cgroups
• 资源隔离： Linux namespaces, chroot 等
• 存储原理： aufs, OverlayFS 等
• 容器边界安全：AppArmor, SELinux, seccomp
• 容器底层实现OCI：lxc, libcontainer, runc, containerd 等
• 容器运行时接口CRI：docker, cri-o，kata-containers, frakti 等
• 用c实现简单的容器环境

Dockerfile

• 采用和遵循multi-stage builds 做法, 编译和运行使用不同的基础镜像。
• 承接上一点，由于常规配置下（docker run不加任何参数），docker与宿主机高度隔离，此时docker运行环境的时区timezone等设置往往是空白的， 如FROM alpine:latest, 此时， 若应用逻辑依赖时间或时区, 如某golang程序：

loc, _     = time.LoadLocation("Asia/Shanghai")
t := time.Unix(t1, 0).In(loc)

则docker运行环境需要添加依赖:

FROM alpine:latest
RUN apk --no-cache tzdata

• 对于golang 开发的app,每次构建时均要下载依赖的dockerfile， 可使用goproxy加快依赖下载速度, 而其配置因go版本而异， 如go 1.12 ENV GOPROXY=https://goproxy.cn

• Docker 的入口程序与Kubernetes的入口程序

  • Dockerfile 用于制作镜像，可以在文件最后指定ENTRYPOINT作为镜像的入口程序，即pid为1的进程。
  • 在Kubernetes用于启动pod的yaml中，也可指定Command和Args作为Docker启动后的入口程序, 即pid为1的进程。
  • 若1号进程退出（尽管入口程序派生了其他后台进程），则Docker退出。
  • 若docker是通过docker run启动的，docker 会完成生命周期，docker进程会退出。
  • 若docker是通过Kubernetes deployment启动的，则pod中的docker在执行完入口程序后会退出，导致pod不断重启，入口程序反复执行。
  • 一般做法会在入口程序的最后添加类似shell的sleep infinity等语句阻止1号进程退出，使得1号进程派生的后台进程能持续服务。
  • Docker和Kubernetes入口程序先后关系:若在dockerfile和k8s中均指定入口程序，则有如下先后关系, 即使用Kubernetes 创建的docker若指定了Command，则该docker镜像的ENTRYPOINT会被覆盖， 相当于调用了docker run ... --entrypoint:

    If you do not supply command or args for a Container,
    the defaults defined in the Docker image are used.
    
    If you supply a command but no args for a Container,  only the supplied command is used. 
    The default EntryPoint and the default Cmd defined in the Docker image are ignored.
    
    If you supply only args for a Container, 
    the default Entrypoint defined in the Docker image is run with the args that you supplied.
    
    If you supply a command and args, 
    the default Entrypoint and the default Cmd defined in the Docker image are ignored. Your command is run with your args.

Docker daemon API

• 与docker daemon 通信