With Microsoft’s acquisition of GitHub in June 2018, it once again became clear that cloud services and thus also the data stored there can quickly change hands.
In addition, a public cloud solution for very sensitive data often isn’t legally permissible. GitLab is a very powerful tool that you can install on your own server.
GitLab Quick Start
To get a first impression of GitLab, you can simply start a GitLab container locally and try out the web interface. Note that all settings and all content created in the test mode will be lost.
docker run -e GITLAB_ROOT_PASSWORD="StrictlySecret" \
--name gitlab -p 8888:80 gitlab/gitlab-ce
-p 8888:80 connects the local port 8888 for access to the web interface. Initializing the database for the first time can take up to five minutes, depending on the performance of your computer.
Because we didn’t start the container in the background, you’ll see the log output in the terminal. When the message gitlab Reconfigured! appears among the messages, you can open your browser with the address http://localhost:8888 and enter the user name root and the password specified under ROOT_PW. Then you can create your first project.
The overview page provides useful tips on how to import an existing Git repository or check out this project in a new folder on your computer. You could also create files directly there, which is also very convenient with the recently introduced Web IDE, but is still an unusual way. Typically, locally installed editors such as Atom, Visual Studio Code (VS Code), Vim, or Emacs are used for developing projects.
To use GitLab in production, you’ll need to adjust some parameters to ensure that your data is stored securely, that encryption works, and that you can enable other features of this impressive program.
GitLab Web Installation
GitLab is a modern web application that consists of various components in different programming languages. Installing from the source code isn’t recommended because it’s very time-consuming and requires various libraries on the system (including Ruby, Go, Node.js, PostgreSQL, and Redis). While there are packages for different operating systems, the more elegant way is to install it with Docker.
The official Docker image from GitLab doesn’t fully comply with the concept of a microservices architecture because databases and program code are packed in the same image and several processes run there in parallel. Because GitLab itself maintains this image very consistently, updates and the greatest possible compatibility are ensured. We’ll also use this image for our setup, but we’ve swapped out the databases (Redis and especially PostgreSQL) to separate containers.
Alternate Setup: Of course, you can also launch the GitLab image as a container running PostgreSQL and Redis alongside the application code. This will give you the highest possible degree of compatibility, as GitLab will undoubtedly test the components extensively in the versions installed there. We’ll describe a distributed setup here to illustrate how straightforward Docker can be to manage various services.
For the following descriptions, it’s necessary that you install GitLab on a server that can be accessed through the internet with a valid domain name. For communication to work smoothly between GitLab, the integrated Docker registry, and GitLab Runner—an outsourced service for builds and tests—it must be encrypted. Although it should be possible to use self-signed certificates for this purpose, our attempts weren’t successful. We’ll therefore use official certificates from Let’s Encrypt, which are managed on the upstream reverse proxy.
We’ll use the following host names for the example:
- dockerbuch.info
- dockerbuch.info
- dockerbuch.info (optional)
Although we only launch one container, we’ll use docker-compose to clearly store the launch parameters in a file. We’ll install GitLab on a server that already has other websites running on HTTPS port 443 using the setup with Nginx as a reverse proxy.
All customizations for the GitLab configuration can be done using the GITLAB_OMNIBUS_ CONFIG environment variable. The advantage of this type of configuration is that no external file needs to be included. GitLab reads the configuration from this environment variable before consulting the actual configuration file /etc/gitlab/gitlab.rb. In the default installation, this file contains only lines that have been commented out, so only the values of the environment variables apply. In the YAML Ain’t Markup Language (YAML) syntax of the docker-compose file, the corresponding excerpt looks like the following (the | pipe character indicates the multiline entry):
# in file gitlab/docker-compose.yml
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'https://gitlab.dockerbuch.info/'
nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"
}
[...]
To prevent the further explanations of the GitLab configuration from becoming too confusing, we’ve distributed the various aspects (reverse proxy, email, Secure Shell [SSH], etc.) across several sections.
Learn more about installing GitLab in this post.
Editor’s note: This post has been adapted from a section of the book Docker: Practical Guide for Developers and DevOps Teams by Bernd Öggl and Michael Kofler.
Comments