Docker 系列<完> Docker Commands 一览


Docker 常用命令

Dockerfile

我们将尝试在 docker 容器中运行程序,爬取 cn.bing 的图片。

对于 bing 图片的爬取,这里采用最简单的方式:通过 bing 官方的 链接 爬取。为此,我们需要先准备一个简单的 Go 程序:

const (
    bingPrefix = "https://cn.bing.com"
    bingUrl    = bingPrefix + "/HPImageArchive.aspx"
    limit      = 5    // 爬取 5 条
    format     = "js" // json 格式
)

var (
    images = make([]string, limit)
)

type Image struct {
    FullStartDate string `json:"fullStartDate,omitempty"`
    Url           string `json:"url"`
}

type Bing struct {
    Images []Image `json:"images"`
}

func main() {
    logrus.Info("*****************  Star Http Server *****************")
    server := echo.New()

    // 这里就不用 POST 了
    server.GET("/pull", scraperHandler)
    server.GET("/list", bingListHandler)

    server.Logger.Fatal(server.Start(":1234"))
}

func scraperHandler(e echo.Context) error {
    var (
        err    error
        res    *http.Response
        rBytes []byte
        bing   Bing
        sorry  = false
    )

    if res, err = http.Get(wrapUrl()); err != nil {
        logrus.Error("get url failed, error=", err.Error())
        sorry = true
    }

    if res == nil || res.Body == nil {
        logrus.Error("we got nil response...")
        sorry = true
    }

    if rBytes, err = ioutil.ReadAll(res.Body); err != nil {
        logrus.Error("read response body failed.", err.Error())
        sorry = true
    }

    if err = json.Unmarshal(rBytes, &bing); err != nil {
        logrus.Error("unmarshal body failed.", err.Error())
        sorry = true
    }

    if sorry {
        return e.JSON(http.StatusInternalServerError, "something wrong...")
    }

    // 先清空
    if len(images) != 0 {
        images = []string{}
    }

    for _, img := range bing.Images {
        if len(img.Url) == 0 {
            continue
        }
        images = append(images, bingPrefix+img.Url)
        if len(images) == limit {
            break
        }
    }
    return e.JSON(http.StatusOK, "Done")
}

func bingListHandler(e echo.Context) error {
    return e.JSONPretty(http.StatusOK, images, "")
}

func wrapUrl() string {
    return fmt.Sprintf("%s?format=%s&idx=0&n=%d", bingUrl, format, limit)
}

1. 编写 Dockerfile

Dockerfile 常见格式如下:

# 声明使用的基础镜像
FROM alpine

# 一系列动作
RUN echo Hello
COPY ./tmp.txt /usr/local
ADD ./add.zip /usr/local
ENV ENV1 ENV_VALUE1

# 启动容器时,默认的执行程序
ENTRYPOINT ["start.sh"]
CMD echo hello

FROM

用来初始化一个新的 build stage(构建阶段),并为后续的指令提供一个 base image(基础镜像)。

一个有效的 Dockerfile ,必须以 FROM 指令开头。

比如我们常常使用 alpine 来作为 linux 的 base image,因为它提供了一个小巧精简的 linux kernel。


RUN

RUN 指令有两种形式:

  • shell 形式: 如 RUN echo $HOME, 该命令会以 /bin/sh -c 方式执行
  • exec 形式: 如 RUN [“echo”, “$HOME”], 这里不会做 shell 解析,所以会输出 $HOME

LABEL

用来将元素据打到镜像中。

我们制作镜像的时候,出了程序,一般会把相关的信息,如分支,commit 短号,构建日期,版本,作者等,放到镜像中。这个时候,就可以使用 LABEL 。以前通过 MAINTAINER 标签来表明作者,现在已弃用,使用 LABEL 来实现:

LABEL version="v0.1" \ 
    built_time="2020-02-02" 、
    maintainer="iyuhp"

COPY & ADD

二者都可以用来添加本地文件到 image 中。

