- Had removed sockets_directory method from most places, but needed to
  remove it from the helper and that exposed it being used in one other
  location

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

- Restart workhorse if the socket directory changes. In its own commit
  so it can be reverted by the maintainer if not approved

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

Signed-off-by: Balasankar "Balu" C <balasankarc@autistici.org>

- Remove the workhorse helper methods that are refactored out
- Fix workhorse helper tests

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

- Do not automatically use sockets directory, allow a user to set the
  directory

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

- Adds a suite of rspec tests for the gitlab workhorse helper
- Checks for and removes orphan workhorse socket files if present

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

- Run the SELinux helper after GitLab Workhorse and other files are
  created ensuring their file contexts are restored
- Place GitLab Workhorse socket files into a sockets directory allowing
  the SELinux file context to be inherited on service restarts
- Add a GitLab Workhorse helper to ensure that new UNIX sockets for
  Workhorse always inherit the proper SELinux file context

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

Unlike AWS and Google, Azure needs to use an Azure client inside
Workhorse to support direct uploads. Using standard HTTP transfers with
pre-signed URLs with the Azure Put Blob API
(https://docs.microsoft.com/en-us/rest/api/storageservices/put-blob)
doesn't work because Azure doesn't support chunked transfer encoding.
However, Azure does support uploading files in segments via the Put
Block and Put Block List API
(https://docs.microsoft.com/en-us/rest/api/storageservices/put-block),
but this requires an Azure client.

To support this, this commit extracts the Azure Fog credentials from the
Rails connection information and adds them to the Workhorse
configuration.

This changes requires two merge requests to work:

1. https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/555
2. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38882

Part of https://gitlab.com/gitlab-org/gitlab/-/issues/25877

This adds support for the gitlab.yml changes in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34460. This allows
GitLab to use the Workhorse S3 client with a single credential, enabling
proper MD5 checksums and multipart uploads, and paves the way for
user-specified keys for encrypted buckets.

These changes require
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35480 to work.

Ian Baum authored 4 years ago and DJ Mountney committed 4 years ago

* Incoroporates our changes to the coobkook so we get our desired
  behavior
* Use start_down instead of down
* Stop checking for permissions on log directories. The runit cookbook does not explicitly create this.
* Rename runit control templates. Don't use -control in the name anymore, upstream has removed that
* In the v5 version of the runit cookbook, they are colliding with the chef service properties

Signed-off-by: Balasankar "Balu" C <balasankarc@autistici.org>

When the Consul service is disabled, Omnibus will delete the Consul service so Prometheus will no long try to discover it and collect metrics.

When Consul is enabled on a given node, Omnibus will register each
enabled exporter as a service in Consul. Then, when Consul is enabled on
the Prometheus server, Prometheus will be configured to pull job
configuration from Consul.

Earlier, we replaced gitlab['redis_*'] settings with redis['master_*']
values in sentinel mode. However, this worked only for gitlab-rails and
not for several other services like gitlab-monitor. This commit changes
that and get gitlab-rails the necessary details based on the knowledge
whether sentinels are present or not.

This merge request brings redis[s]:// support to Workhorse and Rails.
This makes it possible for users to set up stunnel to provide encryption
via https://redislabs.com/blog/stunnel-secure-redis-ssl/ or use AWS
ElasticCache.

This also deprecates the tcp:// scheme since it is no longer needed by
Workhorse.

Trusted Redis SSL certificates should be managed by the standard Omnibus
procedure:

https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates

Note that Redis Sentinel does not yet support SSL.
https://github.com/antirez/redis/pull/4855 may bring native support to
Redis 6.0, but time will tell.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47702

Move env directory of all services to /opt/gitlab/etc/<service>/env

This reverts commit eb78019b2ec79babb24160fc379221fba33e5cf4.