背景前言
任何一项技术的出现，必定有它的背景，解决了某些痛点，Docker也不例外。
传统的虚拟机，非常耗费性能
因此，Docker就应运而生了！
Docker是什么？
Docker可以创建一个虚拟环境容器，可以将你的开发环境、代码、配置文件等一并打包到这个容器中，并发布和应用到任意平台中。比如，你在本地用Python开发网站后台，开发测试完成后，就可以将Python3及其依赖包、Flask及其各种插件、Mysql、Nginx等打包到一个容器中，然后部署到任意你想部署到的环境。
大家需要注意，Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。是用来实现容器化技术的一种工具，也是目前业界最通用的一种方式，来帮我们制作镜像，然后把镜像运行成为容器并管理起来。
传统的虚拟机和Docker容器的区别
容器它为什么轻量、高性能。通过下面这张图片，我们可以将虚拟机和容器进行一个更加直观的对比：
- 虚拟机通过在物理服务器上层通过运行
Hypervisor模拟硬件系统，来提升服务器的能力和容量。每个虚拟机中有一个内核，运行着不同的操作系统，启动之后会做进程管理、内存管理之类的事情。但对于前端应用的构建来说，可能只是需要一个 Nginx 做静态服务器，这种场景下使用虚拟机就太重了。 - 容器之所以轻量，是因为容器没有 Hypervisor 层和内核层，每个容器都共享宿主机的内核和系统调用。因此一个容器内包含的仅仅是一个程序运行所需要的最少文件，启动容器就是启动进程，对资源的开销更小，维护起来更简单。
因此通俗来讲，Docker可以看成一个高性能的虚拟机
Docker的三个概念
镜像（Image）
类似于虚拟机中的镜像。任何应用程序运行都需要环境，而镜像就是用来提供这种运行环境的。例如一个Ubuntu镜像就是一个包含Ubuntu操作系统环境的模板，同理在该镜像上装上Apache软件，就可以称为Apache镜像。
说白了，这个Docker镜像，是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
仓库Repository）
类似于代码仓库，这里是镜像仓库，是Docker用来集中存放镜像文件的地方。
容器Container）
类似于一个轻量级的沙盒。容器是基于镜像来创建的，ubuntu镜像并不能和我们进行各种交互，我们希望有个环境能运行ubuntu，于是基于ubuntu镜像创建了一个容器。Docker引擎利用容器来运行、隔离各个应用。容器是镜像创建的应用实例，可以创建、启动、停止、删除容器，各个容器之间是是相互隔离的，互不影响。
注意：镜像本身是只读的，容器从镜像启动时，Docker在镜像的上层创建一个可写层，镜像本身不变。也就是说容器 = 镜像 + 读写层。
我们可以这样类比：
# 下载源代码
git clone deepred5/app
# 启动app
npm run start
# 拉取镜像
docker pull deepred5/app
# 创建容器
docker run deepred5/app
前端为什么要用 Docker ?
这里只讨论使用 Docker 给前端带来的优势，偏运维相关的比如启动速度快，资源利用率高等略过，有兴趣的同学可以上官网看看文档。
一般来说前端的开发流程是这样的：创建服务/项目 → 本地开发 → 开发环境测试 → 生产环境测试 → 生产灰度 → 上线。
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
基于容器化平台进行前端开发的优势在于，前端和后端完全分离，我们只需要关注前端的项目构建，而不需要和后端代码一起打包。每个构建版本及每个访问规则也都是独立的，一个版本构建失败并不影响其他版本的构建及访问。
提供一致的开发-线上运行环境
在任何环境下使用 Docker 构建的镜像的运行环境都是确定的，Docker 给应用提供了一个从开发到上线均一致的环境。比如 Node.js 项目在不同版本下性能表现不一致，开发环境用的是 Node.js 6，UAT 环境用了 Node.js 10，那么很可能接口的压测结果不一致。
更轻松的平台迁移
由于 Docker确保了运行环境的一致性，使得应用的迁移更加容易。可以很轻易将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行。比如接到任务说下周要加一个分区，或者客户要求部署私有云，可以很放心的说镜像拿走，而不用担心环境问题。
持续交付和部署(CI/CD)
代码从开发到最终在生产环境上的部署，需要经过很多中间环境，通过定制应用镜像来实现持续集成、持续交付，非常有助于降低构建持续交付流程的复杂程度。在中小型公司可以考虑直接使用 GitLab CI 搭建持续集成环境。
通过 Docker 加速应用管道自动化和应用部署，交付速度提高至少 13 倍。
现代化开发流程快速、持续且具备自动执行能力，最终目标是开发出更加可靠的软件。通过持续集成 (CI) 和持续部署 (CD)，每次开发人员签入代码并顺利测试之后，IT 团队都能够集成新代码。作为开发运维方法的基础，CI/CD 创造了一种实时反馈回路机制，持续地传输小型迭代更改，从而加速更改，提高质量。CI 环境通常是完全自动化的，通过 git 推送命令触发测试，测试成功时自动构建新镜像，然后推送到 Docker 镜像库。通过后续的自动化和脚本，可以将新镜像的容器部署到预演环境，从而进行进一步测试。
快速部署、回滚
得益于 Docker 使用的分层存储和镜像技术，使得扩展镜像变得非常简单。可以预先把程序需要的依赖，静态资源等在构建过程中添加到镜像，在需要的时候启动该容器实现快速部署、回滚、止血。比如当出现线上事故需要回滚时，传统做法是触发某些自动化工具去拉代码装依赖打包最后部署，一旦某个环节出了问题，譬如网络被墙了导致依赖拉不下来，构建失败等等，小事故可能会演变为 P0 事故。
Docker在前端的实践
Loading...
