容器 —— Docker容器化技术理解和使用

Docker容器化技术

一：容器介绍

logo

容器其实是一种沙盒技术。顾名思义，沙盒就是能够像一个集装箱一样，把你的应用"装"起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去，这其实是 PaaS 最理想的状态。

云计算服务类型
基础设施即服务IaaS
平台即服务(PaaS)
软件即服务(SaaS)

容器本质
容器的本质是进程，容器就是未来云计算系统中的进程。

容器和虚拟机对比
容器是应用程序层的抽象，将代码和依赖项打包在一起。多个容器可以在同一台计算机上运行，​​并与其他容器共享OS内核，每个容器在用户空间中作为隔离的进程运行。容器占用的空间少于VM，可以处理更多的应用程序，并且需要的VM和操作系统更少。

虚拟机: 在物理机模拟整台机器包含硬件 每台虚拟机就是自己的操作系统，虚拟机一旦 开启，预分配的资源全部占用
·
容器：和 宿主机共享硬件和操作系统实现资源动态分配 容器包含所有的依 赖包都与其他容器共享内核

docker基本概念
Docker系统有两个程序：docker服务端和docker客户端

Docker服务端：
是一个服务进程，管理着所有的容器。
Docker客户端：
是docker服务端的远程控制器，可以用来控制docker的服务端进程。

docker的优势

交付物标准化
Docker是软件工程领域的"标准化"交付组件，最恰到好处的类比是"集装箱"。
集装箱将零散、不易搬运的大量物品封装成一个整体，集装箱更重要的意义在于它提供了一种通用的封装货物的标准，卡车、火车、货轮、桥吊等运输或搬运工具采用此标准，隧道、桥梁等也采用此标准。以集装箱为中心的标准化设计大大提高了物流体系的运行效率。
传统的软件交付物包括：应用程序、依赖软件安装包、配置说明文档、安装文档、上线文档等非标准化组件。
Docker的标准化交付物称为"镜像"，它包含了应用程序及其所依赖的运行环境，大大简化了应用交付的模式。

一次构建，多次交付
类似于集装箱的"一次装箱，多次运输"，Docker镜像可以做到"一次构建，多次交付"。当涉及到应用程序多副本部署或者应用程序迁移时，更能体现Docker的价值。

应用隔离
集装箱可以有效做到货物之间的隔离，使化学物品和食品可以堆砌在一起运输。Docker可以隔离不同应用程序之间的相互影响，但是比虚拟机开销更小。
总之，容器技术部署速度快，开发、测试更敏捷；提高系统利用率，降低资源成本。

namespace 命名空间 名字空间
cgroups 资源限制
rootfs 文件系统

Docker三大核心组件

• Docker 镜像 - Docker images
• Docker 仓库 - Docker registeries
• Docker 容器 - Docker containers

Docker仓库
用来保存镜像，可以理解为代码控制中的代码仓库。同样的，Docker 仓库也有公有和私有的概念。
公有的 Docker 仓库名字是 Docker Hub。Docker Hub 提供了庞大的镜像集合供使用。这些镜像可以是自己创建，或者在别人的镜像基础上创建。Docker 仓库是 Docker 的分发部分。

库:registry

公有库:
Docker-hub Daocloud ali 网易蜂巢

私有库:
公司内部使用(自己部署)

分类:
操作系统名称 centos ubuntu
应用名称 nginx tomcat mysql

Tag:
表示镜像版本

Docker 镜像
Docker 镜像是 Docker 容器运行时的只读模板，每一个镜像由一系列的层 (layers) 组成。
每一个镜像都可能依赖于由一个或多个下层的组成的另一个镜像。下层那个镜像是上层镜像的父镜像。

镜像名称：
仓库名称+镜像分类+tag名称(镜像版本)
完整镜像名称:
docker.io/nginx:v1
docker.io/nginx:latest
daocloud.io/centos:6

镜像ID：
64位的id号

基础镜像：
一个没有任何父镜像的镜像，谓之基础镜像。
注意：

Registry中镜像是通过Repository来组织的，而每个Repository又包含了若干个Image。Registry包含一个或多个Repository

Docker 容器
Docker 容器和文件夹很类似，一个Docker容器包含了所有的某个应用运行所需要的环境。每一个 Docker 容器都是从 Docker 镜像创建的。Docker 容器可以运行、开始、停止、移动和删除。每一个 Docker 容器都是独立和安全的应用平台，Docker 容器是 Docker 的运行部分。

二：容器安装部署

使用aliyun docker yum源安装docker 1.19 = 1.20
docker-ce
docker-ee
删除已安装的Docker
(注意：如果系统中存在那么删除)

[root@vcc ~]# yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-selinux \
                  docker-engine-selinux \
                  docker-engine

配置阿里云Docker Yum源

