0%

1
2
3
location ^~ /abc/ {
return 301 http://192.168.2.123:8503$uri;
}

含义

  • ^~ 正则匹配后面的路径 (这里是 /abc/),这里 location 的作用是匹配所有 uri 前缀是 /abc/ 的请求

  • 301 永久重定向

  • $uri 加上这个防止重定向之后 uri 丢失

很多人都对 Volume 有一个误解,他们认为 Volume 是为了持久化。如此想法是因为他们觉得容器不能持久化,所以 Volume 应该是为了满足这个需求设计的。其实容器会一直存在,除非你删除它们:

这可能来自于容器不是持久的想法,这样确实是不对的。容器是持久的,直到你删除他们,并且你只能这样做:

1
docker rm my_container

如果你没有执行此命令,那么你的容器会一直存在,依旧可以启动、停止等。如果你找不到你的容器,可以运行此命令:

1
docker ps -a

docker ps 只能显示正在运行的容器,但是容器也会处于停止状态,这种情况下,上面的命令会显示所有的容器,无论它们处于什么状态。

综上,再次声明:Volume 并不是为了持久化。

什么是 Volume

Volume 可以将容器以及容器产生的数据分离开来,这样,当你使用 docker rm my_container 删除容器时,不会影响相关的数据。

Volume 可以使用以下两种方式创建:

  • 在 Dockerfile 中指定 VOLUME /some/dir

  • 执行 docker run -v /some/dir 命令来指定

无论哪种方式都是做了同样的事情。它们告诉 Docker 在主机上创建一个目录(默认情况下是在 /var/lib/docker 下),然后将其挂载到指定的路径(例子中是 /some/dir)。当删除使用该 Volume 的容器时,Volume 本身不会受到影响,它可以一直存在下去。

如果在容器中不存在指定的路径,那么该目录将会被自动创建。

你可以告诉 Docker 同时删除容器和其 Volume:

1
docker rm -v my_container

有时候,你想在容器中使用主机上的某个目录,你可以通过其它的参数来指定:

1
docker run -v /host/path:/some/path

这明确地告诉 Docker 使用指定的主机路径来代替 Docker 自己创建的根路径并挂载到容器内指定的路径(以上例子为 /some/path)。需要注意的是,这种方式同样支持文件。在 Docker 术语中,这通常被称为 bind-mount(虽然技术层面上是这样讲的,但是实际的感觉是所有的 Volume 都是 bind-mounts 的)。 如果主机上的路径不存在,目录将自动在给定的路径中创建。

对待 bind-mounts Volume 和一个正常的 Volume 有一点不同,它不会修改主机上那些非 Docker 创建的东西:

  • 一个正常的 Volume,Docker 会自动将指定 Volume 路径(如上面的示例 /some/path)上的数据复制到由 Docker 创建的新目录下,如果是 "bind-mount"。Volume 就不会这样做。(这样做会将主机上的目录复制到容器)

  • 当你执行 docker rm -v my_container 命令时,"bind-mount" 类型的 Volume 不会被删除

容器也可以与其它容器共享 Volume。

1
2
docker run --name my_container -v /some/path ...
docker run --volume-from my_container --name my_container2 ...

上面的命令告诉 Docker 从第一个容器挂载相同的 Volume 到第二个容器,它可以在两个容器之间共享数据。

如果你执行 docker rm -v my_container 命令,而上方的第二个容器依然存在,那 Volume 不会被删除,如果你不使用 docker rm -v my_container2 命令删除第二个容器,那它会一直存在。

Dockerfile 里的 VOLUME

正如前面提到的,Dockerfile 中的 VOLUME 指令也可以做同样的事情,类似 docker run 命令中的 -v 参数(除了你不能在 Dockerfile 指定主机路径)。也正因为如此,构建镜像时可以得到惊奇的效果。

在 Dockerfile 中的每个命令都会创建一个新的用于运行指定命令的容器,并将容器提交到镜像,每一步都是在前一步的基础上构建的。因此 Dockerfile 中 ENV FOO=bar 等同于:

1
2
cid=$(docker run -e FOO=bar <image>)
docker commit $cid

下面让我们来看看这个 Dockerfile 的例子发生了什么:

