最近在挺多项目的方案计划中看到容器的字眼,感觉“容器”这个概念已经深入人心。每当开会讨论新系统新架构,容器、Kubernetes这些词就会被拉出来讨论。当前实际上能不能用上又是另外一回事,但是大家都觉得容器是个好东西,用上了可以解决很多问题。

Docker是什么?

与其说Docker是什么,不如先说说容器是什么?在很多人的理解里面有这么一个公式:容器=Docker

那Docker这个仅不到10年的产品是哪个公司倒腾出来的呢?Docker公司的前身是dotCloud,是几个年轻人在旧金山成立了一个叫做PaaS平台的公司,本来是做dotCloud公有云,结果后来发现Docker越做越好。。。就觉得不如把公司名字改成Docker Ltd吧,改了公司名字感觉还不够带劲,那就把自己的老本行dotCloud给卖了,于是就有了现在的Docker。

虽然 docker 把容器技术推向了巅峰,但容器技术却不是从 docker 诞生的。实际上,容器技术连新技术都算不上,因为它的诞生和使用确实有些年头了。下面的一串名称肯能有的你都没有听说过,但它们的确都是容器技术的应用:

  1. Chroot Jail
    就是我们常见的 chroot 命令的用法。它在 1979 年的时候就出现了,被认为是最早的容器化技术之一。它可以把一个进程的文件系统隔离起来。
  2. The FreeBSD Jail
    Freebsd Jail 实现了操作系统级别的虚拟化,它是操作系统级别虚拟化技术的先驱之一。
  3. Linux VServer
    使用添加到 Linux 内核的系统级别的虚拟化功能实现的专用虚拟服务器。
  4. Solaris Containers
    它也是操作系统级别的虚拟化技术,专为 X86 和 SPARC 系统设计。Solaris 容器是系统资源控制和通过 “区域” 提供边界隔离的组合。
  5. OpenVZ
    OpenVZ 是一种 Linux 中操作系统级别的虚拟化技术。 它允许创建多个安全隔离的 Linux 容器,即 VPS。
  6. Process Containers
    Process 容器由 Google 的工程师开发,一般被称为 cgroups。
  7. LXC
    LXC 又叫 Linux 容器,这也是一种操作系统级别的虚拟化技术,允许使用单个 Linux 内核在宿主机上运行多个独立的系统。
  8. Warden
    在最初阶段,Warden 使用 LXC 作为容器运行时。 如今已被 CloudFoundy 取代。
  9. LMCTFY
    LMCTY 是 Let me contain that for you 的缩写。它是 Google 的容器技术栈的开源版本。
    Google 的工程师一直在与 docker 的 libertainer 团队合作,并将 libertainer 的核心概念进行抽象并移植到此项目中。该项目的进展不明,估计会被 libcontainer 取代。
  10. Docker
    Docker 是一个可以将应用程序及其依赖打包到几乎可以在任何服务器上运行的容器的工具。
  11. RKT
    RKT 是 Rocket 的缩写,它是一个专注于安全和开放标准的应用程序容器引擎。
Docker架构图


文字太多了,上一张图然后直如正题。
在Docker的世界中:build once,run everywhere,通常使用docker build创建一个镜像,然后再通过docker push推送只镜像仓库registry中,每当需要用到这个镜像的时候,就docker pull一下弄一份拷贝出来再用docker run来运行。
当然上述的所有操作都离不开Docker daemon,如果没有启动docker的守护进程,运行任何docker相关的命令只会得到Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Docker组件

整个docker-ce其实包括了docker、containerd、docker-containerd-shim和docker-runc四个组件,通常大家只会关心dockerddocker。其实每个组件都是需要干活的,Docker Engine负责镜像管理,containerd管理容器,包括容器的启动、停止、暂停和销毁。Docker Engine将镜像交付到containerd运行,containerd 调用 containerd-shimcontainerd-shim使用 runC来运行容器。

个人理解上Docker可以解决以下问题:

  1. 一定程度的资源隔离(如果程序实在太烂,死的更惨,只有虚拟机的隔离级别才能扛住)
  2. 运行时环境保持一致
  3. 开发测试能够快速迭代
  4. 上线时不需要考虑安装一大堆依赖包
    。。。and so on

不能解决的问题:

  1. 数量太多了,传统运维扛不住
  2. 出了问题,除了需要确定是那个应用的,还需要分析是哪个容器的(如果应用日志太少,就是个悲剧)。。。
  3. 统一管理。。。
  4. 硬件故障。。。一死一大片。。。再恢复一大片。。。巡检比较痛苦
    。。。and so on

容器是个好东西,但是在解决问题的同时,会带来更多新的问题。
生活不易,且行且珍惜。

发表评论