Installation de Gitlab-ce et d’un serveur web sur une version Linux Debian 10 avec apache

GitLab est un référentiel en ligne qui permet aux développeurs de créer, stocker et gérer leurs projets avec la possibilité de revenir à un état antérieur en cas d’erreur. Pour utiliser le référentiel en ligne, aucune configuration n’est requise, il suffit de créer un compte et de commencer à créer des projets.

Néanmoins vous avez la possibilité d’installer sur votre propre serveur la version Gitlab-ce (gratuite) ou la version Gitlab-ee (payante).

Nous utiliserons un vps, ce qui nous donne la capacité d’installer gitlab-ce et d’accueillir également d’autres projets en même temps.

Le serveur gitlab utilise nginx comme serveur par défaut, tandis que nos projets utilisent le serveur apache pour servir le contenu. L’exécution simultanée de deux serveurs internes peut poser de nombreux problèmes. Nous utiliserons le serveur apache pour exécuter à la fois gitlab et d’autres projets web.

Prérequis :

1 :

Nous installerons gitlab-ce sur notre VPS manuellement à l’aide des commandes suivantes: 

sudo apt install curl openssh-server ca-certificates postfix 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bashsudo 

apt install gitlab-ce

L’installation de gitlab sur notre serveur nous donne la possibilité de changer le serveur nginx par défaut pour lequel il a été configuré.

2 :

Nous allons configurer l’url à utiliser pour accéder au serveur gitlab en éditant le fichier de configuration gitlab à l’aide de la commande suivante :

sudo nano /etc/gitlab/gitlab.rb

Modifiez le fichier de configuration en changeant l’url externe avec l’URL souhaitée:

external_url " http: // <votredomaine>"

Enregistrez votre configuration et exécutez cette commande pour reconfigurer votre installation gitlab:

sudo gitlab-ctl reconfigure

Votre installation de gitlab devrait fonctionner partiellement, visitez l’url spécifiée pour accéder à votre gitlab, ou en local sur le serveur à l’adresse 127.0.0.1/8080

Lors de la première connexion la page vous demandera de modifier votre mot de passe root.

3 :

Nous avons maintenant un serveur gitlab casi fonctionnel, mais nous voulons qu’il fonctionne en utilisant le serveur apache afin que nous puissions héberger d’autres éléments (sites Web, applications, etc.) sur le même serveur. Nous allons donc installer le serveur Apache et configurer le gitlab pour qu’il s’exécute.

Installez le serveur Apache en utilisant:

sudo apt update 
sudo apt install apache2 

sudo a2enmod proxy_http 
sudo a2enmod réécrire 
sudo a2enmod ssl 
sudo a2enmod headers
systemctl restart apache2

Ceux-ci installeront et démarreront le serveur Apache. Pour vérifier si le serveur Apache est en cours d’exécution, utilisez:

sudo systemctl status apache2

qui devrait afficher activé (en cours d’exécution).

4 :

Configurons notre serveur gitlab pour utiliser le serveur apache au lieu du serveur nginx par défaut.

sudo nano /etc/gitlab/gitlab.rb

Modifiez ce qui suit dans notre fichier de configuration gitlab:

# Modifiez l'url externe pour qu'elle corresponde au domaine dans notre fichier de configuration Apache 
external_url " http: // <votredomaine>"

# Désactiver nginx 
nginx ['enable'] = false

# Donnez à l'utilisateur Apache des privilèges pour écouter gitLab 
web_server ['external_users'] = ['www-data']

Enregistrez le fichier, puis créez le fichier de configuration gitlab apache dans le dossier apache sites-available.

# accédez au dossier de configuration apache 
cd /etc/apache2/sites-available

# créer un nouveau fichier de configuration 
touch gitlab.conf

# ouvrir le fichier de configuration pour éditer 
sudo nano gitlab.conf

Copiez et collez ce qui suit dans le fichier en modifiant les valeurs en correspondance avec votre configuration :