在执行 build 命令时,docker 客户端会把上下文中的所有文件发送给 docker daemon。考虑 docker 客户端和 docker daemon 不在同一台机器上的情况,build 命令只能从上下文中获取文件。

如果仅仅是把本地的文件拷贝到容器镜像中,COPY 命令是最合适不过的。其命令的格式为:

COPY  [,, ...,]
COPY  

如果 src 有多个时, dest 必须以 / 左斜杠结尾!

除了指定完整的文件名外,COPY 命令还支持 Go 风格 的通配符,比如:

COPY check* /testdir/           # 拷贝所有 check 开头的文件
COPY check?.log /testdir/       # ? 是单个字符的占位符,比如匹配文件 check1.log

对于目录而言,COPY 和 ADD 命令具有相同的特点:只复制目录中的内容而不包含目录自身。比如我们在 Dockerfile 中添加下面的命令:

# 假设 data 目录下存在 file1 和 file2
WORKDIR /app
COPY data ./  # 此时 ./ 中只包含 file1 和 file2 ,而不是 ./data/file1, 2

 # 如果需要 data 目录,则需要这样做
 COPY data ./data 

如果duo src 拷贝时发生冲突,后面的 src 文件,会覆盖前面的 src 文件。假设有两个目录 /a/c.txt 和 /b/c.txt

通过 COPY /a/c.txt /b/c.txt /abc/ 命令, 容器内会变成 /abc/c.txt ,且该文件来自于 /b/c.txt。

COPY 还可用在 multistage 场景下 COPY --from=builder /src .

对于 ADD 指令,不能用在 multistage 场景,其他的上述描述,ADD 都可以做到:

ADD [<src>, <src>, ... <src>, <dest>]
ADD <src> <dest>

ADD 的 src ,可以是远程文件 URL,ADD 会帮助拉取(一般不建议这样用,可以通过 wget,curl 命令来获取),还可以是采用公认压缩格式(gzip, bzip2, xz,identity) 的本地归档文件,则 docker 会帮助我们执行 tar -x 解压文件(远程 URL 文件不会被解压)

对于 ADD 而言,如果其定义的内容发生了改变,则之后所有的缓存都会失效,对于 dockerfile 优化,这会是一个点,我们要尽量避免这种情况,或者将 ADD 尽量放到 Dockerfile 的后面


ENV

设置环境变量, 支持两种形式:

ENV e1 v1
ENV e1=v1 e2=v2 ...

WORKDIR

指定工作目录,会 cd 到指定的目录下, 可以使用 env

WORKDIR /workspace
RUN pwd # 输出 /workspace
WORKDIR abc # 此时在 /workspace/abc
ENV DIRPATH /tmp
WORKDIR $DIRPATH/abc # 此时在 /tmp/abc

可通过 -w 覆盖:

docker run -ti -w /otherworkspace ubuntu pwd

USER

指定运行 image 时的 user 和组,默认为 root:

USER [:]
USER [<:]

STOPSIGNAL

用来设置停止容器时, 发送什么系统调用信号给容器。这个信号必须是内核系统调用表中合法的数, 如 9, 或者 SIGNAME 格式中的信号名称, 如 SIGKILL 。


ARG

用来定义在 docker build 命令运行时传递给构建运行时的变量。 只需要在构建时, 通过 --build-arg 来使用。 用户只能在构建时指定在 Dockerfile 中定义过的参数!

ARG build
ARG build_user=peifeng # 构建时若未指定, 则使用 peifeng 这个默认值

对于 DevOps 而言,我们会把打包这个动作放到 docker 中执行,我们可以通过 buidl args 参数,限制 cpu / mem 等系统资源的使用。

docker build --build-arg build_user=1234 -t peifeng/demo:v1 .

注意, 不要通过 ARG 来传递证书或者密钥之类的信息。这些在构建过程中以及镜像的构建历史中会被暴露!

ARG 指令可能会导致 docker 的高速缓存失效。参见 这里

