最近用到了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:
但是查了官网以及,谷歌了资料,查到的都是: 若想使用ARG 命令传参数,需要手动使用docker build
命令构建。
但是目前所使用的gitlab-ci.yml,只要传入 image 地址,就可以自动构建。不需要自己手动写docker build 命令。
之后又去gitlab 官方文档查看能不能传递参数。 结果没找到
目前pipeline 里面已经获取到了gitlab-ci.yml文件里定义的变量。下一步打算,想直接构建试试, 看看dockerFile 里面 能不能直接获取到 管道里面的环境变量
参考:
https://blog.csdn.net/qq_3359...
https://zhuanlan.zhihu.com/p/...
https://docs.docker.com/engin...