Docker

Docker Context 是 Docker 2019 年引入的一个特性，用来管理多个 Docker 主机的上下文，通过切换 context 就能让本地的 docker 命令作用在不同的 Docker 主机上。 本地开发机： docker context use default 远程服务器要配置好 ssh 免密登陆，然后使用下面命令添加 context： docker context create my-server --docker "host=ssh://root@1.2.3.4" docker context create my-server --docker "host=ssh://CompanyServer1" 这里的 CompanyServer1 是 ssh 配置，例如这样 Host CompanyServer1 Hostname 192.168.0.106 User root Port 22 IdentityFile ~/.ssh/id_rsa_company 其中 IdentityFile 是存放无密码密钥的地方，如果你的密钥密钥密码就不需要这一行，否则需要设置一个没有密码的密钥，例如这样 ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_company -N "" 配置好后就可以在本地连接服务器 docker 了 docker context list 输出类似这样 NAME DESCRIPTION DOCKER ENDPOINT ERROR company-server ssh://CompanyServer1 default Current DOCKER_HOST based configuration unix:///***/docker.sock desktop-linux * Docker Desktop unix:///***/docker.sock 使用命令 use 切换 context ...

像 VMware 或 KVM 这类虚拟化系统, 他们运行在虚拟化层上运行完整的 Linux 内核与操作系统. 这种架构能提供极强的隔离性, 因为每个虚拟机都搭载独立的内核, 这些内核各自运行在硬甲虚拟化层之上的隔离内存空间中. 而容器技术有着根本性差异, 所有容器共享同一个内核, 工作负载间的隔离性全通过内核机制实现, 这种模式被称为操作系统级虚拟化 operating system virtualization. runc/libcontainer 提供了一个很好的定义: A container is a self-contained execution environment that shares the kernel of the host system and is isolated from other containers in the system. 容器最大的优势就在于性能, 当运行一个进程的时候, 只有小部分的代码在内核中用于管理容器. 如今, 容器几乎在任何地方运行. Docker 和 OCI 镜像提供了生成环境中软件的打包格式, 并为 Kubernetes 和大多数 “serverless” 云技术打下了基础. 所谓的 serverless 技术并不是真的没有服务器: 它们依赖其他人的服务器来完成工作, 这样应用开发者就无需关心管理硬甲和操作系统了. Creating a Container 创建容器的命令 docker container run 实际上是包装在一起的两条命令. 第一件事是从基本的镜像中创建一个容器, 可以通过 docker container create 命令实现. 第二件事是执行容器, 同样地, 可以通过 docker container start 命令实现. ...

每个 Linux 容器都基于一个镜像, 镜像重新构建运行中容器的底层定义. 要启动一个容器, 需要下载公共镜像或者创建自己的镜像. 每个镜像由一个或多个相互关联的文件系统层 layer 组成, 这些层通常与创建镜像的每个构建步骤大致一一对应. 由于镜像由独立的层构建而成, 这就对 Linux 内核提出了特殊要求: 内核必须提供 Docker 所需的驱动, 以便运行存储后端. 在镜像管理, Docker 高度依赖这个存储后端, 该后端通过与底层 Linux 文件系统通信, 用来构建并管理多个层并将它们组合成一个可用的镜像. 主要支持的后端存储有以下类型: Overlay2 B-Tree File System Device Mapper 每一个后端都提供一个快速的 copy-on-write (CoW) 系统用于镜像管理. 包含: Building images Uploading (pushing) images to an image registry Downloading (pulling) images from an image registry Creating and running containers from an image Anatomy of a Dockerfile | 剖析 Dockerfile 这个文件描述了所有构建一个容器所需的步骤, 并且通常存储在项目源码的根目录里. 一个典型的 Dockerfile 看起来像下面这样, 这里是创建一个 Node.js 的应用镜像: ...

The Docker Workflow 这篇文章介绍 Docker 工作流 Revision Control 版本控制 Docker 有两种版本控制方式. 一个是用来跟踪文件系统层 layers (每个镜像的组成), 另一个是 tagging 标签系统. Filesystem layers 文件系统层 Linux 容器由堆叠文件系统层组成, 每一层由一个唯一的哈希标记, 每次 build 都在之前的修改之上. 这意味着, 每次 build 只需要重新构建修改过的层. 这节省了时间和网络带宽. Image Tags 镜像标签 第二种版本控制回答了一个问题: 之前部署的应用版本是? 非容器化应用的解决方案有很多种, 从 Git 发布标签到部署日志. Docker 有一个内置的处理机制: 每次 build 都有一个镜像标签. latest 经常被用来表示最新版本, 但由于这是一个浮动的标签, 因此在生产中使用并不好. 正确的做法应该是使用一个特定的版本. Building 构建镜像 Docker 的命令行工具包含一个 build 标志, 它会读取 Dockerfile 并产生一个 Docker 镜像. Dockerfile 中的每一条指令都会在镜像中生成一个新的层, 因此仅通过查看 Dockerfile 就能比较容易的推断出构建会做什么. 这样标准化的好处是, 任何熟悉 Dockerfile 的工程师都可以直接上手并修改任何其他应用的构建. Dockerfile 通常会提交到版本控制系统, 这也简化了对构建变更的追踪, 现代的多阶段构建还运行将构建环境与最终镜像分离, 为构建环境提供了像生产容器那样强大的可配置性. ...

The Docker Images | Docker 镜像 Image、OCI Image、Docker Image、Container Image 都是指同一个概念镜像的不容叫法. 镜像是一个轻量、只读且不可变的蓝图, 指定了应用运行所谁要的一切, 以及在 Docker 系统上如何运行. 就像是一份配方, 包括所有必要的原料, 诸如依赖、配置、环境设置和你的应用代码, 以及确保应用每次都能稳定运行的详细指令. 可以把镜像类比为面向对象编程中的类: 定义结构和行为, 但不能直接与类交互, 需要创建实例. Pulling and Inspecting an Image 拉取并查看镜像 镜像其实就是一个 JSON 对象, 可以这样拉取一个镜像 % docker pull celery:latest latest: Pulling from library/celery ef0380f84d05: Pull complete ada810c79ed7: Pull complete 4608a1c4fe47: Pull complete 58086cbb21fb: Pull complete a7bccb4a3faa: Pull complete 9de06a08ec25: Pull complete ad6feb8c6a6b: Pull complete 7568ca85d492: Pull complete 2d6f458f7411: Pull complete Digest: sha256:5c236059192a0389a2be21fc42d8db59411d953b7af5457faf501d4eec32dc31 Status: Downloaded newer image for celery:latest docker.io/library/celery:latest What's next: View a summary of image vulnerabilities and recommendations → docker scout quickview celery:latest 现在查看镜像信息 ...

Docker 引擎(Docker Engine), 顾名思意，是 Docker 的核心. 它为 Docker 提供动力, 并承担所有繁重的工作. 本文将深入探讨这一关键组件的内部运作, 以便了解 Docker 在内核下是如何工作的. The Evolution of the Docker Engine | Docker 引擎的演进 Docker 最初是一个巨大的单体(monolith), 所有代码都塞在同一个项目里. 对于 dotCloud来说, 这种方式一开始是可行的. 实际上, 这个方向运作得非常好, 以至于他们放弃了其他服务、把所有赌注都押在 Docker 上, 甚至把公司重命名为 Docker, Inc. 一开始, Docker 是一个又大又混乱的单体应用. 随着时间推移, Docker, Inc. 发现这种做法不可持续, 他们需要把系统拆分出来: 各个部分可以独立成长 更容易升级某些部分 - 可以替换旧组件而不影响整体 让社区更容易参与贡献 - 更小的组件意味着更多人能参与进来 更易跨平台 - 他们想要 Docker 在每个平台上运行, 而不只是 Linux 拆分的第一步是把客户端 client 剥离出来. 把客户端从大应用中抽出, 赋予它新职责: 把用户命令翻译成 Docker 引擎能理解的指令(也就是原来单体里"内核部分"的接口) 此时, Docker 引擎主要有两部分: ...

The Docker Story - Part1: Docker History docCloud - 也就是开发 Docker 的公司, 最初是一家 PaaS(平台即服务)公司, 他们在 PaaS 领域并没有太大的成功, 但他们构建了一个可以无缝管理客户系统与架构的工具: Docker. 2013 年, 他们决定放弃 PaaS 服务, 将全部精力投入到 Docker 这款产品上. Containers 容器 Docker 公司并没有发明容器这个概念. 实际上, 容器的概念已经演进了十多年, 很多参与者都做出了贡献, Linux 基金会和 Google 是推动整个生态走向成熟的重要力量. 假如你在运营一家公司, 希望将应用上线, 以前需要做的事大概是: 购买一台服务器 安装所有必要的应用和依赖 配置环境以匹配你的开发设置 部署应用 把服务器对外开放 看起来很简单, 但实际操作会很复杂: 要手动跟踪并更新每个依赖和配置 如果出问题, 需要手动去修复 基础设施团队需要估算服务器规格(内存、CPU 等) — 为了防止流量高峰崩溃, 通常会配置更高的规格(过度配置) 那台高配服务器大多数时间只是闲置着, 做最少量的工作 不能轻易扩展或在同一服务器上运行多个应用, 因为每个应用都需要独立的运行环境 总之, 非常混乱 后来出现了虚拟机(VM), 情况有了改善. 使用 VM 可以: 在同一台服务器上运行多个隔离的环境 为 VM 做快照并在不同服务器间复用 不再重复重复地搭建环境，这是一个很大的进步 但 VM 也有缺点: ...