ansible-ThoTeam.nexus3-oss

Aperçu Versions Perspectives

Rôle Ansible : Nexus 3 OSS

Ce rôle installe et configure Nexus Repository Manager OSS version 3.x.

Toute configuration peut être mise à jour en relançant le rôle, sauf pour les paramètres liés aux blobstores, qui sont immuables dans Nexus.

logo travis-ci.com L'intégration continue de ce rôle utilise fièrement des crédits OSS attribués par https://travis.com

Table des Matières

Remarque : Les liens dans la table des matières ne fonctionneront pas correctement lors de la consultation depuis le site d'Ansible Galaxy. Voir sur GitHub

(Créé avec gh-md-toc)

Historique / Crédits

Ce rôle est un fork de ansible-nexus3-oss par @savoirfairelinux après qu'ils aient annoncé la fin de maintenance. Vous pouvez consulter les tickets suivants dans le dépôt d'origine pour des explications :

Nous souhaitons remercier les auteurs d'origine pour le travail accompli.

En Mémoriam [Lionel Lecha] (note de l'auteur principal) :

Image de Lionel Lecha Ce travail n'aurait jamais atteint la communauté en tant que projet Open Source sans la confiance inconditionnelle de Lionel Lecha, directeur de SMAP APPUI @La Poste lorsque j'ai commencé à automatiser le déploiement de Nexus pour son unité en 2018 en tant que sous-traitant. Lionel est décédé trop tôt le 17 février 2023 à l'âge de 60 ans. Merci pour toujours votre bonne humeur constante et votre confiance.

Exigences

  • Une version d'Ansible relativement à jour. Nous suivons les versions d'Ansible durant la maintenance/le développement et nous profiterons des nouvelles fonctionnalités si nécessaire (et mettrons à jour meta/main.yml pour la version minimale).
  • OS compatible. Ce rôle est testé via Molecule sur Travis CI pour CentOS 8, Ubuntu Bionic (18.04), et Debian buster. D'autres scénarios de Molecule peuvent être exécutés localement pour CentOS 7, Ubuntu Xenial (16.04), et Debian stretch.
  • Rsync doit être installé sur la machine cible (il n'est pas nécessaire sur l'hôte exécutant Ansible si différent).
  • La bibliothèque jmespath doit être installée sur l'hôte exécutant le playbook (nécessaire pour le filtre json_query). Voir requirements.txt.
  • Java 8 (obligatoire)
    • Oracle a annoncé la fin de vie de Java 8. Sonatype recommande maintenant openjdk8.
    • Pour plus d'informations, voir exigences système de nexus3.
  • Apache HTTPD (optionnel)
    • Utilisé pour configurer un reverse proxy SSL.
    • Les modules suivants doivent être activés dans votre configuration : mod_ssl, mod_rewrite, mod_proxy, mod_proxy_http, mod_headers.

(Voir la section Dépendances ci-dessous pour les rôles correspondants sur Galaxy)

Variables de Rôle

Variables Ansible, avec les valeurs par défaut (voir default/main.yml) :

Variables générales

    nexus_version: ''
    nexus_timezone: 'UTC'
    nexus_download_url: "http://download.sonatype.com/nexus/3"
    # nexus_download_ssl_verify: <unset>
    # nexus_version_running: <unset>

Le rôle installera la dernière version disponible de Nexus par défaut. Vous pouvez fixer la version en définissant la variable nexus_version. Voir les versions disponibles à l'adresse https://www.sonatype.com/download-oss-sonatype. En cas de téléchargement lent via un proxy, un essai peut être utile pour éviter les délais d'attente. Vous pouvez ajouter des essais au téléchargement en définissant ces variables :

    nexus_download_retries: 3 # 0 par défaut
    nexus_download_delay: 15

Si vous fixez la version et la changez pour une autre, le rôle tentera de mettre à niveau votre installation. Assurez-vous de changer pour une version ultérieure dans l'historique des versions. La rétrogradation échouera (à moins que vous ne réinstalliez à partir de zéro en utilisant la nexus_purge variable spéciale).

Si vous ne fixez pas la version et jouez le rôle sur une installation existante, la version installée actuelle sera utilisée (détectant la cible de {{ nexus_installation_dir}}/nexus-latest). Si vous souhaitez mettre à niveau Nexus, vous devrez passer la variable spéciale nexus_upgrade=true sur la ligne de commande d'ansible-playbook. Voir Mettre à niveau Nexus vers la dernière version.

Si vous utilisez une version plus ancienne que la dernière, vous devez vous assurer de ne pas utiliser de fonctionnalités qui ne sont pas disponibles dans la version installée (par exemple, les dépôts hébergés par yum pour Nexus < 3.8.0, le dépôt git lfs pour Nexus < 3.3.0, etc.)

nexus_timezone est un nom de fuseau horaire Java et peut être utile en combinaison avec les expressions cron de nexus_scheduled_tasks ci-dessous.

Vous pouvez changer le site de téléchargement pour les packages en ajustant nexus_download_url (par exemple, environnement fermé, proxy/cache sur votre réseau...). Dans ce cas, la détection automatique de la dernière version échouera probablement et vous devrez fixer la version à télécharger. Si vous souhaitez toujours profiter de la détection automatique de la dernière version, un appel à <votre_emplacement_personnalisé>/latest-unix.tar.gz doit renvoyer un HTTP 302 redirigeant vers la dernière version disponible dans votre cache/proxy. Si votre emplacement de téléchargement utilise https avec un certificat auto-signé (ou d'une PKI privée) et que vous avez des problèmes pour le faire valider (c'est-à-dire, des erreurs de téléchargement dans le rôle) et que vous faites pleinement confiance à la cible, vous pouvez définir nexus_download_ssl_verify: false.

nexus_version_running est une variable utilisée en interne. En tant que telle, elle ne doit jamais être définie directement. Elle n'existera que si Nexus est actuellement installé sur l'hôte et enregistrera la version actuelle avant d'exécuter le rôle. Elle peut être utilisée plus tard dans votre playbook si nécessaire (par exemple, pour un e-mail de notification de mise à niveau).

Répertoire de téléchargement pour le package Nexus

    nexus_download_dir: '/tmp'

Répertoire sur la cible où le package Nexus sera téléchargé.

Remarque importante : si vous avez l'intention d'exécuter le rôle régulièrement pour maintenir/provisionner votre installation Nexus, vous devez vous assurer que les fichiers téléchargés persistent entre les exécutions. Sur RHEL/CentOS spécifiquement, vous devez changer ce répertoire pour un emplacement qui n'est pas nettoyé automatiquement. Si le fichier de package ne persiste pas, il sera retéléchargé, ce qui pourrait entraîner un redémarrage inutile de Nexus.

Répertoire tmp local sur le contrôleur

nexus_local_tmp_dir: /tmp

Ce répertoire est utilisé pour créer une archive locale d'un script Groovy avant de les envoyer à la cible. Sur un contrôleur Ansible partagé, vous devriez modifier ce chemin pour un que vous possédez (par exemple, /home/<user>/tmp). Important : ce répertoire doit exister.

Port, chemin de contexte et IP d'écoute de Nexus

    nexus_default_port: 8081
    nexus_application_host: '{{ httpd_setup_enable | ternary("127.0.0.1", "0.0.0.0") }}'
    nexus_default_context_path: '/'

Port/IP d'écoute et chemin de contexte du processus Java Nexus.

  • L'IP/Interface d'écoute (c'est-à-dire nexus_application_host) dépend par défaut de la configuration httpd_setup_enable. Nexus écoutera seulement sur localhost (127.0.0.1) si le reverse proxy est activé ou sur toutes les IP configurées (0.0.0.0) si ce n'est pas le cas. Vous pouvez changer ce paramètre selon vos besoins (c'est-à-dire ne pas installer de proxy et lier seulement à 127.0.0.1 si vous installez votre propre proxy).
  • nexus_default_context_path doit conserver la barre oblique de fin lorsqu'il est défini, par ex. : nexus_default_context_path: '/nexus/'.

Utilisateur et groupe OS de Nexus

    nexus_os_group: 'nexus'
    nexus_os_gid: 1000
    nexus_os_user: 'nexus'
    nexus_os_uid: 1000

Utilisateur et groupe utilisés pour posséder les fichiers de Nexus et exécuter le service, ceux-ci seront créés par le rôle s'ils sont absents. Si définis, un uid et un gid seront utilisés lors de la création.

    nexus_os_user_home_dir: '/home/nexus'

Permet de changer le répertoire personnel par défaut de l'utilisateur Nexus.

Répertoires d'instance de Nexus

    nexus_installation_dir: '/opt'
    nexus_data_dir: '/var/nexus'
    nexus_tmp_dir: "{{ (ansible_os_family == 'RedHat') | ternary('/var/nexus-tmp', '/tmp/nexus') }}"

Répertoires Nexus.

  • nexus_installation_dir contient les exécutions installées.
  • nexus_data_dir contient toute la configuration, les dépôts et les artefacts téléchargés. Les chemins blobstores personnalisés en dehors de nexus_data_dir peuvent être configurés, voir nexus_blobstores ci-dessous.
  • nexus_tmp_dir contient tous les fichiers temporaires. Le chemin par défaut pour RedHat a été déplacé hors de /tmp pour surmonter les problèmes potentiels avec les procédures de nettoyage automatique. Voir #168.

Paramètres JVM de Nexus

    nexus_min_heap_size: "1200M"
    nexus_max_heap_size: "{{ nexus_min_heap_size }}"
    nexus_max_direct_memory: "2G"

Ce sont les valeurs par défaut pour Nexus. Veuillez ne pas modifier ces valeurs à moins que vous n'ayez lu la section mémoire des exigences système de Nexus et que vous compreniez ce que vous faites.

En second avertissement, voici un extrait du document ci-dessus :

Augmenter la mémoire heap de la JVM au-delà des valeurs recommandées dans le but d'améliorer les performances n'est pas conseillé. Cela peut effectivement avoir l'effet inverse, faisant que le système d'exploitation se débatte inutilement.

    nexus_custom_jvm_settings: []

Paramètres supplémentaires à passer à la JVM. Ceux-ci sont vides par défaut et ne devraient pas contenir d'options liées à la mémoire ci-dessus (c'est-à-dire tout ce qui commence par Xms, Xmx, ou XX:MaxDirectMemorySize=). Chaque option doit être définie comme un élément de la liste sans le tiret de début (-).

Voici un exemple pour changer le collecteur de déchets à G1 et régler les logs GC avec rotation.

    nexus_custom_jvm_settings:
      - XX:+UseG1GC
      - XX:+PrintGCDetails
      - Xloggc:{{ nexus_installation_dir }}log/gc.log
      - XX:+UseGCLogFileRotation
      - XX:NumberOfGCLogFiles=10
      - XX:GCLogFileSize=50m

Installation de plugins

nexus_plugin_urls: []

Mettre une liste d'URLs pointant vers des plugins construits pour votre version de Nexus. Seuls les bundles *.kar peuvent être installés de cette manière.

Assistant d'intégration

nexus_onboarding_wizard: false

Contrôle si l'assistant d'intégration Nexus s'exécute lorsque l'utilisateur admin se connecte pour la première fois.

Mot de passe admin

    nexus_admin_password: 'changeme'

Le mot de passe du compte 'admin' à configurer. Cela ne fonctionne que lors de la première installation par défaut. Veuillez consulter Changer le mot de passe admin après la première installation si vous souhaitez le modifier plus tard avec le rôle.

Il est fortement conseillé de ne pas conserver votre mot de passe en texte clair dans votre playbook et d'utiliser le chiffrement ansible-vault (soit en ligne soit dans un fichier séparé chargé avec include_vars par exemple).

Accès anonyme par défaut

    nexus_anonymous_access: false

Autoriser l'accès anonyme à Nexus.

Nom d'hôte public

    nexus_public_hostname: 'nexus.vm'
    nexus_public_scheme: https

Le nom de domaine pleinement qualifié et le schéma sous lequel l'instance Nexus sera accessible à ses clients.

Accès API pour ce rôle

    nexus_api_hostname: localhost
    nexus_api_scheme: http
    nexus_api_validate_certs: "{{ nexus_api_scheme == 'https' }}"
    nexus_api_context_path: "{{ nexus_default_context_path }}"
    nexus_api_port: "{{ nexus_default_port }}"
    nexus_api_timeout: 60

Ces vars contrôlent comment le rôle se connecte à l'API Nexus pour le provisionnement. Pour les usages avancés uniquement. Vous ne voudrez probablement pas changer ces paramètres par défaut.

Remarque : le nexus_api_timeout a été ajouté dans v2.4.19 et remplace le default uri module timeout de 30s pour tous les appels à l'API.

Capacités de marque

    nexus_branding_header: ""
    nexus_branding_footer: "Dernière provisionnée {{ ansible_date_time.iso8601 }}"

En-tête et pied de page de marque, ceux-ci peuvent contenir du HTML.

Capacité d'audit

    nexus_audit_enabled: false

La capacité d'audit de Nexus est désactivée par défaut. Vous pouvez l'activer en le définissant sur true. Veuillez noter que les données d'audit sont stockées dans la base de données de Nexus, persistent à travers les redémarrages et ne sont pas automatiquement tournées/nettoyées.

Visualiseur Log4j

    nexus_log4j_visualizer_enabled: false

Par défaut, le visualiseur Log4j est désactivé. Vous pouvez l'activer en le définissant sur true. Cela ajoutera la capacité log4j-visualizer à votre instance Nexus.

Configuration du reverse proxy

    httpd_setup_enable: false
    httpd_server_name: "{{ nexus_public_hostname }}"
    httpd_default_admin_email: "[email protected]"
    httpd_ssl_certificate_file: 'files/nexus.vm.crt'
    httpd_ssl_certificate_key_file: 'files/nexus.vm.key'
    # httpd_ssl_certificate_chain_file: "{{ httpd_ssl_certificate_file }}"
    httpd_copy_ssl_files: true

Configurer un reverse proxy SSL. Ceci nécessite que httpd soit installé. Remarque : lorsque httpd_setup_enable est défini sur true, Nexus lie par défaut à 127.0.0.1:8081 donc pas directement accessible sur le port HTTP 8081 depuis une IP externe. (Si vous souhaitez changer cela, vous pouvez explicitement définir nexus_application_host: 0.0.0.0).

Le nom d'hôte par défaut utilisé est nexus_public_hostname. Si vous avez besoin de noms différents pour une raison quelconque, vous pouvez définir httpd_server_name sur une valeur différente.

Avec httpd_copy_ssl_files: true (par défaut), les certificats ci-dessus doivent exister dans votre répertoire de playbook et seront copiés vers le serveur et configurés dans Apache. httpd_ssl_certificate_chain_file est optionnel et doit rester non défini si vous ne souhaitez pas configurer un fichier de chaîne.

Si vous souhaitez utiliser des certificats existants sur le serveur, définissez httpd_copy_ssl_files: false et fournissez les variables suivantes :

    # Ceux-ci spécifient au vhost où trouver sur le système distant les fichiers de certificat.
    httpd_ssl_cert_file_location: "/etc/pki/tls/certs/wildcard.vm.crt"
    httpd_ssl_cert_key_location: "/etc/pki/tls/private/wildcard.vm.key"
    # httpd_ssl_cert_chain_file_location: "{{ httpd_ssl_cert_file_location }}"

httpd_ssl_cert_chain_file_location est optionnel et doit rester non défini si vous ne souhaitez pas configurer un fichier de chaîne.

    httpd_default_admin_email: "[email protected]"

Définir l'adresse e-mail admin par défaut d'httpd.

Configuration LDAP

Les connexions LDAP et le domaine de sécurité sont désactivés par défaut.

    nexus_ldap_realm: false
    ldap_connections: []

Configuration des connexions LDAP, chaque élément se présente comme suit :

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'Mon LDAP d'Entreprise' # utilisé comme clé pour mettre à jour la configuration ldap
        ldap_protocol: 'ldaps' # ldap ou ldaps
        ldap_hostname: 'ldap.monentreprise.com'
        ldap_port: 636
        ldap_use_trust_store: false # S'il faut ou non utiliser des certificats dans le magasin de confiance de Nexus
        ldap_search_base: 'dc=monentreprise,dc=net'
        ldap_auth: 'none' # ou simple
        ldap_auth_username: 'utilisateur' # si auth = simple
        ldap_auth_password: 'motdepasse' # si auth = simple
        ldap_user_base_dn: 'ou=users'
        ldap_user_filter: '(cn=*)' # (optionnel)
        ldap_user_object_class: 'inetOrgPerson'
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_user_subtree: false
        ldap_map_groups_as_roles: false
        ldap_group_base_dn: 'ou=groups'
        ldap_group_object_class: 'posixGroup'
        ldap_group_id_attribute: 'cn'
        ldap_group_member_attribute: 'memberUid'
        ldap_group_member_format: '${username}'
        ldap_group_subtree: false

Exemple de configuration LDAP pour une authentification anonyme (anonyme bind), qui est également la configuration "minimal" :

    nexus_ldap_realm: true
    ldap_connection:
      - ldap_name: 'Configuration LDAP la plus simple'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.monentreprise.com'
        ldap_search_base: 'dc=monentreprise,dc=net'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_user_object_class: 'inetOrgPerson'

Exemple de configuration LDAP pour une authentification simple (en utilisant un compte DSA) :

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'Configuration LDAP avec DSA'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.monentreprise.com'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_auth: 'simple'
        ldap_auth_username: 'cn=mynexus,ou=dsa,dc=monentreprise,dc=net'
        ldap_auth_password: "{{ vault_ldap_dsa_password }}" # mieux vaut garder les mots de passe dans un coffre Ansible
        ldap_search_base: 'dc=monentreprise,dc=net'
        ldap_user_base_dn: 'ou=users'
        ldap_user_object_class: 'inetOrgPerson'
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_user_subtree: false

Exemple de configuration LDAP pour une authentification simple (en utilisant un compte DSA) + groupes mappés en rôles :

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'Configuration LDAP avec DSA'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.monentreprise.com'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_auth: 'simple'
        ldap_auth_username: 'cn=mynexus,ou=dsa,dc=monentreprise,dc=net'
        ldap_auth_password: "{{ vault_ldap_dsa_password }}" # mieux vaut garder les mots de passe dans un coffre Ansible
        ldap_search_base: 'dc=monentreprise,dc=net'
        ldap_user_base_dn: 'ou=users'
        ldap_user_object_class: 'inetOrgPerson'
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_map_groups_as_roles: true
        ldap_group_base_dn: 'ou=groups'
        ldap_group_object_class: 'groupOfNames'
        ldap_group_id_attribute: 'cn'
        ldap_group_member_attribute: 'member'
        ldap_group_member_format: 'uid=${username},ou=users,dc=monentreprise,dc=net'
        ldap_group_subtree: false

Exemple de configuration LDAP pour une authentification simple (en utilisant un compte DSA) + groupes mappés en rôles dynamiquement :

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'Configuration LDAP avec DSA'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.monentreprise.com'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_auth: 'simple'
        ldap_auth_username: 'cn=mynexus,ou=dsa,dc=monentreprise,dc=net'
        ldap_auth_password: "{{ vault_ldap_dsa_password }}" # mieux vaut garder les mots de passe dans un coffre Ansible
        ldap_search_base: 'dc=monentreprise,dc=net'
        ldap_user_base_dn: 'ou=users'
        ldap_user_object_class: 'inetOrgPerson'
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_map_groups_as_roles: true
        ldap_map_groups_as_roles_type: 'dynamic'
        ldap_user_memberof_attribute: 'memberOf'

@nliebelt a proposé une configuration avec des explications dans un problème pour configurer Nexus pour Active Directory.

Privilèges

    nexus_privileges:
      - name: all-repos-read # utilisé comme clé pour mettre à jour un privilège
        # type: <un des application, repository-admin, repository-content-selector, repository-view, script ou wildcard>
        description: 'Accès en lecture et navigation à tous les dépôts'
        repository: '*'
        actions: # peut être add, browse, create, delete, edit, read ou * (tous)
          - read
          - browse
        # pattern: pattern
        # domain: domain
        # script_name: name

Liste des privilèges à configurer. Veuillez consulter la documentation et l'interface utilisateur pour vérifier quelles variables doivent être définies selon le type de privilège.

Ces éléments sont combinés avec les valeurs par défaut suivantes :

    _nexus_privilege_defaults:
      type: repository-view
      format: maven2
      actions:
        - read

Rôles

    nexus_roles:
      - id: Developpers # peut se mapper à un id de groupe LDAP, utilisé également comme clé pour mettre à jour un rôle
        name: developers
        description: Tous les développeurs
        privileges:
          - nx-search-read
          - all-repos-read
        roles: [] # références à d'autres noms de rôle

En plus de créer des rôles, il est également possible de définir un rôle par défaut qui sera appliqué aux utilisateurs et aux requêtes anonymes lorsque Nexus ne trouve pas ou ne mappe pas le rôle correspondant. Le rôle par défaut peut être défini en utilisant :

nexus_default_role: "developers" # utilise le rôle 'developers' pour tous les utilisateurs/requêtes sans un rôle explicitement assigné. Par défaut : ""

Liste des rôles à configurer.

Utilisateurs

    nexus_local_users: []
      # - username: jenkins # utilisé comme clé pour mettre à jour
      #   state: present # valeur par défaut si omise, utilisez 'absent' pour supprimer l'utilisateur
      #   first_name: Jenkins
      #   last_name: CI
      #   email: [email protected]
      #   password: "s3cr3t"
      #   roles:
      #     - developers # id de rôle

Liste des utilisateurs/comptes locaux (non LDAP) à créer dans Nexus. L'état absent supprimera l'utilisateur s'il existe.

      nexus_ldap_users: []
      # - username: j.doe
      #   state: present
      #   roles:
      #     - "nx-admin"

Mappages des utilisateurs/roles LDAP. L'état absent supprimera les rôles de l'utilisateur existant s'ils sont déjà présents. Les utilisateurs LDAP ne sont pas supprimés. Essayer de définir des rôles sur un utilisateur non existant entraînera une erreur.

Sélecteurs de contenu

  nexus_content_selectors:
  - name: docker-login
    description: Sélecteur pour le privilège de connexion à Docker
    search_expression: format=="docker" and path=~"/v2/"

Pour plus d'infos sur le sélecteur de contenu, voir la documentation.

Pour utiliser un sélecteur de contenu, ajoutez un nouveau privilège avec type: repository-content-selector et le contentSelector approprié.

- name: docker-login-privilege
  type: repository-content-selector
  contentSelector: docker-login
  description: 'Connexion au registre Docker'
  repository: '*'
  actions:
  - read
  - browse

Politiques de nettoyage

nexus_repos_cleanup_policies:
#   - name: mvn_cleanup
#     format: maven2
#     mode:
#     notes: ""
#     criteria:
#       lastBlobUpdated: 60
#       lastDownloaded: 120
#       preRelease: RELEASES
#       regexKey: "foo.*"

Définitions des politiques de nettoyage. Peut être ajoutées aux définitions des dépôts avec l'option cleanup_policies.

Blobstores et dépôts

    nexus_delete_default_repos: false

Supprimer certains dépôts de la configuration par défaut initiale de l'installation de Nexus. Cette étape n'est exécutée qu'à la première installation (quand nexus_data_dir a été détecté comme vide).

    nexus_delete_default_blobstore: false

Supprimer le blobstore par défaut de la configuration par défaut initiale de l'installation de Nexus. Cela ne peut être fait que si nexus_delete_default_repos: true et que tous les dépôts configurés (voir ci-dessous) ont un blob_store: custom explicite. Cette étape n'est exécutée qu'à la première installation (quand nexus_data_dir a été détecté comme vide).

    nexus_blobstores: []
    # exemple d'élément de blobstore :
    # - name: separate-storage
    #   type: file
    #   path: /mnt/custom/path
    # - name: s3-blobstore
    #   type: S3
    #   config:
    #     bucket: s3-blobstore
    #     accessKeyId: "{{ VAULT_ENCRYPTED_KEY_ID }}"
    #     secretAccessKey: "{{ VAULT_ENCRYPTED_ACCESS_KEY }}"

Blobstores à créer. Un chemin de blobstore et un blobstore de dépôt ne peuvent pas être mis à jour après la création initiale (toute mise à jour ici sera ignorée lors de la re-provisionnement).

La configuration d'un blobstore sur S3 est fournie à titre de convenance et ne fait pas partie des tests automatisés que nous exécutons sur Travis. Veuillez noter que le stockage sur S3 n'est recommandé que pour les instances déployées sur AWS.

    nexus_repos_maven_proxy:
      - name: central
        remote_url: 'https://repo1.maven.org/maven2/'
        layout_policy: permissive
        # cleanup_policies:
        #    - mvn_cleanup
        # maximum_component_age: -1
        # maximum_metadata_age: 1440
        # negative_cache_enabled: true
        # negative_cache_ttl: 1440
        # La disposition de contenu n'est prise en charge que pour les proxys bruts et maven2 et peut être définie sur attachment ou inline. Inline est le par défaut Nexus, même lorsque la propriété n'est pas explicitement définie.
        # content_disposition: inline
      - name: jboss
        remote_url: 'https://repository.jboss.org/nexus/content/groups/public-jboss/'
        # cleanup_policies:
        #    - mvn_cleanup
        # maximum_component_age: -1
        # maximum_metadata_age: 1440
        # negative_cache_enabled: true
        # negative_cache_ttl: 1440
        # La disposition de contenu n'est prise en charge que pour les proxys bruts et maven2 et peut être définie sur attachment ou inline. Inline est le par défaut Nexus, même lorsque la propriété n'est pas explicitement définie.
        # content_disposition: inline
    # exemple avec un login/mot de passe :
    # - name: secret-remote-repo
    #   remote_url: 'https://company.com/repo/secure/private/go/away'
    #   remote_username: 'username'
    #   remote_password: 'secret'
    #   # maximum_component_age: -1
    #   # maximum_metadata_age: 1440
    #   # negative_cache_enabled: true
    #   # negative_cache_ttl: 1440
    # La disposition de contenu n'est que prise en charge pour les proxys bruts et maven2 et peut être définie sur attachment ou inline, inline étant le par défaut, même lorsque la propriété n'est pas explicitement définie.
    # Pour définir des paramètres de requête HTTP :
    #   # enable_circular_redirects: true
    #   # enable_cookies: true

Configuration des dépôts Maven proxy.

    nexus_repos_maven_hosted:
      - name: private-release
        version_policy: release
        write_policy: allow_once  # un des "allow", "allow_once" ou "deny"
        # cleanup_policies:
        #    - mvn_cleanup

Configuration des dépôts Maven hébergés. La configuration du cache négatif est optionnelle et utilisera les valeurs ci-dessus par défaut si omise.

    nexus_repos_maven_group:
      - name: public
        member_repos:
          - central
          - jboss

Configuration des dépôts Maven groupes.

Tous les trois types de dépôts sont combinés avec les valeurs par défaut suivantes :

    _nexus_repos_maven_defaults:
      blob_store: default # Remarque : ne peut pas être mis à jour une fois le dépôt créé
      strict_content_validation: true
      version_policy: release # release, snapshot ou mixed
      layout_policy: strict # strict ou permissive
      write_policy: allow_once # un des "allow", "allow_once" ou "deny"
      maximum_component_age: -1  # Défault de l'interface Nexus. Pour les proxys uniquement
      maximum_metadata_age: 1440  # Défault de l'interface Nexus. Pour les proxys uniquement
      negative_cache_enabled: true # Dédefault de l'interface Nexus. Pour les proxys uniquement
      negative_cache_ttl: 1440 # Dédefault de l'interface Nexus. Pour les proxys uniquement

Dépôts Docker

nexus_repos_docker_group:
  - name: some-docker-group
    sub_domain: hub-proxy # Lorsqu'il est défini, cela exposera une URL de sous-domaine par exemple : https://hub-proxy.votre-instance-nexus.com
    writable_member_repo: docker-hosted-repo
    blob_store: docker-blob
    v1_enabled: False
    member_repos:
      - docker-hosted-repo

nexus_repos_docker_hosted:
  - name: some-docker-repo
    blob_store: docker-blob
    v1_enabled: false
    write_policy: allow_once # Valeurs : "allow", "allow_once" ou "deny"
    # Lorsqu'il est défini, cela ignorera la politique d'écriture définie et permettra de redéployer des images de conteneur uniquement avec le tag 'latest'.
    allow_redeploy_latest: true

Types de dépôts Maven, Pypi, Docker, Raw, Rubygems, Bower, NPM, Git-LFS, yum, apt, helm, r, p2, conda et go : voir defaults/main.yml pour ces options. Pour des raisons historiques et pour maintenir la compatibilité arrière, maven est configuré par défaut.

      nexus_config_maven: true
      nexus_config_pypi: false
      nexus_config_docker: false
      nexus_config_raw: false
      nexus_config_rubygems: false
      nexus_config_bower: false
      nexus_config_npm: false
      nexus_config_gitlfs: false
      nexus_config_yum: false
      nexus_config_apt: false
      nexus_config_helm: false
      nexus_config_r: false
      nexus_config_p2: false
      nexus_config_conda: false
      nexus_config_go: false

Tous sont faux à moins que vous ne les remplaciez par un playbook / group_var / cli, tous utilisent le même mécanisme que maven.

Veuillez noter que vous devrez peut-être activer certains domaines de sécurité si vous souhaitez utiliser d'autres types de dépôts que Maven. Ceux-ci sont par défaut sur faux.

nexus_nuget_api_key_realm: false
nexus_npm_bearer_token_realm: false
nexus_docker_bearer_token_realm: false  # requis pour l'accès Docker anonyme

Le domaine d'utilisateur distant peut également être activé avec

nexus_rut_auth_realm: true

et l'en-tête peut être configuré en définissant

nexus_rut_auth_header: "CUSTOM_HEADER"

Tâches programmées

Voici quelques exemples rapides et instructions pour configurer des tâches programmées. Pour plus d'informations sur les types de tâches disponibles et les types de calendrier, veuillez vous référer à la section spécifique dans le wiki du dépôt.

    nexus_scheduled_tasks: []
    #  #  Exemple de tâche pour compacter le blobstore :
    #  - name: compact-docker-blobstore
    #    cron: '0 0 22 * * ?'
    #    typeId: blobstore.compact
    #    task_alert_email: [email protected]  # optionnel
    #    taskProperties:
    #      blobstoreName: {{ nexus_blob_names.docker.blob }} # tous les attributs de la tâche sont stockés comme des chaînes en interne par nexus
    #  #  Exemple de tâche pour purger les snapshots maven
    #  - name: Purge-maven-snapshots
    #    cron: '0 50 23 * * ?'
    #    typeId: repository.maven.remove-snapshots
    #    task_alert_email: [email protected]  # optionnel
    #    taskProperties:
    #      repositoryName: "*"  # * pour tous les dépôts. Changez pour un nom de dépôt si vous ne voulez qu'un dépôt spécifique
    #      minimumRetained: "2"
    #      snapshotRetentionDays: "2"
    #      gracePeriodInDays: "2"
    #    booleanTaskProperties:
    #      removeIfReleased: true
    #  #  Exemple de tâche pour purger les manifestes et images Docker inutilisées
    #  - name: Purge unused docker manifests and images
    #    cron: '0 55 23 * * ?'
    #    typeId: "repository.docker.gc"
    #    task_alert_email: [email protected]  # optionnel
    #    taskProperties:
    #      repositoryName: "*"  # * pour tous les dépôts. Changez pour un nom de dépôt si vous ne voulez qu'un dépôt spécifique
    #  #  Exemple de tâche pour purger les téléchargements Docker incomplets
    #  - name: Purge incomplete docker uploads
    #    cron: '0 0 0 * * ?'
    #    typeId: "repository.docker.upload-purge"
    #    task_alert_email: [email protected]  # optionnel
    #    taskProperties:
    #      age: "24"

Tâches programmées à configurer. typeId et taskProperties/booleanTaskProperties spécifiques à la tâche peuvent être devinés soit :

  • à partir de la hiérarchie de types Java de org.sonatype.nexus.scheduling.TaskDescriptorSupport
  • en inspectant le formulaire HTML de création de tâche dans votre navigateur
  • en observant les requêtes AJAX du navigateur lors de la configuration manuelle d'une tâche.

Les propriétés de tâche doivent être déclarées dans le bon bloc yaml en fonction de leur type :

  • taskProperties pour toutes les propriétés de type chaîne (c'est-à-dire, noms de dépôts, noms de blobstore, périodes de temps...).
  • booleanTaskProperties pour toutes les propriétés booléennes (c'est-à-dire principalement des cases à cocher dans l'interface de création de tâche Nexus).

Sauvegardes

      nexus_backup_configure: false
      nexus_backup_schedule_type: cron
      nexus_backup_cron: '0 0 21 * * ?'  # Voir la définition des expressions cron dans l'interface de création de tâches de Nexus
      # nexus_backup_start_date_time: "aaaa-MM-jj'T'HH:mm:ss"
      # nexus_backup_weekly_days: ['LUN', 'MAR', 'MER', 'JEU', 'VEN', 'SAM']
      # nexus_backup_monthly_days: {{ range(1,32) | list + [999] }}
      nexus_backup_dir: '/var/nexus-backup'
      nexus_backup_dir_create: true
      nexus_restore_log: '{{ nexus_backup_dir }}/nexus-restore.log'
      nexus_backup_rotate: false
      nexus_backup_rotate_first: false
      nexus_backup_keep_rotations: 4  # Conserver 4 rotations de sauvegarde par défaut (actuelle + dernières 3)

La sauvegarde ne sera pas configurée à moins que vous ne définissiez nexus_backup_configure: true. Dans ce cas, une tâche de script sera configurée dans Nexus.

Le calendrier de la tâche sera défini par défaut comme cron et s'exécutera chaque jour à 21h00. Vous pouvez définir n'importe quel calendrier que vous souhaitez en ajustant les variables nexus_backup_schedule_type, nexus_backup_cron, nexus_backup_start_date_time, nexus_backup_weekly_days et nexus_backup_monthly_days. Pour comprendre leur utilisation en fonction du type de calendrier que vous choisissez, veuillez consulter Tâches programmées.

Voir le modèle Groovy pour cette tâche pour plus de détails. Cette tâche programmée est indépendante des autres nexus_scheduled_tasks que vous déclarez dans votre playbook.

Si vous souhaitez faire des rotations de sauvegardes, définissez nexus_backup_rotate: true et ajustez le nombre de rotations que vous souhaitez conserver avec nexus_backup_keep_rotations (par défaut 4).

Lorsque vous utilisez la rotation, si vous souhaitez économiser de l'espace disque supplémentaire pendant le processus de sauvegarde, vous pouvez définir nexus_backup_rotate_first: true. Cela configurera une pré-rotation plutôt que la rotation postérieure par défaut. Veuillez noter qu'ainsi, l'ancienne sauvegarde est/les anciennes sauvegardes sont supprimées avant que la sauvegarde actuelle ne soit effectuée avec succès.

Si vous souhaitez sauvegarder dans un répertoire monté (comme s3fs), vous pouvez définir nexus_backup_dir_create sur false.

Procédure de restauration

Exécutez votre playbook avec le paramètre -e nexus_restore_point=<AAAA-MM-JJ-HH-mm-ss> (par exemple 2017-12-17-21-00-00 pour le 17 décembre 2017 à 21h00m00s).

Limitations possibles

Les copies de blobstore sont effectuées directement par Nexus via la tâche programmée du script. Cela n'a été testé que sur des blobstores assez petits (moins de 50 Go) et doit être utilisé avec prudence et testé attentivement sur des installations plus grandes avant de passer en production. En tout cas, vous êtes libre de mettre en œuvre votre propre scénario de sauvegarde en dehors de ce rôle.

Variables spéciales de maintenance/debug

Celles-ci ne sont pas présentes dans defaults/main.yml et sont destinées à être utilisées uniquement sur la ligne de commande à des fins de maintenance/debug.

Purge du nexus

Avertissement : ceci va complètement effacer les données actuelles. Assurez-vous de sauvegarder au préalable si nécessaire.

Utilisez la variable nexus_purge si vous avez besoin de repartir de zéro et de réinstaller une instance de nexus vide.

ansible-playbook -i votre/inventory.ini votre_playbook_nexus.yml -e nexus_purge=true

Forcer l'enregistrement des scripts Groovy

Celui-ci est sûr et prolongera uniquement l'exécution du playbook si cela n'était pas nécessaire.

Pour des raisons de performance, nous utilisons une petite astuce avec plusieurs rsync pour détecter quels scripts de maintenance Groovy doivent être enregistrés dans Nexus. À certaines occasions (par exemple, mauvais mot de passe admin, récupération d'une sauvegarde d'une instance Nexus précédente avec des scripts non enregistrés...), cela peut entraîner une situation où le rôle échoue en tentant d'exécuter les scripts Groovy nécessaires.

Le symptôme : vous obtenez des erreurs HTTP 404 lorsque le rôle essaie d'exécuter des scripts comme dans l'exemple suivant (utilisez l'option -v pour le playbook Ansible) :

fatal: [nexus3-oss]: FAILED! => {"changed": false, "connection": "close", "content": "", "date": "Tue, 11 Sep 2018 07:57:44 GMT", "msg": "Le code d'état était 404 et non [200, 204]: HTTP Error 404: Not Found", "redirected": false, "server": "Nexus/3.13.0-01 (OSS)", "status": 404, "url": "http://localhost:8081/service/rest/v1/script/update_admin_password/run", "x_content_type_options": "nosniff", "x_siesta_faultid": "914acef2-f644-4bd6-9a7d-ce19255ea3dd"}

Dans de tels cas, vous pouvez forcer l'enregistrement (ou la ré-inscription) des scripts Groovy avec la variable nexus_force_groovy_scripts_registration :

ansible-playbook -i votre/inventory.ini votre_playbook.yml -e nexus_force_groovy_scripts_registration=true

Changer le mot de passe admin après la première installation

    nexus_default_admin_password: 'admin123'

Cela ne devrait pas être modifié dans votre playbook. Cette variable est remplie avec le mot de passe admin par défaut de Nexus à la première installation et garantit que nous pouvons changer le mot de passe admin en nexus_admin_password.

Si vous souhaitez changer votre mot de passe admin après la première installation, vous pouvez temporairement changer cela pour votre ancien mot de passe depuis la ligne de commande. Après avoir modifié nexus_admin_password dans votre playbook, vous pouvez exécuter :

ansible-playbook -i votre/inventory.ini votre_playbook.yml -e nexus_default_admin_password=ancienMotDePasse

Mettre à niveau Nexus vers la dernière version

    nexus_upgrade: true

Cette variable n'a aucun effet si nexus_version est fixée dans vos vars.

À moins que vous ne définissiez cette variable, le rôle conservera la version Nexus installée actuelle lorsqu'il sera exécuté contre une hôte déjà provisionnée. Passer cette variable supplémentaire déclenchera la détection automatique de la dernière version de Nexus et la mise à niveau si une nouvelle version est disponible.

Définir cette variable comme partie de votre playbook rompt l'idempotence. (c'est-à-dire que votre playbook apportera des modifications à votre système si une nouvelle version est disponible bien que aucun paramètre n'ait changé).

Nous vous conseillons fortement d'utiliser cette variable uniquement comme variable supplémentaire pour l'appel ansible-playbook :

ansible-playbook -i votre/inventory.ini votre_playbook.yml -e nexus_upgrade=true
Corriger l'échec de la mise à niveau en attendant le port Nexus

Si vous avez un grand dépôt Nexus, vous pouvez parfois voir un message d'erreur lors de la mise à niveau :

RUNNING HANDLER [nexus3-oss : wait-for-nexus-port] *************
fatal: [nexushost]: FAILED! => {"changed": false, "elapsed": 300, "msg": "Timeout when waiting for 127.0.0.1:8081"}

Ceci est probablement dû au fait que le processus de mise à niveau de Nexus (c'est-à-dire la migration interne d'OrientDB) prend plus de temps que le délai par défaut de 300 secondes. Vous pouvez surmonter cette situation en définissant un délai d'attente personnalisé en secondes et/ou un nombre de tentatives pour la tâche de gestionnaire.

ansible-playbook -i votre/inventory.ini votre_playbook.yml \
-e nexus_upgrade=true \
-e nexus_wait_for_port_timeout=600 \
-e nexus_wait_for_port_retries=2

Ignorer les tâches de provisionnement

    nexus_run_provisionning: false

Cette variable est non définie par défaut et sera par défaut sur true. La définir sur false fera que le rôle ignorera toutes les tâches de provisionnement et ne créera donc pas de mise à jour :

  • configurations LDAP
  • sélecteurs de contenu
  • privilèges
  • rôles
  • utilisateurs (sauf vérification/mise à jour du mot de passe admin)
  • blobstores
  • dépôts
  • tâches (la sauvegarde sera toujours configurée si activée).

Cela peut faire gagner du temps si vous avez beaucoup de dépôts/utilisateurs/rôles configurés et que vous souhaitez jouer le rôle pour simplement vérifier que Nexus est correctement installé, ou restaurer une sauvegarde, ou mettre à niveau la version de Nexus.

Nous vous conseillons fortement d'utiliser cette variable uniquement comme variable supplémentaire pour l'appel ansible-playbook :

ansible-playbook -i votre/inventory.ini votre_playbook.yml -e nexus_run_provisionning=false

Forcer la vérification récursive des droits des répertoires de blobstores

Introduit dans la version 2.4.9

    nexus_blobstores_recurse_owner: true

Dans les versions antérieures à 2.4.9, la tâche pour créer les répertoires de blobstores effectuait une vérification récursive des droits de tous les fichiers. Cela ne posait pas de problèmes lors de la création (où le répertoire est vide) ou avec des installations de petits blobstores, mais pouvait entraîner des retards extrêmement longs pour les grands blobstores avec beaucoup de fichiers.

La vérification récursive des droits a été désactivée par défaut pour éviter ce délai supplémentaire. Si pour une raison quelconque vous devez vous assurer que tous les fichiers dans les répertoires de blobstores sont possédés par l'utilisateur Nexus, vous pouvez forcer la vérification :

ansible-playbook -i votre/inventory.ini votre_playbook.yml -e nexus_blobstores_recurse_owner=true

Dépendances

Les exigences Java et httpd / peuvent être satisfaites avec les rôles Galaxy suivants :

N'hésitez pas à les utiliser ou à mettre en œuvre votre propre scénario d'installation à votre convenance.

Exemple de Playbook

---
- name: Nexus
  hosts: nexus
  become: yes

  vars:
    nexus_timezone: 'Canada/Eastern'
    nexus_admin_password: "{{ vault_nexus_admin_password }}"
    nexus_public_hostname: 'nexus.vm'
    httpd_setup_enable: true
    httpd_ssl_certificate_file: "{{ vault_httpd_ssl_certificate_file }}"
    httpd_ssl_certificate_key_file: "{{ vault_httpd_ssl_certificate_key_file }}"
    ldap_connections:
      - ldap_name: 'Company LDAP'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'ldap.company.com'
        ldap_port: 636
        ldap_search_base: 'dc=company,dc=net'
        ldap_user_base_dn: 'ou=users'
        ldap_user_object_class: 'inetOrgPerson'
        ldap_user_id_attribute: 'uid'
        ldap_user_real_name_attribute: 'cn'
        ldap_user_email_attribute: 'mail'
        ldap_group_base_dn: 'ou=groups'
        ldap_group_object_class: 'posixGroup'
        ldap_group_id_attribute: 'cn'
        ldap_group_member_attribute: 'memberUid'
        ldap_group_member_format: '${username}'
    nexus_privileges:
      - name: all-repos-read
        description: 'Accès en lecture et navigation à tous les dépôts'
        repository: '*'
        actions:
          - read
          - browse
      - name: company-project-deploy
        description: 'Déploiements vers le projet d'entreprise'
        repository: company-project
        actions:
          - add
          - edit
    nexus_roles:
      - id: Developpers # se mappe au groupe LDAP
        name: developers
        description: Tous les développeurs
        privileges:
          - nx-search-read
          - all-repos-read
          - company-project-deploy
        roles: []
    nexus_local_users:
      - username: jenkins # utilisé comme clé pour mettre à jour
        first_name: Jenkins
        last_name: CI
        email: [email protected]
        password: "s3cr3t"
        roles:
          - Developpers # id de rôle ici
    nexus_blobstores:
      - name: company-artifacts
        path: /var/nexus/blobs/company-artifacts
    nexus_scheduled_tasks:
      - name: compact-blobstore
        cron: '0 0 22 * * ?'
        typeId: blobstore.compact
        taskProperties:
          blobstoreName: 'company-artifacts'
    nexus_repos_maven_proxy:
      - name: central
        remote_url: 'https://repo1.maven.org/maven2/'
        layout_policy: permissive
      - name: alfresco
        remote_url: 'https://artifacts.alfresco.com/nexus/content/groups/private/'
        remote_username: 'secret-username'
        remote_password: "{{ vault_alfresco_private_password }}"
      - name: jboss
        remote_url: 'https://repository.jboss.org/nexus/content/groups/public-jboss/'
      - name: vaadin-addons
        remote_url: 'https://maven.vaadin.com/vaadin-addons/'
      - name: jaspersoft
        remote_url: 'https://jaspersoft.artifactoryonline.com/jaspersoft/jaspersoft-repo/'
        version_policy: mixed
    nexus_repos_maven_hosted:
      - name: company-project
        version_policy: mixed
        write_policy: allow
        blob_store: company-artifacts
    nexus_repos_maven_group:
      - name: public
        member_repos:
          - central
          - jboss
          - vaadin-addons
          - jaspersoft
    nexus_repos_docker_group:
       - name: some-docker-group
         sub_domain: hub-proxy
         writable_member_repo: docker-hosted-repo
         blob_store: docker-blob
         v1_enabled: False
         member_repos:
           - docker-hosted-repo
    nexus_repos_npm_proxy:
      - name: npm-proxy-name
        blob_store: company-artifacts
        blocked: false # Par défaut c'est faux
        auto_block: true # Par défaut c'est vrai
        connection_timeout: 200 # Par défaut non défini
        connection_retries: 5 # Par défaut non défini
        user_agent_suffix: custom-agent # Par défaut non défini
        remote_url: https://some-private-registry.dev/
        remote_username: 'secret-username'
        remote_password: "{{ vault_alfresco_secret_password }}"
        # Vous pouvez également utiliser un jeton préemptif en définissant la propriété bearerToken
        # bearerToken: "{{ vault_alfresco_secret_bearertoken }}"

  roles:
    - { role: geerlingguy.java, vars: Voir la doc de rôle pour votre distribution/version }
    # Seulement pour Debian/Ubuntu
    # - { role: geerlingguy.apache, apache_create_vhosts: no, apache_mods_enabled: ["proxy.load", "proxy_http.load", "headers.load", "ssl.load", "rewrite.load"], apache_remove_default_vhost: true, tags: ["geerlingguy.apache"] }
    # Seulement pour RedHat/CentOS
    - { role: geerlingguy.apache, apache_create_vhosts: no, apache_remove_default_vhost: true, tags: ["geerlingguy.apache"] }
    - { role: ansible-thoteam.nexus3-oss, tags: ['ansible-thoteam.nexus3-oss'] }

Développement, Contribution et Tests

Contributions

Toutes les contributions à ce rôle sont les bienvenues, que ce soit pour des correctifs, de nouvelles fonctionnalités ou de la documentation.

Si vous souhaitez contribuer :

  • Forkez le dépôt sous votre propre nom/organisation via l'interface GitHub.
  • Créez une branche dans votre propre dépôt avec un nom significatif. Nous suggérons la convention de nommage suivante :
    • feat/<someFeature> pour les fonctionnalités
    • fix/<someBugFix> pour les corrections de bogues
    • docfix/<someDocFix> pour les corrections modifiant uniquement la documentation
  • Si vous commencez un changement de fonctionnalité important, ouvrez une demande de tirage tôt en décrivant ce que vous voulez faire afin que nous puissions en discuter si nécessaire. Cela vous évitera de faire beaucoup de travail sur beaucoup de code pour des changements que nous ne pourrons finalement pas fusionner.
  • S'il y a des erreurs de construction sur votre demande de tirage, jetez un coup d'œil au journal de Travis et corrigez les erreurs pertinentes.

De plus, si vous avez le temps à consacrer à la revue de code, à la fusion pour les versions, etc., envoyez un e-mail à contact@thoteam.com pour entrer en contact.

Test

Ce rôle inclut des tests et une intégration CI via Travis. Pour le moment, nous testons :

  • syntaxe des scripts Groovy
  • syntaxe YAML et normes de codage (yamllint)
  • bonnes pratiques Ansible (ansible lint)
  • un ensemble de déploiements de base sur 2 plateformes Linux différentes
    • Rockylinux 9 (comme un parent proche des produits RHEL puisque CentOS est obsolète)
    • Debian 12 Bookworm.

D'autres tests sont disponibles pour les plateformes plus anciennes/différentes mais ne sont pas exécutés sur CI pour des raisons de performance :

  • Rockylinux 8
  • Debian 11 bullseye
  • Ubuntu 20.04 Focal
  • Ubuntu 22.04 Jammy

Syntaxe Groovy

Ce rôle contient un ensemble de fichiers Groovy utilisés pour provisionner Nexus.

Si vous soumettez des modifications aux fichiers Groovy, veuillez exécuter la vérification de syntaxe Groovy localement avant de pousser vos modifications :

./tests/test_groovySyntax.sh

Cela garantira que vous poussez des fichiers Groovy avec la bonne syntaxe limitant le nombre d'erreurs vérifiées sur Travis.

Vous aurez besoin du paquet Groovy installé localement pour exécuter ce test.

Scénarios par défaut de Molecule

Le rôle est testé sur Travis avec molecule. Vous pouvez exécuter ces tests localement. La meilleure façon d'y parvenir est grâce à un environnement virtuel Python. Vous pouvez trouver plus de détails dans requirements.txt.

# Remarque : le chemin suivant devrait être en dehors du répertoire de travail
virtualenv /path/to/some/pyenv
. /path/to/some/pyenv/bin/activate
pip install -r requirements.txt
molecule [create|converge|destroy|test] -s <nom du scénario>
deactivate

Veuillez consulter la documentation de Molecule (un bon début est molecule --help) pour un usage ultérieur.

Les scénarios actuellement proposés font référence aux plateformes testées (voir le répertoire molecule/). Si vous lancez un scénario et laissez le conteneur en cours d'exécution (c'est-à-dire en utilisant converge pour un simple déploiement), vous pouvez accéder à l'instance en cours d'exécution via votre navigateur à https://localhost:. Voir le fichier molecule/<scénario>/molecule.yml pour plus de détails. À titre de commodité, voici la correspondance entre les scénarios et les ports configurés :

Pour accélérer les tests, Molecule utilise des images Docker pré-construites.

Veuillez noter que ces images sont construites et poussées sur une base de meilleures efforts chaque fois que nécessaire pour les changements dans ce dépôt.

Licence

GNU GPLv3.

Informations sur l'auteur

Voir : https://github.com/ansible-ThoTeam

[Lionel Lecha] : https://www.linkedin.com/in/lionellecha/

À propos du projet

Nexus Repository Manager 3.x (Sonatype)

role nexus nexus3 java maven npm nuget yum docker pypi web
Installer
ansible-galaxy install ansible-ThoTeam.nexus3-oss
GitHub référentiel
296 étoiles
208 forks
33 problèmes ouverts
Licence
gpl-3.0
Téléchargements
1.1M
Propriétaire
Ansible collections and roles by ThoTeam
Ansible public collections and roles by ThoTeam. Contributions welcome