Front-end automated build deployment (CI/CD) process based on GitLab+ Docker

What is CI/CD?

CICD stands for Continuous Integration and Continuous Deployment. The automatic execution of a series of scripts during the development process to reduce the probability of introducing bugs and minimize human intervention in the process of new code from development to deployment.

Continuous integration: CI

Continuous integration refers to the process of running a series of tests, builds, and so on after pushing code to a remote repository and before the commit merges into the main branch. Let’s say you have an application code stored in GitLab that developers push many times a day. For each push, you can create a series of scripts to automate testing, reducing the chance of introducing errors into your application. This is continuous integration, and it can be applied across multiple branches, including the development branch.

Continuous deployment: CD

Continuous deployment takes continuous integration one step further by pushing the deployment of the default branch of the repository to the production environment. If this part needs to be triggered manually, it is a Continuous Delivery link. Gitlab has CICD tools built in, so there is no need to use third-party tools, so we use Gitlab-CI and GitLab-Runner to complete our front-end automated build deployment

Realize the principle of

The front-end release process is based on Gitlab-CI and Gitlab-Runner. Currently, the running environment of Runner is Docker, which ensures that there will be no conflict between development versions of projects. The front-end package files after packaging are synchronized to static resource files through Rsync. Automate the release process by listening for master (production) and dev (development) changes.

The flow chart

1. First deploy the project with Docker +nginx

1. Docker pull nginx download nginx 2. Create HTML, conf, conf.d folders under /data /nginx. Conf: nginx. Conf: default.conf: nginx. Nginx default.conf and nginx default.conf need to be configured by themselves.

server {
  listen       80;
  server_name  localhost;

  #charset koi8-r;
  #access_log /var/log/nginx/host.access.log main;

  location / {
    root   /usr/share/nginx/html;
    indexindex.html index.htm; }}Copy the code

Nginx nginx.conf configuration:

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
  worker_connections  1024;
}
http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;

  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
  '$status $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';

  access_log  /var/log/nginx/access.log  main;

  sendfile        on;
  #tcp_nopush on;

  keepalive_timeout  65;
        gzip on;
        gzip_disable "msie6";
        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 1;
        gzip_buffers 16 8k;
        gzip_http_version 1.0;
        gzip_min_length 256;
        gzip_types text/plain text/css
                   application/json application/x-javascript text/xml
                   application/xml application/xml+rss text/javascript application/javascript
                   application/vnd.ms-fontobject application/x-font-ttf font/opentype 				    image/svg+xml image/x-icon
                   image/jpeg image/gif image/png;


  include /etc/nginx/conf.d/*.conf;
}

Copy the code

4. After all files are created, run the command

Docker run container name - the name * * - p 8088-80 - v/data/nginx/HTML: / usr/share/nginx/HTML - v / data/nginx/conf/nginx. Conf: / etc/nginx/nginx. Conf - v/data/nginx/log: / var/log/nginx - d nginx: 1.13 mirror (name)Copy the code

Common docker instruction operation: –name named container, -p mapping port such as 8088:80, -v mapping the current folder to the folder in the image, -d background run container, docker ps -a view container, docker images -a view all images, Docker RM container ID Delete container, Docker RMI image ID delete image, Docker start container ID run container, docker stop container ID Stop container

At this point, the Docker + Nginx deployment front end project is completed, and the next step is to configure the automated build release

2. Fill in the CI/CD configuration of the project newly created by GitLab with relevant information to be published to the server

2.2 Perform the following operations on the server to configure the Encryption-free Login

Production key pair: Ssh-keygen -t rsa, configure the secret-free login between gitLab server and front-end code server as follows: SSH Run the ssh-keygen -t rsa command. Two files id_rsa and id_rsa.pub are generated

cd .ssh
ssh-keygen -t rsa
Copy the code

Copy the contents of id_rsa.pub to authorized_keys

2.3 Install Gitlab-Runner on the server with Docker

Install gitlab-runner with Docker:

docker pull gitlab/gitlab-runner:latest
Copy the code

Stop and delete existing containers:

docker stop gitlab-runner && docker rm gitlab-runner
Copy the code

Create a startup container:

docker run -d --name gitlab-runner --restart always \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ gitlab/gitlab-runner:latest
Copy the code

View logs:

docker logs gitlab-runner
Copy the code

docker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
Copy the code

At this point the configuration is complete on the server

If you want to see your own Gitlab-Runner startup, you can enter docker ps -a to check

3. Create a.gitlab-ci.yml file under the project you want to publish, and let GitLab perform the automated process

// do cache
cache:
  key: ${CI_PROJECT_NAME}
  paths:
    - node_modules/
/ / test
# test_e2e:
# image: cypress/browsers:chrome67
# stage: test
# script:
# - npm i
# - npm run test:e2e -- --headless --record --key b2a22185-8eeb-4f0e-9b21-2d61f769d8c7
# only:
# - master
//dev environment build
dev:build:
  image: node
  stage: build
  script:
    - yarn
    - yarn build:dev
  only:
    - dev
  tags:
    - eye-runner
  artifacts:
    expire_in: 1 week
    paths:
      - dist // Project packaged folder
//dev The environment is released
dev:deploy:
  image: Alpine: 3.7
  stage: deploy
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_KEY_DEMO_PRIVATE" >> ~/.ssh/id_rsa
    - echo "$SSH_KEY_DEMO_PUB" >> ~/.ssh/id_rsa.pub
    - chmod 600 ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa.pub
    - echo -e "Host *\n\t StrictHostKeyChecking no \n\n" > ~/.ssh/config
    - rsync -rav --delete ./dist/ "$SERVER_DEMO_HOST:$SERVER_DEMO_PATH"// Synchronize the contents of the packed folder to the static resources folder specified by nginx
  only:
    - dev
  tags:
    - eye-runner

Copy the code

Submitting code triggers the CI/CD process

Then I can see the CI/CD task I just triggered in the CI/CD pipeline of gitLab project, as shown in the figure below

Click status or Stage to enter the build release details page to view the content

Release: the deploy

At this point, the job is done, and mom no longer has to worry about the time and mistakes I make publishing code online

Write in the last

Before deploying the front-end service, after modifying something, we had to manually package and upload the deployment, which was very uncomfortable and error-prone. Since I tried the automatic deployment, I have fallen in love with CI/CD. I am afraid of climbing pit for a long time, summed up this set, I hope to bring you some help, there is anything wrong in the document, welcome to correct, thank you ~