1. Premise
jenkins plug-in address: http://updates.jenkins-ci.org/download/plugins/
- 192.168.211.90 gitlab,jenkins,Maven
- 192.168.211.91 git,httpd
- 192.168.211.92 nexus,sonarqube,docker-ce
192.168.211.93 this is a separate environment for testing jenkins and docker
Turn off the firewall # systemctl disable firewalld.service close NetworkManager # systemctl stop NetworkManager close selinux # cat /etc/selinux/config SELINUX=disabled Install common commands # yum install -y net-tools lrzsz tree screen lsof wget ntpdate Set time # crontab -e add # crontab -l */5 * * * * /usr/sbin/ntpdate time1.aliyun.com Change time zone # ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
2. Install gitlab
1.1 installation of gitlab 192.168.211.90
GitHub and GitLab are web-based Git repositories
Installation dependency:
# yum install curl policycoreutils openssh-server openssh-clients policycoreutils-python -y
Download rpm package
# cd /usr/local/src/ #wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.9.1-ce.0.el7.x86_64.rpm # rpm -ivh gitlab-ce-11.9.1-ce.0.el7.x86_64.rpm
3. Configure gitlab
The default configuration file of gitlab is located in VIM / etc / gitlab / gitlab RB, modify external_ The URL is the IP address of the local machine or a domain name that can access the local machine
external_url 'http://192.168.211.90'
After modifying the main configuration file, use gitlab CTL reconfigure to reconfigure and load gitlab
4. Start gitlab
After successful reconfiguration, gitlab can be restarted
# gitlab-ctl restart ok: run: alertmanager: (pid 5060) 1s ok: run: gitaly: (pid 5078) 0s ok: run: gitlab-monitor: (pid 5091) 1s ok: run: gitlab-workhorse: (pid 5114) 0s ok: run: logrotate: (pid 5125) 0s ok: run: nginx: (pid 5132) 1s ok: run: node-exporter: (pid 5216) 0s ok: run: postgres-exporter: (pid 5227) 1s ok: run: postgresql: (pid 5238) 0s ok: run: prometheus: (pid 5246) 1s ok: run: redis: (pid 5260) 0s ok: run: redis-exporter: (pid 5430) 0s ok: run: sidekiq: (pid 5439) 0s ok: run: unicorn: (pid 5451) 0s
Enter in the browser: http://192.168.211.90/ , the first login requires resetting the root password
After changing the password successfully
Just log in
5. Composition of gitlab
Gitlab consists of the following services, which jointly undertake the operation needs of gitlab
- Nginx: static web server
- Gitlab shell: used to process git commands and modify the authorized keys list
- Gitlab workhorse: lightweight reverse proxy server
- logrotate: log file management tool
- postgresql: Database
- redis: cache database
- sidekiq: used to execute queue tasks in the background (asynchronous execution)
- unicorn: An HTTP server for Rack application，gitlab
rails applications are hosted on this server
You can use commands to view the status of individual services
# gitlab-ctl status run: alertmanager: (pid 5060) 53429s; run: log: (pid 4308) 53665s run: gitaly: (pid 5078) 53428s; run: log: (pid 3570) 53739s run: gitlab-monitor: (pid 5091) 53428s; run: log: (pid 4171) 53683s run: gitlab-workhorse: (pid 5114) 53427s; run: log: (pid 3939) 53700s run: logrotate: (pid 5125) 53427s; run: log: (pid 4017) 53693s run: nginx: (pid 5132) 53427s; run: log: (pid 3967) 53699s run: node-exporter: (pid 5216) 53427s; run: log: (pid 4130) 53688s run: postgres-exporter: (pid 5227) 53427s; run: log: (pid 4356) 53660s run: postgresql: (pid 5238) 53426s; run: log: (pid 3660) 53735s run: prometheus: (pid 5246) 53426s; run: log: (pid 4242) 53672s run: redis: (pid 5260) 53425s; run: log: (pid 3387) 53746s run: redis-exporter: (pid 5430) 53425s; run: log: (pid 4210) 53678s run: sidekiq: (pid 5439) 53424s; run: log: (pid 3906) 53705s run: unicorn: (pid 5451) 53423s; run: log: (pid 3875) 53709s
5.1 gitlab shell
Gitlab Shell has two functions: Handling git commands for gitlab and modifying the authorized keys list.
When accessing gitlab server via ssh, the gitlab shell will:
- Call gitlab rails api to check permissions
- Execute pre receive hook (called git hook in gitlab Enterprise Edition)
- Execute the action you requested and handle the post receive action of gitlab
- Handle custom post receive actions
When accessing the gitlab server through http\https, the workflow depends on whether you pull the code from the git warehouse or push the code to the git warehouse
If you pull the code from the GIT repository, the gitlab rails application will be fully responsible for user authentication and executing git commands
If you push the code from the GIT repository, the gitlab rails application will neither authenticate users nor execute git commands. It will hand over the following work to the gitlab shell for processing
- Call gitlab rails api to check permissions
- Execute pre receive hook (called git hook in gitlab Enterprise Edition)
- Perform the action you requested
- Handle the post receive action of gitlab
- Handle custom post receive actions
5.2 gitlab workhorse
gitlab workhorse is an agile reverse proxy, which can handle some large http requests, such as file upload, file download, git push/pull and git package download. Other requests will be reverse proxied to the gitlab rails application, that is, to the unicorn on the back end
6. gitlab command
Start all gitlab components
# gitlab-ctl start Stop all gitlab assembly # gitlab-ctl stop stop it postgresql assembly # gitlab-ctl stop postgresql Stop related data connection services # gitlab-ctl stop unicorn # gitlab-ctl stop sidekiq Restart all gitlab assembly # gitlab-ctl restart restart gitlab-workhorse assembly # gitlab-ctl restart gitlab-workhorse View service status # gitlab-ctl status If you change the configuration file[gitlab.rb file]，Make the configuration file effective, but initialize it except gitlab.rb All documents except # sudo gitlab-ctl reconfigure view log # sudo gitlab-ctl tail inspect redis Log of # sudo gitlab-ctl tail redis
7. Main directory of gitlab
- /Var / opt / gitlab / git data / repositories /: the default storage directory of the library
- /opt/gitlab /: the storage directory of application code and corresponding dependent programs
- /var/opt/gitlab: the application data and configuration files compiled by gitlab CTL reconfigure command do not need to be manually modified
- /etc/gitlab: configuration file directory
- /var/log/gitlab /: the logs generated by various components are stored in this directory
- /var/opt/gitlab/backups /: the directory generated by the backup file
gitlab turns off the user registration function
After logging into the web interface
Click Admin Area in the upper navigation bar
Click setting on the left
Find the sign up restrictions configuration area and click expand
Remove the √ in front of sign up enabled
Finally, click the save button
8. gitlab warehouse management
Gitlab manages the project and user uniformly through the concept of group. By creating a group, creating a warehouse under the group and adding users to the group, gitlab realizes the permission management of users and warehouses
- Create groupcreate group
- Click the Admin area button at the top of the administrator page to enter the administrator area
- Click the new group button
Fill in the necessary information
Group name, group path, group description
Group visibility level
- Visibility level: select who can access the group. We can select private by default
- Private: The group and its projects can only be viewed by members.
Only authorized users can see it - Internal: The group and any internal projects can be viewed by any
logged in user. Any user who logs in to gitlab can see it - Public: The group and any public projects can be viewed without any
authentication. Anyone who can access the gitlab web page can see it
After filling in the information, click create group
Enter the created group management interface
You can find another interface to create a group of users
9. create user
On the administrator page, click the Admin Area button at the top of the page to enter the administrator area
Click create user
Fill in the necessary information
User name, nickname, user name, email address, select user level
Click create user
Enter the user's management interface
Click the Edit button on the upper right page of the page to set the initial password for the user
You can also set other user information
Finally, click save to change
10. grant user
After the user is created, we need to authorize the user so that the user can manage the warehouse. There are two ways: one is to add the user to the group so that the user can manage the warehouse in the group; Second, directly authorize users to manage the warehouse. Usually, we add users to corresponding groups and assign them different roles. The user's role in Gitlab is defined by the system and cannot be changed, which may not be in line with our normal thinking habits.
Next, add the newly created nqt user to xmlgrg_test group and give developer permission
In the administrator area, click the created group to enter the group management interface
Select a user, give permission, and click Add
Added successfully
Official document description of corresponding authority: https://docs.gitlab.com/ee/user/permissions.html
11. Create warehouse create project
In gitlab, create a project to store your program code, as a problem tracker, for code collaboration, for construction, testing and deployment in continuous integration.
Click New project in the administrator area
Fill in the information of the new warehouse
After the creation, the page has these two prompts. Don't worry about it first
When the warehouse related operation line on the left is empty and the warehouse related operation line on the right is displayed in the warehouse related menu bar
Command line instructions Git global setup # git config --global user.name "Administrator" # git config --global user.email "admin@example.com" Create a new repository # git clone http://192.168.137.100/xmlgrg_test/xm.git # cd xm # touch README.md # git add README.md # git commit -m "add README" # git push -u origin master Existing folder # cd existing_folder # git init # git remote add origin http://192.168.137.100/xmlgrg_test/xm.git # git add . # git commit -m "Initial commit" # git push -u origin master Existing Git repository # cd existing_repo # git remote rename origin old-origin # git remote add origin http://192.168.137.100/xmlgrg_test/xm.git # git push -u origin --all # git push -u origin --tags
After adding a warehouse to a group, members of the group can see the warehouse
Log in using nqt user. You can see the warehouse xm
12. Configure ssh key
The warehouse is private. Only authorized users can access the warehouse. As long as the user of the client is bound with our gitlab user, the client can access the warehouse on gitlab. It is recommended to use ssh to bind the client and gitlab user. The specific configuration is as follows:
Generate ssh key pair on the client (note that rsa encryption can only be used under windows client)
On 192.168.211.90, gitlab server
Switch to the user running gitlab. I directly use the root user of the server here
# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:TPquDQ/XGM5zBefa86ZCfKiGLh8aWHWbbVEdV06etUM root@localhost.localdomain The key's randomart image is: +---[RSA 2048]----+ | ...E*| | . o=+| | . o o . +o| | . = + = .| | . . S.o.o | | o + =++. | | . . +.Bo+.o | | .o.Ooo. o. | | .++o+ ..o. | +----[SHA256]-----+ # ll /root/.ssh/ Total consumption 8 -rw------- 1 root root 1679 5 February 17:07 id_rsa -rw-r--r-- 1 root root 408 5 February 17:07 id_rsa.pub # cat /root/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDC9rQr5/sh7EJGMmScIJnyG+vWaXpjibA4i81ik14pdyeV80CYTmV7h38fYSKbsGI+MeQX8euvsqveGhNqJsNvTSNm/c5aoHudY6vNrvVkP1SM1gIsdgGb8I2uJeQBPi KftLnWashuO85vKiZ5hmv9THMW/Zn1NhiCuh3Ixj2PqEiUGxLLMb4NltJSoJOrOkKYZKd6FyLqXoLNJ9QN/m8uCHgS2vlTa7wvNIOZwAQnZ3Rx95dSusosUDHzfwBeMkCuNQpcP2kkQ2E6r+oi+zAlW/q6sUhHQzg0t1zat8IgEpJi3cu0TJRrdAnjNLlSL4Ue+RpmRrwoKs/gUgmrdIlZ root@localhost.localdomain
Bind this user to the root user of gitlab
Click the icon of gitlab user and find setting
Enter the user's setting page and click ssh keys in the menu bar on the left
This page can also set other user information
Configuration page of SH
Only public keys can be added here. Note that a public key can only be added once in the whole gitlab system, but a gitlab user can add multiple public keys
13. Push local client warehouse to gitlab
yum install -y git git --version
Set the global level information of this warehouse
# git config --global user.name quntao # git config --global user.email xmlgrg@163.com # git config --list user.name=quntao user.email=xmlgrg@163.com
Create an empty warehouse
# pwd /data/git_test # git init Initialize empty Git Version library at /data/git_test/.git/ # ll -a Total consumption 0 drwxr-xr-x 3 root root 18 5 February 20:09 . drwxr-xr-x 3 root root 22 5 February 20:09 .. drwxr-xr-x 7 root root 119 5 February 20:09 .git
Set filter file
With the warehouse, we can be in GIT_ We only need to delete the temporary files in the development area, but we don't care about the automatic deletion of other files in the development area. At this time, you need a filter file. Set the filter rules in this file so that git can automatically filter out those temporary files. This file is gitignore file.
Create in the warehouse directory gitignore file
# pwd /data/git_test # touch .gitignore # vim .gitignore # cat .gitignore test.txt /test/ *.txt
- test.txt / / filter test Txt file
- /Test / / filter the test directory
- *. txt / / filter all txt file
Common general configuration rules:
- The directory is indicated by a slash '/'
- Use an asterisk "*" to say one character
- With a question mark Wildcard single character
- Match list containing a single character in square brackets "[]"
- With exclamation mark "!" Indicates that matching files or directories are not ignored (tracked)
# touch a # touch b # touch c # git add a # git add b # git add c # Git commit - M "commit a" / "commit a" description of the submitted version [master(Root submission) 4141 cd7] commit a 3 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a create mode 100644 b create mode 100644 c
Push local client warehouse to gitlab
# pwd /data/git_test # git remote add gitlab git@192.168.137.100:xmlgrg_test/xm.git
You have new messages in / var/spool/mail/root
# git remote gitlab # ll -a Total consumption 4 drwxr-xr-x 3 root root 63 5 February 20:19 . drwxr-xr-x 3 root root 22 5 February 20:09 .. -rw-r--r-- 1 root root 0 5 February 20:19 a -rw-r--r-- 1 root root 0 5 February 20:19 b -rw-r--r-- 1 root root 0 5 February 20:19 c drwxr-xr-x 8 root root 166 5 February 20:25 .git -rw-r--r-- 1 root root 22 5 February 20:14 .gitignore # git push -u gitlab master The authenticity of host '192.168.137.100 (192.168.137.100)' can't be established. ECDSA key fingerprint is SHA256:zUU81Kb1Q5uS1ewufeZ1qLyErPI0uOyIhEmOabssXoE. ECDSA key fingerprint is MD5:1a:bc:a7:24:e7:f6:ce:4e:d3:df:56:ac:4a:e2:a5:3c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.137.100' (ECDSA) to the list of known hosts. Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 203 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@192.168.137.100:xmlgrg_test/xm.git * [new branch] master -> master
The branch master is set to track the remote branch master from gitlab.
Prompt that the push is successful. We can see the pushed content on the xm warehouse on gitlab
14. Clone gitlab warehouse to local client
192.168.211.91
Install git on this server
The git version installed by default using yum is 1.8. The version is lower. We can use the source code to install it
First, you need to install the dependent Library:
# yum install -y curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker
Download the latest source package
# cd /usr/local/src/ # wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.19.2.tar.xz # tar xf git-2.19.2.tar.xz # cd git-2.19.2 # make prefix=/usr/local/git all # make prefix=/usr/local/git install # rm -rf /usr/bin/git # ln -s /usr/local/git/bin/git /usr/bin/git # git --version git version 2.19.2 generate ssh key [root@localhost git-2.19.2]# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:deiQnPXeqNII+GsnVedBO0255UWtGto4PEbeEYSBTPo root@localhost.localdomain The key's randomart image is: +---[RSA 2048]----+ | o..o+. oo| | oo+.oo o +| | . = o.o= =.| | . . +ooBo+ .| | . . E=.Bo*. | | . ..oO.= | | ..o.oo | | o... | | ..o | +----[SHA256]-----+ [root@localhost git-2.19.2]# ll /root/.ssh/ Total consumption 8 -rw------- 1 root root 1675 5 February 20:44 id_rsa -rw-r--r-- 1 root root 408 5 February 20:44 id_rsa.pub [root@localhost git-2.19.2]# cat /root/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCwUIYoYKPxp23ZH+Q4DmQJtuxv9AWmZUKemTVJ0cBDB03K4AhF64orfODrdGmEr1G0IllPuhMJ7HtbRR7EcsCE8MunxikRyJhb8iOYzTtTkGDy9Q0aZ/BUKx7wAmIj+u NHe+X8YUYtpMfMngtLl5XL0yHRvMoPVaUPT9FlejfRtrj3Qh8+vKiN4q9c36tC8eoyEnKE656yboTNkYE43Djp6DyynPmNcuB4dOVNz+OA+uR7OIidT6fxw16bxkCXUQeQ/Y6doMCOjBuZEUsD0VaSQ5J16ewd47cBbeEv/fVUIoZFXv5VrtowYWU6WlzMu2AQRiQs+ZeYik0L2UqcOXmP root@localhost.localdomain
Then configure 192.168.211.91 client to bind with nqt user on gitlab
Use the git clone command to clone the warehouse to the 192.168.211.91 local server
[root@localhost data]# mkdir /101 [root@localhost data]# cd /101 [root@localhost 101]# git clone git@192.168.137.100:xmlgrg_test/xm.git Cloning to 'xm'... The authenticity of host '192.168.137.100 (192.168.137.100)' can't be established. ECDSA key fingerprint is SHA256:zUU81Kb1Q5uS1ewufeZ1qLyErPI0uOyIhEmOabssXoE. ECDSA key fingerprint is MD5:1a:bc:a7:24:e7:f6:ce:4e:d3:df:56:ac:4a:e2:a5:3c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.137.100' (ECDSA) to the list of known hosts. remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) In receiving object: 100% (3/3), complete. [root@localhost 101]# ll -a Total consumption 0 drwxr-xr-x 3 root root 16 5 February 20:49 . dr-xr-xr-x. 19 root root 247 5 February 20:49 .. drwxr-xr-x 3 root root 45 5 February 20:49 xm [root@localhost 101]# cd xm [root@localhost xm]# ll -a Total consumption 0 drwxr-xr-x 3 root root 45 5 February 20:49 . drwxr-xr-x 3 root root 16 5 February 20:49 .. -rw-r--r-- 1 root root 0 5 February 20:49 a -rw-r--r-- 1 root root 0 5 February 20:49 b -rw-r--r-- 1 root root 0 5 February 20:49 c drwxr-xr-x 8 root root 163 5 February 20:49 .git [root@localhost xm]# [root@localhost xm]# git remote origin
You can see that the xm warehouse on gitlab has been cloned to 192.168.137.101, and a remote warehouse pointing to the xm warehouse on gitlab has been added to the local warehouse
Create a dev branch on xm of 192.168.137.101 and push the dev branch to gitlab
[root@localhost 101]# cd xm [root@localhost xm]# pwd /101/xm [root@localhost xm]# pwd /101/xm [root@localhost xm]# git checkout -b dev Switch to a new branch 'dev' [root@localhost xm]# git status In branch dev No documents to be submitted, clean work area [root@localhost xm]# git push -u origin dev Total 0 (difference 0), reuse 0 (difference 0) remote: remote: To create a merge request for dev, visit: remote: http://192.168.137.100/xmlgrg_test/xm/merge_requests/new?merge_request%5Bsource_branch%5D=dev remote: To 192.168.137.100:xmlgrg_test/xm.git * [new branch] dev -> dev
Branch 'dev' is set to track remote branch 'dev' from 'origin'.
After completion, you can see the pushed dev branch on gitlab
15. Set Branch protection
In the actual use process, the stability of the master branch is usually maintained. It is used for the version release of the production environment. Only authorized users can merge code with the master. To achieve this function, you need to set the master as the protection branch and authorize which users can push code to the master user.
Log in to gitlab as root and click setting in the lower left corner of xm warehouse page
Enter the setup page and select the Repository option under the setup menu bar
Find Protected Branches and click expand
Expand Protected Branches
After setting dev as protected, you can see a green protected after the branch on the branch page of the warehouse
By default, the master branch does not allow the developer role to push content to it
16. Backup, recovery and upgrade of gitlab
Backing up gitlab will create an archive file containing all libraries and attachments. The backup can only be restored to the same version of gitlab at the time of backup. The best way to migrate gitlab to another server is through backup and restore. Gitlab provides a simple command line to back up the whole gitlab, and can flexibly meet the requirements.
Backup configuration
The backup file will be saved in the backup defined in the configuration file_ Path, the file name is TIMESTAMP_GITLAB_BACKUP.TAR, TIMESTAMP is the TIMESTAMP of the backup. The format of TIMESTAMP is EPOCH_YYYY_MM_DD_Gitlab-version.
The default backup file directory is: / var/opt/gitlab/backups. If you customize the backup directory, you need to give git permission to the directory. The specific operations are as follows:
Add to the configuration file:
# vim /etc/gitlab/gitlab.rb ### Backup Settings ###! Docs: https://docs.gitlab.com/omnibus/settings/backups.html #gitlab_rails['manage_backup_path'] = true gitlab_rails['backup_path'] = "/data/gitlab/backups" #Backup directory ##!Docs:https://docs.gitlab.com/ce/raketasks/backup_restore.html#backup-archive-permissions # gitlab_rails['backup_archive_permissions'] = 0644 # gitlab_rails['backup_pg_schema'] = 'public' ###! The duration in seconds to keep backups before they are allowed to be deleted gitlab_rails['backup_keep_time'] = 604800 #Backup retention time (in seconds, this is the default value of 7 days) Execute the following command on the command line # mkdir -pv /data/gitlab/backups # chown -R git.git /data/gitlab/backups/ # gitlab-ctl reconfigure # gitlab-ctl restart
16.1 manual backup
On the command line:
# gitlab-rake gitlab:backup:create 2019-05-18 21:26:25 +0800 -- Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] 2019-05-18 21:26:25 +0800 -- done 2019-05-18 21:26:25 +0800 -- Dumping repositories ... * xmlgrg_test/xm ... [DONE] [SKIPPED] Wiki 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping uploads ... 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping builds ... 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping artifacts ... 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping pages ... 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping lfs objects ... 2019-05-18 21:26:26 +0800 -- done 2019-05-18 21:26:26 +0800 -- Dumping container registry images ... 2019-05-18 21:26:26 +0800 -- [DISABLED] Creating backup archive: 1558185986_2019_05_18_11.9.1_gitlab_backup.tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done done done done done done done Deleting old backups ... done. (0 removed) # ll /data/gitlab/backups / generate corresponding backup files in the specified directory Total consumption 112 -rw------- 1 git git 112640 5 June 18-21:26 1558185986_2019_05_18_11.9.1_gitlab_backup.tar
16.2 scheduled backup
By adding:
Automatic backup at 2 a.m. every day: it is realized by using the backup command through crontab, and the cron service needs to be restarted
#Enter the command crontab -e
sudo crontab -e #Enter the corresponding task environment variable CRON=1 to suppress all progress output of the backup script if no error occurs 0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1 # systemctl restart crond restart service
In the crontab file, each line represents a task, and each field in each line represents a setting. Its format is divided into six fields. The first five segments are the time setting segment, and the sixth segment is the command segment to be executed. Each field is separated by spaces, and the useless segment is replaced by * with the following format:
m h dom mon dow user command
Of which:
- m: Represents minutes, which can be any integer from 0 to 59.
- h: Represents the hour, which can be any integer from 0 to 23.
- dom: represents the date and can be any integer from 1 to 31.
- mon: represents the month and can be any integer from 1 to 12.
- dow: represents the day of the week. It can be any integer from 0 to 7. Here, 0 or 7 represents Sunday.
- User: indicates the user executing the.
- Command: the command to be executed can be a system command or a script file written by yourself (such as a shell file).
16.3 recovery practice
Gitlab recovery can only be restored to the system with the same gitlab version as the backup file. During recovery, stop the process connected to the database (that is, stop the data writing service), but keep gitlab running.
# gitlab-ctl stop unicorn ok: down: unicorn: 1s, normally up # gitlab-ctl stop sideki # gitlab-ctl status run: alertmanager: (pid 11282) 1356s; run: log: (pid 1872) 5129s run: gitaly: (pid 11298) 1355s; run: log: (pid 1859) 5129s run: gitlab-monitor: (pid 11338) 1355s; run: log: (pid 1865) 5129s run: gitlab-workhorse: (pid 11376) 1354s; run: log: (pid 1861) 5129s run: logrotate: (pid 11387) 1354s; run: log: (pid 1860) 5129s run: nginx: (pid 11397) 1353s; run: log: (pid 1852) 5129s run: node-exporter: (pid 11407) 1353s; run: log: (pid 1862) 5129s run: postgres-exporter: (pid 11508) 1352s; run: log: (pid 1869) 5129s run: postgresql: (pid 11524) 1351s; run: log: (pid 1847) 5129s run: prometheus: (pid 11540) 1350s; run: log: (pid 1877) 5129s run: redis: (pid 11559) 1349s; run: log: (pid 1875) 5129s run: redis-exporter: (pid 11598) 1349s; run: log: (pid 1870) 5129s run: sidekiq: (pid 11609) 1346s; run: log: (pid 1878) 5129s down: unicorn: 29s, normally up; run: log: (pid 1876) 5129s #
Perform recovery operation
# gitlab-rake gitlab:backup:restore
During the whole recovery process, you can see that you are basically deleting tables and creating tables
2 Input required at yes Before restoring the database, we will remove all existing tables to avoid future upgrade problems. Be aware that if you have custom tables in the GitLab database these tables and all data will be removed. Do you want to continue (yes/no)? yes This task will now rebuild the authorized_keys file. You will lose any data stored in the authorized_keys file. Do you want to continue (yes/no)? yes