Writing in the front

Many people in the company have certainly used Gitlab or other similar privately deployed DevOps platforms deployed on the Intranet, but most of them only do push and pull work when the company’s operations are already deployed 😆. I’ve been at my new company for over a month now, and the company has been experimenting with Gilab and CI tools. Every time I push code to a branch (like Develop), THE CI tool is automatically packaged and deployed to a specific location, all with a simple YML configuration file. Therefore, I came up with a bold idea. Just on November 11, I won a three-year light application server with 2 cores and 4G memory, plus 8M bandwidth and 1200G downlink traffic, which just met the deployment conditions of Gitlab (Gitlab really ate too much memory), and this server was always idle. In line with try the mentality of death, I came home from work yesterday began my step pit road 😭.

Pay attention to

• The system environment used in the following are under the premise of Tencent cloud server +CentOS8, the author is a Linux dish 🐔, if there is not in accordance with the specification of the place please forgive, after all, in the case of Baidu /Google to complete the deployment, and configuration in line with their own ideas has been not easy 😭.
• On Tencent cloud server, we have removed many restrictions on configuring servers (such as SSH, firewall, SeLinux, etc.), which will not be described below.
• All package managers mentioned in this article refer to DNF recommended by CentOS8.

Preparing for deployment

As this is an article in which the author records his own steps and shares them, the degree of mastery of all pre-skills mentioned in this article is the same as that of the author by default.

Postfix

This is an email sending tool. Gitlab itself comes with an account system, and the account needs to be activated before use, so it is necessary to have a corresponding email sending tool to send the activation link to the bound mailbox. This is by default in the package manager’s REPo, so it can be installed directly. You only need to run the following command to install it

dnf install postfix
Copy the code

DNF is compatible with most of the yum usage habits, so the installation steps are similar. Just wait for the prompt to install the license and type yes to complete the installation.

Gitlab-CE

Gitlab itself is a commercial software, if directly through the search engine search and enter the website after you may see the introduction and free trial on commercial version, but you know, free trial as the real free sure or far worse, however Gitlab is, indeed, provides the corresponding real free community edition. Here is the download address for all the community edition Packages: gitlab/ gitlab-CE-Packages · packages.gitlab.com

There are a lot of versions, and there are different versions. Since I can’t understand the actual meaning of the version here, I just choose the version that seems to fit the most. Firstly, CentOS based on RHEL is used. RHEL is actually the famous RedHat. The internal offline package installer is RPM, so gitlab-ce-14.4.2-ce.0.el8.x86_64. RPM is selected. Wget download address:

wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/8/gitlab-ce-14.4.2-ce.0.el8.x86_64.rpm/download.rpm
Copy the code

Select a suitable folder path on the cloud server and run the above instructions directly.

Installation and Configuration

The installation

I found a way to download the installation package, but Tencent Cloud did not speed up the download site, so the speed of direct download on the cloud server may be very slow, and the size of this package is 900M. Seeing the download speed of 10K /s, I finally chose to download it through my local macOS. It is then sent to the cloud server using SCP. RPM will verify the signature of the offline package when the package is installed. If the package is downloaded from macOS, the package will be verified by verify. You can solve this problem by skipping the Verify phase when executing the install command:

RPM -ivh < package name >. RPM --nodigest --nofilesdigestNodigest skips packet validation
# --nofiledigest skips in-package file validation
Copy the code

After a series of installation log messages, about ten minutes, the installation is successful. To verify the installation status, enter the following commands, starting with the installation path of Gitlab

find / -name gitlab
Copy the code

Output a bunch of paths, a few of which are important to remember in particular

/etc/gitlab This is the configuration file for gitLab initialization
/var/opt/gitlab Here is the configuration file for Gitlab at run time
Copy the code

The reason why we need to pay attention to the above two addresses is that I need to configure port and relative path for Gitlab later. Since the cloud server itself will be used to deploy CI later, some simple front-end projects also need to run on it. If port is not set, Gitlab will occupy port 80 by default. However, if Gitlab is set to run as a port, my obsessive-compulsive behavior again, this server is not intended to bind domain name (registration is really troublesome, and DevOps deployment may be difficult review), remember IP is hard enough, but also need to remember a bunch of ports more difficult, So you also need to run an additional Nginx service to reverse proxy and set Gitlab to/Gitlab address.

Configuring a Relative Path

