Before I setup GitLab, I did a fair amount of investigation. I found that GitHub and GitLab were common tools that offered, in my opinion, better git integration than Mantis (which I had some previous experience with). As such, I decided to switch off of Manius. After considering GitHub, I decided to use GitLab. There were multiple reasons for this, but the main one was I could host GitLab locally. And while GitHub is free for open source or non-commercial use, the licensing seemed more restrictive. I like the idea of being able to host my own repository and charge for my code in the future, even it that is not a goal today. Other reasons to move off of Mantis were:
- GitLab uses git, which I decided to be my Version Control System
- It has web integration. This means that I can view the changes and track what I am doing on the web.
- It has a basic ticketing system. This means I can put my requirements, bugs, etc. into a backlog.
- It is free
- It supports multiple users. This means as the project grows, I’ll be able to use the same software.
There are a fair amount of documentation on GitLab. I’m not going to repeat it all, but give the links that I found to be chronologically useful.
Also they are very good at maintaining their documentation. I revisited many of these links five years after my post and found them still working.
Setting Up
There are three ways to setup GitLab. One is installing each individual component from source, another is setting up an entire AWS, bitnami, or other “total” system install. The last one, and the one that I went with, was installing an Omnibus install on an existing Linux Server. The this link for full detail.
Word of warning: Omnibus is not cheap on Memory usage (This will come up later). It may be better to use something like Bitnami, or another prebuilt image on a dedicated server if you have the options.
Following the links above, I installed an rpm
https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/7/gitlab-ce-7.12.0~omnibus.1-1.x86_64.rpm
The complete instructions are here:
- https://gitlab.com/gitlab-org/omnibus-gitlab/blob/629def0a7a26e7c2326566f0758d4a27857b52a3/README.md
I ran out of memory reconfiguring, so stopped a couple of processes, then was successfully able to complete the install.
After install, and a reboot. The server showed up on the default port.
So after the site was up and running, I needed to change the external port I was listening on because I was already running a web server on :80.
editing /etc/gitlab/gitlab.rb, by adding the port number at the end, like so:
external_url='http://myurl:myport'
and then running
sudo gitlab-ctl reconfigureNote: Stay away from port 8080. I changed GiLab to run on a different port because of a post I found here:
http://stackoverflow.com/questions/29320022/gitlab-on-port-8080
Edit file as described:
vi /etc/gitlab/gitlab.rb
With the change, my file worked:
## https://gitlab.com/gitlab-org/omnibus-gitlab/blob/629def0a7a26e7c2326566f0758d4a27857b52a3/README.md#configuring-the-external-url-for-gitlab external_url "http://ip-172-31-78-13.us-west-2.compute.internal:XX"
<Where XX is my port>
<and do not be afraid, my URL (ip-172-31-78-13.us-west-2.compute.internal)has also changed too>
After being confused as to why the site showed up as running, but did not seem to be accessible, I remembered that I needed to change the AWS firewall rules to my new port would be served through the AWS firewall.
Next Step is to log into the git server, make changes, etc. As for now. I’ll just turn it off and wait until tomorrow.
… the next day…
So this almost worked. Looking into the system, it seems that everything is sluggish, and sometimes GitLab completely times out with a 404 error even though the server is running.
With more research I found that it is documented as requiring 2GB of RAM min. AWS micro, only has 1GB Total. After rebooting and searching through logs I found out that the site is crashing due to being unable to allocate memory.
As I continues to google, I found I could reduce the memory by changing the number of workers:
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md#unicorn-settings
12/19/2019 – Update – by default unicorn now only uses 2 workers by default. I did a complete uninstall, reinstall, and imported all of my old git repositorieis (I did not port my GitLab “todos”) and it worked wonderfully as a new install/upgrade to GitLab 11.5.4.
Using ps -aux I saw that sidekiq is also running a ton of memory, but no amount of googling would turn up anything definitive on how to change the site… so I left it and googled other items.
I was still crashing.
Then I remembered about Linux’s swap space. I decided to add a swap partition on the HD. Keep in mind this is the HD that is allocated with the t2.micro (8GB).
I created a swap partion
bash$ dd if=/dev/zero of=/mnt/swap bs=1M count=2000 bash$ mkswap /mnt/swap bash$ swapon /mnt/swap bash$ free total used free shared buffers cached Mem: 1020184 937176 83008 22388 1664 46616 -/+ buffers/cache: 888896 131288 Swap: 2097148 0 2097148
Keep in mind that the bs=1M actually means 1024, so the count can be 2000 for a total of 2GB space.
I also added swap to the /etc/fstab so this will happen automatically on reboot.
$ more /etc/fstab # LABEL=/ / ext4 defaults,noatime 1 1 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /mnt/swap swap swap defaults 0 0
I rebooted and swap was till there (and being used)
$ free total used free shared buffers cached Mem: 1020184 941076 79108 22388 2872 50060 -/+ buffers/cache: 888144 132040 Swap: 2097148 124284 1972864
After a conversation with AWS technical support, it seems I will be charged for the I/O on the swap space. As such, I searched for a way to reduce it. Luckily the Linux kernel has an idea of how to adjust how the kernel prioritizes swap space. Here is a good article:
https://en.wikipedia.org/wiki/Swappiness
I used the option of editing the vi /etc/sysctl.conf file and adding a lines
# set the swap preferences: vm.swappiness = 1
After rebooting and launching everything I ran top and logged into the gitlab site:
It still swapped about 2MB of memory, but at least we were not crashing.
I set my swappieness to 1 because I do not want to use it often. I have an open question to AWS tech support to determine some additional ways to monitor the system. If I find I am using too much swap space I’ll move my tier up. However, as it sits today, I’m still on the free tier, so it is good enough for now.
… or so I thought
Just when I was ready to start I realized that I did not actually have a git server installed.
using yum, I installed git on the server and while I was at it, I thought it a good idea to update all of my packages (because now I am actually ready to start).
GitLab, ironically enough, was one of the items that got upgraded. However, it did not function after the update. Scratching my head I simply uninstalled, reinstalled, and reconfigured and everything worked.
It should also be noted that my upgrade did NOT change my /etc/gitlab/gitlab.rb settings. That means I did not need to do any extra effort. Later while searching for something else, I came across a “how to upgrade” page for gitlab.
They suggested using “gitlab-crl upgrade” I was not sure if the errors were due to recently installing git, so I moved on without trying this feature. I am documenting it so I can come back to it when I need to do it again.
– Update 5/31/16 – the :gitlab-crl upgrade” as well as the ‘yum update all” both seem to function and leave my custom settings.
I logged into gitlab, created a project, and started testing how GitLab works.
I simply created a “TestMe” project so I could play with the features without messing up my real project. It was simple enough I did not need to read the documentation, but I figured that for this post I needed to find a tutorial. Here is one that seemed to cover all the items I did on my own:
So, I created a test project. I tired to check out the project, but it failed. GitLab reminded me
“You won’t be able to pull or push project code via SSH until you add an SSH key to your profile”
It also pointed me to a set of instructions that explained how to set the SSH key up, so I will not repeat them here.
An interesting item of note. I am using TortoiseGit for Windows. Logging in can be done from Windows using the same GitLab username/password as was created on the main page. Once the key is established on the GitLab project, it is not needed locally on Windows, it is simply stored on the Server.
–
Now that I have a repository and ticketing system I can enter the requirements, and code to them – I will blog this in detail later. For now, I am done. Wow that took longer than I thought.
:wq! <- (joke)
Update: Two weeks later GitLab still uses enough memory that I am turning it off occasionally. I am still tweaking the configuration while trying to monitor the costs of the AWS server. More will follow(or not), but my next steps might be to edit my cron jobs so that GitLab restarts daily at 4:30AM.
# free total used free shared buffers cached Mem: 1020184 951772 68412 1596 40116 43408 -/+ buffers/cache: 868248 151936 Swap: 2097148 404872 1692276 #sudo gitlab-ctl restart ok: run: logrotate: (pid 7831) 1s ok: run: nginx: (pid 7834) 0s ok: run: postgresql: (pid 7840) 0s ok: run: redis: (pid 7848) 1s ok: run: sidekiq: (pid 7855) 0s timeout: run: unicorn: (pid 1730) 125458s, got TERM # free total used free shared buffers cached Mem: 1020184 653752 366432 19996 22268 78120 -/+ buffers/cache: 553364 466820 Swap: 2097148 49032 2048116