7月 202018
 

场景: 有个同学不知道因为啥,将容器内部的 /sys/fs/cgroup 挂载到了外面的某个目录; 但是这个目录是很有用的,不想随便被挂载,如何从image中去掉呢?

docker没有给出一个方便的方法, https://github.com/gdraheim/docker-copyedit 给了一个办法,原理如下:

每个image都是有一个manifest.json 文件的,相关配置信息都在这里了,但是你看不到image文件,更无从去谈修改manifest.json 文件了,所以:

  1. 先通过docker save 命令将image导出成tar文件:
  2. 在用tar命令解压文件
  3. 在解压后的文件中找到manifest.json 文件,这个文件可能不是你最终要修改的,里面的Config标识了配置文件的位置,应该就是该文件旁边的一个json文件
  4. 修改配置文件
  5. 重新打包image
  6. 导入image

我这里因为已经存在了同名的image,所以,旧的image的名字就被抢走了,但是ID没有变,新导入的image有自己新的ID

 

参考: https://github.com/gdraheim/docker-copyedit

 Posted by at 下午 5:37
7月 202018
 

往常,我使用docker的network=none ,然后使用pipework给容器添加一个外部可访问的IP,然后,容器就能访问外网了;

后来,我在openstack上创建的centos7虚拟机上安装docker,同样的方式启动的容器却无法访问外网,首先,centos7虚拟机的网卡去掉任何安全组,并设置为非管理状态; 检查centos7的ip_forward 是打开的,最终,发现差别就在于,原来的iptables规则中 FORWARD 的策略是ACCEPT ,而现在是FORWARD 策略是 DROP的;

问题: iptables的 FORWARD 的DROP策略是在哪个环节设置的呢?

 

参考docker 源码发现如下逻辑:

基本逻辑为:

如果本来是开启着ip转发的,就不会去设置iptables 的forward链的默认策略了;

如果本来没有开启ip转发的,就会去设置iptables 的forward链的默认策略。

显然,曾经的机器在docker启动前就已经设置了ip转发了, 而后来的机器在docker启动前还设置ip转发,虽然最终是都设置了IP转发,但是结果却不同;如果直接让docker来管理容器的网络,则docker会按照要求自动添加forward规则,然而,现在我们用的是pipework,就需要自己添加forward规则了,势必会麻烦一些;流氓一些的做法就是直接修改FORWORD 的默认策略。

 Posted by at 上午 10:07
6月 132018
 

下面的dockerd占用了5G的内存+2.6G的swap,管理几个容器需要这么多的资源吗?一定是哪里有bug?

图中的java和mysql也都是不怎么使用的,所以占用很多的swap; 真正用的时候就会很慢。

 Posted by at 下午 2:51
6月 132018
 

场景:

宿主机信息:

docker信息:

容器信息:

centos6.8

启动进程: /sbin/init (因为启动这个可以直接利用 init-scripts 配置自动启动的进程,比如: mysqld等)

 

操作

docker stop $name

 

现象: 卡死了,进不去了

 

分析:

/sbin/init进程不退出,由init进程启动的子进程也处于defunct状态; 很可能是上级的某进程存在bug; 逐级上朔,找到shim进程,该进程kill 默认信号是不死的,看来可能有问题,直接kill -9 ; 然后,容器就干净地退出了

 Posted by at 下午 2:23
5月 112018
 

现象:

自从使用了docker容器,在容器中yum安装的软件就怎么着也man不了,man的时候就提示:

通过rpm查看软件包中是否包含man文件,确实包含; 使用rpm -V 也检查不到rpm包损坏; 实际上,man文件是不存在的。

原因:

  1. 我们使用的docker镜像已经被官方精简过了,把所有已安装软件的man页都删除了,这样镜像可以更小
  2. docker镜像中的/etc/yum.conf 也被刻意处理了一下,里面有个tsflags的选项,配置了nodocs,这样的话,新安装的软件也会被自动剔掉man文件(估计rpm知道man文件是被故意删掉的,所以也不报错)

解决办法:

  • /etc/yum.conf 中注释掉:
  • 卸载掉相关软件,重新yum安装

 

注: 上述情况是把docker容器当虚拟机使用的,并不太在乎镜像的大小

 

 Posted by at 下午 3:23
3月 152018
 

官方文档:

https://github.com/docker/docker-ce-packaging/tree/master/rpm

 

环境搭建:

安装并启动docker就行:

 

命令很简单:

 

打包原理:

