ディレクトリ 検索
Compose About versions and upgrading (Compose) ASP.NET Core + SQL Server on Linux (Compose) CLI environment variables (Compose) Command-line completion (Compose) Compose(组成) Compose command-line reference(组合命令行参考) Control startup order (Compose) Django and PostgreSQL (Compose) Docker stacks and distributed application bundles (Compose) docker-compose build(docker-compose构建) docker-compose bundle docker-compose config docker-compose create docker-compose down docker-compose events docker-compose exec docker-compose help docker-compose images docker-compose kill docker-compose logs docker-compose pause docker-compose port docker-compose ps docker-compose pull docker-compose push docker-compose restart docker-compose rm docker-compose run docker-compose scale docker-compose start docker-compose stop docker-compose top docker-compose unpause docker-compose up Environment file (Compose) Environment variables in Compose Extend services in Compose Frequently asked questions (Compose) Getting started (Compose) Install Compose Link environment variables (deprecated) (Compose) Networking in Compose Overview of Docker Compose Overview of docker-compose CLI Quickstart: Compose and WordPress Rails and PostgreSQL (Compose) Sample apps with Compose Using Compose in production Using Compose with Swarm Engine .NET Core application (Engine) About images, containers, and storage drivers (Engine) Add nodes to the swarm (Engine) Apply custom metadata (Engine) Apply rolling updates (Engine) apt-cacher-ng Best practices for writing Dockerfiles (Engine) Binaries (Engine) Bind container ports to the host (Engine) Breaking changes (Engine) Build your own bridge (Engine) Configure container DNS (Engine) Configure container DNS in user-defined networks (Engine) CouchDB (Engine) Create a base image (Engine) Create a swarm (Engine) Customize the docker0 bridge (Engine) Debian (Engine) Default bridge network Delete the service (Engine) Deploy a service (Engine) Deploy services to a swarm (Engine) Deprecated Engine features Docker container networking (Engine) Docker overview (Engine) Docker run reference (Engine) Dockerfile reference (Engine) Dockerize an application Drain a node (Engine) Engine FAQ (Engine) Fedora (Engine) Get started (Engine) Get started with macvlan network driver (Engine) Get started with multi-host networking (Engine) How nodes work (Engine) How services work (Engine) Image management (Engine) Inspect the service (Engine) Install Docker (Engine) IPv6 with Docker (Engine) Join nodes to a swarm (Engine) Legacy container links (Engine) Lock your swarm (Engine) Manage nodes in a swarm (Engine) Manage sensitive data with Docker secrets (Engine) Manage swarm security with PKI (Engine) Manage swarm service networks (Engine) Migrate to Engine 1.10 Optional Linux post-installation steps (Engine) Overview (Engine) PostgreSQL (Engine) Raft consensus in swarm mode (Engine) Riak (Engine) Run Docker Engine in swarm mode Scale the service (Engine) SDKs (Engine) Select a storage driver (Engine) Set up for the tutorial (Engine) SSHd (Engine) Storage driver overview (Engine) Store service configuration data (Engine) Swarm administration guide (Engine) Swarm mode key concepts (Engine) Swarm mode overlay network security model (Engine) Swarm mode overview (Engine) Understand container communication (Engine) Use multi-stage builds (Engine) Use swarm mode routing mesh (Engine) Use the AUFS storage driver (Engine) Use the Btrfs storage driver (Engine) Use the Device mapper storage driver (Engine) Use the OverlayFS storage driver (Engine) Use the VFS storage driver (Engine) Use the ZFS storage driver (Engine) Engine: Admin Guide Amazon CloudWatch logs logging driver (Engine) Bind mounts (Engine) Collect Docker metrics with Prometheus (Engine) Configuring and running Docker (Engine) Configuring logging drivers (Engine) Control and configure Docker with systemd (Engine) ETW logging driver (Engine) Fluentd logging driver (Engine) Format command and log output (Engine) Google Cloud logging driver (Engine) Graylog Extended Format (GELF) logging driver (Engine) Journald logging driver (Engine) JSON File logging driver (Engine) Keep containers alive during daemon downtime (Engine) Limit a container's resources (Engine) Link via an ambassador container (Engine) Log tags for logging driver (Engine) Logentries logging driver (Engine) PowerShell DSC usage (Engine) Prune unused Docker objects (Engine) Run multiple services in a container (Engine) Runtime metrics (Engine) Splunk logging driver (Engine) Start containers automatically (Engine) Storage overview (Engine) Syslog logging driver (Engine) tmpfs mounts Troubleshoot volume problems (Engine) Use a logging driver plugin (Engine) Using Ansible (Engine) Using Chef (Engine) Using Puppet (Engine) View a container's logs (Engine) Volumes (Engine) Engine: CLI Daemon CLI reference (dockerd) (Engine) docker docker attach docker build docker checkpoint docker checkpoint create docker checkpoint ls docker checkpoint rm docker commit docker config docker config create docker config inspect docker config ls docker config rm docker container docker container attach docker container commit docker container cp docker container create docker container diff docker container exec docker container export docker container inspect docker container kill docker container logs docker container ls docker container pause docker container port docker container prune docker container rename docker container restart docker container rm docker container run docker container start docker container stats docker container stop docker container top docker container unpause docker container update docker container wait docker cp docker create docker deploy docker diff docker events docker exec docker export docker history docker image docker image build docker image history docker image import docker image inspect docker image load docker image ls docker image prune docker image pull docker image push docker image rm docker image save docker image tag docker images docker import docker info docker inspect docker kill docker load docker login docker logout docker logs docker network docker network connect docker network create docker network disconnect docker network inspect docker network ls docker network prune docker network rm docker node docker node demote docker node inspect docker node ls docker node promote docker node ps docker node rm docker node update docker pause docker plugin docker plugin create docker plugin disable docker plugin enable docker plugin inspect docker plugin install docker plugin ls docker plugin push docker plugin rm docker plugin set docker plugin upgrade docker port docker ps docker pull docker push docker rename docker restart docker rm docker rmi docker run docker save docker search docker secret docker secret create docker secret inspect docker secret ls docker secret rm docker service docker service create docker service inspect docker service logs docker service ls docker service ps docker service rm docker service scale docker service update docker stack docker stack deploy docker stack ls docker stack ps docker stack rm docker stack services docker start docker stats docker stop docker swarm docker swarm ca docker swarm init docker swarm join docker swarm join-token docker swarm leave docker swarm unlock docker swarm unlock-key docker swarm update docker system docker system df docker system events docker system info docker system prune docker tag docker top docker unpause docker update docker version docker volume docker volume create docker volume inspect docker volume ls docker volume prune docker volume rm docker wait Use the Docker command line (Engine) Engine: Extend Access authorization plugin (Engine) Docker log driver plugins Docker network driver plugins (Engine) Extending Engine with plugins Managed plugin system (Engine) Plugin configuration (Engine) Plugins API (Engine) Volume plugins (Engine) Engine: Security AppArmor security profiles for Docker (Engine) Automation with content trust (Engine) Content trust in Docker (Engine) Delegations for content trust (Engine) Deploying Notary (Engine) Docker security (Engine) Docker security non-events (Engine) Isolate containers with a user namespace (Engine) Manage keys for content trust (Engine) Play in a content trust sandbox (Engine) Protect the Docker daemon socket (Engine) Seccomp security profiles for Docker (Engine) Secure Engine Use trusted images Using certificates for repository client verification (Engine) Engine: Tutorials Engine tutorials Network containers (Engine) Get Started Part 1: Orientation Part 2: Containers Part 3: Services Part 4: Swarms Part 5: Stacks Part 6: Deploy your app Machine Amazon Web Services (Machine) Digital Ocean (Machine) docker-machine active docker-machine config docker-machine create docker-machine env docker-machine help docker-machine inspect docker-machine ip docker-machine kill docker-machine ls docker-machine provision docker-machine regenerate-certs docker-machine restart docker-machine rm docker-machine scp docker-machine ssh docker-machine start docker-machine status docker-machine stop docker-machine upgrade docker-machine url Driver options and operating system defaults (Machine) Drivers overview (Machine) Exoscale (Machine) Generic (Machine) Get started with a local VM (Machine) Google Compute Engine (Machine) IBM Softlayer (Machine) Install Machine Machine Machine CLI overview Machine command-line completion Machine concepts and help Machine overview Microsoft Azure (Machine) Microsoft Hyper-V (Machine) Migrate from Boot2Docker to Machine OpenStack (Machine) Oracle VirtualBox (Machine) Provision AWS EC2 instances (Machine) Provision Digital Ocean Droplets (Machine) Provision hosts in the cloud (Machine) Rackspace (Machine) VMware Fusion (Machine) VMware vCloud Air (Machine) VMware vSphere (Machine) Notary Client configuration (Notary) Common Server and signer configurations (Notary) Getting started with Notary Notary changelog Notary configuration files Running a Notary service Server configuration (Notary) Signer configuration (Notary) Understand the service architecture (Notary) Use the Notary client
テキスト