1
2
3
FROM debian:jessie
VOLUME /foo/bar
RUN touch /foo/bar/baz
1
docker build -t my_debian .

我们期待的是 Docker 创建一个名为 my_debian 并且 Volume 是 /foo/bar 的镜像,以及在 /foo/bar/baz 下添加了一个空文件,但是让我们看看等同的 CLI 命令行实际上做了哪些:

1
2
3
4
cid=$(docker run -v /foo/bar debian:jessie)
image_id=$(docker commit $cid)
cid=$(docker run $image_id touch /foo/bar/baz)
docker commit $(cid) my_debian

真实过程可能并不是这样,但是类似。

在这里,/foo/bar 会首先创建,所以我们每次通过这个镜像启动一个容器,都会有一个空的 /foo/bar 目录。正如前面所说,Dockerfile 中每个命令都会创建一个新容器。 也就是说,每次都会创建一个新的 Volume。由于例子的 Dockerfile 是先指定 Volume 的,所以当执行 touch /foo/bar/baz 命令的容器创建时,一个 Volume 会被挂载到 /foo/bar,然后 baz 才能被写入此 Volume,而不是实际的容器或镜像的文件系统内。

所以,牢记 Dockerfile 中 VOLUME 指令的位置,因为它在你的镜像内创建了不可改变的目录。

我们在使用 Laravel 的 Command 的时候会发现,里面有两个方法 argumentoption,可是这两个方法有什么区别呢?

Argument

argument 是空格分隔的多个字符串,并且是有序的。

比如:

1
php test.php abc

在 php 里面,如果我们 var_dump($argv),就可以看到里面有 test.phpabc,这些就是 argument 了,并且他们是有顺序的。

option

option 是以 -- 开头的 argument,但是 Laravel 里面会把其当作是 option 而不是 argument。

比如:

1
php test.php abc --name=php

这里的 test.phpabc 是 argument,而 name 是一个 option。

总结

  • argument 前面没有 --,option 前面有 --

  • argument 是有序的,如果顺序乱了,会导致 $this->argument 拿到的 argument 是错误的

参考文档

Docker Volume 使用场景:数据共享、数据容器、备份。

想要了解 Docker Volume,首先我们要知道 Docker 的文件系统是如何工作的。Docker 镜像是由多个文件系统(只读层)叠加而成。当我们启动一个容器的时候,Docker 会加载只读镜像层并在其上添加一个读写层。 如果运行中的容器修改了现有的一个已经存在的文件,那该文件会从读写层下面的只读层复制到读写层,该文件的只读版本仍然存在,只是已经被读写层中该文件的副本所隐藏。当删除 Docker 容器,并通过该镜像重新启动时, 之前的更改将会丢失。在 Docker 中,只读层及在顶部的读写层的组合被称为 Union File System(联合文件系统)。

为了能够保存(持久化)数据以及共享容器间的数据,Docker 提出了 Volume 的概念。简单来说,Volume 就是目录或者文件,它可以绕过默认的联合文件系统,而以正常的文件或者目录的形式存在于宿主机上。

我们可以通过两种方式来初始化 Volume,这两种方式有些细小而又重要的区别。我们可以在运行时使用 -v 来声明 Volume:

1
2
3
docker run -it --name container-test -h CONTAINER -v /data debian /bin/bash
root@CONTAINER:/# ls /data
root@CONTAINER:/#

上面的命令会将 /data 挂载到容器中,并绕过联合文件系统,我们可以在主机上直接操作该目录。任何在该镜像 /data 路径的文件将会被复制到 Volume。我们可以使用 docker inspect 命令找到 Volume 在主机上的存储位置:

1
docker inspect -f {{.Volumes}} container-test

你会看到类似的输出:

1
map[/data:/var/lib/docker/vfs/dir/.....]

这说明 Docker 把 /var/lib/docker 下的某个目录挂载到了容器内的 /data 目录下。

这时如果我们在宿主机上的 /var/lib/docker 下对应目录新增一个文件,在容器内的 /data 就会看到一样的文件。

只要将宿主机的目录挂载到容器的目录上,那改变就会立即生效。我们可以在 Dockerfile 中通过 VOLUME 指令来达到相同的目的:

1
2
FROM debian:wheezy
VOLUME /data