<VirtualHost *: 80>
  ServerName < your_domain_or_sub_domai n> 
  ServerSignature Off 

  ProxyPreserveHost On 
  AllowEncodedSlashes NoDecode 

  <Location /> 
  Obliger tous accordé 

  ProxyPassReverse http://127.0.0.1:8080
  ProxyPassReverse < your_domain_or_sub_domai n> 
  </ Location> 

  RewriteEngine on 
  RewriteCond% {DOCUMENT_ROOT} / {%} REQUEST_FILENAME! -f 
  RewriteRule. * http://127.0.0.1:8080% {REQUEST_URI} [P, QSA] 

  # nécessaire pour télécharger les pièces jointes 
  DocumentRoot / opt / gitlab / embedded / service / gitlab-rails / public

  #Configurez les documents d'erreur Apache, si le back-end tombe en panne (c'est-à-dire une erreur 503), une page de maintenance / déploiement est lancée. 
  ErrorDocument 404 /404.html 
  ErrorDocument 422 /422.html 
  ErrorDocument 500 /500.html 
  ErrorDocument 503 /deploy.html 

  LogFormat "% {X-Forwarded-For} i% l% u% t \"% r \ "%> s % b "common_forwarded 
  ErrorLog / var / log / httpd / logs / < votre_domaine_ou_sub_domai n> _error.log 
  CustomLog / var / log / httpd / logs / < votre_domaine_ou_sous_domaine n> _forwarded.log common_forwarded 
  CustomLog / var / log / httpd / logs / < votre_domaine_ou_sous_domaine n> _access.log combiné env =! dontlog 
  CustomLog / var / log / httpd / logs / < votre_domaine_ou_sous_domain> .log combiné 

</VirtualHost>

Pour le certificat SSL ajouter ces lignes au fichier de configuration gitlab.conf avant le </VirtualHost> en ajustant les paramètres à votre configuration.

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/www.domain.tld-error.log
CustomLog ${APACHE_LOG_DIR}/www.domain.tld-access.log combined

Enregistrez le fichier et activez le site gitlab en activant la configuration en utilisant:

# Activer gitlab 
sudo a2ensite gitlab.conf

#Redémarer Apache 
service apache2 restart

#Reconfigurer gitlab
sudo gitlab-ctl reconfigure

#Redémarrer gitlab server 
sudo gitlab-ctl restart

Nous avons fini de configurer notre gitlab pour qu’il s’exécute à partir du serveur apache, vérifiez maintenant à nouveau l’url pour voir un gitlab fonctionnel.

5 :

Nous avons installé avec succès notre gitlab pour utiliser le serveur apache, vérifions que notre serveur peut également contenir plusieurs sites.

Avant de créer la configuration Apache pour le nouveau site, nous allons créer le dossier pour contenir le contenu du site:

#Créer un répertoire pour le nouveau site 
sudo mkdir -p /var/www/new_site/public_html

# Autoriser les utilisateurs réguliers à modifier les fichiers dans le répertoire 
sudo chown -R $ USER: $ USER /var/www/new_site/public_html

#Autoriser l'accès général en lecture à notre répertoire Web 
sudo chmod -R 755 /var/www

Créez un nouveau fichier de configuration pour le nouveau site en dupliquant le fichier de configuration par défaut /etc/apache2/sites-available/000-default.conf et en le renommant en /etc/apache2/sites-available/new_site.conf

# accédez au dossier de configuration apache 
cd /etc/apache2/sites-available

# copier le contenu de la configuration par défaut dans le nouveau fichier de configuration 
sudo cp 000-default.conf new_site.conf

# ouvrir un nouveau fichier de configuration pour éditer 
sudo nano new_site.conf

puis modifiez le contenu du nouveau fichier pour qu’il corresponde à la configuration ci-dessous:

<VirtualHost *: 80> 

 ServerName <site-domain>     
 ServerAlias ​​<site-domain>  
 ServerAdmin < site-admin-email>  
 DocumentRoot /var/www/new_site/public_html

 #Répertoire créé précédemment 
 ErrorLog $ {APACHE_LOG_DIR} /error.log  
 CustomLog $ {APACHE_LOG_DIR} /access.log combiné

 </VirtualHost>