[root@vcc ~]# yum install -y yum-utils device-mapper-persistent-data lvm2 git
[root@vcc ~]# yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

安装指定版本
查看Docker版本：

[root@vcc ~]# yum list docker-ce --showduplicates

安装较旧版本（比如Docker 17.03.2) ：
需要指定完整的rpm包的包名，并且加上–setopt=obsoletes=0 参数：

[root@vcc ~]# yum install -y --setopt=obsoletes=0 \
        docker-ce-17.03.2.ce-1.el7.centos.x86_64 \
        docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch

安装Docker新版本（比如Docker 2010.2)：

[root@vcc ~]# yum install docker-ce-20.10.2.ce  -y
        或者
[root@vcc ~]# yum install docker-ce -y

启动Docker服务

[root@vcc ~]# systemctl enable docker
[root@vcc ~]# systemctl start docker

查看docker版本状态

[root@vcc ~]# docker -v
Docker version 19.03.12, build 48a66213fe

查看docker运行状态：

[root@vcc ~]# docker info
Client:
Debug Mode: false
Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 3
 Server Version: 19.03.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
Profile: default
 Kernel Version: 3.10.0-1062.12.1.el7.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.637GiB
 Name: vcc ID:DW7V:VN63:7P5F:X36D:UPXA:WSXK:NVXU:FG4E:UIKY:ISIZ:AVW3:3RXT
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

三：国内镜像仓库的使用

国内镜像站
https://www.daocloud.io
国外镜像站
https://hub.docker.com

镜像加速器
使用 Docker 的时候，需要经常从官方获取镜像，但是由于显而易见的网络原因，拉取镜像的过程非常耗时，严重影响使用 Docker 的体验。因此 DaoCloud 推出了加速器工具解决这个难题，通过智能路由和缓存机制，极大提升了国内网络访问 Docker Hub 的速度，目前已经拥有了广泛的用户群体，并得到了 Docker 官方的大力推荐。

配置 Docker 镜像站
Linux：

[root@vcc ~]# curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://f1361db2.m.daocloud.io
docker version >= 1.12
{"registry-mirrors": ["http://f1361db2.m.daocloud.io"]}
Success.
You need to restart docker to take effect: sudo systemctl restart docker 
[root@vcc ~]# systemctl restart docker

登陆登出Docker Hub

login     Register or log in to a Docker registry

登录到自己的Docker register，需有Docker Hub的注册账号

[root@vcc ~]# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: 账号
Password: 
Login Succeeded

logout    Log out from a Docker registry

退出登录

 # docker logout
  Remove login credentials for https://index.docker.io/v1/

四：容器深析

Docker的镜像和容器的区别

• Docker镜像

  假设Linux内核是第0层，那么无论怎么运行Docker，它都是运行于内核层之上的。这个Docker镜像，是一个只读的镜像，位于第1层，它不能被修改或不能保存状态。
  一个Docker镜像可以构建于另一个Docker镜像之上，这种层叠关系可以是多层的。第1层的镜像层 称之为基础镜像（Base Image），其他层的镜像（除了最顶层） 称之为父层镜像（Parent Image）。这些镜像继承了他们的父层镜像的所有属性和设置，并在Dockerfile中添加了自己的配置。
  要列出本地所有有效的镜像，可以使用命令

[root@vcc ~]# docker images

Docker容器
Docker容器可以使用命令创建：

[root@vcc ~]# docker run imagename

它会在所有的镜像层之上增加一个可写层。这个可写层有运行在CPU上的进程，而且有两个不同的状态：运行态（Running）和退出态 （Exited）。这就是Docker容器。当使用docker run启动容器，Docker容器就进入运行态，当停止Docker容器时，它就进入退出态。当 有一个正在运行的Docker容器时，从运行态到停止态， 对它所做的一切变更都会永久地写到容器的文件系统中。要切记，对容器的变更是写入到容器的文件系统的，而不是写入到Docker镜像中的。 可以用同一个镜像启动多个Docker容器，这些容器启动后都是活动的，彼此还是相互隔离的。 对其中一个容器所做的变更只会局限于那个容器本身。如果对容器的底层镜像进行修改，那么当前正在运行的容器是不受影响的，不会发生自动更新现象。

64字符的十六进制的字符串来定义容器ID，它是容器的唯一标识符。容器之间的交互是依靠容器ID识别的，由于容器ID的字符太长， 通常只需键入容器ID的前4个字符即可。当然， 还可以使用容器名。

容器名称
–name= Assign a name to the container
–为容器分配一个名字，如果没有指定，会自动分配一个随机名称
–docker run子命令的参数

容器命名方式：

1）使用UUID长命名（“f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”）
2）使用UUID短命令（“f78375b1c487”）
3）使用Name(“vcc”)

