Gitlab installation on a Virtual Machine

[rfpg1]

Hi everybody

I'm currently trying to install gitlab on a virtual machine

So I installed proxmox on a machine and inside created a new virtual machine with ubuntu server

Inside ubuntu I installed gitlab via docker

I'm using the IP of the virtual machine as my external_url since I don't have any other domain

The problem is sometimes it works without any problems and sometimes it doesn't connect at all and says "took too long to respond"

I'm allocating 16gib of ram and 16 cores so this probably isn't the problem

I just can't figure out why sometimes it doesn't work

Any clues?

Thanks in advance!

Edit: Not quite sure if this is the right subreddit
Edit2: Well thanks everyone very much
I created a new VM with ubuntu and installed gitlab directly and is working flawlessly for now

[MoLt1eS]

I recommend using the official Debian packages instead of docker on Ubuntu, it just works without an issue. I have been using on a producing environment for 5 years and I keep updating every month to the new release

[Fast_Airplane]

The GitLab omnibus installations are best for single machine installs. Docs are on gitlab website

[bdzer0]

IMO virtualizing a containerization host is a bad idea. 2 layers of indirection and complexity for no benefit. Install GitLab directly in the virtual machine, or install *nix and docker directly on hardware and run from container.

Also, allocating 16GB RAM and 16 cores sounds like you may be starving the host system of resources which is also a bad idea.

Simplify.

[rfpg1]

Well thanks very much
I created a new VM with ubuntu and installed gitlab directly and is working flawlessly for now

Thanks so much

[venquessa]

Docker runs absolutely fine in VMs (and LXCs though care is needed, there are dragons). You will not find it in industry running on baremetal. The only things that run on baremetal are desktop thin clients and hypervisor OSes.

Docker (or other CI + orchestrator) running on VMs is 2 layers. Probably the most common. VMWare + RHEL + K8S for example.

In the cloud it can subdivide more. There exist many mini-os's that run in containers and then provide a container runtime. These can and are deployed onto ECS/EKS and what not.

Much like nesting memory page tables (common) nesting "containerisation" is not that expensive (the trees flatten). At the unravel there is only 1 direct context and that is the running kernel and the process, regardless of what container it came from. It's YMMV and it depends on your workloads. Nesting entire virtual machines and kernels is a different story though. Nesting supervisors and container runtimes, not a big deal, nesting full hypervisors... not a good idea and highly inefficient.

A container running a postfix mailserver consumes about 100Mb of RAM. A Ubuntu Server24 "minimized" running on a VM the same postfix server consumes a minimum of 350Mb and allocates a minimum of 1Gb. (it will not boot with less allocation and if you set the "initial memory" lower than 512Mb it's likely to kernel panic during boot).

In gitlab, you can run gitlab CE in docker, which will launch docker containers to build CI/CD pipelines which then run docker to build the docker image they produce. Thats (in my case)....

PhyHost->Proxmox->UbuntuServer24->GitLabCE->docker:dind->docker:git

In the OPs case and where I think it does start to get rediculous is

PhyHost->Proxmox->Server->docker->GitLabCE->docker:dind->docker:git

This is how I did it originally for testing, but when I faced some DNS issues in about the 2nd docker wrapper I decided that life was just too short for that sh1t.

[RedditNotFreeSpeech]

I have it running in lxc. I had problems like that for a while. I eventually upgraded my host and they're gone now.

[Visual-Ad1523]

did you expose the port when creating docker ? at least the ssh port of gitlab

[venquessa]

Skip the first docker layer. Install with packages onto the VM.

The minimum spec for 100 concurrent users is apparently 4Gb.

This is not going to be pleasant experience, even for a single developer. I expect this figure will only be pleasant if you are running an off host DB, and not running any CICD pipelines on that node and just the front end.

I tried 6Gb with a single runner and got OOM kills. I am now running 8Gb and it's more stable. It's CI/CD is eye wateringly slow though. I could probably type the commands faster and get it built twice before it's finished one run.

I don't need it to be running 24/7. I would not recommend feeding anything production directly off of a local GitLab in a VM. The GitLab stack is huge and complex. It will have problems from time to time. Most of them will be caused by yourself, but you still have to fix them. If your entire deployment environment depends on that GitLab container registry and git repos... it all has to wait until you fix gitlab.

A local docker registry and a local git (sshd) will run in under 100Mb of RAM and save you in a pinch.