docker 预定义了一组 ARG 变量,在构建时可直接使用, 参见 官方文档#ARG

  • HTTP_PROXY
  • http_proxy
  • HTTPS_PROXY
  • https_proxy
  • FTP_PROXY
  • ftp_proxy
  • NO_PROXY
  • no_proxy

ONBUILD

为镜像添加触发器。A 镜像中有 ONBUILD 指令, B 镜像使用 A 镜像作为父镜像,构建时, 会触发 ONBUILD 指令。ONBUILD 只有子镜像会被触发, 孙子镜像不会触发。

ONBUILD, FROM, MAINTAINER 不能用在 ONBUILD 指令中, 错误示例: ONBUILD FROM centos:7

子镜像在 FROM 后, 会首先运行父镜像的 ONBUILD 的指令: RUN echo hello world father

该功能可以用作镜像模板功能, 抽象出一些公共的指令放到父镜像中。


HEALTHCHECK

用于容器的健康检查:

HEALTHCHECK [options] CMD command
HEALTHCHECK NONE 禁用从父镜像继承的 health check
HEALTHCHECK --interval=5m \ 
    --timeout=3s \ 
    --start-period=30s \ 
    --retries=3 \ 
    CMD curl -f http://localhost/ || exit 1 

容器的三个状态:

  • starting : 容器的启动状态
  • healthy : 通过健康检查后的状态
  • unhealthy : 健康检查失败且超过重试次数后的状态

参数说明:

  • --interval : 设置检查的时间间隔, 默认 30s
  • --timeout : #设置超时时间,如果一次检查超过 3s (默认 30s) ,则认为不健康。 此时不会将容器置为不健康, 会配合下面的 retries ,超过重试次数后,会见容器置为 unhealthy
  • --start-period : 容器启动时间,容器开始启动到设置的这段时间内,不统计健康检查(默认 0s)
  • --retries : 重试次数,当连续 3 次检查失败,则认为该容器出了问题,置为 unhealthy
  • CMD : CMD 后为检查的动作

该命令每次检查,会返回三个状态码:

  • 0 : 容器健康
  • 1 : 不健康,容器无法正常工作
  • 2 : docker 的保留退出码,暂时没什么作用,谁知道后面用来干嘛,官方建议我们不要用这个退出码

SHELL

shell 指令允许我们设置默认的 shell。 Linux 上的默认 shell 是 [“/bin/sh”, “-c”],而在 Windows 上是 [“cmd”, “/S”, “/C”]。

  • SHELL 指令必须以 JSON 格式写入 Dockerfile

  • SHELL 指令可以多次出现。每条 SHELL 指令都会覆盖所有先前的 SHELL 指令,并影响所有后续指令

# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]

VOLUME

用来指定挂载卷。VOLUME 更多内容请参见 这里

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

上面的 Dockerfile ,会在 docker run 时, 创建一个新的挂载点 /myvol , 然后将 greeting 文件 copy 到卷中。

volume 有如下特性:

  • volume 可以在容器间共享和重用
  • 对 volume 的修改是立即生效的
  • 对 volume 的修改,不会对更新镜像产生影响

当我们通过 Dockerfile 指定 volume 时:

VOLUME ["/data", "/log"]

如果我们执行 docker run 时,未指定宿主机挂载点,则 docker 会自动绑定到宿主机的一个目录下,一般在 /var/lib/docker/volumes 目录下。假设 container id 为 123456, 我们通过 docker inspect -f {{ .Mounts }} 123456 ,找到挂载卷的名称,再到 volumes 下找对应的数据(可能在一个 _data 目录里)就好了。

通过 docker run 方式使用

docker 在 17.06 版本前,对于单机版 docker ,通过 --volume 或者 -v 指定,现在官方建议使用 --mount 命令来指定挂载卷。这里以 --mount 演示:

docker run --rm -ti \
--name bing \
--mount source=/var/volume/bing,target=/myvol,readonly \
nginx:latest
  • –rm 指明当前容器停止后,删除容器
  • -ti , -t 表示打开一个伪终端, -i 表示打开容器的 stdin
  • –mount 中, source 表示宿主机挂载点, target 表示容器内挂载点, readonly 表明该挂载卷为只读模式

