很多人可能遇到过开机重启时,由于Docker守护程序在占用多核CPU使用100%C使用的情况,导致所有容器都无法启动,服务都不能用的情况。很悲催的是这事儿虫虫也遇到了,之前文章中虫虫介绍过利用Docker重构WP博客的新架构。由于VPS机器不是很稳定,时常会重启,重启时候就会遇到这个事情,VPS负载很高,容器都没有起来,网站就无法访问了。这时候只能杀掉所有容器并重启守护进程,才能恢复。经过了解该问题是由于Docker守护进程引起,而且Docker守护进程是以root特权权限启动的,是一个安全问题,那么有什么方法解决呢?
为什么Docker需要一个守护进程呢?那么Docker之后谁是下一代容器技术呢?
PS:k8s+Docker 是当今主流技术架构,可以很好的地完成微服务的部署,促使软件产品能够快速迭代和交付。虽然docker的竞争对手CoreOS和OpenVZ也在发力,但已经不足以与之较量。市场份额Docker为王,并且镜像和社区最为强劲。
Linux
容器是由 Linux
内核所提供的具有特定隔离功能的进程,Linux
容器技术能够让你对应用及其整个运行时环境(包括全部所需文件)一起进行打包或隔离。从而让你在不同环境(如开发、测试和生产等环境)之间轻松迁移应用的同时,还可保留应用的全部功能。
Linux
容器还有利于明确划分职责范围,减少开发和运维团队间的冲突。这样,开发人员可以全心投入应用开发,而运维团队则可专注于基础架构维护。由于 Linux
容器基于开源技术构建,还将便于你在未来轻松采用各类更新、更强的技术产品。包括 CRI-O
、Kubernetes
和 Docker
在内的容器技术,可帮助你的团队有效简化、加速和编排应用的开发与部署。
Docker 是一个开源的应用容器引擎,属于 Linux 容器的一种封装,Docker 提供简单易用的容器使用接口,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上。容器是完全使用沙箱机制,相互之间不会有任何接口。
这三个工具都是符合OCI计划下的工具(github/containers)。主要是由RedHat推动的,他们配合可以完成Docker所有的功能,而且不需要守护程序或访问有root权限的组,更加安全可靠,是下一代容器容器工具。
Podman官方网站 | podman.io https://podman.io/
Podman可以替换Docker中了大多数子命令(RUN,PUSH,PULL等)。Podman不需要守护进程,而是使用用户命名空间来模拟容器中的root,无需连接到具有root权限的套接字保证容器的体系安全。
Podman专注于维护和修改OCI镜像的所有命令和功能,例如拉动和标记。它还允许我们创建,运行和维护从这些图像创建的容器。
Podman
只是 OCI
容器生态系统计划中的一部分,主要专注于帮助用户维护和修改符合 OCI
规范的容器镜像。其它的组件还有 Buildah
、Skopeo
等。
Buildah用来构建OCI图像。虽然Podman也可以用户构建Docker镜像,但是构建速度超慢,并且默认情况下使用vfs存储驱动程序会耗尽大量磁盘空间。 buildah bud(使用Dockerfile构建)则会非常快,并使用覆盖存储驱动程序。
Buildah专注于构建OCI镜像。 Buildah的命令复制了Dockerfile中的所有命令。可以使用Dockerfiles构建镜像,并且不需要任何root权限。 Buildah的最终目标是提供更低级别的coreutils界面来构建图像。Buildah也支持非Dockerfiles构建镜像,可以允许将其他脚本语言集成到构建过程中。 Buildah遵循一个简单的fork-exec模型,不以守护进程运行,但它基于golang中的综合API,可以存储到其他工具中。
虽然 Podman
也可以支持用户构建 Docker
镜像,但是构建速度比较慢。并且默认情况下使用 VFS
存储驱动程序会消耗大量磁盘空间。
Buildah
是一个专注于构建 OCI
容器镜像的工具,Buildah
构建速度非常快并使用覆盖存储驱动程序,可以节约大量的空间。
Buildah
和 Podman
之间的一个主要区别是:Podman
用于运行和管理容器, 允许我们使用熟悉的容器 CLI
命令在生产环境中管理和维护这些镜像和容器,而 Buildah
主用于构建容器。
Skopeo是一个工具,允许我们通过推,拉和复制镜像来处理Docker和OC镜像。
Skopeo 是一个镜像管理工具,允许我们通过 Push、Pull和复制镜像来处理 Docker 和符合 OCI 规范的镜像。
项目地址:https://github.com/containers/skopeo
docker cli
命令通过API跟 Docker Engine(引擎)
交互告诉它我想创建一个container,然后docker Engine
才会调用OCI container runtime(runc)
来启动一个container。这代表container的process(进程)不会是Docker CLI
的child process(子进程)
,而是Docker Engine
的child process
。Podman
是直接给OCI containner runtime(runc)
进行交互来创建container的,所以container process
直接是podman
的child process
。--restart
策略,但是podman不支持,如果在k8s中就不存在这个问题,我们可以设置pod的重启策略,在系统中我们可以采用编写systemd服务来完成自启动Buildah构建容器,Podman运行容器,Skopeo传输容器镜像。这些都是由Github容器组织维护的开源工具(github/containers)。这些工具都不需要运行守护进程,并且大多数情况下也不需要root访问权限。
Podman和Buildah之间的一个主要区别是他们的容器概念。 Podman允许用户创建"传统容器"。虽然Buildah容器实际上只是为了允许将内容添加回容器图像而创建的。一种简单方法是buildah run命令模拟Dockerfile中的RUN命令,而podman run命令模拟功能中的docker run命令。
简而言之,Buildah是创建OCI图像的有效方式,而Podman允许我们使用熟悉的容器cli命令在生产环境中管理和维护这些图像和容器。
基本上各大发行版都提供了二进制安装包, 使用系统包管理就可以安装:
Fedora, CentOS:sudo yum -y install podman
Arch & Manjaro Linux: sudo pacman -S podman
Ubuntu安装:
sudo apt-get update -qq
sudo apt-get install -qq -y software-properties-common uidmap
sudo add-apt-repository -y ppa:projectatomic/ppa
sudo apt-get update -qq
sudo apt-get -qq -y install podman
首先,用podman替换了cron和CI作业中的所有docker实例。
完成后第一步后使用sysdig来捕获对docker的引用,看看是否还有其他东西在调用docker:
sysdig | grep -w docker
如果您对性能敏感,这可能会大大降低系统速度。
现在就可以删除docker了:
sudo:yum remove docker
或者
apt remove -y docker-ce
清理配置文件:
删除/etc/apt/*或者/etc/yum.repos.d/*中指向Docker的源
删除/etc/docker/*,/etc/default/docker和/var/lib/ docker中的任何遗留文件
删除docker组:delgroup docker
Buildah构建容器,Podman运行容器,Skopeo传输容器镜像。这些通过在Github容器组织维护和开源。套件下的工具都无需运行守护进程,并且大多数情况下也不需要root访问权限。
Podman和Buildah之间的一个主要区别是他们的容器概念。 Podman可允许用户创建"传统容器"。Buildah容器作用是给容器添加一些特有的内容而构建容器,Buildah容器是过程容器,编译完成就消失,不能用来跑服务 。简而言之,buildah run命令模拟Dockerfile中的RUN命令,而podman run命令则模拟功能中的docker run命令。
总之,Buildah是创建OCI镜像的有效方式,而Podman允许我们使用熟悉的容器cli命令在生产环境中管理和维护这些镜像和容器。
本文介绍三个了符合 CRI 标准的容器工具 Podman、 Buildah 和 Skopeo。这三个工具都是基于 *nix 传统的 fork-exec 模型,解决了由于 Docker 守护程序导致的启动和安全问题,提高了容器的性能和安全。
使用Podman,Skopeo和Buildah的新一代容器架构后,可以解决由于docker守护程序导致的启动和安全问题。使用新架构后除了"没有守护进程"和"不需要sudo访问"之外,没有发现很多不同之处。构建的容器都位于用户目录下(~/.local/containers中)而不是全局的(在/var/lib/docker中),即面向用户而不是面向守护进程。与Docker相比,podman pull会并行下载获取所有层。
不过真正企业应用还是Docker为主,小众的技术玩玩可以,生产坏境还是要以解决方案最多的Docker为主(云原生成员)。
OCI
(Open Container Initiative),是一个轻量级,开放的治理结构(项目)。在 Linux
基金会的支持下成立,致力于围绕容器格式和运行时创建开放的行业标准。
OCI
项目由 Docker
、CoreOS
和容器行业中的其它领导者在 2015 年 6 月的时候启动,OCI
的技术委员会成员包括 Red Hat
、Microsoft
、Docker
、Cruise
、IBM
、Google
、Red Hat
和 SUSE
等。
CRI
(Container Runtime Interface)是 Kubernetes
v1.5 引入的容器运行时接口,它将 Kubelet
与容器运行时解耦,将原来完全面向 Pod
级别的内部接口拆分成面向 Sandbox
和 Container
的 gRPC
接口,并将镜像管理和容器管理分离到不同的服务。
CNI
(Container Network Interface)是 CNCF
旗下的一个项目,是 Google
和 CoreOS
主导制定的容器网络标准。CNI
包含方法规范、参数规范等,是 Linux
容器网络配置的一组标准和库,用户可以根据这些标准和库来开发自己的容器网络插件。CNI
已经被 Kubernetes
、Mesos
、Cloud Foundry
、RKT
等使用,同时 Calico
、Weave
等项目都在为 CNI 提供插件。