但还有另一件只有 -v 参数能够做到而 Dockerfile 是做不到的事情就是在容器上挂载指定的主机目录。例如:

1
docker run -v /home/tony/data:/data debian ls /data

该命令将挂载主机的 /home/tony/data 目录到容器内的 /data 目录上。任何在 /home/tony/data 目录的文件都会出现在容器内。这对于在主机和容器之间共享文件是非常有帮助的,例如挂载需要编译的源代码。 为了保证可移植性(并不少所有系统的宿主机目录都是可以用的),挂载主机目录不需要从 Dockerfile 指定。当使用 -v 参数时,镜像目录下的任何文件都不会被复制到 Volume 中。(Volume 会复制到镜像目录,镜像不会复制到卷)

数据共享

如果要授权一个容器访问另一个容器的 Volume,我们可以使用 --volumes-from 参数来执行 docker run。

1
docker run -it -h NEWCONTAINER --volumes-from container-test debian /bin/bash

值得注意的是不管 container-test 是否运行,它都会起作用。只要有容器连接 Volume,它就不会被删除。

数据容器

常见的使用场景是使用纯数据容器来持久化数据库、配置文件或者数据文件等。例如:

1
docker run --name dbdata postgres echo "Data-only container for postgres"

该命令将会创建一个已经包含在 Dockerfile 里定义过 Volume 的 postgres 镜像,运行 echo 命令然后退出。 当我们运行 docker ps 命令时,echo 可以帮助我们识别某镜像的用途。我们可以用 --volumes-from 命令来识别其他容器的 Volume:

1
docker run -d --volumes-from dbdata --name db1 postgres

使用数据容器的两个注意点:

  • 不要运行数据容器,这纯粹是在浪费资源

  • 不要为了数据容器而使用 "最小的镜像",如 busybox 或 scratch,只使用数据库镜像本身就可以来。你已经拥有该镜像,所以并不需要占用额外的空间。

备份

如果你在用数据容器,那做备份是相当容易的:

1
$ docker run --rm --volumes-from dbdata -v $(pwd):/backup debian tar cvf /backup/backup.tar /var/lib/postgresql/data

该示例应该会将 Volume 里所有的东西压缩为一个 tar 包(官方的 postgres Dockerfile 在 /var/lib/postgres/data 目录下定义了一个 Volume)

权限与许可

通常你需要设置 Volume 的权限或者为 Volume 初始化一些默认数据或者配置文件。要注意的关键点是,在 Dockerfile 的 VOLUME 指令后的任何东西都不能改变该 Volume,比如:

1
2
3
4
5
FROM debian:wheezy
RUN useradd foo
VOLUME /data
RUN touch /data/x
RUN chown -R foo:foo /data

该 Dockerfile 不能按预期那样运行,我们本来系统 touch 命令在镜像的文件系统上运行,但是实际上它是在一个临时容器的 Volume 上运行。如下所示:

1
2
3
4
5
FROM debian:wheezy
RUN useradd foo
RUN mkdir /data && touch /data/x
RUN chown -R foo:foo /data
VOLUME /data

Docker 可以将镜像中 Volume 下的文件挂载到 Volume 下,并设置正确的权限。如果你指定 Volume 的主机目录将不会出现这种情况。

如果你没有通过 RUN 指令设置权限,那么你就需要在容器启动时使用 CMD 或 ENTRYPOINT 指令来执行。 (CMD 指令用于指定一个容器启动时要运行的命令,与 RUN 类似,只是 RUN 是镜像在构建时要运的命令。)

删除 Volumes

这个功能可能会更加重要,如果你已经使用 docker rm 来删除你的容器,那可能有很多的孤立的 Volume 仍在占用着空间。

Volume 只有在下列情况下才能被删除:

  • 该容器是用 docker rm -v 命令来删除的(-v 是必不可少的)

  • docker run 中使用了 --rm 参数

即使用以上两种命令,也只能没有被容器连接的 Volume。连接到用户指定主机目录的 Volume 永远不会被 docker 删除。

除非你已经很小心的,总是像这样来运行容器,否则你将在 /var/lib/docker/vfs/dir 目录下得到一些僵尸文件和目录,并且还不容器说出它们到底代表什么。