Docker容器和镜像的关系
这周遇到的一个问题是:公司内部的持续集成系统要迁移到另外JDOS上，在测试部署的时候发现这套系统目前并不支持前端静态资源的部署。因为提供的gen-nginx镜像无法将静态资源挂载到正确的目录下。同时后台显示容器运行正常，但实际上容器运行存在其他问题。
个人理解的这个新的持续集成系统有些类似于用Docker进行部署。用Docker部署前端资源的流程大致这两步：
- 写个Dockerfile。
通常会写个Dockerfile文件，先从node上拉取一个node镜像。然后将前端资源复制到容器对应的目录下。
# 拉取镜像
FROM node:12
# 创建容器目录 -p 表示递归
RUN mkdir -p /home/app
WORKDIR /home/app
# 复制资源到对应目录
COPY . /home/app
RUN npm install
RUN npm run build
- 构建镜像
构建镜像的命令如下：
代码语言：javascript复制docker build -t name .
后面的.符号是必须带上的，它是用来指定镜像构建过程中的上下文环境目录的。
- 启动容器
启动容器的命令如下:
代码语言：javascript复制docker run -d --name test -p 80:4000 mirrorName
-d表示容器在后台运行；--name是容器名称；-p将容器的4000端口映射到主机的80端口。
这样就可以通过服务器IP进行访问了。
镜像和容器的关系，个人理解的是：镜像是某个东西的副本，比如一个node镜像就是Node的一个副本，拿过来可以直接使用。容器是镜像运行后的一个实例，比如运行一个nginx的容器，可以根据nginx的镜像运行多个容器。
在沟通的过程中又聊到了两个概念：堡垒机和跳板机。前端的同学大部分对这两个东西没什么概念，这里简单科普一下。
堡垒机
堡垒机，也叫做运维安全审计系统，它的核心功能是 4A：
- 身份验证 Authentication
- 账号管理 Account
- 授权控制 Authorization
- 安全审计 Audit
简单总结一句话：堡垒机是用来控制哪些人可以登录哪些资产（事先防范和事中控制），以及录像记录登录资产后做了什么事情（事后溯源）。
其实就是说你有没有权限登录某台服务器。加入你需要登录服务器的权限，比如你要登录某台服务器上去配置个nginx什么的，就找对应的人申请个权限完事儿。
跳板机
跳板机属于内控堡垒机范畴，是一种用于单点登陆的主机应用系统。
2000年左右，高端行业用户为了对运维人员的远程登录进行集中管理，会在机房里部署跳板机。跳板机就是一台服务器，维护人员在维护过程中，首先要统一登录到这台服务器上，然后从这台服务器再登录到目标设备进行维护。但跳板机并没有实现对运维人员操作行为的控制和审计，使用跳板机过程中还是会有误操作、违规操作导致的操作事故，一旦出现操作事故很难快速定位原因和责任人。
此外，跳板机存在严重的安全风险，一旦跳板机系统被攻入，则将后端资源风险完全暴露无遗。同时，对于个别资源（如telnet）可以通过跳板机来完成一定的内控，但是对于更多更特殊的资源（ftp、rdp等）来讲就显得力不从心了。