docker 官方给出了一张图:

share data

表明通过 volume 来实现各个 container 之间数据共享。


CMD & ENTRYPOINT

这两个命令都可以用来指定容器的默认执行命令。

CMD 的作用:

  • 通过 exec 模式执行默认执行命令 , 可以在 docker run 的时候被覆写
  • 通过 shell 模式执行默认执行命令 , 可以在 docker run 的时候被覆写
  • 为 ENTRYPOINT 提供执行参数
FROM alpine
CMD ["echo", "$HOME"] # docker run 且不复写命令时,输出 $HOME
# 或者这样
CMD echo $HOME # docker run 且不覆写命令时, 输出 /home/xxx (你的 home 目录)

这个时候,我们这样启动:

docker run --rm bing:v0.1 ps

则会执行 ps 命令。

注意, CMD 命令只能被整体覆写,不能覆写 CMD 中的某个参数

ENTRYPOINT 的作用:

  • 通过 exec 模式执行默认命令,可以在 docker run 的时候,追加参数
  • 通过 shell 模式执行默认命令,不可以被覆写, 是什么样就是什么样
FROM alpine
CMD ["p1", "p2"]
ENTRYPOINT ["echo", "hello"]

这个会输出 hello p1 p2

FROM alpine
CMD echo haha
ENTRYPOINT ["echo", "hello"]

这个则会输出 hello /bin/sh -c echo haha , 这也表明 shell 模式下会通过 /bin/sh -c 来解释命令

我们现在通过 docker run 来试试:

docker run --rm -ti bing:v0.1 aha

这个时候,CMD 的参数会被全部覆写,而 docker run 传递的参数会被追加到 ENTRYPOINT 后面,所以最终会输出 hello aha 。

我们来总结一波:

有 ENTRYPOINT 时:

  • 为 shell 模式,那就是它了,别给我扯别的
  • 为 cmd 模式时, CMD 或者 docker run 添加的参数,都乖乖加到我的后面去, 所以这个时候, CMD 都是给 ENTRYPOINT 提供默认的启动参数

只有 CMD 时,会被 docker run 的启动参数全部覆写掉

docker 官方给出的 CMD 和 ENTRYPOINT 的关系图:

CMD & ENTRYPOINT

2. 动手

到目前为止,我们都还没有自己动手写一个 Dockerfile, 现在,可以试一下了:

# 基础镜像
FROM golang:1.14

# 工作目录
WORKDIR /go/cache
COPY ./go.mod ./go.sum ./
RUN GOPROXY=https://goproxy.io/ GO111MODULE=on go mod download

WORKDIR /go/release
ADD . .
RUN GOPROXY=https://goproxy.io/ GOOS=linux CGO_ENABLED=0 GO111MODULE=on go build -ldflags="-s -w" -o ./bing ./main.go
# 添加执行权限
RUN chmod +x /usr/bin/bing
CMD ["/usr/bin/bing"]

有了上面的基础,现在再来看这个 Dockerfile ,是不是太简单了?

tips : 如果你有 golang 环境,只需要把最上面的代码 copy 下去,然后执行 go mod init bing && go mod tidy

之后执行 docker build . -t bing:v1.0 ,通过 docker images | grep bing 查看,会看到一个将近 1G 的镜像。

我滴个乖乖, 事实上,我们的 bing 程序,只有不到 9M:

➜  bing ll
total 9.0M
-rwxrwxr-x 1 dylan dylan 8.5M Apr 22 02:10 bing
-rw-rw-r-- 1 dylan dylan  397 Apr 22 01:59 dockerfile.bing
-rw-rw-r-- 1 dylan dylan  113 Apr 22 02:06 go.mod
-rw-rw-r-- 1 dylan dylan 4.8K Apr 22 02:06 go.sum
-rw-rw-r-- 1 dylan dylan 1.9K Apr 22 01:27 main.go

