GitLab RPM Deployment and Lifecycle Management

The deployment of GitLab via Red Hat Package Manager (RPM) packages represents a critical architectural choice for organizations requiring high levels of control over their source code management and CI/CD infrastructure. Whether deploying the Community Edition (CE) for open-source collaboration or the Enterprise Edition (EE) for advanced corporate support, the use of RPMs allows for precise versioning and stability, particularly in environments where network connectivity is restricted. The process of utilizing RPMs extends beyond the initial installation of the GitLab core application to include the deployment of GitLab Runners and the automation of RPM builds using GitLab's own CI/CD pipelines. By leveraging RPMs, administrators can ensure that the software is installed in a manner consistent with the operating system's package management logic, facilitating easier updates, dependency resolution, and system audits.

Offline Installation of GitLab Community Edition

Installing GitLab in a disconnected or air-gapped environment requires a strategic approach to package acquisition and transfer, as the standard automated installation scripts rely on active internet connectivity to fetch binaries. In a restricted environment, the administrator must act as the bridge between the public repository and the isolated server.

The process begins with the manual acquisition of the specific RPM package. For a system running Red Hat Enterprise Linux 8 (RHEL8), the appropriate package is gitlab-ce-14.5.2-ce.0.el8.x86_64.rpm. This package can be sourced from packages.gitlab.com. The download can be performed via a web browser or through command-line tools on a machine that possesses internet access.

For those preferring the command line, the wget utility is utilized with the --content-disposition flag to ensure the file is saved with the correct filename. The command is as follows:

wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/8/gitlab-ce-14.5.2-ce.0.el8.x86_64.rpm/download.rpm

Once the RPM is acquired, it must be transferred to the target server. The impact of this step is the physical movement of the binary from a "dirty" (internet-connected) zone to a "clean" (isolated) zone. This transfer is typically achieved using secure protocols such as scp (Secure Copy Protocol) or graphical clients like WinSCP.

Before the GitLab RPM can be successfully installed, the underlying operating system must be prepared with a specific set of dependencies. In an offline scenario, the administrator must ensure that the server has access to local yum repositories or a Red Hat Satellite server to resolve these requirements.

The mandatory dependency packages for a RHEL8 installation include:

• curl
• policycoreutils
• openssh-server
• perl
• postfix
• openssl
• tzdata
• yum-utils

These are installed using the following command:

sudo dnf install -y curl policycoreutils openssh-server perl postfix openssl tzdata yum-utils

The inclusion of openssh-server is critical because the administrator must verify that sshd is operational to maintain remote access to the server during the configuration phase. If the administrator is already connected via SSH, the service is implicitly confirmed as working.

Manual Installation and Configuration on CentOS 7

For administrators utilizing CentOS 7 who prefer a manual installation over automated scripts to maintain full visibility into the system changes, a specific sequence of repository configurations and GPG key imports is required.

The first step involves importing the GitLab GPG keys to verify the authenticity of the packages and prevent the installation of corrupted or malicious software. This is done with two specific commands:

rpm --import https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey
rpm --import https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-3D645A26AB9FBD22.pub.gpg

Following the key import, the official GitLab repository configuration file must be downloaded and placed in the yum configuration directory. This allows the system to recognize the GitLab servers as a valid source for software:

curl -s 'https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/config_file.repo?os=centos&dist=7&source=script' -o /etc/yum.repos.d/gitlab-ce.repo

Once the repository is established, the installation of the Community Edition is executed:

yum -y install gitlab-ce

Post-installation, the core configuration of the instance is managed via the /etc/gitlab/gitlab.rb file. A primary configuration requirement is the external_url setting, which must be set to the IP address of the VM (for example, 192.168.122.131) or a registered DNS entry in the hosts file. Any modification to this configuration file requires the application of changes through the reconfigure utility:

gitlab-ctl reconfigure

GitLab Runner Installation and Distribution Support

The GitLab Runner is a separate agent that executes the jobs defined in the .gitlab-ci.yml file. Its installation process varies depending on the distribution and the level of network access available.

Supported Distributions for Runner RPMs and DEBs

GitLab provides extensive support for various Linux distributions, ensuring that the runner can be deployed across a diverse fleet of servers.