According to the online deployment tutorial, this step should actually start the implementation of the service, but because of the pit, so here to Gitlab initialization before a configuration, save the trouble of repeated restart. In official documents – Install GitLab under a relative URL | GitLab has mentioned in more professional way of configuration, but the steps are very complicated, and seems to be based on specific installation mode, because the document in the beginning assumptions GitLab installation path, However, the paths installed through RPM did not seem to match well, so it was abandoned. But after online access to information, as well as their own final experience after stepping on the pit, or can come to a more general solution is 😂. /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb: /etc/gitlab/gitlab.rb /etc/ gitlab.rb /gitlab.rb

external_url 'http://<host>/gitlab' # use your own domain name instead of host
Copy the code

Initial Configuration

After the configuration is modified, the project needs to be initialized, which needs to use the service management tool gitlab-ctl provided by Gitlab after the installation. Gitlab-ctl: gitlab-ctl: gitlab-ctl: gitlab-ctl: gitlab-ctl: gitlab-ctl: gitlab-ctl: gitlab-ctl

reconfigure Initialize all configurations
status Run the following command to check the service status
start Start the service, same as system-ctl
stop # stop service, same as system-ctl
restart Restart the service, same as system-ctl
Copy the code

All except the first one correspond to the basic usage of sysmte-ctl. I’m going to run it directly here

gitlab-ctl reconfigure
Copy the code

Then there will be a heap of log output, if the front set is no problem, here basically just need to wait for the end, but here to note that the first execution after the initialization, will help you allocate a root user, the user has the super administrator privileges, is very important, and the root user’s password will be assigned at this time. The initial password is stored in /etc/gitlab/initial_root_password. Note that this file will be deleted 24 hours after initialization, so be sure to check the password in advance and copy it. After the system is installed, log in to root and change the password. To view the initial password:

cat /etc/gitlab/initial_root_password 
Copy the code

Modifying a Running Port

The initial configuration is completed, but the service is not in a hurry to start at this time, starting at this time will occupy port 80 by default, if you have other services that need port 80 to run, it will be more trouble, so directly find the running configuration: The/var/opt/gitlab/gitlab – rails/etc/gitlab yml and/var/opt/gitlab/nginx/conf/gitlab – HTTP. Conf. First modify gitlab.yml:

port: 8099 You can write any port you want
Copy the code

Then gitlab-http.conf:

Find the server that is in effect by default
server {
    listen* :8099; # this port should be the same as the one above
    #... Other configuration
}
Copy the code

Configuring a Reverse Proxy

Those of you who have done front-end split deployment and NodeJS should be familiar with the concept of proxying a particular path-prefix address to a service on a particular port. This allows multiple services to be stored on port 80 on a single server. Here you need to configure an additional Nginx package, which is also a built-in DNF package and can be downloaded directly:

dnf install nginx
Copy the code

After the installation is complete, go to /etc/nginx/nginx.conf to modify the port. After all, port 80 is used for reverse proxy of different services, so no additional configuration file is required for management.

server {
    location /gitlab {
        proxy_pass http://127.0.0.1:8099/gitlab/; This port must be in the gitLab configuration}}Copy the code

Then start Nginx:

nginx -t -c /etc/nginx/nginx.conf
Copy the code

If you have run Nginx before, this needs to be stopped, re-read the configuration, and then restarted

nginx -s stop
nginx -s restart
Copy the code

access

Once the appeal is complete, access can be attempted. The worst thing is that it redirects us to the default home page of Nginx. If we open GitLab without logging in, it will redirect us directly to the/root route. According to the reason, the relative path we configured should not have this problem, but since the configuration was finished at 0 PM last night, we did not investigate the reason deeply, but we guessed that it should be the pot configured in the front end of Gitlab. After a brief check, we found that the front end of Gitlab seemed to use the React framework. React uses React-Router alone to manage front-end routes. However, a temporary solution was found, that is, direct access to /gitlab/login will open the login address, when successful login, no redirection to the root route.

Configuration in Chinese

userootAfter login, openGitlabTurns out it’s a bunch of English. I can barely read it, butGitlabThere is a Chinese language pack available.

Changing the Administrator Password

The default password of the administrator is very long, which is not good for memory. In addition, the default password file will be deleted periodically. It takes a lot of time to process if you forget it later.

Closing free registration

Their deployment of the platform certainly hope to save resources and save, and too many user registration server resources can not stand, so to close the registration function.

Create a normal user

You might want to use a normal user to write your code, because sometimes you need to share your public project with others, so using root is a bit risky.

Open it and fill in the form normally.

Write in the last

This step pit is also spent a lot of effort, the article has been stepping pit process all skipped, are stepping pit after the results (middle encountered Nginx can not restart normally, and then found that the configuration file is a problem, I too dish 🤦♂️), so normal can be directly according to the steps to configure.

reference

GitLab (cnblogs.com) Install GitLab under a (cnblogs.com relative URL | GitLab