docker attach 可以连接上 Docker 容器的标准输入，输出和错误输出。比如 docker attach 连接后就能显示容器中用 ENTRYPOINT/CMD 启动进程的输出内容内容。想要断开会话连接怎么做呢？ctrl - c, 控制台是不再显示了，可以容器也被终止了，显然这是一个危险的操作。
ctrl - c 不仅仅关闭了 docker attach 本身，因为它的默认参数 --sig-proxy 是 true，所以 SIGKILL 信号同时传递到了 ENTRYPOINT/CMD 的 PID 1 的进程，所以形成了双杀的效果。我们来试一下
如果是在生产环境下，用 docker attach 连接下控制台看下输出，然后不小心像终止 tail -f 命令一样用 ctrl - c 退出，结果服务断了。所以更为小心的操作还是用 docker logs。 docker attach 的优势只是在于能查看实时的控制台输出。 阅读全文 >>
原本是继续阅读《每天5分钟玩转Kubernetes》一书的，发现该书所用的 Kubernetes 版本着实有点老旧( 1.7), 当前版本是 1.18。操作起来有些不同，所以找来了最新的 《Kubernetes in Action》第二版 来看，该书还在写作当中。第二章全是讲 Docker 的内容，本人读书有个不好的习惯，就是不喜欢跳过跳过。看了总会有收获的，这不，就从中稍微理清了 Docker 容器内进程与 Namespace 的关系。
Docker 容器间的进程本质上是宿主主上的一个进程，它能相互隔离靠的是 chroot, namespace 和 cgroup(对 CPU, 内存，磁盘，带宽等的配额)。千万不要认为启动一个 Docker 容器就是启动了一个虚拟机。
其中 namespace 实现了以下几项资源的隔离
经过前几天从 Docker Swarm 到 Docker Compose 的历练之后，终于踏上了 Kubernetes 的学习征程了。虽说前两者并非必要的学习 Kubernetes 的基础，但了解它们之后与 Kubernetes 中的一些概念可以进行对比理解。
本系列是阅读 《每天5分钟玩转Kubernetes》的笔记，书名倒是来的轻松，对我来说每天 5 分钟根本吸收不了什么知识。如果把阅读该书比作台上的话，基本就是台上 5 分钟，台下 50 分钟都不够，实际操作起来不光是版本有差异，还会出现各种意外带来惊喜与折磨。另外该书所采用的版本是 Kubernetes 1.7.4, 当前为 1.18，有不小的差别。
Kubernetes 是当今容器编排引擎的事实标准，以前为 Google 内部项目的 Omega 开源为 Kubernetes。传说中的容器编排三足鼎力，Kubernetes, Docker Swarm 和 Apache Mesos, 现在已是 Kubernetes 的一骑绝尘。Mac 下的 Docker Desktop 版本已内置了 Kubernetes 的支持。AWS 中在 ECS 外也支持了 EKS(Elastic Kubernetes Service)。 阅读全文 >>
继续向 Kubernetes 进发，上一篇 Docker Swarm 集群模式实操 了解完 Swarm 后，有必要对 Docker Compose 了解一番。Docker Swarm 是把 Docker 宿主机组成集群，部署服务时只要告知 Manager 节点，它就会自动找到相应节点去运行相应的容器。Compose 完全是另一个概念，它把相关联的多个容器组织成一个整体来部署，如由负载容器，多个 Web 容器和一个 Redis 缓存容器构成一个整体。
由其名 Compose 正式有了容器编排这么一个概念，后来将要学的 Kubernetes 是更高级别的组织，运行，管理容器的工具。Compose 由于把容器组织起来了，所以能够一条命令启动多个相关联的容器，而无需单独启动一个一个的容器。
关于 Docker Compose 的安装，在 Mac OS X 下的 Docker Desktop 自带了 docker-compose; 由于 Docker Compose 是用 Python 编写的，我们可以用 pip install docker-compose 的安装，安装后使用它的命令就是 docker-compose。
下方的 Docker Container, Swarm, Compose 三者之间的关系图很形像 阅读全文 >>
在正式进入 Kubernetes 之前希望能对早先的 Docker Swarm 有所了解，虽然它目前基本上没什么用处。Swarm 提供的是 Docker 宿主机的集群，集群中至少有一个 Manager(或多个), 再加上 0 或多个 Worker。它的大意是有个 Docker 服务(容器)通过 Manager 告诉用所管理的 Swarm 集群来执行，它就会在该集群中找到相应的宿主机来执行。Manager 和 Workder 都可用来运行 Docker 容器，但只有 Manager 才能执行部分管理命令。
下面两张图很好的体现了我们平时在一个宿主机上和 Swarm 集群宿主机上运行 Docker 容器的区别
 所有容器自己扛 |
=> | 容器大家一起扛 |
Docker 在 1.12 之后自带了 Swarm 模式。本文实质上对 使用Docker Swarm模式搭建Swarm集群 的一次实际操作与体验。只是自己方便使用了三个 Vagrant 虚拟机进行实践，其中一个 Swarm Manager 节点，两个 worker 节点 阅读全文 >>
我们在运行 docker 镜像时希望能用下面的命令向容器传递命令行参数
docker run <image-name> <command> arg1 arg2
docker run <image-name> arg1 arg2
其实只有第一种形式，紧随镜像名后那个总是一个命令，其后才是参数。如果要向 docker 容器传递参数时，Dockerfile 该如何写，这就有必要稍稍了解一下 Dockerfile 中 CMD 和 ENTRYPOINT 这两个指令，并且它们有 exec 和 shell 两种格式的写法。详情请见上篇 Dockerfile 中命令的两种书写方式的区别。
对于一个 docker 镜像，我们可以这么来理解 ENTRYPOINT 与 CMD 的关系
docker run <image> 后的命令覆盖，同时覆盖参数对于 #1 和 #2 更精致的理解是容器运行的最终入口由 ENTRYPOINT 和实际的 CMD 拼接而成。ENTRYPOINT 和 CMD 需转换为实际镜像中的 exec 格式来拼接，合并后的第一个元素是命令，其余是它的参数。 阅读全文 >>
最早的初衷是要研究一下运行 Docker 容器时如何向其传递参数，却冷不防掉入了另一个深渊，不得不关心起 Dockerfile 中命令(包括 RUN, CMD 和 ENTRYPOINT) 的两种不同写法上的区别。
所以呢，先要稍稍了解一下 Dockerfile 中 RUN, CMD, ENTRYPOINT 这三个指令
关于以上三个命令的区别，这儿有篇文章讲得很清楚 RUN vs CMD vs ENTRYPOINT - 每天5分钟玩转 Docker 容器技术（17），此处也照搬了些文字。
RUN, CMD 和 ENTRYPOINT 都支持两种写法，即 exec 和 shell 格式，见 Dockerfile reference #ENTRYPOINT 对这两种方式的解释。RUN 只影响如何构建镜像，所以镜像中不保留 RUN 命令。CMD 和 ENTRYPOINT 都可以在运行容器时执行命令，这里不讲述它们间的区别，而要说的是它们所支持的 exec 和 shell 两种格式的写法。此篇以 ENTRYPOINT 为例说明两种格式的区别，CMD 类似。 阅读全文 >>