注意：
1.这个UUID标识是由Docker deamon生成的。
2.如果你在执行docker run时没有指定–name，那么deamon会自动生成一个随机字符串UUID。
3.但是对于一个容器来说有个name会非常方便，当你需要连接其它容器时或者类似需要区分其它容器时，使用容器名称可以简化操作。无论容器运行在前台或者后台，这个名字都是有效的。
4.如果在使用Docker时有自动化的需求，你可以将containerID输出到指定的文件中（PIDfile）类似于某些应用程序将自身ID输出到文件中，方便后续脚本操作。

--cidfile="": Write the container ID to the file

镜像名称
镜像是Docker最核心的技术之一，也是应用发布的标准格式。无论你是用docker pull image，或者是在Dockerfile里面写FROM image，下载镜像应该是Docker操作里面最频繁的动作之一了。
下面是在本地机器运行docker images的输出结果：

常说的"ubuntu"镜像其实不是一个镜像名称，而是代表了一个名为ubuntu的Repository，同时在这个Repository下面有一系列打了tag的Image，Image的标记是一个GUID，为了方便也可以通过Repository:tag来引用。
那么Registry又是什么呢？Registry存储镜像数据，并且提供拉取和上传镜像的功能。
Registry中镜像是通过Repository来组织的，而每个Repository又包含了若干个Image。
• Registry包含一个或多个Repository
• Repository包含一个或多个Image
• Image用GUID表示，有一个或多个Tag与之关联

注意：
当一个镜像的名称不足以分辨这个镜像所代表的含义时，你可以通过tag将版本信息添加到run命令中，以执行特定版本的镜像。

[root@vcc ~]# docker run ubuntu:14.04

名字空间

• namespace 空间隔离

• cgroup 资源限制

• rootfs 文件系统

  名字空间是 Linux 内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响。

• pid 名字空间

  不同用户的进程就是通过 pid 名字空间隔离开的，且不同名字空间中可以有相同 pid。

• net 名字空间

  有了pid名字空间, 每个名字空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 名字空间实现的，每个 net 名字空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。

• mnt名字空间

  类似 chroot，将一个进程放到一个特定的目录执行。mnt 名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间 中的进程所看到的文件目录就被隔离开了。

• uts 名字空间

  UTS(“UNIX Time-sharing System”) 名字空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非主机上的一个进程。

• user 名字空间

  每个容器可以有不同的用户和组 id, 也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。

五：Docker使用

镜像操作
查看centos所有的镜像:

[root@vcc ~]# docker search centos

凡是镜像大于100的显示出来，小于100的不显示

[root@vcc ~]# docker search centos --stars=100
[root@vcc ~]# docker search centos --filter=stars=100
OFFICIAL [OK]代表官方的
AUTOMATED [OK]代表完整的镜像

拉取镜像：

[root@vcc ~]# docker pull centos
[root@vcc ~]# docker pull daocloud.io/library/centos:7.8.2003

查看本地镜像：

[root@vcc ~]# docker image list
[root@vcc ~]# docker images
[root@vcc ~]# docker image ls

查看镜像详情：

[root@vcc ~]# docker image inspect 镜像id

删除镜像：
删除一个或多个，多个之间用空格隔开，可以使用镜像名称或id

[root@vcc ~]# docker rmi daocloud.io/library/mysql

强制删除：–force
如果镜像正在被使用中可以使用–force强制删除

[root@vcc ~]# docker rmi docker.io/ubuntu:latest --force

删除所有镜像：

[root@vcc ~]# docker rmi $(docker images -q)

#-q查出所有id号
只查看所有镜像的id:

[root@vcc ~]# docker images -q 

容器操作

• 1.启动容器并指定名为server并放后台运行

[root@vcc ~]# docker run --name server -it -d centos:latest /bin/bash

• 2.使用镜像 nginx:latest，以后台模式启动一个容器,将容器的 80 端口映射到主机的 80 端口,主机的目录 /data 映射到容器的 /data。

[root@blackmed ~]# docker run -p 80:80 -v /data:/data -d nginx:latest

• 3.使用镜像nginx:latest以交互模式启动容器,容器内执行/bin/bash命令。

[root@blackmed ~]# docker run -it nginx:latest /bin/bash

参数：
• -v：文件映射，格式为：主机目录：容器目录
• -d: 后台运行容器，并返回容器ID；
• -i: 以交互模式运行容器，通常与 -t 同时使用；
• -p: 端口映射，格式为：主机(宿主)端口:容器端口
• -t: 为容器重新分配一个伪输入终端，通常与 -i 同时使用；
• --name="nginx-lb": 为容器指定一个名称；
• --dns 8.8.8.8: 指定容器使用的DNS服务器，默认和宿主一致；
• --dns-search example.com: 指定容器DNS搜索域名，默认和宿主一致；
• -h "mars": 指定容器的hostname；
• -e username="ritchie": 设置环境变量；
• --cpuset-cpus="0-2" or --cpuset-cpus="0,1,2": 绑定容器到指定CPU运行；
--privileged 以特权模式运行

