容器服务Docker&Kubernetes + 关注
手机版

《自己动手写Docker》书摘之四: 构造简单容器

  1. 云栖社区>
  2. 容器服务Docker&Kubernetes>
  3. 博客>
  4. 正文

《自己动手写Docker》书摘之四: 构造简单容器

xianlubird 2016-11-29 20:17:28 浏览4754 评论0

摘要: 构造简单容器 本章我们即将开始真正踏上构造自己的容器道路上。我们会基于当前的操作系统创建一个与宿主机隔离的容器环境,并且配置上基本的文件系统与网络。最后会在容器内运行一些应用来使用我们的容器,是不是很激动,下面我们开始吧。

构造简单容器

本章我们即将开始真正踏上构造自己的容器道路上。我们会基于当前的操作系统创建一个与宿主机隔离的容器环境,并且配置上基本的文件系统与网络。最后会在容器内运行一些应用来使用我们的容器,是不是很激动,下面我们开始吧。

Linux proc 文件系统介绍

在开始之前,我们还是需要稍微补充一些基本知识,如果你已经对于这些基本知识很熟悉,请直接略过。Linux 下的/proc 文件系统是由内核提供,它其实不是一个真正的文件系统,只包含了系统运行时信息(比如系统内存,mount 设备信息,一些硬件配置等等,它只存在于内存中,而不占用外存空间。它是以文件系统的形式为访问内核数据的操作提供接口。实际上,很多系统工具都是简单去读取这个文件系统的某个文件内容,比如lsmod 其实就是 cat /proc/modules

当你去遍历这个目录的时候会发现很多数字,这些都是为每个进程创建的空间,数字就是他们的 PID。

:~# ls /proc/
1      1216   1320   154  20006  22     27462  32     37   44   51  60   78   868  acpi       devices      interrupts  keys           meminfo       sched_debug  sys            version_signature
10     12180  1336   155  20007  23     27478  32025  38   45   52  61   780  896  buddyinfo  diskstats    iomem       kmsg           misc          schedstat    sysrq-trigger  vmallocinfo
100    12192  13567  16   20008  24     28     33     387  47   53  62   8    9    bus        dma          ioports     kpagecount     modules       scsi         sysvipc        vmstat
10684  12728  14     17   20011  25     29     337    39   48   54  63   818  944  cgroups    driver       ipmi        kpageflags     mounts        self         timer_list     xen
10698  1279   145    18   20012  26     3      34     40   49   55  7    859  954  cmdline    execdomains  irq         latency_stats  mtrr          slabinfo     timer_stats    zoneinfo
11     13     15     19   20013  27     30     343    41   5    57  715  861  961  consoles   fb               kallsyms    loadavg        net           softirqs     tty
1170   1301   1505   2    20042  27396  31     35     42   50   58  75   864  99   cpuinfo    filesystems  kcore       locks          pagetypeinfo  stat         uptime
12     13131  1508   20   21     27443  31809  36     43   501  59  77   865  991  crypto     fs           key-users   mdstat         partitions    swaps        version

下面介绍几个比较重要的部分

/proc/N                     pid为N的进程信息
/proc/N/cmdline             进程启动命令
/proc/N/cwd                 链接到进程当前工作目录
/proc/N/environ                进程环境变量列表
/proc/N/exe                 链接到进程的执行命令文件
/proc/N/fd                     包含进程相关的所有的文件描述符
/proc/N/maps                 与进程相关的内存映射信息
/proc/N/mem                 指代进程持有的内存,不可读
/proc/N/root                 链接到进程的根目录
/proc/N/stat                 进程的状态
/proc/N/statm                 进程使用的内存的状态
/proc/N/status                 进程状态信息,比stat/statm更具可读性
/proc/self                     链接到当前正在运行的进程

实现 run 命令

我们先会实现一个简单版本的 run 命令,类似 docker run -ti [command]。然后在后面的章节逐步添加network, mount filesystem 等功能。为了方便了解 docker 启动容器的原理,我们实现的简单版本是参考 runc 的实现。

目前的代码文件结构如下。

mydocker
    ├── container
    │   ├── container_process.go
    │   └── init.go
    ├── Godeps
    │   ├── Godeps.json
    │   └── Readme
    ├── main_command.go
    ├── main.go
    ├── mydocker
    ├── run.go
    └── vendor

首先来看一下入口main文件

package main

import (
    log "github.com/Sirupsen/logrus"
    "github.com/urfave/cli"
    "os"
)

const usage = `mydocker is a simple container runtime implementation.
               The purpose of this project is to learn how docker works and how to write a docker by ourselves
               Enjoy it, just for fun.`

func main() {
    app := cli.NewApp()
    app.Name = "mydocker"
    app.Usage = usage

    app.Commands = []cli.Command{
        initCommand,
        runCommand,
    }

    app.Before = func(context *cli.Context) error {
        // Log as JSON instead of the default ASCII formatter.
        log.SetFormatter(&log.JSONFormatter{})

        log.SetOutput(os.Stdout)
        return nil
    }

    if err := app.Run(os.Args); err != nil {
        log.Fatal(err)
    }
}

使用github.com/urfave/cli 提供的命令行工具, 我们定义了mydocker 的几个基本的命令,包括runCommand, initCommand ,然后在app.Before 内初始化了一下logrus的日志配置。
下面我们来看一下子命令的具体定义.


//这里定义了 runCommand的Flags,类似于我们运行命令的时候--指定的参数
var runCommand = cli.Command{
    Name:  "run",
    Usage: `Create a container with namespace and cgroups limit
            mydocker run -ti [command]`,
    Flags: []cli.Flag{
        cli.BoolFlag{
            Name:        "ti",
            Usage:       "enable tty",
        },
    },
    /*
    这里是run命令执行的真正函数。
    1. 判断参数是否包含command
    2. 获取用户指定的command
    3. 调用Run function 去准备启动容器
     */
    Action: func(context *cli.Context) error {
        if len(context.Args()) < 1 {
            return fmt.Errorf("Missing container command")
        }
        cmd := context.Args().Get(0)
        tty := context.Bool("ti")
        Run(tty, cmd)
        return nil
    },
}

//这里定义了initCommand的具体操作,此操作为内部方法,禁止外部调用
var initCommand = cli.Command{
    Name:    "init",
    Usage:    "Init container process run user's process in container. Do not call it outside",
    /*
    1. 获取传递过来的command参数
    2. 执行容器初始化操作
    */
    Action:    func(context *cli.Context) error {
        log.Infof("init come on")
        cmd := context.Args().Get(0)
        log.Infof("command %s", cmd)
        err := container.RunContainerInitProcess(cmd, nil)
        return err
    },
}

我们先来看一下run 函数干了一些什么。


/*
这里是父进程也就是我们当前进程执行的内容,根据我们上一章介绍的内容,应该比较容易明白
1.这里的/proc/self/exe 调用,其中/proc/self指的是当前运行进程自己的环境,exec其实就是自己调用了自己,我们使用这种方式实现对创建出来的进程进行初始化
2.后面args是参数,其中 init 是传递给本进程的第一个参数,这在本例子中,其实就是会去调用我们的initCommand去初始化进程的一些环境和资源
3. 下面的clone 参数就是去 fork 出来的一个新进程,并且使用了namespace隔离新创建的进程和外部的环境。
4. 如果用户指定了-ti 参数,我们就需要把当前进程的输入输出导入到标准输入输出上
*/
func NewParentProcess(tty bool, command string) *exec.Cmd {
    args := []string{"init", command}
    cmd := exec.Command("/proc/self/exe", args...)
    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS |
        syscall.CLONE_NEWNET | syscall.CLONE_NEWIPC,
    }
    if tty {
        cmd.Stdin = os.Stdin
        cmd.Stdout = os.Stdout
        cmd.Stderr = os.Stderr
    }
    return cmd
}

