Support for omnibus package installation

[roddhjav]

First thank a lot for this amazing work.

The actual installation follows the manual installation method. This method has the following issues:

• Long to run
• Complex to maintain
• Backups from package installation are not compatible with source installation

Is there a way to support the installation using the gitlab package server as described in gitlab's website?

[drybjed]

Hello, I'm glad that you like it. :-)

The upstream GitLab Omnibus packages manage a "full stack" installation of GitLab, with their own version of Ruby, a webserver, a database server, Redis, and so on. These services are started and managed by the package, and will most likely conflict with the operating system services you might have installed. In contrast, debops.gitlab role was designed to be applied on hosts or infrastructure with existing services (managed by DebOps as well) - for example you can install a GitLab instance alongside DokuWiki, phpIPAM or Netbox (already included in DebOps) without much issues. By using existing DebOps roles, it also seamlessly can be incorporated with other existing infrastructure, like internal PKI (or ACME certificates via debops.pki).

Support for GitLab Omnibus packages would require at least partial duplication of other DebOps roles inside debops.gitlab to allow for configuration of all of the included services. I don't plan to do that at this time, and writing a separate role from scratch probably seems as a better idea anyway. You can check out samdoran's GitLab role to see what would be needed for this to work.

As for alternative installation, it seems that a Debian gitlab package will be available in the Debian Stretch release - although most likely it will be in a "stabilized" state, ie. no new features every month. I might consider adding support for that version as the default, leaving the upstream, manual method optional after the Stretch release, in accordance with the DebOps Software Source Policy.

And to answer your specific complaints... The playbook speed heavily depends on the processing speed of the involved systems - if a given installation takes a long time, you might want to try it on a beefier system with more CPU cores/RAM. Keep in mind that some DebOps roles like debops.dhparam might take a long time to complete on the first run in a given environment, but subsequent runs might be faster. The playbook runtime is also heavily dependent on number of roles enabled on a host - perhaps try installing GitLab separately on a host to see if lower number of roles involved will speed up the process.

As for the complexity - the GitLab Omnibus package isn't some "magic bullet" which takes complexity out of the equation. The package uses the same services as regular installation, only wrapped in a post-inst and configuration scripts. The playbook does basically the same thing, only here you can see all of the involved roles and their relationships.

If some things feel complex, we could try to fix it in the involved roles themselves, which will benefit other projects and environments based on DebOps. Unfortunately more automation and ease of use comes with a bigger complexity, so I don't see that happening anytime soon.

I didn't know about backup incompatibility between source and package installation. Do you know if it's a bug, or is it intentional? Perhaps the debops.gitlab role could be changed to fix this issue?

[roddhjav]

Thanks for these many clarifications. I think I will use debops.gitlab. It is the more integrated with debops services. The integration with other debops services (ferm, log, update, apparmor, nginx, pki...) is one of the reason I use debops.

For the complexity I meant when using Gitlab Omnibus it is the Gitlab job to maintain it not yours. This is not really a concern for a debops user as me. But what if you stop maintaining it?

There is not really a backup incompatibility more a lack of documentation (see gitlab doc )

[drybjed]

I'm using the project at work (eating my own dogfood) so I don't plan to stop maintaining it anytime soon. Also, the project is set up in such a way that control over it could be switched to another person if needed be (separate GitHub organization, a keyring repository that defines who has write and management access, etc.) so if the time comes to move on, it should be possible to pass the project along.

[roddhjav]

Ok, perfect, thank for the quick response !