In this article by Jeroen van Baarsen, the author of the book GitLab Cookbook, we will see how we can manage GitLab. We look at procedures to update GitLab and also concentrate on troubleshooting problems faced.
(For more resources related to this topic, see here.)
When running your GitLab installation, you need to update it every once in a while. GitLab is released every 22nd day of the month, so around the end of the month would be a nice time to update! The releases on the 22nd day are well tested, as gitlab.com is using the release candidates in production all the time. This way, you can be sure that the release meets the standards of the GitLab team!
In this chapter, we will take a look at how you can update your GitLab server and how you can create backups and restore them.
If you want to know what has changed in the new release, you can take a look at the change log provided in the repository for GitLab at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.
In this article, we will take a look at how you can update your GitLab installation when you install it via the Omnibus package. In this article, I’ll make the assumption that you’re using Ubuntu 12.04. You can use other Linux distributions; the steps for these can be found at about.gitlab.com.
Let’s update the Omnibus installation with the following steps:
$ sudo gitlab-ctl stop unicorn
$ sudo gitlab-ctl stop sidekiq
$ sudo gitlab-rake gitlab:backup:create
$ wget https://downloads-packages.s3.amazonaws.com/ubuntu-12.04/gitlab_7.1.1-omnibus.1-1_amd64.deb
sudo dpkg -i gitlab_x.x.x-omnibus.xxx.deb
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
On the 22nd day of every month, a new version of GitLab is released. This also includes the Omnibus package. As the installation of Omnibus based on GitLab does not take very long, the GitLab team has decided to install a new version of GitLab and preserve the old data of the old installation; this way, you don’t go over an update process, but you will be guided through the installation process as if you’re installing a new GitLab instance.
So, when you’re updating an Omnibus-based installation, you’re not really updating but rather installing a newer version and reconfiguring it to use the old data.
One thing you have to keep in mind is that making backups is very important. As any update can go wrong at some level, it’s a good feeling to know that when stuff goes wrong, you always have a backup that you can use to get back up and running as quickly as possible.
Updating used to be a lot of work; you had to open the update document to find out that you need to perform about 15 steps to upgrade your GitLab installation.
To tackle this issue, the GitLab team has created a semiautomatic upgrader. When you run the upgrader, it will check whether there is a new minor version. If there is, it will start the upgrade process for you. It will perform database migrations and update config files for you.
Upgrade your source installation with the following steps:
$ cd /home/git/gitlab
$ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
$ sudo service gitlab stop
$ if [ -f bin/upgrade.rb ]; then sudo -u git -H
ruby bin/upgrade.rb; else sudo -u git -H
ruby script/upgrade.rb; fi
$ sudo service gitlab start && sudo service nginx restart
$ sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
$ cd /home/git/gitlab-shell
$ sudo -u git -H git fetch
sudo -u git -H git checkout v1.9.4
It is highly recommended that you create a backup before you run the upgrader as every update can break something in your installation. It’s a good feeling to know that when all goes wrong, you’re prepared and can roll back the upgrade using the backup.
When your GitLab instance does not work the way you expect it to work, it’s nice to have a way to check what parts of your installation are not working properly. In this article, we will take a look at the self-diagnostic tools provided by GitLab.
Learn how to troubleshoot your GitLab server with the following steps:
The first case shows troubleshooting in the case of a GitLab source installation.
$ cd /home/git/gitlab
$ sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
$ sudo-u git -h bundle exec rake gitlab:satellites:create RAILS_ENV=production
The next few steps concentrate on troubleshooting in the case of the Gitlab Omnibus installation.
$ sudo gitlab-rake gitlab:check
$ sudo gitlab-rake gitlab:satellites:create RAILS_ENV=production
$ sudo gitlab-ctl tail
When you think your GitLab installation might not be in a good shape or you think you’ve found a bug, it’s always a good idea to run the self-diagnostics for GitLab. It will tell you whether you’ve configured GitLab correctly and whether everything is still up to date.
Here is a list of what will be checked:
This is the first place you should start when walking into problems. If this does not give you the correct answers, you can open an issue on the GitLab repository (https://gitlab.com/gitlab-org/gitlab-ce). Make sure you post the output of this check as well, as you will most likely be asked to post it anyway.
It’s important that you have your source code secured so that when your laptop breaks down—or even worse, the office got destroyed—the most valuable part of your company (besides the employees, of course) is still intact. You’ve already taken an important step into the right direction; you set up a Git server so that your source code has multiple places to live. However, what if that server breaks down?
This is where backups come into play! GitLab Omnibus makes it really easy to create backups. With just a simple command, everything in your system gets backed up: the repositories as well as the databases. It’s all packed in a tar ball, so you can store it elsewhere, for example, Amazon S3 or just another server somewhere else.
In this article, we not only created a backup, but also created a schema to automatically back up the creation using crontabs. This way, you can rest assured that all of your code gets backed up every night.
In the following steps, we will set up the backups for GitLab:
The first few steps concentrate on the GitLab source installation.
cd /home/git/gitlab
bundle exec rake gitlab:backup:create RAILS_ENV=production
The backup will now run. This might take a while depending on the number of repositories and the size of each repository.
The backups will be stored in the /home/git/gitlab/tmp/backups directory.
Having to create a backup by hand everyday is no fun, so let’s automate the creation of backups using a cronjob file.
$ sudo -u git crontab -e
0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production
The next few steps talk about the GitLab Omnibus installation.
$ sudo gitlab-rake gitlab:backup:create
A backup is now created in the $ /var/opt/gitlab/backups directory.
$ ls /var/opt/gitlab/backups/
You should see at least one filename, such as 1404647816_gitlab_backup.tar. The number in the filename is a timestamp, so this might differ in your case.
Now we know how to create the backup. Let’s automate this via a cronjob file.
$ crontab -e
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create
After you save the file, a backup will be created every day at 2 A.M. This is great, but there is a tiny catch; if you have the backups run for too long, it will take up all of your disk space. Let’s fix this!
gitlab_rails['backup_keep_time'] = 604800
$ sudo gitlab-ctl reconfigure
If your server breaks down, it is nice to have a backup. However, it’s a pain when it’s a full day’s work to restore that backup; it’s just a waste of time.
Luckily, GitLab makes it super easy to restore the backup. Retrieve the backup from your external Amazon S3 storage or just your external hard drive, copy the file to your server, and run the backup restore command. It won’t get any easier!
Make sure you have a recent backup of your GitLab instance. After you restore the backup, all the data created between the backup creation and the restoration of your backup will be lost.
Let’s restore a backup using the following steps:
The next few steps concentrate on the GitLab source installation.
$ cd /home/git/gitlab
$ cd /home/git/gitlab/tmp/backups
$ cd /home/git/gitlab
$ bundle exec rake gitlab:backup:restore RAILS_ENV=production BACKUP=1234567
The next few steps concentrate on the GitLab Omnibus installation.
$ cp 1407564013_gitlab_backup.tar /var/opt/gitlab/backups/
$ sudo gitlab-ctl stop unicorn
$ sudo gitlab-ctl stop sidekiq
$ sudo gitlab-rake gitlab:backup:restore BACKUP=TIMESTAMP_OF_BACKUP
$ sudo gitlab-ctl start
It’s quite simple to import your repositories from somewhere else. All you need to do is create a new project and select the repository to be imported. In this article, we will take a look at how this is done. For this article, we will import the repository hosted on GitHub at https://github.com/gitlabhq/gitlab-shell.
In the following steps, we will import a repository:
https://github.com/gitlabhq/gitlab-shell
There is really nothing magical about importing a repository. All GitLab does is clone the URL you give it to its own satellite. After this is done, the satellite will be linked to your project, and you’re done!
What if your repository is private and not publicly accessible? You can import it by adding the user credentials in the URL. Don’t worry; this information is not stored anywhere!
So, if we have the same repository as the one we used earlier but it has credentials, it will look like what is shown in https://username:password@github.com/gitlabhq/gitlab-shell.
In this article, we learned about the update processes for GitLab. We also got a gist of the ways that we can use to troubleshoot problems faced. The article explains how we can restore and back up an existing repository.
Further resources on this subject:
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…