Après avoir enregistré notre fichier de configuration, nous pouvons activer notre nouveau site et redémarrer apache pour affecter les changements:

# activer la nouvelle configuration du site 
sudo a2ensite new_site.conf

# redémarrer le serveur apache 
sudo service apache2 restart

Assurez-vous que vos DNS ont été configurés pour pointer vers votre adresse IP public.

Rediriger les requêtes vers le serveur Apache

Dans un premier temps, il va donc falloir faire en sorte que lors d’une requête sur votre box, qui est la seule à être accessible depuis l’extérieur, celle-ci soit redirigée vers votre Serveur web, pour qu’elle soit traitée par le service adapté (en l’occurrence le serveur Apache2).

Pour cela, il va falloir accéder à l’interface de configuration de votre box. L’accès se fait différemment selon votre Fournisseur d’Accès Internet. Il faut donc que vous cherchiez (par exemple sur le site de votre fournisseur d’accès, ou plus simplement via votre moteur de recherche préféré) comment accéder à l’interface d’administration de votre box.
Une fois sur l’interface d’administration, et après vous être authentifié, vous allez pouvoir ouvrir les ports de votre box et rediriger les requêtes vers le serveur Apache.
Cette configuration se fait dans une partie qui peut avoir plusieurs noms, « configuration NAT », « Gestion des redirections de ports », « port forwading », etc.

Une fois que vous êtes dans la catégorie de configuration adaptée, le reste de la procédure est sensiblement équivalente pour l’ensemble des FAI. Vous allez mettre en place deux redirections différentes :

Type de requêtePort externe de la requêtePort interne de la redirectionProtocole employéÉquipement cible
HTTP8080TCPserveur web*
HTTPS443443TCPserveur web*

*serveur web peut correspondre soit au nom de votre Serveur, soit à son adresse IP sur le réseau interne.

Vous pouvez maintenant tester vos URL dans votre navigateur. Si vous rencontrez une erreur, vous devez passer en revue vos configurations pour vous assurer que tout était bien configuré.

Il ce peut cependant que vous rencontriez des erreurs de configuration autres que celles abordées durant ce tutoriel:

Problème de configuration des ports dans le fichier :

nano /etc/apache2/ports.conf

voir ceci : https://httpd.apache.org/docs/2.2/fr/bind.html

Problème d’autorisation dans les fichiers htacess :

nano /etc/apache2/apache2.conf

voir ceci : https://geekonweb.fr/autoriser-les-fichiers-htaccess-dapache-sur-un-serveur-sous-debian-8.html

Au cas où vous souhaiteriez réinitialiser le mot de passe root : https://docs.gitlab.com/12.10/ee/security/reset_root_password.html

Et pour approfondir, je vous partage cette ressource pour l’utilisation de Gitlab : http://osur-wikis.univ-reunion.fr/mediawiki/index.php/Utilisation_de_Git_et_GitLab

6 :

Configurez les référentiels de serveur pour push & pull:
Après avoir créé le serveur gitlab, les nouveaux utilisateurs peuvent s’inscrire et créer des projets sur le serveur gitlab.


Dans une situation où aucun utilisateur n’est autorisé à pull ou à push vers un référentiel, nous pouvons corriger cela en modifiant les lignes suivantes dans notre configuration gitlab (/etc/gitlab/gitlab.rb):


Ouvrez le fichier gitlab pour le modifier:

sudo nano /etc/gitlab/gitlab.rb

Modifiez les lignes suivantes pour refléter les changements ci-dessous:

gitlab_workhorse['enable'] = true
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "localhost:8282"

Après avoir enregistré le fichier de configuration, reconfigurez le serveur gitlab en utilisant:

sudo gitlab-ctl reconfigure

Puis :

sudo gitlab-ctl restart