navigation

[react] Hooks

[React from zero practice 01- background] code split [React from zero practice 02- background] permission control [React from zero practice 03- background] custom hooks [React from zero practice 04- background] docker-compose Deploy React + Egg +nginx+mysql [React From zero practice 05- background] Gitlab-CI using Docker automated deployment

[source code – Webpack01 – precompiler] AST abstract syntax tree [source code – Webpack02 – Precompiler] Tapable [source code – Webpack03] hand written webpack-compiler simple compilation process [source code] Redux React-redux01 [source] Axios [source] vuex [source -vue01] Data reactive and initialize render [source -vue02] Computed responsive – Initialize, access, Update Procedure [source -vue04] Watch Listening properties – Initialize and update [source -vue04] vue. set and vm.$set [source -vue05] vue.extend

Vue. NextTick and VM.$nextTick

[Deployment 01] Nginx [Deployment 02] Docker deployVue project [Deployment 03] gitlab-CI

[Deep 01] Execution context [Deep 02] Prototype chain [Deep 03] Inheritance [Deep 04] Event loop [Deep 05] Curri Bias function [Deep 06] Function memory [Deep 07] Implicit conversions and operators [Deep 07] Browser caching mechanism (HTTP caching mechanism) [Deep 08] Front-end security [Deep 09] Deep copy [Deep 10] Debounce Throttle [Deep 10] Front-end routing [Deep 12] Front-end modularization [Deep 13] Observer mode Publish subscribe mode Bidirectional data binding [Deep 14] Canvas [Deep 15] webSocket Webpack HTTP and HTTPS CSS- Interview Handwriting Promise algorithms – Find and sort

(1) Pre-knowledge

(1) Some words

Appropriate to obtain a token // obtain a token section specific process (A Runner is active and can process any new jobs -------) cluster: You can easily install a Runner on a Kubernetes cluster. You can easily install runner in k8S cluster.) Manually n /n automatically deny // adj => denied structure: The. Gitlab-ci. Yml file defines The structure and order of The Pipelines, and determines The space between them. ) A simple pipeline commonly has three stages A simple pipeline usually has three stages. Let's first explain in brief what this is all about. Faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful, faithful 1) General seting: Advanced placement placement: Advanced placement placement: Wide range of advanced placement placement options Shallow clone: The job is stuck, check runners // the job is stuck. -Chuck: Pause the schedule in parallel above. // If anything of the above rings a bell // SSH key pair Verify: Verify Make sure the private server's SSH host keys are verified. // Verify: Verify the private server's SSH host keys are verified. // Configuration entries that this job inherits from. This job inherits configuration items: compress: compress general: The total -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- line -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the general: // Git commit -- no-verify-m "jump" advanced: git commit -- no-verify-m "jump" advanced: git commit -- no-verify-m "jump" advanced: Maintainer: Developer reporter guest: Stable // Keep stable branches secure Owner: maintainer Visitors -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- line 2021/06/15 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- slug slacking offCopy the code

(2) Some Linux commands

  • SCP command article
