关于安装
到以下地址查询最新的安装版本
https://github.com/docker/compose/releases
然后可以下面的脚本
sudo curl -L "https://github.com/docker/compose/releases/download/1.28.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
docker-compose --version
因为不同容器之间的 network namespace 隔离，所以各个容器的 localhost 回环地址也只能指向自己
不过在 k8s 下，同一 pod 内的容器之间，实际上是可以使用 localhost来互相访问的，这是为什么呢？
k8s 的 pod 中会默认运行一个名字叫pause的容器，其他的容器就挂到这个 pause 上面，也就是使用了 docker run –net container
docker run -i -t --name pause busybox sleep infinity
docker run -i -t --name nginx --net container:pause nginx
docker run -i -t --name watcher --net container:pause ubuntu sleep infinity
docker exec -i -t watcher /bin/bash
容器内
apt update
apt install curl
curl localhost:80
Docker link 实际上已经被标注为 过时 了，但是仍然有一些传统应用在使用它
最典型的是链接 web 应用和 数据库
例如要启动一个 WordPress 就可以
docker run --name wp_mysql -p 3306:3306 -v /data/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123 -d mysql:5.7
docker run --name wp_web --link wp_mysql:mysql -v /data/wordpress:/var/www/html -p 80:80 -p 443:443 -d wordpress:5.6.0使用了 –link 的 WordPress docker 部署，是不需要再配置 mysql 数据库连接就可以直接连上 数据库 的。
这里主要想讨论， link 到底 link 了什么
首先，这里需要明确两个概念，上面的 mysql 是 源容器，是被连接容器，WordPress 是目标容器，是接收容器
为了进行下面的测试，我们启动两个 busybox 容器，把它们连接在一起
docker run -i -t --name source -p 3001:3001 -p 3002:3002 -e source_env_1=123 -e source_env_2=456 busybox sleep infinity
docker run -i -t --name target -p 3003:3003 -p 3004:3004 -e target_env_1=123 -e target_env_2=456 --link source:mysource busybox sleep infinity
–link wp_mysql:mysql
对于 WordPress 容器而言，wp_mysql 和 mysql 是一个容器，有着同样的 containerid
–link source:mysource
对于 target 容器而言，source 和 mysource 是一个容器
2. DNS
3. 环境变量
上面WordPress之所以直接可以连接数据库，实际上是使用了环境变量
WordPress的镜像默认会从 mysql 这个别名来读取 数据库 配置，所以这里如果写成 –link wp_mysql:test_mysql ，WordPress是无法识别到数据库的，可以理解成这是一个约定
Target 容器会得到 如下环境变量
4. 如果 source 容器的 ip 发生变化 的情况
删除source容器之后，我创建一个 Nginx容器，占用原来source容器的
172.17.0.2 ip 可以看到 新的ip 是 172.17.0.4
此时，在target容器中，没有任何信息被更新
启动一个target2 容器，就可以看到 dns 和 env 都换成新的了
对于需要在容器外持久化的数据，需要使用 mount
早期的docker只能挂载本地磁盘路径，也就是下面的第一种方式
第一种方式 直接挂载本地路径
docker run -d -it --name=nginx1 -p 8001:80 -v ~/tmp:/usr/share/nginx/html nginx这种方式下，docker不会覆盖本地路径下的任何文件内容
也就是说，如果本地路径 tmp 中没有文件，那么挂载之后，容器在挂载的路径下，也会 没有任何文件
这是一种， 使用本地内容 覆盖 容器对应路径内容 的方式
第二种方式 创建由docker管理的volume
docker volume create tmpvol
docker run -d -it --name=nginx2 -p 8002:80 -v tmpvol:/usr/share/nginx/html nginx这种方式的方便之处在于，它在持久化数据的同时，还可以继续使用容器内自带的内容
这是一种，仍然使用容器内容 存储到 指定的 volume 的方式
在Linux上，想要直接从宿主机访问这个路径非常容易
路径如下
在MacOS上就相对复杂一些，因为MacOS的 docker desktop 也是基于虚拟机实现的
旧版本的docker desktop 使用下面的命令附着到 tty之后，可以访问上面和 linux类似的路径
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty然而在 3.1.0 的版本中，我没有找到这个tty文件
实际上是，这个操作反而变得比以前简单了
注意到右上角的 CLI 图标了么？
只不过这种方式不是在宿主机上，而是 docker exec 提供的 sh
通常情况下，诸如 apache2、tomcat 和 mysql 等服务进程，是不会直接停止的，所以在这种情况下 docker run 和 docker start 都不会直接退出
docker run -i -t –name nginx nginx
参数 -i -t 是提供交互式shell的根本
Linux 系统中想要对进程进行干涉，需要发送一些特定的信号
这些信号有几十种这里就不一一例举了
要停止或者终止一个进程比较常用的是以下三种，
其中 SIGTERM 和 SIGINT 信号会按照程序自定义的逻辑来处理这些信号，例如下面这个Java程序
import sun.misc.Signal;
import sun.misc.SignalHandler;
@SuppressWarnings("restriction")
public class Test {
public static void main(String[] args) {
System.out.println("Signal handling example.");
SignalHandler handler = new MySignalHandler();
// kill命令
Signal termSignal = new Signal("TERM");
Signal.handle(termSignal, handler);
// ctrl+c命令
Signal intSignal = new Signal("INT");
Signal.handle(intSignal, handler);
try {
Thread.sleep(50000);
} catch (InterruptedException e) {
System.out.println("Interrupted: " + e.getMessage());
}
}
}
@SuppressWarnings("restriction")
class MySignalHandler implements SignalHandler {
@Override
public void handle(Signal signal) {
System.out.println("Signal handler called for signal " + signal);
try {
System.out.println("Handling " + signal.getName());
} catch (Exception e) {
System.out.println("handle|Signal handler" + "failed, reason "
+ e.getMessage());
e.printStackTrace();
}
}
}
使用 ctrl + c 对其发送 SIGINT 信号时，它只是输出了信息，并没有停止自己
使用kill PID发送 SIGTERM信号之后，它只是输出了信息，并没有停止自己
最后是 kill -9 PID 的 SIGKILL信号，直接杀死了
要停止容器的话，最常用的是 docker stop
stop 命令本质上是向该进程（例如Nginx进程）发送 SIGTERM 信号，大多数应用都能正确的响应这个信号，开始停止自己
如果出现了特殊情况，就需要使用 docker kill container_name 来发送 SIGKILL
关于最小镜像
可以直接下载 (pull) 的最小镜像为 alpine
Alpine Linux是一个基于BusyBox和Musl Libc的Linux发行版，其最大的优势就是小，在我写下这篇文章时，最新的版本为 3.12.4，大小只有 2.67M
https://hub.docker.com/_/alpine
alpine 衍生了很多社区版本，基本都以小为主要目的
实际上alpine并不是最小镜像，还有一个叫做 scratch 的空镜像
scratch 连最基本的 /bin、/usr、/lib、/dev 都没有提供
通过go语言编写一个helloworld并且把代码编译成 二进制 格式，直接使用
CMD “./hello”
会报如下错误，这个是因为scratch镜像连最基本的 sh 都没有提供
上面这种情况，需要对 CMD 的格式进行一些修改
FROM library/golang:alpine as base
COPY hello.go /hello.go
WORKDIR /
RUN go build /hello.go
FROM scratch
COPY --from=base /hello /hello
CMD [ "/hello" ]通过这种方式构造的镜像，只有 1.94MB
Docker的镜像从面向对象的角度上看，更类似于class，而容器则是通过它创建的对象
Docker生态圈存在大量的镜像仓库，当然最知名的还是 https://hub.docker.com/
我们知道 docker image 是分层的，例如以下Nginx镜像
我们在 Docker和虚拟机的区别 中提到过，容器会覆盖掉Linux宿主机的rootfs层
从而在宿主机之上构建出虚拟的 Ubuntu、CentOS、Busybox、CoreOS 等环境
其中使用的原理是 copy-on-write，
容器层叫做可写层，容器层之下都叫做镜像层
所有对容器的改动，无论添加、读写还是删除，都只会发生在容器层中，只有容器层是可写的，容器层之下的镜像层都是只读的
docker容器和虚拟机的共同点在于，都可以在宿主机上提供 虚拟化 环境，各个虚拟环境是相互隔离的
它们的主要区别在于
虚拟机是base在硬件层上的，也就是硬件级别的虚拟化，虚拟机有独立的虚拟硬件，独立的虚拟bios，独立的虚拟驱动
而docker base在rootfs层上的
Linux系统的最底层是 系统kernel，一个典型的Linux启动需要两个File system
bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了
rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。
由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs
如果你的应用需要特定的系统内核例如只能运行在 Linux 内核2.6上，那么此应用不适合使用docker，此时应该选择虚拟机方案
大多数的应用，都不依赖于内核
早在2013年，我一直把容器当成虚拟机来使用
直到2021年的今天，仍然有很多人都习惯将 ubuntu或者centos 容器当做虚拟机来使用，启动进程 /bin/bash
实际上，这样做是不合适的
比起虚拟机，容器实际上更类似于 windows 的程序安装包 和 linux 上的 rpm 和 dpkg 安装包，但又不完全相同
安装包的最终目的是让用户 “通过最简单的方式，安装和运行一个应用程序”
通常安装包会拷贝文件，并且设置一些相关的配置，有些需要本地编译，然后设置环境变量等等，但是安装有一个缺点，如果你安装了 Python2 又安装了 Python3 可能会带来一些依赖库之类的环境冲突
Docker 实际上提供了类似于 安装包一样的 一键安装部署应用的 能力，同时又提供了类似 conda 的环境隔离（甚至是网络隔离等等）
在没有Docker以前，如果需要把开发完成的应用程序部署到用户的服务器，通常你可能需要
在Docker出现之后，只需要使用image创建对应的container就可以获得全部的 环境变量 和 环境依赖，这在以前是不可想象的，例如启动一个标准的 mysql 服务
docker run -itd --name mysql-test -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql除了能够快速发布到生产环境，docker的这种快速启动优势还可以应用在许多 POC 场景，快速的试验各种版本，吞吐量，稳定性 和 兼容性 的测试，都可以基于docker实现
在Docker出现以前，想快速分发 dev 的开发环境，还有一种选择是通过 基于 vagrant 使用的 virtual box，实际上这种实践有些类似于 “基础设施既代码” 的概念，使用 Vagrantfile 来定义需要的配置，通过virtualbox的 box 文件来分发本地开发需要的环境
但是virtualbox本质上是虚拟机，虚拟机和docker还是有很大区别的