这必然不能忍啊!

这近 1G 的镜像,大部分都是我们用不到的,都是 golang 相关, 而当我们通过 golang 环境构建完成后,这些环境就可以抛弃了。

基于此, docker 推出了 multistage 构建技术。


multistage 允许我们在一份 Dockerfile 文件中,通过多 stage 来构建我们需要的目标文件,最后使用 copy --from 来把多 stage 产物合并到一起,同时摒弃掉那些已然无用的文件。

在我们这个例子中,我们只需要构建完成的 bing 可执行程序(以及运行这个程序所需的最小环境),剩下的都不需要。

所以,我们这样做:

# 基础镜像 
# 第一个 stage ,我们通过 as 将当前 stage 命名为 builder
FROM golang:1.14 as builder
# 工作目录
WORKDIR /go/cache
COPY ./go.mod ./go.sum ./
RUN GOPROXY=https://goproxy.io/ GO111MODULE=on go mod download

WORKDIR /go/release
ADD . .
RUN GOPROXY=https://goproxy.io/ GOOS=linux CGO_ENABLED=0 GO111MODULE=on go build -ldflags="-s -w" -o ./bing ./main.go
# 到这里为止, 我们的目标程序已经产生,为: /go/release/bing
# 于是我们使用下一个 stage

# 供 bing 程序执行的最小环境
FROM alpine
# 从 上一个 stage 拷贝文件到当前 stage, 通过 --from 知名 copy 的目标 stage
COPY --from=builder /go/release/bing /usr/bin/bing
# 添加执行权限
RUN chmod +x /usr/bin/bing
CMD ["/usr/bin/bing"]

之后,我们再次构建 docker build . -t bing:v1.0docker images | grep bing 查看:

➜  bing docker images | grep bing
bing                                                         v1.0                0504d26e479d        14 minutes ago      18.4MB

可以看到,最终大小,为 18.4MB , 于是我们从 1G ,瘦到了不到 20M ,完美。

现在我们来测试下:

# 从 bing 获取图片
➜  ~ curl localhost:1234/pull
"Done"
# 查看获取的图片记录
➜  ~ curl localhost:1234/list
["https://cn.bing.com/th?id=OHR.KauriTree_ZH-CN3695568740_1920x1080.jpg\u0026rf=LaDigue_1920x1080.jpg\u0026pid=hp","https://cn.bing.com/th?id=OHR.GPS_ZH-CN5160095061_1920x1080.jpg\u0026rf=LaDigue_1920x1080.jpg\u0026pid=hp","https://cn.bing.com/th?id=OHR.BluebellWood_ZH-CN8128422960_1920x1080.jpg\u0026rf=LaDigue_1920x1080.jpg\u0026pid=hp","https://cn.bing.com/th?id=OHR.NeistPoint_ZH-CN3115403132_1920x1080.jpg\u0026rf=LaDigue_1920x1080.jpg\u0026pid=hp","https://cn.bing.com/th?id=OHR.VernalFalls_ZH-CN2664125316_1920x1080.jpg\u0026rf=LaDigue_1920x1080.jpg\u0026pid=hp"]

Docker compose

我们拉取了照片,可是这个时候,我又想把这些东西存起来。于是我们又搞了个 server,专门用来存这些图片 url 。

怎么搞呢?

我们于是又用 docker 起了一个 server。于是我们每次都要启动两个 server 。

要这么麻烦吗? of course not !

docker 可以通过 docker-compose 文件,为我们提供服务编排。

所谓服务编排,说白了,就是对一堆的服务,做排序,先启哪个,后起哪个(当然,服务编排的功能可不仅如此,比如服务发现等) 。

要使用 docker-compose ,需要首先安装:

# 1. 下载
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# 2. 添加执行权限
sudo chmod +x /usr/local/bin/docker-compose

# 3. 添加软连接
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

# 4. 测试安装是否成功
docker-compose --version

这里 可以看到 docker-compose 的版本。