(2) The scp-scp command is used to copy files and directories. - SCP stands for secure copy. - Syntax: -scp [Optional] file_source file_target -scp -r file_source file_target - -r indicates recursive replication. R stands for Recursive recursion (recursive: Recursive) - copy from local to remote SCP local_file remote_IP :remote_folder SCP local_file remote_username@remote_ip:remote_folder specifies the username Copy local_file from local to remote_folder on remote server (Important: SCP local_file remote_usename@remote_ip:remote_folder this command will be used in the.gitlab-ci.yml file. Rm: Cannot delete authorized_keys: Chattr -i authorized_keys chattr -a authorized_keys chattr -u authorized_keys Rm -rf authorized_keys (4) > and >> : > will be overwritten before the contents of > > is additional, will not overwrite memory: > > is an additional more than > and > so less cover (5) && : said the imperative sentence before, when performing a success to execute a command after | | : said previous command execution fails, to execute a command after & : said task execution | in the background: Said the pipeline, the output of the previous command, as the next command parameters (6) the cat index. TXT | tr "ABC" "ABC" / / the above command said: Select * from index.txt where "a" = "a", "b" = "b", "c" = "c", "c" = "c", "c" = "c", "c" = "c", "c" = "c", "c" = "c", "c" = "c", "c" = "c", "c" = "c" / / | said in front of the output of the command as the back command parametersCopy the code

(3) sshpass a non-interactive SSH tool

  • Sshpass is a simple, lightweight, non-interactive SSH command line tool.
  • Yum install -y sshpass
  • Install: apt-get install -y sshpass
  • Common operations are as follows
1. Connect to the local host sshpass -p XXXX SSH xxx@xxx sshpass -p {password} SSH {user name}@{host IP address} 2. Connect the remote host sshpass -p {password} SSH -p {port number} {user name}@{host IP address} 3. Sshpass -f {password text file} SSH {username}@{host IP} 4. Copy directory from remote host to local!! Sshpass -p {password} SCP {username}@{host}:{remote directory} {local directory or file} 5. Copy from local to remote!! (This is important because we need to copy the build folder from Docker to the host)!! Sshpass -p {password} SCP {local directory} {username}@{host}:{remote directory} 6. Connect to the remote host and execute the command!! Sshpass -p {password} ssh-o StrictHostKeyChecking=no {user name}@{host IP address} Command to be executed // -o StrictHostKeyChecking=no: Ignore password prompts such as 'rm -rf/TMP /test 'Copy the code

(2) gitlab – CI

Compare this with the following article

  • [Deployment 01] Nginx
  • [Deployment 02] Docker deployvUE project
  • [Deployment 03] Gitlab-CI

(1) Introduction to Gitlab CI/CD

  • Gitlab provides continuous integration services that automatically trigger (pipeline) when (commit) or (push). Implementations require two things:
    • At the root of the project add (.gitlab-ci.yml) file
    • gitlab-runner
  • .gitlab-ci.yml
    • The YML file defines the structure and order of the pipeline and specifies the following:
    • What to do with gitlab-Runner
    • What should you do when you encounter special cases of process success or failure
  • pipeline => stages => jobs
    • Pipeline in (project => CI/CI => pipeline)
    • Pipiline generally includes three stages => Build Test deploy

(2) (Pipeline), (stages), (Jobs

  • concept
    • Pipeline, pipeline
    • Stages – phase
    • Jobs – jobs
  • Pay attention to the point
    • What can be set to trigger the pipeline, such as COMMIT or MR
    • pipeline => stages
      • A (pipeline) can contain multiple (stage )
      • ( stageExecute in sequenceserial )
      • Successful: The Pipeline will be successful only if all stages complete successfully
      • Failure: Stages that follow a stage failure will not be executed
    • stages => jobs
      • A (stage) can contain multiple (job )
      • ( job) is executed in parallel in a stage (parallel )
      • Success: Stages are successful only when all jobs are completed successfully
      • Failure: If a job fails, the stage fails
+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+
Copy the code

(3) gitlab – runner

(1) What is the Gitlab-Runner used for?

  • The runner is used to run jobs as defined in gitlab-ci.yml
  • Runner can be a physical machine, a container, a cluster, and so on
  • The Runner and Gitlab communicate via API, so the only requirement is that the Runner’s machine can access the GITlab server (the Runner and the server have to be deployed separately).
  • A Runner can serve a specific project or multiple projects, or even all projects, for all names called shared Runner
  • The type of runner:
    • shared runners
      • If you installed Gitlab using (gitlab.com) rather than using your own server, use Shared Runners
      • There are different time limits for public and private projects, with private only running 2,000 minutes per month
    • Specific Runners
      • For self-built GITLab, it is generally considered to use its own server to install specific Gitlab-Runner

(2) How can Gitlab-Runner work?

  • 1. Install gitlab – runner
  • 2. Register Gitlab-Runnner in a project or group

(3) How many installation methods does Gitlab-Runner have?

  • Install gitlab – runner
  • Gitlab-runner can be installed on a variety of systems, such as MacOS, Windows, Linux, etc
  • There are three ways of (installation) :
    • dockerWay to install
    • Downloading binary packages
    • The RPM package
  • (most convenient) installation: use the (Gitlab/Gitlab-Runnner) container for installation

(4) Install – [Docker install Gitlab-runner]

  • Install – Dokcer install gitlab-Runner
  • We use the Docker method here (highly recommended because it is very simple)
  • How to ensure that the data of gitlab-Runner’s container is not lost after the container is restarted?
    • 1. Use the local data volume
    • 2. Use the data volume container
  • Installation Procedure:
      1. First of all, make sure you have (Docker environment)
      1. Docker pull gitlab/ Gitlab – Runnner
      1. After generating the Gitla-Runner container with the following command (generate the container), you can proceed to the next step of the registration process
Docker run - rm - it - v/SRV/gitlab - runner/config: / etc/gitlab - runner gitlab/gitlab - runner register or: The following command generates the container in background mode, which mainly maps the configuration in the container to the host. Docker run -d --name gitlab-runner --restart always \ -v docker run -d --name gitlab-runner --restart always \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latestCopy the code

(5) Registration – [Docker Registration Gitlab-Runner]

  • Register – Register Gitlab-Runner in Docker mode
  • Step (4) Install the Gitlab-Runner container. After obtaining the configuration in the container, you need to register the new runner to run the job.
  • The specific registration process:
    • 1. Create a container for (registered container)
      • Type the commanddocker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
      • Note:The fourth step installation process also generates the container, which is mainly for obtaining the configuration of the runner in the container and mapping to the host. The obtained configuration is used for registration
      • In fact: You can also directly use the runner container generated in step 4, but the data volume is different
    • 2. After registering the container, the interactive command registration process of Gitlab-Runner will be entered. The detailed process is as follows
Registration process 1. Generate registered using the docker container docker run - rm - it - v/SRV/gitlab - runner/config: / etc/gitlab - runner gitlab/gitlab - runner register  2. After you run the command in step 1, the interactive registration command process is displayed. Step 3 3. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):) https://gitlab.com/ 4. Please enter the gitlab-ci token for this runner jkkqxftamyBNnpwy-vfj // How to obtain the token => Gitlab site corresponding to the project/setting/CICD/Runners/Specific Runners get token 5. Both Please enter the gitlab - ci description for this runner 7-react-admin-ts-runner 6. Please enter the gitlab-ci tags for this runner (comma separated) 7-react-admin-ts-runner // tag 7. Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell docker // 1. Input actuator, most of the time using docker shell // 2. How during the deploy phase, because you need to copy the dist folder, 8. Please enter the Docker image (eg. ruby:2.6) node If you do not specify an image in the (.gitlab-ci.yml) file, you will use the image specified in the (.gitlab-ci.yml) file. At the same time = > gitlab website corresponding project/setting/CICD/Runners/Specific access token in the Runners will be displayed in the newly registered runnerCopy the code

