Back to Gitlabhq

Configurer une instance Sidekiq externe

doc-locale/fr-fr/administration/sidekiq/_index.md

19.2.08.8 KB
Original Source

{{< details >}}

  • Niveau : Free, Premium, Ultimate
  • Offre : GitLab Self-Managed

{{< /details >}}

Vous pouvez configurer une instance Sidekiq externe en utilisant Sidekiq intégré dans le package GitLab. Sidekiq nécessite une connexion aux instances Redis, PostgreSQL et Gitaly.

Configurer l'accès TCP pour PostgreSQL, Gitaly et Redis sur l'instance GitLab {#configure-tcp-access-for-postgresql-gitaly-and-redis-on-the-gitlab-instance}

Par défaut, GitLab utilise des sockets UNIX et n'est pas configuré pour communiquer via TCP. Pour modifier cela :

  1. Configurer le serveur PostgreSQL intégré pour écouter sur TCP/IP en ajoutant les adresses IP du serveur Sidekiq à postgresql['md5_auth_cidr_addresses']

  2. Rendre Redis intégré accessible via TCP

  3. Modifiez le fichier /etc/gitlab/gitlab.rb sur votre instance GitLab et ajoutez ce qui suit :

    ruby
    ## Gitaly
    gitaly['configuration'] = {
       # ...
       #
       # Make Gitaly accept connections on all network interfaces
       listen_addr: '0.0.0.0:8075',
       auth: {
          ## Set up the Gitaly token as a form of authentication because you are accessing Gitaly over the network
          ## https://docs.gitlab.com/administration/gitaly/configure_gitaly/#about-the-gitaly-token
          token: 'abc123secret',
       },
    }
    
    gitlab_rails['gitaly_token'] = 'abc123secret'
    
    # Password to Authenticate Redis
    gitlab_rails['redis_password'] = 'redis-password-goes-here'
    
  4. Exécutez reconfigure :

    shell
    sudo gitlab-ctl reconfigure
    
  5. Redémarrez le serveur PostgreSQL :

    shell
    sudo gitlab-ctl restart postgresql
    

Configurer une instance Sidekiq {#set-up-sidekiq-instance}

Trouvez votre architecture de référence et suivez les détails de configuration de l'instance Sidekiq.

Configurer plusieurs nœuds Sidekiq avec un stockage partagé {#configure-multiple-sidekiq-nodes-with-shared-storage}

Si vous exécutez plusieurs nœuds Sidekiq avec un stockage de fichiers partagé, comme NFS, vous devez spécifier les UID et GID pour vous assurer qu'ils correspondent entre les serveurs. La spécification des UID et GID empêche les problèmes de permissions dans le système de fichiers. Ce conseil est similaire aux recommandations pour les configurations Geo.

Pour configurer plusieurs nœuds Sidekiq :

  1. Modifiez /etc/gitlab/gitlab.rb :

    ruby
    user['uid'] = 9000
    user['gid'] = 9000
    web_server['uid'] = 9001
    web_server['gid'] = 9001
    registry['uid'] = 9002
    registry['gid'] = 9002
    
  2. Reconfigurer GitLab :

    shell
    sudo gitlab-ctl reconfigure
    

Configurer le registre de conteneurs lors de l'utilisation d'un Sidekiq externe {#configure-the-container-registry-when-using-an-external-sidekiq}

Si vous utilisez le registre de conteneurs et qu'il s'exécute sur un nœud différent de Sidekiq, suivez les étapes ci-dessous.

  1. Modifiez /etc/gitlab/gitlab.rb et configurez l'URL du registre :

    ruby
    gitlab_rails['registry_api_url'] = "https://registry.example.com"
    
  2. Reconfigurer GitLab :

    shell
    sudo gitlab-ctl reconfigure
    
  3. Dans l'instance où le registre de conteneurs est hébergé, copiez le fichier registry.key vers le nœud Sidekiq.

Configurer le serveur de métriques Sidekiq {#configure-the-sidekiq-metrics-server}

Si vous souhaitez collecter les métriques Sidekiq, activez le serveur de métriques Sidekiq. Pour rendre les métriques disponibles depuis localhost:8082/metrics :

Pour configurer le serveur de métriques :

  1. Modifiez /etc/gitlab/gitlab.rb :

    ruby
    sidekiq['metrics_enabled'] = true
    sidekiq['listen_address'] = "localhost"
    sidekiq['listen_port'] = 8082
    
    # Optionally log all the metrics server logs to log/sidekiq_exporter.log
    sidekiq['exporter_log_enabled'] = true
    
  2. Reconfigurer GitLab :

    shell
    sudo gitlab-ctl reconfigure
    

Activer HTTPS {#enable-https}

{{< history >}}

{{< /history >}}

Pour servir les métriques via HTTPS plutôt que HTTP, activez TLS dans les paramètres de l'exportateur :

  1. Modifiez /etc/gitlab/gitlab.rb pour ajouter (ou trouver et décommenter) les lignes suivantes :

    ruby
    sidekiq['exporter_tls_enabled'] = true
    sidekiq['exporter_tls_cert_path'] = "/path/to/certificate.pem"
    sidekiq['exporter_tls_key_path'] = "/path/to/private-key.pem"
    
  2. Enregistrez le fichier et reconfigurez GitLab pour que les modifications prennent effet.

Lorsque TLS est activé, les mêmes port et address sont utilisés que ceux décrits précédemment. Le serveur de métriques ne peut pas servir à la fois HTTP et HTTPS en même temps.

Configurer les vérifications de santé {#configure-health-checks}

Si vous utilisez des sondes de vérification de santé pour observer Sidekiq, activez le serveur de vérification de santé Sidekiq. Pour rendre les vérifications de santé disponibles depuis localhost:8092 :

  1. Modifiez /etc/gitlab/gitlab.rb :

    ruby
    sidekiq['health_checks_enabled'] = true
    sidekiq['health_checks_listen_address'] = "localhost"
    sidekiq['health_checks_listen_port'] = 8092
    
  2. Reconfigurer GitLab :

    shell
    sudo gitlab-ctl reconfigure
    

Pour plus d'informations sur les vérifications de santé, consultez la page de vérification de santé Sidekiq.

Configurer LDAP et la synchronisation des utilisateurs ou des groupes {#configure-ldap-and-user-or-group-synchronization}

Si vous utilisez LDAP pour la gestion des utilisateurs et des groupes, vous devez ajouter la configuration LDAP à votre nœud Sidekiq ainsi qu'au worker de synchronisation LDAP. Si la configuration LDAP et le worker de synchronisation LDAP ne sont pas appliqués à votre nœud Sidekiq, les utilisateurs et les groupes ne sont pas automatiquement synchronisés.

Pour plus d'informations sur la configuration de LDAP pour GitLab, consultez :

Pour activer LDAP avec le worker de synchronisation pour Sidekiq :

  1. Modifiez /etc/gitlab/gitlab.rb :

    ruby
    gitlab_rails['ldap_enabled'] = true
    gitlab_rails['prevent_ldap_sign_in'] = false
    gitlab_rails['ldap_servers'] = {
    'main' => {
    'label' => 'LDAP',
    'host' => 'ldap.mydomain.com',
    'port' => 389,
    'uid' => 'sAMAccountName',
    'encryption' => 'simple_tls',
    'verify_certificates' => true,
    'bind_dn' => '_the_full_dn_of_the_user_you_will_bind_with',
    'password' => '_the_password_of_the_bind_user',
    'tls_options' => {
       'ca_file' => '',
       'ssl_version' => '',
       'ciphers' => '',
       'cert' => '',
       'key' => ''
    },
    'timeout' => 10,
    'active_directory' => true,
    'allow_username_or_email_login' => false,
    'block_auto_created_users' => false,
    'base' => 'dc=example,dc=com',
    'user_filter' => '',
    'attributes' => {
       'username' => ['uid', 'userid', 'sAMAccountName'],
       'email' => ['mail', 'email', 'userPrincipalName'],
       'name' => 'cn',
       'first_name' => 'givenName',
       'last_name' => 'sn'
    },
    'lowercase_usernames' => false,
    
    # Enterprise Edition only
    # https://docs.gitlab.com/administration/auth/ldap/ldap_synchronization/
    'group_base' => '',
    'admin_group' => '',
    'external_groups' => [],
    'sync_ssh_keys' => false
    }
    }
    gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"
    
  2. Reconfigurer GitLab :

    shell
    sudo gitlab-ctl reconfigure
    

Configurer les groupes SAML pour la synchronisation des groupes SAML {#configure-saml-groups-for-saml-group-sync}

Si vous utilisez la synchronisation des groupes SAML, vous devez configurer les groupes SAML sur tous vos nœuds Sidekiq.

Dépannage {#troubleshooting}

Consultez notre guide d'administration pour le dépannage de Sidekiq.