一般性结构为(具体的 yaml 结构,可以去看它的 源码):

version: '2.0'
services: # 用来定义各个服务
    ...
networks: # 网络设置
    ... 
volumes: # 卷设置
    ...
secrets: # 敏感数据
    ...
configs: # 其他设置
    ...

这里不再展开,我们先尝试把上面的 dockerfile 改写成 docker-compose.yml :

version: '3.8'
services:
    bing:
        ports:
        - "1235:1235"
         image: bing-compose:v1.0
         build:
             context: .
             dockerfile: "dockerfile.bing"
             labels: # 支持 dict 和 list 两种模式, 使用 list 模式请参考 ports 写法
                 source: "I'm from docker compose"
                 maintainer: "iyuhp"

此时,执行 docker-compose up , 则会构建镜像并拉起镜像。

现在,我们把 redis 加进去,作为临时存储:

version: '3.8'
services:
    bing:
        ports:
        - "1235:1235"
         image: bing-compose:v1.0
         build:
             context: .
             dockerfile: "dockerfile.bing"
             labels: # 支持 dict 和 list 两种模式, 使用 list 模式请参考 ports 写法
                 source: "I'm from docker compose"
                 maintainer: "iyuhp"
         depends_on: # 表明该服务依赖于 redis ,会先启动 redis ,再启动该服务
             - redis
    redis:
         ports:
             - "6379:6379"
         image: redis:5.0
         command: ["redis-server", "/usr/local/etc/redis/redis.conf"] # 覆写 CMD 
         volumes:
             - ./redis-data:/data
             - ./redis.conf:/usr/local/etc/redis/redis.con # 自定义 redis.conf

这样,就可以通过 docker-compose up 来依次启动 redis , bing 服务了。

嗯, 虽然这里并没有和 redis 互动。 如果你喜欢,完全可以基于上面的代码,稍微加点 redis 调用,就好了


常用 docker 命令

docker create

创建一个容器, 但是不会运行它

docer start

docker start / restart container_name/container_id

启动或者重启已经停止的容器

docker run

  • -i 保证容器中 STDIN 是开启的, 持久的标准输入是交互式 shell 的“半边天”
  • -t 告诉 docker 要为创建的容器分配一个伪 tty 终端, 这样, 新建的容器才能提供一个交互式 shell
  • -d 后台运行
  • -p 用来控制 docker 在运行时应该公开哪些网络端口给外部(宿主机)。docker 可以通过两种方式来在宿主机上分配方式:
    • 在宿主机上随机选择一个 32768 ~ 61000 的一个比较大的端口号来映射到容器中的 80 端口
    • 在 docker 宿主机中指定一个具体的端口号来映射到容器中的 80 端口
  • –name 制定运行容器的名字, 名字规则:[a-zA-Z0-9_.-]
  • –restart 当由于某种错误,导致容器停止运行时, 该命令会检查容器的退出码,并据此来决定, 是否需要重启。默认的行为是 Docker 不会重启容器。
    • always: 无论退出码是什么, docker 都会自动重启该容器
    • on-failure: 退出码为非 0 时,docker 会重启该容器, 还可接受一个重启次数的参数: --restart=on-failure:3
      docker run --name dylan_ubuntu_container -ti ubuntu /bin/bash
      

docker run -ti -d –name daemon_test centos sh -c ‘while true;do echo hello world;sleep 3;done;’

docker run –restart=always –name daemon_test centos sh -c ‘while true;do echo hello world;sleep 3;done;’

docker run -d -p 8080 –name peifeng/first_image

将容器中的 80 端口绑定到宿主机的 8080 端口

docker run -d -p 8080:80 –name peifeng/first_image

绑定到特定的网络端口

docker run -d -p 127.0.0.1:8080:80 –name peifeng/first_image

绑定到特定网络接口的随机端口

docker run -d -p 127.0.0.1::80 –name peifeng/first_image

只指定 -p 时, 会对外公开通过 Dockerfile中 EXPOSE 指令公开的的所有端口