/*
这里的Start方法是真正开始前面创建好的command的调用,他会首先 clone
出来一个 namespace 隔离的进程,然后在子进程中,调用/proc/self/exe 也就是自己,发送 init 参数,调用我们写的init方法,去初始化容器的一些资源
*/
func Run(tty bool, command string) {
    parent := container.NewParentProcess(tty, command)
    if err := parent.Start(); err != nil {
        log.Error(err)
    }
    parent.Wait()
    os.Exit(-1)
}

那么 Init 函数里面干了啥呢

/*
这里的init函数执行是在容器内部的,也就是说,代码执行到这里后,其实容器所在的进程已经创建出来了,我们是本容器执行的第一个进程。
1.使用mount 先去挂载proc 文件系统,方便我们通过ps等系统命令去查看当前进程资源情况
*/
func RunContainerInitProcess(command string, args []string) error {
    logrus.Infof("command %s", command)

    defaultMountFlags := syscall.MS_NOEXEC | syscall.MS_NOSUID | syscall.MS_NODEV
    syscall.Mount("proc", "/proc", "proc", uintptr(defaultMountFlags), "")
    argv := []string{command}
    if err := syscall.Exec(command, argv, os.Environ()); err != nil {
        logrus.Errorf(err.Error())
    }
    return nil
}