(4). Gitlab – ci. Yml

Official document of.gitlab-ci.yml

(4.1) Commonly used keywords

The keyword describe
image With a Docker image, both of the following work

image: name

image: entrypoint
Stages (Arrays) Definition of pipeline stage, (that is, define the construction phase) is an array — — — — — — — — — — — — — — — — — — — all of the stage
stage A job process, the default test — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — – the specific stage
Tags (arrays) Manage or match runners by tag, that is, which runner is used to execute the job

Tags need to be specified when registering a Runner

Tages is an array because jobs can specify multiple Runners

Usually an array with an S
Script The shell script executed by runner
artifacts roleArfifaces products can be downloaded from Gitlab-UI

applicationArtifacts: A common practice is to define files packaged in the Build phase as artifacts so that they can be used directly in the deploy phase

expire_in: The expiration time of artiFacets. Since these data are kept on Gitlab machines, resources that are too old can be deleted

Paths (arrays): Where to get artifaces, the path is relative to the project directory ($CI_PROJECT_DIR) and cannot be directly linked outside it. Wildcards that follow wildcard patterns and filepath.Match can be used.

name: Name of arfiFacts

when: For example, when: in_success Obtains arfiFacts when the job is successful
dependencies

(array)		 Function:To obtain artifacts, provide the name of the job. That is, the job to obtain artifacts

Note:Only artifacts from jobs prior to this job are retrieved. If artifacts expire, dependencies fail
cache roleCache, a list of files that should be cached between subsequent runs to speed up the build

Pay attention to the point: A global cache available for all jobs

Similar to artifacts

Possible paths: Cache: key, cache: untracked and cache: policy.

Paths (arrays): Specifies the directory to be cached

key: unique cache to solve the problem of cache overwriting
Only (array) Specify a list of Git (branches, tags) for the current job ———–branch, variable, change, etc
Except (array) In addition toUse this job ————— for all branches of Gitbranch, variable, change, etc
Rules (array) Rules will gradually replace only and except

The specific rules are as follows:

if: indicates that the job is triggered if the condition is true

changes: indicates that the job is triggered after the file is modified

