doc-locale/fr-fr/install/azure/_index.md
{{< details >}}
{{< /details >}}
Pour les utilisateurs du cloud professionnel Microsoft Azure, GitLab propose une offre préconfigurée sur le Azure Marketplace. Ce tutoriel décrit l'installation de GitLab Enterprise Edition dans une seule machine virtuelle (VM).
Étant donné que GitLab est déjà installé dans une image préconfigurée, il vous suffit de créer une nouvelle VM :
Pour les besoins de ce guide, créons la VM de toutes pièces en sélectionnant Créer.
[!note] Sachez qu'Azure facture des frais de calcul dès que votre VM est active (« allouée »), même si vous utilisez des crédits d'essai gratuits. comment arrêter correctement une VM Azure pour économiser de l'argent. Consultez la calculatrice de prix Azure pour connaître le coût des ressources.
Après avoir créé la machine virtuelle, utilisez les informations des sections suivantes pour la configurer.
Les premiers éléments à configurer sont les paramètres de base de la machine virtuelle sous-jacente :
GitLab.1. En savoir plus sur les zones de disponibilité.D4s_v3, sélectionnez cette option.Vérifiez les paramètres saisis, puis passez à l'onglet Disks.
Pour les disques :
En savoir plus sur les types de disques qu'Azure propose.
Vérifiez vos paramètres, puis passez à l'onglet Networking.
Utilisez cet onglet pour définir la connectivité réseau de votre machine virtuelle en configurant les paramètres de la carte d'interface réseau (NIC). Vous pouvez les laisser à leurs paramètres par défaut.
Azure crée un groupe de sécurité par défaut et la VM lui est assignée. L'image GitLab sur la marketplace présente les ports ouverts suivants par défaut :
| Port | Description |
|---|---|
| 80 | Permet à la VM de répondre aux requêtes HTTP, autorisant l'accès public. |
| 443 | Permet à notre VM de répondre aux requêtes HTTPS, autorisant l'accès public. |
| 22 | Permet à notre VM de répondre aux demandes de connexion SSH, autorisant l'accès public (avec authentification) aux sessions de terminal à distance. |
Si vous souhaitez modifier les ports ou ajouter des règles, vous pouvez le faire après la création de la VM en sélectionnant Networking settings dans la barre latérale gauche, depuis le tableau de bord de la VM.
Utilisez cet onglet pour configurer les options de surveillance et de gestion de votre VM. Vous n'avez pas besoin de modifier les paramètres par défaut.
Utilisez cet onglet pour ajouter une configuration supplémentaire, des agents, des scripts ou des applications via des extensions de machine virtuelle ou cloud-init. Vous n'avez pas besoin de modifier les paramètres par défaut.
Utilisez cet onglet pour ajouter des paires nom/valeur vous permettant de catégoriser les ressources. Vous n'avez pas besoin de modifier les paramètres par défaut.
L'onglet final vous présente toutes les options sélectionnées, où vous pouvez revoir et modifier vos choix issus des étapes précédentes. Azure exécute des tests de validation en arrière-plan et, si vous avez fourni tous les paramètres requis, vous pouvez créer la VM.
Après avoir sélectionné Créer, si vous avez choisi de laisser Azure créer une paire de clés SSH pour vous, une invite apparaît pour télécharger la clé SSH privée. Téléchargez la clé, car elle est nécessaire pour se connecter à la VM via SSH.
Après avoir téléchargé la clé, le déploiement commence.
À ce stade, Azure commence à déployer votre nouvelle VM. Le processus de déploiement prend quelques minutes. Une fois terminé, la nouvelle VM et ses ressources associées s'affichent dans le tableau de bord Azure. Sélectionnez Go to resource pour accéder au tableau de bord de la VM.
GitLab est maintenant déployé et prêt à être utilisé. Avant de le faire, cependant, vous devez configurer le nom de domaine et configurer GitLab pour l'utiliser.
La VM dispose d'une adresse IP publique (statique par défaut), mais Azure vous permet d'attribuer un nom DNS descriptif à la VM :
gitlab-prod. Cela rend la VM accessible à l'adresse gitlab-prod.eastus.cloudapp.azure.com.À terme, la plupart des utilisateurs souhaitent utiliser leur propre nom de domaine. Pour ce faire, vous devez ajouter un enregistrement DNS A auprès de votre bureau d'enregistrement de domaine qui pointe vers l'adresse IP publique de votre VM Azure. Vous pouvez utiliser Azure DNS ou un autre bureau d'enregistrement.
GitLab utilise external_url dans son fichier de configuration pour définir le nom de domaine. Si vous ne configurez pas cela, lorsque vous accédez au nom convivial Azure, le navigateur vous redirigera vers l'IP publique.
Pour configurer l'URL externe de GitLab :
Connectez-vous à GitLab via SSH en accédant à Paramètres > Connecter depuis le tableau de bord de la VM, puis suivez les instructions. N'oubliez pas de vous connecter avec le nom d'utilisateur et la clé SSH que vous avez spécifiés lors de la création de la VM. Le nom de domaine de la VM Azure est celui que vous avez configuré précédemment. Si vous n'avez pas configuré de nom de domaine pour votre VM, vous pouvez utiliser l'adresse IP à la place.
Dans le cas de notre exemple :
ssh -i <private key path> [email protected]
[!note] Si vous devez réinitialiser vos identifiants, consultez comment réinitialiser les identifiants SSH pour un utilisateur sur une VM Azure.
Ouvrez /etc/gitlab/gitlab.rb avec votre éditeur.
Trouvez external_url et remplacez-le par votre propre nom de domaine. Pour les besoins de cet exemple, utilisez le nom de domaine par défaut qu'Azure configure. L'utilisation de https dans l'URL active automatiquement Let's Encrypt et configure HTTPS par défaut :
external_url 'https://gitlab-prod.eastus.cloudapp.azure.com'
Trouvez les paramètres suivants et commentez-les, afin que GitLab ne récupère pas les mauvais certificats :
# nginx['redirect_http_to_https'] = true
# nginx['ssl_certificate'] = "/etc/gitlab/ssl/server.crt"
# nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/server.key"
Reconfigurez GitLab pour que les modifications prennent effet. Exécutez la commande suivante chaque fois que vous apportez des modifications à /etc/gitlab/gitlab.rb :
sudo gitlab-ctl reconfigure
Pour éviter que le nom de domaine ne soit réinitialisé après un redémarrage, renommez l'utilitaire utilisé par Bitnami :
sudo mv /opt/bitnami/apps/gitlab/bnconfig /opt/bitnami/apps/gitlab/bnconfig.bak
Vous pouvez maintenant accéder à GitLab depuis votre navigateur à l'aide de la nouvelle URL externe.
Utilisez le nom de domaine que vous avez configuré précédemment pour accéder à votre nouvelle instance GitLab dans votre navigateur. Dans cet exemple, il s'agit de https://gitlab-prod.eastus.cloudapp.azure.com.
La première chose qui apparaît est la page de connexion. GitLab crée un utilisateur administrateur par défaut. Les identifiants sont :
rootAprès vous être connecté, veillez à changer immédiatement le mot de passe.
Il est important de maintenir votre environnement GitLab à jour. L'équipe GitLab apporte constamment des améliorations et vous pouvez parfois avoir besoin d'effectuer une mise à jour pour des raisons de sécurité. Utilisez les informations de cette section chaque fois que vous devez mettre à jour GitLab.
Pour déterminer la version de GitLab que vous utilisez actuellement :
Si une version plus récente de GitLab contenant un ou plusieurs correctifs de sécurité est disponible, GitLab affiche une notification Update asap vous invitant à effectuer la mise à jour.
Pour mettre à jour GitLab vers la dernière version :
Connectez-vous à la VM via SSH.
Mettez à jour GitLab :
sudo apt update
sudo apt install gitlab-ee
Cette commande met à jour GitLab et ses composants associés vers les dernières versions et peut prendre un certain temps. Pendant ce temps, le terminal affiche les différentes tâches de mise à jour effectuées dans votre terminal.
[!note] Si vous obtenez une erreur du type
E: The repository 'https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease' is not signed., consultez la section de dépannage.
Une fois le processus de mise à jour terminé, un message similaire au suivant apparaît :
Upgrade complete! If your GitLab server is misbehaving try running
sudo gitlab-ctl restart
before anything else.
Actualisez votre instance GitLab dans le navigateur et accédez à la zone Admin. Votre instance GitLab est maintenant à jour.
Maintenant que vous disposez d'une instance GitLab fonctionnelle, suivez les étapes suivantes pour découvrir ce que vous pouvez faire de plus avec votre nouvelle installation.
Cette section décrit les erreurs courantes que vous pouvez rencontrer.
[!note] Il s'agit d'un correctif temporaire jusqu'à ce que l'image GitLab soit mise à jour avec la nouvelle clé GPG.
L'image GitLab préconfigurée dans Azure (fournie par Bitnami) utilise une clé GPG dépréciée en avril 2020.
Si vous essayez de mettre à jour les dépôts, le système renvoie l'erreur suivante :
[ 21.023494] apt-setup[1198]: W: GPG error: https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
[ 21.024033] apt-setup[1198]: E: The repository 'https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease' is not signed.
Pour corriger ce problème, récupérez la nouvelle clé GPG :
sudo apt install gpg-agent
sudo curl --fail --silent --show-error \
--output /etc/apt/trusted.gpg.d/gitlab.asc \
--url "https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab_new_gpg.key"
Vous pouvez maintenant mettre à jour GitLab. Pour plus d'informations, consultez la documentation sur les signatures des paquets.