My comment about using Core was just meant to say that the VM should be Core + Omnibus and not Core + Posgresql + Omnibus.
Regarding the config options 1-2...these are not GitLab OOTB. They are all ready-to-go but you need to do a few things to enable them. I just thought I would put them on the radar for the VM confconsole / wizard. E.g. Mattermost needs a unique domain...could be prompted for in the confconsole / wizard. AWS requires some credentials and bucket info to be added to multiple places in config files...again...could be prompted for in the confconsole / wizard.
Regarding option 3...the SSL just needs to be sorted. There are a number of places SSL certs need to be added to GitLab config files. Deciding to rely solely on TKLX LetsEncrypt + auto config file updates vs. enabling GitLab native LetsEncrypt is the only thing that needs a bit of thought.
I consider swapdisk to be mandatory. The issue is that GitLab like most (if not all) Linux apps does not moderate its RAM usage. No matter how much RAM you add you risk an OOM kill. The main culprit is C.I. jobs and artifacts. Because jobs can be long running you can have an OOM kill situation on a live system with no reasonable way of addressing it. The RAM disk is insurance. Additionally, AWS has economic flexibility on disk but not RAM. You have to unnecessarily jump an insance size to get more RAM. A decent size GitLab works fine on a Medium T3. Doubling the cost to a large instance is an unnecessary cost for a C.I. triggered short-term RAM overrun. I have already implemented and documented the process for adding a RAM disk. It is quite simple actually (after I did all the research of course).
You bring the VM build knowledge and I will bring the GitLab knowledge. Between the two of us we could have the first pass VM in place within 24 hours and then go from there to decide how much additional effort would be required for release.
Followup...
My comment about using Core was just meant to say that the VM should be Core + Omnibus and not Core + Posgresql + Omnibus.
Regarding the config options 1-2...these are not GitLab OOTB. They are all ready-to-go but you need to do a few things to enable them. I just thought I would put them on the radar for the VM confconsole / wizard. E.g. Mattermost needs a unique domain...could be prompted for in the confconsole / wizard. AWS requires some credentials and bucket info to be added to multiple places in config files...again...could be prompted for in the confconsole / wizard.
Regarding option 3...the SSL just needs to be sorted. There are a number of places SSL certs need to be added to GitLab config files. Deciding to rely solely on TKLX LetsEncrypt + auto config file updates vs. enabling GitLab native LetsEncrypt is the only thing that needs a bit of thought.
I consider swapdisk to be mandatory. The issue is that GitLab like most (if not all) Linux apps does not moderate its RAM usage. No matter how much RAM you add you risk an OOM kill. The main culprit is C.I. jobs and artifacts. Because jobs can be long running you can have an OOM kill situation on a live system with no reasonable way of addressing it. The RAM disk is insurance. Additionally, AWS has economic flexibility on disk but not RAM. You have to unnecessarily jump an insance size to get more RAM. A decent size GitLab works fine on a Medium T3. Doubling the cost to a large instance is an unnecessary cost for a C.I. triggered short-term RAM overrun. I have already implemented and documented the process for adding a RAM disk. It is quite simple actually (after I did all the research of course).
You bring the VM build knowledge and I will bring the GitLab knowledge. Between the two of us we could have the first pass VM in place within 24 hours and then go from there to decide how much additional effort would be required for release.
I'm ready when you are :-)
Cheers,
Tim (Managing Director - OnePressTech)