• 4.查看容器

  只查看运行状态的容器：

[root@vcc ~]# docker ps
[root@vcc ~]# docker ps -a
-a 查看所有容器
只查看所有容器id:
[root@vcc ~]# docker ps -a -q
列出最近一次启动的容器
[root@vcc ~]# docker ps -l

• 5.查看容器详细信息

[root@vcc ~]# docker inspect 1fbf6
[
{
"Id": "1fbf6d9c50217c0f630fec1f98c6647e38e2371af94f2860d34674eeffd42f84",
"Created": "2020-08-12T15:52:39.064893415Z",
"Path": "/docker-entrypoint.sh",
"Args": [
"nginx",
"-g",
"daemon off;"
],
"State": {
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
......

• 6.启动容器

[root@vcc ~]# docker start name     

• 7.关闭容器

[root@vcc ~]# docker stop name
退出不关闭：
快捷键：ctrl +p+q

• 8.删除容器

 [root@vcc ~]# docker rm 容器id或名称
要删除一个运行中的容器，添加 -f 参数
根据格式删除所有容器：
[root@vcc ~]# docker rm $(docker ps -a -q)

---

---

---

Docker容器管理及镜像制作

一：创建自己的镜像

1.将容器的文件系统打包成tar包
将容器的文件系统打包成tar文件,也就是把正在运行的容器直接导出为tar包的镜像文件。
导出：

export
Export a container's filesystem as a tar archive
有两种方式（elated_lovelace为容器名）：
第一种：
[root@vcc ~]# docker export -o elated_lovelace.tar elated_lovelace
第二种：
[root@vcc ~]# docker export 容器名称 > 镜像.tar

导入：
导入镜像归档文件到其他宿主机：

import
Import the contents from a tarball to create a filesystem image
[root@vcc ~]# docker import elated_lovelace.tar elated_lovelace:v1  

注意：
如果导入镜像时没有起名字，随后可以单独起名字(没有名字和tag)，可以手动加tag。

[root@vcc ~]# docker tag 镜像ID mycentos:7  

2.镜像迁移
保存一台宿主机上的镜像为tar文件，然后可以导入到其他的宿主机上。

save
Save an image(s) to a tar archive
将镜像打包，与下面的load命令相对应
[root@vcc ~]# docker save -o nginx.tar nginx
load
Load an image from a tar archive or STDIN
与上面的save命令相对应，将上面sava命令打包的镜像通过load命令导入
[root@vcc ~]# docker load < nginx.tar

注：

1.tar文件的名称和保存的镜像名称没有关系
2.导入的镜像如果没有名称，自己打tag起名字

3.通过容器创建本地镜像
背景：
容器运行起来后，又在里面做了一些操作，并且要把操作结果保存到镜像里。
方案：
使用 docker commit 指令，把一个正在运行的容器，直接提交为一个镜像。commit 是提交的意思,类似告诉svn服务器我要生成一个新的版本。
例子：
在容器内部新建了一个文件

[root@vcc ~]# docker exec -it 4ddf4638572d /bin/sh
root@4ddf4638572d:/app# touch test.txt
root@4ddf4638572d:/app# exit
# 将这个新建的文件提交到镜像中保存
[root@vcc ~]# docker commit 4ddf4638572d vcc/helloworld:v2

例子：

[root@vcc ~]# docker commit -m "my images version1" -a "vcc" 108a85b1ed99 daocloud.io/ubuntu:v2
sha256:ffa8a185ee526a9b0d8772740231448a25855031f25c61c1b63077220469b057
-m 添加注释
-a 作者
108a85b1ed99 容器环境id
daocloud.io/ubuntu:v2 镜像名称：hub的名称/镜像名称：tag
-p，–pause=true 提交时暂停容器运行

二：利用Dockerfile创建镜像

通过Dockerfile创建镜像，虽然可以自己制作 rootfs(根文件系统)，但Docker 提供了一种更便捷的方式，叫作 Dockerfile。
docker build命令用于根据给定的Dockerfile和上下文以构建Docker镜像。
docker build语法：

[root@vcc ~]# docker build [OPTIONS] 

1. 常用选项说明

–build-arg，设置构建时的变量
–no-cache，默认false。设置该选项，将不使用Build Cache构建镜像
–pull，默认false。设置该选项，总是尝试pull镜像的最新版本
–compress，默认false。设置该选项，将使用gzip压缩构建的上下文
–disable-content-trust，默认true。设置该选项，将对镜像进行验证
–file, -f，Dockerfile的完整路径，默认值为‘PATH/Dockerfile’
–isolation，默认–isolation=“default”，即Linux命名空间；其他还有process或hyperv
–label，为生成的镜像设置metadata
–squash，默认false。设置该选项，将新构建出的多个层压缩为一个新层，但是将无法在多个镜像之间共享新层；设置该选项，实际上是创建了新image，同时保留原有image。
–tag, -t，镜像的名字及tag，通常name:tag或者name格式；可以在一次构建中为一个镜像设置多个tag
–network，默认default。设置该选项，Set the networking mode for the RUN instructions during build
–quiet, -q ，默认false。设置该选项，Suppress the build output and print image ID on success
–force-rm，默认false。设置该选项，总是删除掉中间环节的容器
–rm，默认–rm=true，即整个构建过程成功后删除中间环节的容器

2. PATH | URL | -说明

给出命令执行的上下文。
上下文可以是构建执行所在的本地路径，也可以是远程URL，如Git库、tarball或文本文件等。如果是Git库，如https://github.com/docker/rootfs.git#container:docker，则隐含先执行 git clone --depth 1 --recursive，到本地临时目录；然后再将该临时目录发送给构建进程。
构建镜像的进程中，可以通过ADD命令将上下文中的任何文件（注意文件必须在上下文中）加入到镜像中。

-表示通过STDIN给出Dockerfile或上下文。
示例：

[root@vcc ~]# docker build - < Dockerfile

说明：该构建过程只有Dockerfile，没有上下文

[root@vcc ~]# docker build - < context.tar.gz

说明：其中Dockerfile位于context.tar.gz的根路径

[root@vcc ~]# docker build -t champagne/bbauto:latest -t champagne/bbauto:v2.1 .
[root@vcc ~]# docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .

3. 创建镜像所在的文件夹和Dockerfile文件
命令：

mkdir sinatra
cd sinatra
touch Dockerfile 

4. 在Dockerfile文件中写入指令，每一条指令都会更新镜像的信息

# This is a comment
FROM daocloud.io/library/ubuntu
MAINTAINER vcc [email protected]
RUN apt-get update && apt-get install -y ruby ruby-dev  

格式说明：
每行命令都是以 INSTRUCTION statement 形式，就是命令+ 清单的模式。命令要大写，"#"是注解。
FROM 命令是告诉docker 的镜像什么。
MAINTAINER 是描述 镜像的创建人。
RUN 命令是在镜像内部执行。就是说他后面的命令应该是针对镜像可以运行的命令。

5.创建镜像
命令：

docker build -t vcc/sinatra:v2 .
docker build  是docker创建镜像的命令 

-t 是标识新建的镜像
sinatra是仓库的名称
:v2 是tag "."是用来指明 的使用的Dockerfile文件当前目录

详细执行过程：

[root@master sinatra]# docker build -t vcc/sinatra:v2 .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM daocloud.io/ubuntu:14.04
Trying to pull repository daocloud.io/ubuntu ...
14.04: Pulling from daocloud.io/ubuntu
f3ead5e8856b: Pull complete
Digest: sha256:ea2b82924b078d9c8b5d3f0db585297a5cd5b9c2f7b60258cdbf9d3b9181d828
---> 2ff3b426bbaa
Step 2 : MAINTAINER vcc [email protected]
---> Running in 948396c9edaa
---> 227da301bad8
Removing intermediate container 948396c9edaa
Step 3 : RUN apt-get update && apt-get install -y ruby ruby-dev
...
Step 4 : RUN gem install sinatra
---> Running in 89234cb493d9

6.创建完成后，从镜像创建容器

[root@vcc ~]# docker run -t -i vcc/sinatra:v2 /bin/bash

三：容器文件系统

• namespace
• cgroup
• rootfs

IAAS:基础设施及服务 openstack
PAAS:平台及服务
SAAS：软件及服务

问题：
Namespace 的作用是"隔离"，它让应用进程只能看到该 Namespace 内的"世界"；而 Cgroups 的作用是"限制"，它给这个"世界"围上了一圈看不见的墙。这么一折腾，进程就真的被"装"在了一个与世隔绝的房间里，而这些房间就是 PaaS 项目赖以生存的应用"沙盒"。
可是，还有一个问题：这个房间四周虽然有了墙，但是如果容器进程低头一看地面，又是怎样一副景象呢？
换句话说，容器里的进程看到的文件系统又是什么样子的呢？
可能你立刻就能想到，这一定是一个关于 Mount Namespace 的问题：容器里的应用进程，理应看到一份完全独立的文件系统。这样，它就可以在自己的容器目录（比如 /tmp）下进行操作，而完全不会受宿主机以及其他容器的影响。
那么，真实情况是这样吗？
一段小程序：作用是，在创建子进程时开启指定的 Namespace。使用它来验证一下刚刚提到的问题。

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define STACK_SIZE (1024 * 1024)
static char container_stack[STACK_SIZE];
char* const container_args[] = {
"/bin/bash",
NULL
};
int container_main(void* arg)
{
printf("Container - inside the container!\n");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}
int main()
{
printf("Parent - start a container!\n");
int container_pid = clone(container_main, container_stack+STACK_SIZE, CLONE_NEWNS | SIGCHLD , NULL);
waitpid(container_pid, NULL, 0);
printf("Parent - container stopped!\n");
return 0;
}

代码功能非常简单：在 main 函数里，通过 clone() 系统调用创建了一个新的子进程 container_main，并且声明要为它启用 Mount Namespace（即：CLONE_NEWNS 标志）。
而这个子进程执行的，是一个"/bin/bash"程序，也就是一个 shell。所以这个 shell 就运行在了 Mount Namespace 的隔离环境中。
编译一下这个程序：

[root@vcc ~]# gcc -o ns ns.c
[root@vcc ~]# ./ns
Parent - start a container!
Container - inside the container!

这样，就进入了这个"容器"当中（表面上看不大出来-vcc注）。可是，如果在"容器"里执行一下 ls 指令的话，就会发现一个有趣的现象： /tmp 目录下的内容跟宿主机的内容是一样的。

[root@vcc ~]# ls /tmp
# 可以看到好多宿主机的文件

也就是说：
即使开启了 Mount Namespace，容器进程看到的文件系统也跟宿主机完全一样。
这是怎么回事呢？
仔细思考一下，你会发现这其实并不难理解：Mount Namespace 修改的，是容器进程对文件系统"挂载点"的认知。但是，这也就意味着，只有在"挂载"这个操作发生之后，进程的视图才会被改变。而在此之前，新创建的容器会直接继承宿主机的各个挂载点。
这时，你可能已经想到了一个解决办法：创建新进程时，除了声明要启用 Mount Namespace 之外，还可以告诉容器进程，有哪些目录需要重新挂载，就比如这个 /tmp 目录。于是，在容器进程执行前可以添加一步重新挂载 /tmp 目录的操作：

int container_main(void* arg)
{
printf("Container - inside the container!\n");
// 如果你的机器的根目录的挂载类型是 shared，那必须先重新挂载根目录
// mount("", "/", NULL, MS_PRIVATE, "");
mount("none", "/tmp", "tmpfs", 0, "");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}

在修改后的代码里，在容器进程启动之前，加上了一句 mount(“none”, “/tmp”, “tmpfs”, 0, “”) 语句。就这样，告诉了容器以 tmpfs（内存盘）格式，重int container_main(void* arg)

{
printf("Container - inside the container!\n");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}新挂载了 /tmp 目录。

编译执行修改后的代码结果又如何呢？试验一下：

[root@vcc ~]# gcc -o ns ns.c
[root@vcc ~]# ./ns
Parent - start a container!
Container - inside the container!
[root@vcc ~]# ls /tmp
这次 /tmp 变成了一个空目录，这意味着重新挂载生效了。
用 mount -l 检查：
[root@vcc ~]# mount -l | grep tmpfs
none on /tmp type tmpfs (rw,relatime)

容器里的 /tmp 目录是以 tmpfs 方式单独挂载的。可以卸载一下/tmp目录看看效果。
更重要的是，因为创建的新进程启用了 Mount Namespace，所以这次重新挂载的操作，只在容器进程的 Mount Namespace 中有效。如果在宿主机上用 mount -l 来检查一下这个挂载，你会发现它是不存在的：

在宿主机上

[root@vcc ~]# mount -l | grep tmpfs

这就是 Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效。
希望的是：每当创建一个新容器时，我希望容器进程看到的文件系统就是一个独立的隔离环境，而不是继承自宿主机的文件系统。怎么才能做到这一点呢？
可以在容器进程启动之前重新挂载它的整个根目录"/"。而由于 Mount Namespace 的存在，这个挂载对宿主机不可见，所以容器进程就可以在里面随便折腾了。
在 Linux 操作系统里，有一个名为 chroot 的命令可以帮助你在 shell 中方便地完成这个工作。顾名思义，它的作用就是帮你"change root file system"，即改变进程的根目录到你指定的位置。
假设，现在有一个 /home/vcc/test 目录，想要把它作为一个 /bin/bash 进程的根目录。
首先，创建一个 test 目录和几个 lib 文件夹：

[root@vcc ~]# mkdir -p /home/vcc/test
[root@vcc ~]# mkdir -p /home/vcc/test/{bin,lib64,lib}
然后，把 bash 命令拷贝到 test 目录对应的 bin 路径下：
# cp -v /bin/{bash,ls} /home/vcc/test/bin

接下来，把 ls和bash命令需要的所有 so 文件，也拷贝到 test 目录对应的 lib 路径下。找到 so 文件可以用 ldd 命令：（ldd　列出动态依赖库）

[root@vcc ~]# list="$(ldd /bin/ls | egrep -o '/lib.*\.[0-9]')"
[root@vcc ~]# for i in $list; do cp -v "$i" "/home/vcc/test/${i}"; done
[root@vcc ~]# list="$(ldd /bin/bash | egrep -o '/lib.*\.[0-9]')"
[root@vcc ~]# for i in $list; do cp -v "$i" "/home/vcc/test/${i}"; done

最后，执行 chroot 命令，告诉操作系统，将使用 /home/vcc/test 目录作为 /bin/bash 进程的根目录：

[root@vcc ~]# chroot /home/vcc/test /bin/bash

这时，执行 “ls /”，就会看到，它返回的都是 /home/vcc/test 目录下面的内容，而不是宿主机的内容。
更重要的是，对于被 chroot 的进程来说，它并不会感受到自己的根目录已经被"修改"成 /home/vcc/test 了。
这种视图被修改的原理，是不是跟我之前介绍的 Linux Namespace 很类似呢？
实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux 操作系统里的第一个 Namespace。
为了能够让容器的这个根目录看起来更"真实"，一般会在这个容器的根目录下挂载一个完整操作系统的文件系统，比如 Ubuntu16.04 的 ISO。这样，在容器启动之后，在容器里通过执行 “ls /” 查看根目录下的内容，就是 Ubuntu 16.04 的所有目录和文件。
而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的"容器镜像"。它还有一个更为专业的名字，叫作：rootfs（根文件系统）。

所以，一个最常见的 rootfs，或者说容器镜像，会包括如下所示的一些目录和文件，比如 /bin，/etc，/proc 等等：

[root@vcc ~]# ls /
bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var

而进入容器之后执行的 /bin/bash，就是 /bin 目录下的可执行文件，与宿主机的 /bin/bash 完全不同。
所以，对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：
1.启用 Linux Namespace 配置；
2.设置指定的 Cgroups 参数；
3.切换进程的根目录（Change Root）。
这样，一个完整的容器就诞生了。不过，Docker 项目在最后一步的切换上会优先使用 pivot_root 系统调用，如果系统不支持，才会使用 chroot。这两个系统调用功能类似

• rootfs和kernel：

  rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核，同一台机器上的所有容器，都共享宿主机操作系统的内核。如果你的应用程序需要配置内核参数、加载额外的内核模块，以及跟内核进行直接的交互，你就需要注意了：这些操作和依赖的对象，都是宿主机操作系统的内核，它对于该机器上的所有容器来说是一个"全局变量"，牵一发而动全身。
  在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。
  这是容器相比于虚拟机的缺陷之一：虚拟机不仅有模拟出来的硬件机器充当沙盒，而且每个沙盒里还运行着一个完整的 Guest OS 给应用随便用。
  容器的一致性 ：
  由于云端与本地服务器环境不同，应用的打包过程，一直是使用 PaaS 时最"痛苦"的一个步骤。
  但有了容器镜像（即 rootfs）之后，这个问题被解决了。
  由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。
  对于大多数开发者而言，他们对应用依赖的理解，一直局限在编程语言层面。比如 Golang 的 Godeps.json。但实际上，一个一直以来很容易被忽视的事实是，对一个应用来说，操作系统本身才是它运行所需要的最完整的"依赖库"。
  有了容器镜像"打包操作系统"的能力，这个最基础的依赖环境也终于变成了应用沙盒的一部分。这就赋予了容器所谓的一致性：无论在本地、云端，还是在一台任何地方的机器上，用户只需要解压打包好的容器镜像，那么这个应用运行所需要的完整的执行环境就被重现出来了。
  这种深入到操作系统级别的运行环境一致性，打通了应用在本地开发和远端执行环境之间难以逾越的鸿沟。

  联合文件系统：Union File System 也叫 UnionFS
  Docker 公司在实现 Docker 镜像时并没有沿用以前制作 rootfs 的标准流程，做了一个创新：
  Docker 在镜像的设计中，引入了层（layer）的概念。也就是说，用户制作镜像的每一步操作，都会生成一个层，也就是一个增量 rootfs。用到了一种叫作联合文件系统（Union File System）的能力。
  主要的功能是将多个不同位置的目录联合挂载（union mount）到同一个目录下。

  比如，现在有两个目录 A 和 B，它们分别有两个文件：

[root@vcc ~]# tree
├── A
│ ├── a
│ └── x
└── B
├── b
└── x

然后，使用联合挂载的方式，将这两个目录挂载到一个公共的目录 C 上：

[root@vcc ~]# mkdir C
[root@vcc ~]# yum install funionfs -y //我这里用的是centos7自带的联合文件系统，效果一样
[root@vcc ~]# funionfs -o dirs=./A:./B none ./C

再查看目录 C 的内容，就能看到目录 A 和 B 下的文件被合并到了一起：

[root@vcc ~]# tree ./C
./C
├── a
├── b
└── x

可以看到，在这个合并后的目录 C 里，有 a、b、x 三个文件，并且 x 文件只有一份。这，就是"合并"的含义。
此外，如果在目录 C 里对 a、b、x 文件做修改，这些修改也会在对应的目录 A、B 中生效。

[root@vcc ~]# echo hello >> C/a
[root@vcc ~]# cat C/a
hello
[root@vcc ~]# cat A/a
hello
[root@vcc ~]# echo hello1 >> A/a
[root@vcc ~]# cat A/a
hello
hello1
[root@vcc ~]# cat C/a
hello
hello1

四：企业级Dockerfile文件构建容器

1.Dockerfile文件构建nginx

[root@vcc ~]# cat Dockerfile
FROM centos:7.2.1511
ENV TZ=Asia/Shanghai
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
RUN yum -y install gcc openssl openssl-devel pcre-devel zlib-devel make
ADD nginx-1.14.0.tar.gz /opt/
WORKDIR /opt/nginx-1.14.0
RUN ./configure --prefix=/opt/nginx
RUN make && make install
WORKDIR /opt/nginx
RUN rm -rf /opt/nginx-1.14.0
ENV NGINX_HOME=/opt/nginx
ENV PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/nginx/sbin
EXPOSE 80 443
CMD ["nginx", "-g", "daemon off;"]
注意：
Nginx的docker仓库原文说明如下：
If you add a custom CMD in the Dockerfile, be sure to include -g daemon off; in the CMD in order fornginx to stay in the foreground, so that Docker can track the process properly (otherwise your container will stop immediately after starting)!
Running nginx in debug mode
Images since version 1.9.8 come with nginx-debug binary that produces verbose output when using higher log levels. It can be used with simple CMD substitution:
$ docker run --name my-nginx -v /host/path/nginx.conf:/etc/nginx/nginx.conf:ro -d nginx nginx -g 'daemon off;'
Similar configuration in docker-compose.yml may look like this:
web:
image: nginx
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
command: [nginx, '-g', 'daemon off;']

2.Dockerfile文件构建redis

FROM centos:7.2.1511
MAINTAINER qf
ENV TZ=Asia/Shanghai
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
RUN yum -y install gcc make
ADD redis-4.0.9.tar.gz /opt/
RUN cd /opt/ && mv redis-4.0.9 redis && cd /opt/redis && make && make install
RUN mkdir -p /opt/redis/logs && mkdir -p /opt/redis/data && mkdir -p /opt/redis/conf && cp /opt/redis/redis.conf /opt/redis/conf/ && cp /opt/redis/src/redis-trib.rb /usr/local/bin/
EXPOSE 6379
CMD ["redis-server","/opt/redis/conf/redis.conf"]
基于哨兵模式的redis镜像
FROM centos:7.2.1511
MAINTAINER redis4 jichujingxiang
ENV TZ=Asia/Shanghai
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
RUN yum -y install gcc make
ADD redis-4.0.9.tar.gz /opt/
ADD run.sh /
RUN cd /opt/ && mv redis-4.0.9 redis && cd /opt/redis && make && make install
RUN mkdir -p /opt/redis/logs && mkdir -p /opt/redis/data && mkdir -p /opt/redis/conf && cp /opt/redis/redis.conf /opt/redis/conf/ && cp /opt/redis/src/redis-trib.rb /usr/local/bin/ && cp /opt/redis/sentinel.conf /opt/redis/conf/ && chmod 777 /run.sh
EXPOSE 6379
CMD ["./run.sh"]
#cat /run.sh
#!/usr/bin/bash
#2018/10/24
#行癫
cd /opt/redis/src/
./redis-server /opt/redis/conf/redis.conf & #这一个要放在后台运行，不然下面的启动不了
./redis-sentinel /opt/redis/conf/sentinel.conf

3.Dockerfile文件构建jenkins

FROM local/c7-systemd
ADD jdk-9.0.1_linux-x64_bin.tar.gz /usr/local/
ADD apache-tomcat-9.0.14.tar.gz /usr/local/
WORKDIR /usr/local/
ENV JAVA_HOME=/usr/local/java
ENV PATH=$JAVA_HOME/bin:$PATH
ENV CATALINA_HOME=/usr/local/tomcat
ENV export JAVA_HOME CATALINA_HOME PATH
RUN mv jdk-9.0.1 java && mv apache-tomcat-9.0.14 tomcat
COPY jenkins.war /usr/local/tomcat/webapps/
EXPOSE 8080
CMD ["/usr/local/tomcat/bin/catalina.sh run"]

END