docker

install:

sudo yum install -y yum-utils


sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo yum install docker-ce docker-ce-cli containerd.io

sudo systemctl start docker

sudo systemctl enable docker

 sudo docker run hello-world

测试环境：

使用docker 启动mysql 做为测试环境：

拉取镜像：

docker pull mysql:latest
运行容器：

docker run -itd --name mysql-test -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql (这里123456是root的密码)
然后就可以在远程访问使用了：

mysql -u root -p -h 192.168.xx.xx(mysql 容器所在的机器)

docker port  查看端口
docker inspect  查看容器配置
docker inspect --format='{{.NetworkSettings.IPAddress}}'  container-name  查看容器ip

sh-5.0$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
elastic+ 1 0.0 0.0 2484 368 ? Ss 08:37 0:00 /bin/tini -- /usr/local/bin/docker-entrypoint.sh eswrapper
elastic+ 6 17.0 55.6 6864804 4456332 ? Sl+ 08:37 1:22 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress
elastic+ 297 0.0 0.0 108328 4152 ? Sl+ 08:38 0:00 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/c
elastic+ 359 0.1 0.0 4100 2060 ? Ss 08:45 0:00 /bin/sh
elastic+ 367 0.0 0.0 5884 1476 ? R+ 08:45 0:00 ps aux

pid等于1的进程是 entrypoint.sh 也就是 tini 可做进程管理

当你运行一个Docker容器时，镜像的ENTRYPOINT就是你的根进程，即PID 1(如果你没有ENTRYPOINT，那么CMD就会作为根进程，

你可能配置了一个shell脚本，或其他的可执行程序，容器的根进程具体是什么，完全取决于你的配置)。

与其他进程不同的是，PID 1有一个独特的职责，那就是收割“僵尸进程”。

那何为“僵尸进程”呢？

“僵尸进程”是指：

• 已经退出。
• 没有被其父进程wait(wait是指syscall父进程用于检索其子进程的退出代码)。
• 父进程已丢失(也就是说，它们的父进程已经不存在了)，这意味着他们永远不会被其父进程处理。

当“僵尸进程”被创建时(也就是说，一旦它的父进程非正常退出了，它也就跟着无法正常退出了)，它会继承成为PID 1的子级，最后PID 1会负责关闭它。

换句话说，有人必须在“不负责任”的父进程离开后，对这些“孤儿”进行清理，这是PID 1的作用。

请注意，创建“僵尸进程”通常是不被允许的(也就是说，理想情况下，您应该修复代码，这样就不会创建“僵尸进程”)，但是对于像Jenkins这种应用来说，它们是不可避免的：因为Jenkins通常运行的代码不是由Jenkins维护者编写的(也就是您的Jenkins构建脚本)，所以他们也无法“修复代码”。

这就是Jenkins使用Tini的原因：在构建了创建“僵尸进程”的脚本后进行清理。

但其实Bash实际上也做同样的事情(收割“僵尸进程”)，所以你可能会想：为什么不把Bash当作PID 1呢？

第一个问题是，如果您将Bash作为PID 1运行，那么您发送到Docker容器的所有信号(例如，使用docker stop或docker kill)最终都会发送到Bash，Bash默认不会将它们转发到任何地方(除非您自己编写代码实现)。换句话说，如果你使用Bash来运行Jenkins，那么当你运行docker stop的时候，Jenkins将永远收不到停止信号！

而Tini通过“信号转发”解决了这个问题：如果你向Tini发送信号，那么它也会向你的子进程发送同样的信号(在你的例子中是Jenkins)。

第二个问题是，一旦您的进程退出，Bash也会继续退出。如果您不小心，Bash可能会退出，退出代码为0，而您的进程实际上崩溃了(但0表示“一切正常”；这将导致Docker重启策略不符合您的预期)。因为您真正想要的可能是Bash返回与您的进程相同的退出代码。

请注意，您可以通过在Bash中创建信号处理程序来实际执行转发，并返回适当的退出代码来解决这个问题。另一方面，这需要做更多的工作，而添加Tini只是文档中的几行。

如果Jenkins以PID 1运行，那么它可能不会接收到您发送的信号！

这是PID 1进程中的微妙之处。与其他进程不同的是，PID 1没有默认的信号处理程序，这意味着如果Jenkins没有明确地为SIGTERM安装信号处理程序，那么该信号在发送时将被丢弃(而默认行为是终止该过程)。

Tini确实安装了显式信号处理程序(顺便说一下，是为了转发信号)，所以这些信号不再被丢弃。相反，它们被发送到Jenkins，Jenkins并不像PID 1(Tini )那样运行，因此有默认的信号处理程序(注意：这不是Jenkins使用Tini的原因，Jenkins使用它来获取信号，但在RabbitMQ的镜像中是这个作用)。