For distributions not explicitly listed, GitLab supports derivatives. If a distribution is a derivative of a supported OS (such as Deepin being a Debian derivative), the corresponding .deb or .rpm package is generally compatible. In cases where the repository is unavailable, users are instructed to download the packages manually from the GitLab S3 bucket.

Repository-Based Installation Process

The recommended method for installing the runner involves the use of official repository scripts which automate the addition of the GPG keys and repository URLs.

For RPM-based systems, the sequence is:

1. Download the configuration script:
   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" -o script.rpm.sh

2. Inspect the script for security purposes:
   less script.rpm.sh

3. Execute the script:
   sudo bash script.rpm.sh

4. Install the runner:
   sudo yum install gitlab-runner or sudo dnf install gitlab-runner

For DEB-based systems, the process is mirrored:

1. Download the configuration script:
   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh

2. Inspect the script:
   less script.deb.sh

3. Execute the script:
   sudo bash script.deb.sh

4. Install the runner:
   sudo apt install gitlab-runner

Notably, a FIPS 140-2 compliant version of the GitLab Runner is available specifically for RHEL distributions, catering to government and highly regulated industrial sectors.

Automating RPM Construction via GitLab CI/CD

One of the most powerful applications of GitLab is using its CI/CD pipelines to automate the creation of other RPM packages. This creates a recursive loop where GitLab is used to build the very package format it was installed with.

Pipeline Configuration for RPM Builds

To start a CI/CD pipeline, a .gitlab-ci.yml file must be added to the repository. When using templates, it is recommended to change the default image from busybox:latest to centos:6 to ensure the environment has the necessary tools for RPM construction.

A practical example of this is the automation of the libsodium RPM build. The pipeline is divided into three distinct stages: build, test, and deploy.

The before_script section is used to extract metadata from the .spec file, which is the blueprint for the RPM package:

• Extract version: export LIBSODIUM_VERS=$(egrep '^Version:' libsodium.spec | awk '{print $NF}')
• Extract name: export LIBSODIUM_NAME=$(egrep '^Name:' libsodium.spec | awk '{print $NF}')

The Build Stage: run-build

The build stage transforms source code into a binary RPM package. The process involves installing the rpm-build package and the necessary compilers.

The operational steps within the script are:

1. Install build tools: yum -y install rpm-build
2. Install compilers: yum -y install gcc
3. Initialize the RPM directory structure: mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
4. Fetch the source code from GitHub: curl -s -L https://github.com/jedisct1/$LIBSODIUM_NAME/releases/download/$LIBSODIUM_VERS/$LIBSODIUM_NAME-$LIBSODIUM_VERS.tar.gz -o rpmbuild/SOURCES/$LIBSODIUM_NAME-$LIBSODIUM_VERS.tar.gz
5. Execute the build: rpmbuild -D "_topdir \pwd`/rpmbuild" --clean -ba `pwd`/libsodium.spec`

The Test and Deploy Stages

The run-test stage ensures that the resulting RPM is functional by attempting to install the generated package:

yum -y install rpmbuild/RPMS/x86_64/$LIBSODIUM_NAME-$LIBSODIUM_VERS-*.rpm

Finally, the run-deploy stage is where the package would be pushed to a production repository or a mirrored server.

Understanding GitLab Artifacts

A critical component of this process is the use of Artifacts. In GitLab CI/CD, artifacts are files or directories generated during a job (such as the final .rpm file) that are not part of the original Git repository. Because the build environment is ephemeral (the container is destroyed after the job ends), artifacts must be defined so that the resulting RPM can be passed to the test and deploy stages or downloaded by the user.

Conclusion

The deployment and utilization of GitLab through RPM packages provide a robust framework for both the installation of the platform and the automation of software packaging. By meticulously managing dependencies and repository configurations, administrators can deploy GitLab CE in any environment, from fully connected cloud instances to strictly isolated on-premises servers. The synergy between the GitLab Runner and the CI/CD pipeline further allows organizations to treat their infrastructure as code, automating the entire lifecycle of RPM creation—from sourcing the code and compiling the binary to testing the package and deploying it to end-users. This comprehensive ecosystem ensures that version control and software distribution are handled with industrial-grade precision and reliability.

Sources

1. TechBeatly - Install GitLab Offline
2. Balaskas Blog - GitLab CI/CD for Building RPM
3. GitLab Documentation - Install GitLab Runner