Compare commits
42 Commits
dd6b022429
...
v1.5.0
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
fdb879dcf2 | ||
|
|
b4b0d4160a | ||
|
|
99e0eb14ce | ||
|
|
b92ccc8309 | ||
|
|
cbfe75fe9b | ||
|
|
fec2e506d9 | ||
|
|
c58f61dbed | ||
|
|
8a0230e493 | ||
|
|
16e0d3502d | ||
|
|
02898e346c | ||
|
|
7d8d7e63f4 | ||
|
|
cc6510d0b2 | ||
|
|
306a205314 | ||
|
|
5eed72afa0 | ||
|
|
6bba22679b | ||
|
|
24eb615f54 | ||
|
|
43e12058eb | ||
|
|
8bdb8406f9 | ||
|
|
e08a34bcdf | ||
|
|
6e6d31d1d6 | ||
|
|
5c3841dc98 | ||
|
|
61a71f3c25 | ||
|
|
39207f57cf | ||
|
|
3a9d4bff61 | ||
|
|
4bc29c0300 | ||
|
|
65bc905920 | ||
|
|
1b7d941fcd | ||
|
|
e0ff3d315a | ||
|
|
09de77b543 | ||
|
|
344fc8bd3c | ||
|
|
7ec5772432 | ||
|
|
355dd3b051 | ||
|
|
ca011164c2 | ||
|
|
0f2956a646 | ||
|
|
da7991660e | ||
|
|
391c6364a0 | ||
|
|
99433b2e45 | ||
|
|
32c6a91aa9 | ||
|
|
bea7b8d3f4 | ||
|
|
1be1db5a43 | ||
|
|
7052cea8a3 | ||
|
|
584087ad46 |
15
.drone.yml
@@ -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
|
||||
6
.github/workflows/check-link.yml
vendored
@@ -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 \
|
||||
|
||||
12
.github/workflows/ci.yaml
vendored
@@ -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
@@ -11,3 +11,7 @@ node_modules/
|
||||
package-lock.json
|
||||
|
||||
docker-compose.override.yml
|
||||
|
||||
# Editor configs
|
||||
.obsidian/
|
||||
.vscode/
|
||||
|
||||
@@ -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
|
||||
@@ -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 © yeasy",
|
||||
"minHeaderCount": "2",
|
||||
"minHeaderDeep": "2"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -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;
|
||||
|
||||
}
|
||||
}
|
||||
@@ -1,5 +0,0 @@
|
||||
sut:
|
||||
build: .
|
||||
volumes:
|
||||
- ../:/srv/gitbook-src
|
||||
command: build
|
||||
@@ -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
|
||||
@@ -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
@@ -0,0 +1,23 @@
|
||||
# 简介
|
||||
|
||||
本章将带领你进入 **Docker** 的世界。
|
||||
|
||||
## 本章内容
|
||||
|
||||
* [什么是 Docker](what.md)
|
||||
* 介绍 Docker 的起源、发展历程以及其背后的核心技术(Cgroups, Namespaces, UnionFS)。
|
||||
* 了解 Docker 是如何改变软件交付方式的。
|
||||
|
||||
* [为什么要用 Docker](why.md)
|
||||
* 对比传统虚拟机技术,阐述 Docker 在启动速度、资源利用率、交付效率等方面的巨大优势。
|
||||
* 探讨 Docker 在 DevOps、微服务架构中的关键作用。
|
||||
|
||||
## 学习目标
|
||||
|
||||
通过本章的学习,你将能够:
|
||||
|
||||
1. 理解 Docker 的核心概念与架构。
|
||||
2. 明白 Docker 解决了现代软件开发与运维中的哪些痛点。
|
||||
3. 建立起对容器技术的初步认知,为后续的实战操作打下基础。
|
||||
|
||||
好吧,让我们带着问题开始这神奇之旅。
|
||||
65
01_introduction/quickstart.md
Normal 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
@@ -0,0 +1,124 @@
|
||||
# 什么是 Docker
|
||||
|
||||
## 一句话理解 Docker
|
||||
|
||||
> **Docker 是一种轻量级的虚拟化技术,它让应用程序及其依赖环境可以被打包成一个标准化的单元,在任何地方都能一致地运行。**
|
||||
|
||||
如果用一个生活中的类比:**Docker 之于软件,就像集装箱之于货物**。
|
||||
|
||||
在集装箱发明之前,货物的运输是一件麻烦的事情——不同的货物需要不同的包装、不同的装卸方式,换一种运输工具就要重新装卸。集装箱的出现改变了这一切:无论里面装的是什么,集装箱的外形是标准的,可以用同样的方式装卸、堆放和运输。
|
||||
|
||||
Docker 做的事情类似:无论你的应用是用 Python、Java、Node.js 还是其他语言写的,无论它需要什么样的依赖库和环境,一旦被打包成 Docker 镜像,就可以用同样的方式在任何支持 Docker 的机器上运行。
|
||||
|
||||
## Docker 的核心价值
|
||||
|
||||
笔者认为,Docker 解决的是软件开发中最古老的问题之一:**"在我机器上明明能跑啊!"**
|
||||
|
||||
```
|
||||
开发环境 生产环境
|
||||
┌─────────────────┐ ┌─────────────────┐
|
||||
│ Python 3.14 │ ≠ │ Python 3.11 │
|
||||
│ Ubuntu 24.04 │ │ Ubuntu 22.04 │
|
||||
│ 特定版本的库 │ │ 不同版本的库 │
|
||||
└─────────────────┘ └─────────────────┘
|
||||
↓ ↓
|
||||
运行正常 运行失败!
|
||||
```
|
||||
|
||||
有了 Docker:
|
||||
|
||||
```
|
||||
开发环境 生产环境
|
||||
┌─────────────────┐ ┌─────────────────┐
|
||||
│ Docker 镜像 │ = │ 同一个镜像 │
|
||||
│ (包含所有依赖) │ │ (完全一致) │
|
||||
└─────────────────┘ └─────────────────┘
|
||||
↓ ↓
|
||||
运行正常 运行正常!
|
||||
```
|
||||
|
||||
## Docker vs 虚拟机
|
||||
|
||||
很多人第一次接触 Docker 时会问:**"这不就是虚拟机吗?"**
|
||||
|
||||
答案是:**不是,而且差别很大。**
|
||||
|
||||
### 传统虚拟机
|
||||
|
||||
传统虚拟机技术是虚拟出一套完整的硬件,在其上运行一个完整的操作系统,再在该系统上运行应用:
|
||||
|
||||

