docker 和 dockerFile 介绍

最近用到了dockerFIle来构建镜像。在这之前，其实并不太清楚docker的作用，并不清楚容器和镜像的比较清晰的概念。于是在这里记录一下。

docker介绍

首先我们需要先了解虚拟化技术。

比如虚拟机，可能大部分人都用过虚拟机，虚拟机（VM）是一种创建于物理硬件系统、充当虚拟计算机系统的虚拟环境，它模拟出了自己的整套硬件，包括 CPU、内存、网络接口和存储器。

在虚拟机里，你可以和正常电脑一样运行程序，例如下载软件等。

虚拟机属于虚拟化技术。 而docker提供的容器技术，就属于轻量级的虚拟化。

它们本质的区别在于：虚拟机是操作系统级别的资源隔离，而容器是进程级别的资源隔离。

相比较虚拟机，容器化的优势显而易见：

硬件成本低；
部署环境更快；
维护环境更便捷；

容器只需要虚拟一个小规模的环境。而dokcer就是创建容器工具。

所以，近年来，由于docker的开源以及众多优点，使得它越来越受人追捧。

docker的三大概念

Docker技术的三大核心概念，分别是：

镜像（Image）
容器（Container）
仓库（Repository）

我们先来看看docker的口号： build,ship and Run Any APP, Anywhere

不过今天看的时候，官方的页面改成了: build, share Run Any APP, Anywhere

也就是, 搭建、分享、运行。

怎么理解呢？举一个例子：

比如我们要建一个房子，就需要画图纸，搬木材，搭建。盖好之后，住了进去。

过来我突然想搬到另一个地方入住，并建一栋和以前的一样的房子，按以前的做法，我们需要继续画图纸，搬木材,搭建。

但是这时候，docker出来了，并告诉我说，我可以把你以前的房子变成 “镜像”， 然后复制一份一模一样的房子给你。

最后，docker以我以前的房子作为镜像，复制了一个同样的房子给我。让我直接拎包入住。

这里的镜像指的就是 docker 中的 镜像（Image），我用镜像 搭建出来的房子，指的就是 容器（Container）

实际中，这个Docker镜像，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

也就是前面提到的三大概念：

镜像（Image）
容器（Container）
仓库（Repository）

那么 仓库（Repository）又是什么呢？

也很好理解。不同的人会创造出不同的镜像，比如我创建了一个北京四合院的镜像，张三创建了一个蒙古包的镜像，李四创建出了一个别墅的镜像。

那我要想使用别人的镜像，应该怎么办呢？

于是仓库（Repository） 就出现了。

负责对Docker镜像进行管理的，是Docker Registry服务（类似仓库管理员）

这下子，通过仓库（Repository），我就可以搭建其他人的房子了。

这个仓库， 也就是是官方的Docker Hub，并拥有大量的高质量的官方镜像。

另外几个介绍：

container: 容器，是指image的运行时，包含了文件资源和系统资源
image: 镜像，是指将应用打包好之后的存储方式，一个image包含多层layer
layer: 在Dockerfile中每一步都会产生一层layer，每一步的结果产出变成文件
Dockerfile: 一种构建image的文件的DSL
docker: 可以通过Dockerfile构建image，也可以将image运行，使其变成container
docker-compose: Python写的一个docker编排工具

之前也使用过docker-compose，通过编写 docker-compose.yml文件，也可以很方便快捷的 docker-compose 帮助完成镜像的编排。

Dockerfile

这次用到了Dockerfile 来进行 image 镜像的构建。

官方文档： https://docs.docker.com/engin...

编写示例：

FROM node:14.16.0-stretch
ARG DING_TKON
RUN apt-get update
RUN apt install -y curl
RUN apt-get clean
COPY ./send-ding.sh /
CMD sh send-ding.sh -a ${DING_TKON} -t markdown -c pipeine运行成功 -T "title"

命令介绍：

FROM
格式为 FROM <image>或FROM <image>:<tag>。
定制的镜像都是基于FROM的镜像，例如 FROM nginx 就是定制需要的基础镜像，后续的操作都是基于nginx。

FROM node:14.16.0-stretch

RUN
<命令行命令>：等同于在终端操作的 shell 命令。在docker build期间执行。

RUN apt-get update

CMD
["<可执行文件或命令>","","",…]：在docker run 时运行。

CMD sh send-ding.sh -a ${DING_TKON} -t markdown -c pipeine运行成功 -T "title"

ENV
<key>=< value>：设置环境变量，定义了环境变量，那么在后续的指令中，就可以使用这个环境变量。在docker run 时运行。

ARG <key>=< value>：设置环境变量，环境变量只作用于Dockerfile内。在docker build期间执行。

ARG DING_TKON

COPY [–chown=:] <源路径1>… <目标路径> 复制指令，从上下文目录中复制文件或者目录到容器里指定路径。

COPY ./send-ding.sh

可以参考老师的文章将镜像放到阿里云上：https://segmentfault.com/a/11...

遇到的问题

gitlab-ci.yml中使用此image

workflow:
  rules:
    # only run on PR
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
variables:
  FF_USE_FASTZIP: "true"
# 设置步骤（步骤间串行）
stages:
  - unit-test
  - notify
  # - done
# 设置自动执行的管道名称
angular-test:
  # 前台使用docker来构建
  tags:
    - docker
  # 设置该管道属于的步骤，同步骤的管道并行执行
  stage: unit-test
  image: xxxx
  before_script:
    - cd web
  script:
    - pwd
    - npm install
    - npm run test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
success-notify:
  # 前台使用docker来构建
  tags:
    - docker
  # 设置该管道属于的步骤，同步骤的管道并行执行
  stage: notify
  variables:
    DING_TKON: xxxx
  image: xxxx
  script:
    - env

error-notify:
  # 前台使用docker来构建
  tags:
    - docker
  # 设置该管道属于的步骤，同步骤的管道并行执行
  stage: notify
  image: xxx
  script:
    - env
  when: on_failure

目的： 传钉钉toekn 参数到 dockerFile中，dockerFile 接收该参数，执行上传好的脚本。使得gitlab执行该管道的时候，构建该image的时候就自动执行这个脚本。

所写的dockerFile: