关于docker的基本使用

  • dokcer的基本组成
  • 镜像

相当于挂在了root文件系统的Linux。

  • 容器

镜像与容器的关系,就像是面向对象中的类和实体一样。镜像是静态定义的,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等操作。
容器的实质是进程。但是与直接宿主执行的进程不同,容器进程运行属于自己的独立的命名空间。

  • 仓库

Dockerfile的使用

Dockerfile是一个文本文件

  • 如我们在某个目录创建一个Dockerfile文件。
    vi Dockerfile
  • Dockerfile最基本的格式如下:

FROM nginx
RUN echo "

Hello world

" /usr/share/nginx/html/index.html

- 指令说明
 - FROM 指定镜像 基础镜像是必须要指定的。作用就是在此镜像的基础上进行定制。在Dockerfile文件中,FROM是必备的命令,而且是第一条命令。
 - eg

FROM centos

 - 此外,除了选择现有镜像的基础上,Docker还存在一个特殊的镜像,名为scratch,这个镜像是虚拟的概念,并不实际存在,他表示一个空白的镜像

FROM scratch
...

 - RUN 执行命令 ,它是用来执行命令行命令的,由于命令行强大的能力,RUN指令在定制镜像时是最常用的命令之一。
 - RUN命令后跟着的有两种格式:
  - 1、Shell格式:RUN <命令> 

RUN echo "hello world"

  -2、 exec格式:RUN ["可执行文件", "参数1", "参数2"],这更像是函数调用中的格式。
如果RUN执行了多条命令,则应该按照如下方式书写,而不是每条命令都使用RUN执行一次。因为层数限制。

FROM debian:jessie
RUN buildDeps='gcc libc6-dev make'
&& apt-get update
&& apt-get install -y $buildDeps
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.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


### 构建镜像
- 首先创建一个Dockerfile 文件,vi Dockerfile,然后加入最简单的命令:
FROM nginx
RUN echo "hello docker"
保存退出。
- 构建镜像,在Dockerfile文件的当前目录下执行
docker build -t nginx:v2 .
- 等待执行完毕
`说明:我们指定了镜像名 -t nginx:v2`
- 最后,运行该容器

docker run -d -p 8085:80 nginx:v2

 - 在浏览器中输入localhost:8085即可看到输出。

- 删除镜像

docker rmi -f 镜像名


- docker build构建命令的格式为:

docker build [选项] <上下文路径/URL/>


### 构建上下文路径
- docker build命令最后面有个 . ,表示当前路径,在当前路径中寻找Dockerfile文件。
> 这就引入了上下文的概念。当构建的时候,用户会指定构建镜像上下文的路径,docker build 命令得知这个路径后,会将路径下的所有内容打包,然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后,展开就会获得构建镜像所需的一切文件。

- 关于上下文
>  如果在 Dockerfile 中这么写:
```COPY ./package.json /app/```
这并不是要复制执行 docker build 命令所在的目录下的 package.json,也不是复制 Dockerfile 所在目录下的 package.json,而是复制 上下文(context) 目录下的 package.json。
因此,COPY 这类指令中的源文件的路径都是相对路径。这也是初学者经常会问的为什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因,因为这些路径已经超出了上下文的范围,Docker 引擎无法获得这些位置的文件。如果真的需要那些文件,应该将它们复制到上下文目录中去。
现在就可以理解刚才的命令 docker build -t nginx:v3 . 中的这个 .,实际上是在指定上下文的目录,docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。
如果观察 docker build 输出,我们其实已经看到了这个发送上下文的过程:

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...

理解构建上下文对于镜像构建是很重要的,避免犯一些不应该的错误。比如有些初学者在发现 COPY /opt/xxxx /app 不工作后,于是干脆将 Dockerfile 放到了硬盘根目录去构建,结果发现 docker build 执行后,在发送一个几十 GB 的东西,极为缓慢而且很容易构建失败。那是因为这种做法是在让 docker build 打包整个硬盘,这显然是使用错误。
一般来说,应该会将 Dockerfile 置于一个空目录下,或者项目根目录下。如果该目录下没有所需文件,那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎,那么可以用 .gitignore 一样的语法写一个 .dockerignore,该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。
那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢?这是因为在默认情况下,如果不额外指定 Dockerfile 的话,会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。
这只是默认行为,实际上 Dockerfile 的文件名并不要求必须为 Dockerfile,而且并不要求必须位于上下文目录中,比如可以用 -f ../Dockerfile.php 参数指定某个文件作为 Dockerfile。
当然,一般大家习惯性的会使用默认的文件名 Dockerfile,以及会将其置于镜像构建上下文目录中。

你可能感兴趣的:(关于docker的基本使用)