exists: indicates that the file exists, and the job is triggered
variables Define variables, to use variables by${variable name}Get variables
allow_failure A failed job is allowed. The failed job does not affect the commit state or the next job
when When has the following values:

on_success: A job that is executed only when all previous jobs are successful

on_failure: A job that is executed only when all previous jobs fail

always: A job that is executed regardless of whether the previous job succeeded or failed

manual: Indicates a job that needs to be manually executed

delayed: Indicates the job whose execution needs to be delayed

never: Does not execute job or pipeline
before_script

(array)		 The script that runs before the job starts
retry Specifies the number of retry times after the job fails. Eg: retry:2 indicates that the job fails and is retry twice. If both fails, the job is executed for three times
parallel Set the number of concurrent jobs. Note that is the number of concurrent jobs

Distinguish between:

1. All jobs in the same stage are run in parallel

2. Parallel specifies the number of times the same job is run in parallel
extends This job inherits configuration items of other jobs. The same configuration items are overwritten, but different configuration items are inherited

Pay attention to: The inherited job starts with a. (.)

(4.2) Common built-in variables

  • Common built-in variables
  • Built-in variables – documents
  • Built-in variables – Document 2
  • Refer to the tutorial
The keyword describe
CI_PROJECT_NAME Name of the project currently being built
CI_BUILD_REF_NAME => CI_COMMIT_REF_NAME The name of the branch or tag used to build the project
CI_BUILD_REF_SLUG => CI_COMMIT_REF_SLUG First convert the value of $CI_COMMIT_REF_NAME to lowercase, a maximum of 63 bytes, and then convert all characters except 0-9 and a-z to -. Used in URLs and domain names



Slug: It means to be lazy
CI_BUILD_REF => CI_COMMIT_SHA Version number of commit
CI_COMMIT_TAG The tag name for commit, which appears only when the tags are created
CI_JOB_NAME The name of the job defined in.gitlab-ci.yml
CI_JOB_STAGE The name of the stage defined in.gitlab-ci.yml
CI_COMMIT_BRANCH Submits a branch name that can be used for branch pipes, including the pipes of the default branch. Does not apply to merge request pipes or label pipes

(4.3) Ci-Lint does gitlab-ci.yml syntax detection

  • CI/CD > Pipelines or CI/CD > Jobs in your project and click CI lint

(5) the SSH keys

  • Ssh-keys website link

(1) Why use SSH Keys?

The main reasons for studying SSH Keys are:

1. When your CI/CD job runs in a Docker container (meaning the environment is included) and you want to deploy your code on a private server, you need a way to access it. This is where SSH key pairs come in handy.

2. Pass the dist folder packaged by the Gitlab-Runner container environment to the host machine. Of course, you can also directly create the Runner environment of the NGINx environment, because Nginx has been configured in other Dockers before

  • If you want to deploy the dist folder in Runner to your own server, you’re going to have to use SSH to make it secret free
  • If you want to perform SSH from (build environment) to (remote server)
  • If you want to synchronize files from (build environment) to (remote server)

(2) The detailed steps of injecting ssh-keys through the.gitlab-ci.yml file (note: below are the steps for the Docker environment)

SSH keys when using the Docker executor

  • 1. Generate a local key pair (Ssh-keys) by using (ssh-keyGen).
    • ssh-keygen -t rsa -b 2048 -C "[email protected]""
    • The above command will generate. SSH folderIt’s in thereid_rsa ，id_rsa.pubAnd other documents
    • Then add the id_rsa.pub of ssh-keys generated on the server to the gitlab account where the project is located
  • 2. Add the private key id_rsa generated in step 1 to the variables
    • key: SSH_PRIVATE_KEY
    • value: id_rsa
    • Settings/CICD/Variables
  • 3. Use the ssh-agent name to load the private key in the job
    • Add the following related commands to the before_script of.gitlab-ci.yml
    • 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
    • eval $(ssh-agent -s)
    • echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    • mkdir -p ~/.ssh
    • chmod 700 ~/.ssh
  • 4. Ensure that the SSH host key of the private server has been authenticated
    • SSH host Keys are Verified website documentation
    • 1. Enter a value on the serverSsh-keyscan Server address
    • 2. Add new variables
      • key: SSH_KNOWN_HOSTS
      • Value: the value output by step 1
      1. Add in the before_script array of.gitlab-ci.yml
      • echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
      • chmod 644 ~/.ssh/known_hosts
  • 5. Finally, add the public key created in the first step to the services to be accessed from the build environment
    • Note: Deploy Keys need to be configured if the repository is private
    • This section describes the deploy Key website
    • How do I enable the Deploy Key
      • 1. Open Settings > Repository in the project
      • 2. Expand Deploy Keys
      • 3. Specify the title, and the public key
      • 4. Check whether you have the write permission
      • 5. An error may be reported when the system is being added
        • Fingerprint has already been taken, Deploy keys projects deploy key fingerprint has already been taken
        • Paste format problem, copy directly into vscode, one line will not be reported error