这里的MountFlag的意思如下

  • MS_NOEXEC 在本文件系统中不允许运行其他程序
  • MS_NOSUID 在本系统中运行程序的时候不允许set-user-ID或者set-group-ID
  • MS_NODEV 这个参数是自从Linux 2.4以来所有 mount 的系统都会默认设定的参数

本函数的最后一句话syscall.Exec是最为重要的一句黑魔法,正是这个系统调用实现了将我们初始化动作完成并且运行起来用户的进程这个操作。你可以能会问,这有什么神奇的,不就是运行一下程序嘛,这里我们来解释一下这句话的神奇之处。

首先我们使用 docker 创建起来一个容器之后,会发现容器内的第一个程序也就是 PID 为1的那个进程是我们指定的前台进程。那么根据我们前面讲的过程发现,我们的容器创建之后,执行的第一个进程并不是用户的进程,而是我们的 init 初始化进程,那么这时候如果通过ps命令查看就会发现容器内第一个进程变成了我们自己的init,这个是预想的是不一样的。那么你可能会想,大不了我把第一个进程给kill了.这里又有一个头疼的问题,PID 为1的进程是不能 kill 的,如果你给 kill了,那么我们的容器也就推出了,那么有什么办法呢,这里的execve 系统调用就大显神威了。

我们使用的syscall.Exec这个方法其实最终调用了kernel的
`int execve(const char filename, char const argv[],
char *const envp[]);`
这个系统函数。他的作用是执行当前filename对应的程序。它会覆盖当前进程镜像,当前进程的数据,堆栈等信息包括 PID 都会被我们将要运行的进程给覆盖。也就是说,我们调用这个方法,将用户指定的进程运行起来,把最初的 init 进程给替换掉,这样当我们进入到容器内部的时候,就会发现容器内的第一个程序就是我们指定的进程了。这其实也是目前docker使用的容器引擎runc的实现方式之一。

好,代码差不多讲完了,下面我们来编译运行一下。


#使用go build .在mydocker 目录下进行编译
root@ubuntu:[mydocker]# go build .
#我们使用./mydocker run -ti sh命名,其中-ti表示我们想要以交互式运行容器,/bin/sh为我们指定的容器内运行的第一个进程
root@ubuntu:[mydocker]# ./mydocker run -ti /bin/sh
{"level":"info","msg":"init come on","time":"2016-11-27T06:15:44Z"}
{"level":"info","msg":"command /bin/sh","time":"2016-11-27T06:15:44Z"}
# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 06:15 pts/0    00:00:00 /bin/sh
root         4     1  0 06:16 pts/0    00:00:00 ps -ef

我们在容器运行ps -ef可以发现/bin/sh进程是容器内的第一个进程,PID 为1,我们的ps -ef是PID为1的父进程创建出来的。我们对比一下 docker 运行的容器的效果

root@iZ254rt8xf1Z:~# docker run -ti ubuntu /bin/sh
# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  1 06:25 ?        00:00:00 /bin/sh
root         5     1  0 06:25 ?        00:00:00 ps -ef

是不是有些类似。这里的/bin/sh是一个会在前台一直跑着的进程,那么我们试试如果指定一个运行完就会退出的进程会是什么效果呢。

root@ubuntu:[mydocker]# ./mydocker run -ti /bin/ls
{"level":"info","msg":"init come on","time":"2016-11-27T06:28:31Z"}
{"level":"info","msg":"command /bin/ls","time":"2016-11-27T06:28:31Z"}
container  Godeps  main_command.go  main.go  mydocker  run.go  vendor

由于我们没有chroot,所以目前我们的系统文件系统是继承自我们的父进程的,这里我们运行了一下ls命令,发现容器启动起来以后,打印出来了当前目录的内容,然后退出了,这个和docker要求容器必须有一个一直在前台跑着的进程的要求一致。

小结

本节我们构造了一个简单的容器,具有基本的namesapce隔离,并且确定了我们的基本开发架构。基本创建流程如下

_

下面我们会继续完善这个容器。

相关图书推荐<<自己动手写 docker>>

_Docker_01_

【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论