|
||||
|
||||
### Docker 容器
|
||||
|
||||
而 Docker 容器内的应用直接运行于宿主的内核,容器内没有自己的内核,也没有进行硬件虚拟:
|
||||
|
||||

|
||||
|
||||
### 关键区别
|
||||
|
||||
| 特性 | 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**(2013):Docker 最初基于 Linux Containers
|
||||
- **libcontainer**(2014,v0.7):Docker 自研的容器运行时
|
||||
- **runC**(2015,v1.11):捐献给 OCI 的标准容器运行时
|
||||
- **containerd**:高级容器运行时,管理容器生命周期
|
||||
|
||||

|
||||
|
||||
> `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 的成功推动了整个容器生态的发展,催生了 Kubernetes、Podman 等众多相关项目。笔者认为,Docker 最大的贡献不仅是技术本身,更是它**让容器技术从系统管理员的工具变成了每个开发者都能使用的标准工具**。
|
||||
|
||||
## 本章小结
|
||||
|
||||
- Docker 是一种轻量级虚拟化技术,核心价值是**环境一致性**
|
||||
- 与虚拟机相比,Docker 更轻量、更快速、资源利用率更高
|
||||
- Docker 基于 Linux 内核的 Namespace、Cgroups 和 Union FS 技术
|
||||
- Docker 推动了容器技术的标准化(OCI)和生态发展
|
||||
|
||||
接下来,让我们了解[为什么要使用 Docker](why.md)。
|
||||
208
01_introduction/why.md
Normal 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 可以在几乎任何平台上运行:
|
||||
- ✅ 本地开发机(macOS、Windows、Linux)
|
||||
- ✅ 公有云(AWS、Azure、GCP、阿里云、腾讯云)
|
||||
- ✅ 私有云和自建数据中心
|
||||
- ✅ 边缘设备和 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)。
|
||||
9
02_basic_concept/README.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# 基本概念
|
||||
|
||||
**Docker** 包括三个基本概念:
|
||||
|
||||
* **镜像**(`Image`):Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。
|
||||
* **容器**(`Container`):镜像(`Image`)和容器(`Container`)的关系,就像是面向对象程序设计中的 `类` 和 `实例` 一样,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
|
||||
* **仓库**(`Repository`):镜像构建完成后,可以很容易的在当前宿主机上运行,但是,如果需要在其它服务器上使用这个镜像,我们就需要一个集中的存储、分发镜像的服务,Docker Registry 就是这样的服务。
|
||||
|
||||
理解了这三个概念,就理解了 **Docker** 的整个生命周期。
|
||||
246
02_basic_concept/container.md
Normal 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
@@ -0,0 +1,222 @@
|
||||
# Docker 镜像
|
||||
|
||||
## 一句话理解镜像
|
||||
|
||||
> **Docker 镜像是一个只读的模板,包含了运行应用所需的一切:代码、运行时、库、环境变量和配置文件。**
|
||||
|
||||
如果用一个类比:**镜像就像是一张光盘或 ISO 文件**。你可以用同一张光盘在不同电脑上安装系统,而光盘本身不会被修改。同样,一个镜像可以创建多个容器,而镜像本身保持不变。
|
||||
|
||||
## 镜像与操作系统的关系
|
||||
|
||||
我们都知道,操作系统分为**内核**和**用户空间**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 用户空间 │
|
||||
│ ┌─────────────────────────────────────────────────────┐ │
|
||||
│ │ 应用程序、工具、库、配置文件... │ │
|
||||
│ │ (这部分被打包成 Docker 镜像) │ │
|
||||
│ └─────────────────────────────────────────────────────┘ │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Linux 内核 │
|
||||
│ (容器共享宿主机的内核) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
对于 Linux 而言,内核启动后会挂载 `root` 文件系统来提供用户空间支持。**Docker 镜像**本质上就是一个 `root` 文件系统。
|
||||
|
||||
例如,官方镜像 `ubuntu:24.04` 包含了一套完整的 Ubuntu 24.04 最小系统的 root 文件系统——但**不包含 Linux 内核**(因为容器共享宿主机的内核)。
|
||||
|
||||
## 镜像包含什么?
|
||||
|
||||
Docker 镜像是一个特殊的文件系统,包含:
|
||||
|
||||
| 内容类型 | 示例 |
|
||||
|---------|------|
|
||||
| **程序文件** | 应用二进制文件、Python/Node 解释器 |
|
||||
| **库文件** | libc、OpenSSL、各种依赖库 |
|
||||
| **配置文件** | nginx.conf、my.cnf 等 |
|
||||
| **环境变量** | PATH、LANG 等预设值 |
|
||||
| **元数据** | 启动命令、暴露端口、数据卷定义 |
|
||||
|
||||
**关键特性**:
|
||||
- ✅ 镜像是**只读**的
|
||||
- ✅ 镜像**不包含**动态数据
|
||||
- ✅ 镜像构建后**内容不会改变**
|
||||
|
||||
## 分层存储:镜像的核心设计
|
||||
|
||||
### 为什么需要分层?
|
||||
|
||||
笔者认为,分层存储是 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. 镜像 ID(Content-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):深入理解分层存储的技术原理
|
||||
250
02_basic_concept/repository.md
Normal 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 Hub、ghcr.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)** | 支持多种制品类型(Docker、Maven、npm 等) |
|
||||
| **云厂商服务** | 阿里云 ACR、腾讯云 TCR、AWS 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):配置镜像加速
|
||||
|
Before Width: | Height: | Size: 118 KiB After Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 660 KiB After Width: | Height: | Size: 660 KiB |
|
Before Width: | Height: | Size: 291 KiB After Width: | Height: | Size: 291 KiB |
|
Before Width: | Height: | Size: 101 KiB After Width: | Height: | Size: 101 KiB |
|
Before Width: | Height: | Size: 88 KiB After Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
@@ -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 9、Rocky Linux 8/9、AlmaLinux 8/9,并且要求内核版本不低于 3.10。
|
||||
|
||||
对于 Rocky Linux、AlmaLinux 或 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 额外设置
|
||||
@@ -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
|
||||
|
||||
@@ -8,8 +8,9 @@
|
||||
|
||||
Docker 支持以下版本的 [Fedora](https://getfedora.org/) 操作系统:
|
||||
|
||||
* 33
|
||||
* 34
|
||||
* 41
|
||||
* 42
|
||||
* 43
|
||||
|
||||
### 卸载旧版本
|
||||
|
||||
@@ -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` 文件夹即可(其间需要输入用户密码)。
|
||||
|
||||

|
||||

|
||||
|
||||
## 运行
|
||||
|
||||
从应用中找到 Docker 图标并点击运行。
|
||||
|
||||

|
||||

|
||||
|
||||
运行之后,会在右上角菜单栏看到多了一个鲸鱼图标,这个图标表明了 Docker 的运行状态。
|
||||
|
||||

|
||||

|
||||
|
||||
每次点击鲸鱼图标会弹出操作菜单。
|
||||
|
||||

|
||||

|
||||
|
||||
之后,你可以在终端通过命令检查安装后的 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 安装成功了。
|
||||
|
||||

|
||||

|
||||
|
||||
要停止 Nginx 服务器并删除执行下面的命令:
|
||||
|
||||
@@ -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 仓库,我们会在此更新各个镜像地址的状态。
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# 离线部署Docker
|
||||
# Linux 离线安装
|
||||
|
||||
[TOC]
|
||||
\[TOC]
|
||||
|
||||
生产环境中一般都是没有公网资源的,本文介绍如何在生产服务器上离线部署`Docker`
|
||||
|
||||
|
||||
|
||||
括号内的字母表示该操作需要在哪些服务器上执行
|
||||
|
||||
<img src="_images/image-20200412202617411.png" alt="Docker-offile-install-top" style="zoom:30%;" />
|
||||