Docker运行引用

Docker 在独立的容器中运行进程。容器是一个在主机上运行的进程。主机可能是本地或远程的。当运营商执行时docker run,运行的容器进程是独立的,因为它拥有自己的文件系统,自己的网络以及独立于主机的独立进程树。

本页详细介绍如何使用该docker run命令在运行时定义容器的资源。

一般形式

基本docker run命令采用这种形式:

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

docker run命令必须指定一个 IMAGE 以从中派生容器。图像开发人员可以定义与以下相关的图像默认值:

  • 分离或前景运行

  • 货柜识别

  • 网络设置

  • CPU和内存的运行时间限制

随着docker run [OPTIONS]操作者可以添加或覆盖由开发者设置的图像的默认值。此外,运算符可以覆盖 Docker 运行时自身设置的几乎所有默认值。操作员重写图像和 Docker 运行时默认值的能力是为什么run比其他docker命令具有更多选项。

要了解如何解释类型[OPTIONS],请参阅选项类型

注意:根据您的 Docker 系统配置,您可能需要使用前面的docker run命令sudo。为了避免必须使用sudodocker命令,系统管理员可以创建一个名为的 Unix 组docker并向其添加用户。有关此配置的更多信息,请参阅适用于您的操作系统的 Docker 安装文档。

运营商独享选项

只有操作员(执行人员docker run)可以设置以下选项。

  • 分离与前景

    • 分离(-d)

    • 前景

  • 容器标识

    • 名称(-name)

    • PID等值

  • IPC设置(-ipc)

  • 网络设置

  • 重新启动策略(-restart)

  • 清理(-rm)

  • 运行时对资源的限制

  • 运行时权限和Linux功能

分离与前景

启动 Docker 容器时,您必须先决定是否要在后台以“分离”模式或默认的前台模式运行容器:

-d=false: Detached mode: Run container in the background, print new container id

分离(-d)

要以分离模式启动容器,可以使用-d=true或仅使用-d选项。按照设计,当用于运行容器的根进程退出时,容器以分离模式退出,除非您还指定了该--rm选项。如果使用-d--rm,容器,当它退出删除当守护进程退出,先发生者为准。

不要将service x start命令传递给分离的容器。例如,该命令尝试启动该nginx服务。

$ docker run -d -p 80:80 my_image service nginx start

这成功地启动nginx了容器内的服务。然而,它不符合分离的容器范例,因为根进程(service nginx start)返回并且分离的容器按设计停止。因此,该nginx服务已启动,但无法使用。相反,要启动诸如nginxWeb服务器等进程,请执行以下操作:

$ docker run -d -p 80:80 my_image nginx -g 'daemon off;'

要使用分离的容器进行输入/输出,请使用网络连接或共享卷。这些都是必需的,因为容器不再监听docker run运行的命令行。

要重新附加到分离的容器,请使用docker attach 命令。

前景

在前台模式下(-d未指定默认值时),docker run可以在容器中启动进程并将控制台附加到进程的标准输入,输出和标准错误。它甚至可以伪装成 TTY(这是大多数命令行可执行文件所期望的)并传递信号。所有这些都是可配置的:

-a=[]           : Attach to `STDIN`, `STDOUT` and/or `STDERR`
-t              : Allocate a pseudo-tty
--sig-proxy=true: Proxy all received signals to the process (non-TTY mode only)
-i              : Keep STDIN open even if not attached

如果你没有指定,-a那么 Docker 将连接到stdout和stderr。您可以指定其中三个标准流(STDINSTDOUTSTDERR)你想,而不是连接,如:

$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash

对于交互式进程(如shell),必须-i -t一起使用才能为容器进程分配tty。-i -t通常-it会按照后面的示例中的描述进行编写。-t当客户端从管道接收其标准输入时,禁止指定,如下所示:

$ echo test | docker run -i busybox cat

注意:在容器中作为PID 1运行的进程会被Linux专门处理:它将忽略具有默认操作的任何信号。因此,该过程将不会终止SIGINT或者SIGTERM除非它被编写这样做。

容器标识

名称(-name)

操作员可以通过三种方式识别容器:

识别类型

示例值

UUID长标识符

“F78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”

UUID短标识符

“F78375b1c487”

Name

“evil_ptolemy”

UUID  标识符来自 Docker 守护进程。如果您没有为该--name选项分配容器名称,则该守护程序会为您生成一个随机字符串名称。定义一个name可以方便地为容器添加含义。如果您指定了一个name,则可以在 Docker 网络中引用容器时使用它。这适用于后台和前台 Docker 容器。

注意:默认网桥网络上的容器必须链接以通过名称进行通信。

PID 等值

最后,为了帮助实现自动化,您可以让 Docker 将容器 ID 写出到您选择的文件中。这与某些程序可能会将其进程 ID 写入文件(您已将其视为 PID 文件)类似:

--cidfile="": Write the container ID to the file

图片:标签

虽然不是严格意义上的容器识别方法,但您可以通过添加image[:tag]到命令中来指定要运行容器的图像版本。例如,docker run ubuntu:14.04

图片@消化

使用v2或更高版本的图像格式的图像具有称为摘要的内容可寻址标识符。只要用于生成图像的输入保持不变,摘要值是可预测和可引用的。

以下示例从包含摘要的alpine映像运行容器sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0

$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date

PID设置(-pid)

--pid=""  : Set the PID (Process) Namespace mode for the container,             'container:<name|id>': joins another container's PID namespace             'host': use the host's PID namespace inside the container

默认情况下,所有容器都启用了 PID 名称空间。

PID 名称空间提供了进程的分离。PID 名称空间删除系统进程的视图,并允许重新使用进程 ID,包括 PID 1。

在某些情况下,您希望容器共享主机的进程名称空间,基本上允许容器中的进程查看系统上的所有进程。例如,你可以建立与调试工具等的容器stracegdb,但要在容器内调试过程时使用这些工具。

示例:在容器中运行 htop

创建这个 Dockerfile:

