Default variable details
Some of debops.gitlab
default variables have more extensive configuration
than simple strings or lists, here you can find documentation and examples for
them.
gitlab__ssl_symlinks
GitLab Omnibus uses private keys and X.509 certificates provided in the
/etc/gitlab/ssl/
directory to configure encrypted connection support
inside of its environment. The gitlab__ssl_*_symlinks
variables can be used
to create symlinks to the private keys and certificates stored elsewhere in the
filesystem; this is used to integrate GitLab Omnibus with the PKI
infrastructure managed by the debops.pki Ansible role.
Examples
You can see the default set of private key and X.509 certificate symlinks
defined in the gitlab__ssl_default_symlinks
variable.
Syntax
The variables are defined as a list of YAML dictionaries, with specific parameters:
link
Required. Name of the symlink in the
/etc/gitlab/ssl/
directory which will point to a specific resource. GitLab Omnibus expects the*.key
and*.crt
files respectively, with names based on the DNS names used for different resources, for example the service addresses.src
Required. Absolute path to a file which will be symlinked to in the
/etc/gitlab/ssl/
directory.state
Optional. If not specified or
link
, a given symlink will be created or updated if necessary. Ifabsent
, a given symlink will be removed.
gitlab__configuration
The gitlab__*_configuration
variables define the contents of the
/etc/gitlab/gitlab.rb
configuration file, used to configure GitLab
Omnibus installation. You can find an example configuration file with complete
contents in the /opt/gitlab/etc/gitlab.rb.template
file, which might be
useful as a reference. You can also use online GitLab Omnibus documentation
to find more details about configuring GitLab Omnibus.
The role uses Universal Configuration system to integrate the default and inventory variables during configuration file generation.
Examples
You can see the default configuration defined in the role in
gitlab__default_configuration
variable to see examples of various
configuration options.
Syntax
The variables are defined as lists of YAML dictionaries, each entry can configure either a simple variable, a list or a "section" of configuration options. Entries are defined using specific parameters:
name
Required. Name of the variable to define in the configuration file, or a configuration section (for example
gitlab_rails
) if theoptions
parameter is also included. Configuration entries with the samename
parameter are merged together and can affect each other.title
Optional. String or YAML text block with a short "title" comment which describes a given option.
comment
Optional. String or YAML text block with a longer "description" comment.
value
The value of a given configuration option. It can be a string, a number, a boolean variable or a YAML list (usually with strings).
raw
If the
raw
parameter is specified, thename
andvalue
parameters are not included in the generated configuration file. The contents of theraw
parameter (string or YAML text block) will be included in the generated configuration file as-is. You can use Jinja inside of theraw
parameter to augment generated configuration as needed. This is useful with more complex configuration options such as dictionaries or Ruby code.state
Optional. If not specified or
present
, a given configuration option will be included in the generated file. Ifabsent
, a given configuration option will not be included in the finished file. Ifcomment
, the option will be included but commented out. Ifignore
, a given configuration entry will not be evaluated during role execution.separator
Optional. Add an empty line before a given configuration option, for aesthetic purposes.
options
Optional. A list of configuration options which belong to a given "section" (in Ruby terms, keys and values of a given dictionary). Each element of the list is a YAML dictionary with the same paraneters as the main configuration; the
name
parameter specifies the dictionary key andvalue
orraw
parameters can be used to define it.