Quick Configuration application

docker-compose.yml

Docker-compose is used for quick orchestration of docker container clusters

Obtain the docker-comemage. yml configuration file of docker-Gitlab for rapid construction

$ wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
Copy the code

After obtaining the docker-comemage. yml file, customize the configuration.

Configure the environment

Open the docker-comemage. yml file and configure the environment for Gitlab

version: '2.3'

services:
  
  .
  # omit to display other services
  .
  
  gitlab:
    restart: always
    image: Sameersbn/gitlab: 13.0.6
    depends_on:
    - redis
    - postgresql
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - gitlab-data:/home/git/data:Z
    healthcheck:
      test: ["CMD", "/usr/local/sbin/healthcheck"]
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 5m
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Kolkata
    - GITLAB_TIMEZONE=Kolkata

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=localhost
    - GITLAB_PORT=10080
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=
    - GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alphanumeric-string

    .
    # omit other configurations
    .
Copy the code

Referring to the configuration document, we need to set the time zone to GMT + 8, set the data obfuscation key, and set the service address.

environment:
- TZ=Asia/Shanghai
- GITLAB_TIMEZONE=Asia/Shanghai

- GITLAB_HOST = 192.168.2.192
Copy the code

To set the obtrude key, it is recommended that 64 random strings be generated using pwgen. You can install the PWgen service and run pwgen -bsv1 64 to generate random strings.

environment:
- GITLAB_SECRETS_DB_KEY_BASE=nvqgzJdgrmr3tqsC4F9gKVNhKvTq3N7cJPjNggR93qthNhJ3MWkc7jNmNTLRXdhX
- GITLAB_SECRETS_SECRET_KEY_BASE=pcrf73fX4rM7bKxc7tcq3kwKWdtKKtrmmsHwT3J9rwCLMsK37PxCnXbMgnRpqJbk
- GITLAB_SECRETS_OTP_KEY_BASE=3d9tPCzpv7rfmVgnjN9McbztRVbp4rjxWWqFbNLTCbRz9mKkpvqqWgxMq7NM7c9w
Copy the code

In the same way, docker-comemage. yml’s other services also require a timezone GMT + 8.

Data volumes are mounted

Mounting a data volume enables persistent storage of data. Data on the directory to which data is mounted is automatically synchronized with data in the container. Data on the directory to which data is mounted takes precedence over data in the container, that is, data on the data volume is automatically synchronized to data in the container when data is modified.

version: '2.3'

services:
  redis:
    restart: always
    image: Redis: 5.0.9
    command:
    - --loglevel warning
    volumes:
    - redis-data:/var/lib/redis:Z
    environment:
    - TZ=Asia/Shanghai

  postgresql:
    restart: always
    image: sameersbn/postgresql:11-20200524
    volumes:
    - postgresql-data:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm
    - TZ=Asia/Shanghai

  gitlab:
    restart: always
    image: Sameersbn/gitlab: 13.0.6
    depends_on:
    - redis
    - postgresql
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - gitlab-data:/home/git/data:Z
    healthcheck:
      test: ["CMD", "/usr/local/sbin/healthcheck"]
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 5m
Copy the code

Note: To mount a data volume, create a corresponding directory on the host in advance.

Manually create the following directories:

/app/volumes/gitlab/gitlab/
/app/volumes/gitlab/postgresql/
/app/volumes/gitlab/redis/
Copy the code

Modify the corresponding data volume configuration:

redis:
    restart: always
    image: Redis: 5.0.9
    command:
    - --loglevel warning
    volumes:
    - /app/volumes/gitlab/redis:/var/lib/redis:Z
Copy the code
postgresql:
    restart: always
    image: sameersbn/postgresql:11-20200524
    volumes:
    - /app/volumes/gitlab/postgresql:/var/lib/postgresql:Z
Copy the code
gitlab:
    restart: always
    image: Sameersbn/gitlab: 13.0.6
    depends_on:
    - redis
    - postgresql
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - /app/volumes/gitlab/gitlab:/home/git/data:Z
Copy the code

gitlab-runner

The docker-comemage. yml file pulled down does not have gitlab-runner by default. We need to write gitlab-runner to docker-comemage. yml configuration.

Create a directory for mounting files to the data volume:

/app/volumes/gitlab-runner/config/
Copy the code
gitlab-runner: 
    restart: always
    image: gitlab/gitlab-runner
    depends_on:
    - gitlab
    volumes:
    - /app/volumes/gitlab-runner/config:/etc/gitlab-runner:Z
    - /var/run/docker.sock:/var/run/docker.sock
    environment:
    - TZ=Asia/Shanghai
Copy the code

Build applications quickly

/app/docker/gitlab/ and run the following command: docker-comemage. yml

$ cd /app/docker/gitlab/
$ docker-compose up
Copy the code

Docker-compose automatically manages docker container clusters, including pulling, creating, and starting images.

Wait a moment, we can be opened by http://192.168.2.192:10080/ gitlab page, first open is directly set the root password to the account, after setting the password to log in to gitlab inside pages.

Students who are not good at English can go to personal Settings and set the language to Simplified Chinese.

Registered runner

What is runner? Runner is the environment container service that GitLab runs in the process of sustainable integration and delivery.

