doc-locale/fr-fr/administration/reference_architectures/3k_users.md
{{< details >}}
{{< /details >}}
Cette page décrit l'architecture de référence GitLab conçue pour cibler une charge maximale de 60 requêtes par seconde (RPS), la charge maximale typique pour jusqu'à 3 000 utilisateurs, à la fois manuels et automatisés, sur la base de données réelles.
Cette architecture est la plus petite disponible avec la haute disponibilité (HA) intégrée. Si vous avez besoin de la HA mais disposez d'un nombre d'utilisateurs ou d'une charge totale inférieure, la section Modifications prises en charge pour les nombres d'utilisateurs inférieurs explique en détail comment réduire la taille de cette architecture tout en maintenant la HA.
Pour obtenir la liste complète des architectures de référence, voir Architectures de référence disponibles.
| Service | Nœuds | Configuration | Exemple GCP<sup>1</sup> | Exemple AWS<sup>1</sup> | Exemple Azure<sup>1</sup> |
|---|---|---|---|---|---|
| Équilibreur de charge externe<sup>4</sup> | 1 | 4 vCPU, 3,6 Go de mémoire | n1-highcpu-4 | c5n.xlarge | F4s v2 |
| Consul<sup>2</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large | F2s v2 |
| PostgreSQL<sup>2</sup> | 3 | 2 vCPU, 7,5 Go de mémoire | n1-standard-2 | m5.large | D2s v3 |
| PgBouncer<sup>2</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large | F2s v2 |
| Équilibreur de charge interne<sup>4</sup> | 1 | 4 vCPU, 3,6 Go de mémoire | n1-highcpu-4 | c5n.xlarge | F4s v2 |
| Redis/Sentinel<sup>3</sup> | 3 | 2 vCPU, 7,5 Go de mémoire | n1-standard-2 | m5.large | D2s v3 |
| Gitaly<sup>6</sup><sup>7</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge | D4s v3 |
| Praefect<sup>6</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large | F2s v2 |
| Praefect PostgreSQL<sup>2</sup> | 1+ | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large | F2s v2 |
| Sidekiq<sup>8</sup> | 2 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge | D2s v3 |
| GitLab Rails<sup>8</sup> | 3 | 8 vCPU, 7,2 Go de mémoire | n1-highcpu-8 | c5.2xlarge | F8s v2 |
| Nœud de surveillance | 1 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large | F2s v2 |
| Stockage d'objets<sup>5</sup> | - | - | - | - | - |
Footnotes :
<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->Gitaly.[!note] Pour toutes les solutions PaaS impliquant la configuration d'instances, il est recommandé de mettre en œuvre un minimum de trois nœuds dans trois zones de disponibilité différentes afin de s'aligner sur les pratiques d'architecture cloud résiliente.
@startuml 3k
skinparam linetype ortho
card "**External Load Balancer**" as elb #6a9be7
card "**Internal Load Balancer**" as ilb #9370DB
together {
collections "**GitLab Rails** x3" as gitlab #32CD32
collections "**Sidekiq** x2" as sidekiq #ff8dd1
}
together {
card "**Prometheus**" as monitor #7FFFD4
collections "**Consul** x3" as consul #e76a9b
}
card "Gitaly Cluster" as gitaly_cluster {
collections "**Praefect** x3" as praefect #FF8C00
collections "**Gitaly** x3" as gitaly #FF8C00
card "**Praefect PostgreSQL***\n//Non fault-tolerant//" as praefect_postgres #FF8C00
praefect -[#FF8C00]-> gitaly
praefect -[#FF8C00]> praefect_postgres
}
card "Database" as database {
collections "**PGBouncer** x3" as pgbouncer #4EA7FF
card "**PostgreSQL** //Primary//" as postgres_primary #4EA7FF
collections "**PostgreSQL** //Secondary// x2" as postgres_secondary #4EA7FF
pgbouncer -[#4EA7FF]-> postgres_primary
postgres_primary .[#4EA7FF]> postgres_secondary
}
card "Redis" as redis {
collections "**Redis** x3" as redis_nodes #FF6347
}
cloud "**Object Storage**" as object_storage #white
elb -[#6a9be7]-> gitlab
elb -[#6a9be7,norank]--> monitor
gitlab -[#32CD32,norank]--> ilb
gitlab -[#32CD32]r-> object_storage
gitlab -[#32CD32]----> redis
gitlab .[#32CD32]----> database
gitlab -[hidden]-> monitor
gitlab -[hidden]-> consul
sidekiq -[#ff8dd1,norank]--> ilb
sidekiq -[#ff8dd1]r-> object_storage
sidekiq -[#ff8dd1]----> redis
sidekiq .[#ff8dd1]----> database
sidekiq -[hidden]-> monitor
sidekiq -[hidden]-> consul
ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden]--> redis
ilb -[hidden]u-> consul
ilb -[hidden]u-> monitor
consul .[#e76a9b]u-> gitlab
consul .[#e76a9b]u-> sidekiq
consul .[#e76a9b]r-> monitor
consul .[#e76a9b]-> database
consul .[#e76a9b]-> gitaly_cluster
consul .[#e76a9b,norank]--> redis
monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]> consul
monitor .[#7FFFD4]-> database
monitor .[#7FFFD4]-> gitaly_cluster
monitor .[#7FFFD4,norank]--> redis
monitor .[#7FFFD4]> ilb
monitor .[#7FFFD4,norank]u--> elb
@enduml
Avant de continuer, examinez les prérequis pour les architectures de référence.
L'architecture de référence 60 RPS / 3k utilisateurs est conçue pour s'adapter aux flux de travail les plus courants. GitLab effectue régulièrement des tests de performance et de fumée par rapport aux objectifs de débit des points de terminaison suivants :
| Type de point de terminaison | Débit cible |
|---|---|
| API | 60 RPS |
| Web | 6 RPS |
| Git (Pull) | 6 RPS |
| Git (Push) | 1 RPS |
Ces objectifs sont basés sur des données clients réelles reflétant les charges environnementales totales pour le nombre d'utilisateurs spécifié, y compris les pipelines CI et autres charges de travail. Cela représente une composition de charge de travail typique. Pour des conseils sur les modèles de charge de travail atypiques, voir Comprendre la composition RPS.
Pour plus d'informations sur notre méthodologie de test, consultez la section résultats de validation et de test.
Des ajustements supplémentaires peuvent être nécessaires si votre environnement présente :
Dans ces cas, consultez la mise à l'échelle d'un environnement pour plus d'informations. Si vous pensez que ces considérations peuvent s'appliquer à votre cas, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Notre environnement de test utilise :
Pour configurer GitLab et ses composants afin de prendre en charge jusqu'à 60 RPS ou 3 000 utilisateurs :
Les serveurs démarrent sur la même plage de réseau privé 10.6.0.0/24 et peuvent se connecter librement les uns aux autres sur ces adresses.
La liste suivante comprend les descriptions de chaque serveur et son adresse IP attribuée :
10.6.0.10 : Équilibreur de charge externe10.6.0.11 : Consul/Sentinel 110.6.0.12 : Consul/Sentinel 210.6.0.13 : Consul/Sentinel 310.6.0.21 : PostgreSQL principal10.6.0.22 : PostgreSQL secondaire 110.6.0.23 : PostgreSQL secondaire 210.6.0.31 : PgBouncer 110.6.0.32 : PgBouncer 210.6.0.33 : PgBouncer 310.6.0.20 : Équilibreur de charge interne10.6.0.61 : Redis Principal10.6.0.62 : Redis Replica 110.6.0.63 : Redis Replica 210.6.0.51 : Gitaly 110.6.0.52 : Gitaly 210.6.0.93 : Gitaly 310.6.0.131 : Praefect 110.6.0.132 : Praefect 210.6.0.133 : Praefect 310.6.0.141 : Praefect PostgreSQL 1 (non HA)10.6.0.71 : Sidekiq 110.6.0.72 : Sidekiq 210.6.0.41 : Application GitLab 110.6.0.42 : Application GitLab 210.6.0.43 : Application GitLab 310.6.0.81 : PrometheusDans une configuration GitLab multi-nœuds, vous aurez besoin d'un équilibreur de charge externe pour acheminer le trafic vers les serveurs d'application.
Les détails sur le choix de l'équilibreur de charge ou sa configuration exacte dépassent le cadre de la documentation GitLab, mais consultez Équilibreurs de charge pour plus d'informations sur les exigences générales. Cette section se concentrera sur les spécificités de ce qu'il faut configurer pour l'équilibreur de charge de votre choix.
Assurez-vous que l'équilibreur de charge externe n'achemine que vers des services fonctionnels avec des points de terminaison de surveillance intégrés. Les vérifications de disponibilité nécessitent toutes une configuration supplémentaire sur les nœuds vérifiés, sinon l'équilibreur de charge externe ne pourra pas se connecter.
Les ports de base à utiliser sont indiqués dans le tableau ci-dessous.
| Port LB | Port backend | Protocole |
|---|---|---|
| 80 | 80 | HTTP (1) |
| 443 | 443 | TCP ou HTTPS (1) (2) |
| 22 | 22 | TCP |
Connection et Upgrade. Consultez le guide d'intégration du terminal web pour plus de détails.Si vous utilisez GitLab Pages avec la prise en charge des domaines personnalisés, vous aurez besoin de quelques configurations de port supplémentaires. GitLab Pages nécessite une adresse IP virtuelle distincte. Configurez le DNS pour pointer le pages_external_url de /etc/gitlab/gitlab.rb vers la nouvelle adresse IP virtuelle. Consultez la documentation GitLab Pages pour plus d'informations.
| Port LB | Port backend | Protocole |
|---|---|---|
| 80 | Variable (1) | HTTP |
| 443 | Variable (1) | TCP (2) |
gitlab_pages['external_http'] et gitlab_pages['external_https']. Consultez la documentation GitLab Pages pour plus de détails.Certaines organisations ont des politiques contre l'ouverture du port SSH 22. Dans ce cas, il peut être utile de configurer un nom d'hôte SSH alternatif permettant aux utilisateurs d'utiliser SSH sur le port 443. Un nom d'hôte SSH alternatif nécessitera une nouvelle adresse IP virtuelle par rapport à la configuration HTTP GitLab documentée précédemment.
Configurez le DNS pour un nom d'hôte SSH alternatif tel que altssh.gitlab.example.com.
| Port LB | Port backend | Protocole |
|---|---|---|
| 443 | 22 | TCP |
La question suivante est de savoir comment vous allez gérer le SSL dans votre environnement. Il existe plusieurs options différentes :
Configurez votre équilibreur de charge pour passer les connexions sur le port 443 en tant que TCP plutôt qu'en protocole HTTP(S). Cela transmettra la connexion au service NGINX du nœud d'application sans modification. NGINX disposera du certificat SSL et écoutera sur le port 443.
Consultez la documentation HTTPS pour plus de détails sur la gestion des certificats SSL et la configuration de NGINX.
Configurez votre équilibreur de charge pour utiliser le protocole HTTP(S) plutôt que TCP. L'équilibreur de charge sera alors responsable de la gestion des certificats SSL et de la terminaison du SSL.
Étant donné que la communication entre l'équilibreur de charge et GitLab ne sera pas sécurisée, une configuration supplémentaire est nécessaire. Consultez la documentation SSL proxy pour plus de détails.
Configurez vos équilibreurs de charge pour utiliser le protocole « HTTP(S) » plutôt que « TCP ». Les équilibreurs de charge seront responsables de la gestion des certificats SSL que les utilisateurs finaux verront.
Le trafic sera également sécurisé entre les équilibreurs de charge et NGINX dans ce scénario. Il n'est pas nécessaire d'ajouter une configuration pour le SSL proxy car la connexion sera sécurisée de bout en bout. Cependant, une configuration doit être ajoutée à GitLab pour configurer les certificats SSL. Consultez la documentation HTTPS pour plus de détails sur la gestion des certificats SSL et la configuration de NGINX.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Dans une configuration GitLab multi-nœuds, vous aurez besoin d'un équilibreur de charge interne pour acheminer le trafic vers certains composants internes si configurés, tels que les connexions à PgBouncer et Gitaly Cluster (Praefect).
Les détails sur le choix de l'équilibreur de charge ou sa configuration exacte dépassent le cadre de la documentation GitLab, mais consultez Équilibreurs de charge pour plus d'informations sur les exigences générales. Cette section se concentrera sur les spécificités de ce qu'il faut configurer pour l'équilibreur de charge de votre choix.
L'IP suivante sera utilisée comme exemple :
10.6.0.40 : Équilibreur de charge interneVoici comment vous pourriez le faire avec HAProxy :
global
log /dev/log local0
log localhost local1 notice
log stdout format raw local0
defaults
log global
default-server inter 10s fall 3 rise 2
balance leastconn
frontend internal-pgbouncer-tcp-in
bind *:6432
mode tcp
option tcplog
default_backend pgbouncer
backend pgbouncer
mode tcp
option tcp-check
server pgbouncer1 10.6.0.31:6432 check
server pgbouncer2 10.6.0.32:6432 check
server pgbouncer3 10.6.0.33:6432 check
# Praefect load balancing (skip both sections below if using DNS service discovery for Praefect)
# For more information, see https://docs.gitlab.com/administration/gitaly/praefect/configure/#service-discovery
frontend internal-praefect-tcp-in
bind *:2305
mode tcp
option tcplog
option clitcpka
default_backend praefect
backend praefect
mode tcp
option tcp-check
option srvtcpka
server praefect1 10.6.0.131:2305 check
server praefect2 10.6.0.132:2305 check
server praefect3 10.6.0.133:2305 check
Reportez-vous à la documentation de votre équilibreur de charge préféré pour obtenir des conseils supplémentaires.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Ensuite, nous configurons les serveurs Consul.
[!note] Consul doit être déployé avec un nombre impair de 3 nœuds ou plus. Ceci pour garantir que les nœuds peuvent prendre des votes dans le cadre d'un quorum.
Les IPs suivantes seront utilisées comme exemple :
10.6.0.11 : Consul 110.6.0.12 : Consul 210.6.0.13 : Consul 3Pour configurer Consul :
Connectez-vous en SSH au serveur qui hébergera Consul.
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi. Sélectionnez la même version et le même type (éditions Community ou Enterprise) que votre installation actuelle.
Modifiez /etc/gitlab/gitlab.rb et ajoutez le contenu :
roles(['consul_role'])
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
server: true,
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Répétez les étapes pour tous les autres nœuds Consul et assurez-vous de configurer les bonnes IPs.
Un leader Consul est élu lorsque le provisionnement du troisième serveur Consul est terminé. La consultation des journaux Consul sudo gitlab-ctl tail consul affiche ...[INFO] consul: New leader elected: ....
Vous pouvez lister les membres Consul actuels (serveur, client) :
sudo /opt/gitlab/embedded/bin/consul members
Vous pouvez vérifier que les services GitLab fonctionnent :
sudo gitlab-ctl status
La sortie devrait être similaire à ce qui suit :
run: consul: (pid 30074) 76834s; run: log: (pid 29740) 76844s
run: logrotate: (pid 30925) 3041s; run: log: (pid 29649) 76861s
run: node-exporter: (pid 30093) 76833s; run: log: (pid 29663) 76855s
Dans cette section, vous êtes guidé pour configurer un cluster PostgreSQL hautement disponible à utiliser avec GitLab.
Au lieu des composants PostgreSQL, PgBouncer et de découverte de services Consul fournis avec le paquet Linux, vous pouvez utiliser un service externe tiers pour PostgreSQL.
Utilisez un fournisseur réputé qui exécute une version PostgreSQL prise en charge. Ces services sont connus pour bien fonctionner :
Pour plus d'informations, notamment des conseils sur la haute disponibilité et l'équilibrage de charge de la base de données, voir :
Si vous utilisez un service externe tiers :
La configuration de paquet Linux recommandée pour un cluster PostgreSQL avec réplication et basculement nécessite :
Un minimum de trois nœuds PostgreSQL.
Un minimum de trois nœuds de serveur Consul.
Un minimum de trois nœuds PgBouncer qui suivent et gèrent les lectures et écritures de la base de données principale.
Équilibrage de charge de la base de données activé.
Un service PgBouncer local à configurer sur chaque nœud PostgreSQL. Ce service est distinct du cluster PgBouncer principal qui suit le nœud principal.
Les IPs suivantes sont utilisées comme exemple :
10.6.0.21 : PostgreSQL principal10.6.0.22 : PostgreSQL secondaire 110.6.0.23 : PostgreSQL secondaire 2Tout d'abord, assurez-vous d'installer le paquet Linux GitLab on each node. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi, mais ne fournissez not la valeur EXTERNAL_URL.
Connectez-vous en SSH à l'un des nœuds PostgreSQL.
Générez un hachage de mot de passe pour la paire nom d'utilisateur/mot de passe PostgreSQL. Cela suppose que vous utilisez le nom d'utilisateur par défaut gitlab (recommandé). La commande demande un mot de passe et une confirmation. Utilisez la valeur renvoyée par cette commande à l'étape suivante comme valeur de <postgresql_password_hash> :
sudo gitlab-ctl pg-password-md5 gitlab
Générez un hachage de mot de passe pour la paire nom d'utilisateur/mot de passe PgBouncer. Cela suppose que vous utilisez le nom d'utilisateur par défaut pgbouncer (recommandé). La commande demande un mot de passe et une confirmation. Utilisez la valeur renvoyée par cette commande à l'étape suivante comme valeur de <pgbouncer_password_hash> :
sudo gitlab-ctl pg-password-md5 pgbouncer
Générez un hachage de mot de passe pour la paire nom d'utilisateur/mot de passe de réplication PostgreSQL. Cela suppose que vous utilisez le nom d'utilisateur par défaut gitlab_replicator (recommandé). La commande demande un mot de passe et une confirmation. Utilisez la valeur renvoyée par cette commande à l'étape suivante comme valeur de <postgresql_replication_password_hash> :
sudo gitlab-ctl pg-password-md5 gitlab_replicator
Générez un hachage de mot de passe pour la paire nom d'utilisateur/mot de passe de la base de données Consul. Cela suppose que vous utilisez le nom d'utilisateur par défaut gitlab-consul (recommandé). La commande demande un mot de passe et une confirmation. Utilisez la valeur renvoyée par cette commande à l'étape suivante comme valeur de <consul_password_hash> :
sudo gitlab-ctl pg-password-md5 gitlab-consul
Sur chaque nœud de base de données, modifiez /etc/gitlab/gitlab.rb en remplaçant les valeurs indiquées dans la section # START user configuration :
# Disable all components except Patroni, PgBouncer and Consul
roles(['patroni_role', 'pgbouncer_role'])
# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'
# Sets `max_replication_slots` to double the number of database nodes.
# Patroni uses one extra slot per node when initiating the replication.
patroni['postgresql']['max_replication_slots'] = 6
# Set `max_wal_senders` to one more than the number of replication slots in the cluster.
# This is used to prevent replication from using up all of the
# available database connections.
patroni['postgresql']['max_wal_senders'] = 7
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
# Configure the Consul agent
consul['services'] = %w(postgresql)
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PGBOUNCER_PASSWORD_HASH with a generated md5 value
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# Replace POSTGRESQL_REPLICATION_PASSWORD_HASH with a generated md5 value
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = '<postgresql_password_hash>'
# Set up basic authentication for the Patroni API (use the same username/password in all nodes).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'
# Replace 10.6.0.0/24 with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
# Local PgBouncer service for Database Load Balancing
pgbouncer['databases'] = {
gitlabhq_production: {
host: "127.0.0.1",
user: "pgbouncer",
password: '<pgbouncer_password_hash>'
}
}
# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration
PostgreSQL, avec Patroni gérant son basculement, utilise par défaut pg_rewind pour gérer les conflits. Comme la plupart des méthodes de gestion du basculement, cela comporte un faible risque de perte de données. Pour plus d'informations, voir les différentes méthodes de réplication Patroni.
/etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.Les options de configuration avancées sont prises en charge et peuvent être ajoutées si nécessaire.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Connectez-vous en SSH à l'un des nœuds Patroni sur le primary site :
Vérifiez le statut du leader et du cluster :
gitlab-ctl patroni members
La sortie devrait être similaire à ce qui suit :
| Cluster | Member | Host | Role | State | TL | Lag in MB | Pending restart |
|---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
| postgresql-ha | <PostgreSQL primary hostname> | 10.6.0.21 | Leader | running | 175 | | * |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 | | running | 175 | 0 | * |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 | | running | 175 | 0 | * |
Si la colonne « État » d'un nœud n'indique pas « running », consultez la section de dépannage de la réplication et du basculement PostgreSQL avant de continuer.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Maintenant que les serveurs PostgreSQL sont tous configurés, configurons PgBouncer pour le suivi et la gestion des lectures/écritures vers la base de données principale.
[!note] PgBouncer est mono-thread et ne bénéficie pas significativement d'une augmentation du nombre de cœurs CPU. Consultez la documentation sur la mise à l'échelle pour plus d'informations.
Les IPs suivantes sont utilisées comme exemple :
10.6.0.31 : PgBouncer 110.6.0.32 : PgBouncer 210.6.0.33 : PgBouncer 3Sur chaque nœud PgBouncer, modifiez /etc/gitlab/gitlab.rb et remplacez <consul_password_hash> et <pgbouncer_password_hash> par les hachages de mot de passe que vous avez configurés précédemment :
# Disable all components except Pgbouncer and Consul agent
roles(['pgbouncer_role'])
# Configure PgBouncer
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
'gitlab-consul': {
password: '<consul_password_hash>'
},
'pgbouncer': {
password: '<pgbouncer_password_hash>'
}
}
# Configure Consul agent
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Créez un fichier .pgpass pour que Consul puisse recharger PgBouncer. Saisissez le mot de passe PgBouncer deux fois lorsqu'on vous le demande :
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
Assurez-vous que chaque nœud communique avec le master actuel :
gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
Si une erreur psql: ERROR: Auth failed apparaît après avoir saisi le mot de passe, assurez-vous d'avoir précédemment généré les hachages de mot de passe MD5 avec le format correct. Le format correct consiste à concaténer le mot de passe et le nom d'utilisateur : PASSWORDUSERNAME. Par exemple, Sup3rS3cr3tpgbouncer serait le texte nécessaire pour générer un hachage de mot de passe MD5 pour l'utilisateur pgbouncer.
Une fois l'invite de console disponible, exécutez les requêtes suivantes :
show databases ; show clients ;
La sortie devrait être similaire à ce qui suit :
name | host | port | database | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production | | 20 | 0 | | 0 | 0
pgbouncer | | 6432 | pgbouncer | pgbouncer | 2 | 0 | statement | 0 | 0
(2 rows)
type | user | database | state | addr | port | local_addr | local_port | connect_time | request_time | ptr | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
C | pgbouncer | pgbouncer | active | 127.0.0.1 | 56846 | 127.0.0.1 | 6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 | | 0 |
(2 rows)
Vérifiez que les services GitLab fonctionnent :
sudo gitlab-ctl status
La sortie devrait être similaire à ce qui suit :
run: consul: (pid 31530) 77150s; run: log: (pid 31106) 77182s
run: logrotate: (pid 32613) 3357s; run: log: (pid 30107) 77500s
run: node-exporter: (pid 31550) 77149s; run: log: (pid 30138) 77493s
run: pgbouncer: (pid 32033) 75593s; run: log: (pid 31117) 77175s
run: pgbouncer-exporter: (pid 31558) 77148s; run: log: (pid 31498) 77156s
L'utilisation de Redis dans un environnement évolutif est possible en utilisant une topologie Principal x Replica avec un service Redis Sentinel pour surveiller et démarrer automatiquement la procédure de basculement.
[!note]
- Les clusters Redis doivent chacun être déployés avec un nombre impair de 3 nœuds ou plus. Ceci pour garantir que Redis Sentinel peut prendre des votes dans le cadre d'un quorum. Cela ne s'applique pas lors de la configuration de Redis en externe, comme avec un service de fournisseur cloud.
- Redis est principalement mono-thread et ne bénéficie pas significativement d'une augmentation du nombre de cœurs CPU. Cette architecture utilise un seul cluster Redis combiné (3 nœuds), mais pour des performances optimales, vous pouvez séparer Redis en instances Cache et Persistantes distinctes (6 nœuds au total). Ceci est fortement recommandé si le CPU de Redis est saturé. Consultez la documentation sur la mise à l'échelle pour plus d'informations.
Redis nécessite une authentification lorsqu'il est utilisé avec Sentinel. Consultez la documentation Redis Security pour plus d'informations. Nous recommandons d'utiliser une combinaison d'un mot de passe Redis et de règles de pare-feu strictes pour sécuriser votre service Redis. Nous vous encourageons vivement à lire la documentation Redis Sentinel avant de configurer Redis avec GitLab pour bien comprendre la topologie et l'architecture.
Les exigences pour une configuration Redis sont les suivantes :
6379) et Sentinel (26379) (sauf si vous modifiez les valeurs par défaut).Dans cette section, vous serez guidé pour configurer un cluster Redis externe à utiliser avec GitLab. Les IPs suivantes seront utilisées comme exemple :
10.6.0.61 : Redis Principal10.6.0.62 : Redis Replica 110.6.0.63 : Redis Replica 2Vous pouvez optionnellement utiliser un service externe tiers pour l'instance Redis en suivant les conseils ci-après :
Pour plus d'informations, voir Fournisseurs et services cloud recommandés.
C'est dans cette section que nous installons et configurons les nouvelles instances Redis.
Les nœuds Redis principal et réplica doivent avoir le même mot de passe défini dans redis['password']. À tout moment lors d'un basculement, les Sentinels peuvent reconfigurer un nœud et modifier son statut de principal à réplica (et vice versa).
Connectez-vous en SSH au serveur Redis Principal.
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi. Sélectionnez la même version et le même type (éditions Community ou Enterprise) que votre installation actuelle.
Modifiez /etc/gitlab/gitlab.rb et ajoutez le contenu :
# Specify server roles as 'redis_master_role' with Sentinel and the Consul agent
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really must bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.61'
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis'
## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.61'
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Connectez-vous en SSH au serveur Redis replica.
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi. Sélectionnez la même version et le même type (éditions Community ou Enterprise) que votre installation actuelle.
Modifiez /etc/gitlab/gitlab.rb et ajoutez le contenu :
# Specify server roles as 'redis_sentinel_role' and 'redis_replica_role'
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really must bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.62'
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
# The same password for Redis authentication you set up for the primary node.
redis['password'] = 'REDIS_PRIMARY_PASSWORD'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis'
# The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.61'
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Répétez les étapes pour tous les autres nœuds réplica et assurez-vous de configurer correctement les IPs.
Les options de configuration avancées sont prises en charge et peuvent être ajoutées si nécessaire.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Gitaly Cluster (Praefect) est une solution tolérante aux pannes fournie et recommandée par GitLab pour le stockage des dépôts Git. Dans cette configuration, chaque dépôt Git est stocké sur chaque nœud Gitaly du cluster, l'un d'eux étant désigné comme principal, et le basculement se produit automatiquement si le nœud principal tombe en panne.
[!warning] Les spécifications de Gitaly sont basées sur des percentiles élevés à la fois des modèles d'utilisation et des tailles de dépôt en bonne santé. Cependant, si vous avez des monodépôts volumineux (de plus de plusieurs gigaoctets) ou des charges de travail supplémentaires, ceux-ci peuvent avoir un impact significatif sur les performances de l'environnement et des ajustements supplémentaires peuvent être nécessaires. Si vous pensez que cela vous concerne, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Gitaly Cluster (Praefect) offre les avantages de la tolérance aux pannes, mais implique une complexité supplémentaire de configuration et de gestion. Examinez les limitations techniques et considérations existantes avant de déployer Gitaly Cluster (Praefect).
Pour des conseils sur :
La configuration de cluster recommandée comprend les composants suivants :
Cette section explique en détail comment configurer la configuration standard recommandée dans l'ordre. Pour les configurations plus avancées, consultez la documentation autonome de Gitaly Cluster (Praefect).
Vous pouvez distribuer le trafic vers les nœuds Praefect en utilisant soit un équilibreur de charge TCP, soit un DNS de découverte de services. Un équilibreur de charge TCP est recommandé pour la plupart des configurations car il fonctionne dans tous les scénarios de déploiement.
Un équilibreur de charge TCP traditionnel (tel que HAProxy ou AWS ELB) distribue le trafic sur les nœuds Praefect. Cette approche :
Pour les instructions de configuration, voir Équilibreur de charge.
La découverte de services utilise le DNS pour récupérer les adresses des nœuds Praefect, permettant aux clients de distribuer les requêtes de manière uniforme sur tous les nœuds disponibles. Cette approche :
Pour les instructions de configuration, voir Découverte de services.
Praefect, le routeur et gestionnaire de transactions pour Gitaly Cluster (Praefect), nécessite son propre serveur de base de données pour stocker les données sur le statut de Gitaly Cluster (Praefect).
Si vous souhaitez une configuration hautement disponible, Praefect nécessite une base de données PostgreSQL tierce. Une solution intégrée est en cours de développement.
Les IPs suivantes seront utilisées comme exemple :
10.6.0.141 : Praefect PostgreSQLTout d'abord, assurez-vous d'installer le paquet Linux sur le nœud Praefect PostgreSQL. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi, mais ne fournissez not la valeur EXTERNAL_URL.
Connectez-vous en SSH au nœud Praefect PostgreSQL.
Créez un mot de passe fort pour l'utilisateur Praefect PostgreSQL. Notez ce mot de passe en tant que <praefect_postgresql_password>.
Générez le hachage de mot de passe pour la paire nom d'utilisateur/mot de passe Praefect PostgreSQL. Cela suppose que vous utiliserez le nom d'utilisateur par défaut praefect (recommandé). La commande demandera le mot de passe <praefect_postgresql_password> et une confirmation. Utilisez la valeur renvoyée par cette commande à l'étape suivante comme valeur de <praefect_postgresql_password_hash> :
sudo gitlab-ctl pg-password-md5 praefect
Modifiez /etc/gitlab/gitlab.rb en remplaçant les valeurs indiquées dans la section # START user configuration :
# Disable all components except PostgreSQL and Consul
roles(['postgres_role', 'consul_role'])
# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
# Configure the Consul agent
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
# Replace XXX.XXX.XXX.XXX/YY with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Suivez la post-configuration.
Comme indiqué, une solution PostgreSQL tierce pour la base de données de Praefect est recommandée si vous visez une haute disponibilité complète.
Il existe de nombreuses solutions tierces pour PostgreSQL HA. La solution sélectionnée doit avoir les éléments suivants pour fonctionner avec Praefect :
LISTEN doit être prise en charge.[!note] Avec une configuration tierce, il est possible de co-localiser la base de données de Praefect sur le même serveur que la base de données principale de GitLab. Cependant, si vous utilisez Geo, des instances de base de données séparées sont nécessaires pour gérer correctement la réplication. Dans cette configuration, les spécifications de la configuration principale de la base de données n'ont pas besoin d'être modifiées car l'impact devrait être minimal.
Un fournisseur ou une solution réputé(e) doit être utilisé(e) pour cela. Google Cloud SQL et Amazon RDS sont connus pour fonctionner. Cependant, Amazon Aurora est incompatible avec l'équilibrage de charge activé par défaut depuis 14.4.0.
Voir Fournisseurs et services cloud recommandés pour plus d'informations.
Une fois la base de données configurée, suivez la post-configuration.
Une fois le serveur Praefect PostgreSQL configuré, vous devez configurer l'utilisateur et la base de données que Praefect utilisera.
Nous recommandons de nommer l'utilisateur praefect et la base de données praefect_production, et ceux-ci peuvent être configurés de manière standard dans PostgreSQL. Le mot de passe de l'utilisateur est le même que celui que vous avez configuré précédemment en tant que <praefect_postgresql_password>.
Voici comment cela fonctionnerait avec une configuration PostgreSQL du package Linux :
Connectez-vous en SSH au nœud Praefect PostgreSQL.
Connectez-vous au serveur PostgreSQL avec un accès administratif. L'utilisateur gitlab-psql doit être utilisé ici car il est ajouté par défaut dans le package Linux. La base de données template1 est utilisée car elle est créée par défaut sur tous les serveurs PostgreSQL.
/opt/gitlab/embedded/bin/psql -U gitlab-psql -d template1 -h POSTGRESQL_SERVER_ADDRESS
Créez le nouvel utilisateur praefect, en remplaçant <praefect_postgresql_password> :
CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';
Reconnectez-vous au serveur PostgreSQL, cette fois en tant qu'utilisateur praefect :
/opt/gitlab/embedded/bin/psql -U praefect -d template1 -h POSTGRESQL_SERVER_ADDRESS
Créez une nouvelle base de données praefect_production :
CREATE DATABASE praefect_production WITH ENCODING=UTF8;
Praefect est le routeur et le gestionnaire de transactions pour Gitaly Cluster (Praefect), et toutes les connexions à Gitaly passent par lui. Cette section explique comment le configurer.
[!note] Praefect doit être déployé sur un nombre impair de 3 nœuds ou plus. Ceci pour garantir que les nœuds peuvent prendre des votes dans le cadre d'un quorum.
Praefect nécessite plusieurs jetons secrets pour sécuriser les communications au sein du cluster :
<praefect_external_token> : Utilisé pour les dépôts hébergés sur Gitaly Cluster (Praefect) et accessible uniquement par les clients Gitaly qui portent ce jeton.<praefect_internal_token> : Utilisé pour le trafic de réplication à l'intérieur de Gitaly Cluster (Praefect). Celui-ci est distinct de praefect_external_token car les clients Gitaly ne doivent pas pouvoir accéder directement aux nœuds internes de Gitaly Cluster (Praefect) ; cela pourrait entraîner une perte de données.<praefect_postgresql_password> : Le mot de passe PostgreSQL de Praefect défini dans la section précédente est également requis dans le cadre de cette configuration.Les nœuds de Gitaly Cluster (Praefect) sont configurés dans Praefect via un virtual storage. Chaque stockage contient les détails de chaque nœud Gitaly qui compose le cluster. Chaque stockage reçoit également un nom, et ce nom est utilisé dans plusieurs zones de la configuration. Dans ce guide, le nom du stockage sera default. De plus, ce guide est destiné aux nouvelles installations ; si vous effectuez une mise à niveau d'un environnement existant pour utiliser Gitaly Cluster (Praefect), vous devrez peut-être utiliser un nom différent. Consultez la documentation de Gitaly Cluster (Praefect) pour plus d'informations.
Les IPs suivantes seront utilisées comme exemple :
10.6.0.131 : Praefect 110.6.0.132 : Praefect 210.6.0.133 : Praefect 3Pour configurer les nœuds Praefect, sur chacun d'eux :
Connectez-vous en SSH au serveur Praefect.
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi.
Modifiez le fichier /etc/gitlab/gitlab.rb pour configurer Praefect :
<!-- Updates to example must be made at: - <https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/administration/gitaly/praefect/configure.md#praefect> - All reference architecture pages -->[!note] Vous ne pouvez pas supprimer l'entrée
defaultdevirtual_storagescar GitLab l'exige.
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
# Praefect Configuration
praefect['enable'] = true
# Prevent database migrations from running on upgrade automatically
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false
# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
# START user configuration
# Please set the real values as explained in Required Information section
#
praefect['configuration'] = {
# ...
listen_addr: '0.0.0.0:2305',
auth: {
# ...
#
# Praefect External Token
# This is needed by clients outside the cluster (like GitLab Shell) to communicate with the Praefect cluster
token: '<praefect_external_token>',
},
# Praefect Database Settings
database: {
# ...
host: '10.6.0.141',
port: 5432,
dbname: 'praefect_production',
user: 'praefect',
password: '<praefect_postgresql_password>',
},
# Praefect Virtual Storage config
# Name of storage hash must match storage name in gitlab_rails['repositories_storages'] on the GitLab
# server ('praefect') and in gitaly['configuration'][:storage] on Gitaly nodes ('gitaly-1')
virtual_storage: [
{
# ...
name: 'default',
node: [
{
storage: 'gitaly-1',
address: 'tcp://10.6.0.91:8075',
token: '<praefect_internal_token>'
},
{
storage: 'gitaly-2',
address: 'tcp://10.6.0.92:8075',
token: '<praefect_internal_token>'
},
{
storage: 'gitaly-3',
address: 'tcp://10.6.0.93:8075',
token: '<praefect_internal_token>'
},
],
},
],
# Set the network address Praefect will listen on for monitoring
prometheus_listen_addr: '0.0.0.0:9652',
}
# Set the network address the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Praefect doit exécuter des migrations de base de données, tout comme l'application GitLab principale. Pour cela, vous devez sélectionner one Praefect node only to run the migrations, également appelé le nœud de déploiement. Ce nœud doit être configuré en premier, avant les autres, comme suit :
Dans le fichier /etc/gitlab/gitlab.rb, modifiez la valeur du paramètre praefect['auto_migrate'] de false à true
Pour vous assurer que les migrations de base de données ne sont exécutées que lors de la reconfiguration et non automatiquement lors d'une mise à niveau, exécutez :
sudo touch /etc/gitlab/skip-auto-reconfigure
Sur tous les autres nœuds Praefect, reconfigurez GitLab pour que les modifications prennent effet.
Les nœuds serveurs Gitaly qui composent le cluster ont des exigences qui dépendent des données et de la charge.
[!warning] Les spécifications de Gitaly sont basées sur des percentiles élevés à la fois des modèles d'utilisation et des tailles de dépôt en bonne santé. Cependant, si vous avez des monodépôts volumineux (de plus de plusieurs gigaoctets) ou des charges de travail supplémentaires, ceux-ci peuvent avoir un impact significatif sur les performances de l'environnement et des ajustements supplémentaires peuvent être nécessaires. Si vous pensez que cela vous concerne, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Gitaly a certaines exigences en matière de disque pour les stockages Gitaly.
Les serveurs Gitaly ne doivent pas être exposés à l'Internet public car le trafic réseau sur Gitaly est non chiffré par défaut. L'utilisation d'un pare-feu est fortement recommandée pour restreindre l'accès au serveur Gitaly. Une autre option consiste à utiliser TLS.
Pour configurer Gitaly, vous devez noter les points suivants :
gitaly['configuration'][:storage] doit être configuré pour refléter le chemin de stockage du nœud Gitaly spécifiqueauth_token doit être identique à praefect_internal_tokenLes IPs suivantes seront utilisées comme exemple :
10.6.0.91 : Gitaly 110.6.0.92 : Gitaly 210.6.0.93 : Gitaly 3Sur chaque nœud :
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi, mais ne fournissez not la valeur EXTERNAL_URL.
Modifiez le fichier /etc/gitlab/gitlab.rb du nœud serveur Gitaly pour configurer les chemins de stockage, activer l'écouteur réseau et configurer le jeton :
# https://docs.gitlab.com/omnibus/roles/#gitaly-roles
roles(["gitaly_role"])
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
# START user configuration
# Please set the real values as explained in Required Information section
#
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
# Set the network address that the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
gitaly['configuration'] = {
# ...
#
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
listen_addr: '0.0.0.0:8075',
# Set the network address that Gitaly will listen on for monitoring
prometheus_listen_addr: '0.0.0.0:9236',
# Gitaly Auth Token
# Should be the same as praefect_internal_token
auth: {
# ...
token: '<praefect_internal_token>',
},
# Gitaly Pack-objects cache
# Recommended to be enabled for improved performance but can notably increase disk I/O
# Refer to https://docs.gitlab.com/administration/gitaly/configure_gitaly/#pack-objects-cache for more info
pack_objects_cache: {
# ...
enabled: true,
},
}
#
# END user configuration
Ajoutez les éléments suivants à /etc/gitlab/gitlab.rb pour chaque serveur concerné :
Sur le nœud Gitaly 1 :
gitaly['configuration'] = {
# ...
storage: [
{
name: 'gitaly-1',
path: '/var/opt/gitlab/git-data/repositories',
},
],
}
Sur le nœud Gitaly 2 :
gitaly['configuration'] = {
# ...
storage: [
{
name: 'gitaly-2',
path: '/var/opt/gitlab/git-data/repositories',
},
],
}
Sur le nœud Gitaly 3 :
gitaly['configuration'] = {
# ...
storage: [
{
name: 'gitaly-3',
path: '/var/opt/gitlab/git-data/repositories',
},
],
}
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Enregistrez le fichier, puis reconfigurez GitLab.
Praefect prend en charge le chiffrement TLS. Pour communiquer avec une instance Praefect qui écoute les connexions sécurisées, vous devez :
tls:// dans le gitaly_address de l'entrée de stockage correspondante dans la configuration GitLab.De plus, le certificat, ou son autorité de certification, doit être installé sur tous les serveurs Gitaly et sur tous les clients Praefect qui communiquent avec lui, en suivant la procédure décrite dans la configuration des certificats personnalisés GitLab (et répétée ci-dessous).
Notez les points suivants :
listen_addr et une adresse d'écoute chiffrée tls_listen_addr en même temps. Cela vous permet d'effectuer une transition progressive du trafic non chiffré vers le trafic chiffré, si nécessaire. Pour désactiver l'écouteur non chiffré, définissez praefect['configuration'][:listen_addr] = nil.Pour configurer Praefect avec TLS :
Créez des certificats pour les serveurs Praefect.
Sur les serveurs Praefect, créez le répertoire /etc/gitlab/ssl et copiez-y votre clé et votre certificat :
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem
Modifiez /etc/gitlab/gitlab.rb et ajoutez :
praefect['configuration'] = {
# ...
tls_listen_addr: '0.0.0.0:3305',
tls: {
# ...
certificate_path: '/etc/gitlab/ssl/cert.pem',
key_path: '/etc/gitlab/ssl/key.pem',
},
}
Enregistrez le fichier et reconfigurez.
Sur les clients Praefect (y compris chaque serveur Gitaly), copiez les certificats, ou leur autorité de certification, dans /etc/gitlab/trusted-certs :
sudo cp cert.pem /etc/gitlab/trusted-certs/
Sur les clients Praefect (sauf les serveurs Gitaly), modifiez gitlab_rails['repositories_storages'] dans /etc/gitlab/gitlab.rb comme suit :
gitlab_rails['repositories_storages'] = {
"default" => {
"gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
"gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
}
}
Enregistrez le fichier et reconfigurez GitLab.
Sidekiq nécessite une connexion aux instances Redis, PostgreSQL et Gitaly. Une connexion à Object Storage est également requise, comme recommandé.
Étant donné qu'il est recommandé d'utiliser le stockage d'objets plutôt que NFS pour les objets de données, les exemples suivants incluent la configuration du stockage d'objets.
Si vous constatez que le traitement des jobs Sidekiq de l'environnement est lent avec de longues files d'attente, vous pouvez le mettre à l'échelle en conséquence. Consultez la documentation sur la mise à l'échelle pour plus d'informations.
Lors de la configuration de fonctionnalités GitLab supplémentaires telles que Container Registry, SAML ou LDAP, mettez à jour la configuration Sidekiq en plus de la configuration Rails. Consultez la documentation externe Sidekiq pour plus d'informations.
Les nœuds Sidekiq suivants sont utilisés à titre d'exemple :
10.6.0.71 : Sidekiq 110.6.0.72 : Sidekiq 2Pour configurer les nœuds Sidekiq, sur chacun d'eux :
Connectez-vous en SSH au serveur Sidekiq.
Confirmez que vous pouvez accéder aux ports PostgreSQL, Gitaly et Redis :
telnet <GitLab host> 5432 # PostgreSQL
telnet <GitLab host> 8075 # Gitaly
telnet <GitLab host> 6379 # Redis
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi.
Créez ou modifiez /etc/gitlab/gitlab.rb et utilisez la configuration suivante :
# https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])
# External URL
## This should match the URL of the external load balancer
external_url 'https://gitlab.example.com'
# Redis
redis['master_name'] = 'gitlab-redis'
## The same password for Redis authentication you set up for the master node.
redis['master_password'] = '<redis_primary_password>'
## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
{'host' => '10.6.0.11', 'port' => 26379},
{'host' => '10.6.0.12', 'port' => 26379},
{'host' => '10.6.0.13', 'port' => 26379},
]
# Gitaly Cluster
## repositories_storages gets configured for the Praefect virtual storage
## TCP load balancer (recommended for most setups):
gitlab_rails['repositories_storages'] = {
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
"gitaly_token" => '<praefect_external_token>'
}
}
## Alternatively, use service discovery DNS (requires DNS infrastructure):
# gitlab_rails['repositories_storages'] = {
# "default" => {
# "gitaly_address" => "dns:PRAEFECT_SERVICE_DISCOVERY_ADDRESS:2305",
# "gitaly_token" => '<praefect_external_token>'
# }
# }
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
# Sidekiq
sidekiq['listen_address'] = "0.0.0.0"
## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 4
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
# Object Storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "<gcp-ci_secure_files-bucket-name>"
gitlab_rails['ci_secure_files_object_store_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Pour vous assurer que les migrations de base de données ne sont exécutées que lors de la reconfiguration et non automatiquement lors d'une mise à niveau, exécutez :
sudo touch /etc/gitlab/skip-auto-reconfigure
Seul un nœud désigné unique doit gérer les migrations, comme décrit dans la section Post-configuration de GitLab Rails.
Enregistrez le fichier et reconfigurez GitLab.
Vérifiez que les services GitLab fonctionnent :
sudo gitlab-ctl status
La sortie devrait être similaire à ce qui suit :
run: consul: (pid 30114) 77353s; run: log: (pid 29756) 77367s
run: logrotate: (pid 9898) 3561s; run: log: (pid 29653) 77380s
run: node-exporter: (pid 30134) 77353s; run: log: (pid 29706) 77372s
run: sidekiq: (pid 30142) 77351s; run: log: (pid 29638) 77386s
Cette section décrit comment configurer le composant application GitLab (Rails).
Rails nécessite des connexions aux instances Redis, PostgreSQL et Gitaly. Une connexion à Object Storage est également requise, comme recommandé.
[!note] Étant donné qu'il est recommandé d'utiliser le stockage d'objets plutôt que NFS pour les objets de données, les exemples suivants incluent la configuration du stockage d'objets.
Sur chaque nœud, effectuez les opérations suivantes :
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi.
Créez ou modifiez /etc/gitlab/gitlab.rb et utilisez la configuration suivante. Pour maintenir l'uniformité des liens entre les nœuds, le paramètre external_url sur le serveur d'application doit pointer vers l'URL externe que les utilisateurs utiliseront pour accéder à GitLab. Il s'agirait de l'URL de l'équilibreur de charge externe qui acheminera le trafic vers le serveur d'application GitLab :
external_url 'https://gitlab.example.com'
# gitlab_rails['repositories_storages'] gets configured for the Praefect virtual storage
# TCP load balancer (recommended for most setups):
gitlab_rails['repositories_storages'] = {
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
"gitaly_token" => '<praefect_external_token>'
}
}
# Alternatively, use service discovery DNS (requires DNS infrastructure):
# gitlab_rails['repositories_storages'] = {
# "default" => {
# "gitaly_address" => "dns:PRAEFECT_SERVICE_DISCOVERY_ADDRESS:2305",
# "gitaly_token" => '<praefect_external_token>'
# }
# }
## Disable components that will not be on the GitLab application server
roles(['application_role'])
gitaly['enable'] = false
sidekiq['enable'] = false
## PostgreSQL connection details
# Disable PostgreSQL on the application node
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
## Redis connection details
## Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
## The same password for Redis authentication you set up for the Redis primary node.
redis['master_password'] = '<redis_primary_password>'
## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
{'host' => '10.6.0.11', 'port' => 26379},
{'host' => '10.6.0.12', 'port' => 26379},
{'host' => '10.6.0.13', 'port' => 26379}
]
## Enable service discovery for Prometheus
consul['enable'] = true
consul['monitoring_service_discovery'] = true
# Set the network addresses that the exporters used for monitoring will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
# Add the monitoring node's IP address to the monitoring whitelist and allow it to
# scrape the NGINX metrics
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## Ensure UIDs and GIDs match between servers for permissions via NFS
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002
# Object storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "<gcp-ci_secure_files-bucket-name>"
gitlab_rails['ci_secure_files_object_store_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
Si vous utilisez Gitaly avec la prise en charge TLS, assurez-vous que l'entrée gitlab_rails['repositories_storages'] est configurée avec tls à la place de tcp :
# TCP load balancer with TLS (recommended for most setups):
gitlab_rails['repositories_storages'] = {
"default" => {
"gitaly_address" => "tls://10.6.0.40:3305", # internal load balancer IP
"gitaly_token" => '<praefect_external_token>'
}
}
# Alternatively, use service discovery DNS with TLS (requires DNS infrastructure and GitLab 18.9+):
# gitlab_rails['repositories_storages'] = {
# "default" => {
# "gitaly_address" => "dns+tls://DNS_SERVER_ADDRESS:53/PRAEFECT_SERVICE_DISCOVERY_ADDRESS:3305",
# "gitaly_token" => '<praefect_external_token>'
# }
# }
Copiez le certificat dans /etc/gitlab/trusted-certs :
sudo cp cert.pem /etc/gitlab/trusted-certs/
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de paquet Linux que vous avez configuré et ajoutez ou remplacez le fichier du même nom sur ce serveur. S'il s'agit du premier nœud de paquet Linux que vous configurez, vous pouvez ignorer cette étape.
Copiez les clés d'hôte SSH (toutes au format de nom /etc/ssh/ssh_host_*_key*) du premier nœud Rails que vous avez configuré et ajoutez-les ou remplacez les fichiers du même nom sur ce serveur. Cela garantit que les erreurs de non-correspondance d'hôte ne sont pas générées pour vos utilisateurs lorsqu'ils accèdent aux nœuds Rails à charge équilibrée. S'il s'agit du premier nœud du package Linux que vous configurez, vous pouvez ignorer cette étape.
Pour vous assurer que les migrations de base de données ne sont exécutées que lors de la reconfiguration et non automatiquement lors d'une mise à niveau, exécutez :
sudo touch /etc/gitlab/skip-auto-reconfigure
Seul un nœud désigné unique doit gérer les migrations, comme décrit dans la section Post-configuration de GitLab Rails.
Reconfigurez GitLab pour que les modifications prennent effet.
Exécutez sudo gitlab-rake gitlab:gitaly:check pour confirmer que le nœud peut se connecter à Gitaly.
Consultez les journaux pour voir les requêtes :
sudo gitlab-ctl tail gitaly
Vérifiez que les services GitLab fonctionnent :
sudo gitlab-ctl status
La sortie devrait être similaire à ce qui suit :
run: consul: (pid 4890) 8647s; run: log: (pid 29962) 79128s
run: gitlab-exporter: (pid 4902) 8647s; run: log: (pid 29913) 79134s
run: gitlab-workhorse: (pid 4904) 8646s; run: log: (pid 29713) 79155s
run: logrotate: (pid 12425) 1446s; run: log: (pid 29798) 79146s
run: nginx: (pid 4925) 8646s; run: log: (pid 29726) 79152s
run: node-exporter: (pid 4931) 8645s; run: log: (pid 29855) 79140s
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s
Lorsque vous spécifiez https dans le external_url, comme dans l'exemple précédent, GitLab s'attend à ce que les certificats SSL se trouvent dans /etc/gitlab/ssl/. Si les certificats ne sont pas présents, NGINX ne pourra pas démarrer. Pour plus d'informations, consultez la documentation HTTPS.
Vérifiez que toutes les migrations ont été exécutées :
gitlab-rake gitlab:db:configure
Cette opération nécessite la configuration du nœud Rails pour se connecter directement à la base de données principale, en contournant PgBouncer. Une fois les migrations terminées, vous devez configurer le nœud pour qu'il passe à nouveau par PgBouncer.
Configurez la recherche rapide des clés SSH autorisées dans la base de données.
Le package Linux peut être utilisé pour configurer un nœud de surveillance autonome exécutant Prometheus :
Connectez-vous en SSH au nœud de surveillance.
Téléchargez et installez le paquet Linux de votre choix. Veillez à n'ajouter que le dépôt de paquets GitLab et à installer GitLab pour le système d'exploitation choisi.
Modifiez /etc/gitlab/gitlab.rb et ajoutez le contenu :
roles(['monitoring_role', 'consul_role'])
external_url 'http://gitlab.example.com'
# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Configure Prometheus to scrape services not covered by discovery
prometheus['scrape_configs'] = [
{
'job_name': 'pgbouncer',
'static_configs' => [
'targets' => [
"10.6.0.31:9188",
"10.6.0.32:9188",
"10.6.0.33:9188",
],
],
},
{
'job_name': 'praefect',
'static_configs' => [
'targets' => [
"10.6.0.131:9652",
"10.6.0.132:9652",
"10.6.0.133:9652",
],
],
},
]
nginx['enable'] = false
Enregistrez le fichier et reconfigurez GitLab.
Vérifiez que les services GitLab fonctionnent :
sudo gitlab-ctl status
La sortie devrait être similaire à ce qui suit :
run: consul: (pid 31637) 17337s; run: log: (pid 29748) 78432s
run: logrotate: (pid 31809) 2936s; run: log: (pid 29581) 78462s
run: nginx: (pid 31665) 17335s; run: log: (pid 29556) 78468s
run: prometheus: (pid 31672) 17335s; run: log: (pid 29633) 78456s
GitLab prend en charge l'utilisation d'un service de stockage d'objets pour stocker de nombreux types de données. Il est recommandé par rapport à NFS pour les objets de données et, en général, il est préférable dans les configurations plus importantes car le stockage d'objets est généralement beaucoup plus performant, fiable et évolutif. Voir Fournisseurs et services cloud recommandés pour plus d'informations.
Il existe deux façons de spécifier la configuration du stockage d'objets dans GitLab :
Le formulaire consolidé est utilisé dans les exemples suivants lorsqu'il est disponible.
L'utilisation de buckets séparés pour chaque type de données est l'approche recommandée pour GitLab. Cela garantit qu'il n'y a pas de collisions entre les différents types de données que GitLab stocke. Il est prévu de permettre l'utilisation d'un seul bucket à l'avenir.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>GitLab Runner renvoie les journaux de job en morceaux que le package Linux met en cache temporairement sur le disque dans /var/opt/gitlab/gitlab-ci/builds par défaut, même lors de l'utilisation du stockage d'objets consolidé. Avec la configuration par défaut, ce répertoire doit être partagé via NFS sur tous les nœuds GitLab Rails et Sidekiq.
Bien que le partage des journaux de job via NFS soit pris en charge, évitez d'utiliser NFS en activant la journalisation incrémentielle (requise lorsqu'aucun nœud NFS n'a été déployé). La journalisation incrémentielle utilise Redis au lieu de l'espace disque pour la mise en cache temporaire des journaux de job.
Vous pouvez tirer parti d'Elasticsearch et activer la recherche avancée pour une recherche de code plus rapide et plus avancée sur l'ensemble de votre instance GitLab.
La conception et les exigences du cluster Elasticsearch dépendent de vos données spécifiques. Pour les meilleures pratiques recommandées sur la configuration de votre cluster Elasticsearch aux côtés de votre instance, lisez comment choisir la configuration optimale du cluster.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>L'architecture de référence GitLab à 60 RPS ou 3 000 utilisateurs est la plus petite que nous recommandons qui atteigne la haute disponibilité (HA). Cependant, pour les environnements qui doivent servir moins d'utilisateurs ou un RPS plus faible tout en maintenant la HA, il existe plusieurs modifications prises en charge que vous pouvez apporter à cette architecture pour réduire la complexité et les coûts.
Il convient de noter que pour atteindre la HA avec GitLab, la composition de l'architecture à 60 RPS ou 3 000 utilisateurs est en définitive ce qui est requis. Chaque composant a diverses considérations et règles à respecter, et l'architecture satisfait à toutes ces exigences. Les versions plus petites de cette architecture seront fondamentalement les mêmes, mais avec des exigences de performances moindres, les modifications suivantes sont prises en charge comme suit :
[!note] Si cela n'est pas indiqué ci-dessous, aucune autre modification n'est prise en charge pour les nombres d'utilisateurs inférieurs.
Une approche alternative consiste à exécuter des composants GitLab spécifiques dans Kubernetes. Les services suivants sont pris en charge :
Les installations hybrides tirent parti des avantages des déploiements cloud natifs et des déploiements de calcul traditionnels. Ainsi, les composants sans état peuvent bénéficier des avantages de la gestion des charges de travail cloud native, tandis que les composants avec état sont déployés dans des machines virtuelles de calcul avec des installations de packages Linux pour bénéficier d'une permanence accrue.
Consultez la documentation de configuration avancée des charts Helm pour les instructions de configuration, notamment les conseils sur les secrets GitLab à synchroniser entre Kubernetes et les composants backend.
[!note] Il s'agit d'une configuration advanced. L'exécution de services dans Kubernetes est bien connue pour être complexe. This setup is only recommended que si vous avez de solides connaissances et une expérience pratique de Kubernetes. Le reste de cette section part de ce principe.
Pour des informations sur la disponibilité de Gitaly sur Kubernetes, les limitations et les considérations de déploiement, consultez Gitaly sur Kubernetes.
Les tableaux et le diagramme suivants détaillent l'environnement hybride en utilisant les mêmes formats que l'environnement type documenté précédemment.
Les premiers sont les composants qui s'exécutent dans Kubernetes. Ceux-ci s'exécutent sur plusieurs groupes de nœuds, bien que vous puissiez modifier la composition globale selon vos besoins, tant que les exigences minimales en matière de CPU et de mémoire sont respectées.
| Groupe de nœuds de composants | Totaux du pool de nœuds cibles | Exemple GCP | Exemple AWS |
|---|---|---|---|
| Webservice | 16 vCPU | ||
| 20 Go de mémoire (demande) | |||
| 28 Go de mémoire (limite) | 2 x n1-standard-16 | 2 x c5.4xlarge | |
| Sidekiq | 7,2 vCPU | ||
| 16 Go de mémoire (demande) | |||
| 32 Go de mémoire (limite) | 3 x n1-standard-4 | 3 x m5.xlarge | |
| Services de support | 4 vCPU | ||
| 15 Go de mémoire | 2 x n1-standard-2 | 2 x m5.large |
Viennent ensuite les composants backend qui s'exécutent sur des machines virtuelles de calcul statiques à l'aide du package Linux (ou de services PaaS externes le cas échéant) :
| Service | Nœuds | Configuration | Exemple GCP<sup>1</sup> | Exemple AWS<sup>1</sup> |
|---|---|---|---|---|
| Consul<sup>2</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large |
| PostgreSQL<sup>2</sup> | 3 | 2 vCPU, 7,5 Go de mémoire | n1-standard-2 | m5.large |
| PgBouncer<sup>2</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large |
| Équilibreur de charge interne<sup>4</sup> | 1 | 4 vCPU, 3,6 Go de mémoire | n1-highcpu-4 | c5n.xlarge |
| Redis/Sentinel<sup>3</sup> | 3 | 2 vCPU, 7,5 Go de mémoire | n1-standard-2 | m5.large |
| Gitaly<sup>6</sup><sup>7</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge |
| Praefect<sup>6</sup> | 3 | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large |
| Praefect PostgreSQL<sup>2</sup> | 1+ | 2 vCPU, 1,8 Go de mémoire | n1-highcpu-2 | c5.large |
| Stockage d'objets<sup>5</sup> | - | - | - | - |
Footnotes :
<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->Gitaly.[!note] Pour toutes les solutions PaaS impliquant la configuration d'instances, il est recommandé de mettre en œuvre un minimum de trois nœuds dans trois zones de disponibilité différentes afin de s'aligner sur les pratiques d'architecture cloud résiliente.
@startuml 3k
skinparam linetype ortho
card "Kubernetes via Helm Charts" as kubernetes {
card "**External Load Balancer**" as elb #6a9be7
together {
collections "**Webservice**" as gitlab #32CD32
collections "**Sidekiq**" as sidekiq #ff8dd1
}
card "**Supporting Services**" as support
}
card "**Internal Load Balancer**" as ilb #9370DB
collections "**Consul** x3" as consul #e76a9b
card "Gitaly Cluster" as gitaly_cluster {
collections "**Praefect** x3" as praefect #FF8C00
collections "**Gitaly** x3" as gitaly #FF8C00
card "**Praefect PostgreSQL***\n//Non fault-tolerant//" as praefect_postgres #FF8C00
praefect -[#FF8C00]-> gitaly
praefect -[#FF8C00]> praefect_postgres
}
card "Database" as database {
collections "**PGBouncer** x3" as pgbouncer #4EA7FF
card "**PostgreSQL** (Primary)" as postgres_primary #4EA7FF
collections "**PostgreSQL** (Secondary) x2" as postgres_secondary #4EA7FF
pgbouncer -[#4EA7FF]-> postgres_primary
postgres_primary .[#4EA7FF]> postgres_secondary
}
card "redis" as redis {
collections "**Redis** x3" as redis_nodes #FF6347
}
cloud "**Object Storage**" as object_storage #white
elb -[#6a9be7]-> gitlab
elb -[hidden]-> sidekiq
elb -[hidden]-> support
gitlab -[#32CD32]--> ilb
gitlab -[#32CD32]r--> object_storage
gitlab -[#32CD32,norank]----> redis
gitlab -[#32CD32]----> database
sidekiq -[#ff8dd1]--> ilb
sidekiq -[#ff8dd1]r--> object_storage
sidekiq -[#ff8dd1,norank]----> redis
sidekiq .[#ff8dd1]----> database
ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden,norank]--> redis
consul .[#e76a9b]--> database
consul .[#e76a9b,norank]--> gitaly_cluster
consul .[#e76a9b]--> redis
@enduml
La section suivante détaille les cibles utilisées pour les composants GitLab déployés dans Kubernetes.
Chaque pod Webservice (Puma et Workhorse) est recommandé d'être exécuté avec la configuration suivante :
Pour 60 RPS ou 3 000 utilisateurs, nous recommandons un nombre total de workers Puma d'environ 16, et il est donc recommandé d'exécuter au moins 4 pods Webservice.
Pour plus d'informations sur l'utilisation des ressources Webservice, consultez la documentation Charts sur les ressources Webservice.
Il est également recommandé de déployer les pods du contrôleur Gateway API ou Ingress sur les nœuds Webservice en tant que DaemonSet. Cela permet aux contrôleurs de s'adapter dynamiquement aux pods Webservice qu'ils servent et tire parti de la bande passante réseau plus élevée que les types de machines plus grands ont généralement.
Ce n'est pas une exigence stricte. Les pods du contrôleur Gateway API ou Ingress peuvent être déployés selon les besoins, tant qu'ils disposent de ressources suffisantes pour gérer le trafic web.
Chaque pod Sidekiq est recommandé d'être exécuté avec la configuration suivante :
Comme pour le déploiement standard documenté précédemment, une cible initiale de 8 workers Sidekiq a été utilisée ici. Des workers supplémentaires peuvent être nécessaires en fonction de votre flux de travail spécifique.
Pour plus d'informations sur l'utilisation des ressources Sidekiq, consultez la documentation Charts sur les ressources Sidekiq.
Le pool de nœuds Supporting est conçu pour héberger tous les déploiements de support qui ne sont pas requis sur les pools Webservice et Sidekiq.
Cela inclut divers déploiements liés à l'implémentation du fournisseur cloud et aux déploiements GitLab de support tels que GitLab Shell.
Pour effectuer des déploiements supplémentaires tels que Container Registry, Pages ou Monitoring, déployez-les dans le pool de nœuds Supporting si possible et non dans les pools Webservice ou Sidekiq. Le pool de nœuds Supporting a été conçu pour accueillir plusieurs déploiements supplémentaires. Cependant, si vos déploiements ne s'intègrent pas dans le pool tel que défini, vous pouvez augmenter le pool de nœuds en conséquence. À l'inverse, si le pool est sur-dimensionné pour votre cas d'utilisation, vous pouvez le réduire en conséquence.
Un exemple pour les charts Helm GitLab pour la configuration de l'architecture de référence à 60 RPS ou 3 000 utilisateurs est disponible dans le projet Charts.
<div align="right"> <a type="button" class="btn btn-default" href="#set-up-components"> Retour à la configuration des composants <i class="fa fa-angle-double-up" aria-hidden="true"></i> </a> </div>Après avoir suivi ce guide, vous devriez maintenant disposer d'un environnement GitLab vierge avec les fonctionnalités principales configurées en conséquence.
Vous souhaiterez peut-être configurer des fonctionnalités optionnelles supplémentaires de GitLab en fonction de vos besoins. Consultez Étapes après l'installation de GitLab pour plus d'informations.
[!note] En fonction de votre environnement et de vos besoins, des exigences matérielles supplémentaires ou des ajustements peuvent être nécessaires pour configurer des fonctionnalités supplémentaires selon vos souhaits. Consultez les pages individuelles pour plus d'informations.