从make命令说起,通过docker容器对engine  cli分别进行打包,通过git获取版本号信息,通过docker-ce-packaging/rpm/Dockerfile.x86_64 构建一个基于centos:7 的容器镜像,镜像中安装编译环境(golang),容器挂载外部的一些目录,即,输入来自于外部目录,编译结果输出到外部目录;容器镜像直接启动rpmbuild命令进行构建,构建的详细步骤都在rpm的spec文件中,构建过程中还需要下载有些其他的源码

 

部分细节:

rpmbuild 命令:

 

容器挂载的外部目录:

 

问题记录:

  1. git 版本需要支持 -C 选项
  2. engine 的路径不小心写错了,导致engine的源码文件没有打进去,修改后OK

 

构建优化:

  1. 将github.com 解析到自己的代理服务器,加速下载构建中依赖的代码
  2. 将Dockerfile.x86_64中golang安装包下载地址修改为国内地址,只需将golang.org 修改为golang.google.cn 即可,加速下载golang安装包,当然,更快的办法是改为本地的地址
  3. 更快的办法是,自己build一个自己的环境,用完也不要销毁,每次自己直接执行rpmbuild -ba docker-ce.spec 就行了,不过注意:
    1. 构建过程中需要git clone一些代码,如果目录已经存在,就报错的,所以,可以做一个假的git,使得目录已存在就不再clone,这样还快些

 

 Posted by at 下午 5:25
3月 052018
 

当vsftpd在容器里面,而且容器IP又是host内部的私有IP的情况,client采用passive模式来下载数据能行得通吗? 可以的

  1. passive模式下,vsftpd需要listen临时端口来传输数据,所以docker创建容器时,不仅要暴露21端口,还要暴露可能listen的临时端口,为了不映射太多端口,可以在vsftpd的配置文件中配置可能的临时端口的范围
  2. passive模式下,vsftpd需要通过协议内容告知client临时端口及IP地址,然而,容器网卡IP地址显然是不能被client直接访问到的,庆幸的是,vsftpd配置文件中有关于可以告知client的ip地址的配置,该ip地址并不要求本机上必须有的,显然该配置是给类似情况准备的

 Posted by at 下午 6:13
1月 102018
 

把下面脚本当做容器的init进程:

 

知识点:

  1. while循环中修改外部的环境变量,则 不能使用管道的方式给while提供数据,这样的话,while 就是在新的子shell中执行的,不会影响到当前shell,所以:
    1. 使用了标准输入的重定向
    2. 使用了 <($cmd) 的方式
  2. 为了让字符串中连续的空格被保留,参数传递时多要通过双引号引上,即使是 $(cmd) 产生的字符串也要整个用双引号引上,当然,此时的双引号比较特殊,因为此时的双引号可以套双引号而不需要转义,示例: (注意下面几种双引号中嵌套单引号的的区别)

 

注意:

  1. 这个init进程是bash做的,如果docker attach的话,不管是ctrl-d退出还是ctrl-c退出,都会导致init进程终止,容器退出
  2. 脚本中的while循环最初想到的是通过sleep实现暂停的,但是考虑到sleep会产生一个额外的进程,不好看,于是选择了read;
    注: 后来发现,使用read有一定好处,bash处理信号需要注意的是,在执行外部命令(如: sleep)时不能实时处理信号,只有在外部命令结束后才能处理信号; 而read虽然也是阻塞的,但是能实时处理信号
 Posted by at 上午 10:57
12月 142017
 

场景,用docker做开发用的虚拟机,每个docker都有一个可以公开访问的IP地址。

由于docker和宿主机共享内核,一不小心可能会把整个宿主机搞挂,而且,docker热迁移也是个难题,所以,尽管openstack马上可以支持docker,我也不想让docker直接部署在计算节点;我的思路是,将docker部署在openstack管理的kvm虚拟机上,这样还能通过热迁移kvm的方式将容器迁移到别的计算节点。

 

注意事项:

  1. 关闭openstack的端口安全,注意:
    1. 需要先从安全组中拿掉
    2. 在管理员界面操作
  2. 热迁移后容器的IP地址在交换机上的mac地址与端口的映射不能及时更新
    1. 如果容器频繁地和外部通信的话,mac地址与端口的映射会被及时刷新
    2. 如果没能及时刷新的话,可以在与容器IP同网段的机器上,先clear一下arp缓存,在ping 一下容器IP,就可以了;
    3. 如何自动处理呢?在kvm虚拟机上(就是容器的宿主机上),docker exec到容器内部,然后ping一下网关就行。

 Posted by at 下午 2:01