(VI) [Public Warehouse project] Implementation of GITlab-CI process

(1). Gitlab-ci. yml The detailed configuration is as follows

image: node variables: PROJECT_NAME: "7-react-admin-ts" stages: - environment - build - deploy environment-stage-name-job: stage: environment image: node tags: - 7-react-ci script: - echo "gitlab-ci start" - echo ${PROJECT_NAME} allow_failure: true parallel: 2 environment-stage-env-job: stage: environment image: node tags: - 7-react-ci script: - echo ${CI_COMMIT_SHA} - echo ${CI_PROJECT_NAME} - echo ${CI_PROJECT_NAMESPACE} - echo ${CI_PROJECT_PATH} - echo ${CI_PROJECT_URL} - echo ${GITLAB_USER_NAME} - echo ${GITLAB_USER_EMAIL} - echo ${CI_PROJECT_DIR} - echo ${CI_PIPELINE_ID} - echo ${CI_COMMIT_REF_NAME} allow_failure: true build-stage-job: stage: build image: node tags: - 7-react-ci only: - master script: - echo "build job start" - apt-get install -y git - npm install -g cnpm --registry=https://registry.npm.taobao.org - git  --version - cnpm -v - npm -v - node -v - ls - rm -rf ${PROJECT_DIR} - git clone ${REMOTE_PROJECT_URL} - cd ${PROJECT_DIR} - cnpm install - cnpm run build - ls allow_failure: false retry: 2 artifacts: name: "build_dist" paths: ${BUILD_DIR} when: on_success expire_in: 7 week Deploy-stage-job: # extends:. deploy image: node tags: - 7-react-ci only: - master dependencies: - build-stage-job before_script: - echo "deploy job start" - ls - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )' - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - - mkdir -p ~/.ssh - chmod  700 ~/.ssh - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts - chmod 644 ~/.ssh/known_hosts script: - echo "deploy start" - ls - apt-get update - apt-get install -y sshpass - sshpass -p ${PASSWORD} scp -r ${BUILD_DIR} [email protected]:build_dir allow_failure: false retry: 2 When: on_SUCCESSCopy the code

(2) Deploy the build folder obtained from Gitlab-CI to the Docker nginx container

After one to six steps, you can automatically obtain the packaged folder when the master changes. The final step is to deploy the Build folder to the Nginx container and use the data volume mapping for real-time updates and data persistence

(1) docker pull nginx (2) docker run -it --name=nginx_ci \ -p 7777:81 \ -v /root/build_dir/build:/usr/share/nginx/html \ - v/root/deploy - ci - test/conf. D: / etc/nginx/conf. D \ nginx description: (1) Put the front-end package file in /root/build_dir/build. (2) Put the nginx configuration file default.conf in /root/gitlab-ci-test/conf.d. (3) Default server { listen 81; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; } {the location/API proxy_pass http://49.233.215.163:7001; }}Copy the code

(3) The pits encountered

  • When using public repositories, git Clone mode is selected in HTTPS mode
  • The environment for each job is not shared. For example, if you install Git in joB1, it is not in JoB2
  • A CI deployment for a public project is different from a CI deployment for a private project
  • After using code segmentation and style-Component in React, there will be a chunk warning locally and an error in CI. You need to change the CI variable to false

Program source code

  • Program source code
  • Deployment effect Preview address

data

With my old Gitlab-CI study notes juejin.cn/post/684490… Install gitlab on remote server juejin.cn/post/684490… Data transfer between different stages in the same pipeline blog.csdn.net/textdemo123… How to set the Deploy Keys of Gitlab-CI newsn.net/say/git-pul… Environment Variables in Gitlab-CI article juejin.cn/post/684490… In Linux && and &, | and | | blog.csdn.net/chinabestch…

www.joelled.com/yuncourse/1… Blog.csdn.net/cindy647/ar… Blog.csdn.net/cuandeqin20… Github.com/facebook/cr…