What is Continuous integration?
CI
In a continuous integration environment, developers will frequently have to commit code to the trunk. These new commits need to be verified by compilation and automated tests before they are finally merged into the mainline. This is based on the previous continuous integration process attaches great importance to automated test verification results, in order to ensure that all the submitted quality problems after merging the trunk, and to anticipate some problems that may occur.
Continuous Delivery
Continuous delivery is the process by which we have to ship the application. This process ensures that we deliver as quickly as possible. This means that in addition to automated testing, we need an automated release flow and an application that can be deployed anywhere at the click of a button
With continuous delivery, you can decide to publish every day, every week, every two weeks, which is completely customized for your business.
However, if you really want to experience the benefits of continuous delivery, you need to launch in small batches first and deploy to the production line as quickly as possible so you can troubleshoot problems when they occur.
Continuous Deployment
If we want to go further, it’s continuous deployment. In this way, any changes that go through all existing workflows are directly addressed to the customer. There is no human intervention (no one-click deployment button) and only if a change fails to build in the workflow can it be prevented from being deployed to the product line.
Continuous deployment is a great way to speed up the feedback loop with the customer, but it puts pressure on the team because there is no “release day” anymore. Developers can focus on building the software, and they see their modifications coming online a few minutes after they finish their work. Basically, when a developer merges a commit in the main branch, the branch is built, tested, and if all goes well, deployed into production.
Continuous integration requirements
- Continuous integration (CI) is a method to automate and precipitate work by connecting various development steps together on a platform.
- Online code is out of sync with the repository, affecting iteration and team collaboration.
- Static resource publishing relies on manual labor and wastes development effort.
- Lack of automated testing, product quality is not guaranteed
- Copy simple modification online, need technical intervention.
Gitlab
Gitlab is an open source version management system that implements a self-hosted Git project repository that allows access to public and private projects via a Web interface. It has similar features to Github, the ability to browse source code, manage defects and comments, manage team access to the repository, make it very easy to browse submitted versions and provide a file history library. Team members can communicate using a simple built-in chat program. It also provides a snippet collection feature for code reuse.
GitLab has requirements for system performance, so we need to increase the memory of the cloned VIRTUAL machine to at least 2 gb.
Gitlab installation
Method one:
sudo docker run --detach \
--hostname localhost \
--publish 443:443 --publish 8084:8084 --publish 222:22 \
--name gitlab \
--restart always \
--volume /home/docker/gitlab/config:/etc/gitlab \
--volume /home/docker/gitlab/logs:/var/log/gitlab \
--volume /home/docker/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
Copy the codeLocalhost: indicates the host name, that is, the IP address of the VM. 8084 Specifies the port number. Restart Restart mode,volume directory mounting,gitlab/gitlab-ce:latest image name.
Method 2:
docker pull twang2218/gitlab-ce-zh
Copy the codeWait for it to pull, then create a docker directory under /home, and then create a gitlab directory under it, enter the gitlab directory, and create a docker-comemess. yml configuration file under the current directory, and write the following content:
version: '3'
services:
web:
image: 'twang2218/gitlab-ce-zh'# gitlab mirrorrestart: always
privileged: true# permissionshostname: ' 'The host name is the IP address of the VMenvironment:
TZ: 'Asia/Shanghai'
GITLAB_OMNIBUS_CONFIG: |
external_url ' 'Gitlab_rails ['gitlab_shell_ssh_port'] = 2222
unicorn['port'] = 8888
nginx['listen_port'] = 8084
ports:
- '8084:8084'
- '8443:443'
- '2222:22'
volumes:
- './config:/etc/gitlab'
- './logs:/var/log/gitlab'
- './data:/var/opt/gitlab'
Copy the codeDocker-compose up, and wait for the docker-compose to be ready for the virtual machine’s IP and port number.
If there is an error with privileged during installation, then add privileged: true
Viewing Mode:
root@iZm5ebvlfc3n55vzckl9ifZ:# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ddc7d0e214ef twang2218/gitlab-ce-zh "/assets/wrapper" 30 hours ago Up 6 hours (healthy) 80/tcp, 0.0. 0. 0:8084->8084/tcp, 0.0. 0. 0:2222->22/tcp, 0.0. 0. 0:8443->443/tcp gitlab_web_1
Copy the codeIf you use the IP address and port number of the virtual host to access the vm, set the administrator password to root and the password must contain at least eight characters.
After a successful login, the following information is displayed:
Project creation
Click the + sign –> New project
Enter the project name and description and set the visibility level: private, internal, and public.
Initialize the project
We can optionally initialize the project by adding a README as follows:
There was a problem when creating the project. When I defined the port number at the beginning of the project, there would be no port number when creating the project, so I could not access the clone project. At this time, we found gitlab.rb in the config directory of the initial installation definition directory, edited it, searched for external_url, If no, add external_URL: host IP address + port number. That’s when we can go clone. Of course, we can also push the project to gitLab through the following methods:
Gitlab-Runner
The installation
sudo docker run -d --name gitlab-runner --restart always \
-v /home/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest
Copy the codeSock is mapped so that the container can communicate with the docker daemon through /var/run/docker.sock. Manage other Docker containers – v/home/gitlab – runner/config: / etc/gitlab – runner is mapped to the host machine will runner configuration file/home/gitlab – runner/config convenient adjustment and check the configuration
After installation, we need to register gitlab-Runner.
Run docker PS to view:
root@iZm5ebvlfc3n55vzckl9ifZ:/home/docker/gitlab# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ed6c7a038263 gitlab/gitlab-runner:latest "/ usr/bin/dumb - init..." 24 hours ago Up 24 hours gitlab-runner
ddc7d0e214ef twang2218/gitlab-ce-zh "/assets/wrapper" 30 hours ago Up 6 hours (healthy) 80/tcp, 0.0. 0. 0:8084->8084/tcp, 0.0. 0. 0:2222->22/tcp, 0.0. 0. 0:8443->443/tcp gitlab_web_1
Copy the coderegistered
docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
--non-interactive \
--executor "docker" \
--docker-image alpine:latest \
--url "" \
--registration-token "" \
--description "first-register-runner" \
--tag-list "vue3-app" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"
Copy the codeRegistration requires the output of url, token, description, tag, actuator, etc. In Settings ->CI/CD->Runner, I registered a dedicated and shared Runner, normally we use dedicated Runner. The shared version of Runner is to log in to the root account in the head of the small wrench picture inside the Runner gets the URL and token, and then to register. These tag values will be used when writing.gitlab-ci.yml.
Running line
Create a.gitlab-ci.yml file in the project root directory and write the following code:
image: node:alpine
stages: # section-install-eslint-build-deploycache: # cachepaths:
- node_modules
job_install:
tags:
- vue3-app
stage: install
script:
- npm install
job_build:
tags:
- vue3-app
stage: build
script:
- npm run build
Copy the codeParameter Description:
- Stages: A list of stages of a pipeline that defines the entire pipeline phase
- Stage: Defines the stage of a job
- Image: Specifies a base Docker to use as the base runtime environment, such as Node, Python, Java
- Tags: Used to specify Runner. The value range of tags is in the Runner tags visible in the project, which is the previous tag we set
- Only /except: knows the current task condition
- When: Implements a job that can run in the event of a failure
- Cache: Refers to the files in the current working environment directory. The folders are stored and used for recovery during the initialization of each task
- Environment: Specifies the environment where related tasks will be deployed. It is not a real environment but a classification of tasks to be deployed in an environment. Easy aggregation on GitLab for rollback and redeployment operations
- Artifacts: Preserve the document. Runner clears files that are not tracked by Git before each job. To allow the compiled or other operations to be retained for later use, add this parameter and set the directory to be retained, for how long, and so on. Retained files will be uploaded to GitLab for future use.
- Dependencies: Task dependencies. Specify the pre-job of the job. After this parameter is added, you can obtain the artifacts for the preloaded job. Notice If the preceding job fails to be executed, the artifacts cannot be generated, and the job also fails.
After writing the above code and pushing it to GitLab, it will execute the statement inside itself:
The deployment of
Create a Dockerfile in your project as follows:
FROM node:latest as builder
WORKDIR /app
COPY package.json
RUN npm install --registry=http://registry.npm.taobao.org
COPY ..
RUN npm run build
FROM nginx:latest
COPY --from=builder /app/dist /usr/share/nginx/html
Copy the code.gitlab-ci.yml modified as follows:
image: node:alpine
stages: # section-install-eslint-build-deploycache: # cachepaths:
- node_modules
job_install:
tags:
- vue3-app
stage: install
script:
- npm install
job_build:
tags:
- vue3-app
stage: build
script:
- npm run build
job_deploy:
image: docker
stage: deploy
script:
- docker build -t appimages
- if[ $(docker ps -aq --filter name=app-container) ]; then docker rm -f app-container; fi - docker run -d -p8082:80 --name app-container appimages
Copy the codeUse the docker command to check whether there is an app-container in the docker container. If there is an app-container in the docker container, destroy it so that the new container can be run again.
Image :docker error:
After the code push, the assembly line work, to the third step will be the next error:
Docker command in the runner configuration file:
"/usr/bin/docker:/usr/bin/docker"."/var/run/docker.sock:/var/run/docker.sock"
Copy the codeRun the gitlab-runner->config-vim config.toml command to add volumes to the volumes array.
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "first-register-runner"
url = ""
token = ""
executor = "docker"[runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.cache.azure] [runners.docker] tls_verify =false
image = "alpine:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"."/usr/bin/docker:/usr/bin/docker"."/var/run/docker.sock:/var/run/docker.sock"]
shm_size = 0
Copy the codeWe went to re-run the failed Jobs and found success:
Then access the project through the previously registered port number.