Dockerize Vue.js 应用程序
简单示例
因此,您使用令人惊叹的 Vue.js webpack 模板 构建了您的第一个 Vue.js 应用程序,现在您真的想通过向同事展示您也可以在 Docker 容器中运行它来炫耀一下。
让我们从在项目的根文件夹中创建一个 Dockerfile
开始
|
首先复制 package.json
和 package-lock.json
,然后在两个单独的步骤中复制所有项目文件和文件夹,这似乎是多余的,但实际上 有一个很好的理由(剧透:它允许我们利用缓存的 Docker 层)。
现在让我们构建 Vue.js 应用程序的 Docker 镜像
|
最后,让我们在 Docker 容器中运行 Vue.js 应用程序
|
我们应该能够在 localhost:8080
上访问我们的 Vue.js 应用程序。
真实世界示例
在前面的示例中,我们使用了一个简单的、零配置的命令行 http 服务器 来提供我们的 Vue.js 应用程序,这对于快速原型设计来说是完全可以的,而且对于简单的生产场景来说也可能没问题。毕竟,文档中说
它功能强大,足以用于生产环境,但它足够简单且可破解,可用于测试、本地开发和学习。
然而,对于现实中复杂的生产用例,可能明智的做法是站在像 NGINX 或 Apache 这样的巨人的肩膀上,而这正是我们接下来要做的:我们即将利用 NGINX 来提供我们的 Vue.js 应用程序,因为它被认为是最有效率和经过实战检验的解决方案之一。
让我们重构我们的 Dockerfile
以使用 NGINX
|
好的,让我们看看这里发生了什么
- 我们通过利用 Docker 的 多阶段构建 功能,将我们最初的
Dockerfile
分成了多个阶段; - 第一阶段负责构建 Vue.js 应用程序的生产就绪工件;
- 第二阶段负责使用 NGINX 提供此类工件。
现在让我们构建 Vue.js 应用程序的 Docker 镜像
|
最后,让我们在 Docker 容器中运行 Vue.js 应用程序
|
我们应该能够在 localhost:8080
上访问我们的 Vue.js 应用程序。
附加上下文
如果您正在阅读此菜谱,您很可能已经知道为什么您决定将 Vue.js 应用程序 dockerize。但是,如果您只是在点击 Google 的 我感觉很幸运
按钮后才来到此页面,请允许我与您分享一些这样做的充分理由。
当今的现代趋势是使用 云原生 方法构建应用程序,该方法主要围绕以下流行语展开
- 微服务
- DevOps
- 持续交付
让我们看看这些概念如何真正影响我们决定将 Vue.js 应用程序 dockerize。
微服务的影响
通过采用 微服务架构风格,我们最终将单个应用程序构建为一系列小型服务,每个服务都在自己的进程中运行并使用轻量级机制进行通信。这些服务围绕业务能力构建,并且可以通过完全自动化的部署机制独立部署。
因此,承诺这种架构方法通常意味着将我们的前端开发和交付为一个独立的服务。
DevOps 的影响
采用 DevOps 文化、工具和敏捷工程实践,除其他外,还具有很好的效果,可以提高开发和运维角色之间的协作。过去的主要问题(但如今在某些现实中仍然存在)是,开发团队倾向于对系统交付给运维团队后不感兴趣,而运维团队则倾向于不了解系统的业务目标,因此不愿意满足系统的运营需求(也称为“开发人员的怪癖”)。
因此,将我们的 Vue.js 应用程序交付为 Docker 镜像有助于减少(如果不是完全消除)在开发人员的笔记本电脑、生产环境或我们可能想到的任何环境中运行服务之间的差异。
持续交付的影响
通过利用 持续交付 纪律,我们以一种可以随时发布到生产环境的方式构建软件。这种工程实践是通过通常称为 持续交付管道 的方式实现的。持续交付管道的目的是将我们的构建拆分为阶段(例如,编译、单元测试、集成测试、性能测试等),并在我们的软件发生更改时让每个阶段验证我们的构建工件。最终,每个阶段都增加了我们对构建工件生产就绪性的信心,因此降低了在生产环境(或任何其他环境)中破坏事物的风险。
因此,为我们的 Vue.js 应用程序创建 Docker 镜像是一个不错的选择,因为这将代表我们的最终构建工件,与我们的持续交付管道验证的相同工件,并且可以自信地发布到生产环境。
替代模式
如果您的公司还没有使用 Docker 和 Kubernetes,或者您只是想尽快推出 MVP,那么将 Vue.js 应用程序 dockerize 可能不是您需要的。
常见的替代方案是
- 利用像 Netlify 这样的多合一平台;
- 将您的 SPA 托管在 Amazon S3 上,并使用 Amazon CloudFront 提供服务(有关详细指南,请参阅 此 链接)。