To do CI/CD => sustainable integration/sustainable deployment, we need to register a Runner, usually we register a shared Runner, that is, any CI/CD of the warehouse can run on it. Of course, we can also create multiple Runner services to specify a runner for a particular repository.

Take registering shared Runner as an example:

Such as

  1. Enter therunnerThe container
$ docker exec-it container ID bashCopy the code
  1. registeredrunner
$ gitlab-runner register
Copy the code
  1. The inputgitlabThe sample ofurl
$do enter the gitlab - ci coordinator URL (e.g., https://gitlab.com) : http://192.168.2.192:10080/Copy the code
  1. Input for registrationrunnertoken
$ Please enter the gitlab-ci token for this runner:
yrErncrc8XY_e5-g7bU8
Copy the code
  1. The inputrunnerA description is subsequently available ingitlabModify in the interface
$ Please enter the gitlab-ci description for this runner:
gitlab-ci
Copy the code
  1. The input andrunnerBound label (modifiable)
$ Please enter the gitlab-ci tags for this runner (comma separated):
gitlab-ci
Copy the code
  1. chooserunner(recommendeddocker)
 $ Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
 docker

Copy the code
  1. If the execution mode chosen isdocker, will ask you to fill in the default image
$ Please enter the Docker image (eg. ruby:2.1):
alpine:latest
Copy the code

After successful registration, the config.toml configuration file will be generated in the runner container ~/etc/gitlab-runner/ directory, and the active Runner can be seen in the gitlab administration page

Then, modify runner, check runner can select the project without label (the default is the same label of the project can use the corresponding label runner). In this way, a runner can become a shared runner.

When we need to run a runner specifically for a project, there is no need to check runner to choose no label option, and save the project that adds runner service in the following configuration.

Sustainable integration/deployment

Gitlab-ci. yml file needs to be configured for sustainable integration and deployment. Gitlab will check whether there is a.gitlab-ci.yml file in the root directory of each warehouse, and runner will automatically run if there is.

Auto Devops is enabled by default in gitlab. If there is no.gitlab-ci.yml file, auto Devops will be automatically run. You are advised to disable the default Auto Devops function.

.gitlab-ci.yml

This is a configuration file that automatically compiles the front-end code and publishes it to the GitLab Page:

building: 
  image: node:alpine    # specify the runtime environment
  stage: build          The current stage is build
  script:               The script to run in the build phase
    - yarn --registry=https://registry.npm.taobao.org
    - yarn docs:build
  artifacts:            # Artifacts can be cached in gitLab pipeline records for direct download
    expire_in: 3 days   The valid time of the artifact cache
    paths:              # path
      - docs/.vuepress/dist/            In this case, the entire DIST directory

cache:                  # cache
  paths:                # path
    - node_modules/     Caching node_mudules will greatly speed up CI running

deploying: 
  stage: deploy         # The current phase is deploy
  script:               The command to run in the # deploy phase
    - rm -rf public/*   -mv dist/* public // Remove all files from dist/* public // remove all files from dist/* public // remove all files from dist/* public //
  artifacts:            # Artifact cache
    expire_in: 3 days   The validity period is 3 days
    paths:              # path
      - public          Caches files from the entire public directory
  only: 
    - master               All operations under # ceate Pages are performed only on the master branch

Copy the code

automation

When we submit our code, Gitlab will automatically run Runner according to the.gitlab-ci.yml configuration.

This allowed us to automate integration and deployment, greatly increasing our development efficiency.

The identity authentication

After we register our account in Gitlab, we generally need to use SSH to generate the authentication key to facilitate identity authentication, so that we do not need to enter the account password every time we access.

Configure the SHH key

Git bash on our computer:

$ ssh-keygen -t rsa -C "Our registered email address in Gitlab" -f ~/.ssh/gitlab_id_rsa
Copy the code

SSH: /.ssh: /.ssh: /.ssh: /.ssh

gitlab_id_rsa
gitlab_id_rsa.pub
Copy the code

Open the public key with the pub suffix, copy and paste it into gitlab user Settings, and save it.

Git has mixed up github’s SSH key with Gitlab’s SSH key.

Github coexists with GitLab

Let’s assume we’ve generated github’s SSH key before:

github_id_rsa
github_id_rsa.pub
Copy the code

In our computer user directory /.ssh/ create config file, configure as follows, save:

#github
Host github.com
HostName github.com
IdentityFile C:/Users/jwchan/.ssh/github_id_rsa

#gitlabThe Host 192.168.2.192 HostName 192.168.2.192 IdentityFile C: / Users/jwchan /. SSH/gitlab_id_rsaCopy the code

This way, when we submit code, we will automatically differentiate between the target server and use the corresponding SSH key.

Git Basic Operations

  1. Pull the warehouse
$ git cloneSSH: / / [email protected]:10022 / jwchan/blog. GitCopy the code
  1. Go into the repository and contribute code
$ cd /blog/
Copy the code
  1. View repository code modification status
$ git status
Copy the code
  1. Add code buffer
$ git add .
Copy the code
  1. Submit the code and comment it
$ git commit -m "[fix]: bug"
Copy the code
  1. Push code to remote repository
$ git push 
Copy the code