We installed Gitlab maybe 7y ago, always making upgrades. Now I was messing around with Pages and found out I’m missing some parameters in the gitlab.rb file.
For example:
# Set this flag to enable this feature
gitlab_pages["namespace_in_path"] = true
It just not there
So I compared my gitlab.rb with original template from Master branch and: mine 80kb and 150kb
Why? i was thinking rb will be the same as I would have been installed a newest version from the scratch.
The config file under /etc/gitlab is not updated automatically, so that is normal. You will have to put the new entries. Also, you can find the current file under /opt/gitlab/etc/gitlab.rb.template and copy from this to your config file.
It’s impossible to automatically determine which settings can be changed, and which depend on the value they have (which might be the old default - that’s a major factor in what makes it hard) in a given deployment, so upgrades leave the config alone (most things work that way, it’s in no way unique to GitLab).
Adding/removals from the default config file are linked to new/removed features, so if you keep an eye on release announcements you shouldn’t get surprises, it will probably be very clear if some setting that used to do something begins causing an error or doing something different.
Understand.. and what is the best way to upgrade gitlab.rb? Manual merge? and then replace and Reconfigure?
The majority of the config options are hashed and defaults anyway, so there is no need to manually merge anything. Just add what you are missing and configure it with the values that you need.
That depends…
But it will probably always end with the steps you outline, i.e. manually merge (e.g. the database password will need to be copied from the old - when that becomes a merge is a question of semantics, so I don’t think I disagree with @iwalker), place your new file as /etc/gitlab/gitlab.rb (or whereever GitLab reads it from) and gitlab-ctl reconfigure - I would probably also restart GitLab completely (with gitlab-ctl restart), and perhaps even reboot the server - but what to do also depends on how SLA you (implicitly) have with the users, some factors that might influence it:
If the defaults have served you well, grabbing the file that @iwalker mentions
My /etc/gitlab/gitlab.rb is also from 2018 so 7 years old as well. If I search and don’t find a certain section in it, I either view the Gitlab documentation, or go to the template under /opt/gitlab/etc/gitlab.rb.template and in that file find the appropriate section I need, and then just copy it to my /etc/gitlab/gitlab.rb.
Sure you could grab that whole file, and then apply all edits that you currently have in your existing /etc/gitlab/gitlab.rb - external_url being one thing that definitely needs to be configured, plus another other stuff you may have customised over the years. Especially if there are things relating to passwords, to the database, or email settings, etc.
The real question is whether you feel it’s necessary to do that or not? Considering it’s easy enough to find stuff in the template file. I would find it too much hassle having to grab that and manually apply back all my customisations which are 20-30 lines if not more. For me it’s just easy to copy what I’m missing if I’m wanting to configure Gitlab Pages, or something else.
When we changed setup some years ago (more redundancy was the keyword) we had to make so many changes that it made sense to start over, so our current gitlab.rb is based on something that is only 2-3 years old, but I guess the one we had before those changes were 6-7 years old (I didn’t maintain GitLab back then, so I don’t know how it was made/handled, but the installation was made around that time.
how easy is to migrate gitlab from one mashine to another? Now I’m on Ubuntu via Omnibus and might move it to Debian LXC, also Omnibus based
LXC is effectively container-based (or at least what they used to call “chroot on steroids”). Some people like running Gitlab in containers, I will never see myself doing that personally as I think it’s just too problematic in terms of administration - eg: upgrades, etc and complicates things more than it really should. But that’s just my opinion.
BTW backups can only be restored to the same version. So if you have an omnibus backup it can only be restored to an omnibus install. Therefore it probably will be difficult if not impossible to attempt restoring omnibus on docker/lxc or vice-versa.
You’ll probably experience more problems with LXC than say using Docker. Also, LXC is not in the list of supported installation options as shown here: Download and install GitLab | GitLab
We run GitLab in a (series of, as I’ve just said we have multiple servers) LXC guest(s) ((all) running Ubuntu jammy, hosted on Ubuntu jammy). When LXC is set up properly, it looks like a virtual machine, and you don’t notice it. In daily operation there’s no difference between running stuff directly on hardware or in an LXC guest, and the installation instructions should just work.
Migrating GitLab is basically (if you really know what you’re doing you can deviate, but you probably wouldn’t be asking about the process here if you were in that category) backing it up on the old host and restoring the backup on the new, and remember as @iwalker says: the versions must be exactly the same, but from omnibus installation to omnibus installation there should only be issues if you try to switch from CE to EE (or the other way round) at the same time.
Exactly, LXC is minimalistic alternative to full-fledged virtual machines, allowing you to isolate processes and applications while sharing the underlying operating system.
And it is not ‘Docker’ at all.
For me LXC is very lightweight (when you create LXC in Proxmox you choose the template and those a basically stripped down linux distros. I choose Debian and it weigts liek 150mb)
I have not much experience but in my point of view it is easier to migrate from full vm to lxc. Underneath it is a small linux with own IP and full shell.
Backup-restore is another topic, you are right. Just thinking how could i refresh my Gitlab and move it (would need to move it soon)
I didn’t say it was docker 
I said:
And from the package management system:
or from a Debian-based system:
which you can clearly see says that it is a containerised system. Purely semantics. If we go back about 15-20 years, LXC or even OpenVZ at the point were seen as chrooted environments rather than being called containers as they are today. Similar in the way apps can be installed as if it was a VM but without the VM overhead. OpenVZ could be more problematic, and did give you the ability to change various parameters to get apps to work. I had tried to run Zimbra email server under OpenVZ but it wouldn’t work without a lot of tweaking. I don’t remember trying it with LXC to see if it would have been the same or not, but I have a feeling LXC didn’t require as much tweaking like OpenVZ could need.
It’s up to you how you choose to run your Gitlab instance though
Maybe
is a good thing to read.
If you would like to run your GitLab instance in a LXC instance go ahead, with the knowledge that someone on an internet forum (i.e. me - but in general you should be wary of what strangers on the internet says) said that it’s easy.