- Overview
- Module Description - What the module does and why it is useful
- Setup - The basics of getting started with gitlab
- Usage - Configuration options and additional functionality
- Reference - An under-the-hood peek at what the module is doing and how
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
This Puppet module installs and manages Gitlab. It makes use of the provided Omnibus packages and the packagecloud package repositories.
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.
- Package repository (APT or YUM)
- Package
gitlab-ce
orgitlab-ee
(depending on the chosen edition) - Configuration file
/etc/gitlab/gitlab.rb
- System service
gitlab-runsvdir
- Gitlab configuration using
gitlab-ctl reconfigure
Have 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.
class { 'gitlab':
external_url => 'http://gitlab.mydomain.tld',
}
The module also supports Hiera, here comes an example:
gitlab::external_url: 'http://gitlab.mydomain.tld'
gitlab::gitlab_rails:
time_zone: 'UTC'
gitlab_email_enabled: false
gitlab_default_theme: 4
gitlab_email_display_name: 'Gitlab'
gitlab::sidekiq:
shutdown_timeout: 5
If one wants to install Gitlab Enterprise Edition, just define the parameter edition
with the value ee
:
class { 'gitlab':
external_url => 'http://gitlab.mydomain.tld',
edition => '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:
class { 'gitlab':
external_url => 'http://gitlab.mydomain.tld',
gitlab_rails => {
'webhook_timeout' => 10,
'gitlab_default_theme' => 2,
},
logging => {
'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:
gitlab::secrets:
gitlab_shell:
secret_token: 'asecrettoken1234567890'
gitlab_rails:
secret_token: 'asecrettoken123456789010'
gitlab_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:
gitlab::gitlab_rails:
ldap_enabled: true
ldap_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 externaly.
classes:
- gitlab::cirunner
gitlab::cirunner::concurrent: 4
gitlab::cirunner::metrics_server: "localhost:8888"
gitlab_ci_runners:
gitlab::cirunner::default_token: '1234567890abcdef'
gitlab::cirunner::default_url: https://git.example.com/ci
gitlab::cirunner::docker_runners:
test_runner1:{}
test_runner2:{}
test_runner3:
url: "https://git.alternative.org/ci"
token: "abcdef1234567890"
gitlab::cirunner::docker::default_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:
class { 'gitlab':
external_url => 'https://gitlab.mydomain.tld',
nginx => {
redirect_http_to_https => true,
},
}
Similarly, the certificate and key location can be configured as follows:
class { 'gitlab':
external_url => 'https://gitlab.mydomain.tld',
nginx => {
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.
gitlab::custom_hook { 'my_custom_hook':
namespace => 'my_group',
project => 'my_project',
type => 'post-receive',
source => 'puppet:///modules/my_module/post-receive',
}
or via hiera
gitlab::custom_hooks:
my_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.
gitlab::global_hook { 'my_custom_hook':
type => 'post-receive',
source => 'puppet:///modules/my_module/post-receive',
}
or via hiera
gitlab::global_hooks:
my_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.
- Fork it (https://github.com/voxpupuli/puppet-gitlab/fork)
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create a new Pull Request
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.