What do we have today? How to deal with GitLab, one of the UI tool for Git core. Unfortunately, I'm too bad with git so please tolerate on my knowledge with git activities (actually I won't mentioned anything about git commands here ... hehehe)
Alright, today I will give some detail how to setup GitLab then migrate old GitLab to a newer version, instance.
Alright, today I will give some detail how to setup GitLab then migrate old GitLab to a newer version, instance.
Setup GitLab
GitLab did an superior task on their documentation, just follow their guide then you will be good. So a quick recap from the document to install GitLab EE on Ubuntu 16.04
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates postfix mailutils sasl2-bin
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://gitlab.example.com" apt-get install gitlab-ce
So I will use postfix as an relay email server. This is a painful side quest. To configure postfix, you might need to learn more from beside this post. I only note down how to relay email with Office365. You can refer to this guide for a huge configuration with postfix. I only need to update the configuration file at /etc/postfix/main.cf for the email forwarding rule to my Office365 domain, also the email account to access the smtp version.
Create the credential access to smtp server, create /etc/postfix/sasl_passwd
[smtp.office365.com]:587 usernameOffice365@domainOffice365.it:password
Then use postmap tool to create the hashmap database file
postmap hash:/etc/postfix/sasl_passwrd
We will also need to create a forwarding rule to use an existing account from Office365 as the sender. Create /etc/postfix/sender_canonical
/.+/ gitlab@domainOffice365.it
Then create the hash map database for this too
postmap hash:/etc/postfix/sender_canocical
Make sure root user will have 644 permission on those file so postfix service can access to those data
Update those configuration into /etc/postfix/main.cf
inet_protocols = ipv4
relayhost = [smtp.office365.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
sender_canonical_maps = regexp:/etc/postfix/sender_canonical
smtp_use_tls = yes
Make sure you have the smtp_sasl_security_options line, I got some problem with the sasl issue, to test the email setup
echo "Mail body" | mail -s "Mail subject" youremail@domainOffice365.it
That should be good for postfix configuration, now take a look at gitlab configuration at /etc/gitlab/gitlab.rb. I only need to change the datastore and backup path
gitlab_rails['backup_path'] = "/my/backups"
gitlab_rails['backup_keep_time'] = 24 * 60 * 60 # 1 day
git_data_dir "/my/gitlab/git-data"
Then run
sudo gitlab-ctl reconfigure
Then setup a cron job for the daily backup data. Now you should be good with the new instance.
Migrate GitLab
You will find most of the guidelines will ask to upgrade to the latest version first then migrate to the new server. However, I have to work on my production server so there is no room for failure, then I will do a different way, means I will install the new server with the same version of my old server, do the migration then upgrade the new server to my desired version. My current server is 9.x CE version and I want to migrate to new server instance with 11.x EE. Here are the steps:
- Install new instance with the old version 9.x CE
- Copy the /etc/gitlab/gitlab-secrets.json (if you use 2 Factor Authentication - 2FA)
- Adjust the configuration from old Gitlab to new instance (/etc/gitlab/gitlab.rb)
- Backup the current data image: sudo gitlab-rake gitlab:backup:create
- Copy the data backup into the backup_path in your configuration in the new server (there is a trick here because the backup file is owned by the local git user which created via Gitlab installation)
- Restore the data:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
sudo gitlab-rake gitlab:backup:restore BACKUP=backup_file (the backup file name without _gitlab_backup.tar)
- Upgrade to 11.x EE version
There is a huge gap between 9.x CE vs 11.x EE so you have to upgrade to the latest 10.x (it should be 10.8.7) EE in between. You have to remove any incompatible configuration in gitlab.rb (in order to let gitlab service running - gitlab-ctl reconfigure). If you encounter error 502, then there is a case (in my case) that gitlab-workhorse can't talk to unicorn, to fix this, remove the comment of those lines in /etc/gitlab/gitlab.rb
unicorn['socket'] = '/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
gitlab_workhorse['listen_addr'] = "/var/opt/gitlab/gitlab-workhorse/socket"
Run gitlab-ctl reconfigure to apply the change.
Then upgrade to 11.x EE version, in version 11, Gitlab has moved to prometheus 2.x so you have to upgrade the prometheus with
unicorn['socket'] = '/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
gitlab_workhorse['listen_addr'] = "/var/opt/gitlab/gitlab-workhorse/socket"
Run gitlab-ctl reconfigure to apply the change.
Then upgrade to 11.x EE version, in version 11, Gitlab has moved to prometheus 2.x so you have to upgrade the prometheus with
sudo gitlab-ctl prometheus-upgrade
To make sure everything is update with
sudo gitlab-ctl reconfigure
This is it! I have done the setup with my Ansible script like the other topics then manually upgrade as mentioned above. The most tricky part is to copy the data backup file to new machine with different owner permission and upgrade to 11.x EE version. Other then that, GitLab did a perfect job on the documentation and scripts. I have not yet rollout my new production server yet, but those few weeks ago, it's running fine with the daily backup.
You can take a look at this guide to find more information on the logging system.
You can take a look at this guide to find more information on the logging system.
Happy reading and nice rainy weekend, friends!
Comments
Post a Comment