有时候, 有些地方不能从互联网下载东西, 但是可以上传一些内部的 docker image, 比如 生产环境, 一般是连不上外网的, 及时使用代理, 很有可能也不允许下载很大的东西. 这个时候, 可以做个 docker image 上传上去, 然后供生产环境使用. 下面是一个基于 nginx 的最简单 web 服务器.

需要2个文件, 里面的 mat.zip 和 那个 jdk 的 exe 是我需要下载的东西.
Dockerfile (去除下面的所有注释)

FROM alpine
RUN apk update
RUN apk --no-cache add nginx   #安装 nginx
ADD nginx.conf /etc/nginx/nginx.conf  #复制本地的配置文件
RUN mkdir -p /run/nginx  #建立 nginx pid 文件需要的文件夹
ADD mat.zip /usr/share/nginx/www/  #复制本地需要复制的文件1 例子
ADD jdk-8u171-windows-x64.exe /usr/share/nginx/www/  #复制本地需要复制的文件2 例子
RUN chmod 755 /usr/share/nginx/www/*  #更改文件读权限
EXPOSE 80  #暴露80端口
CMD ["nginx", "-g", "daemon off;"]  #启动 nginx

nginx.conf

events {
  worker_connections 1024;
}

http {
  include /etc/nginx/mime.types;
  index index.html;
  default_type application/octet-stream;
  sendfile     on;

  server {
    location / {
      root /usr/share/nginx/www;
      index not_a_file;
      autoindex on;
      types {}
    }
  }
}

打包: docker build -t repo.tianxiaohui.com/xiatian/test:0.1 .
上传: docker push repo.tianxiaohui.com/xiatian/test:0.1
下载: docker pull repo.tianxiaohui.com/xiatian/test:0.1
运行: docker run -p 9191:80 repo.tianxiaohui.com/xiatian/test:0.1
使用: http://container.tianxiaophui.com:9191/

Control Groups (cgroups) provide resource limitations and accounting for containers. From the Linux Kernel documentation:

Control Groups provide a mechanism for aggregating/partitioning sets
of tasks, and all their future children, into hierarchical groups with
specialized behaviour.

In simple terms, they can be compared to the ulimit shell command or the setrlimit system call. Instead of setting the resource limit to a single process, cgroups allow the limiting of resources to a group of processes.

Control groups are split into different subsystems, such as CPU, CPU sets, memory block I/O, and so on. Each subsystem can be used independently or can be grouped with others. The features that cgroups provide are:

1. Resource limiting: For example, one cgroup can be bound to specific
   CPUs, so all processes in that group would run off given CPUs only
2. Prioritization: Some groups may get a larger share of CPUs
3. Accounting: You can measure the resource usage of different
   subsystems for billing
4. Control: Freezing and restarting groups

Some of the subsystems that can be managed by cgroups are as follows:

• blkio: It sets I/O access to and from block devices such as disk,
  SSD, and so on
• Cpu: It limits access to CPU
• Cpuacct: It generates CPU resource utilization
• Cpuset: It assigns the CPUs on a multicore system to tasks in a
  cgroup
• Devices: It devises access to a set of tasks in a cgroup
• Freezer: It suspends or resumes tasks in a cgroup
• Memory: It sets limits on memory use by tasks in a cgroup

There are multiple ways to control work with cgroups. Two of the most popular ones are accessing the cgroup virtual filesystem manually and accessing it with the libcgroup library.

There are different types of namespaces and each one of them isolates applications from each other. They are created using the clone system call. One can also attach to existing namespaces.

1. The pid namespace allows each container to have its own process
   numbering. Each pid forms its own process hierarchy. A parent
   namespace can see the children namespaces and affect them, but a
   child can neither see the parent namespace nor affect it.
2. The net namespace allows us to have different network interfaces on
   each container, like port. Each net namespace has its own routing
   table and firewall rules.
3. ipc namespace sepratate IPC (Inter Process Communication) between
   different container's process;
4. with mnt namespace, a container can have its own set of mounted
   filesystems and root directories, enhenance chroot.
5. With uts namespace, we can have different hostnames for each
   container.
6. With user namespace support, we can have users who have a nonzero ID
   on the host but can have a zero ID inside the container.

There are ways to share namespaces between the host and container and container and container.

摘自book: docker cookbook, 第一章 introduction and Installation, 第一节 Introduction

1) It’s important to set the USER statement in all your Dockerfiles (or change user within any ENTRYPOINT / CMD scripts). If you don’t do this, your processes will be running as root within the container. As UIDs are the same within a container and on the host, should an attacker manage to break the container, they will have root access to the host machine.

2) 查看container 的CPU, 内存, 网络使用情况
docker stats $(docker inspect -f {{.Name}} $(docker ps -q))

3) cAdvisor aggregates and processes various stats and also makes these available through a REST API, for further processing and storage.

默认情况下, Docker Daemon 监听在本地的 unix:///var/run/docker.sock 上, 只允许本地 root 用户 docker client 连接. 如果要想远程连接, 必须监听 tcp 端口.

Docker Daemon 可以选择在启动的时候, 设置监听在 tcp 端口, IPC socket 监听, 或者2个都监听.

• 首先看一下Docker Daemon 是不是在监听 (ps -aux | grep docker);
• 如果已经起来了, 先shutdown (service docker stop);
• 重新启动, 设置tcp 和 sock 同时监听 (sudo docker -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock -d &);

官方关于设置Docker Daemon 的文档: http://docs.docker.com/articles/basics/
如下图:

重新查看进程状态, 可以看到 Docker Deamon 已经起来了. 那么就可以远程http连接了
http://docker.tianxiaohui.com:2375/containers/json?all=1 (查看所有container)

使用 RESTful client, 启动一个container, 这里返回204, 代表没有任何错误

官方关于docker remote API 的文档 http://docs.docker.com/reference/api/docker_remote_api/