最近用到了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-stretchARG DING_TKONRUN apt-get updateRUN apt install -y curlRUN apt-get cleanCOPY ./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=ChromeHeadlessCIsuccess-notify:  # 前台应用docker来构建  tags:    - docker  # 设置该管道属于的步骤，同步骤的管道并行执行  stage: notify  variables:    DING_TKON: xxxx  image: xxxx  script:    - enverror-notify:  # 前台应用docker来构建  tags:    - docker  # 设置该管道属于的步骤，同步骤的管道并行执行  stage: notify  image: xxx  script:    - env  when: on_failure

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

所写的dockerFile:



然而查了官网以及，谷歌了材料，查到的都是： 若想应用ARG 命令传参数，须要手动应用docker build命令构建。



然而目前所应用的gitlab-ci.yml,只有传入 image 地址，就能够主动构建。不须要本人手动写docker build 命令。



之后又去gitlab 官网文档查看能不能传递参数。 后果没找到




目前pipeline 外面曾经获取到了gitlab-ci.yml文件里定义的变量。下一步打算，想间接构建试试， 看看dockerFile 外面 能不能间接获取到 管道外面的环境变量