|
||||
|
||||
## Centos7 离线安装Docker
|
||||
## CentOS/Rocky/AlmaLinux 离线安装Docker
|
||||
|
||||
> 注意:以下命令以 CentOS 7 为例。对于 CentOS Stream 9、Rocky 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
|
||||
```
|
||||
|
||||
|
||||
@@ -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`。
|
||||
@@ -6,23 +6,31 @@
|
||||
|
||||
### 系统要求
|
||||
|
||||
Docker 支持以下版本的 [Ubuntu](https://ubuntu.com/server) 操作系统:
|
||||
Docker 支持诸多版本的 [Ubuntu](https://ubuntu.com/server) 操作系统。但是较旧的版本上将不会有 Docker 新版本的持续更新,以截至 2026 年初的几个 Ubuntu LTS(Long 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 发行版中,LTS(Long-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 支持 amd64、arm64、armhf、ppc64el、s390x 等 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
|
||||
```
|
||||
|
||||
## 使用脚本自动安装
|
||||
@@ -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** 开始运行。
|
||||
|
||||

|
||||

|
||||
|
||||
Docker 启动之后会在 Windows 任务栏出现鲸鱼图标。
|
||||
|
||||

|
||||

|
||||
|
||||
等待片刻,当鲸鱼图标静止时,说明 Docker 启动成功,之后你可以打开 PowerShell 使用 Docker。
|
||||
|
||||
|
Before Width: | Height: | Size: 77 KiB After Width: | Height: | Size: 77 KiB |
|
Before Width: | Height: | Size: 101 KiB After Width: | Height: | Size: 101 KiB |
@@ -4,6 +4,18 @@
|
||||
|
||||
Dockerfile 是一个文本文件,其内包含了一条条的 **指令(Instruction)**,每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。
|
||||
|
||||
## 使用 docker init 快速创建(推荐)
|
||||
|
||||
Docker 提供了 `docker init` 命令,可以根据项目类型自动生成 Dockerfile、.dockerignore 和 compose.yaml 文件:
|
||||
|
||||
```bash
|
||||
$ docker init
|
||||
```
|
||||
|
||||
该命令会交互式地询问项目类型(如 Go、Node.js、Python、Rust 等),并生成符合最佳实践的配置文件。对于新项目,这是推荐的起步方式。
|
||||
|
||||
## 手动创建 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 \
|
||||
@@ -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 欢迎页面。
|
||||
|
||||

|
||||

|
||||
|
||||
现在,假设我们非常不喜欢这个欢迎页面,我们希望改成欢迎 Docker 的文字,我们可以使用 `docker exec` 命令进入容器,修改其内容。
|
||||
|
||||
@@ -37,7 +37,7 @@ exit
|
||||
|
||||
现在我们再刷新浏览器的话,会发现内容被改变了。
|
||||
|
||||

|
||||

|
||||
|
||||
我们修改了容器的文件,也就是改动了容器的存储层。我们可以通过 `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
|
||||
0
image/demo/multistage-builds/build.sh → 04_image/demo/multistage-builds/build.sh
Executable file → Normal file
221
04_image/dockerfile/add.md
Normal 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
@@ -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
@@ -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
@@ -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 编写指南
|
||||
306
04_image/dockerfile/entrypoint.md
Normal 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 # ✓ 正常工作
|
||||
当前 IP:61.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 # ✓ 正常工作
|
||||
当前 IP:61.148.226.66
|
||||
|
||||
$ docker run myip -i # ✓ 添加 -i 参数
|
||||
HTTP/1.1 200 OK
|
||||
...
|
||||
当前 IP:61.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
@@ -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 编写指南
|
||||
219
04_image/dockerfile/expose.md
Normal 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 中的端口配置
|
||||
206
04_image/dockerfile/healthcheck.md
Normal 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):容器排障
|
||||
154
04_image/dockerfile/label.md
Normal 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)
|
||||
151
04_image/dockerfile/onbuild.md
Normal 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
@@ -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)
|
||||
141
04_image/dockerfile/shell.md
Normal 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
@@ -0,0 +1,273 @@
|
||||
# USER 指定当前用户
|
||||
|
||||
## 基本语法
|
||||
|
||||
```docker
|
||||
USER <用户名>[:<用户组>]
|
||||
USER <UID>[:<GID>]
|
||||
```
|
||||
|
||||
`USER` 指令切换后续指令(RUN、CMD、ENTRYPOINT)的执行用户。
|
||||
|
||||
---
|
||||
|
||||
## 为什么要使用 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 用户无法绑定 80、443 等端口。
|
||||
|
||||
**解决**:
|
||||
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 安全
|
||||
247
04_image/dockerfile/volume.md
Normal 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 中的卷配置
|
||||
196
04_image/dockerfile/workdir.md
Normal 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
@@ -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):理解镜像概念
|
||||
@@ -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
|
||||
```
|
||||
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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):管理多个后台容器的更好方式
|
||||
@@ -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
@@ -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
@@ -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
@@ -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):排查停止原因
|
||||
@@ -1,8 +1,8 @@
|
||||
version: '3'
|
||||
|
||||
|
||||
services:
|
||||
registry:
|
||||
image: registry
|
||||
image: registry:2
|
||||
ports:
|
||||
- "443:5000"
|
||||
volumes:
|
||||
126
06_repository/dockerhub.md
Normal 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):加速下载
|
||||
@@ -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 加密以后程序需要访问就不能采用修改配置的方式了。具体方法如下:
|
||||
|
||||
@@ -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` 中写入如下内容(如果文件不存在请新建该文件)
|
||||
|
||||