Docker – 第2页 – PHPor 的Blog

变化的mac地址

4,673

11月 212017

一个bridge诞生时，会有一个mac地址；当向bridge上addif veth2时，bridge的mac地址就跟随了veth2的mac地址，难道br0就不能固定一个mac地址吗？

可以的：

默认情况下，bridge总是跟随port中mac地址最小的那个port的mac地址，如果不想让mac地址总是变化，则可以设置bridge的首选mac地址，方法就是显式地给bridge设置mac地址：

ip link set dev br0 address fa:11:11:11:11:11

1	ip link set dev br0 address fa:11:11:11:11:11

参考：

http://blog.csdn.net/fanwenbo/article/details/2131193

原文链接：https://phpor.net/blog/post/6815

创建新的名字空间

Docker 1 Response »

2,896

10月 202017

#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

static char child_stack[1048576];

static int child_fn() {
	printf("PID: %ld\n", (long)getpid());
	sleep(100000);
	return 0;
}

int main(int ac, char** av) {
	int ch;
	int flag = SIGCHLD;
	while((ch = getopt(ac, av, "pmnuU")) != -1) {
		switch(ch) {
			case 'p':
				flag |= CLONE_NEWPID;break;
			case 'm':
				flag |= CLONE_NEWNS;break;
			case 'n':
				flag |= CLONE_NEWNET;break;
			case 'u':
				flag |= CLONE_NEWUTS;break;
			case 'U':
				flag |= CLONE_NEWUSER;break;
		}
	}

	pid_t child_pid = clone(child_fn, child_stack+1048576, flag, NULL);
	printf("clone() = %ld\n", (long)child_pid);

	waitpid(child_pid, NULL, 0);
	return 0;
}

#define _GNU_SOURCE

#include <sched.h>

#include <stdio.h>

#include <stdlib.h>

#include <sys/wait.h>

#include <unistd.h>

static char child_stack[1048576];

static int child_fn() {

printf("PID: %ld\n", (long)getpid());

sleep(100000);

return 0;

}