docker run -d -p –name peifeng/first_image




### docker ps

- -a  列出所有容器, 包括正在运行和已经停止的
- -q  : quiet ,只列出 container id,不返回其他信息
- -l  last, 列出最后一个运行的容器, 无论其是在运行还是停止
- -n x  列出最后运行的 x 个容器, 无论其是在运行还是停止

### docker top container_id

查看容器内的所有进程

## docker stats container_id

查看容器状态

### docker exec

在容器内部额外启动新进程。

可以在容器内部运行的进程有两种:后台任务和交互式任务。

- 后台任务在容器内运行且没有交互需求
- 交互式任务保持在前台运行

```bash
# -d 表明需要运行一个后台进程
docker exec -d daemon_task touch /etc/new_file

# 启动一个打开 shell 的交互式任务
docker exec -ti daemon_task /bin/bash

docker stop container_id

停止容器, stop 会向容器发送 SIGTERM 信号

docker kill container_id

停止容器, kill 会向容器发送 SIGKILL 信号

docker rm container_id

  • -f : Docker 1.6.2 开始, 使用 -f 标志来强制删除运行中的 Docker 容器。
  • 无参, 需要先 stop or kill 掉该容器, 再 rm
# 删除所有容器
docker rm  `docker ps -aq`

docker inspect

  • 无参数 对容器进行详细的检查,然后返回其配置信息, 包括名称/命令/网络配置等
  • -f/–format 指定查看结果。 该标志支持完整的 Go 语言模板
# 查看 docker 运行状态
docker inspect --format '{{ .State.Running }}' container_id

查找所有 Docker Hub 上公共的可用镜像

docker images

  • -a 列出本地所有镜像,含中间镜像层,不加 -a 会忽略中间镜像
  • -q 只显示镜像 id , quiet
  • -f 过滤
# 列出特定的某个镜像,也就是说指定仓库名和标签
docker images ubuntu
docker images ubuntu:12.04

# 支持 go 语言模板
docker images --format "{{ .ID }}:{{ .Registry }}"

# -f 参数过滤
docker images -f label=Language=golang

# 希望看到在 mongo:3.2 之后建立的镜像(之前用 before 即可)
docker images -f since=mongo:3.2

# 虚悬镜像已经失去了存在的价值,是可以随意删除的,可以用下面的命令删除。
docker rmi $(docker images -q -f dangling=true)

# 在 Docker 1.13+ 版本中你可以便捷的使用以下命令来删除虚悬镜像。
docker image prune

docker pull name:tag

拉取镜像

docker tag

给镜像打 tag

一览图

Docker Commands


拓展

linux 中 shell 提供了用户与 kernel 交互的接口,它将用户输入的命令送到 kernel 执行,是 kernel 与用户之间的解释器,相当于 kernel 的“外壳”。

在上文中,当我们使用 shell 方式执行命令时, shell 会通过 fork 的方式,复制一个子进程执行,当前 shell 作为父进程。

而当我们使用 exec 模式时,命令将在当前 shell 内执行,不会产生新的进程。

Reference

Docker Cli 官方文档

Docker Compose 官方文档

Read More

Linux fork exec source 介绍


文章作者: peifeng
版权声明: 本博客所有文章除特別声明外,均采用 CC BY-NC-ND 4.0 许可协议。转载请注明来源 peifeng !
 上一篇
Java 系列<一> -- Java RoadMap Java 系列<一>-- Java RoadMap
今天整理了一份 java 的 roadmap ,后面将按照这份 roadmap ,进行复习和学习,然后持续输出。完了,感觉 summary 的字数不太够,所以我多说一点,现在字数应该够了。
2020-04-22
下一篇 
Docker 系列<二> Docker 架构 Docker 系列<二>Docker 架构
上一篇文章我们介绍了 Docker 的安装,本文将深入到 Docker 内部,着重描述它的架构以及几个核心点。其中着重描述 docker container 网络的内部通信机制,告诉你 curl container api 时,网络做了什么事情。
2020-04-18
  目录