Allow external_url to be optional to support HA configurations

[MichaelGerhart]

The problem I am encountering:

Currently, I am trying to automate the deployment of an HA Gitlab EE instance. This means I need at least two Gitlab App only app servers. and 3 Redis only app servers. This module forces the installation of the gitlab application on anything it touches.

What I expect:

I want to use gitlab omnibus to configure my Redis cluster, without also installing gitlab along with it. In the future, I would expect the same functionality when the automated gitlab omnibus PG cluster functionality leaves alpha.

[LongLiveCHIEF]

This module configures only Gitlab Omnibus. if you're using omnibus to configure you're various HA nodes, then the omnibus package has to be installed. There's no avoiding that unfortunately.

This is not a side-effect of this module, that's just the nature of the GitLab Omnibus solution.

[MichaelGerhart]

@LongLiveCHIEF I guess I should re-phrase. This module requires that you have a URL specified, if you don't specify one then it creates a default URL.

If you remove that logic, then I can install gitlab omnibus and install ONLY Redis using gitlab.rb, for instance.

"Just include the class and specify at least external_url. If external_url is not specified it will default to the FQDN fact of the system."

[LongLiveCHIEF]

Before HA made it into Omnibus, this was required. As of 10.2, this is now only required on application_role nodes, or non-ha nodes.

In other words, yeah this needs to be done.

I have also been working on HA, and have several merges completed already, with a few outstanding WIP's. I'm going to create a "Gitlab HA Supported" milestone, and add this issue to it.

@MichaelGerhart are you ok with changing the title of this to: "Allow external_url to be optional for HA deployments"?

[LongLiveCHIEF]

So I discovered this week that this config is required even in non-application_role nodes in order for the post-install steps in omnibus to work correctly.

I'm changing the ordering of the manifests in this module (putting config in front of install). When you don't have a valid external_url in your gitlab.rb before a package install or update, then you get a message at the end of the install that says something like:

Could not determine valid hostname for external_url, please update external_url in /etc/gitlab/gitlab.rb then run gitlab-ctl reconfigure

So, thinking through this...

• gitlab-ctl reconfigure is suppossed to run during the install/upgrade
• HA support revolves around this, and gives you two ways to alter this depending on the role of the host
• create /etc/gitlab/skip-auto-reconfigure if it's an application_role deploy node
• set gitlab_rails['auto_migrate'] = false for all other ha roles

So, not having an external_url in the config will wind up causing issues for non-deploy nodes during fresh installs, or during upgrades or scaling events.

Having the external_url doesn't cause any non-needed components to install onto the node if we change the ordering of this module to run host configs and lay down the /etc/gitlab/gitlab.rb before the package is installed updated.

Additionally, this makes sense from an upgrade standpoint. When gitlab is running, changing the gitlab.rb config doesn't impact your installation until a gitlab-ctl reconfigure is run. This is run during package updates automatically, so updating the config after the package will actually cause gitlab-ctl reconfigure to run twice (once by the package manager, and at least once by puppet).

On the flip side, putting config in place prior to the package resource means that not only can we install/enable only the services you want on a node right from the start, but we can begin to support zero-downtime upgrades with this module by enhancing the reconfigure command by adding an env flag for SKIP_POST_DEPLOYMENT_MIGRATIONS=true whenever deploy_node=true