mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-24 18:55:31 +00:00
Move more dockerfile content to chapter 7
This commit is contained in:
@@ -66,53 +66,15 @@ RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
|
||||
|
||||
* *exec* 格式:`RUN ["可执行文件", "参数1", "参数2"]`,这更像是函数调用中的格式。
|
||||
|
||||
既然 `RUN` 就像 Shell 脚本一样可以执行命令,那么我们是否就可以像 Shell 脚本一样把每个命令对应一个 RUN 呢?比如这样:
|
||||
Dockerfile 中每一个指令都会建立一层,`RUN` 也不例外。每一个 `RUN` 的行为,就和刚才我们手工建立镜像的过程一样:新建立一层,在其上执行这些命令,执行结束后,`commit` 这一层的修改,构成新的镜像。
|
||||
|
||||
```docker
|
||||
FROM debian:bookworm
|
||||
> **注意**
|
||||
>
|
||||
> 每一个 `RUN` 指令都会产生一个新的镜像层。为了减少镜像体积和层数,我们通常会将多个命令合并到一个 `RUN` 指令中执行。
|
||||
>
|
||||
> 更多关于 `RUN` 指令的详细用法、最佳实践(如清理缓存、使用 pipefail 等)及 `Union FS` 的层数限制等内容,请参阅 **[第七章 Dockerfile 指令详解](../07_dockerfile/README.md)** 中的 **[RUN 指令](../07_dockerfile/7.1_run.md)** 小节。
|
||||
|
||||
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-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
|
||||
RUN make -C /usr/src/redis install
|
||||
```
|
||||
|
||||
之前说过,Dockerfile 中每一个指令都会建立一层,`RUN` 也不例外。每一个 `RUN` 的行为,就和刚才我们手工建立镜像的过程一样:新建立一层,在其上执行这些命令,执行结束后,`commit` 这一层的修改,构成新的镜像。
|
||||
|
||||
而上面的这种写法,创建了 7 层镜像。这是完全没有意义的,而且很多运行时不需要的东西,都被装进了镜像里,比如编译环境、更新的软件包等等。结果就是产生非常臃肿、非常多层的镜像,不仅仅增加了构建部署的时间,也很容易出错。
|
||||
这是很多初学 Docker 的人常犯的一个错误。
|
||||
|
||||
*Union FS 是有最大层数限制的,比如 AUFS,曾经是最大不得超过 42 层,现在是不得超过 127 层。*
|
||||
|
||||
上面的 `Dockerfile` 正确的写法应该是这样:
|
||||
|
||||
```docker
|
||||
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-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 \
|
||||
&& make -C /usr/src/redis install \
|
||||
&& rm -rf /var/lib/apt/lists/* \
|
||||
&& rm redis.tar.gz \
|
||||
&& rm -r /usr/src/redis \
|
||||
&& apt-get purge -y --auto-remove $buildDeps
|
||||
```
|
||||
|
||||
首先,之前所有的命令只有一个目的,就是编译、安装 redis 可执行文件。因此没有必要建立很多层,这只是一层的事情。因此,这里没有使用很多个 `RUN` 一一对应不同的命令,而是仅仅使用一个 `RUN` 指令,并使用 `&&` 将各个所需命令串联起来。将之前的 7 层,简化为了 1 层。在撰写 Dockerfile 的时候,要经常提醒自己,这并不是在写 Shell 脚本,而是在定义每一层该如何构建。
|
||||
|
||||
并且,这里为了格式化还进行了换行。Dockerfile 支持 Shell 类的行尾添加 `\` 的命令换行方式,以及行首 `#` 进行注释的格式。良好的格式,比如换行、缩进、注释等,会让维护、排障更为容易,这是一个比较好的习惯。
|
||||
|
||||
此外,还可以看到这一组命令的最后添加了清理工作的命令,删除了为了编译构建所需要的软件,清理了所有下载、展开的文件,并且还清理了 `apt` 缓存文件。这是很重要的一步,我们之前说过,镜像是多层存储,每一层的东西并不会在下一层被删除,会一直跟随着镜像。因此镜像构建时,一定要确保每一层只添加真正需要添加的东西,任何无关的东西都应该清理掉。
|
||||
|
||||
很多人初学 Docker 制作出了很臃肿的镜像的原因之一,就是忘记了每一层构建的最后一定要清理掉无关文件。
|
||||
要想编写优秀的 `Dockerfile`,必须了解每一条指令的作用和副作用。在 **[第七章 Dockerfile 指令详解](../07_dockerfile/README.md)** 中,我们将对 `COPY`, `ADD`, `CMD`, `ENTRYPOINT` 等指令进行详细讲解。
|
||||
|
||||
### 构建镜像
|
||||
|
||||
|
||||
@@ -1,9 +1,63 @@
|
||||
## 4.7 镜像的实现原理
|
||||
## 4.7 实现原理
|
||||
|
||||
Docker 镜像是怎么实现增量的修改和维护的?
|
||||
Docker 镜像是怎么实现增量的修改和维护的?为什么容器启动如此之快?这一切都归功于 Docker 的镜像分层存储设计。
|
||||
|
||||
每个镜像都由很多层次构成,Docker 使用 [Union FS](https://en.wikipedia.org/wiki/UnionFS) 将这些不同的层结合到一个镜像中去。
|
||||
### 镜像与分层存储
|
||||
|
||||
通常 Union FS 有两个用途, 一方面可以实现不借助 LVM、RAID 将多个 disk 挂到同一个目录下,另一个更常用的就是将一个只读的分支和一个可写的分支联合在一起,Live CD 正是基于此方法可以允许在镜像不变的基础上允许用户在其上进行一些写操作。
|
||||
在之前的章节中,我们一直强调镜像包含操作系统完整的 `root` 文件系统,其体积往往是庞大的。因此在 Docker 设计时,就充分利用 **Union FS** 的技术,将其设计为分层存储的架构。
|
||||
|
||||
Docker 在 OverlayFS 上构建的容器也是利用了类似的原理。
|
||||
Docker 镜像并不是一个单纯的文件,而是由一组文件系统叠加构成的。
|
||||
|
||||
最底层的镜像称为 **基础镜像(Base Image)**,通常是各种 Linux 发行版的 root 文件系统,如 Ubuntu、Debian、CentOS 等。
|
||||
|
||||
当我们在基础镜像之上构建新的镜像时(例如安装了 Nginx),Docker 并不是复制一份基础镜像,而是在基础镜像之上,**新建一个层(Layer)**,并在该层中仅记录为了安装 Nginx 而发生的文件变更(添加、修改、删除)。
|
||||
|
||||
这种分层存储结构使得镜像的复用、分发变得非常高效:
|
||||
|
||||
* **复用**:如果多个镜像都基于同一个基础镜像(例如都基于 `ubuntu:24.04`),那么宿主机只需要下载一份 `ubuntu:24.04`,所有镜像都可以共享它。
|
||||
* **轻量**:镜像仅仅记录了与基础镜像的差异,因此体积非常小。
|
||||
|
||||
### 容器层与读写
|
||||
|
||||
我们要理解的一个关键概念是:**镜像的每一层都是只读的(Read-only)**。
|
||||
|
||||
那么,既然镜像只读,容器为什么能写文件呢?
|
||||
|
||||
当容器启动时,Docker 会在镜像的最上层,添加一个新的**可写层(Writable Layer)**,通常被称为**容器层**。
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────┐
|
||||
│ 容器层 (可写, Writable Container Layer) │ <-- 所有的写操作都在这里
|
||||
├──────────────────────────────────────────────┤
|
||||
│ 镜像层 (只读, Read-only Image Layer) │
|
||||
├──────────────────────────────────────────────┤
|
||||
│ 镜像层 (只读, Read-only Image Layer) │
|
||||
├──────────────────────────────────────────────┤
|
||||
│ 基础镜像层 (只读, Base Image Layer) │
|
||||
└──────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
* **读取文件**:当容器需要读取文件时,Docker 会从最上层(容器层)开始向下层(镜像层)寻找,直到找到该文件为止。
|
||||
* **修改文件**:当容器需要修改某个文件时,Docker 会从下层镜像中将该文件复制到上层的容器层,然后对副本进行修改。这被称为 **写时复制(Copy-on-Write, CoW)** 策略。
|
||||
* **删除文件**:当容器删除某个文件时,Docker 并不是真的去下层删除它(因为下层是只读的),而是在容器层创建一个特殊的“白障(Whiteout)”文件,用来标记该文件已被删除,从而在容器视图中隐藏它。
|
||||
|
||||
这就是为什么:
|
||||
|
||||
1. **容器删除后数据会丢失**:因为所有的数据修改都保存在最上层的容器层中,容器销毁时,这个层也就随之销毁了。(除非使用了数据卷,详见[数据管理](../08_data_network/README.md))。
|
||||
2. **镜像不可变**:无论我们在容器里删除了多少文件,基础镜像的体积并不会减小,因为它们依然存在于底层的只读层中。
|
||||
|
||||
### 内容寻址与镜像 ID
|
||||
|
||||
Docker 镜像的每一层都有一个唯一的 ID,这个 ID 是根据该层的内容计算出来的哈希值(SHA256)。这意味着:
|
||||
|
||||
* **内容即 ID**:只要层的内容有一丁点变化,ID 就会变。
|
||||
* **安全性**:确保了镜像内容的完整性,下载过程中如果数据损坏,ID 校验就会失败。
|
||||
* **去重**:如果两个不同的镜像(甚至是不同来源的镜像)包含相同的层(ID 相同),Docker 引擎在本地只会存储一份,绝不重复下载。
|
||||
|
||||
### 联合文件系统 (Union FS)
|
||||
|
||||
Docker 使用联合文件系统(Union FS)来实现这种分层挂载。常见的驱动包括 `overlay2`(目前推荐)、`aufs`(早期使用)、`btrfs`、`zfs` 等。
|
||||
|
||||
虽然实现细节不同,但它们都遵循上述的 **分层 + CoW** 模型。
|
||||
|
||||
> 想要深入了解 Overlay2 等文件系统的具体实现原理,包括 WorkDir、UpperDir、LowerDir 等底层细节,请阅读 **[第十四章 底层实现](../14_implementation/README.md)** 中的 **[联合文件系统](../14_implementation/14.4_ufs.md)** 章节。
|
||||
|
||||
@@ -1,192 +0,0 @@
|
||||
# 多阶段构建
|
||||
|
||||
## 之前的做法
|
||||
|
||||
在 Docker 17.05 版本之前,我们构建 Docker 镜像时,通常会采用两种方式:
|
||||
|
||||
### 全部放入一个 Dockerfile
|
||||
|
||||
一种方式是将所有的构建过程编包含在一个 `Dockerfile` 中,包括项目及其依赖库的编译、测试、打包等流程,这里可能会带来的一些问题:
|
||||
|
||||
* 镜像层次多,镜像体积较大,部署时间变长
|
||||
|
||||
* 源代码存在泄露的风险
|
||||
|
||||
例如,编写 `app.go` 文件,该程序输出 `Hello World!`
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main(){
|
||||
fmt.Printf("Hello World!");
|
||||
}
|
||||
```
|
||||
|
||||
编写 `Dockerfile.one` 文件
|
||||
|
||||
```docker
|
||||
FROM golang:alpine
|
||||
|
||||
RUN apk --no-cache add git ca-certificates
|
||||
|
||||
WORKDIR /go/src/github.com/go/helloworld/
|
||||
|
||||
COPY app.go .
|
||||
|
||||
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
|
||||
|
||||
WORKDIR /root/
|
||||
|
||||
CMD ["./app"]
|
||||
```
|
||||
|
||||
构建镜像
|
||||
|
||||
```bash
|
||||
$ docker build -t go/helloworld:1 -f Dockerfile.one .
|
||||
```
|
||||
|
||||
### 分散到多个 Dockerfile
|
||||
|
||||
另一种方式,就是我们事先在一个 `Dockerfile` 将项目及其依赖库编译测试打包好后,再将其拷贝到运行环境中,这种方式需要我们编写两个 `Dockerfile` 和一些编译脚本才能将其两个阶段自动整合起来,这种方式虽然可以很好地规避第一种方式存在的风险,但明显部署过程较复杂。
|
||||
|
||||
例如,编写 `Dockerfile.build` 文件
|
||||
|
||||
```docker
|
||||
FROM golang:alpine
|
||||
|
||||
RUN apk --no-cache add git
|
||||
|
||||
WORKDIR /go/src/github.com/go/helloworld
|
||||
|
||||
COPY app.go .
|
||||
|
||||
RUN go get -d -v github.com/go-sql-driver/mysql \
|
||||
&& CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
|
||||
```
|
||||
|
||||
编写 `Dockerfile.copy` 文件
|
||||
|
||||
```docker
|
||||
FROM alpine:latest
|
||||
|
||||
RUN apk --no-cache add ca-certificates
|
||||
|
||||
WORKDIR /root/
|
||||
|
||||
COPY app .
|
||||
|
||||
CMD ["./app"]
|
||||
```
|
||||
|
||||
新建 `build.sh`
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
echo Building go/helloworld:build
|
||||
|
||||
docker build -t go/helloworld:build . -f Dockerfile.build
|
||||
|
||||
docker create --name extract go/helloworld:build
|
||||
docker cp extract:/go/src/github.com/go/helloworld/app ./app
|
||||
docker rm -f extract
|
||||
|
||||
echo Building go/helloworld:2
|
||||
|
||||
docker build --no-cache -t go/helloworld:2 . -f Dockerfile.copy
|
||||
rm ./app
|
||||
```
|
||||
|
||||
现在运行脚本即可构建镜像
|
||||
|
||||
```bash
|
||||
$ chmod +x build.sh
|
||||
|
||||
$ ./build.sh
|
||||
```
|
||||
|
||||
对比两种方式生成的镜像大小
|
||||
|
||||
```bash
|
||||
$ docker image ls
|
||||
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
go/helloworld 2 f7cf3465432c 22 seconds ago 6.47MB
|
||||
go/helloworld 1 f55d3e16affc 2 minutes ago 295MB
|
||||
```
|
||||
|
||||
## 使用多阶段构建
|
||||
|
||||
为解决以上问题,Docker v17.05 开始支持多阶段构建 (`multistage builds`)。使用多阶段构建我们就可以很容易解决前面提到的问题,并且只需要编写一个 `Dockerfile`:
|
||||
|
||||
例如,编写 `Dockerfile` 文件
|
||||
|
||||
```docker
|
||||
FROM golang:alpine as builder
|
||||
|
||||
RUN apk --no-cache add git
|
||||
|
||||
WORKDIR /go/src/github.com/go/helloworld/
|
||||
|
||||
RUN go get -d -v github.com/go-sql-driver/mysql
|
||||
|
||||
COPY app.go .
|
||||
|
||||
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
|
||||
|
||||
FROM alpine:latest as prod
|
||||
|
||||
RUN apk --no-cache add ca-certificates
|
||||
|
||||
WORKDIR /root/
|
||||
|
||||
COPY --from=0 /go/src/github.com/go/helloworld/app .
|
||||
|
||||
CMD ["./app"]
|
||||
```
|
||||
|
||||
构建镜像
|
||||
|
||||
```bash
|
||||
$ docker build -t go/helloworld:3 .
|
||||
```
|
||||
|
||||
对比三个镜像大小
|
||||
|
||||
```bash
|
||||
$ docker image ls
|
||||
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
go/helloworld 3 d6911ed9c846 7 seconds ago 6.47MB
|
||||
go/helloworld 2 f7cf3465432c 22 seconds ago 6.47MB
|
||||
go/helloworld 1 f55d3e16affc 2 minutes ago 295MB
|
||||
```
|
||||
|
||||
很明显使用多阶段构建的镜像体积小,同时也完美解决了上边提到的问题。
|
||||
|
||||
### 只构建某一阶段的镜像
|
||||
|
||||
我们可以使用 `as` 来为某一阶段命名,例如
|
||||
|
||||
```docker
|
||||
FROM golang:alpine as builder
|
||||
```
|
||||
|
||||
例如当我们只想构建 `builder` 阶段的镜像时,增加 `--target=builder` 参数即可
|
||||
|
||||
```bash
|
||||
$ 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
|
||||
```
|
||||
@@ -1,17 +0,0 @@
|
||||
.idea/
|
||||
.git/
|
||||
|
||||
vendor/
|
||||
|
||||
node_modules/
|
||||
|
||||
public/js/
|
||||
public/css/
|
||||
public/mix-manifest.json
|
||||
|
||||
yarn-error.log
|
||||
|
||||
bootstrap/cache/*
|
||||
storage/
|
||||
|
||||
# 自行添加其他需要排除的文件,例如 .env.* 文件
|
||||
@@ -1,55 +0,0 @@
|
||||
FROM node:alpine as frontend
|
||||
|
||||
COPY package.json /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& npm install --registry=https://registry.npm.taobao.org
|
||||
|
||||
COPY webpack.mix.js webpack.config.js tailwind.config.js /app/
|
||||
COPY resources/ /app/resources/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& touch artisan \
|
||||
&& mkdir -p public \
|
||||
&& npm run production
|
||||
|
||||
FROM composer as composer
|
||||
|
||||
COPY database/ /app/database/
|
||||
COPY composer.json /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ \
|
||||
&& composer install \
|
||||
--ignore-platform-reqs \
|
||||
--no-interaction \
|
||||
--no-plugins \
|
||||
--no-scripts \
|
||||
--prefer-dist
|
||||
|
||||
FROM php:7.4-fpm-alpine as laravel
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY --from=composer /app/vendor/ ${LARAVEL_PATH}/vendor/
|
||||
COPY . ${LARAVEL_PATH}
|
||||
COPY --from=frontend /app/public/js/ ${LARAVEL_PATH}/public/js/
|
||||
COPY --from=frontend /app/public/css/ ${LARAVEL_PATH}/public/css/
|
||||
COPY --from=frontend /app/public/mix-manifest.json ${LARAVEL_PATH}/public/mix-manifest.json
|
||||
|
||||
RUN set -x ; cd ${LARAVEL_PATH} \
|
||||
&& mkdir -p storage \
|
||||
&& mkdir -p storage/framework/cache \
|
||||
&& mkdir -p storage/framework/sessions \
|
||||
&& mkdir -p storage/framework/testing \
|
||||
&& mkdir -p storage/framework/views \
|
||||
&& mkdir -p storage/logs \
|
||||
&& chmod -R 777 storage \
|
||||
&& php artisan package:discover
|
||||
|
||||
FROM nginx:alpine as nginx
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY laravel.conf /etc/nginx/conf.d/
|
||||
COPY --from=laravel ${LARAVEL_PATH}/public ${LARAVEL_PATH}/public
|
||||
@@ -1,18 +0,0 @@
|
||||
server {
|
||||
listen 80 default_server;
|
||||
root /app/laravel/public;
|
||||
index index.php index.html;
|
||||
|
||||
location / {
|
||||
try_files $uri $uri/ /index.php?$query_string;
|
||||
}
|
||||
|
||||
location ~ .*\.php(\/.*)*$ {
|
||||
fastcgi_pass laravel:9000;
|
||||
include fastcgi.conf;
|
||||
|
||||
# fastcgi_connect_timeout 300;
|
||||
# fastcgi_send_timeout 300;
|
||||
# fastcgi_read_timeout 300;
|
||||
}
|
||||
}
|
||||
@@ -1,237 +0,0 @@
|
||||
## 实战多阶段构建 Laravel 镜像
|
||||
|
||||
> 本节适用于 PHP 开发者阅读。`Laravel` 基于 8.x 版本,各个版本的文件结构可能会有差异,请根据实际自行修改。
|
||||
|
||||
### 准备
|
||||
|
||||
新建一个 `Laravel` 项目或在已有的 `Laravel` 项目根目录下新建 `Dockerfile` `.dockerignore` `laravel.conf` 文件。
|
||||
|
||||
在 `.dockerignore` 文件中写入以下内容。
|
||||
|
||||
```bash
|
||||
.idea/
|
||||
.git/
|
||||
|
||||
vendor/
|
||||
|
||||
node_modules/
|
||||
|
||||
public/js/
|
||||
public/css/
|
||||
public/mix-manifest.json
|
||||
|
||||
yarn-error.log
|
||||
|
||||
bootstrap/cache/*
|
||||
storage/
|
||||
|
||||
## 自行添加其他需要排除的文件,例如 .env.* 文件
|
||||
|
||||
具体内容如下:
|
||||
|
||||
```
|
||||
|
||||
在 `laravel.conf` 文件中写入 nginx 配置。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80 default_server;
|
||||
root /app/laravel/public;
|
||||
index index.php index.html;
|
||||
|
||||
location / {
|
||||
try_files $uri $uri/ /index.php?$query_string;
|
||||
}
|
||||
|
||||
location ~ .*\.php(\/.*)*$ {
|
||||
fastcgi_pass laravel:9000;
|
||||
include fastcgi.conf;
|
||||
|
||||
# fastcgi_connect_timeout 300;
|
||||
# fastcgi_send_timeout 300;
|
||||
# fastcgi_read_timeout 300;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 前端构建
|
||||
|
||||
第一阶段进行前端构建。
|
||||
|
||||
```docker
|
||||
FROM node:alpine as frontend
|
||||
|
||||
COPY package.json /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& npm install --registry=https://registry.npmmirror.com
|
||||
|
||||
COPY webpack.mix.js webpack.config.js tailwind.config.js /app/
|
||||
COPY resources/ /app/resources/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& touch artisan \
|
||||
&& mkdir -p public \
|
||||
&& npm run production
|
||||
```
|
||||
|
||||
### 安装 Composer 依赖
|
||||
|
||||
第二阶段安装 Composer 依赖。
|
||||
|
||||
```docker
|
||||
FROM composer as composer
|
||||
|
||||
COPY database/ /app/database/
|
||||
COPY composer.json composer.lock /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ \
|
||||
&& composer install \
|
||||
--ignore-platform-reqs \
|
||||
--no-interaction \
|
||||
--no-plugins \
|
||||
--no-scripts \
|
||||
--prefer-dist
|
||||
```
|
||||
|
||||
### 整合以上阶段所生成的文件
|
||||
|
||||
第三阶段对以上阶段生成的文件进行整合。
|
||||
|
||||
```docker
|
||||
FROM php:7.4-fpm-alpine as laravel
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY --from=composer /app/vendor/ ${LARAVEL_PATH}/vendor/
|
||||
COPY . ${LARAVEL_PATH}
|
||||
COPY --from=frontend /app/public/js/ ${LARAVEL_PATH}/public/js/
|
||||
COPY --from=frontend /app/public/css/ ${LARAVEL_PATH}/public/css/
|
||||
COPY --from=frontend /app/public/mix-manifest.json ${LARAVEL_PATH}/public/mix-manifest.json
|
||||
|
||||
RUN set -x ; cd ${LARAVEL_PATH} \
|
||||
&& mkdir -p storage \
|
||||
&& mkdir -p storage/framework/cache \
|
||||
&& mkdir -p storage/framework/sessions \
|
||||
&& mkdir -p storage/framework/testing \
|
||||
&& mkdir -p storage/framework/views \
|
||||
&& mkdir -p storage/logs \
|
||||
&& chmod -R 777 storage \
|
||||
&& php artisan package:discover
|
||||
```
|
||||
|
||||
### 最后一个阶段构建 NGINX 镜像
|
||||
|
||||
具体内容如下:
|
||||
|
||||
```docker
|
||||
FROM nginx:alpine as nginx
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY laravel.conf /etc/nginx/conf.d/
|
||||
COPY --from=laravel ${LARAVEL_PATH}/public ${LARAVEL_PATH}/public
|
||||
```
|
||||
|
||||
### 构建 Laravel 及 Nginx 镜像
|
||||
|
||||
使用 `docker build` 命令构建镜像。
|
||||
|
||||
```bash
|
||||
$ docker build -t my/laravel --target=laravel .
|
||||
|
||||
$ docker build -t my/nginx --target=nginx .
|
||||
```
|
||||
|
||||
### 启动容器并测试
|
||||
|
||||
新建 Docker 网络
|
||||
|
||||
```bash
|
||||
$ docker network create laravel
|
||||
```
|
||||
|
||||
启动 laravel 容器, `--name=laravel` 参数设定的名字必须与 `nginx` 配置文件中的 `fastcgi_pass laravel:9000;` 一致
|
||||
|
||||
```bash
|
||||
$ docker run -dit --rm --name=laravel --network=laravel my/laravel
|
||||
```
|
||||
|
||||
启动 nginx 容器
|
||||
|
||||
```bash
|
||||
$ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
|
||||
```
|
||||
|
||||
浏览器访问 `127.0.0.1:8080` 可以看到 Laravel 项目首页。
|
||||
|
||||
> 也许 Laravel 项目依赖其他外部服务,例如 redis、MySQL,请自行启动这些服务之后再进行测试,本小节不再赘述。
|
||||
|
||||
### 生产环境优化
|
||||
|
||||
本小节内容为了方便测试,将配置文件直接放到了镜像中,实际在使用时 **建议** 将配置文件作为 `config` 或 `secret` 挂载到容器中,请读者自行学习 `Kubernetes` 的相关内容。
|
||||
|
||||
由于篇幅所限本小节只是简单列出,更多内容可以参考 https://github.com/khs1994-docker/laravel-demo 项目。
|
||||
|
||||
### 附录
|
||||
|
||||
完整的 `Dockerfile` 文件如下。
|
||||
|
||||
```docker
|
||||
FROM node:alpine as frontend
|
||||
|
||||
COPY package.json /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& npm install --registry=https://registry.npmmirror.com
|
||||
|
||||
COPY webpack.mix.js webpack.config.js tailwind.config.js /app/
|
||||
COPY resources/ /app/resources/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& touch artisan \
|
||||
&& mkdir -p public \
|
||||
&& npm run production
|
||||
|
||||
FROM composer as composer
|
||||
|
||||
COPY database/ /app/database/
|
||||
COPY composer.json /app/
|
||||
|
||||
RUN set -x ; cd /app \
|
||||
&& composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ \
|
||||
&& composer install \
|
||||
--ignore-platform-reqs \
|
||||
--no-interaction \
|
||||
--no-plugins \
|
||||
--no-scripts \
|
||||
--prefer-dist
|
||||
|
||||
FROM php:7.4-fpm-alpine as laravel
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY --from=composer /app/vendor/ ${LARAVEL_PATH}/vendor/
|
||||
COPY . ${LARAVEL_PATH}
|
||||
COPY --from=frontend /app/public/js/ ${LARAVEL_PATH}/public/js/
|
||||
COPY --from=frontend /app/public/css/ ${LARAVEL_PATH}/public/css/
|
||||
COPY --from=frontend /app/public/mix-manifest.json ${LARAVEL_PATH}/public/mix-manifest.json
|
||||
|
||||
RUN set -x ; cd ${LARAVEL_PATH} \
|
||||
&& mkdir -p storage \
|
||||
&& mkdir -p storage/framework/cache \
|
||||
&& mkdir -p storage/framework/sessions \
|
||||
&& mkdir -p storage/framework/testing \
|
||||
&& mkdir -p storage/framework/views \
|
||||
&& mkdir -p storage/logs \
|
||||
&& chmod -R 777 storage \
|
||||
&& php artisan package:discover
|
||||
|
||||
FROM nginx:alpine as nginx
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
COPY laravel.conf /etc/nginx/conf.d/
|
||||
COPY --from=laravel ${LARAVEL_PATH}/public ${LARAVEL_PATH}/public
|
||||
```
|
||||
Reference in New Issue
Block a user