A Puppet Module for managing GitLab running on Apache and Passenger
This Puppet module installs, manages and configures the GitLab open source code repository. This module configures GitLab to run on Apache and Passenger using the Puppetlabs Apache Module. Apache is used instead of Ngnix as there are some authorisation models that have already been solved for Apache and not yet resolved for Ngnix.
As GitLab requires Ruby 2.0.0 this module has been developed to work on Ubuntu 14.04LTS which uses this as it's natural Ruby version. Work has been done to try and make it work with Ubuntu 12.04LTS, but runs into issues getting the gems installed correctly.
This module has been used on:
There is a complete install manifest example in the tests directory. An updated version for Gitlab 7.7 is also provided.
The upgrade process is a WORK IN PROGRESS! Don't do it.
...the puppet manifest creates a new database, rather than updating it, which drops everything. (also, yay for test servers that caught this before going into production)
Before upgrading stop Gitlab.
$ service apache2 stop
$ service gitlab stop
Back up Gitlab:
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
On the puppetmaster edit the Puppet Manifest for gitlab, and include new version references and update package dependencies if required:
class{'gitlab':
gitlab_url => 'http://localhost/',
gitlab_app_rev => '7-7-stable',
gitlab_shell_rev => 'v2.4.1',
require => [
Class[
'git',
'postgresql::lib::devel'
],
Package[
'libicu-dev',
'cmake',
'libkrb5-dev'
]
]
}
No don't do that.
Migrate database:
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
Clean up assets and cache:
sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production
Use puppet to restart services and check everything:
puppet agent -t
The following packages are required to get GitLab installed. They're not installed directly by this module in case this interferes with them being managed or required by other modules.
cmake
libicu-dev
For Gitlab 7.7 and later the Kerberos development libraries are also required:
libkrb5-dev
This module provides a base gitlab
class that will be used in most manifests. There are a number of private classes set up to reduce the complexity of the base class, however some may be of use in separating some of the functionality across different hosts, e.g. running the database on a separate host.
/
80
omniauth
or shibboleth
are used.git
/home/git
true
the GitLab shell will be installed. The default is true
v1.9.6
git
gitlab
veryveryunsafe
true
self-signed certificates are used. The default is true
true
, user names will be audited in the GitLab shell. The default is true.INFO
./home/git/gitlab
7-1-stable
true
true
.2
, which is 'Mars'true
.true
.true
.true
.private
.true
.true
this will allow users to create new accounts via the login screen, otherwise all accounts must be created by the site Administrators. The default is false
.false
this will require users to use one of the OmniAuth providers instead of being able to log in with a username and password. The default is true
. NOTE: this needs to be true
to log in with the default administrator account and do the initial set up of the Gitlab application and to appoint new administrators.The omniauth
parameter on the base gitlab
class takes an array of hashes that define an OmniAuth provider. Check the test scripts for examples. More information on GitLab OmniAuth Providers.
Currently the list of supported providers is:
google
, google+
or google_oauth2
)github
)twitter
)NOTE: if the allow_sso
is true and block_auto_create
is false, then anyone with an identity on any of the configured OmniAuth providers can log in and use the GitLab instance, which includes access to internal projects.
Setting the shibboleth
parameter will enable the Shibboleth OmniAuth provider for GitLab. However this is not straight forward and additional dependencies and work are required for this to work correctly. Although this is a separate parameter, it is compatible with the other OmniAuth providers.
mod_shib
correctly. Currently this is the master branch from the git repository, not the current version from the Puppet Forge./etc/shibboleth/shibboleth2.xml
will need to be correct. There is a companion module for the Puppetlabs Apache module on GitHub
This class sets up a PostgreSQL database for the GitLab application. It does not install the PostgreSQL service, this should be declared beforehand.
git
gitlab
veryveryunsafe
Contains the global variables and defaults for the module. Should not be used directly.
This class has no parameters.
Runs the install procedure using vcsrepo
to use git to install GitLab from the GitLab Community Edition Repository. This separation simplifies adding different installers in later versions.
/home/git/gitlab
.7-3-stable
git
Runs the install procedure to install the GitLab command line shell, allowing it to potentially be installed independently of the GitLab application. (this use case is not yet tested)
git
/home/git
v2.0.0
/home/git/repositories
INFO
This resources uses the Gitlab shell to create a repository and import it into the Gitlab application. If the repository's group or user does not exist, a new group will be created to host the repository. If the repository already exist, Puppet remains idempotent and does nothing but acknowledge it's existence. Ownership of the repository is assigned to the first administrator, which will usually be the default administrator. Any administrator should be able to reassign ownership of the repository or move it into another namespace. This resource is a bit clumsy, and not the best way to create repositories, but it does make Puppet aware that a repository exist regardless of whether Puppet created it a not and was a prerequisite for managing repository hook scripts.
group
parameter. The owner will be the first administrator. This is a required parameter with no default value.This resource creates a Git server-side hook script that will be executed at different stages through pushing a git commit to the target repository. Creation of hooks requires that the repository be previously defined in the Puppet manifest. These hooks are not currently visible in the Gitlab web application. These hook scripts should follow the Gitlab custom hook guidelines.
The repository must be declared as a resource with gitlab::shell::repo
.
NOTE: This resource requires Gitlab shell v2.2.0 or later which has the custom hook scripts feature.
There are examples of how these scripts should be declared in the test scripts
One of, but not both, content
or source
is required. If both, or none of, the content
or source
parameters are defined an error will be thrown.
gitlab::shell::repo
. This parameter is required and has no default value.name
of the resource by default. Git only executes scripts with the name pre-recieve
, update
, or post-recieve
, scripts with other names or paths will need to be explicitly called by a recognised script.file
resource. One of, but not both, content
or source
is required. The default is undefined.file
resource. One of, but not both, content
or source
is required. The default is undefined.When running the gitlab:check
rake command to verify the Gitlab installation, it should all be correct with the exception of the init script check. This is correct behaviour as this module deploys it's own init script customised to work with Apache, so has all the Unicorn parts removed.
Hence, the following output is expected and no corrective action should be taken.
Init script up-to-date? ... no
Try fixing it:
Redownload the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
These are good implementations, but install GitLab on Ngnix, which is not what's being done here.
##GitLab installation references
This module is derived from the puppet-blank module by Aaron Hicks ([email protected])
This module has been developed for the use with Open Source Puppet (Apache 2.0 license) for automating server & service deployment.
This file is part of the gitlab Puppet module.
The gitlab Puppet module is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
The gitlab Puppet module is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with the gitlab Puppet module. If not, see http://www.gnu.org/licenses/.