Automatically Deploying Frontend Projects with GitLab CI/CD
Preface I previously wrote a series of posts on GitLab installation and usage as well as GitLab CI/CD configuration and usage, and I've already set up continuous integration for the AspNetCore backend projects. After tasting the benefits, I now want to add automated deployment for frontend projects as well, so after some tinkering, this article came about~ Previous articles: GitLab Installation, Configuration, and Usage Continuous Integration Guide: GitLab CI/CD Tool Configuration and Usage Similar to how I handled the AspNetCore projects before, I still use docke
目录7 个章节
Preface
I previously wrote a series of posts on GitLab installation and usage as well as GitLab CI/CD configuration and usage, and I've already set up continuous integration for the AspNetCore backend projects. After tasting the benefits, I now want to add automated deployment for frontend projects as well, so after some tinkering, this article came about~
Previous articles:
- GitLab Installation, Configuration, and Usage
- Continuous Integration Guide: GitLab CI/CD Tool Configuration and Usage
Similar to how I handled the AspNetCore projects before, I still use Docker for deployment, independent of the server environment—just convenient and elegant~
Docker Configuration
This was my first time using Docker to build a frontend project, and I ran into many pitfalls, but I eventually got it working by referring to my previous DjangoStarter project and the AspNetCore Dockerfile~
The idea is two containers: one Node container to compile the project, and another Nginx to serve static files. In other words, after I build the project, I provide the web service directly inside the container, instead of copying it out and putting it into a shared Nginx on the server.
Then I set up forwarding in the server's Nginx, so the experience is the same as before. (Or you can use it directly without forwarding, depending on the actual situation.)
Using Nginx in Docker is better—this shows in aspects such as configuration complexity, permission management, security/audit checks, and the like. I won't elaborate; just use it and you're done~
Dockerfile
FROM node:lts-alpine as build
RUN mkdir /code
WORKDIR /code
ADD package.json /code
RUN npm install --registry=http://registry.npmmirror.com
ADD . /code
RUN npm run build
FROM nginx:alpine as final
LABEL maintainer="DealiAxy <feedback@deali.cn>"
COPY --from=build /code/dist/ /usr/share/nginx/html/
EXPOSE 80
Note that the COPY inside the Nginx container must have the --from parameter set, otherwise it won't be able to read the files built in the node container~
Once done, this Dockerfile is fixed, and you won't need to modify it in the future unless there are special circumstances~
docker-compose.yml
Not much to say. Actually this compose file can be omitted; I just don't want to type docker commands and am being lazy~
version: '3.4'
services:
web:
restart: always
build:
context: .
ports:
- "8080:80"
GitLab CI Configuration
Nothing special
variables:
GIT_STRATEGY: none
stages:
- deploy
deploy_job:
stage: deploy
only:
- master
script:
- cd /home/gitlab-runner/projects/0_frontend/dashboard-front
- rm -rf dashboard-front
- git clone http://127.0.0.1:8080/deali/dashboard-front.git
- cd dashboard-front
- docker-compose up --build -d
Summary
All set. The first time I did this I still ran into many pitfalls, but luckily I didn't give up and then solved the problems step by step.
After that, for each project you only need to modify the docker-compose.yml file to specify the exposed port and the .gitlab-ci.yml file to specify the folder to build. Much more convenient than the original manual build and publish.
References
Note: The Dockerfile in this reference article is wrong; please follow this article.
Setting aside the errors, there are still some parts of this reference article that can be useful—please verify them yourself~
- Deploying frontend applications with Docker: https://zhuanlan.zhihu.com/p/102853707
_EOF_
Automatically Deploying Frontend Projects with GitLab CI/CD
- 本文作者:
- 程序设计实验室
- 版权声明:
- 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
相关文章
关于DevOps
前天写了Gitlab安装配置的文章,把之前在Gitee企业版上的大部分项目迁移到本地Gitlab管理,用着还不错~ 随着项目的规模逐渐变大以及手头上开发维护的项目逐渐变多,DevOps的重要性也逐渐凸显,目前我们开发、测试和部署的流程还是相对原始,意识到这点之后我开了一个新的博客分类(DevOps),边学边记录~ https://zh.m.wikipedia.org/zh-sg/DevOps
2022-07-21 · DevOps · 约 1 分钟
code-porter 代码工作区迁移工具
换电脑几十个项目手动拷?你不是懒就是蠢。写了code-porter,自动扫描、智能打包(bundle/zip),脏仓库也能保留未提交改动,一行uvx搞定。零依赖跨平台,U盘一插完事。别问我为什么不用rsync——它懂你项目结构?
2026-05-22 · DevOps · 约 1 分钟
极大提高项目部署的生产力!分享一个半自动化的CICD实现方案
半自动CICD?听起来就像是对完全自动化方案的妥协。用脚本一键发布,还真能省事,不过得忍受服务器内网访问等麻烦。国内环境下的CI/CD,果然还是得自己想办法。
2025-07-11 · DevOps · 约 1 分钟
lighthouse-fw:一个管理腾讯云轻量服务器防火墙的终端工具
公网IP一换手动改防火墙?这效率也配叫程序员? 一个增量diff引擎+系统钥匙串+TUI/CLI双模,443行重构包完事。 uvx直接跑,别告诉我还要pip install。
2026-05-02 · DevOps · 约 1 分钟
讨论
共 0 条加载评论中…