int main(int ac, char** av) {

int ch;

int flag = SIGCHLD;

while((ch = getopt(ac, av, "pmnuU")) != -1) {

switch(ch) {

case 'p':

flag |= CLONE_NEWPID;break;

case 'm':

flag |= CLONE_NEWNS;break;

case 'n':

flag |= CLONE_NEWNET;break;

case 'u':

flag |= CLONE_NEWUTS;break;

case 'U':

flag |= CLONE_NEWUSER;break;

}

pid_t child_pid = clone(child_fn, child_stack+1048576, flag, NULL);

printf("clone() = %ld\n", (long)child_pid);

waitpid(child_pid, NULL, 0);

return 0;

}

功能：创建新的名字空间，并使得进程处于sleep状态，可以随时nsenter进来

测试 mnt 时发现，似乎并没有实现mount的隔离；测试方法：

./new-namespace -m &

然后使用nsenter，分别在名字空间内外查看 /proc/self/mountinfo 的内容，发现如何操作，内外都是一致的。

注意：需要和pid名字空间一起使用：

./new-namespace -m -p &amp;
nsenter -m -p -t $pid

1 2	./new-namespace -m -p & nsenter -m -p -t $pid

参考： https://www.toptal.com/linux/separation-anxiety-isolating-your-system-with-linux-namespaces

原文链接：https://phpor.net/blog/post/6279

docker 之 exec失败的问题

Docker No Responses »

9,140

10月 122017

环境：

# docker info
Containers: 56
 Running: 33
 Paused: 0
 Stopped: 23
Images: 31
Server Version: 1.12.5
Storage Driver: devicemapper
 Pool Name: data-docker_thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 32.21 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 516.2 GB
 Data Space Total: 644.2 GB
 Data Space Available: 128.1 GB
 Metadata Space Used: 45.47 MB
 Metadata Space Total: 16.98 GB
 Metadata Space Available: 16.93 GB
 Thin Pool Minimum Free Space: 64.42 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.135-RHEL7 (2016-11-16)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc docker-runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.6.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 40
Total Memory: 94.14 GiB
Name: VM-2-10-12
ID: NYBE:NZML:4KQQ:PF2J:RXCB:IPPI:Y3BI:CY7E:RVAC:WVWV:VDM2:3EEK
Docker Root Dir: /data1/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 docker-registry.i.bbtfax.com:5000
 127.0.0.0/8
Registries: docker.io (secure)

# docker info

Containers: 56

Running: 33

Paused: 0

Stopped: 23

Images: 31

Server Version: 1.12.5

Storage Driver: devicemapper

Pool Name: data-docker_thinpool

Pool Blocksize: 524.3 kB

Base Device Size: 32.21 GB

Backing Filesystem: xfs

Data file:

Metadata file:

Data Space Used: 516.2 GB

Data Space Total: 644.2 GB

Data Space Available: 128.1 GB

Metadata Space Used: 45.47 MB

Metadata Space Total: 16.98 GB

Metadata Space Available: 16.93 GB

Thin Pool Minimum Free Space: 64.42 GB

Udev Sync Supported: true

Deferred Removal Enabled: true

Deferred Deletion Enabled: false

Deferred Deleted Device Count: 0

Library Version: 1.02.135-RHEL7 (2016-11-16)

Logging Driver: journald

Cgroup Driver: cgroupfs

Plugins:

Volume: local

Network: host bridge null overlay

Swarm: inactive

Runtimes: runc docker-runc

Default Runtime: runc

Security Options: seccomp

Kernel Version: 3.10.0-514.6.1.el7.x86_64

Operating System: CentOS Linux 7 (Core)

OSType: linux

Architecture: x86_64

Number of Docker Hooks: 2

CPUs: 40

Total Memory: 94.14 GiB

Name: VM-2-10-12

ID: NYBE:NZML:4KQQ:PF2J:RXCB:IPPI:Y3BI:CY7E:RVAC:WVWV:VDM2:3EEK

Docker Root Dir: /data1/docker

Debug Mode (client): false

Debug Mode (server): false

Registry: https://index.docker.io/v1/

Insecure Registries:

docker-registry.i.bbtfax.com:5000

127.0.0.0/8

Registries: docker.io (secure)

现象：

# docker exec -it c6176f37c4b6 bash
rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: container_linux.go:247: starting container process caused \"process_linux.go:75: starting setns process caused \\\"fork/exec /proc/self/exe: no such file or directory\\\"\"\n"

1 2	# docker exec -it c6176f37c4b6 bash rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: container_linux.go:247: starting container process caused \"process_linux.go:75: starting setns process caused \\\"fork/exec /proc/self/exe: no such file or directory\\\"\"\n"

乍一看， /proc/self/exe 文件找不见？

一般来讲，文件找不见并不奇怪，怪就怪在是 /proc/self/exe 找不见就不太应该了；

因为docker exec 最终是由libcontainerd进程来出来的，strace跟进发现，是chdir到 /root/data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc/rootfs 时，找不到目标目录导致的，于是我就迅速地看了一下，该目录确实不存在，但是对于正常的能够exec的容器来讲，相应的rootfs目录也是不存在的

思考中。。。

docker玩的就是名字空间和cgroup，所以不能不想到这些；libcontainerd也有自己的（mnt）名字空间，我们进入libcontainerd进程的文件系统就可以查看到上面目录的存在了，而且，正常的容器存在相应的目录，异常的容器不存在相应的目录；

通过mount命令可以发现mount的规律，从容器的config.json (/var/run/docker/libcontainerd/c6176f37c4b67b03d4187edef6d1131cd44ab80bd0f0c20b24a7a20056967652/config.json) 中查看到对应的mount的位置，通过nsenter进入libcontainerd的mnt名字空间手动mount上去就好了，如下：

# nsenter  -m -t 3639 bash
# mount /dev/mapper/docker-253\:3-3221225568-4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc -o rw,relatime,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota -t xfs /data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc

# nsenter -m -t 3639 bash

# mount /dev/mapper/docker-253\:3-3221225568-4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc -o rw,relatime,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota -t xfs /data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc

写个脚本自动修复之：

#!/bin/bash
# author: phpor
#
LIBCONTAINERD_DIR=/var/run/docker/libcontainerd

function main() {
        local pidOfCotainerd=$(pidof docker-containerd-current)
        local mountinfo=$(< /proc/$pidOfCotainerd/mountinfo)
        for config in $LIBCONTAINERD_DIR/*/config.json;do
                local cid=$(awk -F'/' '{print $6}' <<<$config)
                local rootpath=$(jq -r .root.path $config|sed 's/\/rootfs$//')
                grep "$rootpath" <<<$mountinfo >/dev/null
                if [[ $? -eq 0 ]]; then
                        echo $cid $rootpath OK
                else
                        echo $cid $rootpath Should repair
                        local device=/dev/mapper/$(docker inspect $cid|jq -r .[0].GraphDriver.Data.DeviceName)
                        nsenter -m -p -t $pidOfCotainerd mount -t xfs -o rw,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota $device $rootpath
                fi
        done
}
main

#!/bin/bash

# author: phpor

LIBCONTAINERD_DIR=/var/run/docker/libcontainerd

function main() {

local pidOfCotainerd=$(pidof docker-containerd-current)

local mountinfo=$(< /proc/$pidOfCotainerd/mountinfo)

for config in $LIBCONTAINERD_DIR/*/config.json;do

local cid=$(awk -F'/' '{print $6}' <<<$config)

local rootpath=$(jq -r .root.path $config|sed 's/\/rootfs$//')

grep "$rootpath" <<<$mountinfo >/dev/null

if [[ $? -eq 0 ]]; then

echo $cid $rootpath OK

else

echo $cid $rootpath Should repair

local device=/dev/mapper/$(docker inspect $cid|jq -r .[0].GraphDriver.Data.DeviceName)

nsenter -m -p -t $pidOfCotainerd mount -t xfs -o rw,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota $device $rootpath

done

}

main

那么该mount点是如何丢掉的呢？重启dockerd能否自动修复该问题呢？（应该重启一下容器就行）稍后再研究

原文链接：https://phpor.net/blog/post/6142

RUNNING CONTAINERS WITH RUNC

Docker No Responses »

2,302

10月 112017

http://www.centosabc.com/archives/1573

原文链接：https://phpor.net/blog/post/6109

cgroup 审计策略

Docker, Linux & Unix No Responses »

3,951

9月 072017

内存子系统

场景：

当你把一个已经占用了1GB内存的进程转移到一个新的cgroup后，新的cgroup看到的该进程使用的内存大小会是多少呢？

memory.max_usage_in_bytes 和 memory.usage_in_bytes 都不会将这1GB计算在内的，只有该进程继续申请内存才会计算新申请的内存。

同样，如果把一个占用内存很多的进程从cgroup中移出来，memory.max_usage_in_bytes 和 memory.usage_in_bytes 应该也不会被更新

Process Number Controller

pids.current 可以大于 pids.max
1. 当cgroup中进程数量达到最大时，cgroup并不“阻止”从其它cgroup中移动一个进程到该cgroup中；只是说不允许在该cgroup中fork、clone新的进程或线程
pids.current包含所有子孙cgroup中的进程(和线程）
当cgroup对进程数量不限制时，pids.max 不是0（零）也不是-1，而是字符串max😓

原文链接：https://phpor.net/blog/post/5893

docker 之磁盘限额

Docker, Linux & Unix No Responses »

6,880

9月 062017

docker-ce-17.07.0 版本开始支持overlay2的磁盘配额，该版本 8月29号release了，现在可以使用edge版本：

https://download.docker.com/linux/centos/7/x86_64/edge/Packages/docker-ce-17.07.0.ce-1.el7.centos.x86_64.rpm

overlay2的配额限制是有条件的：

基于xfs文件系统(如果不开启配额的话，ext4上也能支持，如果内核版本够高的话，btrfs也能支持)
xfs文件系统挂载时使用pquota选项(pquota和gquota 不能同时出现)

mount -o pquota,uqnoenforce /dev/rbd2 /xfs

1

mount -o pquota,uqnoenforce /dev/rbd2 /xfs
xfs 格式化时需要ftype=1，用于enable d_type

xfs的pquota是个啥东西： https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/xfsquota.html

XFS quotas are enabled at mount time, with specific mount options. Each mount option can also be specified as noenforce; this will allow usage reporting without enforcing any limits. Valid quota mount options are:

uquota/uqnoenforce – User quotas
gquota/gqnoenforce – Group quotas
pquota/pqnoenforce – Project quota

注意：

pquota和gquota 不能同时出现

uquota：强制限制，绝对不能超限
uqnoenforce：可以超限，但是会贴罚单

如果是kickstart 安装的系统，用如下命令：

logvol / --fstype xfs --mkfsoptions='-n ftype=1'

1	logvol / --fstype xfs --mkfsoptions='-n ftype=1'

mkfs.xfs 还有很多选项，专门研究存储的话，还是要了解的

参考： http://foxhound.blog.51cto.com/1167932/1841487

docker-ce-17.07.0 关于xfs上的overlay2存储驱动的磁盘限额，使用效果如下：

注意：

–storage-opt时，使用的是size，而不是overlay2.size；关键是多处文档描述的都是overlay2.size=1g，而实际上却不识别overlay2.size，识别的却是size
做磁盘限额的时候，基础镜像的大小显然没有计算在内；不做磁盘限额的时候，显示的是整个overlay文件系统的使用情况
据说daemon.json 中也是可以定义存储选项的，但是测试发现不管使用overlay2.size还是size都不报错，也都不生效（但是源码上确实都是overlay2.size呢）
docker info中不显示默认的存储配额
关于存储选项： overlay2.override_kernel_check，文档要求必须设置为true，实际情况是：
1. 如果设置为true，docker会帮忙检查内核版本够不够高，不够高就直接报错了
2. 如果设置为false，docker依然会帮忙检查内核版本够不够高，不够包就记录一个警告日志

阿里云提供的centos7镜像的文件系统类型似乎都是ext4的

并非所有的D状态的进程都是kill不掉的：

docker 的磁盘限额是可以通过xfs_quota 查看到的（kernel内核版本要求4.6以上才能查看到，小于4.6的内核版本上不是不支持限额，只是通过xfs_quota 看不到而已）

原文链接：https://phpor.net/blog/post/5853

docker之username space

Docker, Linux & Unix No Responses »

2,498

9月 062017

usernamespace在docker中的用法：

docker 中可以通过dockerd的 –userns-remap=$username 选项来指定用户映射，从文档上来看，该选项只能使用一次，也就是说，只能指定一个用户
docker 参考的用户映射关系文件为 /etc/subuid 和 /etc/subgid ,文件格式大约为：

bozo:100000:65536

1

bozo:100000:65536

其中：
bozo：是–userns-remap 指定的用户名
100000:65536 以为着该用户可以映射到的容器外部的uid的范围为 100000 ~ (100000 + 65536）
目前来看，不同容器中相同用户映射到容器外面的uid是相同的
docker文档要求需要映射的用户必须在容器外面是真实存在的，至少在 /etc/passwd 中是需要存在的；从uid映射来看，/etc/passwd 中定义的uid基本是被无视的
通过–userns-remap伪造的容器内部的root用户，虽然在容器外部就是个普通用户，但是在容器内部确实是有很大的特权的
docker create的 –user选项和usernamespace没有关系，只是说用哪个用户启动容器内部的进程而已
参考： https://github.com/docker/labs/tree/master/security/userns

从上面分析来看，userns-remap使用起来是比较麻烦的、且功能太有限；我们期望不需要太多配置的情况下，不同容器中所有进程、子进程的用户都能自动映射到外部单独的uid，可能实现这个确实比较麻烦（参考下面原理部分）

username space原理：

User Namespace是Linux 3.8新增的一种namespace
clone系统调用CLONE_NEWUSER
/proc/$pid/uid_map (对于支持user namespace的内核，都存在该文件，不明确设置就为空）
当我们通过CLONE_NEWUSER去clone一个进程（或线程）的话，进程的后续行为都会参考 /proc/$pid/uid_map 来决定用户的身份，那么该uid_map 文件必然要在clone之后才能写入了；为了避免我们clone出来的那个进程很快执行到用户代码而实现提权，则往往在clone后执行的是可控的代码，在准备工作完成后在execv()去执行用户的进程（注意： execv并不改变进程号，或者说不产生新的进程，而是在当前进程空间来执行用户的代码），用户代码中很可能会继续clone，那么后续的clone如果没有CLONE_NEWUSER的话，能否参考到上面的/proc/$pid/uid_map 呢？或者说，只参考该pid namespace中init进程下面的uid_map ? (稍后继续研究）
http://man7.org/linux/man-pages/man7/user_namespaces.7.html

看个例子：

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/mount.h>
#include <sys/capability.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char container_stack[STACK_SIZE];
char* const container_args[] = {
    "/bin/bash",
    NULL
};

int pipefd[2];

void set_map(char* file, int inside_id, int outside_id, int len) {
    FILE* mapfd = fopen(file, "w");
    if (NULL == mapfd) {
        perror("open file error");
        return;
    }
    fprintf(mapfd, "%d %d %d", inside_id, outside_id, len);
    fclose(mapfd);
}

void set_uid_map(pid_t pid, int inside_id, int outside_id, int len) {
    char file[256];
    sprintf(file, "/proc/%d/uid_map", pid);
    set_map(file, inside_id, outside_id, len);
}

void set_gid_map(pid_t pid, int inside_id, int outside_id, int len) {
    char file[256];
    sprintf(file, "/proc/%d/gid_map", pid);
    set_map(file, inside_id, outside_id, len);
}

int container_main(void* arg)
{

    printf("Container [%5d] - inside the container!\n", getpid());

    printf("Container: eUID = %ld;  eGID = %ld, UID=%ld, GID=%ld\n",
            (long) geteuid(), (long) getegid(), (long) getuid(), (long) getgid());

    /* 等待父进程通知后再往下执行（进程间的同步） */
    char ch;
    close(pipefd[1]);
    read(pipefd[0], &ch, 1);

    printf("Container [%5d] - setup hostname!\n", getpid());
    //set hostname
    sethostname("container",10);

    //remount "/proc" to make sure the "top" and "ps" show container's information
    mount("proc", "/proc", "proc", 0, NULL);

    execv(container_args[0], container_args);
    printf("Something's wrong!\n");
    return 1;
}

int main()
{
    const int gid=getgid(), uid=getuid();

    printf("Parent: eUID = %ld;  eGID = %ld, UID=%ld, GID=%ld\n",
            (long) geteuid(), (long) getegid(), (long) getuid(), (long) getgid());

    pipe(pipefd);

    printf("Parent [%5d] - start a container!\n", getpid());

    int container_pid = clone(container_main, container_stack+STACK_SIZE, 
            CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWUSER | SIGCHLD, NULL);


    printf("Parent [%5d] - Container [%5d]!\n", getpid(), container_pid);

    //To map the uid/gid, 
    //   we need edit the /proc/PID/uid_map (or /proc/PID/gid_map) in parent
    //The file format is
    //   ID-inside-ns   ID-outside-ns   length
    //if no mapping, 
    //   the uid will be taken from /proc/sys/kernel/overflowuid
    //   the gid will be taken from /proc/sys/kernel/overflowgid
    (container_pid, 0, uid, 1);
    set_gid_map(container_pid, 0, gid, 1);

    printf("Parent [%5d] - user/group mapping done!\n", getpid());

    /* 通知子进程 */
    close(pipefd[1]);

    waitpid(container_pid, NULL, 0);
    printf("Parent - container stopped!\n");
    return 0;
}

100

101

102

103

104

105

#define _GNU_SOURCE

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/wait.h>

#include <sys/mount.h>

#include <sys/capability.h>

#include <stdio.h>

#include <sched.h>

#include <signal.h>

#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char container_stack[STACK_SIZE];

char* const container_args[] = {

"/bin/bash",

NULL

};

int pipefd[2];

void set_map(char* file, int inside_id, int outside_id, int len) {

FILE* mapfd = fopen(file, "w");

if (NULL == mapfd) {

perror("open file error");

return;

}

fprintf(mapfd, "%d %d %d", inside_id, outside_id, len);

fclose(mapfd);

}

void set_uid_map(pid_t pid, int inside_id, int outside_id, int len) {

char file[256];

sprintf(file, "/proc/%d/uid_map", pid);

set_map(file, inside_id, outside_id, len);

}

void set_gid_map(pid_t pid, int inside_id, int outside_id, int len) {

char file[256];

sprintf(file, "/proc/%d/gid_map", pid);

set_map(file, inside_id, outside_id, len);

}

int container_main(void* arg)

{

printf("Container [%5d] - inside the container!\n", getpid());

printf("Container: eUID = %ld; eGID = %ld, UID=%ld, GID=%ld\n",

(long) geteuid(), (long) getegid(), (long) getuid(), (long) getgid());

/* 等待父进程通知后再往下执行（进程间的同步） */

char ch;

close(pipefd[1]);

read(pipefd[0], &ch, 1);

printf("Container [%5d] - setup hostname!\n", getpid());

//set hostname

sethostname("container",10);

//remount "/proc" to make sure the "top" and "ps" show container's information

mount("proc", "/proc", "proc", 0, NULL);

execv(container_args[0], container_args);

printf("Something's wrong!\n");

return 1;

}

int main()

{

const int gid=getgid(), uid=getuid();

printf("Parent: eUID = %ld; eGID = %ld, UID=%ld, GID=%ld\n",

(long) geteuid(), (long) getegid(), (long) getuid(), (long) getgid());

pipe(pipefd);

printf("Parent [%5d] - start a container!\n", getpid());

int container_pid = clone(container_main, container_stack+STACK_SIZE,

CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWUSER | SIGCHLD, NULL);

printf("Parent [%5d] - Container [%5d]!\n", getpid(), container_pid);

//To map the uid/gid,

// we need edit the /proc/PID/uid_map (or /proc/PID/gid_map) in parent

//The file format is

// ID-inside-ns ID-outside-ns length

//if no mapping,

// the uid will be taken from /proc/sys/kernel/overflowuid

// the gid will be taken from /proc/sys/kernel/overflowgid

(container_pid, 0, uid, 1);

set_gid_map(container_pid, 0, gid, 1);

printf("Parent [%5d] - user/group mapping done!\n", getpid());

/* 通知子进程 */

close(pipefd[1]);

waitpid(container_pid, NULL, 0);

printf("Parent - container stopped!\n");

return 0;

}

实际问题：

在没有使用–userns-map的情况下，很多容器都使用相同的镜像（所以，相同用户名的uid基本都一样），每个容器都可以通过容器中的sshd进行登录，sshd登录后都会有相应的limits限制，以单个用户最大进程数量为例，一般来讲，root都是没有限制的，其他用户都是有限制的，对于mysql用户，通常会产生很多线程，从容器的角度来看，该用户名下的进程数量确实不多，甚至整个容器都没有几个进程，这时候，启动mysql时却是失败的；原因在于：

启动进程这事儿归根结底还是内核干的
ulimit资源限制最终是从进程属性上生效的，而不是直接从配置文件上生效的
容器外部和容器内部看到的uid是相同的
其他容器已经在没有ulimit限制（或者配额足够）的情况下启动了很多mysql进程（或线程）了
最后，在ulimit限制比较小的情况下启动mysql进程（或线程）自然就会失败的
所以，从用户级别的资源限制方面来讲，容器之间的相互影响是比较难以控制的
docker本来不是让作为虚拟机使用的，所以，类似问题是不会被docker官方在意（和觉察）的，docker中的–userns-map 仅仅考虑了通常情况下单个容器中只有单个（被docker-containerd启动）的进程的场景
解决办法：给用户足够的资源
我们可以限制单个容器的进程数量:
1. https://segmentfault.com/a/1190000007468509 https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
2. 通过docker create 的 –pids-limit 选项进行配置
dockerd 启动选项 –default-ulimit 可以设置默认的ulimit

目前，我们生产环境使用的docker容器都是通过docker exec 启动进程的，docker exec 进去后，ulimit如下：

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15726
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

core file size (blocks, -c) unlimited

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 15726

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 65536

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 8192

cpu time (seconds, -t) unlimited

max user processes (-u) unlimited

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

问题：

如何从容器级别限制进程数量？

参考资料：

原文链接：https://phpor.net/blog/post/5834

关于容器oom

Docker No Responses »

2,873

9月 052017

缘起：

偶尔有同学反应容器很慢，查看容器状态发现内存没用完了；问题是，oom命名是开启的，为什么不杀进程呢？

其实，我忽略了一个问题，为了不必要的内存浪费，我给每个容器都配备了相当多的swap，oom是发生在连swap都被用完的情况下的；上面的情况是：内存用完了，但是swap还足够，开始大量使用swap，于是乎，反应就很慢；不仅如此，swap引发的设备IO，是不受单个容器的IO配额限制的，在没有控制的情况下疯狂使用swap会导致其他容器也会变慢

结论：

容器之间的资源隔离是相对的，总是会有某些情况下，容器之间会相互影响的；有些场景下，这些问题都无所谓，有些情况下就是致命的

原文链接：https://phpor.net/blog/post/5803

docker & cache

Docker No Responses »

3,404

8月 052017

缘起：

dubbo-monitor容器swap使用率超过 20% ，而且在不断上升，为什么呢？

下面是容器dubbo-monitor在drop-caches前后的对比：

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
dubbo_monitor 6.25% 1.4 GiB / 2 GiB 69.99% 0 B / 0 B 6.306 GB / 54.5 GB 0

[root@CX-DOCKER-BASE-1-10.139.105.202 ~]# echo 3 &gt; /proc/sys/vm/drop_caches

[root@CX-DOCKER-BASE-1-10.139.105.202 ~]# docker stats dubbo_monitor
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
dubbo_monitor 3.87% 595.7 MiB / 2 GiB 29.09% 0 B / 0 B 6.373 GB / 54.5 GB 0

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS

dubbo_monitor 6.25% 1.4 GiB / 2 GiB 69.99% 0 B / 0 B 6.306 GB / 54.5 GB 0

[root@CX-DOCKER-BASE-1-10.139.105.202 ~]# echo 3 > /proc/sys/vm/drop_caches

[root@CX-DOCKER-BASE-1-10.139.105.202 ~]# docker stats dubbo_monitor

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS

dubbo_monitor 3.87% 595.7 MiB / 2 GiB 29.09% 0 B / 0 B 6.373 GB / 54.5 GB 0

drop-cache后，容器的swap使用率没有变化

结论：

docker stats 显示的内存使用是包含cache的
~~该容器的部分cache信息会被swap出内存~~
1. cache和swap之间存在一些不默契；cache认为内存够多，还可以cache更多信息；swap机制为，经内存充裕，只要是不常被访问的内存数据，尽量swap出来；于是乎，就形成了一个恶性循环，导致swap占用越来越大
2. ~~解决办法：定期drop一下cache~~
系统不会傻到把cache内容换出到swap中的，swap确实为进程使用的（虚拟）内存的一部分
一个允许最大使用2g内存的java进程，swap出来500m或1g不足为奇，如果给他的swap大小为2g的话，占用50%的swap都有可能

原文链接：https://phpor.net/blog/post/5617

docker swarm 模式下证书过期后daemon无法启动

Docker No Responses »

3,121

7月 212017

报错信息：

Error creating cluster component: error while loading TLS Certificate

1	Error creating cluster component: error while loading TLS Certificate

解决办法：把 Docker Root Dir (通过docker info查看）下的swarm目录删掉就好了

原文链接：https://phpor.net/blog/post/5555

Older Entries Newer Entries