FROM alpine:latest
RUN apk add --update htop && rm -rf /var/cache/apk/*
CMD ["htop"]

构建 Dockerfile 并将图像标记为myhtop

$ docker build -t myhtop .

使用以下命令htop在容器内运行:

$ docker run -it --rm --pid=host myhtop

加入另一个容器的 pid 名称空间可用于调试该容器。

例子

启动运行 redis 服务器的容器:

$ docker run --name my-redis -d redis

通过运行另一个容器来调试 redis 容器:

$ docker run -it --pid=container:my-redis my_strace_docker_image bash
$ strace -p 1

UTS设置(-uts)

--uts=""  : Set the UTS namespace mode for the container,       'host': use the host's UTS namespace inside the container

UTS 命名空间用于设置在该命名空间中运行进程可见的主机名和域。默认情况下,所有容器(包括那些容器)--network=host都有自己的 UTS 名称空间。该host设置将导致容器使用与主机相同的 UTS 名称空间。请注意,--hostnamehostUTS 模式下无效。

如果您希望容器的主机名随着主机的主机名更改而更改,您可能希望与主机共享 UTS 名称空间。更高级的用例将从容器中更改主机的主机名。

IPC设置(-ipc)

--ipc=""  : Set the IPC mode for the container,             'container:<name|id>': reuses another container's IPC namespace             'host': use the host's IPC namespace inside the container

默认情况下,所有容器都启用了 IPC 命名空间。

IPC(POSIX / SysV IPC)命名空间提供命名共享内存段,信号量和消息队列的分离。

共享内存段用于以内存速度加速进程间通信,而不是通过管道或通过网络堆栈。共享内存通常由数据库和定制(通常为C / OpenMPI,C ++ /使用boost库)用于科学计算和金融服务行业的高性能应用程序使用。如果这些类型的应用程序分成多个容器,则可能需要共享容器的IPC机制。

网络设置

--dns=[]           : Set custom dns servers for the container--network="bridge" : Connect a container to a network                      'bridge': create a network stack on the default Docker bridge                      'none': no networking                      'container:<name|id>': reuse another container's network stack                      'host': use the Docker host network stack                      '<network-name>|<network-id>': connect to a user-defined network--network-alias=[] : Add network-scoped alias for the container--add-host=""      : Add a line to /etc/hosts (host:IP)--mac-address=""   : Sets the container's Ethernet device's MAC address--ip=""            : Sets the container's Ethernet device's IPv4 address--ip6=""           : Sets the container's Ethernet device's IPv6 address--link-local-ip=[] : Sets one or more container's Ethernet device's link local IPv4/IPv6 addresses

默认情况下,所有容器都已启用网络连接,并且可以进行任何传出连接。运营商可以完全禁用网络docker run --network none,禁用所有进入和离开的网络。在这样的情况下,你将I / O通过文件或执行STDINSTDOUT只。

发布端口和链接到其他容器只能使用默认(桥接)。链接功能是一项传统功能。您应该始终更喜欢使用 Docker 网络驱动程序进行链接。

默认情况下,您的容器将使用与主机相同的 DNS 服务器,但您可以使用它覆盖此容器--dns

默认情况下,使用分配给容器的IP地址生成 MAC 地址。您可以通过--mac-address参数(format 12:34:56:78:9a:bc:)提供MAC地址来明确设置容器的MAC地址。请注意,Docker不会检查手动指定的MAC地址是否唯一。

支持的网络:

网络

描述

没有

容器中没有网络。

桥(默认)

通过veth接口将容器连接到桥。

主办

在容器内使用主机的网络堆栈。

容器:<名称| ID>

使用另一个容器的网络堆栈,通过其名称或ID指定。

网络

将容器连接到用户创建的网络(使用docker network create命令)

网络:无

与网络是none一个容器将不能访问任何外部路由。该容器仍然loopback在容器中启用了一个接口,但它没有任何到外部流量的路由。

网桥

将网络设置为bridge容器将使用docker的默认网络设置。在主机上设置docker0一个通常命名的网桥,并veth为该容器创建一对接口。该veth对中的一侧将保留在连接到桥的主机上,而另一侧将放置在容器的命名空间内,除了该loopback界面。一个IP地址将被分配给桥接网络上的容器,流量将通过该桥接路由到容器。

容器默认通过 IP 地址进行通信。要通过名称进行交流,他们必须联系起来。

网络:主机

将网络设置为host容器将共享主机的网络堆栈,并且主机的所有接口都可用于容器。容器的主机名将与主机系统上的主机名匹配。请注意,--mac-addresshostnetmode中无效。即使在host网络模式下,默认情况下容器也有自己的UTS命名空间。因为这--hostname是在host网络模式下允许的,并且只会改变容器内的主机名。类似--hostname--add-host--dns--dns-search,和--dns-option选项可以用在host网络模式。这些选项更新/etc/hosts/etc/resolv.conf在容器内部。没有变化的,以制作/etc/hosts,并/etc/resolv.conf在主机上。

与默认bridge模式相比,该host模式显着提高了网络性能,因为它使用主机的本地网络堆栈,而网桥必须通过 docker 守护进程通过一级虚拟化。建议在网络性能至关重要的情况下以此模式运行容器,例如生产负载平衡器或高性能 Web 服务器。

注意--network="host"给容器充分访问本地系统服务,如 D-bus,因此被认为是不安全的。

网络:容器

将网络设置为container一个容器将共享另一个容器的网络堆栈。另一个容器的名称必须以格式提供--network container:<name|id>。请注意,--add-host --hostname --dns --dns-search --dns-option并且--mac-addresscontainernetmode 中无效,并且在netmode --publish --publish-all --expose中也无效container

示例使用 Redis 绑定运行 Redis 容器,localhost然后运行该redis-cli命令并通过localhost接口连接到 Redis 服务器。

$ docker run -d --name redis example/redis --bind 127.0.0.1$ # use the redis container's network stack to access localhost
$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1

用户定义的网络

您可以使用 Docker 网络驱动程序或外部网络驱动程序插件来创建网络。您可以将多个容器连接到同一个网络。一旦连接到用户定义的网络,容器就可以很容易地使用另一个容器的 IP 地址或名称进行通信。

对于overlay支持多主机连接的网络或自定义插件,连接到相同多主机网络但从不同引擎启动的容器也可以通过这种方式进行通信。

以下示例使用内置bridge网络驱动程序创建网络,并在创建的网络中运行容器

$ docker network create -d bridge my-net
$ docker run --network=my-net -itd --name=container3 busybox

Managing /etc/hosts

您的容器将具有/etc/hosts定义容器本身的主机名以及localhost其他一些常见事物的行。该--add-host标志可用于添加更多行/etc/hosts

$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts172.17.0.22     09d03f76bf2c
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters127.0.0.1       localhost::1	            localhost ip6-localhost ip6-loopback86.75.30.9      db-static

如果容器连接到默认桥接网络和linked其他容器,则/etc/hosts使用链接容器的名称更新容器的文件。

注意由于 Docker 可能实时更新容器的/etc/hosts文件,因此容器中的进程最终可能会读取空的或不完整的/etc/hosts文件。在大多数情况下,再次重试读取应解决问题。

重新启动策略(-restart)

--restart在Docker运行中使用标志,您可以指定一个重启策略,以便在退出时应该或不应该重启容器。

当重新启动策略是活性的容器上,它将被显示为任一UpRestartingdocker ps。使用docker events查看重启策略的效果也很有用。

Docker支持以下重启策略:

政策

结果

没有

退出时不要自动重启容器。这是默认设置。

对故障:最大重试

仅在容器以非零退出状态退出时才能重新启动。或者,限制Docker守护程序尝试重新启动的次数。

总是

不管退出状态如何,始终重新启动容器。当你总是指定时,Docker守护进程将尝试无限期地重启容器。无论容器的当前状态如何,容器也将始终在守护进程启动时启动。

除非,停止

无论退出状态如何,始终重新启动容器,但如果容器之前已处于停止状态,则不要在守护进程启动时启动它。

在每次重新启动前添加一个不断增加的延迟(前一延迟的两倍,从100毫秒开始),以防止服务器泛滥。这意味着守护进程将等待100毫秒,然后等待200毫秒,400,800,1600等,直到on-failure命中限制或者您docker stopdocker rm -f容器。

如果容器重新启动成功(容器启动并运行至少10秒钟),延迟将重置为默认值100 ms。

您可以指定 Docker 在使用故障策略时尝试重新启动容器的最大次数。默认情况下,Docker 将永远尝试重新启动容器。可以通过以下方式获取容器(尝试)重新启动的次数docker inspect。例如,要获取容器“my-container”的重新启动次数;

$ docker inspect -f "{{ .RestartCount }}" my-container
# 2

或者,为了获得最后一次容器(重新)启动;

$ docker inspect -f "{{ .State.StartedAt }}" my-container
# 2015-03-04T23:47:07.691840179Z

--restart(重新启动策略)与--rm(清除)标志组合会导致错误。在容器重启时,连接的客户端被断开连接 请参阅--rm本页后面使用(清理)标志的示例。

例子

$ docker run --restart=always redis

这将运行redis一个始终重启策略的容器,这样如果容器退出,Docker 将重新启动它。

$ docker run --restart=on-failure:10 redis

这将运行redis容器,其重启策略为on-failure,最大重启次数为10.如果redis容器以非零退出状态在一行中退出10次以上,Docker 将中止尝试重新启动容器。提供最大重新启动限制仅适用于故障策略。

退出状态

退出码docker run提供了有关容器无法运行或为何退出的信息。当docker run退出时非零码时,退出代码遵循chroot标准,见下文:

如果错误是 Docker 守护进程本身,则为 125

$ docker run --foo busybox; echo $?# flag provided but not defined: --foo
  See 'docker run --help'.  125

126 如果 包含的命令不能被调用

$ docker run busybox /etc; echo $?# docker: Error response from daemon: Container command '/etc' could not be invoked.  126

127 如果 包含的命令不能被找到

$ docker run busybox foo; echo $?# docker: Error response from daemon: Container command 'foo' not found or does not exist.  127

退出代码 包含命令否则

$ docker run busybox /bin/sh -c 'exit 3'; echo $?# 3

清理(-rm)

即使在容器退出后,默认情况下容器的文件系统仍然存在。这使调试更容易(因为您可以检查最终状态),并且默认情况下保留所有数据。但是如果你正在运行短期的 前台 进程,这些容器文件系统可能真的堆积如山。相反,如果您希望Docker  在容器退出时自动清理容器并移除文件系统,则可以添加该--rm标志:

--rm=false: Automatically remove the container when it exits (incompatible with -d)

注意:设置--rm标志时,当容器被移除时,Docker 也会删除与容器关联的卷。这与运行相似docker rm -v my-container。只有未指定名称的卷才会被删除。例如,与docker run --rm -v /foo -v awesome:/bar busybox top,音量/foo将被删除,但音量/bar不会。通过--volumes-from相同的逻辑将继承的卷将被删除 - 如果原始卷指定了名称,则不会被删除。

安全配置

--security-opt="label=user:USER"     : Set the label user for the container--security-opt="label=role:ROLE"     : Set the label role for the container--security-opt="label=type:TYPE"     : Set the label type for the container--security-opt="label=level:LEVEL"   : Set the label level for the container--security-opt="label=disable"       : Turn off label confinement for the container--security-opt="apparmor=PROFILE"    : Set the apparmor profile to be applied to the container--security-opt="no-new-privileges:true|false"   : Disable/enable container processes from gaining new privileges--security-opt="seccomp=unconfined"  : Turn off seccomp confinement for the container--security-opt="seccomp=profile.json": White listed syscalls seccomp Json file to be used as a seccomp filter

您可以通过指定--security-opt标志来覆盖每个容器的默认标签方案。在以下命令中指定级别允许您在容器之间共享相同的内容。

$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash

注意:目前不支持自动翻译MLS标签。

要禁用此容器的安全标签而不是使用该--privileged标志运行,请使用以下命令:

$ docker run --security-opt label=disable -it fedora bash

如果您希望容器中的进程采用更严格的安全策略,则可以为容器指定备用类型。您可以通过执行以下命令来运行只允许在Apache端口上侦听的容器:

$ docker run --security-opt label=type:svirt_apache_t -it centos bash

注意:您必须编写定义svirt_apache_t类型的策略。

如果你想阻止你的容器进程获得额外的权限,你可以执行下面的命令:

$ docker run --security-opt no-new-privileges -it centos bash

这意味着提升诸如su或者sudo将不再起作用的特权的命令。它还会导致任何 seccomp 过滤器稍后应用,权限被删除后,这可能意味着您可以拥有更多限制性的过滤器集。有关更多详细信息,请参阅内核文档。

指定一个 init 进程

您可以使用该--init标志来指示 init 过程应该用作容器中的 PID 1。指定init进程可确保在创建的容器内执行init系统的常规职责(如收割僵尸进程)。

使用的默认 init 进程是docker-init在 Docker 守护进程的系统路径中找到的第一个可执行文件。docker-init包含在默认安装中的这个二进制文件由tini提供支持。

指定自定义 cgroups

使用该--cgroup-parent标志,您可以传递特定的 cgroup 来运行容器。这允许您自行创建和管理 cgroup。您可以为这些 cgroup 定义自定义资源,并将容器放在公共父组下。

运行时对资源的限制

操作员还可以调整容器的性能参数:

选项

描述

-m,--memory =“”

内存限制(格式:<数字> <单位>)。数字是一个正整数。单位可以是b,k,m或g中的一个。最低为4M。

--memory交换=“”

内存总量限制(内存+交换,格式:<编号> <单位>)。数字是一个正整数。单位可以是b,k,m或g中的一个。

--memory预约=“”

内存软限制(格式:<编号> <单位>)。数字是一个正整数。单位可以是b,k,m或g中的一个。

--kernel内存=“”

内核内存限制(格式:<数字> <单位>)。数字是一个正整数。单位可以是b,k,m或g中的一个。最低为4M。

-c,--cpu-shares = 0

CPU份额(相对重量)

--cpus = 0.000

CPU数量。数字是一个小数。0.000表示没有限制。

--cpu周期= 0

限制CPU CFS(完全公平调度程序)期限

--cpuset-的CPU = “”

允许执行的CPU(0-3,0,1)

--cpuset-MEMS = “”

在其中允许执行的内存节点(MEM)(0-3,0,1)。只对NUMA系统有效。

--cpu配额= 0

限制CPU CFS(完全公平调度程序)配额

--cpu-RT-周期= 0

限制CPU实时期限。以微秒为单位。需要设置父cgroups并且不能高于父级。另请检查rtprio ulimits。

--cpu-RT-运行时间= 0

限制CPU实时运行时间。以微秒为单位。需要设置父cgroups并且不能高于父级。另请检查rtprio ulimits。

--blkio重量= 0

块IO权重(相对权重)接受介于10和1000之间的权重值。

--blkio-重设备= “”

阻止IO权重(相对设备权重,格式:DEVICE_NAME:WEIGHT)

--device读-BPS = “”

限制设备的读取速率(格式:<设备路径>:<编号> <单元>)。数字是一个正整数。单位可以是kb,mb或gb中的一个。

--device  - 写 -  BPS =“”

限制写入速率到设备(格式:<device-path>:<number> <unit>)。数字是一个正整数。单位可以是kb,mb或gb中的一个。

--device读-IOPS = “”

限制来自设备的读取速率(每秒IO)(格式:<device-path>:<number>)。数字是一个正整数。

--device  - 写 -  IOPS =“”

限制写入速率(每秒IO)到设备(格式:<device-path>:<number>)。数字是一个正整数。

--oom杀-禁用=假

是否禁用容器的OOM杀手。

--oom分数ADJ = 0

调整容器的OOM首选项(-1000到1000)

--memory-swappiness = “”

调整容器的内存swappiness行为。接受0到100之间的整数。

--shm尺寸=“”

/ dev / shm的大小。格式是<编号> <单位>。数字必须大于0.单位是可选的,可以是b(字节),k(千字节),m(兆字节)或g(千兆字节)。如果您省略了单位,系统会使用字节。如果完全忽略尺寸,则系统使用64米。

User memory constraints

我们有四种方法来设置用户内存使用情况:

选项

结果

memory = inf,memory-swap = inf(默认)

容器没有内存限制。容器可以根据需要使用尽可能多的内存。

内存= L <inf,内存交换= inf

(指定内存并将内存交换设置为-1)容器不允许使用多于L字节的内存,但可以根据需要使用尽可能多的交换(如果主机支持交换内存)。

内存= L <inf,内存交换= 2 * L

(指定没有内存交换的内存)容器不允许使用超过L字节的内存,swap和内存使用率是其中的两倍。

内存= L <inf,内存交换= S <inf,L <= S

(指定内存和内存交换)容器不允许使用多于L字节的内存,交换加内存使用受S限制。

例子:

$ docker run -it ubuntu:14.04 /bin/bash

我们没有设置内存,这意味着容器中的进程可以根据需要使用尽可能多的内存和交换内存。

$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash

我们设置内存限制和禁用交换内存限制,这意味着容器中的进程可以使用300M内存和尽可能多的交换内存(如果主机支持交换内存)。

$ docker run -it -m 300M ubuntu:14.04 /bin/bash

我们只设置内存限制,这意味着容器中的进程可以使用300M内存和300M交换内存,默认情况下,总虚拟内存大小(-memory-swap)将被设置为内存的两倍,在这种情况下,内存+ swap 会是2 * 300M,所以进程也可以使用300M交换内存。

$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash

我们设置了内存和交换内存,因此容器中的进程可以使用 300M 内存和 700M 交换内存。

内存预留是一种内存软限制,允许更大的内存共享。在正常情况下,容器可以根据需要使用尽可能多的内存,并且仅受限于使用-m/ --memory选项设置的硬限制。当设置了内存预留时,Docker 会检测内存争用或内存不足,并强制容器将其消耗限制在预留限制内。

始终将内存预留值设置为低于硬限制,否则硬限制优先。保留0与设置不保留相同。默认情况下(没有预留设置),内存预留与硬内存限制相同。

内存预留是一项软限制功能,并不保证不会超出限制。相反,该功能会尝试确保在内存严重竞争时基于预留提示/设置分配内存。

以下示例将内存(-m)限制为 500M,并将内存预留设置为 200M。

$ docker run -it -m 500M --memory-reservation 200M ubuntu:14.04 /bin/bash

在此配置下,当容器消耗的内存超过200M且小于500M时,下一次系统内存回收尝试将容器内存缩小到200M以下。

以下示例将内存预留设置为1G,但没有硬内存限制。

$ docker run -it --memory-reservation 1G ubuntu:14.04 /bin/bash

容器可以根据需要使用尽可能多的内存。内存预留设置可确保容器不会消耗太多内存很长时间,因为每个内存回收都会将容器的消耗量缩减到预留量。

默认情况下,如果发生内存不足(OOM)错误,内核会杀死容器中的进程。要更改此行为,请使用该--oom-kill-disable选项。只有在您还设置-m/--memory选项的容器上禁用 OOM 杀手。如果-m未设置标志,则可能导致主机内存不足,并且需要杀死主机的系统进程以释放内存。

以下示例将内存限制为100M,并禁用此容器的 OOM 杀手:

$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash

以下示例说明了使用该标志的危险方法:

$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash

该容器具有无限制的内存,这可能导致主机耗尽内存并需要查杀系统进程以释放内存。该--oom-score-adj参数是可以改变的选择优先权,容器就会被杀死,当系统内存不足,负得分使他们不太可能被杀害,并积极分数的可能性较大。

内核内存限制

内核内存与用户内存根本不同,因为内核内存不能被换出。无法进行交换使得容器可能通过消耗太多内核内存来阻塞系统服务。内核内存包括:

  • 堆叠页面

  • 平板页面

  • 插座内存压力

  • tcp 内存压力

您可以设置内核内存限制来限制这些内存。例如,每个进程都会消耗一些堆栈页面。通过限制内核内存,可以防止在内核内存使用率过高时创建新进程。

内核内存永远不会完全独立于用户内存。相反,您在用户内存限制的上下文中限制内核内存。假设“U”是用户内存限制,“K”是内核限制。有三种可能的方式来设置限制:

选项

结果

U!= 0,K = inf(默认)

这是使用内核内存之前已经存在的标准内存限制机制。内核内存被完全忽略。

U!= 0,K <U

内核内存是用户内存的一个子集。这种设置在每个cgroup的总内存数量过量的部署中非常有用。绝对不推荐过度使用内核内存限制,因为该方框仍可能耗尽不可回收的内存。在这种情况下,您可以配置K,使所有组的总和永远不会大于总内存。然后,以系统服务质量为代价自由设置U.

U!= 0,K> U

由于内核内存电荷也被馈送到用户计数器,并且为这两种内存的容器触发回收。这种配置为管理员提供了统一的内存视图。对于只想跟踪内核内存使用情况的人也很有用。

例子:

$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash

我们设置内存和内核内存,所以容器中的进程总共可以使用500M内存,在这个500M内存中,它可以是50M内核内存。

$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash

我们在不使用-m的情况下设置内核内存,因此容器中的进程可以使用尽可能多的内存,但它们只能使用50M内核内存。

Swappiness constraint

默认情况下,容器的内核可以换出一定比例的匿名页面。要为容器设置此百分比,请指定--memory-swappiness介于0和100之间的值。值为0将关闭匿名页面交换。值为100将所有匿名页面设置为可交换。默认情况下,如果你不使用--memory-swappiness,内存swappiness值将从父项继承。

例如,您可以设置:

$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash

如果--memory-swappiness要保留容器的工作集并避免交换性能处罚,设置该选项很有用。

CPU share constraint

默认情况下,所有容器都获得相同比例的CPU周期。通过相对于所有其他正在运行的容器的权重更改容器的CPU份额权重,可以修改此比例。

要从默认值1024修改比例,请使用-c--cpu-shares标志将权重设置为2或更高。如果设置为0,系统将忽略该值并使用默认值1024。

该比例仅适用于 CPU 密集型进程正在运行时。当一个容器中的任务空闲时,其他容器可以使用剩余的 CPU 时间。实际的 CPU 时间量取决于系统上运行的容器数量。

例如,考虑三个容器,一个 cpu-share 为1024,另外两个 cpu-share 设置为512.当所有三个容器中的进程尝试使用100%的 CPU 时,第一个容器将获得50%的 CPU 总 CPU 时间。如果添加一个 cpu-share 为1024的第四个容器,则第一个容器只能获得33%的 CPU。剩下的容器获得 CPU 的16.5%,16.5%和33%。

在多核系统上,CPU 时间份额分布在所有 CPU 核心上。即使容器的CPU时间限制在100%以内,它也可以使用每个 CPU 内核的100%。

例如,考虑一个具有三个以上内核的系统。如果你开始一个容器{C0}-c=512运行的一个过程,而另一个容器{C1}-c=1024运行的两个过程,这可能会导致CPU份额如下划分:

PID    container	CPU	CPU share100    {C0}0100% of CPU0101    {C1}1100% of CPU1102    {C1}2100% of CPU2

CPU周期约束

默认 CPU CFS(完全公平调度程序)周期为100ms。我们可以使用--cpu-period设置 CPU 的时间段来限制容器的 CPU 使用率。通常--cpu-period应该与--cpu-quota

例子:

$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash

如果有1个 CPU,这意味着容器每50ms可以获得50%的 CPU 运行时间。

除了使用--cpu-period--cpu-quota设置 CPU 周期约束外,还可以--cpus使用浮点数指定以实现相同的目的。例如,如果有1个 CPU,--cpus=0.5则会达到与设置--cpu-period=50000--cpu-quota=25000(50% CPU)相同的结果。

--cpusis 的默认值是0.000,这意味着没有限制。

有关更多信息,请参阅CFS有关带宽限制的文档。

Cpuset constraint

我们可以设置允许执行容器的 cpus。

例子:

$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash

这意味着容器中的进程可以在 cpu 1和 cpu 3上执行。

$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash

这意味着容器中的进程可以在 cpu 0,cpu 1和 cpu 2上执行。

我们可以设置允许执行容器的 mems。只对 NUMA 系统有效。

例子:

$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash

此示例将容器中的进程限制为仅使用内存节点1和3中的内存。

$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash

此示例将容器中的进程限制为仅使用内存节点0,1和2中的内存。

CPU配额限制

--cpu-quota标志限制了容器的 CPU 使用率。默认的0值允许容器占用100%的 CPU 资源(1个CPU)。CFS(完全公平调度程序)为执行进程处理资源分配,并且是内核使用的默认 Linux 调度程序。将此值设置为50000以将容器限制为 CPU 资源的50%。对于多个 CPU,--cpu-quota根据需要进行调整。有关更多信息,请参阅CFS有关带宽限制的文档。

Block IO bandwidth (Blkio) constraint

默认情况下,所有容器都获得相同比例的块 IO 带宽(blkio)。该比例为500.要修改此比例,请使用--blkio-weight标志更改容器的 blkio 权重与所有其他正在运行的容器的权重。

注意: blkio 权重设置仅适用于直接 IO。缓冲 IO 目前不受支持。

--blkio-weight标志可以将权重设置为10至1000之间的值。例如,下面的命令创建两个具有不同 blkio 权重的容器:

$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash
$ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash

如果您同时在两个容器中阻止 IO,例如:

$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct

您会发现时间的比例与两个容器的 blkio 权重的比例相同。

--blkio-weight-device="DEVICE_NAME:WEIGHT"标志设置了特定的设备重量。这DEVICE_NAME:WEIGHT是一个包含冒号分隔的设备名称和权重的字符串。例如,要将/dev/sda设备重量设置为200

$ docker run -it \    --blkio-weight-device "/dev/sda:200" \
    ubuntu

如果您同时指定--blkio-weight--blkio-weight-device,则 Docker 将使用--blkio-weight默认权重,并使用--blkio-weight-device此值在特定设备上用新值覆盖此默认值。以下示例使用默认权重300并将/dev/sda该权重设置为以下内容时将覆盖此默认值200

$ docker run -it \    --blkio-weight 300 \    --blkio-weight-device "/dev/sda:200" \
    ubuntu

--device-read-bps标志限制了设备的读取速率(每秒字节数)。例如,该命令创建一个容器并将读取速率限制为1mb每秒从以下位置开始/dev/sda

$ docker run -it --device-read-bps /dev/sda:1mb ubuntu

--device-write-bps标志限制了设备的写入速率(每秒字节数)。例如,该命令创建一个容器并将写入速率限制为1mb每秒的写入速率/dev/sda

$ docker run -it --device-write-bps /dev/sda:1mb ubuntu

两种标志都采用<device-path>:<limit>[unit]格式限制。读取和写入速率都必须是正整数。您可以指定速率kb(千字节),mb(兆字节)或gb(千兆字节)。

--device-read-iops标志限制了设备的读取速率(每秒 IO)。例如,该命令创建一个容器,并且限制了读出速度,以1000从 IO 每秒/dev/sda

$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu

--device-write-iops标志限制写入速率(每秒 IO)到设备。例如,该命令创建一个容器并将写入速率限制为每秒1000IO,以便/dev/sda

$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu

两种标志都采用<device-path>:<limit>格式限制。读取和写入速率都必须是正整数。

其他组

--group-add: Add additional groups to run as

默认情况下,泊坞窗容器进程运行时,为指定用户查找补充组。如果你想添加更多的组,那么你可以使用这个标志:

$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777

运行时权限和Linux功能

--cap-add: Add Linux capabilities--cap-drop: Drop Linux capabilities--privileged=false: Give extended privileges to this container--device=[]: Allows you to run devices inside the container without the --privileged flag.

默认情况下,Docker 容器是“非特权”的,例如不能在 Docker 容器中运行 Docker 守护进程。这是因为默认情况下容器不允许访问任何设备,但“特权”容器可以访问所有设备(请参阅cgroups设备上的文档)。

当操作员执行时docker run --privileged,Docker 将启用对主机上所有设备的访问,并在 AppArmor 或 SELinux 中设置一些配置,以允许容器几乎对主机的所有访问权限与主机上容器外运行的进程相同。有关运行的更多信息--privileged可在Docker博客上找到。

如果你想限制访问特定的设备或设备,你可以使用该--device标志。它允许您指定一个或多个在容器内可访问的设备。

$ docker run --device=/dev/snd:/dev/snd ...

默认情况下,容器就可以readwritemknod这些设备。这可以使用:rwm每个--device标志的第三组选项来覆盖:

$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk  /dev/xvdcCommand (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk  /dev/xvdc
You will not be able to write the partition table.Command (m for help): q

$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk  /dev/xvdc
    crash....$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk  /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted

除此之外--privileged,操作员可以对使用--cap-add和的能力进行细粒度控制--cap-drop。默认情况下,Docker 具有保留的默认功能列表。下表列出了默认情况下允许并可以删除的 Linux 功能选项。

能力密钥

能力描述

SETPCAP

修改过程功能。

MKNOD

使用mknod(2)创建特殊文件。

AUDIT_WRITE

将记录写入内核审计日志。

CHOWN

对文件UID和GID进行任意更改(请参见chown(2))。

NET_RAW

使用RAW和PACKET套接字。

DAC_OVERRIDE

绕过文件读取,写入和执行权限检查。

FOWNER

对通常需要进程的文件系统UID的操作绕过权限检查以匹配文件的UID。

FSETID

修改文件时,不要清除set-user-ID和set-group-ID权限位。

KILL

绕过发送信号的权限检查。

SETGID

任意操作进程GID和补充GID列表。

SETUID

任意操作进程UID。

NET_BIND_SERVICE

将套接字绑定到Internet域特权端口(端口号小于1024)。

SYS_CHROOT

使用chroot(2),更改根目录。

SETFCAP

设置文件功能。

下表显示了默认情况下未授予的功能,可以添加。

Capability Key

Capability Description

SYS_MODULE

Load and unload kernel modules.

SYS_RAWIO

Perform I/O port operations (iopl(2) and ioperm(2)).

SYS_PACCT

Use acct(2), switch process accounting on or off.

SYS_ADMIN

Perform a range of system administration operations.

SYS_NICE

Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes.

SYS_RESOURCE

Override resource Limits.

SYS_TIME

Set system clock (settimeofday(2), stime(2), adjtimex(2)); set real-time (hardware) clock.

SYS_TTY_CONFIG

Use vhangup(2); employ various privileged ioctl(2) operations on virtual terminals.

AUDIT_CONTROL

Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules.

MAC_OVERRIDE

Allow MAC configuration or state changes. Implemented for the Smack LSM.

MAC_ADMIN

Override Mandatory Access Control (MAC). Implemented for the Smack Linux Security Module (LSM).

NET_ADMIN

Perform various network-related operations.

SYSLOG

Perform privileged syslog(2) operations.

DAC_READ_SEARCH

Bypass file read permission checks and directory read and execute permission checks.

LINUX_IMMUTABLE

Set the FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags.

NET_BROADCAST

Make socket broadcasts, and listen to multicasts.

IPC_LOCK

Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)).

IPC_OWNER

Bypass permission checks for operations on System V IPC objects.

SYS_PTRACE

Trace arbitrary processes using ptrace(2).

SYS_BOOT

Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.

LEASE

Establish leases on arbitrary files (see fcntl(2)).

WAKE_ALARM

Trigger something that will wake up the system.

BLOCK_SUSPEND

Employ features that can block system suspend.

Further reference information is available on the capabilities(7) - Linux man page

两个标志都支持该值ALL,所以如果运营商想要拥有所有功能,但MKNOD可以使用:

$ docker run --cap-add=ALL --cap-drop=MKNOD ...

为了与网络堆栈进行交互,而不是使用--privileged它们--cap-add=NET_ADMIN来修改网络接口。

$ docker run -it --rm  ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy

要安装基于 FUSE 的文件系统,您需要将两者--cap-add--device

$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516drwxrwxr-x 1 1000 1000   4096 Dec  4 06:08 .drwxrwxr-x 1 1000 1000   4096 Dec  4 11:46 ..-rw-rw-r-- 1 1000 1000     16 Oct  8 00:09 .dockerignore-rwxrwxr-x 1 1000 1000    464 Oct  8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000   4096 Dec  4 06:11 .git-rw-rw-r-- 1 1000 1000    461 Dec  4 06:08 .gitignore....

默认的 seccomp 配置文件将根据选定的功能进行调整,以便允许使用功能所允许的设施,因此,自 Docker 1.12以来,您无需对其进行调整。在 Docker 1.10和1.11中,这没有发生,可能需要使用自定义的 seccomp 配置文件或--security-opt seccomp=unconfined在添加功能时使用。

Logging drivers (–log-driver)

容器可以具有与 Docker 守护程序不同的日志记录驱动程序。使用--log-driver=VALUEwith docker run命令配置容器的日志记录驱动程序。支持以下选项:

Driver

Description

none

Disables any logging for the container. docker logs won’t be available with this driver.

json-file

Default logging driver for Docker. Writes JSON messages to file. No logging options are supported for this driver.

syslog

Syslog logging driver for Docker. Writes log messages to syslog.

journald

Journald logging driver for Docker. Writes log messages to journald.

gelf

Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash.

fluentd

Fluentd logging driver for Docker. Writes log messages to fluentd (forward input).

awslogs

Amazon CloudWatch Logs logging driver for Docker. Writes log messages to Amazon CloudWatch Logs

splunk

Splunk logging driver for Docker. Writes log messages to splunk using Event Http Collector.

docker logs命令仅适用于json-filejournald日志记录驱动程序。有关使用记录驱动程序的详细信息,请参阅配置记录驱动程序。

Overriding Dockerfile image defaults

当开发人员从Dockerfile构建图像或提交时,开发人员可以设置许多默认参数,这些参数在图像作为容器启动时生效。

在 Dockerfile 命令的四个不能在运行时被覆盖:FROMMAINTAINERRUN,和ADD。其他的都有相应的覆盖docker run。我们将通过开发人员在每个Dockerfile指令中设置的内容以及操作员如何覆盖该设置。

  • CMD(默认命令或选项)

  • 入口点(运行时执行的默认命令)

  • EXPOSE(传入端口)

  • ENV(环境变量)

  • HEALTHCHECK

  • VOLUME(共享文件系统)

  • USER

  • WORKDIR

CMD(默认命令或选项)

回想COMMANDDocker命令行中的可选项:

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

该命令是可选的,因为创建这个命令的人IMAGE可能已经COMMAND使用 Dockerfile CMD指令提供了默认值。作为操作员(从图像运行容器的人员),CMD只需指定一个新操作即可覆盖该指令COMMAND

如果图片还指定了一个ENTRYPOINTthen,CMD或者COMMAND将其作为参数附加到ENTRYPOINT

ENTRYPOINT(在运行时执行的默认命令)

--entrypoint="": Overwrite the default entrypoint set by the image

ENTRYPOINT图像是类似COMMAND,因为它指定了可执行文件运行容器启动时,但它是(故意)更难以覆盖。在ENTRYPOINT给出了一个容器,它的默认性质或行为,所以,当你设置一个ENTRYPOINT可以运行的容器,就好像它是二进制,完全使用默认选项,并且可以在通过更多的选择传球COMMAND。但是,有时操作员可能想在容器内部运行其他内容,因此可以ENTRYPOINT在运行时通过使用字符串来指定新的值来覆盖默认值ENTRYPOINT。以下是如何在已经设置为自动运行其他内容(如/usr/bin/redis-server)的容器中运行shell的示例:

$ docker run -it --entrypoint /bin/bash example/redis

或者如何将更多参数传递给该入口点的两个示例:

$ docker run -it --entrypoint /bin/bash example/redis -c ls -l
$ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help

您可以通过传递空字符串来重置容器入口点,例如:

$ docker run -it --entrypoint="" mysql bash

注意:传递--entrypoint将清除图像上设置的任何默认命令(即CMD用于构建它的Dockerfile中的任何指令)。

EXPOSE (incoming ports)

以下run命令选项适用于容器网络:

--expose=[]: Expose a port or a range of ports inside the container.
             These are additional to those exposed by the `EXPOSE` instruction-P         : Publish all exposed ports to the host interfaces-p=[]      : Publish a container᾿s port or a range of ports to the host
               format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
               Both hostPort and containerPort can be specified as a
               range of ports. When specifying ranges for both, the
               number of container ports in the range must match the
               number of host ports in the range, for example:                   -p 1234-1236:1234-1236/tcp

               When specifying a range for hostPort only, the
               containerPort must not be a range.  In this case the
               container port is published somewhere within the
               specified hostPort range. (e.g., `-p 1234-1236:1234/tcp`)               (use 'docker port' to see the actual mapping)--link=""  : Add link to another container (<name or id>:alias or <name or id>)

EXPOSE指令外,图像开发人员对网络控制不够。该EXPOSE指令定义了提供服务的初始传入端口。这些端口可用于容器内的进程。操作员可以使用该--expose选项添加到暴露的端口。

要显示容器的内部端口,操作员可以使用-P-p标志启动容器。暴露的端口可以在主机上访问,并且端口可供任何可以连接到主机的客户端使用。

-P选项将所有端口发布到主机接口。Docker 将每个暴露的端口绑定到主机上的随机端口。端口范围在由...定义的临时端口范围内/proc/sys/net/ipv4/ip_local_port_range。使用该-p标志来显式映射单个端口或端口范围。

容器(服务侦听的地方)中的端口号不需要与容器外部(客户端连接的地方)上公开的端口号相匹配。例如,在容器内,HTTP 服务正在端口80上进行侦听(因此图像开发人员EXPOSE 80在 Dockerfile 中指定)。在运行时,端口可能会绑定到主机上的42800。要找到主机端口和外露端口之间的映射,请使用docker port

如果运营商--link在默认网桥网络中启动新的客户端容器时使用,则客户端容器可以通过专用网络接口访问公开的端口。如果--linkDocker 网络概述中描述的在用户定义的网络中启动容器时使用,它将为要链接的容器提供一个命名别名。

ENV (environment variables)

Docker 在创建 Linux 容器时会自动设置一些环境变量。在创建 Windows 容器时,Docker 不会设置任何环境变量。

为 Linux 容器设置以下环境变量:

变量

根据USER的值进行设置

主机名

与容器关联的主机名

路径

包括流行的目录,例如/ usr / local / sbin:/ usr / local / bin:/ usr / sbin:/ usr / bin:/ sbin:/ bin

术语

xterm如果容器被分配了伪TTY

另外,操作员可以通过使用一个或多个标志来设置容器中的任何环境变量-e,甚至覆盖上面提到的那些标志,或者已经由开发人员用 Dockerfile 定义ENV。如果操作符命名环境变量而不指定值,则命名变量的当前值会传播到容器的环境中:

$ export today=Wednesday
$ docker run -e "deep=purple" -e today --rm alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=d2219b854598
deep=purple
today=Wednesday
HOME=/root
PS C:\> docker run --rm -e "foo=bar" microsoft/nanoserver cmd /s /c setALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\ContainerAdministrator\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common FilesCommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=C2FAEFCC8253
ComSpec=C:\Windows\system32\cmd.exe
foo=bar
LOCALAPPDATA=C:\Users\ContainerAdministrator\AppData\Local
NUMBER_OF_PROCESSORS=8OS=Windows_NT
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 62 Stepping 4, GenuineIntel
PROCESSOR_LEVEL=6PROCESSOR_REVISION=3e04ProgramData=C:\ProgramData
ProgramFiles=C:\Program FilesProgramFiles(x86)=C:\Program Files (x86)ProgramW6432=C:\Program Files
PROMPT=$P$G
PUBLIC=C:\Users\Public
SystemDrive=C:SystemRoot=C:\Windows
TEMP=C:\Users\ContainerAdministrator\AppData\Local\Temp
TMP=C:\Users\ContainerAdministrator\AppData\Local\Temp
USERDOMAIN=User Manager
USERNAME=ContainerAdministrator
USERPROFILE=C:\Users\ContainerAdministrator
windir=C:\Windows

同样,操作员可以设置HOSTNAME(Linux)或COMPUTERNAME(Windows)-h

健康检查

  --health-cmd            Command to run to check health  --health-interval       Time between running the check  --health-retries        Consecutive failures needed to report unhealthy  --health-timeout        Maximum time to allow one check to run  --health-start-period   Start period for the container to initialize before starting health-retries countdown  --no-healthcheck        Disable any container-specified HEALTHCHECK

例子:

$ docker run --name=test -d \    --health-cmd='stat /etc/passwd || exit 1' \    --health-interval=2s \
    busybox sleep 1d
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test{  "Status": "unhealthy",  "FailingStreak": 3,  "Log": [    {      "Start": "2016-05-25T17:22:04.635478668Z",      "End": "2016-05-25T17:22:04.7272552Z",      "ExitCode": 0,      "Output": "  File: /etc/passwd\n  Size: 334       \tBlocks: 8          IO Block: 4096   regular file\nDevice: 32h/50d\tInode: 12          Links: 1\nAccess: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."    },    {      "Start": "2016-05-25T17:22:06.732900633Z",      "End": "2016-05-25T17:22:06.822168935Z",      "ExitCode": 0,      "Output": "  File: /etc/passwd\n  Size: 334       \tBlocks: 8          IO Block: 4096   regular file\nDevice: 32h/50d\tInode: 12          Links: 1\nAccess: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (    0/    root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."    },    {      "Start": "2016-05-25T17:22:08.823956535Z",      "End": "2016-05-25T17:22:08.897359124Z",      "ExitCode": 1,      "Output": "stat: can't stat '/etc/passwd': No such file or directory\n"    },    {      "Start": "2016-05-25T17:22:10.898802931Z",      "End": "2016-05-25T17:22:10.969631866Z",      "ExitCode": 1,      "Output": "stat: can't stat '/etc/passwd': No such file or directory\n"    },    {      "Start": "2016-05-25T17:22:12.971033523Z",      "End": "2016-05-25T17:22:13.082015516Z",      "ExitCode": 1,      "Output": "stat: can't stat '/etc/passwd': No such file or directory\n"    }  ]}

docker ps输出中还显示健康状况。

TMPFS (mount tmpfs filesystems)

--tmpfs=[]: Create a tmpfs mount with: container-dir[:<options>],
            where the options are identical to the Linux            'mount -t tmpfs -o' command.

下面的例子中安装一个空的 tmpfs 与容器rwnoexecnosuid,和size=65536k选项。

$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image

VOLUME (shared filesystems)

-v, --volume=[host-src:]container-dest[:<options>]: Bind mount a volume.The comma-delimited `options` are [rw|ro], [z|Z],[[r]shared|[r]slave|[r]private], and [nocopy].The 'host-src' is an absolute path or a name value.If neither 'rw' or 'ro' is specified then the volume is mounted inread-write mode.The `nocopy` modes is used to disable automatic copying requested volume
path in the container to the volume storage location.For named volumes, `copy` is the default mode. Copy modes are not supportedfor bind-mounted volumes.--volumes-from="": Mount all volumes from the given container(s)

注意:当使用 systemd 管理 Docker 守护进程的启动和停止时,在 systemd 单元文件中,有一个选项可以控制 Docker 守护进程本身的挂载传播MountFlags。此设置的值可能会导致 Docker 无法看到挂载点在挂载点上进行的挂载传播更改。例如,如果此值为slave,您可能无法在卷上使用sharedrshared传播。

卷命令足够复杂,可以在“ 管理容器中的数据”部分中拥有自己的文档。开发人员可以定义VOLUME与图像关联的一个或多个图像,但只有操作员可以从一个容器访问另一个容器(或从容器访问主机上安装的卷)。

container-dest必须始终是绝对路径,例如/src/docs。该host-src可以是绝对路径或name值。如果你提供了一个绝对路径host-dir,Docker 绑定到你指定的路径。如果你提供一个name,Docker 通过它创建一个命名的卷name

一个name值必须以字母数字字符,接着启动a-z0-9_(下划线), .(周期)或-(连字符)。绝对路径以/(正斜杠)开头。

例如,您可以指定一个值/foofoo一个host-src值。如果你提供这个/foo值,Docker 会创建一个绑定挂载。如果您提供foo规范,Docker 将创建一个命名卷。

USER

root(id = 0)是容器内的默认用户。图像开发人员可以创建更多用户。这些用户可以通过名称访问。在传递数字标识时,用户不必在容器中存在。

开发人员可以设置默认用户使用 Dockerfile USER指令运行第一个进程。启动容器时,操作员可以USER通过传递-u选项来覆盖指令。

-u="", --user="": Sets the username or UID used and optionally the groupname or GID for the specified command.The followings examples are all valid:--user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]

注意:如果你传递一个数字 uid,它必须在0-2147483647的范围内。

WORKDIR

在容器中运行二进制文件的默认工作目录是根目录(/),但开发人员可以使用 Dockerfile WORKDIR命令设置不同的默认值。操作员可以通过以下方式覆盖此项:

-w="": Working directory inside the container
前の記事: 次の記事: