42 Commits

Author SHA1 Message Date
Baohua Yang
fdb879dcf2 Release v1.5.0: Restructure chapters and update for Docker v30.x 2026-02-04 22:14:22 -08:00
Baohua Yang
b4b0d4160a Add latest techniques 2026-02-03 11:09:52 -08:00
Baohua Yang
99e0eb14ce bump to latest stable versions 2026-02-03 10:14:25 -08:00
Baohua Yang
b92ccc8309 Add star history 2026-02-03 09:13:39 -08:00
Baohua Yang
cbfe75fe9b Add more practices 2026-01-30 17:10:28 -08:00
Baohua Yang
fec2e506d9 Add more content 2026-01-30 16:48:39 -08:00
Baohua Yang
c58f61dbed Clean up 2026-01-30 16:28:20 -08:00
Baohua Yang
8a0230e493 fix: remove non-existent advanced_network/_images from CI 2026-01-30 16:08:28 -08:00
Baohua Yang
16e0d3502d Fix wrong link 2026-01-26 18:16:39 -08:00
Baohua Yang
02898e346c Update to latest 2026-01-25 17:46:02 -08:00
Baohua Yang
7d8d7e63f4 Fix coding lang 2026-01-25 17:26:05 -08:00
Baohua Yang
cc6510d0b2 fix: resolve content issues found in user review
- fix(install): correct Docker version in macOS guide
- fix(intro): localize external image to prevent link rot
- doc(swarm): add context note about Kubernetes supremacy
- fix(network): remove broken missing image reference
2026-01-24 19:45:22 -08:00
Baohua Yang
306a205314 Update local serve using honkit 2026-01-22 09:01:49 -08:00
Baohua Yang
5eed72afa0 Fix missing files 2026-01-21 11:31:23 -08:00
Baohua Yang
6bba22679b Use latest tools 2026-01-12 09:33:56 -08:00
Baohua Yang
24eb615f54 Use latest version tools 2026-01-12 09:02:39 -08:00
Baohua Yang
43e12058eb Update tools to latest version 2026-01-11 10:05:49 -08:00
Baohua Yang
8bdb8406f9 Fix words 2026-01-10 22:39:51 -08:00
Baohua Yang
e08a34bcdf Merge networks 2026-01-02 16:57:09 -08:00
Baohua Yang
6e6d31d1d6 Merge networks 2026-01-02 16:55:39 -08:00
yeasy
5c3841dc98 GitBook: No commit message 2025-12-17 10:37:56 +00:00
Baohua Yang
61a71f3c25 Comment out unavailable gitee figures 2025-11-24 15:00:01 -08:00
Baohua Yang
39207f57cf Update docker book intro to v4 2025-11-24 13:27:16 -08:00
Baohua Yang
3a9d4bff61 Merge pull request #549 from CNAHYZ/patch-1
Update figure's path
2024-12-25 19:49:09 -08:00
intfoo
4bc29c0300 Update overview.md 修复图片地址问题 2024-12-25 16:20:30 +08:00
Kang Huaishuai
65bc905920 Update registry mirror 2024-11-23 23:23:50 +08:00
Baohua Yang
1b7d941fcd Merge pull request #548 from trevanlye/patch-1
Add go init
2024-11-20 10:17:28 -08:00
Baohua Yang
e0ff3d315a Merge pull request #542 from upbeat-backbone-bose/master
Update django version
2024-11-20 10:16:04 -08:00
trevanlye
09de77b543 Update README.md
we need 'go mod init first' before 'go get'
2024-11-11 11:05:23 +08:00
debian-go
344fc8bd3c Merge branch 'yeasy:master' into master 2024-11-08 11:42:06 +08:00
Baohua Yang
7ec5772432 Merge pull request #546 from liangbinfudan/master
ubuntu.md update #545
2024-09-26 16:38:42 -07:00
Hugo Dock
355dd3b051 Update ubuntu.md
The relationships among Ubuntu LTS versions have been described, and the relevant scripts have been modified slightly
2024-09-19 13:09:38 +08:00
Baohua Yang
ca011164c2 Merge pull request #543 from my-vegetable-has-exploded/debian11
Add suggestion for gpg in debian11
2024-07-30 14:02:19 -07:00
yi wang
0f2956a646 Update debian.md 2024-07-29 22:25:02 +08:00
debian-go
da7991660e Merge pull request #1 from upbeat-backbone-bose/dependabot/pip/compose/demo/django/pip-062e67ef1e
Update django requirement from <3.0,>=2.0 to >=5.0.6,<6.0 in /compose/demo/django in the pip group across 1 directory
2024-07-09 10:26:30 +08:00
dependabot[bot]
391c6364a0 Update django requirement
Updates the requirements on [django](https://github.com/django/django) to permit the latest version.

Updates `django` to 5.0.6
- [Commits](https://github.com/django/django/compare/2.0...5.0.6)

---
updated-dependencies:
- dependency-name: django
  dependency-type: direct:production
  dependency-group: pip
...

Signed-off-by: dependabot[bot] <support@github.com>
2024-07-09 02:26:13 +00:00
Baohua Yang
99433b2e45 Merge pull request #540 from RockChinQ/master
Add error solution for docker installation on raspi OS
2024-02-03 19:46:31 -08:00
RockChinQ
32c6a91aa9 doc(raspberry-pi): tested on bookworm 2024-02-02 23:03:39 +08:00
RockChinQ
bea7b8d3f4 doc(raspberry-pi.md): error solution for bullseye 2024-02-02 10:36:14 +08:00
Baohua Yang
1be1db5a43 Merge pull request #538 from CybCom/master
Fix CI error
Close issue #537
2023-12-29 16:27:59 -08:00
CybCom
7052cea8a3 refactor(workflows): 💚 Update the YAMLs for GitHub workflows
Update the out dated action version. Remove redundant/useless lines. Some other updates.
2023-12-23 01:01:32 +08:00
CybCom
584087ad46 ci(workflows): 💚 Try to confirm and fix CI error:0308010C
There might be a conflict between the new version node.js and this project's dependencies, according to CI Error message "error:0308010C:digital envelope routines::unsupported". Try to confirm and fix it by specifying the old styled openssl.
2023-12-22 18:27:38 +08:00
393 changed files with 11930 additions and 4506 deletions

View File

@@ -1,15 +0,0 @@
kind: pipeline
type: docker
name: build
steps:
- name: build
image: yeasy/docker_practice:latest
pull: if-not-exists # always never
environment:
TZ: Asia/Shanghai
commands:
- docker-entrypoint.sh build
trigger:
branch:
- master

View File

@@ -1,8 +1,6 @@
name: Check link
on:
# push:
# pull_request:
workflow_dispatch:
jobs:
@@ -10,9 +8,7 @@ jobs:
name: check-link
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
with:
fetch-depth: 1
- uses: actions/checkout@v4.1.1
# search Issues :-(
- run: |
docker run -i --rm \

View File

@@ -1,10 +1,10 @@
name: CI
on:
push:
pull_request:
workflow_dispatch:
name: CI
defaults:
run:
shell: bash --noprofile --norc -exo pipefail {0}
@@ -14,9 +14,7 @@ jobs:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
with:
fetch-depth: 2
- uses: actions/checkout@v4.1.1
- name: Build Gitbook
uses: docker://yeasy/docker_practice
with:
@@ -68,8 +66,8 @@ jobs:
PCIT_USERNAME: khs1994
- name: vuepress
run: |
export NODE_OPTIONS=--openssl-legacy-provider
sudo rm -rf _book
# npm i vuepress --save-dev
npm i
git clone https://github.com/docker-practice/.vuepress .vuepress2
@@ -80,11 +78,9 @@ jobs:
npx vuepress --version
npm run vuepress:build
# echo "vuepress.docker-practice.com" > .vuepress/dist/CNAME
echo "vuepress.mirror.docker-practice.com" > .vuepress/dist/CNAME
cp -r _images .vuepress/dist
cp -r advanced_network/_images .vuepress/dist/advanced_network
cp -r appendix/_images .vuepress/dist/appendix
cp -r cases/ci/drone/_images .vuepress/dist/cases/ci/drone
cp -r cases/os/_images .vuepress/dist/cases/os

4
.gitignore vendored
View File

@@ -11,3 +11,7 @@ node_modules/
package-lock.json
docker-compose.override.yml
# Editor configs
.obsidian/
.vscode/

View File

@@ -1,26 +0,0 @@
FROM node:14.4.0-alpine
ENV TZ=Asia/Shanghai
WORKDIR /srv/gitbook
COPY book.json book.json
COPY docker-entrypoint.sh /usr/local/bin/
RUN set -x && apk add --no-cache \
tzdata bash \
&& npm install -g gitbook-cli \
&& gitbook install \
&& ln -s /usr/local/bin/docker-entrypoint.sh / \
&& rm -rf /root/.npm /tmp/*
EXPOSE 4000
VOLUME /srv/gitbook-src
WORKDIR /srv/gitbook-src
ENTRYPOINT ["docker-entrypoint.sh"]
CMD server

View File

@@ -1,37 +0,0 @@
{
"title": "Docker -- 从入门到实践",
"author": "yeasy",
"language": "zh-hans",
"links": {
"sidebar": {
"GitHub": "https://github.com/yeasy/docker_practice"
}
},
"plugins": [
"-livereload",
"image-captions",
"github",
"page-treeview@2.9.8",
"editlink"
],
"pluginsConfig": {
"image-captions": {
"attributes": {
"width": "600"
},
"caption": "图 _PAGE_LEVEL_._PAGE_IMAGE_NUMBER_ - _CAPTION_"
},
"github": {
"url": "https://github.com/yeasy/docker_practice"
},
"editlink": {
"base": "https://github.com/yeasy/docker_practice/blob/master/",
"label": "编辑本页"
},
"page-treeview": {
"copyright": "Copyright &#169; yeasy",
"minHeaderCount": "2",
"minHeaderDeep": "2"
}
}
}

View File

@@ -1,43 +0,0 @@
user root;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
index index.html index.php;
server {
server_name localhost;
listen 4000;
root /srv/www/;
index index.html;
}
}

View File

@@ -1,5 +0,0 @@
sut:
build: .
volumes:
- ../:/srv/gitbook-src
command: build

View File

@@ -1,23 +0,0 @@
#!/bin/sh
START=`date "+%F %T"`
if [ $1 = "sh" ];then sh ; exit 0; fi
rm -rf node_modules _book
srcDir=$PWD
cp -a . /srv/gitbook
cd /srv/gitbook
main(){
if [ "$1" = build ];then
gitbook build && cp -a _book $srcDir && echo $START && date "+%F %T" && exit 0
else
exec gitbook serve
fi
}
main $1 $2 $3

View File

@@ -1,8 +0,0 @@
#!/usr/bin/env bash
# cd .travis
# ./update.sh
if [ ! -f Dockerfile ];then exit 1; fi
cp -a ../book.json book.json

23
01_introduction/README.md Normal file
View File

@@ -0,0 +1,23 @@
# 简介
本章将带领你进入 **Docker** 的世界
## 本章内容
* [什么是 Docker](what.md)
* 介绍 Docker 的起源发展历程以及其背后的核心技术Cgroups, Namespaces, UnionFS
* 了解 Docker 是如何改变软件交付方式的
* [为什么要用 Docker](why.md)
* 对比传统虚拟机技术阐述 Docker 在启动速度资源利用率交付效率等方面的巨大优势
* 探讨 Docker DevOps微服务架构中的关键作用
## 学习目标
通过本章的学习你将能够
1. 理解 Docker 的核心概念与架构
2. 明白 Docker 解决了现代软件开发与运维中的哪些痛点
3. 建立起对容器技术的初步认知为后续的实战操作打下基础
好吧让我们带着问题开始这神奇之旅

View File

@@ -0,0 +1,65 @@
# 快速上手 (5分钟)
本节将通过一个简单的 Web 应用例子带你快速体验 Docker 的核心流程构建镜像运行容器
## 1. 准备代码
创建一个名为 `hello-docker` 的文件夹并在其中创建一个 `index.html` 文件
```html
<h1>Hello, Docker!</h1>
```
## 2. 编写 Dockerfile
在同级目录下创建一个名为 `Dockerfile` (无后缀) 的文件
```dockerfile
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
```
## 3. 构建镜像
打开终端进入该目录执行构建命令
```bash
$ docker build -t my-hello-world .
```
* `docker build`: 构建命令
* `-t my-hello-world`: 给镜像起个名字标签
* `.`: 指定上下文路径为当前目录
## 4. 运行容器
使用刚才构建的镜像启动一个容器
```bash
$ docker run -d -p 8080:80 my-hello-world
```
* `docker run`: 运行命令
* `-d`: 后台运行
* `-p 8080:80`: 将宿主机的 8080 端口映射到容器的 80 端口
## 5. 访问测试
打开浏览器访问 [http://localhost:8080](http://localhost:8080),你应该能看到 "Hello, Docker!"。
## 6. 清理
停止并删除容器
```bash
# 查看正在运行的容器 ID
$ docker ps
# 停止容器
$ docker stop <CONTAINER_ID>
# 删除容器
$ docker rm <CONTAINER_ID>
```
恭喜你已经完成了第一次 Docker 实战接下来请阅读 [Docker 核心概念](../02_basic_concept/README.md) 做深入了解

124
01_introduction/what.md Normal file
View File

@@ -0,0 +1,124 @@
# 什么是 Docker
## 一句话理解 Docker
> **Docker 是一种轻量级的虚拟化技术它让应用程序及其依赖环境可以被打包成一个标准化的单元在任何地方都能一致地运行**
如果用一个生活中的类比**Docker 之于软件就像集装箱之于货物**
在集装箱发明之前货物的运输是一件麻烦的事情不同的货物需要不同的包装不同的装卸方式换一种运输工具就要重新装卸集装箱的出现改变了这一切无论里面装的是什么集装箱的外形是标准的可以用同样的方式装卸堆放和运输
Docker 做的事情类似无论你的应用是用 PythonJavaNode.js 还是其他语言写的无论它需要什么样的依赖库和环境一旦被打包成 Docker 镜像就可以用同样的方式在任何支持 Docker 的机器上运行
## Docker 的核心价值
笔者认为Docker 解决的是软件开发中最古老的问题之一**"在我机器上明明能跑啊!"**
```
开发环境 生产环境
┌─────────────────┐ ┌─────────────────┐
│ Python 3.14 │ ≠ │ Python 3.11 │
│ Ubuntu 24.04 │ │ Ubuntu 22.04 │
│ 特定版本的库 │ │ 不同版本的库 │
└─────────────────┘ └─────────────────┘
↓ ↓
运行正常 运行失败!
```
有了 Docker
```
开发环境 生产环境
┌─────────────────┐ ┌─────────────────┐
│ Docker 镜像 │ = │ 同一个镜像 │
│ (包含所有依赖) │ │ (完全一致) │
└─────────────────┘ └─────────────────┘
↓ ↓
运行正常 运行正常!
```
## Docker vs 虚拟机
很多人第一次接触 Docker 时会问**"这不就是虚拟机吗?"**
答案是**不是而且差别很大**
### 传统虚拟机
传统虚拟机技术是虚拟出一套完整的硬件在其上运行一个完整的操作系统再在该系统上运行应用
![传统虚拟化](../_images/virtualization.png)
### Docker 容器
Docker 容器内的应用直接运行于宿主的内核容器内没有自己的内核也没有进行硬件虚拟
![Docker](../_images/docker.png)
### 关键区别
| 特性 | Docker 容器 | 传统虚拟机 |
|------|-------------|------------|
| **启动速度** | 秒级 | 分钟级 |
| **资源占用** | MB 级别 | GB 级别 |
| **性能** | 接近原生 | 有明显损耗 |
| **隔离级别** | 进程级隔离 | 完全隔离 |
| **单机数量** | 可运行上千个 | 通常几十个 |
> 笔者经常用这个类比来解释虚拟机像是每个应用都住在一栋独立的房子里有自己的地基水电系统而容器像是大家住在同一栋公寓楼里的不同房间共享地基和水电系统但各自独立
## Docker 的技术基础
Docker 使用 [Go 语言](https://golang.google.cn/) 开发,基于 Linux 内核的以下技术:
- **[Namespace](https://en.wikipedia.org/wiki/Linux_namespaces)**:实现资源隔离(进程、网络、文件系统等)
- **[Cgroups](https://zh.wikipedia.org/wiki/Cgroups)**实现资源限制CPU、内存、I/O 等)
- **[Union FS](https://en.wikipedia.org/wiki/Union_mount)**:实现分层存储(如 OverlayFS
> 如果你对这些底层技术感兴趣可以阅读本书的[底层实现](../13_implementation/README.md)章节
### Docker 架构演进
Docker 的底层实现经历了多次演进
```
2013 2014 2015 现在
│ │ │ │
▼ ▼ ▼ ▼
LXC ──→ libcontainer ──→ runC ──→ containerd + runC
└── OCI 标准化
```
- **LXC**2013Docker 最初基于 Linux Containers
- **libcontainer**2014v0.7Docker 自研的容器运行时
- **runC**2015v1.11捐献给 OCI 的标准容器运行时
- **containerd**高级容器运行时管理容器生命周期
![Docker 架构](../_images/docker-on-linux.png)
> `runc` 是一个 Linux 命令行工具用于根据 [OCI 容器运行时规范](https://github.com/opencontainers/runtime-spec) 创建和运行容器。
> `containerd` 是一个守护程序它管理容器生命周期提供了在一个节点上执行容器和管理镜像的最小功能集
## Docker 的历史与生态
**Docker** 最初是 `dotCloud` 公司创始人 [Solomon Hykes](https://github.com/shykes) 在法国期间发起的一个公司内部项目,于 [2013 年 3 月以 Apache 2.0 授权协议开源](https://en.wikipedia.org/wiki/Docker_(software))。
Docker 的发展历程
- **2013 3 **开源发布
- **2013 年底**dotCloud 公司改名为 Docker, Inc.
- **2015 **成立 [开放容器联盟OCI](https://opencontainers.org/),推动容器标准化
- **至今**[GitHub 项目](https://github.com/moby/moby) 超过 7 万星标
Docker 的成功推动了整个容器生态的发展催生了 KubernetesPodman 等众多相关项目笔者认为Docker 最大的贡献不仅是技术本身更是它**让容器技术从系统管理员的工具变成了每个开发者都能使用的标准工具**
## 本章小结
- Docker 是一种轻量级虚拟化技术核心价值是**环境一致性**
- 与虚拟机相比Docker 更轻量更快速资源利用率更高
- Docker 基于 Linux 内核的 NamespaceCgroups Union FS 技术
- Docker 推动了容器技术的标准化OCI和生态发展
接下来让我们了解[为什么要使用 Docker](why.md)

208
01_introduction/why.md Normal file
View File

@@ -0,0 +1,208 @@
# 为什么要使用 Docker
在回答"为什么用 Docker"之前笔者想先问一个问题**你有没有经历过这些场景**
## 没有 Docker 的世界
### 场景一"在我电脑上明明能跑"
```
周五下午 5:00
├── 开发者:代码写完了,本地测试通过,提交!🎉
├── 周一早上 9:00
│ └── 测试:"这个功能在测试环境跑不起来"
└── 开发者:" 不可能,在我电脑上明明能跑啊……"
```
笔者统计过这个问题通常由以下原因导致
- Python/Node/Java 版本不一致
- 依赖库版本不一致
- 操作系统配置不一致
- 某些环境变量没有设置
- "哦,忘了说我本地装了个 XXX"
### 场景二环境配置的噩梦
```
新同事入职
├── Day 1领电脑配环境
├── Day 2继续配环境遇到问题
├── Day 3换种方法配环境
├── Day 4问老同事怎么配的他也忘了
└── Day 5终于能跑起来了但不知道为什么……
```
### 场景三服务器迁移的恐惧
```
运维:"我们需要把服务迁移到新服务器"
开发:"旧服务器上的配置文档在哪?"
运维:"当时是一个已经离职的同事配的……"
所有人:😱
```
## Docker 如何解决这些问题
### 核心理念一次构建到处运行
```
开发环境 测试环境 生产环境
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Docker │ = │ Docker │ = │ Docker │
│ 镜像 │ │ 镜像 │ │ 镜像 │
└─────────┘ └─────────┘ └─────────┘
↓ ↓ ↓
完全一致 完全一致 完全一致
```
## Docker 的核心优势
### 1. 环境一致性
Docker 镜像包含了应用运行所需的**一切**代码运行时系统工具配置这意味着
- 开发环境和生产环境完全一致
- 不会再有"在我机器上能跑"的问题
- 新人入职一条命令就能启动开发环境
```bash
# 新同事入职第一天
$ git clone https://github.com/company/project.git
$ docker compose up
# 完整的开发环境就准备好了
```
### 2. 秒级启动
传统虚拟机启动需要几分钟引导操作系统 Docker 容器启动通常只需要**几秒甚至几百毫秒**
笔者实测数据
| 启动内容 | 虚拟机 | Docker 容器 |
|---------|--------|-------------|
| 空系统 | ~60 | ~0.5 |
| MySQL | ~90 | ~3 |
| 完整 Web 应用 | ~120 | ~5 |
这个差异对以下场景尤为重要
- **CI/CD 流水线**每次构建节省几分钟一天累积下来就是几小时
- **弹性扩容**流量高峰时能快速启动更多实例
- **开发体验**快速重启服务进行调试
### 3. 资源效率
Docker 容器共享宿主机内核无需为每个应用运行完整的操作系统
```
传统虚拟机方案:
┌────────────────────────────────────────────────┐
│ 物理服务器 (64GB 内存) │
├──────────────┬───────────────┬─────────────────┤
│ VM1 │ VM2 │ VM3 │
│ 8GB 内存 │ 8GB 内存 │ 8GB 内存 │
│ (含 OS 2GB) │ (含 OS 2GB) │ (含 OS 2GB) │
│ 应用 1 │ 应用 2 │ 应用 3 │
└──────────────┴───────────────┴─────────────────┘
实际可用于应用3 × 6GB = 18GB ❌
Docker 方案:
┌────────────────────────────────────────────────┐
│ 物理服务器 (64GB 内存) │
│ 宿主机 OS + Docker (约 4GB) │
├──────────────┬───────────────┬─────────────────┤
│ 容器 1 │ 容器 2 │ 容器 3 │
│ 应用 1 │ 应用 2 │ 应用 3 │
│ (按需分配) │ (按需分配) │ (按需分配) │
└──────────────┴───────────────┴─────────────────┘
实际可用于应用:约 60GB ✅
```
### 4. 持续交付和部署
Docker 完美契合 DevOps 的工作流程
```
代码提交 ──→ 自动构建镜像 ──→ 自动测试 ──→ 自动部署
│ │ │ │
▼ ▼ ▼ ▼
Git docker 容器内 容器滚动
push build 运行测试 更新
```
使用 [Dockerfile](../04_image/build.md) 定义镜像构建过程使得
- 构建过程**可重复可追溯**
- 任何人都能从代码重建完全相同的镜像
- 配合 [GitHub Actions](../14_cases/ci/actions/README.md) CI 系统实现自动化
### 5. 轻松迁移
Docker 可以在几乎任何平台上运行
- 本地开发机macOSWindowsLinux
- 公有云AWSAzureGCP阿里云腾讯云
- 私有云和自建数据中心
- 边缘设备和 IoT
**同一个镜像在任何地方运行结果都一致** 这让应用迁移变得前所未有的简单
### 6. 微服务架构的基石
现代微服务架构几乎都依赖容器技术Docker 让你可以
- **隔离服务**每个服务运行在独立容器中互不干扰
- **独立扩展**哪个服务负载高就单独扩展哪个
- **独立部署**更新一个服务不影响其他服务
- **技术多样**不同服务可以用不同语言和框架
```
┌───────────────────────────────────────────────────┐
│ 微服务架构示例 │
├─────────────┬─────────────┬───────────────────────┤
│ 前端容器 │ API 容器 │ Worker 容器 │
│ (Node.js) │ (Python) │ (Go) │
├─────────────┴─────────────┴───────────────────────┤
│ Redis 容器 │
├───────────────────────────────────────────────────┤
│ PostgreSQL 容器 │
└───────────────────────────────────────────────────┘
```
## Docker 不适合的场景
笔者认为技术选型要客观Docker 并非银弹以下场景可能不太适合
### 1. 需要完全隔离的场景
容器共享宿主机内核隔离性不如虚拟机如果你需要运行不受信任的代码虚拟机可能更安全
### 2. 需要特殊内核的场景
容器使用宿主机内核如果应用需要特定版本的内核或内核模块可能需要虚拟机
### 3. Windows 原生应用
虽然 Docker 支持 Windows 容器但生态不如 Linux 容器成熟传统 Windows 应用的容器化仍有挑战
### 4. 桌面应用
Docker 主要面向服务端应用桌面 GUI 应用的容器化虽然可行但通常得不偿失
## 与传统虚拟机的对比总结
| 特性 | Docker 容器 | 传统虚拟机 |
|:------|:-----------|:-----------|
| 启动速度 | 秒级 | 分钟级 |
| 磁盘占用 | MB 级别 | GB 级别 |
| 性能 | 接近原生 | 5-20% 损耗 |
| 单机支持量 | 上千个容器 | 几十个虚拟机 |
| 隔离性 | 进程级别 | 完全隔离 |
| 最佳场景 | 微服务CI/CD开发环境 | 多租户高安全需求 |
## 本章小结
Docker 的核心价值可以用一句话概括**让应用的开发测试部署保持一致同时极大提高资源利用效率**
笔者认为对于现代软件开发者来说Docker 已经不是"要不要学"的问题而是**必备技能**无论你是前端后端运维还是全栈开发者掌握 Docker 都能让你的工作更高效
接下来让我们学习 Docker [基本概念](../02_basic_concept/README.md)

View File

@@ -0,0 +1,9 @@
# 基本概念
**Docker** 包括三个基本概念
* **镜像**`Image`Docker 镜像是一个特殊的文件系统除了提供容器运行时所需的程序资源配置等文件外还包含了一些为运行时准备的一些配置参数如匿名卷环境变量用户等镜像不包含任何动态数据其内容在构建之后也不会被改变
* **容器**`Container`镜像`Image`和容器`Container`的关系就像是面向对象程序设计中的 `` `实例` 一样镜像是静态的定义容器是镜像运行时的实体容器可以被创建启动停止删除暂停等
* **仓库**`Repository`镜像构建完成后可以很容易的在当前宿主机上运行但是如果需要在其它服务器上使用这个镜像我们就需要一个集中的存储分发镜像的服务Docker Registry 就是这样的服务
理解了这三个概念就理解了 **Docker** 的整个生命周期

View File

@@ -0,0 +1,246 @@
# Docker 容器
## 一句话理解容器
> **容器是镜像的运行实例如果把镜像比作程序那么容器就是进程**
用面向对象编程的术语来说**镜像是类Class容器是对象Instance**
- 一个镜像可以创建多个容器
- 每个容器相互独立互不影响
- 容器可以被创建启动停止删除暂停
## 容器的本质
> 💡 **笔者认为理解这一点是理解 Docker 的关键**
**容器的本质是一个特殊的进程**
```
┌─────────────────────────────────────────────────────────────┐
│ 普通进程 │
│ • 与其他进程共享系统资源 │
│ • 可以看到其他进程 │
│ • 共享网络和文件系统 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 容器进程 │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • 有自己的进程空间(看不到宿主机上的其他进程) │ │
│ │ • 有自己的网络(独立 IP、端口 │ │
│ │ • 有自己的文件系统(独立的 root 目录) │ │
│ │ • 有自己的用户(容器内的 root ≠ 宿主机的 root │ │
│ └───────────────────────────────────────────────────────┘ │
│ 但仍然运行在宿主机的内核上 │
└─────────────────────────────────────────────────────────────┘
```
这种隔离是通过 Linux 内核的 **Namespace** 技术实现的
## 容器 vs 虚拟机核心区别
很多初学者会混淆容器和虚拟机笔者用一张图来说明
```
虚拟机 容器
┌───────────────────────┐ ┌───────────────────────┐
│ App A │ App B │ │ App A │ App B │
├────────────┼──────────┤ ├────────────┼──────────┤
│ Guest OS │ Guest OS │ │ Container │ Container│
│ (完整系统) │ (完整系统)│ │ (仅应用) │ (仅应用) │
├────────────┴──────────┤ └────────────┴──────────┤
│ Hypervisor │ │ Docker Engine │
├───────────────────────┤ ├───────────────────────┤
│ Host OS │ │ Host OS │
├───────────────────────┤ ├───────────────────────┤
│ Hardware │ │ Hardware │
└───────────────────────┘ └───────────────────────┘
每个 VM 运行完整 OS 所有容器共享宿主机内核
```
| 特性 | 容器 | 虚拟机 |
|------|------|--------|
| **隔离级别** | 进程级Namespace | 硬件级Hypervisor |
| **启动时间** | 秒级甚至毫秒 | 分钟级 |
| **资源占用** | MB 级别 | GB 级别 |
| **性能损耗** | 几乎为零 | 5-20% |
| **内核** | 共享宿主机内核 | 各自独立内核 |
## 容器的存储层
### 镜像层 + 容器层
当容器运行时Docker 会在镜像的只读层之上创建一个**可写层**容器存储层
```
┌─────────────────────────────────────────────┐
│ 容器存储层(可读写) │ ← 容器运行时创建
│ 运行时产生的文件变化记录在这里 │
├─────────────────────────────────────────────┤
│ 镜像第 N 层(只读) │
├─────────────────────────────────────────────┤
│ 镜像第 N-1 层(只读) │
├─────────────────────────────────────────────┤
│ ... │
├─────────────────────────────────────────────┤
│ 镜像第 1 层(只读) │ ← 基础镜像层
└─────────────────────────────────────────────┘
```
### Copy-on-Write写时复制
当容器需要修改镜像层中的文件时
1. Docker 将该文件**复制**到容器存储层
2. 在容器层中进行修改
3. 原始镜像层保持不变
```
读取文件:直接从镜像层读取(共享,高效)
修改文件:复制到容器层,然后修改(只有这个容器能看到修改)
```
### 容器存储层的生命周期
> **笔者特别强调**这是新手最容易踩的坑
**容器存储层与容器生命周期绑定容器删除数据就没了**
```bash
# 创建容器,写入数据
$ docker run -it ubuntu bash
root@abc123:/# echo "important data" > /data.txt
root@abc123:/# exit
# 删除容器
$ docker rm abc123
# 数据丢了!没有任何办法恢复!
```
### 正确的数据持久化方式
按照 Docker 最佳实践容器存储层应该保持**无状态**需要持久化的数据应该使用
| 方式 | 说明 | 适用场景 |
|------|------|---------|
| **[数据卷Volume](../07_data_network/data/volume.md)** | Docker 管理的存储 | 数据库应用数据 |
| **[绑定挂载Bind Mount](../07_data_network/data/bind-mounts.md)** | 挂载宿主机目录 | 开发时共享代码 |
```bash
# 使用数据卷(推荐)
$ docker run -v mydata:/var/lib/mysql mysql
# 使用绑定挂载
$ docker run -v /host/path:/container/path nginx
```
这些位置的读写**会跳过容器存储层**直接写入宿主机性能更好也不会随容器删除而丢失
## 容器的生命周期
```
┌──────────────────────────────────────────────────┐
│ 容器生命周期 │
└──────────────────────────────────────────────────┘
docker create docker start docker stop
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Created │───────────▶│ Running │───────────▶│ Stopped │
└─────────┘ └─────────┘ └─────────┘
│ │ │
│ │ docker pause │
│ ▼ │
│ ┌─────────┐ │
│ │ Paused │ │
│ └─────────┘ │
│ │ │
│ docker rm │ docker rm │
└───────────────────────┴──────────────────────┘
┌──────────┐
│ Deleted │
└──────────┘
```
### 常用生命周期命令
```bash
# 创建并启动容器(最常用)
$ docker run nginx
# 分步操作
$ docker create nginx # 创建容器(不启动)
$ docker start abc123 # 启动容器
# 停止容器
$ docker stop abc123 # 优雅停止(发送 SIGTERM等待后发送 SIGKILL
$ docker kill abc123 # 强制停止(直接发送 SIGKILL
# 暂停/恢复(不常用,但有时有用)
$ docker pause abc123 # 暂停容器内所有进程
$ docker unpause abc123 # 恢复
# 删除容器
$ docker rm abc123 # 删除已停止的容器
$ docker rm -f abc123 # 强制删除运行中的容器
```
## 容器与进程的关系
> **核心概念**容器的生命周期 = 主进程PID 1的生命周期
```bash
# 主进程运行,容器运行
# 主进程退出,容器停止
```
这就是为什么
```bash
# 这个容器会立即退出bash 没有输入就退出了)
$ docker run ubuntu
# 这个容器会持续运行nginx 作为守护进程持续运行)
$ docker run nginx
```
详细解释请参考[后台运行](../05_container/daemon.md)章节
## 容器的隔离性
Docker 容器通过以下 Namespace 实现隔离
| Namespace | 隔离内容 | 效果 |
|-----------|---------|------|
| **PID** | 进程 ID | 容器内 PID 1 是应用进程看不到宿主机其他进程 |
| **NET** | 网络 | 独立的网络栈IP 地址端口 |
| **MNT** | 文件系统 | 独立的根目录和挂载点 |
| **UTS** | 主机名 | 独立的主机名和域名 |
| **IPC** | 进程间通信 | 独立的信号量消息队列 |
| **USER** | 用户 | 独立的用户和组 ID |
> 想深入了解请阅读[底层实现 - 命名空间](../13_implementation/namespace.md)
## 本章小结
| 概念 | 要点 |
|------|------|
| **容器是什么** | 镜像的运行实例本质是隔离的进程 |
| **容器 vs 虚拟机** | 共享内核更轻量但隔离性较弱 |
| **存储层** | 可写层随容器删除而消失 |
| **数据持久化** | 使用 Volume Bind Mount |
| **生命周期** | 与主进程PID 1绑定 |
理解了镜像和容器接下来让我们学习[仓库](repository.md)存储和分发镜像的服务
## 延伸阅读
- [启动容器](../05_container/run.md)详细的容器启动选项
- [后台运行](../05_container/daemon.md)理解容器为什么会"立即退出"
- [进入容器](../05_container/attach_exec.md)如何操作运行中的容器
- [数据管理](../07_data_network/README.md)Volume 和数据持久化详解

222
02_basic_concept/image.md Normal file
View File

@@ -0,0 +1,222 @@
# Docker 镜像
## 一句话理解镜像
> **Docker 镜像是一个只读的模板包含了运行应用所需的一切代码运行时环境变量和配置文件**
如果用一个类比**镜像就像是一张光盘或 ISO 文件**你可以用同一张光盘在不同电脑上安装系统而光盘本身不会被修改同样一个镜像可以创建多个容器而镜像本身保持不变
## 镜像与操作系统的关系
我们都知道操作系统分为**内核****用户空间**
```
┌─────────────────────────────────────────────────────────────┐
│ 用户空间 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 应用程序、工具、库、配置文件... │ │
│ │ (这部分被打包成 Docker 镜像) │ │
│ └─────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ Linux 内核 │
│ (容器共享宿主机的内核) │
└─────────────────────────────────────────────────────────────┘
```
对于 Linux 而言内核启动后会挂载 `root` 文件系统来提供用户空间支持**Docker 镜像**本质上就是一个 `root` 文件系统
例如官方镜像 `ubuntu:24.04` 包含了一套完整的 Ubuntu 24.04 最小系统的 root 文件系统**不包含 Linux 内核**因为容器共享宿主机的内核
## 镜像包含什么
Docker 镜像是一个特殊的文件系统包含
| 内容类型 | 示例 |
|---------|------|
| **程序文件** | 应用二进制文件Python/Node 解释器 |
| **库文件** | libcOpenSSL各种依赖库 |
| **配置文件** | nginx.confmy.cnf |
| **环境变量** | PATHLANG 等预设值 |
| **元数据** | 启动命令暴露端口数据卷定义 |
**关键特性**
- 镜像是**只读**
- 镜像**不包含**动态数据
- 镜像构建后**内容不会改变**
## 分层存储镜像的核心设计
### 为什么需要分层
笔者认为分层存储是 Docker 最巧妙的设计之一
假设你有三个应用都基于 Ubuntu 运行
```
传统方式(不分层):
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
│ Ubuntu │ │ Ubuntu │ │ Ubuntu │
│ 500MB │ │ 500MB │ │ 500MB │
└─────────────┘ └─────────────┘ └─────────────┘
总计1.5GB ❌
Docker 分层方式:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
│ 50MB │ │ 30MB │ │ 40MB │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────┼────────────────┘
┌─────────────────┐
│ Ubuntu │
共享500MB │
└─────────────────┘
总计620MB ✅
```
### 分层是如何工作的
笔者用一个实际的 Dockerfile 来解释分层
```docker
FROM ubuntu:24.04 # 第 1 层:基础系统(约 78MB
RUN apt-get update # 第 2 层:更新包索引
RUN apt-get install nginx # 第 3 层:安装 nginx
COPY app.conf /etc/nginx/ # 第 4 层:复制配置文件
```
构建后的镜像结构
```
┌─────────────────────────────────────┐
│ 第 4 层: COPY app.conf (只读) │ ← 最新添加的层
├─────────────────────────────────────┤
│ 第 3 层: nginx 安装文件 (只读) │
├─────────────────────────────────────┤
│ 第 2 层: apt 缓存更新 (只读) │
├─────────────────────────────────────┤
│ 第 1 层: Ubuntu 基础系统 (只读) │ ← 基础镜像层
└─────────────────────────────────────┘
```
每一层的特点
- **只读**构建完成后不可修改
- **可共享**多个镜像可以共享相同的层
- **有缓存**未变化的层不会重新构建
### 分层存储的"陷阱"
> **笔者特别提醒**理解这一点可以帮你避免构建出臃肿的镜像
**关键原理**每一层的文件变化会被记录**删除操作只是标记不会真正减小镜像体积**
```docker
# 错误示范 ❌
FROM ubuntu:24.04
RUN apt-get update
RUN apt-get install -y build-essential # 安装编译工具(约 200MB
RUN make && make install # 编译应用
RUN apt-get remove build-essential # 试图删除编译工具
# 结果:镜像仍然包含 200MB 的编译工具!
```
```docker
# 正确做法 ✅
FROM ubuntu:24.04
RUN apt-get update && \
apt-get install -y build-essential && \
make && make install && \
apt-get remove -y build-essential && \
apt-get autoremove -y && \
rm -rf /var/lib/apt/lists/*
# 在同一层完成安装、使用、清理
```
### 查看镜像的分层
```bash
# 查看镜像的历史(每层的构建记录)
$ docker history nginx:latest
IMAGE CREATED CREATED BY SIZE
a6bd71f48f68 2 weeks ago CMD ["nginx" "-g" "daemon off;"] 0B
<missing> 2 weeks ago STOPSIGNAL SIGQUIT 0B
<missing> 2 weeks ago EXPOSE map[80/tcp:{}] 0B
<missing> 2 weeks ago ENTRYPOINT ["/docker-entrypoint.sh"] 0B
<missing> 2 weeks ago COPY 30-tune-worker-processes.sh /docker-ent… 4.62kB
...
```
## 镜像的标识
Docker 镜像有多种标识方式
### 1. 镜像名称和标签
格式`[仓库地址/]仓库名[:标签]`
```bash
# 完整格式
registry.example.com/myproject/myapp:v1.2.3
# 简写(使用 Docker Hub
nginx:1.25
ubuntu:24.04
# 省略标签(默认使用 latest
nginx # 等同于 nginx:latest
```
### 2. 镜像 IDContent-Addressable
每个镜像有一个基于内容计算的唯一 ID
```bash
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest a6bd71f48f68 2 weeks ago 187MB
ubuntu 24.04 ca2b0f26964c 3 weeks ago 78.1MB
```
### 3. 镜像摘要Digest
更精确的标识基于镜像内容的 SHA256 哈希
```bash
$ docker images --digests
REPOSITORY TAG DIGEST IMAGE ID
nginx latest sha256:6db391d1c0cfb30588ba0bf72ea999404f2764184d8b8d10d89e8a9c6... a6bd71f48f68
```
> 💡 笔者建议在生产环境使用镜像摘要而非标签因为标签可以被覆盖但摘要是不可变的
## 镜像的来源
Docker 镜像可以通过以下方式获取
| 方式 | 说明 | 示例 |
|------|------|------|
| ** Registry 拉取** | 最常用的方式 | `docker pull nginx` |
| ** Dockerfile 构建** | 自定义镜像 | `docker build -t myapp .` |
| **从容器提交** | 保存容器状态不推荐 | `docker commit` |
| **从文件导入** | 离线传输 | `docker load < image.tar` |
## 本章小结
| 概念 | 要点 |
|------|------|
| **镜像是什么** | 只读的应用模板包含运行所需的一切 |
| **分层存储** | 多层叠加共享基础层节省空间 |
| **只读特性** | 构建后不可修改保证一致性 |
| **层的陷阱** | 删除操作只是标记不减小体积 |
理解了镜像接下来让我们学习[容器](container.md)镜像的运行实例
## 延伸阅读
- [获取镜像](../04_image/pull.md) Registry 下载镜像
- [使用 Dockerfile 定制镜像](../04_image/build.md)创建自己的镜像
- [Dockerfile 最佳实践](../15_appendix/best_practices.md)构建高质量镜像的技巧
- [底层实现 - 联合文件系统](../13_implementation/ufs.md)深入理解分层存储的技术原理

View File

@@ -0,0 +1,250 @@
# Docker Registry
## 一句话理解 Registry
> **Docker Registry 是存储和分发 Docker 镜像的服务类似于代码的 GitHub 或包管理的 npm**
镜像构建完成后可以在当前机器上运行但如果需要在其他服务器上使用这个镜像就需要一个集中的存储和分发服务这就是 Docker Registry
## 核心概念
### Registry仓库标签的关系
```
┌─────────────────────────────────────────────────────────────────────┐
│ Docker Registry │
│ (如 Docker Hub
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Repository仓库: nginx │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ :latest │ │ :1.25 │ │ :1.24 │ │ :alpine │ ... │ │
│ │ │ (tag) │ │ (tag) │ │ (tag) │ │ (tag) │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Repository仓库: mysql │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ :latest │ │ :8.0 │ │ :5.7 │ ... │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
```
| 概念 | 说明 | 示例 |
|------|------|------|
| **Registry** | 存储镜像的服务 | Docker Hubghcr.io |
| **Repository仓库** | 同一软件的镜像集合 | `nginx``mysql``mycompany/myapp` |
| **Tag标签** | 仓库内的版本标识 | `latest``1.25``alpine` |
### 镜像的完整名称
```
[registry地址/][用户名/]仓库名[:标签]
```
示例
```bash
# 完整格式
registry.example.com/mycompany/myapp:v1.2.3
│ │ │ │
│ │ │ └── 标签
│ │ └── 仓库名
│ └── 用户名/组织名
└── Registry 地址
# Docker Hub 官方镜像(省略 registry 和用户名)
nginx:1.25
ubuntu:24.04
# Docker Hub 用户镜像
jwilder/nginx-proxy:latest
# 其他 Registry
ghcr.io/username/myapp:v1.0
gcr.io/google-containers/pause:3.6
```
> 💡 **笔者提示**如果不指定 Registry 地址默认使用 Docker Hub如果不指定标签默认使用 `latest`
## 公共 Registry 服务
### Docker Hub默认
[Docker Hub](https://hub.docker.com/) 是最大的公共 Registry也是 Docker 的默认 Registry。
**特点**
- 拥有大量[官方镜像](https://hub.docker.com/search?q=&type=image&image_filter=official)nginx、mysql、redis 等)
- 免费账户可以创建公开仓库
- 付费账户支持私有仓库
```bash
# 从 Docker Hub 拉取镜像
$ docker pull nginx # 官方镜像
$ docker pull bitnami/redis # 第三方镜像
# 推送镜像到 Docker Hub
$ docker login
$ docker push username/myapp:v1.0
```
### 其他公共 Registry
| Registry | 地址 | 说明 |
|----------|------|------|
| **GitHub Container Registry** | ghcr.io | GitHub 提供 GitHub Actions 集成好 |
| **Google Container Registry** | gcr.io | Google Cloud 提供Kubernetes 镜像常用 |
| **Quay.io** | quay.io | Red Hat 提供 |
| **阿里云容器镜像服务** | registry.cn-*.aliyuncs.com | 国内访问快 |
| **腾讯云容器镜像服务** | ccr.ccs.tencentyun.com | 国内访问快 |
## 镜像加速器
由于网络原因在国内直接访问 Docker Hub 可能会很慢可以配置**镜像加速器**Registry Mirror来加速下载
```json
// /etc/docker/daemon.json
{
"registry-mirrors": [
"https://your-accelerator-url"
]
}
```
详细配置方法请参考[镜像加速器](../install/mirror.md)章节
> **笔者提醒**镜像加速器的可用性经常变化使用前建议先测试是否可用
## 私有 Registry
对于企业用户通常需要搭建私有 Registry 来存储内部镜像
### 官方 Registry 镜像
Docker 官方提供了 [registry](https://hub.docker.com/_/registry/) 镜像,可以快速搭建私有 Registry
```bash
# 启动一个本地 Registry
$ docker run -d -p 5000:5000 --name registry registry:2
# 推送镜像到本地 Registry
$ docker tag myapp:v1.0 localhost:5000/myapp:v1.0
$ docker push localhost:5000/myapp:v1.0
# 从本地 Registry 拉取
$ docker pull localhost:5000/myapp:v1.0
```
### 企业级解决方案
官方 Registry 功能较为基础企业环境常用以下方案
| 方案 | 特点 |
|------|------|
| **[Harbor](https://goharbor.io/)** | CNCF 项目,功能全面(用户管理、漏洞扫描、镜像签名) |
| **[Nexus Repository](../repository/nexus3_registry.md)** | 支持多种制品类型DockerMavennpm |
| **云厂商服务** | 阿里云 ACR腾讯云 TCRAWS ECR |
笔者建议
- 小团队可以先用官方 Registry够用即可
- 中大型团队推荐 Harbor功能完善且开源免费
- 已使用云服务直接用云厂商的 Registry 服务更省心
## 镜像的推送和拉取
### 完整工作流程
```
开发者机器 Registry 生产服务器
│ │ │
│ docker build │ │
│ 构建镜像 │ │
│ │ │
│ docker push ─────────────▶ │
│ 推送镜像 │ 存储镜像 │
│ │ │
│ │ ◀───────────── docker pull │
│ │ 拉取镜像 │
│ │ │
│ │ docker run │
│ │ 运行容器 │
```
### 常用命令
```bash
# 登录 Registry
$ docker login # 登录 Docker Hub
$ docker login registry.example.com # 登录其他 Registry
# 拉取镜像
$ docker pull nginx:1.25
# 标记镜像(准备推送)
$ docker tag myapp:latest registry.example.com/myteam/myapp:v1.0
# 推送镜像
$ docker push registry.example.com/myteam/myapp:v1.0
# 登出
$ docker logout
```
## 镜像的安全性
### 使用官方镜像
Docker Hub [官方镜像](https://hub.docker.com/search?q=&type=image&image_filter=official)(标有 "Official Image" 标识)经过 Docker 团队审核,相对更安全。
```bash
# 官方镜像示例
nginx # ✅ 官方
mysql # ✅ 官方
redis # ✅ 官方
# 第三方镜像(需要自行评估可信度)
bitnami/redis # ⚠️ 需要评估
someuser/myapp # ⚠️ 需要评估
```
### 镜像签名
使用 Docker Content Trust (DCT) 验证镜像来源
```bash
# 启用镜像签名验证
$ export DOCKER_CONTENT_TRUST=1
# 此后的 pull/push 会验证签名
$ docker pull nginx:latest
```
### 漏洞扫描
```bash
# 使用 Docker Scout 扫描镜像漏洞
$ docker scout cves nginx:latest
# 使用 Trivy开源工具
$ trivy image nginx:latest
```
## 本章小结
| 概念 | 要点 |
|------|------|
| **Registry** | 存储和分发镜像的服务 |
| **仓库Repository** | 同一软件的镜像集合 |
| **标签Tag** | 版本标识默认为 latest |
| **Docker Hub** | 默认的公共 Registry |
| **私有 Registry** | 企业内部使用推荐 Harbor |
现在你已经了解了 Docker 的三个核心概念[镜像](image.md)[容器](container.md)和仓库接下来让我们开始[安装 Docker](../install/README.md)动手实践
## 延伸阅读
- [Docker Hub](../repository/dockerhub.md)Docker Hub 的详细使用
- [私有仓库](../repository/registry.md)搭建私有 Registry
- [私有仓库高级配置](../repository/registry_auth.md)认证TLS 配置
- [镜像加速器](../install/mirror.md)配置镜像加速

View File

Before

Width:  |  Height:  |  Size: 118 KiB

After

Width:  |  Height:  |  Size: 118 KiB

View File

Before

Width:  |  Height:  |  Size: 660 KiB

After

Width:  |  Height:  |  Size: 660 KiB

View File

Before

Width:  |  Height:  |  Size: 291 KiB

After

Width:  |  Height:  |  Size: 291 KiB

View File

Before

Width:  |  Height:  |  Size: 101 KiB

After

Width:  |  Height:  |  Size: 101 KiB

View File

Before

Width:  |  Height:  |  Size: 88 KiB

After

Width:  |  Height:  |  Size: 88 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

@@ -6,7 +6,11 @@
### 系统要求
Docker 支持 64 位版本 CentOS 7/8并且要求内核版本不低于 3.10 CentOS 7 满足最低内核的要求但由于内核版本比较低部分功能 `overlay2` 存储层驱动无法使用并且部分功能可能不太稳定
> **重要提示**CentOS 8 已于 2021 12 31 日停止维护CentOS 7 已于 2024 6 30 日结束支持建议新项目使用 **Rocky Linux** **AlmaLinux** 作为替代
Docker 支持 64 位版本 CentOS Stream 9Rocky Linux 8/9AlmaLinux 8/9并且要求内核版本不低于 3.10
对于 Rocky LinuxAlmaLinux CentOS Stream推荐使用 `dnf` 包管理器
### 卸载旧版本
@@ -22,7 +26,9 @@ $ sudo yum remove docker \
docker-logrotate \
docker-selinux \
docker-engine-selinux \
docker-engine
docker-engine \
docker-ce-cli \
containerd.io
```
## 使用 yum 安装
@@ -30,7 +36,7 @@ $ sudo yum remove docker \
执行以下命令安装依赖包
```bash
$ sudo yum install -y yum-utils
$ sudo dnf install -y dnf-utils
```
鉴于国内网络问题强烈建议使用国内源官方源请在注释中查看
@@ -38,14 +44,14 @@ $ sudo yum install -y yum-utils
执行下面的命令添加 `yum` 软件源
```bash
$ sudo yum-config-manager \
$ sudo dnf config-manager \
--add-repo \
https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
$ sudo sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/yum.repos.d/docker-ce.repo
$ sudo sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/dnf.repos.d/docker-ce.repo
# 官方源
# $ sudo yum-config-manager \
# $ sudo dnf config-manager \
# --add-repo \
# https://download.docker.com/linux/centos/docker-ce.repo
```
@@ -53,15 +59,15 @@ $ sudo sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/yum.r
如果需要测试版本的 Docker 请执行以下命令
```bash
$ sudo yum-config-manager --enable docker-ce-test
$ sudo dnf config-manager --enable docker-ce-test
```
### 安装 Docker
更新 `yum` 软件源缓存并安装 `docker-ce`
更新 `dnf` 软件源缓存并安装 `docker-ce`
```bash
$ sudo yum install docker-ce docker-ce-cli containerd.io
$ sudo dnf install docker-ce docker-ce-cli containerd.io
```
## CentOS8 额外设置

View File

@@ -8,8 +8,9 @@
Docker 支持以下版本的 [Debian](https://www.debian.org/intro/about) 操作系统:
* Debian Bullseye 11
* Debian Buster 10
* Debian Trixie 13 (stable)
* Debian Bookworm 12 (oldstable)
* Debian Bullseye 11 (LTS)
### 卸载旧版本
@@ -65,7 +66,7 @@ $ echo \
```
>以上命令会添加稳定版本的 Docker APT 如果需要测试版本的 Docker 请将 stable 改为 test
>以上命令会添加稳定版本的 Docker APT 如果需要测试版本的 Docker 请将 stable 改为 test Debian11可能不使用`/etc/apt/keyrings/` 如gpg错误可以考虑更换为`/etc/apt/trusted.gpg.d` [issue 15727](https://github.com/docker/docs/issues/15727)。
### 安装 Docker

View File

@@ -8,8 +8,9 @@
Docker 支持以下版本的 [Fedora](https://getfedora.org/) 操作系统:
* 33
* 34
* 41
* 42
* 43
### 卸载旧版本

View File

@@ -1,8 +1,8 @@
# macOS 安装 Docker
# macOS
## 系统要求
[Docker Desktop for Mac](https://docs.docker.com/docker-for-mac/) 要求系统最低为 macOS 必须是 10.15 或更高版本, Catalina、Big Sur 或者 Monterey,建议升级到最新版本的 macOS。
[Docker Desktop for Mac](https://docs.docker.com/docker-for-mac/) 要求系统最低为 macOS Sonora 14.0 或更高版本,建议升级到最新版本的 macOS。
## 安装
@@ -18,31 +18,31 @@ $ brew install --cask docker
如果需要手动下载请点击以下 [链接](https://desktop.docker.com/mac/main/amd64/Docker.dmg) 下载 Docker Desktop for Mac。
> 如果你的电脑搭载的是 M1 芯片`arm64` 架构请点击以下 [链接](https://desktop.docker.com/mac/main/arm64/Docker.dmg) 下载 Docker Desktop for Mac。你可以在 [官方文档](https://docs.docker.com/docker-for-mac/apple-silicon/) 查阅已知的问题。
> 如果你的电脑搭载的是 Apple Silicon 芯片`arm64` 架构请点击以下 [链接](https://desktop.docker.com/mac/main/arm64/Docker.dmg) 下载 Docker Desktop for Mac。你可以在 [官方文档](https://docs.docker.com/docker-for-mac/apple-silicon/) 查阅已知的问题。
如同 macOS 其它软件一样安装也非常简单双击下载的 `.dmg` 文件然后将那只叫 [Moby](https://www.docker.com/blog/call-me-moby-dock/) 的鲸鱼图标拖拽到 `Application` 文件夹即可(其间需要输入用户密码)。
![](./_images/install-mac-dmg.png)
![](../_images/install-mac-dmg.png)
## 运行
从应用中找到 Docker 图标并点击运行
![](./_images/install-mac-apps.png)
![](../_images/install-mac-apps.png)
运行之后会在右上角菜单栏看到多了一个鲸鱼图标这个图标表明了 Docker 的运行状态
![](./_images/install-mac-menubar.png)
![](../_images/install-mac-menubar.png)
每次点击鲸鱼图标会弹出操作菜单
![](./_images/install-mac-menu.png)
![](../_images/install-mac-menu.png)
之后你可以在终端通过命令检查安装后的 Docker 版本
```bash
$ docker --version
Docker version 20.10.0, build 7287ab3
Docker version 26.1.1, build 4cf5afa
```
如果 `docker version``docker info` 都正常的话可以尝试运行一个 [Nginx 服务器](https://hub.docker.com/_/nginx/)
@@ -51,9 +51,9 @@ Docker version 20.10.0, build 7287ab3
$ docker run -d -p 80:80 --name webserver nginx
```
服务运行后可以访问 <http://localhost>,如果看到了 "Welcome to nginx!",就说明 Docker Desktop for Mac 安装成功了。
服务运行后可以访问 [http://localhost](http://localhost),如果看到了 "Welcome to nginx!",就说明 Docker Desktop for Mac 安装成功了。
![](./_images/install-mac-example-nginx.png)
![](../_images/install-mac-example-nginx.png)
要停止 Nginx 服务器并删除执行下面的命令

View File

@@ -1,16 +1,20 @@
# 镜像加速器
国内从 Docker Hub 拉取镜像有时会遇到困难此时可以配置镜像加速器国内很多云服务商都提供了国内加速器服务例如
国内从 Docker Hub 拉取镜像有时会遇到困难此时可以配置镜像加速器
* [阿里云加速器(点击管理控制台 -> 登录账号(淘宝账号) -> 左侧镜像工具 -> 镜像加速器 -> 复制加速器地址)](https://cr.console.aliyun.com/cn-hangzhou/instances)
* [网易云加速器 `https://hub-mirror.c.163.com`](https://www.163yun.com/help/documents/56918246390157312)
* [百度云加速器 `https://mirror.baidubce.com`](https://cloud.baidu.com/doc/CCE/s/Yjxppt74z#%E4%BD%BF%E7%94%A8dockerhub%E5%8A%A0%E9%80%9F%E5%99%A8)
> **注意**镜像加速器的可用性经常变化配置前请先访问 [docker-practice/docker-registry-cn-mirror-test](https://github.com/docker-practice/docker-registry-cn-mirror-test/actions) 查看各镜像站的实时状态。
**由于镜像服务可能出现宕机建议同时配置多个镜像各个镜像站测试结果请到 [docker-practice/docker-registry-cn-mirror-test](https://github.com/docker-practice/docker-registry-cn-mirror-test/actions) 查看。**
## 推荐配置方案
> 国内各大云服务商腾讯云阿里云百度云均提供了 Docker 镜像加速服务建议根据运行 Docker 的云平台选择对应的镜像加速服务具体请参考本页最后一小节
1. **云服务器用户**优先使用所在云平台提供的内部加速器见本页末尾
2. **本地开发用户**使用阿里云个人加速器或其他可用的公共加速器
3. **代理方案**如有条件可配置 HTTP 代理直接访问 Docker Hub
本节我们以 [网易云](https://www.163yun.com/) 镜像服务 `https://hub-mirror.c.163.com` 为例进行介绍。
* [阿里云加速器](https://cr.console.aliyun.com/cn-hangzhou/instances)(需登录获取个人加速地址)
本节以 [AtomHub 可信镜像中心](https://hub.atomgit.com/) 镜像服务 `https://hub.atomgit.com` 为例进行介绍。
> `hub.atomgit.com` 仅包含部分官方镜像可以满足初学者的使用
## Ubuntu 16.04+Debian 8+CentOS 7+
@@ -29,8 +33,7 @@ $ systemctl cat docker | grep '\-\-registry\-mirror'
```json
{
"registry-mirrors": [
"https://hub-mirror.c.163.com",
"https://mirror.baidubce.com"
"https://hub.atomgit.com"
]
}
```
@@ -46,13 +49,12 @@ $ sudo systemctl restart docker
## Windows 10
对于使用 `Windows 10` 的用户在任务栏托盘 Docker 图标内右键菜单选择 `Settings`打开配置窗口后在左侧导航菜单选择 `Docker Engine`在右侧像下边一样编辑 json 文件之后点击 `Apply & Restart` 保存后 Docker 就会重启并应用配置的镜像地址了
对于使用 `Windows 10` 的用户在任务栏托盘 Docker 图标内右键菜单选择 `Change settings`打开配置窗口后在左侧导航菜单选择 `Docker Engine`在右侧像下边一样编辑 json 文件之后点击 `Apply & Restart` 保存后 Docker 就会重启并应用配置的镜像地址了
```json
{
"registry-mirrors": [
"https://hub-mirror.c.163.com",
"https://mirror.baidubce.com"
"https://hub.atomgit.com"
]
}
```
@@ -64,8 +66,7 @@ $ sudo systemctl restart docker
```json
{
"registry-mirrors": [
"https://hub-mirror.c.163.com",
"https://mirror.baidubce.com"
"https://hub.atomgit.com"
]
}
```
@@ -76,7 +77,7 @@ $ sudo systemctl restart docker
```bash
Registry Mirrors:
https://hub-mirror.c.163.com/
https://hub.atomgit.com/
```
## `k8s.gcr.io` 镜像
@@ -100,6 +101,8 @@ $ docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/xxx
* https://dockerhub.azk8s.cn **已转为私有**
* https://reg-mirror.qiniu.com
* https://registry.docker-cn.com
* https://hub-mirror.c.163.com
* https://mirror.baidubce.com
建议 **watch页面右上角** [镜像测试](https://github.com/docker-practice/docker-registry-cn-mirror-test) 这个 GitHub 仓库,我们会在此更新各个镜像地址的状态。

View File

@@ -1,22 +1,22 @@
# 离线部署Docker
# Linux 离线安装
[TOC]
\[TOC]
生产环境中一般都是没有公网资源的本文介绍如何在生产服务器上离线部署`Docker`
括号内的字母表示该操作需要在哪些服务器上执行
<img src="_images/image-20200412202617411.png" alt="Docker-offile-install-top" style="zoom:30%;" />
![Docker-offile-install-top](../_images/image-20200412202617411.png)
## Centos7 离线安装Docker
## CentOS/Rocky/AlmaLinux 离线安装Docker
> 注意以下命令以 CentOS 7 为例对于 CentOS Stream 9Rocky Linux 9 AlmaLinux 9请将 `yum` 替换为 `dnf`并将软件包后缀 `el7` 替换为 `el9`
### YUM本地文件安装推荐
推荐这种方式是因为在生产环境种一般会选定某个指定的文档软件版本使用
#### 查询可用的软件版本(A)
#### 查询可用的软件版本(A)
```bash
#下载清华的镜像源文件
@@ -77,28 +77,32 @@ Background downloading packages, then exiting:
Total 118 MB/s | 87 MB 00:00:00
exiting because "Download Only" specified
```
#### 复制到目标服务器之后进入文件夹安装(C-N)
* 离线安装时必须使用rpm命令不检查依赖的方式安装
```bash
rpm -Uvh *.rpm --nodeps --force
```
#### 锁定软件版本(C-N)
##### 下载锁定版本软件
**下载锁定版本软件**
可参考下文的网络源搭建
```bash
sudo yum install yum-plugin-versionlock
```
##### 锁定软件版本
**锁定软件版本**
```bash
sudo yum versionlock add docker
```
##### 查看锁定列表
**查看锁定列表**
```bash
sudo yum versionlock list
@@ -110,7 +114,7 @@ Loaded plugins: fastestmirror, versionlock
versionlock list done
```
##### 锁定后无法再更新
**锁定后无法再更新**
```bash
sudo yum install docker-ce
@@ -121,7 +125,7 @@ Package 3:docker-ce-24.0.4-1.el7.x86_64 already installed and latest version
Nothing to do
```
##### 解锁指定软件
**解锁指定软件**
```bash
sudo yum versionlock delete docker-ce
@@ -133,14 +137,12 @@ Deleting versionlock for: 3:docker-ce-24.0.4-1.el7.*
versionlock deleted: 1
```
##### 解锁所有软件
**解锁所有软件**
```bash
sudo yum versionlock delete all
```
### YUM 本地源服务器搭建安装Docker
#### 挂载 ISO 镜像搭建本地 File AB
@@ -170,8 +172,6 @@ yum clean all
yum install createrepo -y
```
#### 根据本地文件搭建BASE网络源B
```bash
@@ -245,5 +245,3 @@ sudo yum makecache fast
sudo yum install docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker
```

View File

@@ -8,7 +8,9 @@ Docker 不仅支持 `x86_64` 架构的计算机,同时也支持 `ARM` 架构
Docker 支持以下版本的 [Raspberry Pi OS](https://www.raspberrypi.org/software/operating-systems/) 操作系统:
* Raspberry Pi OS Buster
* Raspberry Pi OS Trixie
* Raspberry Pi OS Bookworm
* Raspberry Pi OS Bullseye
** `Raspberry Pi OS` 由树莓派的开发与维护机构 [树莓派基金会](https://www.raspberrypi.org/) 官方支持,并推荐用作树莓派的首选系统,其基于 `Debian`。
@@ -58,6 +60,33 @@ $ sudo add-apt-repository \
>以上命令会添加稳定版本的 Docker APT 如果需要测试版本的 Docker 请将 stable 改为 test
#### 报错解决办法
`Raspberry Pi OS Bullseye/Bookworm` 添加 Docker 软件源的步骤可能会出现如下报错:
```bash
Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 95, in <module>
sp = SoftwareProperties(options=options)
File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 109, in __init__
self.reload_sourceslist()
File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 599, in reload_sourceslist
self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources
raise NoDistroTemplateException(
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/bullseye
```
通过以下命令手动添加镜像源到 `/etc/apt/sources.list` 文件中即可解决:
```bash
$ sudo echo "deb [arch=armhf] https://mirrors.aliyun.com/docker-ce/linux/raspbian $(lsb_release -cs) stable" | sudo tee -a /etc/apt/sources.list
# 官方源
# $ sudo echo "deb [arch=armhf] https://download.docker.com/linux/raspbian $(lsb_release -cs) stable" | sudo tee -a /etc/apt/sources.list
```
### 安装 Docker
更新 apt 软件包缓存并安装 `docker-ce`

View File

@@ -6,23 +6,31 @@
### 系统要求
Docker 支持以下版本的 [Ubuntu](https://ubuntu.com/server) 操作系统:
Docker 支持诸多版本的 [Ubuntu](https://ubuntu.com/server) 操作系统。但是较旧的版本上将不会有 Docker 新版本的持续更新,以截至 2026 年初的几个 Ubuntu LTSLong Term Support长期支持版本为例
* Ubuntu Hirsute 21.04
* Ubuntu Groovy 20.10
* Ubuntu Focal 20.04 (LTS)
* Ubuntu Bionic 18.04 (LTS)
Docker 可以安装在 64 位的 x86 平台或 ARM 平台上Ubuntu 发行版中LTSLong-Term-Support长期支持版本会获得 5 年的升级维护支持这样的版本会更稳定因此在生产环境中推荐使用 LTS 版本
* Ubuntu Noble 24.04 (LTS)Docker v30.x
* Ubuntu Jammy 22.04 (LTS), Docker v30.x
> **注意**Ubuntu 20.04 LTS 已于 2025 年结束标准支持不再推荐用于新部署
Ubuntu LTS 版本上目前 Docker 支持 amd64arm64armhfppc64els390x 5 个平台而非 LTS 版本支持的平台通常较少同时LTS 版本会获得 5 年的升级维护支持这样的系统会获得更长期的安全保障因此在生产环境中推荐使用 LTS 版本
### 卸载旧版本
旧版本的 Docker 称为 `docker` 或者 `docker-engine`使用以下命令卸载旧版本
```bash
$ sudo apt-get remove docker \
docker-engine \
docker.io
$ for pkg in docker \
docker-engine \
docker.io \
docker-doc \
podman-docker \
containerd \
runc;
do
sudo apt remove $pkg;
done
```
## 使用 APT 安装
@@ -30,9 +38,9 @@ $ sudo apt-get remove docker \
由于 `apt` 源使用 HTTPS 以确保软件下载过程中不被篡改因此我们首先需要添加使用 HTTPS 传输的软件包以及 CA 证书
```bash
$ sudo apt-get update
$ sudo apt update
$ sudo apt-get install \
$ sudo apt install \
apt-transport-https \
ca-certificates \
curl \
@@ -73,9 +81,9 @@ $ echo \
更新 apt 软件包缓存并安装 `docker-ce`
```bash
$ sudo apt-get update
$ sudo apt update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
$ sudo apt install docker-ce docker-ce-cli containerd.io
```
## 使用脚本自动安装

View File

@@ -1,8 +1,8 @@
# Windows 10 安装 Docker
# Windows 10/11
## 系统要求
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/) 支持 64 位版本的 Windows 10 Pro且必须开启 Hyper-V若版本为 v1903 及以上则无需开启 Hyper-V或者 64 位版本的 Windows 10 Home v1903 及以上版本
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/) 支持 64 位版本的 Windows 11 或 Windows 10需开启 Hyper-V推荐使用 Windows 11
## 安装
@@ -12,7 +12,7 @@
下载好之后双击 `Docker Desktop Installer.exe` 开始安装
**使用 [winget](https://docs.microsoft.com/zh-cn/windows/package-manager/) 安装**
**使用** [**winget**](https://docs.microsoft.com/zh-cn/windows/package-manager/) **安装**
```powershell
$ winget install Docker.DockerDesktop
@@ -26,11 +26,11 @@ $ winget install Docker.DockerDesktop
Windows 搜索栏输入 **Docker** 点击 **Docker Desktop** 开始运行
![](./_images/install-win-docker-app-search.png)
![](../_images/install-win-docker-app-search.png)
Docker 启动之后会在 Windows 任务栏出现鲸鱼图标
![](./_images/install-win-taskbar-circle.png)
![](../_images/install-win-taskbar-circle.png)
等待片刻当鲸鱼图标静止时说明 Docker 启动成功之后你可以打开 PowerShell 使用 Docker

View File

Before

Width:  |  Height:  |  Size: 77 KiB

After

Width:  |  Height:  |  Size: 77 KiB

View File

Before

Width:  |  Height:  |  Size: 101 KiB

After

Width:  |  Height:  |  Size: 101 KiB

View File

@@ -4,6 +4,18 @@
Dockerfile 是一个文本文件其内包含了一条条的 **指令(Instruction)**每一条指令构建一层因此每一条指令的内容就是描述该层应当如何构建
## 使用 docker init 快速创建推荐
Docker 提供了 `docker init` 命令可以根据项目类型自动生成 Dockerfile.dockerignore compose.yaml 文件
```bash
$ docker init
```
该命令会交互式地询问项目类型 GoNode.jsPythonRust 并生成符合最佳实践的配置文件对于新项目这是推荐的起步方式
## 手动创建 Dockerfile
还以之前定制 `nginx` 镜像为例这次我们使用 Dockerfile 来定制
在一个空白目录中建立一个文本文件并命名为 `Dockerfile`
@@ -57,11 +69,11 @@ RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
既然 `RUN` 就像 Shell 脚本一样可以执行命令那么我们是否就可以像 Shell 脚本一样把每个命令对应一个 RUN 比如这样
```docker
FROM debian:stretch
FROM debian:bookworm
RUN apt-get update
RUN apt-get install -y gcc libc6-dev make wget
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz"
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-7.2.4.tar.gz"
RUN mkdir -p /usr/src/redis
RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
RUN make -C /usr/src/redis
@@ -78,12 +90,12 @@ RUN make -C /usr/src/redis install
上面的 `Dockerfile` 正确的写法应该是这样
```docker
FROM debian:stretch
FROM debian:bookworm
RUN set -x; buildDeps='gcc libc6-dev make wget' \
&& apt-get update \
&& apt-get install -y $buildDeps \
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-7.2.4.tar.gz" \
&& mkdir -p /usr/src/redis \
&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
&& make -C /usr/src/redis \

View File

@@ -1,6 +1,6 @@
# 利用 commit 理解镜像构成
>注意如果您是初学者您可以暂时跳过后面的内容直接学习 [容器](../container) 一节
> 注意如果您是初学者您可以暂时跳过后面的内容直接学习 [容器](../05_container/) 一节
注意 `docker commit` 命令除了学习之外还有一些特殊的应用场合比如被入侵后保存现场等但是不要使用 `docker commit` 定制镜像定制镜像应该使用 `Dockerfile` 来完成如果你想要定制镜像请查看下一小节
@@ -16,11 +16,11 @@ $ docker run --name webserver -d -p 80:80 nginx
这条命令会用 `nginx` 镜像启动一个容器命名为 `webserver`并且映射了 80 端口这样我们可以用浏览器去访问这个 `nginx` 服务器
如果是在本机运行的 Docker那么可以直接访问`http://localhost` 如果是在虚拟机云服务器上安装的 Docker则需要将 `localhost` 换为虚拟机地址或者实际云服务器地址
如果是在本机运行的 Docker那么可以直接访问`http://localhost` 如果是在虚拟机云服务器上安装的 Docker则需要将 `localhost` 换为虚拟机地址或者实际云服务器地址
直接用浏览器访问的话我们会看到默认的 Nginx 欢迎页面
![](./_images/images-mac-example-nginx.png)
![](../_images/images-mac-example-nginx.png)
现在假设我们非常不喜欢这个欢迎页面我们希望改成欢迎 Docker 的文字我们可以使用 `docker exec` 命令进入容器修改其内容
@@ -37,7 +37,7 @@ exit
现在我们再刷新浏览器的话会发现内容被改变了
![](./_images/images-create-nginx-docker.png)
![](../_images/images-create-nginx-docker.png)
我们修改了容器的文件也就是改动了容器的存储层我们可以通过 `docker diff` 命令看到具体的改动
@@ -90,7 +90,7 @@ sha256:07e33465974800ce65751acc279adc6ed2dc5ed4e0838f8b86f0c87aa1795214
$ docker image ls nginx
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx v2 07e334659748 9 seconds ago 181.5 MB
nginx 1.11 05a60462f8ba 12 days ago 181.5 MB
nginx 1.27 05a60462f8ba 12 days ago 181.5 MB
nginx latest e43d811ce2f4 4 weeks ago 181.5 MB
```
@@ -104,7 +104,7 @@ e43d811ce2f4 4 weeks ago /bin/sh -c #(nop) CMD ["nginx" "-g" "da
<missing> 4 weeks ago /bin/sh -c #(nop) EXPOSE 443/tcp 80/tcp 0 B
<missing> 4 weeks ago /bin/sh -c ln -sf /dev/stdout /var/log/nginx/ 22 B
<missing> 4 weeks ago /bin/sh -c apt-key adv --keyserver hkp://pgp. 58.46 MB
<missing> 4 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.11.5-1 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.27.0-1 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) MAINTAINER NGINX Docker Ma 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 4 weeks ago /bin/sh -c #(nop) ADD file:23aa4f893e3288698c 123 MB

221
04_image/dockerfile/add.md Normal file
View File

@@ -0,0 +1,221 @@
# ADD 更高级的复制文件
## 基本语法
```docker
ADD [选项] <源路径>... <目标路径>
ADD [选项] ["<源路径>", ... "<目标路径>"]
```
`ADD` `COPY` 基础上增加了两个功能
1. 自动解压 tar 压缩包
2. 支持从 URL 下载文件不推荐
---
## ADD vs COPY
| 特性 | COPY | ADD |
|------|------|-----|
| 复制本地文件 | | |
| 自动解压 tar | | |
| 支持 URL | | 不推荐 |
| 行为可预测性 | | |
| 推荐程度 | **优先使用** | 仅解压场景 |
> 笔者建议除非需要自动解压 tar 文件否则始终使用 COPY明确的行为比隐式的魔法更好
---
## 自动解压功能
### 基本用法
```docker
# 自动解压 tar.gz 到目标目录
ADD app.tar.gz /app/
```
ADD 会识别并解压以下格式
- `.tar`
- `.tar.gz` / `.tgz`
- `.tar.bz2` / `.tbz2`
- `.tar.xz` / `.txz`
### 实际应用
官方基础镜像通常使用 ADD 解压根文件系统
```docker
FROM scratch
ADD ubuntu-noble-core-cloudimg-amd64-root.tar.gz /
```
### 解压过程
```
ADD app.tar.gz /app/
├─ 识别 .tar.gz 格式
├─ 自动解压
└─ 内容放入 /app/
app.tar.gz 包含: /app/ 目录结果:
├── src/ ├── src/
│ └── main.py │ └── main.py
└── config.json └── config.json
```
---
## URL 下载功能不推荐
### 基本用法
```docker
# 从 URL 下载文件
ADD https://example.com/app.zip /app/app.zip
```
### 为什么不推荐
| 问题 | 说明 |
|------|------|
| 权限固定 | 下载的文件权限为 600通常需要额外 RUN 修改 |
| 不会解压 | URL 下载的压缩包不会自动解压 |
| 缓存问题 | URL 内容变化时不会重新下载 |
| 层数增加 | 需要额外 RUN 清理 |
### 推荐替代方案
```docker
# ❌ 不推荐:使用 ADD 下载
ADD https://example.com/app.tar.gz /tmp/
RUN tar -xzf /tmp/app.tar.gz -C /app && rm /tmp/app.tar.gz
# ✅ 推荐:使用 RUN + curl
RUN curl -fsSL https://example.com/app.tar.gz | tar -xz -C /app
```
优势
- 一条 RUN 完成下载解压清理
- 减少镜像层数
- 更清晰的构建意图
---
## 修改文件所有者
```docker
ADD --chown=node:node app.tar.gz /app/
ADD --chown=1000:1000 files/ /app/
```
---
## 何时使用 ADD
### 适合使用 ADD
```docker
# 解压本地 tar 文件
FROM scratch
ADD rootfs.tar.gz /
# 解压应用包
ADD dist.tar.gz /app/
```
### 不适合使用 ADD
```docker
# 复制普通文件(用 COPY
ADD package.json /app/ # ❌
COPY package.json /app/ # ✅
# 下载文件(用 RUN + curl
ADD https://example.com/file / # ❌
RUN curl -fsSL ... -o /file # ✅
# 需要保留 tar 不解压(用 COPY
ADD archive.tar.gz /archives/ # ❌ 会解压
COPY archive.tar.gz /archives/ # ✅ 保持原样
```
---
## 缓存行为
ADD 可能导致构建缓存失效
```docker
# 如果 app.tar.gz 内容变化,此层及后续层都需重建
ADD app.tar.gz /app/
RUN npm install
```
**优化建议**
```docker
# 先复制依赖文件
COPY package*.json /app/
RUN npm install
# 再添加应用代码
ADD app.tar.gz /app/
```
---
## 最佳实践
### 1. 默认使用 COPY
```docker
# ✅ 大多数场景使用 COPY
COPY . /app/
```
### 2. 仅在需要解压时使用 ADD
```docker
# ✅ 自动解压场景
ADD app.tar.gz /app/
```
### 3. 不要用 ADD 下载文件
```docker
# ❌ 避免
ADD https://example.com/file.tar.gz /tmp/
# ✅ 推荐
RUN curl -fsSL https://example.com/file.tar.gz | tar -xz -C /app
```
### 4. 解压后清理
```docker
# 如果需要控制解压过程
COPY app.tar.gz /tmp/
RUN tar -xzf /tmp/app.tar.gz -C /app && \
rm /tmp/app.tar.gz
```
---
## 本章小结
| 场景 | 推荐指令 |
|------|---------|
| 复制普通文件 | `COPY` |
| 复制目录 | `COPY` |
| 自动解压 tar | `ADD` |
| URL 下载 | `RUN curl` |
| 保持 tar 不解压 | `COPY` |
## 延伸阅读
- [COPY 复制文件](copy.md)基本复制操作
- [多阶段构建](../multistage-builds.md)减少镜像体积
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 编写指南

238
04_image/dockerfile/arg.md Normal file
View File

@@ -0,0 +1,238 @@
# ARG 构建参数
## 基本语法
```docker
ARG <参数名>[=<默认值>]
```
`ARG` 指令定义构建时的变量可以在 `docker build` 时通过 `--build-arg` 传入
---
## ARG vs ENV
| 特性 | ARG | ENV |
|------|-----|-----|
| **生效时间** | 仅构建时 | 构建时 + 运行时 |
| **持久性** | 构建后消失 | 写入镜像 |
| **覆盖方式** | `docker build --build-arg` | `docker run -e` |
| **适用场景** | 构建参数版本号等 | 应用配置 |
| **可见性** | `docker history` 可见 | `docker inspect` 可见 |
```
构建时 运行时
├─ ARG VERSION=1.0 │ ARG 已消失)
├─ ENV APP_ENV=prod │ APP_ENV=prod仍存在
└─ RUN echo $VERSION │
```
> **安全提示**不要用 ARG 传递密码等敏感信息`docker history` 可以查看所有 ARG
---
## 基本用法
### 定义和使用
```docker
# 定义有默认值的 ARG
ARG NODE_VERSION=20
# 使用 ARG
FROM node:${NODE_VERSION}-alpine
RUN echo "Using Node.js $NODE_VERSION"
```
### 构建时覆盖
```bash
# 使用默认值
$ docker build -t myapp .
# 覆盖默认值
$ docker build --build-arg NODE_VERSION=18 -t myapp .
```
---
## ARG 的作用域
### FROM 之前的 ARG
```docker
# FROM 之前的 ARG 只能用于 FROM 指令
ARG REGISTRY=docker.io
ARG IMAGE_NAME=node
FROM ${REGISTRY}/${IMAGE_NAME}:20
# ❌ 这里无法使用上面的 ARG
RUN echo $REGISTRY # 输出空
```
### FROM 之后重新声明
```docker
ARG NODE_VERSION=20
FROM node:${NODE_VERSION}-alpine
# 需要再次声明才能使用
ARG NODE_VERSION
RUN echo "Node version: $NODE_VERSION"
```
### 多阶段构建中的 ARG
```docker
ARG BASE_VERSION=alpine
FROM node:20-${BASE_VERSION} AS builder
# 需要重新声明
ARG NODE_VERSION=20
RUN echo "Building with Node $NODE_VERSION"
FROM node:20-${BASE_VERSION}
# 每个阶段都需要重新声明
ARG NODE_VERSION=20
RUN echo "Running with Node $NODE_VERSION"
```
---
## 常见使用场景
### 1. 控制基础镜像版本
```docker
ARG ALPINE_VERSION=3.19
FROM alpine:${ALPINE_VERSION}
```
```bash
$ docker build --build-arg ALPINE_VERSION=3.18 .
```
### 2. 设置软件版本
```docker
ARG NGINX_VERSION=1.25.0
RUN curl -fsSL https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz | tar -xz
```
### 3. 配置构建环境
```docker
ARG BUILD_ENV=production
ARG ENABLE_DEBUG=false
RUN if [ "$ENABLE_DEBUG" = "true" ]; then \
npm install --include=dev; \
else \
npm install --production; \
fi
```
### 4. 配置私有仓库
```docker
ARG NPM_TOKEN
RUN echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc && \
npm install && \
rm ~/.npmrc
```
```bash
# 构建时传入 token
$ docker build --build-arg NPM_TOKEN=xxx .
```
---
## ARG 传递给 ENV
如果需要在运行时使用 ARG 的值
```docker
ARG VERSION=1.0.0
# 将 ARG 传递给 ENV
ENV APP_VERSION=$VERSION
# 运行时可用
CMD echo "App version: $APP_VERSION"
```
---
## 预定义 ARG
Docker 提供了一些预定义的 ARG无需声明即可使用
| ARG | 说明 |
|-----|------|
| `HTTP_PROXY` | HTTP 代理 |
| `HTTPS_PROXY` | HTTPS 代理 |
| `NO_PROXY` | 不使用代理的地址 |
| `FTP_PROXY` | FTP 代理 |
```bash
# 构建时使用代理
$ docker build --build-arg HTTP_PROXY=http://proxy:8080 .
```
---
## 最佳实践
### 1. ARG 提供合理默认值
```docker
# ✅ 好:有默认值
ARG NODE_VERSION=20
# ⚠️ 需要每次传入
ARG NODE_VERSION
```
### 2. 不要用 ARG 存储敏感信息
```docker
# ❌ 错误:密码会被记录在镜像历史中
ARG DB_PASSWORD
RUN echo "password=$DB_PASSWORD" > /app/.env
# ✅ 正确:使用 secrets 或运行时环境变量
```
### 3. 使用 ARG 提高构建灵活性
```docker
ARG BASE_IMAGE=python:3.12-slim
FROM ${BASE_IMAGE}
# 可以构建不同基础镜像的版本
# docker build --build-arg BASE_IMAGE=python:3.11-alpine .
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 定义构建时变量 |
| **语法** | `ARG NAME=value` |
| **覆盖** | `docker build --build-arg NAME=value` |
| **作用域** | FROM 之后需要重新声明 |
| **vs ENV** | ARG 仅构建时ENV 构建+运行时 |
| **安全** | 不要存储敏感信息 |
## 延伸阅读
- [ENV 设置环境变量](env.md)运行时环境变量
- [FROM 指令](../../04_image/build.md)基础镜像指定
- [多阶段构建](../multistage-builds.md)复杂构建场景

268
04_image/dockerfile/cmd.md Normal file
View File

@@ -0,0 +1,268 @@
# CMD 容器启动命令
## 什么是 CMD
`CMD` 指令用于指定容器启动时默认执行的命令它定义了容器的"主进程"
> **核心概念**容器的生命周期 = 主进程的生命周期CMD 指定的命令就是这个主进程
---
## 语法格式
CMD 有三种格式
| 格式 | 语法 | 推荐程度 |
|------|------|---------|
| **exec 格式** | `CMD ["可执行文件", "参数1", "参数2"]` | **推荐** |
| **shell 格式** | `CMD 命令 参数1 参数2` | 简单场景 |
| **参数格式** | `CMD ["参数1", "参数2"]` | 配合 ENTRYPOINT |
### exec 格式推荐
```docker
CMD ["nginx", "-g", "daemon off;"]
CMD ["python", "app.py"]
CMD ["node", "server.js"]
```
**优点**
- 直接执行指定程序是容器的 PID 1
- 正确接收信号 SIGTERM
- 无需 shell 解析
### shell 格式
```docker
CMD echo "Hello World"
CMD nginx -g "daemon off;"
```
**实际执行**会被包装为 `sh -c`
```docker
# 你写的
CMD echo $HOME
# 实际执行的
CMD ["sh", "-c", "echo $HOME"]
```
**优点**可以使用环境变量管道等 shell 特性
**缺点**主进程是 sh信号无法正确传递给应用
---
## exec 格式 vs shell 格式
| 特性 | exec 格式 | shell 格式 |
|------|----------|-----------|
| 主进程 | 指定的程序 | `/bin/sh` |
| 信号传递 | 正确 | 无法传递 |
| 环境变量 | 需要 shell 包装 | 自动解析 |
| 推荐使用 | 大多数场景 | 需要 shell 特性时 |
### 信号传递问题示例
```docker
# ❌ shell 格式docker stop 会超时
CMD node server.js
# 实际是 sh -c "node server.js"
# SIGTERM 发给 sh不会传递给 node
# ✅ exec 格式docker stop 正常工作
CMD ["node", "server.js"]
# SIGTERM 直接发给 node
```
---
## 运行时覆盖 CMD
`docker run` 后的命令会覆盖 Dockerfile 中的 CMD
```bash
# ubuntu 默认 CMD 是 /bin/bash
$ docker run -it ubuntu # 进入 bash
$ docker run ubuntu cat /etc/os-release # 覆盖为 cat 命令
```
```
Dockerfile: docker run 命令:
CMD ["/bin/bash"] + cat /etc/os-release
│ │
└───────► 被覆盖 ◄───────┘
执行: cat /etc/os-release
```
---
## 经典错误容器立即退出
### 错误示例
```docker
# ❌ 容器启动后立即退出
CMD service nginx start
```
### 原因分析
```
1. CMD service nginx start
↓ 被转换为
2. CMD ["sh", "-c", "service nginx start"]
3. sh 启动,执行 service 命令
4. service 命令将 nginx 放到后台
5. service 命令结束sh 退出
6. 容器主进程sh退出 → 容器停止
```
### 正确做法
```docker
# ✅ 让 nginx 在前台运行
CMD ["nginx", "-g", "daemon off;"]
```
---
## CMD vs ENTRYPOINT
| 指令 | 用途 | 运行时行为 |
|------|------|-----------|
| **CMD** | 默认命令 | `docker run` 参数会**覆盖** |
| **ENTRYPOINT** | 入口点 | `docker run` 参数会**追加**到它后面 |
### 单独使用 CMD
```docker
# Dockerfile
CMD ["curl", "-s", "http://example.com"]
```
```bash
$ docker run myimage # 执行默认命令
$ docker run myimage curl -v ... # 完全覆盖
```
### 搭配 ENTRYPOINT
```docker
# Dockerfile
ENTRYPOINT ["curl", "-s"]
CMD ["http://example.com"]
```
```bash
$ docker run myimage # curl -s http://example.com
$ docker run myimage http://other.com # curl -s http://other.com参数覆盖
```
详见 [ENTRYPOINT 入口点](entrypoint.md) 章节
---
## 最佳实践
### 1. 优先使用 exec 格式
```docker
# ✅ 推荐
CMD ["python", "app.py"]
# ⚠️ 仅在需要 shell 特性时使用
CMD ["sh", "-c", "echo $PATH && python app.py"]
```
### 2. 确保应用在前台运行
```docker
# ✅ 前台运行
CMD ["nginx", "-g", "daemon off;"]
CMD ["apache2ctl", "-D", "FOREGROUND"]
CMD ["java", "-jar", "app.jar"]
# ❌ 不要使用后台服务命令
CMD service nginx start
CMD systemctl start nginx
```
### 3. 使用双引号
```docker
# ✅ 正确:双引号
CMD ["node", "server.js"]
# ❌ 错误单引号JSON 不支持)
CMD ['node', 'server.js']
```
### 4. 配合 ENTRYPOINT 使用
```docker
# 用于可配置参数的场景
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]
# 运行时可以覆盖端口
$ docker run myapp --port 9000
```
---
## 常见问题
### Q: CMD 可以写多个吗
不可以多个 CMD 只有最后一个生效
```docker
CMD ["echo", "first"]
CMD ["echo", "second"] # 只有这个生效
```
### Q: 如何在 CMD 中使用环境变量
```docker
# 方法1使用 shell 格式
CMD echo "Port is $PORT"
# 方法2显式使用 sh -c
CMD ["sh", "-c", "echo Port is $PORT"]
```
### Q: 为什么我的容器不响应 Ctrl+C
可能是使用了 shell 格式信号被 sh 吃掉了
```docker
# ❌ 信号无法传递
CMD python app.py
# ✅ 信号正确传递
CMD ["python", "app.py"]
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 指定容器启动时的默认命令 |
| **推荐格式** | exec 格式 `CMD ["程序", "参数"]` |
| **覆盖方式** | `docker run image 新命令` |
| ** ENTRYPOINT** | CMD 作为 ENTRYPOINT 的默认参数 |
| **核心原则** | 应用必须在前台运行 |
## 延伸阅读
- [ENTRYPOINT 入口点](entrypoint.md)固定的启动命令
- [后台运行](../../05_container/daemon.md)容器前台/后台概念
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 编写指南

261
04_image/dockerfile/copy.md Normal file
View File

@@ -0,0 +1,261 @@
# COPY 复制文件
## 基本语法
```docker
COPY [选项] <源路径>... <目标路径>
COPY [选项] ["<源路径1>", "<源路径2>", ... "<目标路径>"]
```
`COPY` 指令将构建上下文中的文件或目录复制到镜像内
---
## 基本用法
### 复制单个文件
```docker
# 复制文件到指定目录
COPY package.json /app/
# 复制文件并重命名
COPY config.json /app/settings.json
```
### 复制多个文件
```docker
# 复制多个指定文件
COPY package.json package-lock.json /app/
# 使用通配符
COPY *.json /app/
COPY src/*.js /app/src/
```
### 复制目录
```docker
# 复制整个目录的内容(不是目录本身)
COPY src/ /app/src/
```
> **注意**复制目录时复制的是目录的**内容**不包含目录本身
```
构建上下文: 镜像内:
src/ /app/src/
├── index.js → ├── index.js
└── utils.js └── utils.js
```
---
## 通配符规则
COPY 支持 Go `filepath.Match` 通配符规则
| 通配符 | 说明 | 示例 |
|--------|------|------|
| `*` | 匹配任意字符序列 | `*.json` |
| `?` | 匹配单个字符 | `config?.json` |
| `[abc]` | 匹配括号内任一字符 | `[abc].txt` |
| `[a-z]` | 匹配范围内字符 | `file[0-9].txt` |
```docker
COPY hom* /mydir/ # home.txt, homework.md 等
COPY hom?.txt /mydir/ # home.txt, homy.txt 等
COPY app[0-9].js /app/ # app0.js ~ app9.js
```
---
## 目标路径
### 绝对路径
```docker
COPY app.js /usr/src/app/
```
### 相对路径基于 WORKDIR
```docker
WORKDIR /app
COPY package.json ./ # 复制到 /app/package.json
COPY src/ ./src/ # 复制到 /app/src/
```
### 自动创建目录
如果目标目录不存在Docker 会自动创建
```docker
# /app/config/ 不存在也会自动创建
COPY settings.json /app/config/
```
---
## 修改文件所有者
使用 `--chown` 选项设置文件的用户和组
```docker
# 使用用户名和组名
COPY --chown=node:node package.json /app/
# 使用 UID 和 GID
COPY --chown=1000:1000 . /app/
# 只指定用户
COPY --chown=node . /app/
```
> 💡 结合 `USER` 指令使用确保应用以非 root 用户运行
---
## 保留文件元数据
COPY 会保留源文件的元数据
- 执行权限
- 修改时间
这对于脚本文件特别重要
```docker
# start.sh 的可执行权限会被保留
COPY start.sh /app/
```
---
## COPY vs ADD
| 特性 | COPY | ADD |
|------|------|-----|
| 复制本地文件 | | |
| 自动解压 tar | | |
| 支持 URL | | 不推荐 |
| 推荐程度 | **推荐** | 特殊场景使用 |
```docker
# 推荐:使用 COPY
COPY app.tar.gz /app/
RUN tar -xzf /app/app.tar.gz
# ADD 会自动解压(行为不明显,不推荐)
ADD app.tar.gz /app/
```
> 笔者建议除非需要自动解压 tar 文件否则始终使用 COPY明确的行为比隐式的魔法更好
---
## 多阶段构建中的 COPY
### 从其他构建阶段复制
```docker
# 构建阶段
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
# 生产阶段
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
```
### 使用 --link 优化缓存BuildKit
```docker
# 使用 --link 后,文件以独立层添加,不依赖前序指令
COPY --link --from=builder /app/dist /usr/share/nginx/html
```
`--link` 的优势
- 更高效利用构建缓存
- 并行化构建过程
- 加速多阶段构建
---
## .dockerignore
使用 `.dockerignore` 排除不需要复制的文件
```gitignore
# .dockerignore
node_modules
.git
.env
*.log
Dockerfile
.dockerignore
```
这可以
- 减小构建上下文大小
- 加速构建
- 避免复制敏感文件
---
## 最佳实践
### 1. 利用缓存先复制依赖文件
```docker
# ✅ 好:先复制依赖定义,再安装,最后复制代码
COPY package.json package-lock.json ./
RUN npm install
COPY . .
# ❌ 差:一次性复制所有文件,代码变更会导致重新 npm install
COPY . .
RUN npm install
```
### 2. 使用 .dockerignore
```docker
# 确保 node_modules 不被复制
COPY . .
# .dockerignore 中应包含 node_modules
```
### 3. 明确复制路径
```docker
# ✅ 好:明确的路径
COPY src/ /app/src/
COPY package.json /app/
# ❌ 差:过于宽泛
COPY . .
```
---
## 本章小结
| 操作 | 示例 |
|------|------|
| 复制文件 | `COPY app.js /app/` |
| 复制多个文件 | `COPY *.json /app/` |
| 复制目录内容 | `COPY src/ /app/src/` |
| 修改所有者 | `COPY --chown=node:node . /app/` |
| 从构建阶段复制 | `COPY --from=builder /app/dist ./` |
## 延伸阅读
- [ADD 指令](add.md)复制和解压
- [WORKDIR 指令](workdir.md)设置工作目录
- [多阶段构建](../multistage-builds.md)优化镜像大小
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 编写指南

View File

@@ -0,0 +1,306 @@
# ENTRYPOINT 入口点
## 什么是 ENTRYPOINT
`ENTRYPOINT` 指定容器启动时运行的入口程序 CMD 不同ENTRYPOINT 定义的命令不会被 `docker run` 的参数覆盖而是**接收这些参数**
> **核心作用**让镜像像一个可执行程序一样使用`docker run` 的参数作为这个程序的参数
---
## 语法格式
| 格式 | 语法 | 推荐程度 |
|------|------|---------|
| **exec 格式** | `ENTRYPOINT ["可执行文件", "参数1"]` | **推荐** |
| **shell 格式** | `ENTRYPOINT 命令 参数` | 不推荐 |
```docker
# exec 格式(推荐)
ENTRYPOINT ["nginx", "-g", "daemon off;"]
# shell 格式(不推荐)
ENTRYPOINT nginx -g "daemon off;"
```
---
## ENTRYPOINT vs CMD
### 核心区别
| 特性 | ENTRYPOINT | CMD |
|------|------------|-----|
| **定位** | 固定的入口程序 | 默认参数 |
| **docker run 参数** | 追加为参数 | 完全覆盖 |
| **覆盖方式** | `--entrypoint` | 直接指定命令 |
| **适用场景** | 把镜像当命令用 | 提供默认行为 |
### 行为对比
```docker
# 只用 CMD
CMD ["curl", "-s", "http://example.com"]
```
```bash
$ docker run myimage # curl -s http://example.com
$ docker run myimage -v # 执行 -v错误
$ docker run myimage curl -v ... # curl -v ...(完全替换)
```
```docker
# 只用 ENTRYPOINT
ENTRYPOINT ["curl", "-s"]
```
```bash
$ docker run myimage # curl -s缺参数
$ docker run myimage http://example.com # curl -s http://example.com ✓
```
```docker
# ENTRYPOINT + CMD 组合(推荐)
ENTRYPOINT ["curl", "-s"]
CMD ["http://example.com"]
```
```bash
$ docker run myimage # curl -s http://example.com默认
$ docker run myimage http://other.com # curl -s http://other.com ✓
$ docker run myimage -v http://other.com # curl -s -v http://other.com ✓
```
---
## 场景一让镜像像命令一样使用
### 需求
创建一个查询公网 IP "命令"镜像
### 使用 CMD 的问题
```docker
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
CMD ["curl", "-s", "http://myip.ipip.net"]
```
```bash
$ docker run myip # ✓ 正常工作
当前 IP61.148.226.66
$ docker run myip -i # ✗ 错误!
exec: "-i": executable file not found
# -i 替换了整个 CMD被当作可执行文件
```
### 使用 ENTRYPOINT 解决
```docker
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["curl", "-s", "http://myip.ipip.net"]
```
```bash
$ docker run myip # ✓ 正常工作
当前 IP61.148.226.66
$ docker run myip -i # ✓ 添加 -i 参数
HTTP/1.1 200 OK
...
当前 IP61.148.226.66
```
### 交互图示
```
ENTRYPOINT ["curl", "-s", "http://myip.ipip.net"]
docker run myip -i
curl -s http://myip.ipip.net -i
└─────────────────────────────┘
ENTRYPOINT + docker run 参数
```
---
## 场景二启动前的准备工作
### 需求
在启动主服务前执行初始化脚本如数据库迁移权限设置
### 实现方式
```docker
FROM redis:7-alpine
COPY docker-entrypoint.sh /usr/local/bin/
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["redis-server"]
```
**docker-entrypoint.sh**
```bash
#!/bin/sh
set -e
# 准备工作
echo "Initializing..."
# 如果第一个参数是 redis-server以 redis 用户运行
if [ "$1" = 'redis-server' ]; then
chown -R redis:redis /data
exec gosu redis "$@"
fi
# 其他命令直接执行
exec "$@"
```
### 工作流程
```
docker run redis docker run redis bash
│ │
▼ ▼
docker-entrypoint.sh redis-server docker-entrypoint.sh bash
│ │
├─ 初始化 ├─ 初始化
├─ chown -R redis:redis /data │
└─ exec gosu redis redis-server └─ exec bash
(以 redis 用户运行) (以 root 用户运行)
```
### 关键点
1. **exec "$@"**用传入的参数替换当前进程确保信号正确传递
2. **条件判断**根据 CMD 不同执行不同逻辑
3. **用户切换**使用 `gosu` 切换用户 `su` 更适合容器
---
## 场景三带参数的应用
```docker
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "app.py"]
CMD ["--host", "0.0.0.0", "--port", "8080"]
```
```bash
# 使用默认参数
$ docker run myapp
# 执行: python app.py --host 0.0.0.0 --port 8080
# 覆盖参数
$ docker run myapp --host 0.0.0.0 --port 9000
# 执行: python app.py --host 0.0.0.0 --port 9000
# 完全不同的参数
$ docker run myapp --help
# 执行: python app.py --help
```
---
## 覆盖 ENTRYPOINT
使用 `--entrypoint` 参数覆盖
```bash
# 正常运行
$ docker run myimage
# 覆盖 ENTRYPOINT 进入 shell 调试
$ docker run --entrypoint /bin/sh myimage
# 覆盖 ENTRYPOINT 并传入参数
$ docker run --entrypoint /bin/cat myimage /etc/os-release
```
---
## ENTRYPOINT CMD 组合表
| ENTRYPOINT | CMD | 最终执行命令 |
|------------|-----|-------------|
| | | 容器无法启动 |
| | `["cmd", "p1"]` | `cmd p1` |
| `["ep", "p1"]` | | `ep p1` |
| `["ep", "p1"]` | `["cmd", "p2"]` | `ep p1 cmd p2` |
| `ep p1`shell | `["cmd", "p2"]` | `/bin/sh -c "ep p1"`CMD 被忽略 |
> **注意**shell 格式的 ENTRYPOINT 会忽略 CMD
---
## 最佳实践
### 1. 使用 exec 格式
```docker
# ✅ 推荐
ENTRYPOINT ["python", "app.py"]
# ❌ 避免 shell 格式
ENTRYPOINT python app.py
```
### 2. 提供有意义的默认参数
```docker
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]
```
### 3. 入口脚本使用 exec
```bash
#!/bin/sh
# 准备工作...
# 使用 exec 替换当前进程
exec "$@"
```
### 4. 处理信号
确保 ENTRYPOINT 脚本能正确传递信号
```bash
#!/bin/bash
trap 'kill -TERM $PID' TERM INT
# 启动应用
app "$@" &
PID=$!
# 等待应用退出
wait $PID
```
---
## 本章小结
| ENTRYPOINT | CMD | 适用场景 |
|------------|-----|---------|
| | | 镜像作为固定命令使用 |
| | | 简单的默认命令 |
| | | **推荐**固定命令 + 可配置参数 |
## 延伸阅读
- [CMD 容器启动命令](cmd.md)默认命令
- [最佳实践](../../15_appendix/best_practices.md)启动命令设计
- [后台运行](../../05_container/daemon.md)前台/后台概念

248
04_image/dockerfile/env.md Normal file
View File

@@ -0,0 +1,248 @@
# ENV 设置环境变量
## 基本语法
```docker
# 格式一:单个变量
ENV <key> <value>
# 格式二:多个变量(推荐)
ENV <key1>=<value1> <key2>=<value2> ...
```
---
## 基本用法
### 设置单个变量
```docker
ENV NODE_VERSION 20.10.0
ENV APP_ENV production
```
### 设置多个变量
```docker
ENV NODE_VERSION=20.10.0 \
APP_ENV=production \
APP_NAME="My Application"
```
> 💡 包含空格的值用双引号括起来
---
## 环境变量的作用
### 1. 后续指令中使用
```docker
ENV NODE_VERSION=20.10.0
# 在 RUN 中使用
RUN curl -fsSL https://nodejs.org/dist/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.xz \
| tar -xJ -C /usr/local --strip-components=1
# 在 WORKDIR 中使用
ENV APP_HOME=/app
WORKDIR $APP_HOME
# 在 COPY 中使用
COPY . $APP_HOME
```
### 2. 容器运行时使用
```docker
ENV DATABASE_URL=postgres://localhost/mydb
```
应用代码中可以读取
```python
import os
db_url = os.environ.get('DATABASE_URL')
```
```javascript
const dbUrl = process.env.DATABASE_URL;
```
---
## 支持环境变量的指令
以下指令可以使用 `$变量名` `${变量名}` 格式
| 指令 | 示例 |
|------|------|
| `RUN` | `RUN echo $VERSION` |
| `CMD` | `CMD ["sh", "-c", "echo $HOME"]` |
| `ENTRYPOINT` | 同上 |
| `COPY` | `COPY . $APP_HOME` |
| `ADD` | `ADD app.tar.gz $APP_HOME` |
| `WORKDIR` | `WORKDIR $APP_HOME` |
| `EXPOSE` | `EXPOSE $PORT` |
| `VOLUME` | `VOLUME $DATA_DIR` |
| `USER` | `USER $USERNAME` |
| `LABEL` | `LABEL version=$VERSION` |
| `FROM` | `FROM node:$NODE_VERSION` |
---
## 运行时覆盖
使用 `-e` `--env` 覆盖 Dockerfile 中定义的环境变量
```bash
# 覆盖单个变量
$ docker run -e APP_ENV=development myimage
# 覆盖多个变量
$ docker run -e APP_ENV=development -e DEBUG=true myimage
# 从环境变量文件读取
$ docker run --env-file .env myimage
```
### .env 文件格式
```bash
# .env
APP_ENV=development
DEBUG=true
DATABASE_URL=postgres://localhost/mydb
```
---
## ENV vs ARG
| 特性 | ENV | ARG |
|------|-----|-----|
| **生效时间** | 构建时 + 运行时 | 仅构建时 |
| **持久性** | 写入镜像运行时可用 | 构建后消失 |
| **覆盖方式** | `docker run -e` | `docker build --build-arg` |
| **适用场景** | 应用配置 | 构建参数如版本号 |
### 组合使用
```docker
# ARG 接收构建时参数
ARG NODE_VERSION=20
# ENV 保存到运行时
ENV NODE_VERSION=$NODE_VERSION
# 后续指令使用
RUN curl -fsSL https://nodejs.org/dist/v${NODE_VERSION}/...
```
```bash
# 构建时指定版本
$ docker build --build-arg NODE_VERSION=18 -t myapp .
```
---
## 最佳实践
### 1. 统一管理版本号
```docker
# ✅ 好:版本集中管理
ENV NGINX_VERSION=1.25.0 \
NODE_VERSION=20.10.0 \
PYTHON_VERSION=3.12.0
RUN apt-get install nginx=${NGINX_VERSION}
# ❌ 差:版本分散在各处
RUN apt-get install nginx=1.25.0
```
### 2. 不要存储敏感信息
```docker
# ❌ 错误:密码写入镜像
ENV DB_PASSWORD=secret123
# ✅ 正确:运行时传入
# docker run -e DB_PASSWORD=xxx myimage
```
### 3. 为应用提供合理默认值
```docker
ENV APP_ENV=production \
APP_PORT=8080 \
LOG_LEVEL=info
```
### 4. 使用有意义的变量名
```docker
# ✅ 好:清晰的命名
ENV REDIS_HOST=localhost \
REDIS_PORT=6379
# ❌ 差:模糊的命名
ENV HOST=localhost \
PORT=6379
```
---
## 常见问题
### Q: 环境变量在 CMD 中不展开
exec 格式不会自动展开环境变量
```docker
# ❌ 不会展开 $PORT
CMD ["python", "app.py", "--port", "$PORT"]
# ✅ 使用 shell 格式或显式调用 sh
CMD ["sh", "-c", "python app.py --port $PORT"]
```
### Q: 如何查看容器的环境变量
```bash
$ docker inspect mycontainer --format '{{json .Config.Env}}'
$ docker exec mycontainer env
```
### Q: 多行 ENV 还是多个 ENV
```docker
# ✅ 推荐:减少层数
ENV VAR1=value1 \
VAR2=value2 \
VAR3=value3
# ⚠️ 多个 ENV 会创建多层
ENV VAR1=value1
ENV VAR2=value2
ENV VAR3=value3
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **语法** | `ENV KEY=value` |
| **作用范围** | 构建时 + 运行时 |
| **覆盖方式** | `docker run -e KEY=value` |
| ** ARG** | ARG 仅构建时ENV 持久化到运行时 |
| **安全** | 不要存储敏感信息 |
## 延伸阅读
- [ARG 构建参数](arg.md)构建时变量
- [Compose 环境变量](../../compose/compose_file.md)Compose 中的环境变量
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 编写指南

View File

@@ -0,0 +1,219 @@
# EXPOSE 声明端口
## 基本语法
```docker
EXPOSE <端口> [<端口>/<协议>...]
```
`EXPOSE` 声明容器运行时提供服务的端口这是一个**文档性质的声明**告诉使用者容器会监听哪些端口
---
## 基本用法
```docker
# 声明单个端口
EXPOSE 80
# 声明多个端口
EXPOSE 80 443
# 声明 TCP 和 UDP 端口
EXPOSE 80/tcp
EXPOSE 53/udp
```
---
## EXPOSE 的作用
### 1. 文档说明
告诉镜像使用者容器将在哪些端口提供服务
```docker
# 使用者一看就知道这是 web 应用
EXPOSE 80 443
```
```bash
# 查看镜像暴露的端口
$ docker inspect nginx --format '{{.Config.ExposedPorts}}'
map[80/tcp:{}]
```
### 2. 配合 -P 使用
使用 `docker run -P` Docker 会自动映射 EXPOSE 的端口到宿主机随机端口
```docker
# Dockerfile
EXPOSE 80
```
```bash
$ docker run -P nginx
$ docker port $(docker ps -q)
80/tcp -> 0.0.0.0:32768
```
---
## EXPOSE vs -p
| 特性 | EXPOSE | -p |
|------|--------|-----|
| **位置** | Dockerfile | docker run 命令 |
| **作用** | 声明/文档 | 实际端口映射 |
| **是否必需** | | 外部访问时 |
| **映射发生时** | 不发生 | 运行时发生 |
```
┌────────────────────────────────────────────────────────────┐
│ EXPOSE 80 │
│ ↓ │
│ 仅声明意图 │
│ └───────────────────────────────────────┘ │
│ │
│ docker run -p │
│ ↓ │
│ ┌─────────────────────┐ │
│ │ 实际端口映射 │ │
│ │ 宿主机 ←→ 容器 │ │
│ └─────────────────────┘ │
└────────────────────────────────────────────────────────────┘
```
### 没有 EXPOSE 也能 -p
```docker
# 即使没有 EXPOSE也可以使用 -p
FROM nginx
# 没有 EXPOSE
```
```bash
# 仍然可以映射端口
$ docker run -p 8080:80 mynginx
```
---
## 常见误解
### 误解EXPOSE 会打开端口
```docker
# ❌ 错误理解:这不会让容器可从外部访问
EXPOSE 80
```
EXPOSE 不会
- 自动进行端口映射
- 让服务可从外部访问
- 在容器启动时开启端口监听
EXPOSE 只是元数据声明容器是否实际监听该端口取决于容器内的应用
### 正确理解
```docker
# Dockerfile
FROM nginx
EXPOSE 80 # 1. 声明:这个容器会在 80 端口提供服务
```
```bash
# 运行:需要 -p 才能从外部访问
$ docker run -p 8080:80 nginx # 2. 映射:宿主机 8080 → 容器 80
```
---
## 最佳实践
### 1. 总是声明应用使用的端口
```docker
# Web 服务
FROM nginx
EXPOSE 80 443
# 数据库
FROM postgres
EXPOSE 5432
# Redis
FROM redis
EXPOSE 6379
```
### 2. 使用明确的协议
```docker
# 默认是 TCP
EXPOSE 80
# 明确指定 UDP
EXPOSE 53/udp
# 同时支持 TCP 和 UDP
EXPOSE 53/tcp 53/udp
```
### 3. 与应用实际端口保持一致
```docker
# ✅ 好EXPOSE 与应用端口一致
ENV PORT=3000
EXPOSE 3000
CMD ["node", "server.js"]
# ❌ 差EXPOSE 与应用端口不一致(误导)
EXPOSE 80
CMD ["node", "server.js"] # 实际监听 3000
```
---
## 使用环境变量
```docker
ARG PORT=80
EXPOSE $PORT
```
---
## Compose
```yaml
services:
web:
build: .
ports:
- "8080:80" # 映射端口(类似 -p
expose:
- "80" # 仅声明(类似 EXPOSE
```
`expose` Compose 中仅用于容器间通信的文档说明不进行端口映射
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 声明容器提供服务的端口文档 |
| **不会** | 自动映射端口或开放外部访问 |
| **配合** | `docker run -P` 自动映射 |
| **外部访问** | 需要 `-p 宿主机端口:容器端口` |
| **语法** | `EXPOSE 80` `EXPOSE 80/tcp` |
## 延伸阅读
- [网络配置](../../network/README.md)Docker 网络详解
- [端口映射](../../network/port_bindingbindingbinding.md)-p 参数详解
- [Compose 端口](../../compose/compose_file.md)Compose 中的端口配置

View File

@@ -0,0 +1,206 @@
# HEALTHCHECK 健康检查
## 基本语法
```docker
HEALTHCHECK [选项] CMD <命令>
HEALTHCHECK NONE
```
`HEALTHCHECK` 指令告诉 Docker 如何判断容器状态是否正常这是保障服务高可用的重要机制
---
## 为什么需要 HEALTHCHECK
在没有 HEALTHCHECK 之前Docker 只能通过**进程退出码**来判断容器状态
**问题场景**
- Web 服务死锁无法响应请求但进程仍在运行
- 数据库正在启动中尚未准备好接受连接
- 应用陷入死循环CPU 爆满但进程存活
**引入 HEALTHCHECK **
Docker 定期执行指定的检查命令根据返回值判断容器是否"健康"
```
容器状态转换:
Starting ──成功──> Healthy ──失败N次──> Unhealthy
▲ │
└──────成功──────┘
```
---
## 基本用法
### Web 服务检查
```docker
FROM nginx
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -fs http://localhost/ || exit 1
```
### 命令返回值
- `0`: 成功 (healthy)
- `1`: 失败 (unhealthy)
- `2`: 保留值 (不使用)
### 常用选项
| 选项 | 说明 | 默认值 |
|------|------|--------|
| `--interval` | 两次检查的间隔 | 30s |
| `--timeout` | 检查命令的超时时间 | 30s |
| `--start-period` | 启动缓冲期期间失败不计入次数 | 0s |
| `--retries` | 连续失败多少次标记为 unhealthy | 3 |
---
## 屏蔽健康检查
如果基础镜像定义了 HEALTHCHECK但你不想使用它
```docker
FROM my-base-image
HEALTHCHECK NONE
```
---
## 常见检查脚本
### HTTP 服务
使用 `curl` `wget`
```docker
# 使用 curl
HEALTHCHECK CMD curl -f http://localhost/ || exit 1
# 使用 wget (Alpine 默认包含)
HEALTHCHECK CMD wget -q --spider http://localhost/ || exit 1
```
### 数据库
```docker
# MySQL
HEALTHCHECK CMD mysqladmin ping -h localhost || exit 1
# Redis
HEALTHCHECK CMD redis-cli ping || exit 1
```
### 自定义脚本
```docker
COPY healthcheck.sh /usr/local/bin/
HEALTHCHECK CMD ["healthcheck.sh"]
```
---
## Compose 中使用
可以在 `docker-compose.yml` 中覆盖或定义健康检查
```yaml
services:
web:
image: nginx
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
start_period: 40s
```
带健康检查的依赖启动
```yaml
services:
web:
depends_on:
db:
condition: service_healthy # 等待 db 变健康才启动 web
db:
image: mysql
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
```
---
## 查看健康状态
```bash
# 查看容器状态(包含健康信息)
$ docker ps
CONTAINER ID STATUS
abc123 Up 1 minute (healthy)
def456 Up 2 minutes (unhealthy)
# 查看详细健康日志
$ docker inspect --format '{{json .State.Health}}' mycontainer | jq
{
"Status": "healthy",
"FailingStreak": 0,
"Log": [
{
"Start": "...",
"End": "...",
"ExitCode": 0,
"Output": "..."
}
]
}
```
---
## 最佳实践
### 1. 避免副作用
健康检查会被频繁执行不要在检查脚本中进行写操作或消耗大量资源的操作
### 2. 使用轻量级工具
优先使用镜像中已有的工具 `wget`避免为了健康检查安装庞大的依赖 `curl`
### 3. 设置合理的 Start Period
应用启动可能需要时间 Java 应用设置 `--start-period` 可以防止在启动阶段因检查失败而误判
```docker
# 给应用 1 分钟启动时间
HEALTHCHECK --start-period=60s CMD curl -f http://localhost/ || exit 1
```
### 4. 只检查核心依赖
健康检查应主要关注**当前服务**是否可用而不是检查其下游依赖数据库等下游依赖的检查应由应用逻辑处理
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 检测容器应用是否真实可用 |
| **命令** | `HEALTHCHECK [选项] CMD command` |
| **状态** | starting, healthy, unhealthy |
| **Compose** | 支持 `condition: service_healthy` 依赖 |
| **注意** | 避免副作用节省资源 |
## 延伸阅读
- [CMD 容器启动命令](cmd.md)启动主进程
- [Compose 模板文件](../../compose/compose_file.md)Compose 中的健康检查
- [Docker 调试](../../15_appendix/debug.md)容器排障

View File

@@ -0,0 +1,154 @@
# LABEL 为镜像添加元数据
## 基本语法
```docker
LABEL <key>=<value> <key>=<value> ...
```
`LABEL` 指令以键值对的形式给镜像添加元数据这些数据不会影响镜像的功能但可以帮助用户理解镜像或被自动化工具使用
---
## 为什么需要 LABEL
1. **版本管理**记录版本号构建时间Git Commit ID
2. **联系信息**维护者邮箱文档地址支持渠道
3. **自动化工具** CI/CD 工具可以读取标签触发操作
4. **许可证信息**声明开源协议
---
## 基本用法
### 定义单个标签
```docker
LABEL version="1.0"
LABEL description="这是一个 Web 应用服务器"
```
### 定义多个标签推荐
```docker
LABEL maintainer="user@example.com" \
version="1.2.0" \
description="My App Description" \
org.opencontainers.image.authors="Yeasy"
```
> 💡 包含空格的值需要用引号括起来
---
## 常用标签规范 (OCI Annotations)
为了标准和互操作性推荐使用 [OCI Image Format Specification](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys) 定义的标准标签:
| 标签 Key | 说明 | 示例 |
|----------|------|------|
| `org.opencontainers.image.created` | 构建时间(RFC 3339) | `2024-01-01T00:00:00Z` |
| `org.opencontainers.image.authors` | 作者/维护者 | `support@example.com` |
| `org.opencontainers.image.url` | 项目主页 | `https://example.com` |
| `org.opencontainers.image.documentation`| 文档地址 | `https://example.com/docs` |
| `org.opencontainers.image.source` | 源码仓库 | `https://github.com/user/repo` |
| `org.opencontainers.image.version` | 版本号 | `1.0.0` |
| `org.opencontainers.image.licenses` | 许可证 | `MIT` |
| `org.opencontainers.image.title` | 镜像标题 | `My App` |
| `org.opencontainers.image.description` | 描述 | `Production ready web server` |
### 示例
```docker
LABEL org.opencontainers.image.authors="yeasy" \
org.opencontainers.image.documentation="https://yeasy.gitbooks.io" \
org.opencontainers.image.source="https://github.com/yeasy/docker_practice" \
org.opencontainers.image.licenses="MIT"
```
---
## MAINTAINER 指令已废弃
旧版本的 Dockerfile 中常看到 `MAINTAINER` 指令
```docker
# ❌ 已弃用
MAINTAINER user@example.com
```
现在推荐使用 `LABEL`
```docker
# ✅ 推荐
LABEL maintainer="user@example.com"
# 或
LABEL org.opencontainers.image.authors="user@example.com"
```
---
## 动态标签
配合 `ARG` 使用可以在构建时动态注入标签
```docker
ARG BUILD_DATE
ARG VCS_REF
LABEL org.opencontainers.image.created=$BUILD_DATE \
org.opencontainers.image.revision=$VCS_REF
```
构建命令
```bash
$ docker build \
--build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ') \
--build-arg VCS_REF=$(git rev-parse --short HEAD) \
.
```
---
## 查看标签
### docker inspect
查看镜像的标签信息
```bash
$ docker inspect nginx --format '{{json .Config.Labels}}' | jq
{
"maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
}
```
### 过滤器
可以使用标签过滤镜像
```bash
# 列出作者是 yeasy 的所有镜像
$ docker images --filter "label=org.opencontainers.image.authors=yeasy"
# 删除所有带有特定标签的镜像
$ docker rmi $(docker images -q --filter "label=stage=builder")
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 添加 key-value 元数据 |
| **语法** | `LABEL k=v k=v ...` |
| **规范** | 推荐使用 OCI 标准标签 |
| **弃用** | 不要再使用 `MAINTAINER` |
| **查看** | `docker inspect` |
## 延伸阅读
- [OCI 标签规范](https://github.com/opencontainers/image-spec/blob/main/annotations.md)
- [Dockerfile 最佳实践](../../15_appendix/best_practices.md)

View File

@@ -0,0 +1,151 @@
# ONBUILD 为他人做嫁衣裳
## 基本语法
```docker
ONBUILD <其它指令>
```
`ONBUILD` 是一个特殊的指令它后面跟的是其它指令 `RUN`, `COPY` 这些指令**在当前镜像构建时不会执行**只有当以当前镜像为基础镜像去构建下一级镜像时才会被执行
---
## 为什么需要 ONBUILD
`ONBUILD` 主要用于制作**语言栈基础镜像****框架基础镜像**
### 场景维护 Node.js 项目
假设你有多个 Node.js 项目它们的构建流程都一样
1. 创建目录
2. 复制 `package.json`
3. 执行 `npm install`
4. 复制源码
5. 启动应用
如果不使用 `ONBUILD`每个项目的 Dockerfile 都要重复这些步骤且通过 `COPY` 复制文件时基础镜像无法预知子项目的文件名
### 使用 ONBUILD 的解决方案
**基础镜像 (my-node-base)**
```docker
FROM node:20-alpine
WORKDIR /app
# 这些指令将在子镜像构建时执行
ONBUILD COPY package*.json ./
ONBUILD RUN npm install
ONBUILD COPY . .
CMD ["npm", "start"]
```
**子项目 Dockerfile**
```docker
FROM my-node-base
# 只需要一行!
# 构建时会自动执行 COPY 和 RUN
```
---
## 执行机制
```
基础镜像构建:
Dockerfile (含 ONBUILD) ──build──> 基础镜像 (记录了 ONBUILD 触发器)
(指令未执行)
子镜像构建:
FROM 基础镜像 ──build──> 读取基础镜像触发器 ──> 执行触发器指令 ──> 继续执行子 Dockerfile
```
---
## 常见使用场景
### 1. 自动处理依赖安装
```docker
# Python 基础镜像
ONBUILD COPY requirements.txt ./
ONBUILD RUN pip install -r requirements.txt
```
### 2. 自动编译代码
```docker
# Go 基础镜像
ONBUILD COPY . .
ONBUILD RUN go build -o app main.go
```
### 3. 处理静态资源
```docker
# Nginx 静态网站基础镜像
ONBUILD COPY dist/ /usr/share/nginx/html/
```
---
## 注意事项
### 1. 继承性限制
`ONBUILD` 指令**只会继承一次**
- 镜像 A ( ONBUILD)
- 镜像 B (FROM A) -> 触发 ONBUILD
- 镜像 C (FROM B) -> **不会**再次触发 ONBUILD
### 2. 构建上下文
子镜像构建时`ONBUILD COPY . .` 中的 `.` 指的是**子项目**的构建上下文而不是基础镜像的上下文
### 3. 不允许级联
`ONBUILD ONBUILD` 是非法的你不能写 `ONBUILD ONBUILD COPY ...`
### 4. 可能会导致构建失败
由于 `ONBUILD` 实际上是在子镜像中执行指令如果子项目的上下文不满足要求例如缺少 `package.json`会导致子镜像构建失败且错误信息可能比较隐晦
---
## 最佳实践
### 1. 命名规范
建议在镜像标签中添加 `-onbuild` 后缀明确告知使用者该镜像包含触发器
```
node:20-onbuild
python:3.12-onbuild
```
### 2. 避免执行耗时操作
尽量不要在 `ONBUILD` 中执行过于耗时或不确定的操作如更新系统软件这会让子镜像构建变得缓慢且不可控
### 3. 清理工作
如果 `ONBUILD` 指令产生了临时文件最好在同一个指令链中清理或者提供机制让子镜像清理
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 定义在子镜像构建时执行的指令 |
| **语法** | `ONBUILD INSTRUCTION` |
| **适用** | 基础架构镜像Node, Python, Go |
| **限制** | 只继承一次不可级联 |
| **规范** | 建议使用 `-onbuild` 标签后缀 |
## 延伸阅读
- [COPY 指令](copy.md)文件复制
- [Dockerfile 最佳实践](../../15_appendix/best_practices.md)基础镜像设计

181
04_image/dockerfile/run.md Normal file
View File

@@ -0,0 +1,181 @@
# RUN 执行命令
## 基本语法
```docker
RUN <command>
RUN ["executable", "param1", "param2"]
```
`RUN` 指令是 Dockerfile 中最常用的指令之一它在**当前镜像层**之上创建一个新层执行指定的命令并提交结果
---
## 两种格式对比
### 1. Shell 格式
```docker
RUN apt-get update
```
- **特点**默认通过 `/bin/sh -c` 执行
- **优势**可以使用环境变量管道重定向等 Shell 特性
- **示例**
```docker
RUN echo "Hello" > /test.txt
```
### 2. Exec 格式
```docker
RUN ["apt-get", "update"]
```
- **特点**直接调用可执行文件不经过 Shell
- **优势**避免 Shell 字符串解析问题适用于参数中包含特殊字符的情况
- **注意**无法使用 `$VAR` 环境变量替换除非显式调用 shell
---
## 常见最佳实践
### 1. 组合命令减少层数
每一个 `RUN` 指令都会新建一层镜像为了减少镜像体积和层数应使用 `&&` 连接命令
** 糟糕的写法**创建 3
```docker
RUN apt-get update
RUN apt-get install -y nginx
RUN rm -rf /var/lib/apt/lists/*
```
** 推荐写法**创建 1
```docker
RUN apt-get update && \
apt-get install -y nginx && \
rm -rf /var/lib/apt/lists/*
```
### 2. 清理缓存
在安装完软件后立即清除缓存可以显著减小镜像体积
- **Debian/Ubuntu**:
```docker
RUN apt-get update && apt-get install -y package-bar \
&& rm -rf /var/lib/apt/lists/*
```
- **Alpine**:
```docker
RUN apk add --no-cache package-bar
```
### 3. 使用 `set -e` `pipefail`
默认情况下管道命令 `cmd1 | cmd2` 只要 `cmd2` 成功整个 `RUN` 就视为成功
** 隐蔽的错误**
```docker
# 如果下载失败gzip 可能会报错,但如果不影响后续,构建可能继续
RUN wget http://error-url | gzip -d > file
```
** 推荐写法**
```docker
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
RUN wget http://url | gzip -d > file
```
---
## 常见问题
### Q: 为什么 `RUN cd /app` 不生效
```docker
RUN cd /app
RUN touch hello.txt
```
**结果**`hello.txt` 会出现在根目录 `/`而不是 `/app`
**原因**每个 `RUN` 都在一个新的 Shell/容器 环境中执行`cd` 只影响当前 `RUN` 的环境
**解决**使用 `WORKDIR` 指令
```docker
WORKDIR /app
RUN touch hello.txt
```
### Q: 环境变量不生效
```docker
RUN export MY_VAR=hello
RUN echo $MY_VAR
```
**结果**输出为空
**原因**同上环境变量只在当前 `RUN` 有效
**解决**使用 `ENV` 指令或在同一行 `RUN` 中导出
```docker
ENV MY_VAR=hello
RUN echo $MY_VAR
```
---
## 高级技巧
### 1. 使用 BuildKit 的挂载缓存
BuildKit 支持在 `RUN` 指令中使用 `--mount` 挂载缓存加速构建
```docker
# 缓存 apt 包
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
--mount=type=cache,target=/var/lib/apt,sharing=locked \
apt-get update && apt-get install -y gcc
```
```docker
# 缓存 Go 模块
RUN --mount=type=cache,target=/go/pkg/mod \
go build -o app
```
### 2. 挂载密钥
安全地使用 SSH 密钥或 Token而不将其记录在镜像中
```docker
RUN --mount=type=secret,id=mysecret \
cat /run/secrets/mysecret
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 在新层执行命令 |
| **原则** | 合并命令清理缓存 |
| **格式** | Shell (常用) vs Exec |
| **陷阱** | `cd` 不持久环境变量不持久 |
| **进阶** | 使用 Cache Mount 加速构建 |
## 延伸阅读
- [CMD 容器启动命令](cmd.md)容器启动时的命令
- [WORKDIR 指定工作目录](workdir.md)改变目录
- [Dockerfile 最佳实践](../../15_appendix/best_practices.md)

View File

@@ -0,0 +1,141 @@
# SHELL 指令
## 基本语法
```docker
SHELL ["executable", "parameters"]
```
`SHELL` 指令允许覆盖 Docker 默认的 shell
- **Linux 默认**`["/bin/sh", "-c"]`
- **Windows 默认**`["cmd", "/S", "/C"]`
该指令会影响后续的 `RUN`, `CMD`, `ENTRYPOINT` 指令当它们使用 shell 格式时
---
## 为什么要用 SHELL 指令
### 1. 使用 bash 特性
默认的 `/bin/sh`通常是 dash alpine ash功能有限如果你需要使用 bash 的特有功能如数组`{}` 扩展`pipefail` 可以切换 shell
```docker
FROM ubuntu:24.04
# 切换到 bash
SHELL ["/bin/bash", "-c"]
# 现在可以使用 bash 特性了
RUN echo {a..z}
```
### 2. 增强错误处理 (pipefail)
默认情况下管道命令 `cmd1 | cmd2` 只要 `cmd2` 成功整个指令就视为成功这可能掩盖构建错误
```docker
# ❌ 这里的 wget 失败了,但构建继续(因为 tar 成功了)
RUN wget -O - https://invalid-url | tar xz
```
使用 `SHELL` 启用 `pipefail`
```docker
# ✅ 启用 pipefail
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
# 如果 wget 失败,整个 RUN 就会失败
RUN wget -O - https://invalid-url | tar xz
```
### 3. Windows 环境
Windows 容器中经常需要在 `cmd` `powershell` 之间切换
```docker
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# 默认是 cmd
RUN echo Default shell is cmd
# 切换到 powershell
SHELL ["powershell", "-command"]
RUN Write-Host "Hello from PowerShell"
# 切回 cmd
SHELL ["cmd", "/S", "/C"]
```
---
## 作用范围
`SHELL` 指令可以出现多次每次只影响其后的指令
```docker
FROM ubuntu:24.04
# 使用默认 sh
RUN echo "Using sh"
SHELL ["/bin/bash", "-c"]
# 使用 bash
RUN echo "Using bash"
SHELL ["/bin/sh", "-c"]
# 回到 sh
RUN echo "Using sh again"
```
---
## 对其他指令的影响
`SHELL` 影响的是所有使用 **shell 格式** 的指令
| 指令格式 | 是否受 SHELL 影响 |
|---------|-------------------|
| `RUN command` | |
| `RUN ["exec", "param"]` | |
| `CMD command` | |
| `CMD ["exec", "param"]` | |
| `ENTRYPOINT command` | |
| `ENTRYPOINT ["exec", "param"]` | |
---
## 最佳实践
### 1. 推荐开启 pipefail
对于使用 bash 的镜像强烈建议开启 `pipefail`以确保构建过程中的错误能被及时捕获
```docker
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
```
### 2. 明确意图
如果由于脚本需求必须更改 shell最好在 Dockerfile 中显式声明而不是依赖默认行为
### 3. 尽量保持一致
避免在 Dockerfile 中频繁切换 SHELL这会使构建过程难以理解和调试尽量在头部定义一次即可
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 更改 RUN/CMD/ENTRYPOINT 的默认 shell |
| **Linux 默认** | `["/bin/sh", "-c"]` |
| **Windows 默认** | `["cmd", "/S", "/C"]` |
| **推荐用法** | `SHELL ["/bin/bash", "-o", "pipefail", "-c"]` |
| **影响范围** | 后续所有使用 shell 格式的指令 |
## 延伸阅读
- [RUN 指令](../../04_image/build.md)执行命令
- [Dockerfile 最佳实践](../../15_appendix/best_practices.md)错误处理与调试

273
04_image/dockerfile/user.md Normal file
View File

@@ -0,0 +1,273 @@
# USER 指定当前用户
## 基本语法
```docker
USER <用户名>[:<用户组>]
USER <UID>[:<GID>]
```
`USER` 指令切换后续指令RUNCMDENTRYPOINT的执行用户
---
## 为什么要使用 USER
> 笔者强调以非 root 用户运行容器是最重要的安全实践之一
```
root 用户运行的风险:
┌────────────────────────────────────────────────────────┐
│ 容器内 root ←─ 可能逃逸 ─→ 宿主机 root │
│ │ │ │
│ └── 漏洞利用 ───────────────→ 完全控制宿主机 │
└────────────────────────────────────────────────────────┘
非 root 用户运行:
┌────────────────────────────────────────────────────────┐
│ 容器内普通用户 ──逃逸后──→ 宿主机普通用户 │
│ │ │ │
│ └── 权限受限,危害降低 ─────→ 无法控制系统 │
└────────────────────────────────────────────────────────┘
```
---
## 基本用法
### 创建并切换用户
```docker
FROM node:20-alpine
# 1. 创建用户和组
RUN addgroup -g 1001 appgroup && \
adduser -u 1001 -G appgroup -D appuser
# 2. 设置目录权限
WORKDIR /app
COPY --chown=appuser:appgroup . .
# 3. 切换用户
USER appuser
# 4. 后续命令以 appuser 身份运行
CMD ["node", "server.js"]
```
### 使用 UID/GID
```docker
# 也可以使用数字
USER 1001:1001
```
---
## 用户必须已存在
`USER` 指令只能切换到**已存在**的用户
```docker
# ❌ 错误:用户不存在
USER nonexistent
# Error: unable to find user nonexistent
# ✅ 正确:先创建用户
RUN useradd -r -s /bin/false appuser
USER appuser
```
### 创建用户的方式
**Debian/Ubuntu**
```docker
RUN groupadd -r appgroup && \
useradd -r -g appgroup appuser
```
**Alpine**
```docker
RUN addgroup -g 1001 -S appgroup && \
adduser -u 1001 -S -G appgroup appuser
```
| 选项 | 说明 |
|------|------|
| `-r` (useradd) / `-S` (adduser) | 创建系统用户 |
| `-g` | 指定主组 |
| `-G` | 指定附加组 |
| `-u` | 指定 UID |
| `-s /bin/false` | 禁用登录 shell |
---
## 运行时切换用户
### 使用 gosu推荐
ENTRYPOINT 脚本中切换用户时不要使用 `su` `sudo`应使用 [gosu](https://github.com/tianon/gosu)
```docker
FROM debian:bookworm
# 创建用户
RUN groupadd -r redis && useradd -r -g redis redis
# 安装 gosu
RUN apt-get update && apt-get install -y gosu && rm -rf /var/lib/apt/lists/*
COPY docker-entrypoint.sh /usr/local/bin/
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["redis-server"]
```
**docker-entrypoint.sh**
```bash
#!/bin/bash
set -e
# 以 root 执行初始化
chown -R redis:redis /data
# 用 gosu 切换到 redis 用户运行服务
exec gosu redis "$@"
```
### 为什么不用 su/sudo
| 问题 | su/sudo | gosu |
|------|---------|------|
| TTY 要求 | 需要 | 不需要 |
| 信号传递 | 不正确 | 正确 |
| 子进程 | | exec 替换 |
| 容器中使用 | | |
---
## 运行时覆盖用户
使用 `-u` `--user` 参数
```bash
# 以指定用户运行
$ docker run -u 1001:1001 myimage
# 以 root 运行(调试时)
$ docker run -u root myimage
```
---
## 文件权限处理
切换用户后确保应用有权访问文件
```docker
FROM node:20-alpine
# 创建用户
RUN adduser -D -u 1001 appuser
WORKDIR /app
# 方式1使用 --chown
COPY --chown=appuser:appuser . .
# 方式2手动 chown减少层数
# COPY . .
# RUN chown -R appuser:appuser /app
USER appuser
CMD ["node", "server.js"]
```
---
## 最佳实践
### 1. 始终使用非 root 用户
```docker
# ✅ 推荐
RUN adduser -D appuser
USER appuser
CMD ["myapp"]
# ❌ 避免
CMD ["myapp"] # 以 root 运行
```
### 2. 使用固定 UID/GID
便于在宿主机和容器间共享文件
```docker
# 使用常见的非 root UID
RUN addgroup -g 1000 -S appgroup && \
adduser -u 1000 -S -G appgroup appuser
USER 1000:1000
```
### 3. 多阶段构建中的 USER
```docker
# 构建阶段可以用 root
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build
# 生产阶段用非 root
FROM node:20-alpine
RUN adduser -D appuser
WORKDIR /app
COPY --from=builder --chown=appuser:appuser /app/dist .
USER appuser
CMD ["node", "server.js"]
```
---
## 常见问题
### Q: 权限被拒绝
```bash
permission denied: '/app/data.log'
```
**解决**确保目录权限正确
```docker
RUN mkdir -p /app/data && chown appuser:appuser /app/data
```
### Q: 无法绑定低于 1024 的端口
root 用户无法绑定 80443 等端口
**解决**
1. 使用高端口 8080
2. 在运行时映射端口`docker run -p 80:8080`
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 切换后续指令的执行用户 |
| **语法** | `USER username` `USER UID:GID` |
| **前提** | 用户必须已存在 |
| **运行时覆盖** | `docker run -u` |
| **切换工具** | 使用 gosu不用 su/sudo |
## 延伸阅读
- [安全](../../security/README.md)容器安全实践
- [ENTRYPOINT](entrypoint.md)入口脚本中的用户切换
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 安全

View File

@@ -0,0 +1,247 @@
# VOLUME 定义匿名卷
## 基本语法
```docker
VOLUME ["/路径1", "/路径2"]
VOLUME /路径
```
`VOLUME` 指令创建挂载点并标记为外部挂载的卷
---
## 为什么使用 VOLUME
> **核心原则**容器存储层应该保持无状态任何运行时数据都应该存储在卷中
```
没有 VOLUME 使用 VOLUME
┌─────────────────────┐ ┌─────────────────────┐
│ 容器存储层 │ │ 容器存储层 │
│ ┌─────────────┐ │ │ (只读/无状态) │
│ │ 数据库文件 │←─问题 │ │
│ │ 日志文件 │ │ └──────────┬──────────┘
│ │ 上传文件 │ │ │
│ └─────────────┘ │ ┌──────────▼──────────┐
└─────────────────────┘ │ 数据卷 │
容器删除 = 数据丢失 │ ┌─────────────┐ │
│ │ 持久化数据 │←─安全
│ └─────────────┘ │
└─────────────────────┘
容器删除,数据保留
```
---
## 基本用法
### 定义单个卷
```docker
FROM mysql:8.0
VOLUME /var/lib/mysql
```
### 定义多个卷
```docker
FROM myapp
VOLUME ["/data", "/logs", "/config"]
```
---
## VOLUME 的行为
### 1. 自动创建匿名卷
如果运行时未指定挂载Docker 会自动创建匿名卷
```bash
$ docker run mysql:8.0
$ docker volume ls
DRIVER VOLUME NAME
local a1b2c3d4e5f6... # 自动创建的匿名卷
```
### 2. 可被命名卷覆盖
```bash
# 使用命名卷替代匿名卷
$ docker run -v mysql_data:/var/lib/mysql mysql:8.0
```
### 3. 可被 Bind Mount 覆盖
```bash
# 使用宿主机目录替代
$ docker run -v /my/data:/var/lib/mysql mysql:8.0
```
---
## VOLUME 在构建时的特殊行为
> **重要**VOLUME 之后对该目录的修改会被丢弃
```docker
FROM ubuntu
VOLUME /data
# ❌ 这个文件不会出现在镜像中!
RUN echo "hello" > /data/test.txt
```
**原因**VOLUME 指令之后Docker 将该目录视为外部挂载点不再记录对它的修改
### 正确做法
```docker
FROM ubuntu
# ✅ 先写入文件
RUN mkdir -p /data && echo "hello" > /data/test.txt
# 再声明 VOLUME
VOLUME /data
```
---
## 常见使用场景
### 数据库持久化
```docker
FROM postgres:15
VOLUME /var/lib/postgresql/data
```
### 日志目录
```docker
FROM nginx
VOLUME /var/log/nginx
```
### 上传文件目录
```docker
FROM myapp
VOLUME /app/uploads
```
---
## 查看 VOLUME 定义
```bash
# 查看镜像定义的 VOLUME
$ docker inspect mysql:8.0 --format '{{json .Config.Volumes}}' | jq
{
"/var/lib/mysql": {}
}
# 查看容器挂载的卷
$ docker inspect mycontainer --format '{{json .Mounts}}' | jq
```
---
## VOLUME vs docker run -v
| 特性 | Dockerfile VOLUME | docker run -v |
|------|-------------------|---------------|
| **定义时机** | 镜像构建时 | 容器运行时 |
| **默认行为** | 创建匿名卷 | 可指定命名卷或路径 |
| **灵活性** | 固定路径 | 可任意指定 |
| **适用场景** | 定义必须持久化的路径 | 灵活的数据管理 |
---
## Compose
```yaml
services:
db:
image: postgres:15
volumes:
# 命名卷(推荐)
- postgres_data:/var/lib/postgresql/data
# Bind Mount
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
volumes:
postgres_data: # 声明命名卷
```
---
## 安全注意事项
### 匿名卷可能导致数据丢失
```bash
# 使用 --rm 运行的容器,匿名卷会在容器删除时一起删除
$ docker run --rm mysql:8.0
# 容器停止后,数据丢失!
```
**解决**始终使用命名卷
```bash
$ docker run -v mysql_data:/var/lib/mysql mysql:8.0
```
---
## 最佳实践
### 1. 定义必须持久化的路径
```docker
# 数据库必须使用卷
FROM postgres:15
VOLUME /var/lib/postgresql/data
```
### 2. 不要在 VOLUME 后修改目录
```docker
# ❌ 避免
VOLUME /app/data
RUN cp init-data.json /app/data/
# ✅ 正确
RUN mkdir -p /app/data && cp init-data.json /app/data/
VOLUME /app/data
```
### 3. 文档中说明 VOLUME 用途
```docker
# 持久化用户上传的文件
VOLUME /app/uploads
# 持久化数据库数据
VOLUME /var/lib/mysql
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 创建挂载点标记为外部卷 |
| **语法** | `VOLUME /path` |
| **默认行为** | 自动创建匿名卷 |
| **覆盖方式** | `docker run -v name:/path` |
| **注意** | VOLUME 之后的修改会丢失 |
## 延伸阅读
- [数据卷](../../07_data_network/data/volume.md)卷的管理和使用
- [挂载主机目录](../../07_data_network/data/bind-mounts.md)Bind Mount
- [Compose 数据管理](../../compose/compose_file.md)Compose 中的卷配置

View File

@@ -0,0 +1,196 @@
# WORKDIR 指定工作目录
## 基本语法
```docker
WORKDIR <工作目录路径>
```
`WORKDIR` 指定后续指令的工作目录如果目录不存在Docker 会自动创建
---
## 基本用法
```docker
WORKDIR /app
RUN pwd # 输出 /app
RUN echo "hello" > world.txt # 创建 /app/world.txt
COPY . . # 复制到 /app/
```
---
## 为什么需要 WORKDIR
### 常见错误
```docker
# ❌ 错误cd 在下一个 RUN 中无效
RUN cd /app
RUN echo "hello" > world.txt # 文件在根目录!
```
### 原因分析
```
RUN cd /app
启动容器 → cd /app仅内存变化→ 提交镜像层 → 容器销毁
↓ 工作目录未改变!
RUN echo "hello" > world.txt
启动新容器(工作目录在 /)→ 创建 /world.txt
```
每个 RUN 都在新容器中执行**前一个 RUN 的内存状态包括工作目录不会保留**
### 正确做法
```docker
# ✅ 正确:使用 WORKDIR
WORKDIR /app
RUN echo "hello" > world.txt # 创建 /app/world.txt
```
---
## 相对路径
WORKDIR 支持相对路径基于上一个 WORKDIR
```docker
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd # 输出 /a/b/c
```
---
## 使用环境变量
```docker
ENV APP_HOME=/app
WORKDIR $APP_HOME
RUN pwd # 输出 /app
```
---
## 多阶段构建中的 WORKDIR
```docker
# 构建阶段
FROM node:20 AS builder
WORKDIR /build
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
# 生产阶段
FROM nginx:alpine
WORKDIR /usr/share/nginx/html
COPY --from=builder /build/dist .
```
---
## 最佳实践
### 1. 尽早设置 WORKDIR
```docker
FROM node:20
WORKDIR /app # 尽早设置
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]
```
### 2. 使用绝对路径
```docker
# ✅ 推荐:绝对路径,意图明确
WORKDIR /app
# ⚠️ 避免:相对路径可能造成混淆
WORKDIR app
```
### 3. 不要用 RUN cd
```docker
# ❌ 避免
RUN cd /app && echo "hello" > world.txt
# ✅ 推荐
WORKDIR /app
RUN echo "hello" > world.txt
```
### 4. 适时重置 WORKDIR
```docker
WORKDIR /app
# ... 应用相关操作 ...
WORKDIR /data
# ... 数据相关操作 ...
```
---
## 与其他指令的关系
| 指令 | WORKDIR 的影响 |
|------|---------------|
| `RUN` | WORKDIR 中执行命令 |
| `CMD` | WORKDIR 中启动 |
| `ENTRYPOINT` | WORKDIR 中启动 |
| `COPY` | 相对目标路径基于 WORKDIR |
| `ADD` | 相对目标路径基于 WORKDIR |
```docker
WORKDIR /app
RUN pwd # /app
COPY . . # 复制到 /app
CMD ["./start.sh"] # /app/start.sh
```
---
## 运行时覆盖
使用 `-w` 参数覆盖工作目录
```bash
$ docker run -w /tmp myimage pwd
/tmp
```
---
## 本章小结
| 要点 | 说明 |
|------|------|
| **作用** | 设置后续指令的工作目录 |
| **语法** | `WORKDIR /path` |
| **自动创建** | 目录不存在会自动创建 |
| **持久性** | 影响后续所有指令直到下次 WORKDIR |
| **不要用** | `RUN cd /path`无效 |
## 延伸阅读
- [COPY 复制文件](copy.md)文件复制
- [RUN 执行命令](../../04_image/build.md)执行构建命令
- [最佳实践](../../15_appendix/best_practices.md)Dockerfile 编写指南

258
04_image/list.md Normal file
View File

@@ -0,0 +1,258 @@
# 列出镜像
## 基本用法
查看本地已下载的镜像
```bash
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest 5f515359c7f8 5 days ago 183MB
nginx latest 05a60462f8ba 5 days ago 181MB
ubuntu 24.04 329ed837d508 3 days ago 78MB
ubuntu noble 329ed837d508 3 days ago 78MB
```
> 💡 `docker images` `docker image ls` 的简写两者等效
---
## 输出字段说明
| 字段 | 说明 |
|------|------|
| **REPOSITORY** | 仓库名 |
| **TAG** | 标签版本 |
| **IMAGE ID** | 镜像唯一标识 ID 12 |
| **CREATED** | 创建时间 |
| **SIZE** | 本地占用空间 |
### 同一镜像多个标签
注意上面的 `ubuntu:24.04` `ubuntu:noble` 拥有相同的 IMAGE ID它们是同一个镜像的不同标签只占用一份存储空间
---
## 理解镜像大小
### 本地大小 vs Hub 显示大小
| 位置 | 显示大小 | 说明 |
|------|---------|------|
| Docker Hub | 29MB | 压缩后的网络传输大小 |
| docker image ls | 78MB | 本地解压后的实际大小 |
### 实际磁盘占用
由于镜像是分层存储不同镜像可能共享相同的层
```
ubuntu:24.04 nginx:latest redis:latest
│ │ │
└───────┬───────┘ │
▼ │
共享基础层 ◄───────────────────┘
```
因此`docker image ls` 中各镜像大小之和 > 实际磁盘占用
### 查看实际空间占用
```bash
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 3 2.5GB 1.8GB (72%)
Containers 5 2 100MB 80MB (80%)
Local Volumes 8 2 500MB 400MB (80%)
Build Cache 0 0 0B 0B
```
---
## 过滤镜像
### 按仓库名过滤
```bash
# 列出所有 ubuntu 镜像
$ docker images ubuntu
REPOSITORY TAG IMAGE ID SIZE
ubuntu 24.04 329ed837d508 78MB
ubuntu noble 329ed837d508 78MB
ubuntu 22.04 a1b2c3d4e5f6 72MB
```
### 按仓库名和标签过滤
```bash
$ docker images ubuntu:24.04
REPOSITORY TAG IMAGE ID SIZE
ubuntu 24.04 329ed837d508 78MB
```
### 使用过滤器 --filter
| 过滤条件 | 说明 | 示例 |
|---------|------|------|
| `dangling=true` | 虚悬镜像 | `-f dangling=true` |
| `before=镜像` | 在某镜像之前创建 | `-f before=nginx:latest` |
| `since=镜像` | 在某镜像之后创建 | `-f since=nginx:latest` |
| `label=key=value` | LABEL 过滤 | `-f label=version=1.0` |
| `reference=pattern` | 按名称模式 | `-f reference='*:latest'` |
```bash
# 列出 nginx 之后创建的镜像
$ docker images -f since=nginx:latest
# 列出所有带 latest 标签的镜像
$ docker images -f reference='*:latest'
# 列出带特定 LABEL 的镜像
$ docker images -f label=maintainer=example@email.com
```
---
## 虚悬镜像Dangling Images
### 什么是虚悬镜像
仓库名和标签都显示为 `<none>` 的镜像
```bash
$ docker images
REPOSITORY TAG IMAGE ID SIZE
<none> <none> 00285df0df87 342MB
```
### 产生原因
1. **镜像重新构建**新镜像使用了旧镜像的标签旧镜像标签被移除
2. **docker pull 更新**拉取更新版本时旧版本失去标签
### 处理虚悬镜像
```bash
# 列出虚悬镜像
$ docker images -f dangling=true
# 删除虚悬镜像
$ docker image prune
```
---
## 中间层镜像
### 查看所有镜像包含中间层
```bash
$ docker images -a
```
会显示很多无标签镜像这些是构建过程中产生的中间层被其他镜像依赖
> 不要删除中间层镜像它们是其他镜像的依赖删除会导致上层镜像无法使用删除顶层镜像时会自动清理不再需要的中间层
---
## 格式化输出
### 只输出 ID
```bash
$ docker images -q
5f515359c7f8
05a60462f8ba
329ed837d508
```
常用于配合其他命令
```bash
# 删除所有镜像
$ docker rmi $(docker images -q)
# 删除所有 redis 镜像
$ docker rmi $(docker images -q redis)
```
### 显示完整 ID
```bash
$ docker images --no-trunc
```
### 显示摘要
```bash
$ docker images --digests
REPOSITORY TAG DIGEST IMAGE ID
nginx latest sha256:b4f0e0bdeb5... e43d811ce2f4
```
### 自定义格式
使用 Go 模板语法自定义输出
```bash
# 只显示 ID 和仓库名
$ docker images --format "{{.ID}}: {{.Repository}}"
5f515359c7f8: redis
05a60462f8ba: nginx
329ed837d508: ubuntu
# 表格形式(带标题)
$ docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"
REPOSITORY TAG SIZE
redis latest 183MB
nginx latest 181MB
ubuntu 24.04 78MB
```
### 可用模板字段
| 字段 | 说明 |
|------|------|
| `.ID` | 镜像 ID |
| `.Repository` | 仓库名 |
| `.Tag` | 标签 |
| `.Digest` | 摘要 |
| `.CreatedSince` | 创建后经过的时间 |
| `.CreatedAt` | 创建时间 |
| `.Size` | 大小 |
---
## 常用命令组合
```bash
# 列出所有镜像及其大小,按大小排序(需要系统 sort 命令)
$ docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | sort -h
# 查找大于 500MB 的镜像
$ docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | grep -E "^[0-9]+GB|^[5-9][0-9]{2}MB"
# 导出镜像列表
$ docker images --format "{{.Repository}}:{{.Tag}}" > images.txt
```
---
## 本章小结
| 操作 | 命令 |
|------|------|
| 列出所有镜像 | `docker images` |
| 按仓库名过滤 | `docker images nginx` |
| 列出虚悬镜像 | `docker images -f dangling=true` |
| 只输出 ID | `docker images -q` |
| 显示摘要 | `docker images --digests` |
| 自定义格式 | `docker images --format "..."` |
| 查看空间占用 | `docker system df` |
## 延伸阅读
- [获取镜像](pull.md) Registry 拉取镜像
- [删除镜像](rm.md)清理本地镜像
- [镜像](../02_basic_concept/image.md)理解镜像概念

View File

@@ -35,7 +35,8 @@ WORKDIR /go/src/github.com/go/helloworld/
COPY app.go .
RUN go get -d -v github.com/go-sql-driver/mysql \
RUN go mod init helloworld \
&& go get -d -v github.com/go-sql-driver/mysql \
&& CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . \
&& cp /go/src/github.com/go/helloworld/app /root
@@ -187,5 +188,5 @@ $ docker build --target builder -t username/imagename:tag .
上面例子中我们使用 `COPY --from=0 /go/src/github.com/go/helloworld/app .` 从上一阶段的镜像中复制文件我们也可以复制任意镜像中的文件
```docker
$ COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
```

View File

@@ -165,7 +165,7 @@ $ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
## 生产环境优化
本小节内容为了方便测试将配置文件直接放到了镜像中实际在使用时 **建议** 将配置文件作为 `config` `secret` 挂载到容器中请读者自行学习 `Swarm mode` `Kubernetes` 的相关内容
本小节内容为了方便测试将配置文件直接放到了镜像中实际在使用时 **建议** 将配置文件作为 `config` `secret` 挂载到容器中请读者自行学习 `Kubernetes` 的相关内容
由于篇幅所限本小节只是简单列出更多内容可以参考 https://github.com/khs1994-docker/laravel-demo 项目。

232
04_image/pull.md Normal file
View File

@@ -0,0 +1,232 @@
# 获取镜像
## docker pull 命令
从镜像仓库获取镜像的命令是 `docker pull`
```bash
docker pull [选项] [Registry地址/]仓库名[:标签]
```
### 镜像名称格式
```
docker.io / library / ubuntu : 24.04
────┬──── ───┬─── ──┬─── ──┬──
│ │ │ │
Registry地址 用户名 仓库名 标签
(可省略) (可省略)
```
| 组成部分 | 说明 | 默认值 |
|---------|------|--------|
| Registry 地址 | 镜像仓库地址 | `docker.io`Docker Hub |
| 用户名 | 镜像所属用户/组织 | `library`官方镜像 |
| 仓库名 | 镜像名称 | 必须指定 |
| 标签 | 版本标识 | `latest` |
### 示例
```bash
# 完整格式
$ docker pull docker.io/library/ubuntu:24.04
# 省略 Registry默认 Docker Hub
$ docker pull library/ubuntu:24.04
# 省略 library官方镜像
$ docker pull ubuntu:24.04
# 省略标签(默认 latest
$ docker pull ubuntu
# 拉取第三方镜像
$ docker pull bitnami/redis:latest
# 从其他 Registry 拉取
$ docker pull ghcr.io/username/myapp:v1.0
```
---
## 下载过程解析
```bash
$ docker pull ubuntu:24.04
24.04: Pulling from library/ubuntu
92dc2a97ff99: Pull complete
be13a9d27eb8: Pull complete
c8299583700a: Pull complete
Digest: sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26
Status: Downloaded newer image for ubuntu:24.04
docker.io/library/ubuntu:24.04
```
### 输出解读
| 输出内容 | 说明 |
|---------|------|
| `Pulling from library/ubuntu` | 正在从官方 ubuntu 仓库拉取 |
| `92dc2a97ff99: Pull complete` | 各层的下载状态显示层 ID 12 |
| `Digest: sha256:...` | 镜像内容的唯一摘要 |
| `docker.io/library/ubuntu:24.04` | 镜像的完整名称 |
### 分层下载
从输出可以看到镜像是**分层下载**
```
┌─────────────────────────────────────────────────────────────┐
│ ubuntu:24.04 镜像 │
├─────────────────────────────────────────────────────────────┤
│ 第3层 c8299583700a ───────► 已存在,跳过下载 │
├─────────────────────────────────────────────────────────────┤
│ 第2层 be13a9d27eb8 ───────► 下载中... 完成 │
├─────────────────────────────────────────────────────────────┤
│ 第1层 92dc2a97ff99 ───────► 下载中... 完成 │
└─────────────────────────────────────────────────────────────┘
```
如果本地已有相同的层Docker 会跳过下载节省带宽和时间
---
## 常用选项
| 选项 | 说明 | 示例 |
|------|------|------|
| `--all-tags, -a` | 拉取所有标签 | `docker pull -a ubuntu` |
| `--platform` | 指定平台架构 | `docker pull --platform linux/arm64 nginx` |
| `--quiet, -q` | 静默模式 | `docker pull -q nginx` |
### 指定平台
Apple Silicon Mac 上拉取 x86 镜像
```bash
$ docker pull --platform linux/amd64 nginx
```
---
## 拉取后运行
拉取镜像后可以基于它启动容器
```bash
# 拉取镜像
$ docker pull ubuntu:24.04
# 运行容器
$ docker run -it --rm ubuntu:24.04 bash
root@e7009c6ce357:/# cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
...
root@e7009c6ce357:/# exit
```
**参数说明**
| 参数 | 说明 |
|------|------|
| `-it` | 交互式终端模式 |
| `--rm` | 退出后自动删除容器 |
| `bash` | 启动命令 |
> 💡 `docker run` 在需要时会自动 `pull` 镜像因此通常不需要单独执行 `docker pull`
---
## 镜像加速
Docker Hub 下载可能较慢可以配置镜像加速器
```json
// /etc/docker/daemon.json (Linux)
// ~/.docker/daemon.json (Docker Desktop)
{
"registry-mirrors": [
"https://your-accelerator-url"
]
}
```
配置后重启 Docker
```bash
$ sudo systemctl restart docker # Linux
# 或在 Docker Desktop 中重启
```
详见 [镜像加速器](../install/mirror.md) 章节
---
## 验证镜像完整性
### 查看镜像摘要
```bash
$ docker images --digests ubuntu
REPOSITORY TAG DIGEST IMAGE ID
ubuntu 24.04 sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26 ca2b0f26964c
```
### 使用摘要拉取
用摘要拉取可确保获取完全相同的镜像
```bash
$ docker pull ubuntu@sha256:4bc3ae6596938cb0d9e5ac51a1152ec9dcac2a1c50829c74abd9c4361e321b26
```
> 笔者建议生产环境使用摘要而非标签因为标签可能被覆盖摘要则是不可变的
---
## 常见问题
### Q: 下载速度很慢
1. 配置镜像加速器
2. 检查网络连接
3. 尝试拉取更小的镜像版本 `alpine` 变体
### Q: 提示镜像不存在
```bash
Error: pull access denied, repository does not exist
```
可能原因
- 镜像名拼写错误
- 私有镜像未登录需要 `docker login`
- 镜像确实不存在
### Q: 磁盘空间不足
```bash
# 清理未使用的镜像
$ docker image prune
# 清理所有未使用资源
$ docker system prune
```
---
## 本章小结
| 操作 | 命令 |
|------|------|
| 拉取镜像 | `docker pull 镜像名:标签` |
| 拉取所有标签 | `docker pull -a 镜像名` |
| 指定平台 | `docker pull --platform linux/amd64 镜像名` |
| 用摘要拉取 | `docker pull 镜像名@sha256:...` |
## 延伸阅读
- [列出镜像](list.md)查看本地镜像
- [删除镜像](rm.md)清理本地镜像
- [镜像加速器](../install/mirror.md)加速镜像下载
- [Docker Hub](../repository/dockerhub.md)官方镜像仓库

255
04_image/rm.md Normal file
View File

@@ -0,0 +1,255 @@
# 删除本地镜像
## 基本用法
使用 `docker image rm` 删除本地镜像
```bash
$ docker image rm [选项] <镜像1> [<镜像2> ...]
```
> 💡 `docker rmi` `docker image rm` 的简写两者等效
---
## 镜像标识方式
删除镜像时可以使用多种方式指定镜像
| 方式 | 说明 | 示例 |
|------|------|------|
| ** ID** | ID 的前几位通常 3-4 | `docker rmi 501` |
| ** ID** | 完整的镜像 ID | `docker rmi 501ad78535f0...` |
| **镜像名:标签** | 仓库名和标签 | `docker rmi redis:alpine` |
| **镜像摘要** | 精确的内容摘要 | `docker rmi nginx@sha256:...` |
### 使用短 ID 删除
```bash
$ docker image ls
REPOSITORY TAG IMAGE ID SIZE
redis alpine 501ad78535f0 30MB
nginx latest e43d811ce2f4 142MB
# 只需输入足够区分的前几位
$ docker rmi 501
Untagged: redis:alpine
Deleted: sha256:501ad78535f0...
```
### 使用镜像名删除
```bash
$ docker rmi redis:alpine
Untagged: redis:alpine
Deleted: sha256:501ad78535f0...
```
### 使用摘要删除
摘要删除最精确适用于 CI/CD 场景
```bash
# 查看镜像摘要
$ docker images --digests
REPOSITORY TAG DIGEST IMAGE ID
nginx latest sha256:b4f0e0bdeb5... e43d811ce2f4
# 使用摘要删除
$ docker rmi nginx@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
```
---
## 理解输出信息
删除镜像时会看到两类信息**Untagged** **Deleted**
```bash
$ docker rmi redis:alpine
Untagged: redis:alpine
Untagged: redis@sha256:f1ed3708f538b537eb9c2a7dd50dc90a706f7debd7e1196c9264edeea521a86d
Deleted: sha256:501ad78535f015d88872e13fa87a828425117e3d28075d0c117932b05bf189b7
Deleted: sha256:96167737e29ca8e9d74982ef2a0dda76ed7b430da55e321c071f0dbff8c2899b
Deleted: sha256:32770d1dcf835f192cafd6b9263b7b597a1778a403a109e2cc2ee866f74adf23
```
### Untagged vs Deleted
| 操作 | 含义 |
|------|------|
| **Untagged** | 移除镜像的标签 |
| **Deleted** | 删除镜像的存储层 |
### 删除流程
```
docker rmi redis:alpine
┌───────────────────────────────────────────────────────────────┐
│ 1. Untag移除 redis:alpine 标签 │
│ ↓ │
│ 2. 检查是否还有其他标签指向这个镜像 │
│ ├── 有 → 只 Untag不删除 │
│ └── 无 → │
│ ↓ │
│ 3. 检查是否有容器依赖 │
│ ├── 有 → 报错,无法删除 │
│ └── 无 → │
│ ↓ │
│ 4. 从上到下逐层删除,检查每层是否被其他镜像使用 │
│ ├── 被使用 → 保留 │
│ └── 未使用 → Deleted │
└───────────────────────────────────────────────────────────────┘
```
---
## 批量删除
### 删除所有虚悬镜像
虚悬镜像dangling没有标签的镜像通常是旧版本被新版本覆盖后产生的
```bash
# 查看虚悬镜像
$ docker images -f dangling=true
# 删除虚悬镜像
$ docker image prune
# 不提示确认
$ docker image prune -f
```
### 删除所有未使用的镜像
```bash
# 删除所有没有被容器使用的镜像
$ docker image prune -a
# 保留最近 24 小时的
$ docker image prune -a --filter "until=24h"
```
### 按条件删除
```bash
# 删除所有 redis 镜像
$ docker rmi $(docker images -q redis)
# 删除 mongo:8.0 之前的所有镜像
$ docker rmi $(docker images -q -f before=mongo:8.0)
# 删除某个时间之前的镜像
$ docker image prune -a --filter "until=168h" # 7天前
```
---
## 删除失败的常见原因
### 原因一有容器依赖
```bash
$ docker rmi nginx
Error: conflict: unable to remove repository reference "nginx"
(must force) - container abc123 is using its referenced image
```
**解决方案**
```bash
# 方案1先删除依赖的容器
$ docker rm abc123
$ docker rmi nginx
# 方案2强制删除镜像容器仍可运行但无法再创建新容器
$ docker rmi -f nginx
```
### 原因二多个标签指向同一镜像
```bash
$ docker images
REPOSITORY TAG IMAGE ID
ubuntu 24.04 ca2b0f26964c
ubuntu latest ca2b0f26964c # 同一个镜像
$ docker rmi ubuntu:24.04
Untagged: ubuntu:24.04
# 只是移除标签,镜像仍存在(因为还有 ubuntu:latest 指向它)
```
### 原因三被其他镜像依赖中间层
```bash
$ docker rmi some_base_image
Error: image has dependent child images
```
中间层镜像被其他镜像依赖无法删除需要先删除依赖它的镜像
---
## 常用过滤条件
| 过滤条件 | 说明 | 示例 |
|---------|------|------|
| `dangling=true` | 虚悬镜像 | `-f dangling=true` |
| `before=镜像` | 在某镜像之前 | `-f before=mongo:3.2` |
| `since=镜像` | 在某镜像之后 | `-f since=mongo:3.2` |
| `label=key=value` | 按标签过滤 | `-f label=version=1.0` |
| `reference=pattern` | 按名称模式 | `-f reference='*:latest'` |
---
## 清理策略
### 开发环境
```bash
# 定期清理虚悬镜像
$ docker image prune -f
# 一键清理所有未使用资源
$ docker system prune -a
```
### CI/CD 环境
```bash
# 只保留最近使用的镜像
$ docker image prune -a --filter "until=72h" -f
```
### 查看空间占用
```bash
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 3 2.5GB 1.8GB (72%)
Containers 5 2 100MB 80MB (80%)
Local Volumes 8 2 500MB 400MB (80%)
Build Cache 0 0 0B 0B
```
---
## 本章小结
| 操作 | 命令 |
|------|------|
| 删除指定镜像 | `docker rmi 镜像名:标签` |
| 强制删除 | `docker rmi -f 镜像名` |
| 删除虚悬镜像 | `docker image prune` |
| 删除未使用镜像 | `docker image prune -a` |
| 批量删除 | `docker rmi $(docker images -q -f ...)` |
| 查看空间占用 | `docker system df` |
## 延伸阅读
- [列出镜像](list.md)查看和过滤镜像
- [删除容器](../05_container/rm.md)清理容器
- [数据卷](../07_data_network/data/volume.md)清理数据卷

264
05_container/attach_exec.md Normal file
View File

@@ -0,0 +1,264 @@
# 进入容器
## 为什么需要进入容器
使用 `-d` 参数启动容器后容器在后台运行以下场景需要进入容器内部操作
| 场景 | 示例 |
|------|------|
| **调试问题** | 查看日志检查配置排查错误 |
| **临时操作** | 执行数据库迁移清理缓存 |
| **检查状态** | 查看进程网络连接文件系统 |
| **开发测试** | 交互式测试命令验证环境 |
## 两种进入方式
Docker 提供两种进入容器的命令
| 命令 | 推荐程度 | 特点 |
|------|---------|------|
| `docker exec` | **推荐** | 启动新进程退出不影响容器 |
| `docker attach` | 谨慎使用 | 附加到主进程退出可能停止容器 |
---
## docker exec推荐
### 基本用法
```bash
# 进入容器并启动交互式 shell
$ docker exec -it 容器名 /bin/bash
# 或使用 sh适用于 Alpine 等精简镜像)
$ docker exec -it 容器名 /bin/sh
```
### 参数说明
| 参数 | 作用 |
|------|------|
| `-i` | 保持标准输入打开interactive |
| `-t` | 分配伪终端TTY |
| `-it` | 两者组合获得完整交互体验 |
| `-u` | 指定用户 `-u root` |
| `-w` | 指定工作目录 |
| `-e` | 设置环境变量 |
### 示例
```bash
# 启动一个后台容器
$ docker run -dit --name myubuntu ubuntu
69d137adef7a...
# 进入容器(交互式 shell
$ docker exec -it myubuntu bash
root@69d137adef7a:/# ls
bin boot dev etc home lib ...
root@69d137adef7a:/# exit
# 容器仍在运行!
$ docker ps
CONTAINER ID IMAGE STATUS NAMES
69d137adef7a ubuntu Up 2 minutes myubuntu
```
### 执行单条命令
不进入交互模式直接执行命令
```bash
# 查看容器内进程
$ docker exec myubuntu ps aux
# 查看配置文件
$ docker exec myubuntu cat /etc/nginx/nginx.conf
# 以 root 用户执行
$ docker exec -u root myubuntu apt update
```
### 只用 -i 不用 -t 的区别
```bash
# 只用 -i可以执行命令但没有提示符
$ docker exec -i myubuntu bash
ls # 输入命令
bin # 输出结果
boot
dev
...
# 用 -it有完整的终端体验
$ docker exec -it myubuntu bash
root@69d137adef7a:/# # 有提示符
```
> 💡 通常使用 `-it` 组合只有在脚本中需要通过管道传入命令时才只用 `-i`
---
## docker attach谨慎使用
### 基本用法
```bash
$ docker attach 容器名
```
### 工作原理
`attach` 会附加到容器的**主进程**PID 1的标准输入输出
```
┌─────────────────────────────────────────┐
│ 容器 │
│ ┌─────────────────────────────────┐ │
│ │ PID 1: /bin/bash (主进程) │◄───┼─── docker attach 附加到这里
│ │ └─ 你的输入直接发送到主进程 │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
```
### 示例
```bash
# 启动容器
$ docker run -dit --name myubuntu ubuntu
243c32535da7...
# 附加到容器
$ docker attach myubuntu
root@243c32535da7:/#
```
### 重要警告
** attach 会话中输入 `exit` 或按 `Ctrl+D` 会导致容器停止**
```bash
$ docker attach myubuntu
root@243c32535da7:/# exit # 这会停止容器!
$ docker ps
CONTAINER ID IMAGE STATUS NAMES
243c32535da7 ubuntu Exited (0) 2 seconds ago myubuntu
```
**原因**attach 附加到主进程退出主进程就等于退出容器
### 安全退出 attach
使用 `Ctrl+P` 然后 `Ctrl+Q` 可以从 attach 会话中**分离**而不停止容器
```bash
$ docker attach myubuntu
root@243c32535da7:/#
# 按 Ctrl+P 然后 Ctrl+Q
read escape sequence
$ docker ps # 容器仍在运行
CONTAINER ID IMAGE STATUS NAMES
243c32535da7 ubuntu Up 5 minutes myubuntu
```
---
## exec vs attach 对比
| 特性 | docker exec | docker attach |
|------|-------------|---------------|
| **工作方式** | 在容器内启动新进程 | 附加到主进程 |
| **退出影响** | 不影响容器 | 可能停止容器 |
| **多终端** | 可以开多个 | 共享同一个会话 |
| **适用场景** | 调试临时操作 | 查看主进程输出 |
| **推荐程度** | 推荐 | 特殊场景使用 |
```
docker exec docker attach
┌─────────────────────┐ ┌─────────────────────┐
│ 容器 │ │ 容器 │
│ ┌───────────────┐ │ │ ┌───────────────┐ │
│ │ PID 1: nginx │ │ │ │ PID 1: bash │◄─┼── 附加到主进程
│ ├───────────────┤ │ │ └───────────────┘ │
│ │ PID 50: bash │◄─┼── 新进程 │ │
│ └───────────────┘ │ │ │
└─────────────────────┘ └─────────────────────┘
退出 bash 不影响 nginx 退出 bash 容器停止
```
---
## 最佳实践
### 1. 首选 docker exec
```bash
# 进入容器调试
$ docker exec -it myapp bash
# 查看日志
$ docker exec myapp tail -f /var/log/app.log
# 执行数据库迁移
$ docker exec myapp python manage.py migrate
```
### 2. 生产环境避免进入容器
笔者建议生产环境应尽量避免进入容器直接操作而是通过
- 日志系统查看日志 `docker logs` 或集中式日志
- 监控系统查看状态
- 重新部署而非手动修改
### 3. shell 镜像的处理
某些精简镜像如基于 `scratch` `distroless`没有 shell
```bash
# 这会失败
$ docker exec -it myapp bash
OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found
# 解决方案使用调试容器Docker Desktop 或 Kubernetes debug
$ docker debug myapp
```
---
## 常见问题
### Q: exec 进入后看不到其他终端的操作
这是正常的exec 启动的是独立进程多个 exec 会话互不影响
### Q: 容器没有 bash
尝试使用 sh
```bash
$ docker exec -it myapp /bin/sh
```
### Q: 需要 root 权限
```bash
$ docker exec -u root -it myapp bash
```
---
## 本章小结
| 需求 | 推荐命令 |
|------|---------|
| 进入容器调试 | `docker exec -it 容器名 bash` |
| 执行单条命令 | `docker exec 容器名 命令` |
| 查看主进程输出 | `docker attach 容器名`慎用 |
## 延伸阅读
- [后台运行](daemon.md)理解容器主进程
- [查看容器](ls.md)列出和过滤容器
- [容器日志](logs.md)查看容器输出

218
05_container/daemon.md Normal file
View File

@@ -0,0 +1,218 @@
# 后台运行
在生产环境中我们通常需要容器持续运行不受终端关闭的影响本节将深入讲解如何让容器在后台运行以及理解容器生命周期的核心概念
## 核心概念前台 vs 后台
当你在终端运行一个程序时有两种模式
- **前台运行**程序占用当前终端输出直接显示关闭终端程序就停止
- **后台运行**程序在后台执行不占用终端终端关闭也不影响程序
Docker 容器默认是**前台运行**使用 `-d`detach参数可以让容器在后台运行
## 基本使用
### 前台运行默认
```bash
$ docker run ubuntu:24.04 /bin/sh -c "while true; do echo hello world; sleep 1; done"
hello world
hello world
hello world
hello world
```
容器会把输出的结果STDOUT打印到宿主机上面此时
- 终端被占用无法执行其他命令
- `Ctrl+C` 会终止容器
- 关闭终端窗口容器也会停止
### 后台运行使用 -d 参数
```bash
$ docker run -d ubuntu:24.04 /bin/sh -c "while true; do echo hello world; sleep 1; done"
77b2dc01fe0f3f1265df143181e7b9af5e05279a884f4776ee75350ea9d8017a
```
使用 `-d` 参数后
- 容器在后台运行
- 返回容器的完整 ID
- 终端立即释放可以继续执行其他命令
- 输出不会直接显示需要用 `docker logs` 查看
## 深入理解容器为什么会"立即退出"
> **这是初学者最常遇到的困惑** 理解这个问题你就理解了 Docker 的核心设计理念
很多人尝试这样启动容器
```bash
$ docker run -d ubuntu:24.04
```
然后用 `docker ps` 查看发现容器根本不在运行这是为什么
### 核心原理容器的生命周期与主进程绑定
```
┌─────────────────────────────────────────────────────────────────────┐
│ Docker 容器的生命周期 = 容器内 PID 1 进程的生命周期 │
│ │
│ 主进程启动 → 容器运行 │
│ 主进程退出 → 容器停止 │
└─────────────────────────────────────────────────────────────────────┘
```
当你运行 `docker run -d ubuntu:24.04`
1. 容器启动
2. 没有指定命令默认执行 `/bin/bash`
3. 但没有交互式终端没有 `-it` 参数bash 发现没有输入源
4. bash 立即退出
5. 主进程退出容器停止
**关键理解**
- `-d` 参数**不是**让容器"一直运行"
- `-d` 参数是让容器"在后台运行"能运行多久取决于主进程
### 常见的"立即退出"场景
| 场景 | 原因 | 解决方案 |
|------|------|---------|
| `docker run -d ubuntu` | 默认 bash 无输入立即退出 | 指定长期运行的命令 |
| `docker run -d nginx` 后改了配置 | 配置错误导致 nginx 启动失败 | 查看 `docker logs` |
| 自定义镜像容器启动即退 | Dockerfile CMD 执行完毕 | 确保 CMD 是前台进程 |
## 查看后台容器
### 查看运行中的容器
```bash
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
77b2dc01fe0f ubuntu:24.04 /bin/sh -c 'while tr 2 minutes ago Up 1 minute agitated_wright
```
### 查看容器输出日志
```bash
$ docker container logs 77b2dc01fe0f
hello world
hello world
hello world
...
```
**实时查看日志**类似 `tail -f`
```bash
$ docker container logs -f 77b2dc01fe0f
```
### 查看已停止的容器
```bash
$ docker container ls -a
```
加上 `-a` 参数可以看到所有容器包括已停止的这对于调试"容器启动即退出"的问题非常有用
## 最佳实践
### 1. 长期运行的服务使用 -d
```bash
# Web 服务器
$ docker run -d -p 80:80 nginx
# 数据库
$ docker run -d -p 3306:3306 mysql:8
# 缓存服务
$ docker run -d -p 6379:6379 redis
```
### 2. 调试时先用前台模式
当容器启动有问题时**去掉 `-d` 参数**可以直接看到输出和错误
```bash
# 有问题的容器,先前台运行看看发生了什么
$ docker run myimage:latest
```
### 3. 使用 --rm 自动清理
对于一次性任务使用 `--rm` 参数让容器退出后自动删除
```bash
$ docker run --rm ubuntu:24.04 echo "Hello, World!"
Hello, World!
# 容器执行完后自动删除
```
### 4. 配合日志查看
```bash
# 后台启动
$ docker run -d --name myapp myimage:latest
# 查看最近 100 行日志
$ docker logs --tail 100 myapp
# 实时跟踪日志
$ docker logs -f myapp
# 查看带时间戳的日志
$ docker logs -t myapp
```
## 常见问题排查
### Q: 容器启动后立即退出
1. **查看退出状态码**
```bash
$ docker ps -a --filter "name=mycontainer"
# 查看 STATUS 列,如 "Exited (1)" 表示异常退出
```
2. **查看容器日志**
```bash
$ docker logs mycontainer
```
3. **以交互模式调试**
```bash
$ docker run -it myimage:latest /bin/sh
# 进入容器手动执行命令,查找问题
```
### Q: 容器在后台运行但无法访问服务
1. **检查端口映射**
```bash
$ docker port mycontainer
```
2. **检查容器内服务状态**
```bash
$ docker exec mycontainer ps aux
```
### Q: 如何让已经在后台运行的容器回到前台
使用 `docker attach`
```bash
$ docker attach mycontainer
```
> **注意**`attach` 会连接到容器的主进程如果主进程不是交互式的你可能只能看到输出使用 `Ctrl+P` `Ctrl+Q` 可以安全退出而不停止容器
## 延伸阅读
- [进入容器](attach_exec.md)如何进入正在运行的容器执行命令
- [容器日志](../15_appendix/best_practices.md)生产环境的日志管理最佳实践
- [HEALTHCHECK 健康检查](../04_image/dockerfile/healthcheck.md)自动检测容器内服务是否正常
- [Docker Compose](../compose/README.md)管理多个后台容器的更好方式

View File

@@ -6,7 +6,7 @@
```bash
$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7691a814370e ubuntu:18.04 "/bin/bash" 36 hours ago Exited (0) 21 hours ago test
7691a814370e ubuntu:24.04 "/bin/bash" 36 hours ago Exited (0) 21 hours ago test
$ docker export 7691a814370e > ubuntu.tar
```

238
05_container/rm.md Normal file
View File

@@ -0,0 +1,238 @@
# 删除容器
## 基本用法
使用 `docker rm` 删除已停止的容器
```bash
$ docker rm 容器名或ID
```
> 💡 `docker rm` `docker container rm` 的简写两者等效
---
## 删除选项
| 选项 | 说明 | 示例 |
|------|------|------|
| 无参数 | 删除已停止的容器 | `docker rm mycontainer` |
| `-f` | 强制删除运行中的容器 | `docker rm -f mycontainer` |
| `-v` | 同时删除关联的匿名卷 | `docker rm -v mycontainer` |
### 删除已停止的容器
```bash
$ docker rm mycontainer
mycontainer
```
### 强制删除运行中的容器
```bash
# 不加 -f 会报错
$ docker rm running_container
Error: cannot remove running container
# 加 -f 强制删除
$ docker rm -f running_container
running_container
```
> 强制删除会向容器发送 SIGKILL 信号可能导致数据丢失建议先 `docker stop` 优雅停止
### 删除容器及其数据卷
```bash
# 删除容器时同时删除其匿名卷
$ docker rm -v mycontainer
```
> 注意只删除匿名卷命名卷不会被删除
---
## 批量删除
### 删除所有已停止的容器
```bash
# 方式一:使用 prune 命令(推荐)
$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
abc123...
def456...
Total reclaimed space: 150MB
# 方式二:不提示确认
$ docker container prune -f
```
### 删除所有容器包括运行中的
```bash
# 先停止所有容器,再删除
$ docker stop $(docker ps -q)
$ docker rm $(docker ps -aq)
# 或者直接强制删除
$ docker rm -f $(docker ps -aq)
```
### 按条件删除
```bash
# 删除所有已退出的容器
$ docker rm $(docker ps -aq -f status=exited)
# 删除名称包含 "test" 的容器
$ docker rm $(docker ps -aq -f name=test)
# 删除 24 小时前创建的容器
$ docker container prune --filter "until=24h"
```
---
## 常用过滤条件
`docker ps` 的过滤条件可以配合 `rm` 使用
| 过滤条件 | 说明 | 示例 |
|---------|------|------|
| `status=exited` | 已退出的容器 | `-f status=exited` |
| `status=created` | 已创建未启动 | `-f status=created` |
| `name=xxx` | 名称匹配 | `-f name=myapp` |
| `ancestor=xxx` | 基于某镜像创建 | `-f ancestor=nginx` |
| `before=xxx` | 在某容器之前创建 | `-f before=mycontainer` |
| `since=xxx` | 在某容器之后创建 | `-f since=mycontainer` |
### 示例
```bash
# 删除所有基于 nginx 镜像的容器
$ docker rm $(docker ps -aq -f ancestor=nginx)
# 删除所有创建后未启动的容器
$ docker rm $(docker ps -aq -f status=created)
```
---
## 容器与镜像的依赖关系
> 有容器依赖的镜像无法删除
```bash
# 尝试删除有容器依赖的镜像
$ docker image rm nginx
Error: image is being used by stopped container abc123
# 需要先删除依赖该镜像的容器
$ docker rm abc123
$ docker image rm nginx
```
---
## 清理策略建议
### 开发环境
```bash
# 定期清理已停止的容器
$ docker container prune -f
# 一键清理所有未使用资源
$ docker system prune -f
```
### 生产环境
```bash
# 使用 --rm 参数运行临时容器
$ docker run --rm ubuntu echo "Hello"
# 容器退出后自动删除
# 定期清理(设置保留时间)
$ docker container prune --filter "until=168h" # 保留 7 天内的
```
### 完整清理脚本
```bash
#!/bin/bash
# cleanup.sh - Docker 资源清理脚本
echo "清理已停止的容器..."
docker container prune -f
echo "清理未使用的镜像..."
docker image prune -f
echo "清理未使用的数据卷..."
docker volume prune -f
echo "清理未使用的网络..."
docker network prune -f
echo "清理完成!"
docker system df
```
---
## 常见问题
### Q: 容器无法删除
```bash
Error: container is running
```
解决先停止容器或使用 `-f` 强制删除
```bash
$ docker stop mycontainer
$ docker rm mycontainer
# 或
$ docker rm -f mycontainer
```
### Q: 删除后磁盘空间没释放
可能原因
1. 容器的数据卷未删除使用 `-v` 参数
2. 镜像未删除
3. 构建缓存未清理
解决
```bash
# 查看空间占用
$ docker system df
# 完整清理
$ docker system prune -a --volumes
```
---
## 本章小结
| 操作 | 命令 |
|------|------|
| 删除已停止容器 | `docker rm 容器名` |
| 强制删除运行中容器 | `docker rm -f 容器名` |
| 删除容器及匿名卷 | `docker rm -v 容器名` |
| 清理所有已停止容器 | `docker container prune` |
| 删除所有容器 | `docker rm -f $(docker ps -aq)` |
## 延伸阅读
- [终止容器](stop.md)优雅停止容器
- [删除镜像](../04_image/rm.md)清理镜像
- [数据卷](../07_data_network/data/volume.md)数据卷管理

229
05_container/run.md Normal file
View File

@@ -0,0 +1,229 @@
# 启动容器
## 启动方式概述
启动容器有两种方式
- **新建并启动**基于镜像创建新容器
- **重新启动**将已终止的容器重新运行
由于 Docker 容器非常轻量实际使用中常常是随时删除和新建容器而不是反复重启同一个容器
## 新建并启动
### 基本语法
```bash
docker run [选项] 镜像 [命令] [参数...]
```
### 最简单的例子
输出 "Hello World" 后容器自动终止
```bash
$ docker run ubuntu:24.04 /bin/echo 'Hello world'
Hello world
```
这与直接执行 `/bin/echo 'Hello world'` 几乎没有区别但实际上已经启动了一个完整的 Ubuntu 容器来执行这条命令
### 交互式容器
启动一个可以交互的 bash 终端
```bash
$ docker run -it ubuntu:24.04 /bin/bash
root@af8bae53bdd3:/#
```
**参数说明**
| 参数 | 作用 |
|------|------|
| `-i` | 保持标准输入stdin打开允许输入 |
| `-t` | 分配伪终端pseudo-TTY提供终端界面 |
| `-it` | 两者组合使用获得交互式终端 |
在交互模式下可以执行命令
```bash
root@af8bae53bdd3:/# pwd
/
root@af8bae53bdd3:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root@af8bae53bdd3:/# exit # 退出容器
```
## docker run 的完整流程
执行 `docker run` Docker 在后台完成以下操作
```
┌─────────────────────────────────────────────────────────────────────┐
│ docker run ubuntu:24.04 /bin/echo "Hello" │
└───────────────────────────────┬─────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ 1. 检查本地是否有 ubuntu:24.04 镜像 │
│ ├── 有 → 使用本地镜像 │
│ └── 无 → 从 Registry 下载 │
├─────────────────────────────────────────────────────────────────────┤
│ 2. 创建容器 │
│ • 基于镜像的只读层 │
│ • 添加一层可读写层(容器存储层) │
├─────────────────────────────────────────────────────────────────────┤
│ 3. 配置网络 │
│ • 创建虚拟网卡 │
│ • 分配 IP 地址 │
│ • 连接到 Docker 网桥 │
├─────────────────────────────────────────────────────────────────────┤
│ 4. 启动容器,执行指定命令 │
├─────────────────────────────────────────────────────────────────────┤
│ 5. 命令执行完毕,容器停止 │
└─────────────────────────────────────────────────────────────────────┘
```
## 常用启动选项
### 基础选项
| 选项 | 说明 | 示例 |
|------|------|------|
| `-d` | 后台运行detach | `docker run -d nginx` |
| `-it` | 交互式终端 | `docker run -it ubuntu bash` |
| `--name` | 指定容器名称 | `docker run --name myapp nginx` |
| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu echo hi` |
### 端口映射
```bash
# 将容器的 80 端口映射到宿主机的 8080 端口
$ docker run -d -p 8080:80 nginx
# 随机映射端口
$ docker run -d -P nginx
# 只绑定到 localhost
$ docker run -d -p 127.0.0.1:8080:80 nginx
```
### 数据卷挂载
```bash
# 挂载命名卷
$ docker run -v mydata:/data nginx
# 挂载宿主机目录
$ docker run -v /host/path:/container/path nginx
# 只读挂载
$ docker run -v /host/path:/container/path:ro nginx
```
### 环境变量
```bash
# 设置单个环境变量
$ docker run -e MYSQL_ROOT_PASSWORD=secret mysql
# 从文件加载环境变量
$ docker run --env-file .env myapp
```
### 资源限制
```bash
# 限制内存
$ docker run -m 512m nginx
# 限制 CPU
$ docker run --cpus=1.5 nginx
```
## 启动已终止容器
使用 `docker start` 重新启动已停止的容器
```bash
# 查看所有容器(包括已停止的)
$ docker ps -a
CONTAINER ID IMAGE STATUS NAMES
af8bae53bdd3 ubuntu Exited (0) 2 minutes ago myubuntu
# 重新启动
$ docker start myubuntu
# 启动并附加终端
$ docker start -ai myubuntu
```
## 容器内进程的特点
容器内只运行指定的应用程序及其必需资源
```bash
root@ba267838cc1b:/# ps
PID TTY TIME CMD
1 ? 00:00:00 bash
11 ? 00:00:00 ps
```
可见容器中仅运行了 `bash` 进程这种特点使得 Docker 对资源的利用率极高
> 💡 笔者提示容器内的 PID 1 进程很重要它是容器的主进程该进程退出则容器停止详见[后台运行](daemon.md)章节
## 常见问题
### Q: 容器启动后立即退出
**原因**主进程执行完毕或无法保持运行
```bash
# 这个容器会立即退出echo 执行完就结束了)
$ docker run ubuntu echo "hello"
# 解决:使用能持续运行的命令
$ docker run -d nginx # nginx 是持续运行的服务
```
详细解释见[后台运行](daemon.md)
### Q: 无法连接容器内的服务
**原因**未正确映射端口
```bash
# 错误:没有 -p 参数,外部无法访问
$ docker run -d nginx
# 正确:映射端口
$ docker run -d -p 80:80 nginx
```
### Q: 容器内修改的文件丢失
**原因**未使用数据卷数据保存在容器存储层
```bash
# 使用数据卷持久化
$ docker run -v mydata:/app/data myapp
```
详见[数据管理](../07_data_network/README.md)
## 本章小结
| 操作 | 命令 | 说明 |
|------|------|------|
| 新建并运行 | `docker run` | 最常用的启动方式 |
| 交互式启动 | `docker run -it` | 用于调试或临时操作 |
| 后台运行 | `docker run -d` | 用于服务类应用 |
| 启动已停止的容器 | `docker start` | 重用已有容器 |
## 延伸阅读
- [后台运行](daemon.md)理解 `-d` 参数和容器生命周期
- [进入容器](attach_exec.md)操作运行中的容器
- [网络配置](../network/README.md)理解端口映射的原理
- [数据管理](../07_data_network/README.md)数据持久化方案

256
05_container/stop.md Normal file
View File

@@ -0,0 +1,256 @@
# 终止容器
## 终止方式概述
终止容器有三种方式
| 方式 | 命令 | 说明 |
|------|------|------|
| **优雅停止** | `docker stop` | 先发 SIGTERM超时后发 SIGKILL |
| **强制停止** | `docker kill` | 直接发 SIGKILL |
| **自动终止** | - | 容器主进程退出时自动停止 |
---
## docker stop推荐
### 基本用法
```bash
$ docker stop 容器名或ID
```
### 工作原理
```
docker stop mycontainer
┌─────────────────────────────────────────────────────────────────┐
│ 1. 发送 SIGTERM 信号给容器主进程PID 1
│ ↓ │
│ 2. 等待容器优雅退出(默认 10 秒) │
│ ↓ │
│ 3. 如果超时仍未退出,发送 SIGKILL 强制终止 │
└─────────────────────────────────────────────────────────────────┘
```
### 自定义超时时间
```bash
# 等待 30 秒后强制终止
$ docker stop -t 30 mycontainer
# 立即发送 SIGKILL相当于 docker kill
$ docker stop -t 0 mycontainer
```
### 停止多个容器
```bash
# 停止多个指定容器
$ docker stop container1 container2 container3
# 停止所有运行中的容器
$ docker stop $(docker ps -q)
```
---
## docker kill
### 基本用法
```bash
$ docker kill 容器名或ID
```
### stop 的区别
| 命令 | 信号 | 使用场景 |
|------|------|---------|
| `docker stop` | SIGTERM SIGKILL | 正常停止让应用优雅退出 |
| `docker kill` | SIGKILL | 应用无响应强制终止 |
### 发送自定义信号
```bash
# 发送 SIGHUP让进程重新加载配置
$ docker kill -s HUP mycontainer
# 发送 SIGTERM
$ docker kill -s TERM mycontainer
```
---
## 容器自动终止
容器的生命周期与主进程绑定主进程退出时容器自动停止
```bash
# 主进程是交互式 bash
$ docker run -it ubuntu bash
root@abc123:/# exit # 退出 bash → 容器停止
# 主进程执行完毕
$ docker run ubuntu echo "Hello" # echo 执行完 → 容器停止
```
---
## 查看已停止的容器
```bash
$ docker ps -a
CONTAINER ID IMAGE COMMAND STATUS NAMES
ba267838cc1b ubuntu "/bin/bash" Exited (0) 2 minutes ago myubuntu
c5d3a5e8f7b2 nginx "nginx" Up 5 minutes mynginx
```
**STATUS 字段说明**
| 状态 | 说明 |
|------|------|
| `Up X minutes` | 运行中 |
| `Exited (0)` | 正常退出退出码 0 |
| `Exited (1)` | 异常退出非零退出码 |
| `Exited (137)` | SIGKILL 终止128 + 9 |
| `Exited (143)` | SIGTERM 终止128 + 15 |
---
## 重新启动容器
### 启动已停止的容器
```bash
$ docker start 容器名或ID
# 启动并附加终端
$ docker start -ai 容器名
```
### 重启运行中的容器
```bash
# 先停止再启动
$ docker restart 容器名
# 自定义停止超时
$ docker restart -t 30 容器名
```
---
## 生命周期状态图
```
docker create
┌──────────┐
┌────────│ Created │────────┐
│ └──────────┘ │
│ │ │
│ │ docker start│
│ ▼ │
│ ┌──────────┐ │
│ ┌────│ Running │────┐ │
│ │ └──────────┘ │ │
│ │ │ │ │
│ │ docker │ docker │ │
│ │ pause │ stop │ │
│ ▼ │ │ │
│ ┌──────┐ │ │ │
│ │Paused│ │ │ │
│ └──────┘ │ │ │
│ │ │ │ │
│ │ docker │ │ │
│ │ unpause │ │ │
│ ▼ ▼ │ │
│ └──────►┌──────────┐◄┘ │
│ │ Stopped │ │
│ └──────────┘ │
│ │ │
│ │ docker rm │
│ ▼ │
│ ┌──────────┐ │
└──────────►│ Deleted │◄────┘
└──────────┘
```
---
## 批量操作
### 停止所有容器
```bash
$ docker stop $(docker ps -q)
```
### 删除所有已停止的容器
```bash
$ docker container prune
```
### 停止并删除所有容器
```bash
$ docker stop $(docker ps -q) && docker container prune -f
```
---
## 常见问题
### Q: 容器停止很慢
原因应用没有正确处理 SIGTERM 信号需要等待超时后强制终止
解决方案
1. 在应用中正确处理 SIGTERM
2. 使用 `docker stop -t 0` 立即终止
3. 检查 Dockerfile 中的 `STOPSIGNAL` 配置
### Q: 如何让容器优雅退出
确保容器主进程正确处理信号
```dockerfile
# Dockerfile 示例
FROM node:22
...
# 使用 exec 形式确保信号能传递给 node 进程
CMD ["node", "server.js"]
```
### Q: 容器无法停止
```bash
# 强制终止
$ docker kill 容器名
# 如果仍无法停止,检查系统资源
$ docker inspect 容器名
```
---
## 本章小结
| 操作 | 命令 | 说明 |
|------|------|------|
| 优雅停止 | `docker stop` | SIGTERM超时后 SIGKILL |
| 强制停止 | `docker kill` | 直接 SIGKILL |
| 重新启动 | `docker start` | 启动已停止的容器 |
| 重启 | `docker restart` | 停止后立即启动 |
| 停止全部 | `docker stop $(docker ps -q)` | 停止所有运行中容器 |
## 延伸阅读
- [启动容器](run.md)容器启动详解
- [删除容器](rm.md)清理容器
- [容器日志](logs.md)排查停止原因

View File

@@ -1,8 +1,8 @@
version: '3'
services:
registry:
image: registry
image: registry:2
ports:
- "443:5000"
volumes:

126
06_repository/dockerhub.md Normal file
View File

@@ -0,0 +1,126 @@
# Docker Hub
## 什么是 Docker Hub
[Docker Hub](https://hub.docker.com/) 是 Docker 官方维护的公共镜像仓库,也是全球最大的容器镜像库。
它提供了
- **官方镜像** Docker 官方和软件厂商 Nginx, MySQL, Node.js维护的高质量镜像
- **个人/组织仓库**用户可以上传自己的镜像
- **自动构建** GitHub/Bitbucket 集成需付费
- **Webhooks**镜像更新时触发回调
---
## 核心功能
### 1. 搜索镜像
除了网页搜索也可以使用命令行
```bash
$ docker search centos
NAME DESCRIPTION STARS OFFICIAL
centos The official build of CentOS. 7000+ [OK]
```
> **技巧**始终优先使用 `OFFICIAL` 标记为 `[OK]` 的镜像安全性更有保障
### 2. 拉取镜像
```bash
$ docker pull nginx:alpine
```
### 3. 推送镜像
需要先登录
```bash
$ docker login
# 输入用户名和密码
```
打标签并推送
```bash
# 1. 标记镜像
$ docker tag myapp:v1 username/myapp:v1
# 2. 推送
$ docker push username/myapp:v1
```
---
## 限制与配额重要
### 镜像拉取限制 (Rate Limiting)
2020 11 月起Docker Hub 对匿名和免费用户实施了拉取速率限制
| 用户类型 | 限制 |
|---------|------|
| **匿名用户** (未登录) | 6 小时 100 次请求 |
| **免费账户** (已登录) | 6 小时 200 次请求 |
| **Pro/Team 账户** | 无限制 |
> **提示**如果在 CI/CD 环境中遇到 `toomanyrequests` 错误建议
> 1. CI 中配置 `docker login`
> 2. 使用国内镜像加速器
> 3. 搭建私有仓库代理
---
## 安全最佳实践
### 1. 启用 2FA (双因素认证)
Account Settings -> Security 中启用 2FA保护账号安全启用后CLI 登录需要使用 **Access Token** 而非密码
### 2. 使用 Access Token
不要在脚本或 CI/CD 中直接使用登录密码
1. Docker Hub -> Account Settings -> Security -> Access Tokens 创建 Token
2. 使用 Token 作为密码登录
```bash
$ docker login -u username -p dckr_pat_xxxxxxx
```
### 3. 关注镜像漏洞
Docker Hub 会对官方镜像和付费用户的镜像进行安全扫描在镜像标签页可以看到漏洞扫描结果
---
## Webhooks
当镜像被推送时可以自动触发 HTTP 回调例如通知 CI 系统部署
**配置方法**
仓库页面 -> Webhooks -> Create Webhook
---
## 自动构建 (Automated Builds)
> 目前仅限付费用户 (Pro/Team) 使用
链接 GitHub/Bitbucket 仓库后当代码有提交或打标签时Docker Hub 会自动运行构建这保证了镜像总是与代码同步且由可信的官方环境构建
---
## 本章小结
| 功能 | 说明 |
|------|------|
| **官方镜像** | 优先使用的基础镜像 |
| **拉取限制** | 匿名 100/6h登录 200/6h |
| **安全** | 推荐开启 2FA 并使用 Access Token |
| **自动化** | 支持 Webhooks 和自动构建 |
## 延伸阅读
- [私有仓库](registry.md)搭建自己的 Registry
- [镜像加速器](../install/mirror.md)加速下载

View File

@@ -1,4 +1,4 @@
# Nexus3.x 的私有仓库
# Nexus 3
使用 Docker 官方的 Registry 创建的仓库面临一些维护问题比如某些镜像删除以后空间默认是不会回收的需要一些命令去回收空间然后重启 Registry在企业中把内部的一些工具包放入 `Nexus` 中是比较常见的做法最新版本 `Nexus3.x` 全面支持 Docker 的私有镜像所以使用 [`Nexus3.x`](https://www.sonatype.com/product/repository-oss-download) 一个软件来管理 `Docker` , `Maven` , `Yum` , `PyPI` 等是一个明智的选择。
@@ -22,7 +22,6 @@ $ docker logs nexus3 -f
Started Sonatype Nexus OSS 3.30.0-01
-------------------------------------------------
```
如果你看到以上内容说明 `Nexus` 已经启动成功你可以使用浏览器打开 `http://YourIP:8081` 访问 `Nexus`
@@ -53,7 +52,7 @@ $ docker exec nexus3 cat /nexus-data/admin.password
菜单 `Security->Realms` Docker Bearer Token Realm 移到右边的框中保存
添加用户规则菜单 `Security->Roles`->`Create role` `Privlleges` 选项搜索 docker 把相应的规则移动到右边的框中然后保存
添加用户规则菜单 `Security->Roles`->`Create role` `Privlleges` 选项搜索 docker 把相应的规则移动到右边的框中然后保存
添加用户菜单 `Security->Users`->`Create local user` `Roles` 选项中选中刚才创建的规则移动到右边的窗口保存
@@ -114,7 +113,7 @@ server {
## Docker 主机访问镜像仓库
如果不启用 SSL 加密可以通过 [前面章节](./registry.md) 的方法添加非 https 仓库地址到 Docker 的配置文件中然后重启 Docker
如果不启用 SSL 加密可以通过 [前面章节](registry.md) 的方法添加非 https 仓库地址到 Docker 的配置文件中然后重启 Docker
使用 SSL 加密以后程序需要访问就不能采用修改配置的方式了具体方法如下

View File

@@ -97,7 +97,7 @@ REPOSITORY TAG IMAGE ID CREAT
这是因为 Docker 默认不允许非 `HTTPS` 方式推送镜像我们可以通过 Docker 的配置选项来取消这个限制或者查看下一节配置能够通过 `HTTPS` 访问的私有仓库
### Ubuntu 16.04+, Debian 8+, centos 7
### Linux (systemd)
对于使用 `systemd` 的系统请在 `/etc/docker/daemon.json` 中写入如下内容如果文件不存在请新建该文件

Some files were not shown because too many files have changed in this diff Show More