doc-locale/fr-fr/administration/reference_architectures/10k_users.md
{{< details >}}
{{< /details >}}
Cette page décrit l'architecture de référence GitLab conçue pour cibler une charge maximale de 200 requêtes par seconde (RPS), la charge maximale typique jusqu'à 10 000 utilisateurs, à la fois manuels et automatisés, basée sur des données réelles.
Pour une liste complète des architectures de référence, voir Architectures de référence disponibles.
[!note] Avant de déployer cette architecture, il est recommandé de lire d'abord la documentation principale, notamment les sections Avant de commencer et Choisir l'architecture à utiliser.
| 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 | 8 vCPU, 30 Go de mémoire | n1-standard-8 | m5.2xlarge | D8s 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 - Cache<sup>3</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge | D4s v3 |
| Redis/Sentinel - Persistant<sup>3</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge | D4s v3 |
| Gitaly<sup>6</sup><sup>7</sup> | 3 | 16 vCPU, 60 Go de mémoire | n1-standard-16 | m5.4xlarge | D16s 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> | 4 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge | D4s v3 |
| GitLab Rails<sup>8</sup> | 3 | 32 vCPU, 28,8 Go de mémoire | n1-highcpu-32 | c5.9xlarge | F32s v2 |
| Nœud de surveillance | 1 | 4 vCPU, 3,6 Go de mémoire | n1-highcpu-4 | c5.xlarge | F4s 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 10k
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** x4" 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 Persistent** x3" as redis_persistent #FF6347
collections "**Redis Cache** x3" as redis_cache #FF6347
redis_cache -[hidden]-> redis_persistent
}
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 exigences pour les architectures de référence.
L'architecture de référence 200 RPS / 10 000 utilisateurs est conçue pour s'adapter aux flux de travail les plus courants. GitLab effectue régulièrement des tests de smoke et de performance par rapport aux cibles de débit des points de terminaison suivantes :
| Type de point de terminaison | Débit cible |
|---|---|
| API | 200 RPS |
| Web | 20 RPS |
| Git (Pull) | 20 RPS |
| Git (Push) | 4 RPS |
Ces cibles sont basées sur des données client 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.
Vous pourriez avoir besoin d'ajustements supplémentaires 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 à vous, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Notre environnement de test utilise :
Pour configurer GitLab et ses composants afin d'accueillir jusqu'à 200 RPS ou 10 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 des descriptions de chaque serveur et son IP attribuée :
10.6.0.10 : Équilibreur de charge externe10.6.0.11 : Consul 110.6.0.12 : Consul 210.6.0.13 : Consul 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.40 : Équilibreur de charge interne10.6.0.51 : Redis - Cache Principal10.6.0.52 : Redis - Réplique Cache 110.6.0.53 : Redis - Réplique Cache 210.6.0.61 : Redis - Persistant Principal10.6.0.62 : Redis - Réplique Persistante 110.6.0.63 : Redis - Réplique Persistante 210.6.0.91 : Gitaly 110.6.0.92 : 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.101 : Sidekiq 110.6.0.102 : Sidekiq 210.6.0.103 : Sidekiq 310.6.0.104 : Sidekiq 410.6.0.111 : Application GitLab 110.6.0.112 : Application GitLab 210.6.0.113 : Application GitLab 310.6.0.151 : 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 concernant l'équilibreur de charge à utiliser 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 votre équilibreur de charge de 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 configurations de ports supplémentaires. GitLab Pages nécessite une adresse IP virtuelle distincte. Configurez DNS pour pointer pages_external_url depuis /etc/gitlab/gitlab.rb vers la nouvelle adresse IP virtuelle. Consultez la documentation de 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 de 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 qui permet 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 GitLab HTTP documentée précédemment.
Configurez 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 transmettre les connexions sur le port 443 en tant que protocole TCP plutôt que HTTP(S). Cela transmettra la connexion au service NGINX du nœud d'application sans la modifier. 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 concernant l'équilibreur de charge à utiliser 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 votre équilibreur de charge de 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
Consultez la documentation de votre équilibreur de charge préféré pour plus d'informations.
<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. Cela garantit que les nœuds peuvent voter 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 package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 IPs correctes.
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 sont en cours d'exécution :
sudo gitlab-ctl status
La sortie devrait ressembler à 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 serez guidé dans la configuration d'un cluster PostgreSQL hautement disponible à utiliser avec GitLab.
Au lieu des composants PostgreSQL, PgBouncer et Consul de découverte de services fournis avec le package 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 recommandée du package Linux 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. Ceci est distinct du cluster PgBouncer principal qui suit le nœud principal.
Les IPs suivantes seront 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 package Linux GitLab on each node. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 hash de mot de passe pour la paire nom d'utilisateur/mot de passe PostgreSQL. Cela suppose que vous utiliserez le nom d'utilisateur par défaut gitlab (recommandé). La commande vous demandera un mot de passe et une confirmation. Utilisez la valeur générée par cette commande à l'étape suivante comme valeur de <postgresql_password_hash> :
sudo gitlab-ctl pg-password-md5 gitlab
Générez un hash de mot de passe pour la paire nom d'utilisateur/mot de passe PgBouncer. Cela suppose que vous utiliserez le nom d'utilisateur par défaut pgbouncer (recommandé). La commande vous demandera un mot de passe et une confirmation. Utilisez la valeur générée par cette commande à l'étape suivante comme valeur de <pgbouncer_password_hash> :
sudo gitlab-ctl pg-password-md5 pgbouncer
Générez un hash de mot de passe pour la paire nom d'utilisateur/mot de passe de réplication PostgreSQL. Cela suppose que vous utiliserez le nom d'utilisateur par défaut gitlab_replicator (recommandé). La commande vous demandera un mot de passe et une confirmation. Utilisez la valeur généré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 hash de mot de passe pour la paire nom d'utilisateur/mot de passe de la base de données Consul. Cela suppose que vous utiliserez le nom d'utilisateur par défaut gitlab-consul (recommandé). La commande vous demandera un mot de passe et une confirmation. Utilisez la valeur généré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, utilisera par défaut pg_rewind pour gérer les conflits. Comme la plupart des méthodes de gestion du basculement, celle-ci présente une faible probabilité d'entraîner une perte de données. Pour plus d'informations, consultez les différentes méthodes de réplication Patroni.
/etc/gitlab/gitlab-secrets.json depuis le premier nœud de package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 ressembler à 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 'State' pour un nœud ne 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 seront 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 hashes 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'
Copiez le fichier /etc/gitlab/gitlab-secrets.json depuis le premier nœud de package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Si une erreur execute[generate databases.ini] se produit, cela est dû à un problème connu existant. Il sera résolu lorsque vous exécuterez un second reconfigure après l'étape suivante.
Créez un fichier .pgpass afin que Consul puisse recharger PgBouncer. Saisissez le mot de passe PgBouncer deux fois lorsque vous y êtes invité :
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
Reconfigurez GitLab une nouvelle fois pour résoudre les erreurs potentielles des étapes précédentes.
Assurez-vous que chaque nœud communique avec le nœud principal actuel :
gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
Une fois que l'invite de la console est disponible, exécutez les requêtes suivantes :
show databases ; show clients ;
La sortie devrait ressembler à 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)
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. Cela garantit que Redis Sentinel peut voter dans le cadre d'un quorum. Cela ne s'applique pas lors de la configuration de Redis en externe, par exemple via 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. Pour cette taille d'architecture, il est fortement recommandé d'avoir des instances Cache et Persistant séparées comme spécifié pour obtenir des performances optimales. Consultez la documentation sur la mise à l'échelle pour plus d'informations.
Redis nécessite une authentification si 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 afin de 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 ports par défaut).Dans cette section, vous serez guidé dans la configuration de deux clusters Redis externes à utiliser avec GitLab. Les IPs suivantes seront utilisées comme exemple :
10.6.0.51 : Redis - Cache Principal10.6.0.52 : Redis - Réplique Cache 110.6.0.53 : Redis - Réplique Cache 210.6.0.61 : Redis - Persistant Principal10.6.0.62 : Redis - Réplique Persistante 110.6.0.63 : Redis - Réplique Persistante 2Vous pouvez optionnellement utiliser un service externe tiers pour les instances Redis Cache et Persistance avec les conseils suivants :
Pour plus d'informations, voir Fournisseurs de cloud et services recommandés.
C'est la section où nous installons et configurons les nouvelles instances Redis Cache.
Les nœuds Redis principal et réplique ont besoin du même mot de passe défini dans redis['password']. À tout moment lors d'un basculement, les Sentinels peuvent reconfigurer un nœud et changer son statut de principal à réplique (et vice versa).
Connectez-vous en SSH au serveur Redis Principal.
Téléchargez et installez le package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 must bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.51'
# 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_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'
## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.51'
# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
## 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 même contenu que le nœud principal dans la section précédente en remplaçant redis_master_node par redis_replica_node :
# 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 must bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.52'
# 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_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'
## The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.51'
# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
## 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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épliques 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>C'est la section où nous installons et configurons les nouvelles instances Redis Persistant.
Les nœuds Redis principal et réplique ont besoin du même mot de passe défini dans redis['password']. À tout moment lors d'un basculement, les Sentinels peuvent reconfigurer un nœud et changer son statut de principal à réplique (et vice versa).
Connectez-vous en SSH au serveur Redis Principal.
Téléchargez et installez le package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 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_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'
## 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package Linux que vous configurez, vous pouvez ignorer cette étape.
Reconfigurez GitLab pour que les modifications prennent effet.
Connectez-vous en SSH au serveur Redis Persistant replica.
Téléchargez et installez le package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 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_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'
# 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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épliques 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 stocker les dépôts Git. Dans cette configuration, chaque dépôt Git est stocké sur chaque nœud Gitaly du cluster, l'un é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 les centiles élevés des modes d'utilisation et des tailles de dépôt en bon état. Cependant, si vous avez des monorepos volumineux (supérieurs à 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 pourraient être nécessaires. Si vous pensez que cela s'applique à vous, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Gitaly Cluster (Praefect) offre les avantages de la tolérance aux pannes, mais s'accompagne d'une complexité supplémentaire en termes 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 recommandée du cluster comprend les composants suivants :
Cette section explique comment configurer la configuration standard recommandée dans l'ordre. Pour des 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 entre les nœuds Praefect. Cette approche :
Pour les instructions de configuration, voir équilibreur de charge.
La découverte de services utilise DNS pour récupérer les adresses des nœuds Praefect, permettant aux clients de distribuer les requêtes uniformément entre 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 d'état du cluster.
Si vous souhaitez disposer d'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 package Linux sur le nœud Praefect PostgreSQL. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 à utiliser pour l'utilisateur Praefect PostgreSQL. Notez ce mot de passe en tant que <praefect_postgresql_password>.
Générez le hachage du mot de passe pour la paire nom d'utilisateur/mot de passe de Praefect PostgreSQL. Cela suppose que vous utiliserez le nom d'utilisateur par défaut praefect (recommandé). La commande demande le mot de passe <praefect_postgresql_password> et la confirmation. Utilisez la valeur généré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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 la haute disponibilité PostgreSQL. La solution sélectionnée doit présenter les caractéristiques suivantes pour fonctionner avec Praefect :
LISTEN doit être prise en charge.[!note] Avec une configuration tierce, il est possible de colocaliser la base de données de Praefect sur le même serveur que la base de données principale de GitLab, par commodité, sauf si vous utilisez Geo, où des instances de base de données séparées sont requises pour gérer correctement la réplication. Dans cette configuration, les spécifications de la configuration de base de données principale n'ont pas à être modifiées car l'impact devrait être minimal.
Un fournisseur ou une solution réputée doit être utilisé 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 à partir de la version 14.4.0.
Consultez 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, ces éléments pouvant ê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 via le 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-ci 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 le traversent. Cette section explique comment le configurer.
[!note] Consul doit être déployé avec un nombre impair de 3 nœuds ou plus. Cela garantit que les nœuds peuvent voter 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 au sein de Gitaly Cluster (Praefect). Il 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), ce qui 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 avec 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, qui est utilisé dans plusieurs domaines de la configuration. Dans ce guide, le nom du stockage sera default. De plus, ce guide est destiné aux nouvelles installations. Si vous mettez à niveau un environnement existant pour utiliser Gitaly Cluster (Praefect), vous devrez peut-être utiliser un nom différent. Reportez-vous à 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 package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 de la 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 serveur Gitaly qui composent le cluster ont des exigences dépendant des données et de la charge.
[!warning] Les spécifications de Gitaly sont basées sur les centiles élevés des modes d'utilisation et des tailles de dépôt en bon état. Cependant, si vous avez des monorepos volumineux (supérieurs à 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 pourraient être nécessaires. Si vous pensez que cela s'applique à vous, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Gitaly présente 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 n'est pas 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, tenez compte des 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 package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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',
auth: {
# Gitaly Auth Token
# Should be the same as praefect_internal_token
token: '<praefect_internal_token>',
},
pack_objects_cache: {
# 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
enabled: true,
},
}
#
# END user configuration
Ajoutez ce qui suit à /etc/gitlab/gitlab.rb pour chaque serveur respectif :
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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package 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 Configuration de 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. Il nécessite également une connexion au stockage d'objets tel que 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 dimensionner 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. Reportez-vous à la documentation externe sur Sidekiq pour plus d'informations.
Les nœuds Sidekiq suivants sont utilisés à titre d'exemple :
10.6.0.101 : Sidekiq 110.6.0.102 : Sidekiq 210.6.0.103 : Sidekiq 310.6.0.104 : Sidekiq 4Pour 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 package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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 connection details
## First cluster that will host the cache data
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
gitlab_rails['redis_cache_sentinels'] = [
{host: '10.6.0.51', port: 26379},
{host: '10.6.0.52', port: 26379},
{host: '10.6.0.53', port: 26379},
]
## Second cluster that hosts all other persistent data
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
gitlab_rails['redis_sentinels'] = [
{host: '10.6.0.61', port: 26379},
{host: '10.6.0.62', port: 26379},
{host: '10.6.0.63', port: 26379},
]
# Gitaly Cluster
## 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>'
# }
# }
# 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.151/32', '127.0.0.0/8']
# 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de 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 de la mise à niveau, exécutez :
sudo touch /etc/gitlab/skip-auto-reconfigure
Un seul nœud désigné doit gérer les migrations, comme indiqué dans la section Post-configuration de GitLab Rails.
Reconfigurez GitLab pour que les modifications prennent effet.
Cette section décrit comment configurer le composant application GitLab (Rails).
Rails nécessite des connexions aux instances Redis, PostgreSQL et Gitaly. Il nécessite également une connexion au stockage d'objets tel que 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.
Les IPs suivantes seront utilisées comme exemple :
10.6.0.111 : Application GitLab 110.6.0.112 : Application GitLab 210.6.0.113 : Application GitLab 3Sur chaque nœud, effectuez les opérations suivantes :
Téléchargez et installez le package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre système d'exploitation choisi.
Modifiez /etc/gitlab/gitlab.rb et utilisez la configuration suivante. Pour maintenir l'uniformité des liens entre les nœuds, le external_url sur le serveur d'application doit pointer vers l'URL externe que les utilisateurs utiliseront pour accéder à GitLab. Il s'agira 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
## First cluster that will host the cache data
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
gitlab_rails['redis_cache_sentinels'] = [
{host: '10.6.0.51', port: 26379},
{host: '10.6.0.52', port: 26379},
{host: '10.6.0.53', port: 26379},
]
## Second cluster that hosts all other persistent data
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
gitlab_rails['redis_sentinels'] = [
{host: '10.6.0.61', port: 26379},
{host: '10.6.0.62', port: 26379},
{host: '10.6.0.63', port: 26379},
]
# 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'
puma['listen'] = '0.0.0.0'
# 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.151/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.151/32', '127.0.0.0/8']
#############################
### 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 au lieu 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 package Linux que vous avez configuré et ajoutez-le ou remplacez le fichier du même nom sur ce serveur. Si c'est le premier nœud de package Linux que vous configurez, vous pouvez ignorer cette étape.
Copiez les clés hôtes SSH (toutes au format de nom /etc/ssh/ssh_host_*_key*) depuis le premier nœud Rails que vous avez configuré et ajoutez-les ou remplacez les fichiers du même nom sur ce serveur. Cela garantit qu'aucune erreur de non-concordance d'hôte n'est générée pour vos utilisateurs lorsqu'ils accèdent aux nœuds Rails équilibrés en charge. S'il s'agit du premier nœud de 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 de la mise à niveau, exécutez :
sudo touch /etc/gitlab/skip-auto-reconfigure
Un seul nœud désigné doit gérer les migrations, comme indiqué dans la section Post-configuration de GitLab Rails.
Reconfigurez GitLab pour que les modifications prennent effet.
Confirmez que le nœud peut se connecter à Gitaly :
sudo gitlab-rake gitlab:gitaly:check
Ensuite, consultez les logs pour voir les requêtes :
sudo gitlab-ctl tail gitaly
Optionnellement, depuis les serveurs Gitaly, confirmez que Gitaly peut effectuer des callbacks vers l'API interne :
sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml.sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml.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 démarrera pas. Pour plus d'informations, consultez la documentation HTTPS.
Désignez un nœud d'application pour l'exécution des migrations de base de données lors de l'installation et des mises à jour. Initialisez la base de données GitLab et assurez-vous que toutes les migrations ont été exécutées :
sudo gitlab-rake gitlab:db:configure
Cette opération nécessite de configurer le nœud Rails pour se connecter directement à la base de données primaire, 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.
L'IP suivante sera utilisée comme exemple :
10.6.0.151 : PrometheusPour configurer le nœud de surveillance :
Connectez-vous en SSH au nœud de surveillance.
Téléchargez et installez le package Linux de votre choix. Veillez à n'ajouter que le référentiel de packages GitLab et à installer GitLab pour votre 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
Reconfigurez GitLab pour que les modifications prennent effet.
GitLab prend en charge l'utilisation d'un service de stockage d'objets pour stocker de nombreux types de données. Il est recommandé de préférer le stockage d'objets à NFS pour les objets de données et, en général, il est plus adapté aux configurations plus grandes car le stockage d'objets est généralement beaucoup plus performant, fiable et évolutif. Consultez 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 compartiments distincts pour chaque type de données est l'approche recommandée pour GitLab. Cela garantit l'absence de collisions entre les différents types de données stockés par GitLab. Des plans sont en cours pour permettre l'utilisation d'un compartiment unique à 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 logs de job par blocs, 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 logs de job via NFS soit pris en charge, évitez d'utiliser NFS en activant la journalisation incrémentielle (obligatoire lorsqu'aucun nœud NFS n'a été déployé). La journalisation incrémentielle utilise Redis plutôt que l'espace disque pour la mise en cache temporaire des logs 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 connaître 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>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 natives, tandis que les composants avec état sont déployés dans des VM de calcul avec des installations de packages Linux pour bénéficier d'une permanence accrue.
Reportez-vous à la documentation 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 connue pour être complexe. This setup is only recommended si vous avez de solides connaissances et une expérience pratique de Kubernetes. Le reste de cette section part de ce postulat.
Pour obtenir des informations sur la disponibilité de Gitaly sur Kubernetes, ses limites et les considérations de déploiement, consultez Gitaly sur Kubernetes.
Les tableaux et le diagramme suivants décrivent l'environnement hybride en utilisant les mêmes formats que l'environnement typique documenté précédemment.
Les premiers sont les composants qui s'exécutent dans Kubernetes. Ceux-ci s'exécutent dans plusieurs groupes de nœuds, bien que vous puissiez modifier la composition globale selon vos besoins, à condition que les exigences minimales en matière de CPU et de mémoire soient respectées.
| Groupe de nœuds de composant | Totaux cibles du pool de nœuds | Exemple GCP | Exemple AWS |
|---|---|---|---|
| Webservice | 80 vCPU | ||
| 100 Go de mémoire (requête) | |||
| 140 Go de mémoire (limite) | 3 x n1-standard-32 | 3 x c5.9xlarge | |
| Sidekiq | 12,6 vCPU | ||
| 28 Go de mémoire (requête) | |||
| 56 Go de mémoire (limite) | 4 x n1-standard-4 | 4 x m5.xlarge | |
| Services de support | 8 vCPU | ||
| 30 Go de mémoire | 2 x n1-standard-4 | 2 x m5.xlarge |
Viennent ensuite les composants backend qui s'exécutent sur des VM de calcul statiques utilisant le package Linux (ou des 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 | 8 vCPU, 30 Go de mémoire | n1-standard-8 | m5.2xlarge |
| 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 - Cache<sup>3</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge |
| Redis/Sentinel - Persistant<sup>3</sup> | 3 | 4 vCPU, 15 Go de mémoire | n1-standard-4 | m5.xlarge |
| Gitaly<sup>6</sup><sup>7</sup> | 3 | 16 vCPU, 60 Go de mémoire | n1-standard-16 | m5.4xlarge |
| 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 10k
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 Persistent** x3" as redis_persistent #FF6347
collections "**Redis Cache** x3" as redis_cache #FF6347
redis_cache -[hidden]-> redis_persistent
}
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.
Il est recommandé d'exécuter chaque pod Webservice (Puma et Workhorse) avec la configuration suivante :
Pour 200 RPS ou 10 000 utilisateurs, nous recommandons un nombre total de workers Puma d'environ 80, ce qui implique qu'il est recommandé d'exécuter au moins 20 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 se mettre à l'échelle dynamiquement avec les pods Webservice qu'ils servent, tout en tirant parti de la bande passante réseau plus élevée que les types de machines plus importants offrent 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, à condition de disposer de suffisamment de ressources pour gérer le trafic web.
Il est recommandé d'exécuter chaque pod Sidekiq avec la configuration suivante :
Comme pour le déploiement standard documenté précédemment, une cible initiale de 14 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 de support est conçu pour héberger tous les déploiements de support qui ne sont pas requis dans 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 de support dans la mesure du possible, et non dans les pools Webservice ou Sidekiq. Le pool de nœuds de support a été conçu pour accueillir plusieurs déploiements supplémentaires. Cependant, si vos déploiements ne tiennent 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-approvisionné dans votre cas d'utilisation, vous pouvez le réduire en conséquence.
Un exemple de configuration des charts Helm GitLab ciblant l'architecture de référence 200 RPS ou 10 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 récent 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] Selon votre environnement et 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. Reportez-vous aux pages individuelles pour plus d'informations.