有时候我们在 Mac OS X 或 Windows 平台下需要开发以 Linux 为运行时的应用，IDE 或可直接使用 Docker 容器，或 SSH 远程连接。本地命令行下操作虽然可以用docker exec连接正在运行的容器，但 IDE 远程连接的话 SSH 总是一种较为通用的连接方式，所以我们希望做一个能进行 SSH 连接的 Docker 容器。因为是本地运行的 Docker，我们想直接用 root 连接，以获得在容器中最大的运行权限。下面以 ubuntu:2004 基础镜像为例，看如何安装启用 ssh 服务以及允许 root 连接。创建允许 root + 密码登陆的镜像
我们创建一个基本的 Dockerfile 文件，内容为 Read More- 不觉一晃还是在五年前记录过一篇 Dockerfile 中命令的两种书写方式的区别，其中提到过 Dockerfile 中可选择用 ENTRYPOINT 或 CMD 来启动进程，并且在 ENTRYPOINT 和 CMD 都支持 exec, shell 和增强型 shell 方式。如果同时有 ENTRYPOINT 和 CMD(或 docker 运行时的 CMD), 则 CMD 将为 ENTRYPOINT 提供参数。
在原来那篇文中认为 shell 无法接收到 docker stop 或 docker -s SIGTERM 发来的信号，也许是随着 Docker 版本的变迁，Docker 变得越发聪明了起来，无论何种格式的 ENTRYPOINT, 都能够收到 SIGTERM 信号，比如在 Java 的 ShutdownHook 能捕捉到该信号，得以在进程停止之前作必要的清理工作。
进行本文相关研究的主因是部署在 ECS(Fargate) 中的 Java Web 服务，Task 总是因为 OutOfMemoryError 被杀掉，而在应用程序日志中却见不着半点线索说 JVM 的 OutOfMemoryError，即使后来给 Fargate 配上了 EFS, 加了+XX:+HeapDumpOnOutOfMemoryError XX:HeapDumpPath=/efsJVM参数，在任务被 kill 时在 /efs 上从来就都没生成过内存映像文件。最后发现是因为 JVM 的 -Xmx 配置太高，留给 Fargate 容器的太少的缘故。 Read More 突然间研究这个来的缘由是正在从 Jenkins 往 Harness 的过度, 而完全用命令来构建 Docker 镜像变得不一样了。在 Jenkins 中 Agent 本身也是一个 Docker Daemon, 所以 Docker 命令执行无障碍，而 Harness 的所谓的 Agent 就是一个个的运行在 Kubernetes 中的 Docker Container (Pod) 了，这其中没有 Docker Daemon, 又不能连接到 Kubernetes 本身的 Docker Daemon。另外 CloudBees CI/CD 的运行环境与 Harness 类似，也是运行在 Kubernetes 中的 Pod。
因此可能要使用某个 Docker 容器来作为 Docker Daemon, 所以牵连出对此的研究，相应的方案有 Docker in Docker(DinD) 和 Docker outside of Docker(DooD)。
对容器中启动 Docker Daemon 的探索
在知晓 DinD 和 DooD 这两个概念本人还试图构建过一个 Docker 镜像，试图用一个 Docker 容器既作 Docker Daemon 又作为 Docker 客户端。在容器中 Docker 安装成功，但无法在容器中启动 Docker Daemon。比如用下面的 Dockerfile Read More
基于 EC2 的 ECS 服务，要看看容器内的状态，一直以来都是先 SSM(Simple System Manager) 或 SSH 进到 EC2 实例，然后再docker exec -it <container-id> sh, 查看容器的控制台日志则用docker logs <container-id> [--follow]. 但是对使用 Farget 的 ECS 服务就无能为力了，因为找不到 SSM 或 SSH 的主体, 只能通过程序日志来大概了解容器内发生的事了。
Amazon 在 2021-03-15 推出了一个新的特性ECS Exec允许我们直接连接 Fargate 或 EC2 中的容器会话，见 Amazon ECS now allows you to run commands in a container running on Amazon EC2 or AWS Fargate. ECS Exec 支持 Container Agent 版本为 1.50.2 及以上的 ECS Optimized AMI 系列，和 Fargate Platform Version 1.4.0(Linux) 或 1.0.0(Windows) 及以上。
ECS Exec 的实现原理是以往在 EC2 实例上启动的 SSM Agent，也在容器内部启动一份，然后命令aws ecs execute-command直指容器本身。参考本人写过的一篇 AWS Session Manager 管理 EC2 实例，连接过程中唯一的不同就是容器中也运行了一个 SSM Agent, 所以这个容器也就无所谓是在 EC2 实例还是在 Fargate 中。
Read More- 一谈到 Docker 容器，按照以往的惯性思维，那就是 Linux 容器(LXC)，和 Windows 没多大关系，顶多也就是在 Windows 的 Linux 虚拟机中跑 Docker 容器。
不过自从 Windows Server 2016 开始，出现了 Windows 原生的 Docker 容器，它再也不只是 Linux 下的专利了。Docker 容器中可以运行 Windows 系统了, 每个 Windows 容器共享宿主机的 Windows 内核(--isolation=process,)，或使用一个高度优化虚拟机中的 Windows 内核(--isolation=hyperv)。
我们说自 Windows Server 2016 开始，包括现在的 Windows Server 2019, Windows Server 2022, 还有桌面系统的 Windows 10 和 11 上 借助于 Docker Desktop 也能跑 Windows 容器。
原本在 Windows 桌面版上安装 Docker Desktop 就能用来运行 Linux 容器，由此可知在 Windows 桌面版上(如 Windows 7, 10, 11) 可运行两种类型的容器- Linux 容器: 每个容器运行的是 Linux 实例，用 cgcroups 命名空间隔离资源。默认的，使用 Docker Desktop 的 LinuxEngine
- Windows 容器：容器中运行的是 Windows 实例，进程隔离模式是容器共享主 机的 Windows 内核，Hyper-V 隔离模式是容器使用高度优化虚拟机的内核。需启用 Windows 的 Hyper-V 特性，并切换 Docker Desktop 使用 WindowsEngine
Read More - AWS 的 Lambda 在 2020-12-01 开始支持用 Docker 镜像存放代码，见 New for AWS Lambda - Container Image Support。AWS Lambda 最初的对发布包的限制是 50M, 解压后(因为执行前需要解压缩)不能超过 250M，对于压缩比小于 1/5 的包来说，要突破 50M 部署包的限制就要用 2018-11-29 推出的层(layer), 即把 Lambda 的依赖可以组织为层，每个 Lambda 可引用最多 5 个层，但最终 Lambda 加上层所解压后的大小仍然有 250 M 的限制。
对于使用了大量依赖的 Lambda，比如 Python 中用了 Pandas 之类的数学分析包，250M 的大小是不够的，所以才有了 Docker 镜像化的 Lambda, 镜像的大小限制一下蹦到 10G，要构建出一个 10G Lambda 用的 Linux 镜像, 那绝对是个巨兽，至少目前是超越我的想像力，除非往里面塞入大量的业务数据。关于 Lambda 有哪些限制，请参阅 Lambda quotas。
介绍完 Lambda 引入 Docker 镜像的背景后，本文接下来只关注如何构建一个 Python Lambda 镜像，对于如何部署 Docker 化的 Lambda, 不在本文的范围之内。主要的参考文档为 AWS Lambda 官方的 Deploy Python Lambda functions with container images. Read More 本文继上篇 摆脱 Docker Desktop 即将到来的收费 进一步寻找符合自己需求的 Docker Desktop 替代品，前面试用过 hyperkit + minikube, Podman, 最终还是确定了用 docker-machine。之所以选择了它是基于下面几个需求：
- 连接 VPN 后 Docker 还要能继续工作 (通过 socket 文件和 localhost 与 Docker Host 通信不惧怕 VPN 连接. 因为 VPN 会接管路由表，所以用 IP 来连接 Docker Host 的话，VPN 连上后将可能无法访问 Docker Host)
- 能与 IDE 进行集成开发与调试 (IntelliJ IDEA 能与 Docker Desktop, Docker Machine, TCP socket 和 SSH 上的 Docker Host 集成调试，但无法与 Daemonless 的 Podman 集成)
- DOCKER_HOST 能是远程机器 (由于 Podman 设计为 Daemonless，也就没有 Docker Host, 无法进行远程构建)
本文力图更深入的理解 Docker 的架构来解释最后选择的来由，清楚了原理后可以自主创建一个 Docker Host，连 docker-machine 也可以不用。比如创建一个 AWS EC2 实例作为 Docker Host, 然后在本地执行 docker 命令进行镜像的构建与容器的运行，这时候镜像构建过程与容器执行的环境是在 EC2 上，再也不用先把本地的文件上传(scp 或 rsync) 到 EC2 上，然后 ssh 到 EC2 去执行 docker 命令了。
一个小插曲：本人曾经随手在
～/Downloads目录下建立一个只有FROM busybox一行的Dockerfile文件，然后运行docker build ...命令，结果每次都提示磁盘空间不足，本机磁盘还非常宽裕，Docker Machine 也分配了 20 G 内存，怎么会不够了呢？登入到 Docker Machine 后df确实没空间了。四处找原因，原来是docker build ...一执行，不管 3721 首先把当前目录下的所有文件全部拷贝到 Docker Machine 中去，~/Downloads目录中下了几十个 G 的内容，所以把 Docker Machine 给挤暴掉。解决办法就是要把Dockerfile放到一个没有无用文件的独立目录中去，这也是为什么Dockerfile中的COPY命令只能从当前目录中拷贝文件的原因。 Read More- 最近本人在 Mac OS X 下安装的 Docker Desktop 经常蹦出要升级的窗口，
Skip this update PRO不能用，Install & Restart也总是失败，所以每次只能SNOOZE。原来觉得事有蹊跷，后来才知道这或许与近日吵得沸沸扬扬的 Docker Desktop 收费计划有关。Docker Desktop 是专门为 Windows 和 Mac OS X 定制的，Mac OS X 和 Windows 都是开发人员用的平台。Linux 下可以不用 Docker Desktop，Linux 下 Docker 之间甚至一层窗户纸都没有，实际部署的 Docker 服务也是运行在 Linux 下的。
墙里边微信正在谋划着对聊天记录的云存储收年费，外边是 Docker 在向大公司和开发人员下手，这难道是美国加州版的共同富裕？
Read More 常常因为在 AWS 上部署的 ECS 或 EKS 服务，甚至是使用了 ECR 镜像的 Lambda 服务这样或那样的原因无法启动，或其他莫名的异常，这时候最好能直接调试 ECR 上的 Docker 镜像，比调试用于打包 Docker 的源代码更接近真实环境。
要调试 Docker 镜像需要先从 ECR 中下载到 AWS 服务用的镜像，下面以运行 Java 的 Docker 为例，同时用 IntelliJ IDEA 关联源代码进行远程调试。
从 ECR 下载 Docker 镜像部分可参考 推送 Docker 镜像到 Amazon ECR 仓库, 那篇文章写作之时可能与现在略有不同。具体需直接进到 ECR 的页面，如 https://console.aws.amazon.com/ecr/repositories/private/<aws_account_id>/<ecr_name>?region=<region>，点击
View push commands可看到用 AWS CLI 如何登陆 ECR，现在看到的在 macOS/Linux 下的命令是(假设 AWS AccountId 是 123456789, region 是 us-east-1)aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com
假如 ECR 仓库名是 test-java, 那么要下载 tag 1.0.1 的命令是 Read More
Before officially entering into Kubernetes, I hope to know something about the earlier Docker Swarm, although it is basically no long used currently. Swarm provides a cluster of Docker hosts. There is at least one Manager (or more) in the cluster, plus 0 or more Workers. The main idea is that a Docker service (container) is executed by the Swarm cluster manager, and it will find the corresponding host in the cluster to execute the container. Both Manager and Worker can to run Docker containers, but only Manager can execute management commands.
The following two pictures shows the difference between running Docker containers on a host and a Swarm cluster host.
Run all containers in one host=> 
Run container together