Name: puppet-gitlab
Owner: Vox Pupuli
Description: Puppet module to manage Gitlab (Omnibus)
Created: 2015-05-29 08:46:28.0
Updated: 2018-01-16 18:17:24.0
Pushed: 2018-01-15 14:27:34.0
Homepage: null
Size: 325
Language: Puppet
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This Puppet module installs and manages Gitlab. It makes use of the provided Omnibus packages and the packagecloud package repositories.
Please note: The module vshn/gitlab has been deprecated and is now available under Vox Pupuli puppet/gitlab.
The module installs the Gitlab package from the provided repositories and creates the configuration file
which is then used by gitlab-ctl reconfigure to configure all the services. Fun fact: This really uses
Chef to configure all the services.
Supported are Debian based (Ubuntu, Debian) and RedHat based (CentOS, RHEL) operating systems.
Beaker acceptance tests are run in Travis for CentOS 6 and Ubuntu 12.04.
As Gitlab is providing the package repo since 7.10+, this module only works with CE edition greater than 7.10. Also the enterprise edition package is only available since 7.11+. So the EE is supported with versions greater than 7.11.
gitlab-ce or gitlab-ee (depending on the chosen edition)/etc/gitlab/gitlab.rbgitlab-runsvdirgitlab-ctl reconfigureHave a look at the official download page for the required prerequisits (f.e. Postfix). This module doesn't handle them, that's the job of the specific modules.
It requires only the puppetlabs-apt module when using it under
a Debian based OS and the paramater manage_package_repo is not false. Furthermore the stdlib module is required.
At least on RedHat based OS versions, it's required that Puppet is configured with
the stringify_facts setting set to false (Puppet < 4.0), otherwise
the $::os fact used in install.pp doesn't work as expected.
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.
s { 'gitlab':
ternal_url => 'http://gitlab.mydomain.tld',
The module also supports Hiera, here comes an example:
ab::external_url: 'http://gitlab.mydomain.tld'
ab::gitlab_rails:
me_zone: 'UTC'
tlab_email_enabled: false
tlab_default_theme: 4
tlab_email_display_name: 'Gitlab'
ab::sidekiq:
utdown_timeout: 5
If one wants to install Gitlab Enterprise Edition, just define the parameter edition with the value ee:
s { 'gitlab':
ternal_url => 'http://gitlab.mydomain.tld',
ition => 'ee',
Note: This works only for Gitlab version 7.11 and greater. See this blog entry: GitLab 7.11 released with Two-factor Authentication and a publicly viewable Enterprise Edition
To find the default values, have a look at params.pp. All other parameters are documented
inside init.pp.
The main class (init.pp) exposes the configuration sections from the gitlab.rb configuration file
as hashes. So if there are any parameter changes in future versions of Gitlab, the module should support
them right out of the box. Only if there would be bigger changes to sections, the module would need
some updates.
All possible parameters for gitlab.rb can be found here: gitlab.rb.template
Some examples:
s { 'gitlab':
ternal_url => 'http://gitlab.mydomain.tld',
tlab_rails => {
'webhook_timeout' => 10,
'gitlab_default_theme' => 2,
gging => {
'svlogd_size' => '200 * 1024 * 1024',
To manage /etc/gitlab/gitlab-secrets.json the parameter secrets accepts a hash.
Here is an example how to use it with Hiera:
ab::secrets:
tlab_shell:
secret_token: 'asecrettoken1234567890'
tlab_rails:
secret_token: 'asecrettoken123456789010'
tlab_ci:
secret_token: null
secret_key_base: 'asecrettoken123456789011'
db_key_base: 'asecrettoken123456789012'
Hint 1: This secret tokens can be generated f.e. using Ruby with SecureRandom.hex(64), or
taken out of an installation without having secrets used.
Hint 2: When using the gitlab_ci parameter to specify the gitlab_server, then this parameters
must be added also to the secrets hash (Omnibus overrides gitlab-secrets.json).
Here is an example how to configure LDAP using Hiera:
ab::gitlab_rails:
ap_enabled: true
ap_servers:
myldapserver:
label: 'Company LDAP'
host: 'ldap.company.tld'
port: 389
uid: 'uid'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'MYBINDDN'
password: 'MYBINDPW'
active_directory: false
allow_username_or_email_login: false
block_auto_created_users: false
base: 'MYBASEDN'
group_base: 'MYGROUPBASE'
user_filter: ''
Here is an example how to configure Gitlab CI runners using Hiera:
To use the Gitlab CI runners it is required to have the garethr/docker module.
$manage_docker can be set to false if docker is managed externally.
ses:
gitlab::cirunner
ab::cirunner::concurrent: 4
ab::cirunner::metrics_server: "localhost:8888"
ab_ci_runners:
st_runner1:{}
st_runner2:{}
st_runner3:
url: "https://git.alternative.org/ci"
registration-token: "abcdef1234567890"
ab_ci_runners_defaults:
l: "https://git.example.com/ci"
gistration-token: "1234567890abcdef"
ecutor: "docker"
cker-image: "ubuntu:trusty"
Configuration of the embedded NGINX instance is handled by the /etc/gitlab/gitlab.rb file. Details on available configuration options are available at http://doc.gitlab.com/omnibus/settings/nginx.html. Options listed here can be passed in to the nginx parameter as a hash. For example, to enable ssh redirection:
s { 'gitlab':
ternal_url => 'https://gitlab.mydomain.tld',
inx => {
redirect_http_to_https => true,
Similarly, the certificate and key location can be configured as follows:
s { 'gitlab':
ternal_url => 'https://gitlab.mydomain.tld',
inx => {
ssl_certificate => '/etc/gitlab/ssl/gitlab.example.com.crt',
ssl_certificate_key => '/etc/gitlab/ssl/gitlab.example.com.key'
Manage custom hook files within a GitLab project. Custom hooks can be created as a pre-receive, post-receive, or update hook. It's possible to create different custom hook types for the same project - one each for pre-receive, post-receive and update.
ab::custom_hook { 'my_custom_hook':
mespace => 'my_group',
oject => 'my_project',
pe => 'post-receive',
urce => 'puppet:///modules/my_module/post-receive',
or via hiera
ab::custom_hooks:
_custom_hook:
namespace: my_group
project: my_project
type: post-receive
source: 'puppet:///modules/my_module/post-receive'
Since GitLab Shell 4.1.0 and GitLab 8.15 Chained hooks are supported. You can create global hooks which will run for each repository on your server. Global hooks can be created as a pre-receive, post-receive, or update hook.
ab::global_hook { 'my_custom_hook':
pe => 'post-receive',
urce => 'puppet:///modules/my_module/post-receive',
or via hiera
ab::global_hooks:
_custom_hook:
type: post-receive
source: 'puppet:///modules/my_module/post-receive'
The Gitlab CI runner installation is at the moment only tested on Ubuntu 14.04.
git checkout -b my-new-feature)git commit -am 'Add some feature')git push origin my-new-feature)Make sure your PR passes the Rspec tests.
Have a look at Github contributors to see a list of all the awesome contributors to this Puppet module. <3 This module was created and maintained by VSHN AG until the end of 2017. It was then donated to Voxpupuli so that a broader community is able to maintain the module.