ansible-ThoTeam.nexus3-oss

Überblick Versionen Einblicke

Ansible Rolle: Nexus 3 OSS

Diese Rolle installiert und konfiguriert den Nexus Repository Manager OSS Version 3.x.

Alle Konfigurationen können durch erneutes Ausführen der Rolle aktualisiert werden, außer für die Blobstores bezogenen Einstellungen, die in Nexus unveränderlich sind.

travis-ci.com Logo Die CI dieser Rolle verwendet stolz die OSS-Guthaben, die von https://travis.com zugewiesen wurden.

Inhaltsverzeichnis

Hinweis: TOC-Links funktionieren nicht richtig, wenn Sie sie von der Ansible Galaxy-Website aus anzeigen. Auf GitHub ansehen

(Erstellt mit gh-md-toc)

Geschichte / Credits

Diese Rolle ist ein Fork von ansible-nexus3-oss von @savoirfairelinux, nachdem sie das Ende der Wartung angekündigt hatten. Sie können sich die folgenden Tickets im ursprünglichen Repository ansehen:

Wir möchten den ursprünglichen Autoren für ihre geleistete Arbeit danken.

In Memoriam Lionel Lecha (Hinweis des Hauptautors):

Bild von Lionel Lecha Diese Arbeit hätte die Gemeinschaft niemals als Open-Source-Projekt erreicht, ohne das bedingungslose Vertrauen von Lionel Lecha, Direktor von SMAP APPUI @La Poste, als ich 2018 als externen Dienstleister mit der Automatisierung der Bereitstellung von Nexus für seine Einheit begann. Lionel starb viel zu früh am 17. Februar 2023 im Alter von 60 Jahren. Danke für deine immer gleichbleibende gute Laune und dein Vertrauen.

Voraussetzungen

  • Eine recht aktuelle Version von Ansible. Wir verfolgen die Ansible-Versionen während der Wartung/Entwicklung und nutzen neue Funktionen bei Bedarf (und aktualisieren die meta/main.yml für die Mindestversion)
  • Kompatibles Betriebssystem. Diese Rolle wird über Molecule auf Travis CI für CentOS 8, Ubuntu Bionic (18.04) und Debian Buster getestet. Andere Molecule-Szenarien können lokal für CentOS 7, Ubuntu Xenial (16.04) und Debian Stretch gespielt werden
  • Rsync muss auf der Zielmaschine installiert sein (es ist nicht erforderlich auf dem Host, der Ansible ausführt, wenn diese unterschiedlich sind)
  • Die jmespath-Bibliothek muss auf dem Host installiert sein, der das Playbook ausführt (benötigt für den Filter json_query). Siehe requirements.txt
  • Java 8 (obligatorisch)
    • Oracle hat das EOL von Java 8 angekündigt. Sonatype empfiehlt jetzt openjdk8
    • Für weitere Informationen siehe Nexus3-Systemanforderungen
  • Apache HTTPD (optional)
    • Wird verwendet, um einen SSL-Reverse-Proxy einzurichten
    • Die folgenden Module müssen in Ihrer Konfiguration aktiviert sein: mod_ssl, mod_rewrite, mod_proxy, mod_proxy_http, mod_headers.

(Siehe Abschnitt Abhängigkeiten weiter unten für zugeordnete Rollen auf Galaxy)

Rollenvariablen

Ansible-Variablen sowie die Standardwerte (siehe default/main.yml):

Allgemeine Variablen

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

Die Rolle installiert standardmäßig die neueste verfügbare Version von Nexus. Sie können die Version festlegen, indem Sie die Variable nexus_version einstellen. Verfügbare Versionen finden Sie unter https://www.sonatype.com/download-oss-sonatype. Wenn Sie einen langsamen Pull über einen Proxy haben, können Wiederholungsversuche nützlich sein, um Zeitüberschreitungen zu verhindern. Sie können die Wiederholungen zum Herunterladen hinzufügen, indem Sie diese Variablen einstellen:

    nexus_download_retries: 3 # standardmäßig 0
    nexus_download_delay: 15

Wenn Sie die Version festlegen und sie auf eine andere ändern, wird die Rolle versuchen, Ihre Installation zu aktualisieren. Stellen Sie sicher, dass Sie zu einer späteren Version in der Versionshistorie wechseln. Ein Downgrade schlägt fehl (es sei denn, Sie installieren von Grund auf neu mit der nexus_purge-Sondervar).

Wenn Sie die Version nicht festlegen und die Rolle auf einer vorhandenen Installation ausführen, wird die derzeit installierte Version verwendet (Erkennung des Ziels von {{ nexus_installation_dir}}/nexus-latest). Wenn Sie Nexus aktualisieren möchten, müssen Sie die Sondervar nexus_upgrade=true in der Ansible-Playbook-Befehlszeile übergeben. Siehe Upgrade Nexus auf die neueste Version.

Wenn Sie eine ältere Version von Nexus als die neueste verwenden, sollten Sie sicherstellen, dass Sie keine Funktionen verwenden, die in der installierten Version nicht verfügbar sind (z. B. YUM-gehostete Repositories für Nexus < 3.8.0, GIT LFS-Repo für Nexus < 3.3.0 usw.).

nexus_timezone ist der Name einer Java-Zeitzone und kann in Kombination mit den Cron-Ausdrücken der nexus_scheduled_tasks unten nützlich sein.

Sie können die Download-Website für die Pakete ändern, indem Sie nexus_download_url anpassen (z. B. in geschlossenen Umgebungen, Proxy/Cache in Ihrem Netzwerk ...). In diesem Fall schlägt die automatische Erkennung der neuesten Version höchstwahrscheinlich fehl, und Sie müssen die Version zum Herunterladen festlegen. Wenn Sie dennoch die automatische Erkennung der neuesten Version nutzen möchten, muss ein Aufruf an <your_custom_location>/latest-unix.tar.gz einen HTTP 302-Redirect auf die neueste verfügbare Version in Ihrem Cache/Proxy zurückgeben. Wenn Ihr Download-Standort HTTPS mit einem selbstsignierten Zertifikat verwendet (oder von einer privaten PKI stammt) und Sie Probleme haben, es zu validieren (d. h. Downloadfehler in der Rolle) und Ihnen das Ziel vollständig vertraut, können Sie nexus_download_ssl_verify: false setzen.

nexus_version_running ist eine intern verwendete Variable. Deshalb sollte sie niemals direkt gesetzt werden. Sie wird nur existieren, wenn Nexus derzeit auf dem Host installiert ist und registriert die aktuelle Version vor dem Ausführen der Rolle. Sie kann später in Ihrem Playbook nach Bedarf verwendet werden (z. B. für eine Upgrade-Benachrichtigungs-E-Mail).

Download-Verzeichnis für Nexus-Paket

    nexus_download_dir: '/tmp'

Verzeichnis auf dem Ziel, in dem das Nexus-Paket heruntergeladen wird.

Wichtiger Hinweis: Wenn Sie die Rolle regelmäßig ausführen möchten, um Ihre Nexus-Installation zu warten / bereitzustellen, sollten Sie sicherstellen, dass die heruntergeladenen Dateien zwischen den Ausführungen bestehen bleiben. Speziell auf RHEL/CentOS sollten Sie dieses Verzeichnis an einem Ort ändern, der nicht automatisch bereinigt wird. Wenn die Paketdatei nicht bestehen bleibt, wird sie erneut heruntergeladen, was möglicherweise zu einem unnötigen Neustart von Nexus führt.

Lokales temporäres Verzeichnis auf dem Controller

nexus_local_tmp_dir: /tmp

Dieses Verzeichnis wird verwendet, um ein lokales Archiv des Groovy-Skripts zu erstellen, bevor sie an das Ziel gesendet werden. Auf einem gemeinsam genutzten Ansible-Controller sollten Sie diesen Pfad ändern, um einen eigenen Speicherort anzugeben (z. B. /home/<user>/tmp). Wichtig: Dieses Verzeichnis muss existieren.

Nexus-Port, Kontextpfad und hörende IP

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

Hörender Port/IP und Kontextpfad des Java-Nexus-Prozesses.

  • Die hörende IP/Schnittstelle (d. h. nexus_application_host) hängt standardmäßig von der Einstellung httpd_setup_enable ab. Nexus hört nur auf localhost (127.0.0.1), wenn der Reverse-Proxy aktiviert ist, oder auf alle konfigurierten IPs (0.0.0.0), wenn nicht. Sie können diese Einstellung nach Ihrem tatsächlichen Bedarf ändern (d. h. den Proxy nicht installieren und dennoch nur an 127.0.0.1 binden, wenn Sie Ihren eigenen Proxy installieren)
  • nexus_default_context_path muss den abschließenden Schrägstrich behalten, wenn gesetzt, z. B.: nexus_default_context_path: '/nexus/'.

Nexus OS-Benutzer und Gruppe

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

Benutzer und Gruppe, die die Nexus-Dateien besitzen und den Dienst ausführen, werden von der Rolle erstellt, wenn sie nicht vorhanden sind. Wenn UID und GID definiert werden, werden sie bei der Erstellung verwendet.

    nexus_os_user_home_dir: '/home/nexus'

Erlaubt, das Standard-Home-Verzeichnis des Nexus-Benutzers zu ändern.

Nexus Instanzverzeichnisse

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

Nexus-Verzeichnisse.

  • nexus_installation_dir enthält die installierten ausführbaren Dateien.
  • nexus_data_dir enthält alle Konfigurationen, Repositories und hochgeladenen Artefakte. Benutzerdefinierte Blobstore-Pfade außerhalb von nexus_data_dir können konfiguriert werden, siehe nexus_blobstores unten.
  • nexus_tmp_dir enthält alle temporären Dateien. Der Standardpfad für Red Hat wurde aus /tmp verschoben, um potenzielle Probleme mit automatischen Bereinigungsverfahren zu umgehen. Siehe #168.

Nexus JVM-Einstellungen

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

Dies sind die Standards für Nexus. Bitte ändern Sie diese Werte nicht, es sei denn, Sie haben das Speicherabschnitt der Nexus-Systemanforderungen gelesen und wissen, was Sie tun.

Als zweite Warnung ein Auszug aus dem obigen Dokument:

Es wird nicht empfohlen, den JVM-Heap-Speicher größer als die empfohlenen Werte zu erhöhen, um die Leistung zu verbessern. Dies kann tatsächlich den gegenteiligen Effekt haben und dazu führen, dass das Betriebssystem unnötig belastet wird.

    nexus_custom_jvm_settings: []

Zusätzliche Einstellungen, die an die JVM übergeben werden. Diese sind standardmäßig leer und sollten keine Optionen enthalten, die mit dem Speicher über den genannten hinausgehen (d. h. alles, was mit Xms, Xmx oder XX:MaxDirectMemorySize= beginnt). Jede Option sollte als Element der Liste ohne den führenden Bindestrich (-) gesetzt werden.

Hier ist ein Beispiel, um den Garbage Collector auf G1 zu ändern und GC-Protokolle mit Rotation festzulegen.

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

Plugin-Installation

nexus_plugin_urls: []

Liste von URLs, die auf Plugins verweisen, die für Ihre Nexus-Version erstellt wurden. Nur *.kar-Pakete können auf diese Weise installiert werden.

Onboarding-Assistent

nexus_onboarding_wizard: false

Steuert, ob der Onboarding-Assistent von Nexus beim ersten Anmelden des Administrators ausgeführt wird.

Admin-Passwort

    nexus_admin_password: 'changeme'

Das Passwort des 'admin'-Kontos, das eingerichtet werden soll. Dies funktioniert standardmäßig nur bei der Erstinstallation. Bitte siehe Ändern des Admin-Passworts nach der ersten Installation, wenn Sie es später mit der Rolle ändern möchten.

Es wird dringend empfohlen, Ihr Passwort nicht im Klartext in Ihrem Playbook zu belassen und die Ansible-Vault-Verschlüsselung (entweder inline oder in einer separaten Datei, die beispielsweise mit include_vars geladen wird) zu verwenden.

Standardanonymer Zugriff

    nexus_anonymous_access: false

Erlaubt anonymen Zugriff auf Nexus.

Öffentlicher Hostname

    nexus_public_hostname: 'nexus.vm'
    nexus_public_scheme: https

Der vollqualifizierte Domainname und das Schema, unter dem die Nexus-Instanz für ihre Clients zugänglich ist.

API-Zugriff für diese Rolle

    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

Diese Variablen steuern, wie die Rolle mit der Nexus-API für die Bereitstellung verbindet. Für erweiterte Verwendung gedacht. Sie möchten diese Standardeinstellungen höchstwahrscheinlich nicht ändern.

Hinweis: Der nexus_api_timeout wurde in v2.4.19 hinzugefügt und überschreibt das Standard-uri-Modul-Timeout von 30s für alle Aufrufe der API.

Branding-Möglichkeiten

    nexus_branding_header: ""
    nexus_branding_footer: "Letzte Bereitstellung {{ ansible_date_time.iso8601 }}"

Header- und Fußzeilenbranding, die HTML enthalten können.

Audit-Funktionalität

    nexus_audit_enabled: false

Die Audit-Funktion von Nexus ist standardmäßig deaktiviert. Sie können sie aktivieren, indem Sie dies auf true umschalten. Bitte beachten Sie, dass die Audiodaten in der Nexus-Datenbank gespeichert werden, zwischen den Neustarts bestehen bleiben und nicht automatisch rotiert/bereinigt werden.

Log4j-Visualizer

    nexus_log4j_visualizer_enabled: false

Standardmäßig ist der Log4j-Visualizer auf false gesetzt. Sie können dies aktivieren, indem Sie auf true umschalten. Dies fügt die Log4j-Visualizer-Funktionalität zu Ihrer Nexus-Instanz hinzu.

Reverse-Proxy-Einrichtung

    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

Richten Sie einen SSL-Reverse-Proxy ein. Dies erfordert die Installation von httpd. Hinweis: Wenn httpd_setup_enable auf true gesetzt ist, bindet Nexus standardmäßig an 127.0.0.1:8081 und ist somit nicht direkt über den HTTP-Port 8081 von einer externen IP aus erreichbar. (Wenn Sie dies ändern möchten, können Sie ausdrücklich nexus_application_host: 0.0.0.0 festlegen.)

Der Standardhostname ist nexus_public_hostname. Wenn Sie aus irgendeinem Grund unterschiedliche Namen benötigen, können Sie httpd_server_name auf einen anderen Wert setzen.

Mit httpd_copy_ssl_files: true (Standardwert) müssen die oben genannten Zertifikate in Ihrem Playbook-Verzeichnis vorhanden sein und werden auf den Server kopiert und in Apache konfiguriert. httpd_ssl_certificate_chain_file ist optional und muss nicht gesetzt werden, wenn Sie keine Ketten-Datei konfigurieren möchten.

Wenn Sie vorhandene Zertifikate auf dem Server verwenden möchten, setzen Sie httpd_copy_ssl_files: false und geben Sie die folgenden Variablen an:

    # Diese geben an, wo auf dem Remote-Server-Dateisystem die Zertifikatdateien zu finden sind.
    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 ist optional und muss nicht gesetzt werden, wenn Sie keine Ketten-Datei konfigurieren möchten.

    httpd_default_admin_email: "[email protected]"

Setzen Sie die Standard-Admin-E-Mail-Adresse von httpd.

LDAP-Konfiguration

LDAP-Verbindungen und der Sicherheitsbereich sind standardmäßig deaktiviert.

    nexus_ldap_realm: false
    ldap_connections: []

LDAP-Verbindung(en) konfigurieren, wobei jeder Eintrag wie folgt aussieht:

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'Mein Unternehmens-LDAP' # wird als Schlüssel verwendet, um die LDAP-Konfiguration zu aktualisieren
        ldap_protocol: 'ldaps' # ldap oder ldaps
        ldap_hostname: 'ldap.meinunternehmen.com'
        ldap_port: 636
        ldap_use_trust_store: false # ob Zertifikate im Nexus-Vertrauensspeicher verwendet werden sollen
        ldap_search_base: 'dc=meinfirma,dc=net'
        ldap_auth: 'none' # oder simple
        ldap_auth_username: 'benutzername' # wenn auth = simple
        ldap_auth_password: 'passwort' # wenn auth = simple
        ldap_user_base_dn: 'ou=benutzer'
        ldap_user_filter: '(cn=*)' # (optional)
        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=gruppen'
        ldap_group_object_class: 'posixGroup'
        ldap_group_id_attribute: 'cn'
        ldap_group_member_attribute: 'memberUid'
        ldap_group_member_format: '${benutzername}'
        ldap_group_subtree: false

Beispiel für die LDAP-Konfiguration für die anonyme Authentifizierung (anonymer Bindung), dies ist auch die "minimale" Konfiguration:

    nexus_ldap_realm: true
    ldap_connection:
      - ldap_name: 'Einfachste LDAP-Konfiguration'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.meinfirma.com'
        ldap_search_base: 'dc=meinfirma,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'

Beispielhafte LDAP-Konfiguration für einfache Authentifizierung (unter Verwendung eines DSA-Kontos):

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'LDAP-Konfiguration mit DSA'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.meinfirma.com'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_auth: 'simple'
        ldap_auth_username: 'cn=mynexus,ou=dsa,dc=meinfirma,dc=net'
        ldap_auth_password: "{{ vault_ldap_dsa_password }}" # besser Passwörter in einem Ansible Vault aufbewahren
        ldap_search_base: 'dc=meinfirma,dc=net'
        ldap_user_base_dn: 'ou=benutzer'
        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

Beispielhafte LDAP-Konfiguration für einfache Authentifizierung (mit DSA-Konto) + Gruppen, die als Rollen gemappt werden:

    nexus_ldap_realm: true
    ldap_connections:
      - ldap_name: 'LDAP-Konfiguration mit DSA'
        ldap_protocol: 'ldaps'
        ldap_hostname: 'annuaire.meinfirma.com'
        ldap_port: 636
        ldap_use_trust_store: false
        ldap_auth: 'simple'
        ldap_auth_username: 'cn=mynexus,ou=dsa,dc=meinfirma,dc=net'
        ldap_auth_password: "{{ vault_ldap_dsa_password }}" # besser Passwörter in einem Ansible Vault aufbewahren
        ldap_search_base: 'dc=meinfirma,dc=net'
        ldap_user_base_dn: 'ou=benutzer'
        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=gruppen'
        ldap_group_object_class: 'groupOfNames'
        ldap_group_id_attribute: 'cn'
        ldap_group_member_attribute: 'member'
        ldap_group_member_format: 'uid=${benutzername},ou=benutzer,dc=meinfirma,dc=net'
        ldap_group_subtree: false

@Nliebelt schlug eine Konfiguration mit Erklärungen in einem Issue vor, um Nexus für Active Directory zu konfigurieren: https://github.com/ansible-ThoTeam/nexus3-oss/issues/341

Berechtigungen

    nexus_privileges:
      - name: all-repos-read # wird als Schlüssel verwendet, um eine Berechtigung zu aktualisieren
        # type: <eines von application, repository-admin, repository-content-selector, repository-view, script oder wildcard>
        description: 'Lese- und Durchsuchzugriff auf alle Repos'
        repository: '*'
        actions: # können add, browse, create, delete, edit, read oder * (alle) sein
          - read
          - browse
        # pattern: pattern
        # domain: domain
        # script_name: name

Liste der Berechtigungen, die eingerichtet werden sollen. Bitte sehen Sie sich die Dokumentation und die GUI an, um zu überprüfen, welche Variablen festgelegt werden sollten, abhängig vom Typ der Berechtigung.

Diese Elemente werden mit den folgenden Standardwerten kombiniert:

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

Rollen

    nexus_roles:
      - id: Developpers # kann auf eine LDAP-Gruppen-ID abgebildet werden, wird auch als Schlüssel verwendet, um eine Rolle zu aktualisieren
        name: developers
        description: Alle Entwickler
        privileges:
          - nx-search-read
          - all-repos-read
        roles: [] # Verweise auf andere Rollennamen

Neben der Erstellung von Rollen ist es auch möglich, eine Standardrolle zu definieren, die auf Benutzer und anonyme Anfragen angewendet wird, wenn Nexus die entsprechende Rolle nicht finden oder zuordnen kann. Die Standardrolle kann mit folgendem Befehl definiert werden:

nexus_default_role: "developers" # verwendet die Rolle 'entwickler' für alle Benutzer/Anfragen, denen keine ausdrücklich zugeordnete Rolle zugewiesen wurde. Standard: ""

Liste der Rollen, die eingerichtet werden sollen.

Benutzer

    nexus_local_users: []
      # - username: jenkins # wird als Schlüssel verwendet, um zu aktualisieren
      #   state: present # Standardwert, wenn weggelassen, verwenden Sie 'absent', um den Benutzer zu entfernen
      #   first_name: Jenkins
      #   last_name: CI
      #   email: [email protected]
      #   password: "s3cr3t"
      #   roles:
      #     - developers # Rolle-ID

Liste der lokalen (nicht LDAP) Benutzer/Konten, die in Nexus erstellt werden sollen. Der Status absent entfernt den Benutzer, wenn er vorhanden ist.

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

LDAP-Benutzer/-rollenzuordnungen. Der Status absent entfernt Rollen vom vorhandenen Benutzer, sofern sie bereits vorhanden sind. LDAP-Benutzer werden nicht entfernt. Der Versuch, Rollen für einen nicht existierenden Benutzer festzulegen, führt zu einem Fehler.

Inhaltsauswähler

  nexus_content_selectors:
  - name: docker-login
    description: Auswahl für Docker-Login-Berechtigung
    search_expression: format=="docker" and path=~"/v2/"

Für weitere Informationen zu Inhaltsauswählern siehe Dokumentation

Um den Inhaltsauswähler zu verwenden, fügen Sie eine neue Berechtigung mit type: repository-content-selector und dem entsprechenden contentSelector hinzu:

- name: docker-login-privilege
  type: repository-content-selector
  contentSelector: docker-login
  description: 'Login in das Docker-Repository'
  repository: '*'
  actions:
  - read
  - browse

Aufräumrichtlinien

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

Definitionen der Aufräumrichtlinien. Diese können zu den Repo-Definitionen mit der Option cleanup_policies hinzugefügt werden.

Blobstores und Repositories

    nexus_delete_default_repos: false

Löscht die Repositories aus der ursprünglichen Standardkonfiguration der Nexus-Installation. Dieser Schritt wird nur bei der Erstinstallation ausgeführt (wenn nexus_data_dir als leer erkannt wurde).

    nexus_delete_default_blobstore: false

Löscht den Standard-Blobstore aus der ursprünglichen Standardkonfiguration der Nexus-Installation. Dies kann nur erfolgen, wenn nexus_delete_default_repos: true und alle konfigurierten Repositories (siehe unten) einen expliziten blob_store: custom haben. Dieser Schritt wird nur bei der Erstinstallation ausgeführt (wenn nexus_data_dir als leer erkannt wurde).

    nexus_blobstores: []
    # Beispiel Blobstore-Element :
    # - 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, die erstellt werden sollen. Ein Blobstore-Pfad und ein Repository-Blobstore können nach der ursprünglichen Erstellung nicht mehr aktualisiert werden (jede Änderung wird beim erneuten Bereitstellen ignoriert).

Die Konfiguration des Blobstores auf S3 wird als Bequemlichkeit angeboten und ist nicht Teil der automatisierten Tests, die wir auf Travis ausführen. Bitte beachten Sie, dass das Speichern auf S3 nur für in AWS bereitgestellte Instanzen empfohlen wird.

    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
        # Content disposition ist nur für Raw- und Maven2-Proxy verfügbar und kann auf "attachment" oder "inline" gesetzt werden. Inline ist der Standardwert von Nexus, selbst wenn die Eigenschaft nicht explizit festgelegt wird.
        # 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
        # Content disposition ist nur für Raw- und Maven2-Proxy verfügbar und kann auf "attachment" oder "inline" gesetzt werden. Inline ist der Standardwert von Nexus, selbst wenn die Eigenschaft nicht explizit festgelegt wird.
        # content_disposition: inline
    # Beispiel mit Login/Passwort :
    # - name: secret-remote-repo
    #   remote_url: 'https://company.com/repo/secure/private/go/away'
    #   remote_username: 'benutzername'
    #   remote_password: 'geheim'
    #   # maximum_component_age: -1
    #   # maximum_metadata_age: 1440
    #   # negative_cache_enabled: true
    #   # negative_cache_ttl: 1440
    # Content disposition ist nur für Raw- und Maven2-Proxy verfügbar und kann auf "attachment" oder "inline" gesetzt werden. Inline ist der Standardwert von Nexus, selbst wenn die Eigenschaft nicht explizit festgelegt wird.
    # Um die HTTP-Anforderungseinstellungen festzulegen:
    #   # enable_circular_redirects: true
    #   # enable_cookies: true

Maven Proxy-Repositories-Konfiguration.

    nexus_repos_maven_hosted:
      - name: private-release
        version_policy: release
        write_policy: allow_once  # einer von "allow", "allow_once" oder "deny"
        # cleanup_policies:
        #    - mvn_cleanup

Maven gehostete Repositories-Konfiguration. Die negative Cache-Konfiguration ist optional und hat standardmäßig die Werte oben, wenn sie weggelassen wird.

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

Maven Gruppen-Repositories-Konfiguration.

Alle drei Repository-Typen werden mit den folgenden Standardwerten kombiniert:

    _nexus_repos_maven_defaults:
      blob_store: default # Hinweis: kann nicht aktualisiert werden, sobald das Repo erstellt wurde
      strict_content_validation: true
      version_policy: release # release, snapshot oder mixed
      layout_policy: strict # strict oder permissive
      write_policy: allow_once # einer von "allow", "allow_once" oder "deny"
      maximum_component_age: -1  # Nexus-GUI-Standard. Nur für Proxys
      maximum_metadata_age: 1440  # Nexus-GUI-Standard. Nur für Proxys
      negative_cache_enabled: true # Nexus-GUI-Standard. Nur für Proxys
      negative_cache_ttl: 1440 # Nexus-GUI-Standard. Nur für Proxys

Docker-Repositories

nexus_repos_docker_group:
  - name: einige-docker-gruppe
    sub_domain: hub-proxy # Wenn gesetzt, wird dies eine Subdomain-URL bereitstellen, z.B.: https://hub-proxy.your-nexus-instance.com
    writable_member_repo: docker-hosted-repo
    blob_store: docker-blob
    v1_enabled: False
    member_repos:
      - docker-hosted-repo

nexus_repos_docker_hosted:
  - name: einige-docker-repo
    blob_store: docker-blob
    v1_enabled: false
    write_policy: allow_once # Werte: "allow", "allow_once" oder "deny"
    # Wenn gesetzt, wird die definierte Schreibrichtlinie ignoriert und ermöglicht das erneute Bereitstellen von Containerbildern nur mit dem Tag 'latest'.
    allow_redeploy_latest: true

Maven, Pypi, Docker, Raw, Rubygems, Bower, NPM, Git-LFS, YUM, APT, Helm, R, P2, Conda und Go-Repositorytypen: siehe defaults/main.yml für diese Optionen. Aus historischen Gründen und um die Abwärtskompatibilität zu gewährleisten, ist Maven standardmäßig konfiguriert.

      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

Diese sind alle false, es sei denn, Sie überschreiben sie in Playbook / group_var / cli, diese nutzen alle denselben Mechanismus wie Maven.

Bitte beachten Sie, dass Sie möglicherweise bestimmte Sicherheitsbereiche aktivieren müssen, wenn Sie andere Repository-Typen als Maven verwenden möchten. Diese sind standardmäßig auf false gesetzt.

nexus_nuget_api_key_realm: false
nexus_npm_bearer_token_realm: false
nexus_docker_bearer_token_realm: false  # erforderlich für den anonymen Docker-Zugriff

Der Remote User Realm kann ebenfalls aktiviert werden mit:

nexus_rut_auth_realm: true

Und der Header kann konfiguriert werden, indem Sie angeben:

nexus_rut_auth_header: "CUSTOM_HEADER"

Geplante Aufgaben

Dies sind schnelle Beispiele und Anweisungen zur Einrichtung geplanter Aufgaben. Für detaillierte Informationen zu den verfügbaren Aufgabentypen und Zeitplänen siehe den spezifischen Abschnitt im Repo-Wiki

    nexus_scheduled_tasks: []
    #  #  Beispielsauftrag zur Verdichtung des Blobstores :
    #  - name: compact-docker-blobstore
    #    cron: '0 0 22 * * ?'
    #    typeId: blobstore.compact
    #    task_alert_email: [email protected]  # optional
    #    taskProperties:
    #      blobstoreName: {{ nexus_blob_names.docker.blob }} # alle Aufgabenattribute werden intern von Nexus als Strings gespeichert
    #  #  Beispielsauftrag, um Maven-Snapshots zu beseitigen
    #  - name: Purge-maven-snapshots
    #    cron: '0 50 23 * * ?'
    #    typeId: repository.maven.remove-snapshots
    #    task_alert_email: [email protected]  # optional
    #    taskProperties:
    #      repositoryName: "*"  # * für alle Repos. Ändern Sie auf einen Repositoriesnamen, wenn Sie nur einen bestimmten wollen
    #      minimumRetained: "2"
    #      snapshotRetentionDays: "2"
    #      gracePeriodInDays: "2"
    #    booleanTaskProperties:
    #      removeIfReleased: true
    #  #  Beispielsauftrag, um ungenutzte Docker-Manifest und -Images zu beseitigen
    #  - name: Purge unused docker manifests and images
    #    cron: '0 55 23 * * ?'
    #    typeId: "repository.docker.gc"
    #    task_alert_email: [email protected]  # optional
    #    taskProperties:
    #      repositoryName: "*"  # * für alle Repos. Ändern Sie auf einen Repositoriesnamen, wenn Sie nur einen bestimmten wollen
    #  #  Beispielsauftrag, um unvollständige Docker-Uploads zu beseitigen
    #  - name: Purge incomplete docker uploads
    #    cron: '0 0 0 * * ?'
    #    typeId: "repository.docker.upload-purge"
    #    task_alert_email: [email protected]  # optional
    #    taskProperties:
    #      age: "24"

Geplante Aufgaben einrichten. typeId und aufgabenspezifische taskProperties/booleanTaskProperties können erraten werden entweder:

  • von der Java-Typ-Hierarchie von org.sonatype.nexus.scheduling.TaskDescriptorSupport
  • durch die Inspektion des HTML-Formulars zur Aufgabenerstellung in Ihrem Browser
  • durch einen Blick auf die Browser-AJAX-Anfragen während der manuellen Konfiguration einer Aufgabe.

Aufgabeigenschaften müssen im richtigen YAML-Block erklärt werden, abhängig von ihrem Typ:

  • taskProperties für alle Zeichenfolgen-Eigenschaften (d. h. Repositoriesnamen, Blobstore-Namen, Zeiträume ...).
  • booleanTaskProperties für alle booleschen Eigenschaften (d. h. hauptsächlich Kontrollkästchen in der Nexus-Benutzeroberfläche zur Erstellung von Aufgaben).

Backups

      nexus_backup_configure: false
      nexus_backup_schedule_type: cron
      nexus_backup_cron: '0 0 21 * * ?'  # Siehe Cron-Ausdrucksdefinitionen in der Nexus-Aufgabenerstellungs-GUI
      # nexus_backup_start_date_time: "yyyy-MM-dd'T'HH:mm:ss"
      # nexus_backup_weekly_days: ['MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT']
      # 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  # Bewahren Sie standardmäßig 4 Backup-Drehungen (aktuell + die letzten 3) auf

Backups werden nicht konfiguriert, es sei denn, Sie setzen nexus_backup_configure: true. In diesem Fall wird eine Skriptaufgabe in Nexus konfiguriert.

Der Zeitplan der Skriptaufgabe wird standardmäßig auf cron gesetzt und läuft jeden Tag um 21:00 Uhr. Sie können jeden beliebigen Zeitplan festlegen, den Sie möchten, indem Sie entsprechend die Variablen nexus_backup_schedule_type, nexus_backup_cron, nexus_backup_start_date_time, nexus_backup_weekly_days und nexus_backup_monthly_days einstellen. Um deren Verwendung je nach dem Typ des Zeitplans zu verstehen, siehe Geplante Aufgaben.

Siehe die Groovy-Vorlage für diese Aufgabe für Details. Diese geplante Aufgabe ist unabhängig von den anderen nexus_scheduled_tasks, die Sie in Ihrem Playbook erklären.

Wenn Sie Backups in ein gemountetes Verzeichnis (z. B. s3fs) sichern möchten, können Sie nexus_backup_dir_create auf false setzen.

Wiederherstellungsverfahren

Führen Sie Ihr Playbook mit dem Parameter -e nexus_restore_point=<YYYY-MM-dd-HH-mm-ss> aus (z. B. 2017-12-17-21-00-00 für den 17. Dezember 2017 um 21:00:00).

Mögliche Einschränkungen

Blobstore-Kopien werden direkt von Nexus über die zum Zeitplan gehörende Skriptaufgabe erstellt. Dies wurde nur für eher kleine Blobstores (weniger als 50 Go) getestet und sollte mit Vorsicht verwendet und bei größeren Installationen sorgfältig getestet werden, bevor es in die Produktion geht. In jedem Fall können Sie Ihr eigenes Backup-Szenario unabhängig von dieser Rolle implementieren.

Besondere Wartungs-/Debugvariablen

Diese Variablen sind nicht in defaults/main.yml enthalten und sind nur für Wartungs-/Debugzwecke über die Befehlszeile gedacht.

Nexus bereinigen

Warnung: Dadurch werden die aktuellen Daten vollständig gelöscht. Stellen Sie sicher, dass Sie vorher ein Backup erstellen, falls erforderlich.

Verwenden Sie die Variable nexus_purge, wenn Sie von Grund auf neu neu starten und eine leere Instanz von Nexus neu installieren müssen.

ansible-playbook -i your/inventory.ini your_nexus_playbook.yml -e nexus_purge=true

Erzwinge die Registrierung von Groovy-Skripten

Diese ist sicher und sorgt nur dafür, dass das Playbook länger ausgeführt wird, wenn es nicht nötig ist.

Aus Leistungsgründen verwenden wir einen kleinen Trick mit mehreren Rsyncs, um zu erkennen, welche Wartungs-Groovy-Skripte in Nexus registriert werden müssen. In einigen Fällen (z. B. bei falschem Admin-Passwort, Wiederherstellung eines Backups von einer vorherigen Nexus-Instanz mit nicht registrierten Skripten ...) kann dies zu Situationen führen, in denen die Rolle fehlschlägt, wenn versucht wird, die notwendigen Groovy-Skripte auszuführen.

Das Symptom: Sie erhalten HTTP 404-Fehler, wenn die Rolle versucht, Skripte auszuführen, wie im folgenden Beispiel (verwenden Sie die Option -v für das Ansible-Playbook):

fatal: [nexus3-oss]: FAILED! => {"changed": false, "connection": "close", "content": "", "date": "Tue, 11 Sep 2018 07:57:44 GMT", "msg": "Status code was 404 and not [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"}

In solchen Fällen können Sie die (Re-)Registrierung der Groovy-Skripte mit der Variable nexus_force_groovy_scripts_registration erzwingen:

ansible-playbook -i your/inventory.ini your_playbook.yml -e nexus_force_groovy_scripts_registration=true

Ändern des Admin-Passworts nach der ersten Installation

    nexus_default_admin_password: 'admin123'

Diese sollte nicht in Ihrem Playbook geändert werden. Diese Variable wird mit dem Standard-Nexus-Admin-Passwort bei der Erstinstallation ausgefüllt und sorgt dafür, dass wir das Admin-Passwort auf nexus_admin_password ändern können.

Wenn Sie Ihr Admin-Passwort nach der ersten Installation ändern möchten, können Sie dies vorübergehend auf Ihr altes Passwort von der Befehlszeile ändern. Nachdem Sie nexus_admin_password in Ihrem Playbook geändert haben, können Sie Folgendes ausführen:

ansible-playbook -i your/inventory.ini your_playbook.yml -e nexus_default_admin_password=oldPassword

Upgrade von Nexus auf die neueste Version

    nexus_upgrade: true

Diese Variable hat keine Auswirkungen, wenn nexus_version in Ihren Variablen festgelegt ist.

Sofern Sie diese Variable nicht festlegen, behält die Rolle die aktuell installierte Nexus-Version bei, wenn sie gegen einen bereits bereitgestellten Host ausgeführt wird. Durch Übergabe dieser zusätzlichen Variablen wird die automatische Erkennung der neuesten Nexus-Version aktiviert und ein Upgrade durchgeführt, wenn eine neuere Version verfügbar ist.

Einstellung dieser Variablen als Teil Ihres Playbooks unterbricht die Idempotenz (d.h. Ihr Playbook bringt Änderungen an Ihrem System vor, wenn eine neue Version verfügbar ist, obwohl keine Parameter geändert wurden).

Wir empfehlen dringend, diese Variable nur als zusätzliche Variable im Ansible-Playbook-Befehl zu verwenden:

ansible-playbook -i your/inventory.ini your_playbook.yml -e nexus_upgrade=true
Fehler beim Upgrade beheben, der aufgrund von Zeitüberschreitungen beim Warten auf den Nexus-Port auftritt

Wenn Sie ein großes Nexus-Repository haben, sehen Sie möglicherweise gelegentlich eine Fehlermeldung beim Upgrade:

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"}

Dies liegt höchstwahrscheinlich daran, dass der Nexus-Upgrade-Prozess (d.h. Migration des internen OrientDB) länger dauert als die Standard-300 Sekunden. Sie können diese Situation überwinden, indem Sie einen benutzerdefinierten Timeout in Sekunden und/oder eine Anzahl von Wiederholungen für die Handler-Aufgabe festlegen.

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

Provisionierungsaufgaben überspringen

    nexus_run_provisionning: false

Diese Variable ist standardmäßig nicht gesetzt und wird standardmäßig auf true gesetzt. Das Setzen auf false führt dazu, dass die Rolle alle Provisionierungsaufgaben überspringt und somit nicht erstellt/aktualisiert:

  • LDAP-Konfigurationen
  • Inhaltsauswähler
  • Berechtigungen
  • Rollen
  • Benutzer (außer Überprüfung/Aktualisierung des Admin-Passworts)
  • Blobstores
  • Repositories
  • Aufgaben (Backups werden weiterhin konfiguriert, falls aktiviert)

Dies kann Zeit sparen, wenn Sie viele konfigurierte Repositories/Benutzer/Rollen haben und die Rolle spielen möchten, nur um sicherzustellen, dass Nexus korrekt installiert ist oder um ein Backup wiederherzustellen oder die Nexus-Version zu aktualisieren.

Wir empfehlen dringend, diese Variable nur als zusätzliche Variable im Ansible-Playbook-Befehl zu verwenden:

ansible-playbook -i your/inventory.ini your_playbook.yml -e nexus_run_provisionning=false

Erzwingen der rekursiven Überprüfung des Eigentums von Blobstores-Verzeichnissen

Eingeführt in Version 2.4.9

    nexus_blobstores_recurse_owner: true

In Versionen vor 2.4.9 überprüfte die Aufgabe, die die Blobstores-Verzeichnisse erstellte, rekursiv das Eigentum aller Dateien. Dies war bei der Erstellung (wo das Verzeichnis leer ist) oder bei Installationen mit kleinen Blobstores kein Problem, könnte jedoch zu extrem langen Verzögerungen bei großen Blobstores mit vielen Dateien führen.

Die rekursive Überprüfung des Eigentums wurde standardmäßig deaktiviert, um diese zusätzliche Verzögerung zu verhindern. Wenn Sie aus irgendeinem Grund sicherstellen müssen, dass alle Dateien in den Blobstore-Verzeichnissen dem Nexus-Benutzer gehören, können Sie die Überprüfung erzwingen:

ansible-playbook -i your/inventory.ini your_playbook.yml -e nexus_blobstores_recurse_owner=true

Abhängigkeiten

Die Anforderungen an Java und HTTPD / können mit den folgenden Galaxy-Rollen erfüllt werden:

Fühlen Sie sich frei, diese zu verwenden oder Ihr eigenes Installationsszenario nach Ihrem Belieben zu implementieren.

Beispiel-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: 'Lese- und Durchsuchzugriff auf alle Repos'
        repository: '*'
        actions:
          - read
          - browse
      - name: company-project-deploy
        description: 'Bereitstellungen in das Unternehmensprojekt'
        repository: company-project
        actions:
          - add
          - edit
    nexus_roles:
      - id: Developpers # ordnet der LDAP-Gruppe zu
        name: developers
        description: Alle Entwickler
        privileges:
          - nx-search-read
          - all-repos-read
          - company-project-deploy
        roles: []
    nexus_local_users:
      - username: jenkins # wird als Schlüssel verwendet, um zu aktualisieren
        first_name: Jenkins
        last_name: CI
        email: [email protected]
        password: "s3cr3t"
        roles:
          - Developpers # Rolle-ID hier
    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 # Standard ist false
        auto_block: true # Standard ist true
        connection_timeout: 200 # Standard ist nicht gesetzt
        connection_retries: 5 # Standard ist nicht gesetzt
        user_agent_suffix: custom-agent # Standard ist nicht gesetzt
        remote_url: https://some-private-registry.dev/
        remote_username: 'secret-username'
        remote_password: "{{ vault_alfresco_secret_password }}"
        # Sie können ebenfalls einen präemptiven Bearer-Token verwenden, indem Sie die Eigenschaft bearerToken definieren
        # bearerToken: "{{ vault_alfresco_secret_bearertoken }}"

  rollen:
    - { rolle: geerlingguy.java, vars: Siehe Rollendokumentation für Ihre Distribution/version }
    # Nur Debian/Ubuntu
    # - { rolle: 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"] }
    # Nur RedHat/CentOS
    - { rolle: geerlingguy.apache, apache_create_vhosts: no, apache_remove_default_vhost: true, tags: ["geerlingguy.apache"] }
    - { rolle: ansible-thoteam.nexus3-oss, tags: ['ansible-thoteam.nexus3-oss'] }

Entwicklung, Beitrag und Testing

Beiträge

Alle Beiträge zu dieser Rolle sind willkommen, sei es für Fehlerbehebungen, neue Funktionen oder Dokumentationen.

Wenn Sie einen Beitrag leisten möchten:

  • Forken Sie das Repository unter Ihrem eigenen Namen/Ihrer eigenen Organisation über die GitHub-Oberfläche.
  • Erstellen Sie einen Branch in Ihrem eigenen Repository mit einem bedeutungsvollen Namen. Wir schlagen die folgende Namenskonvention vor:
    • feat/<someFeature> für Funktionen
    • fix/<someBugFix> für Fehlerbehebungen
    • docfix/<someDocFix> für Dokumentationsfehler
  • Wenn Sie eine wichtige Funktionsänderung starten, öffnen Sie frühzeitig einen Pull-Request, um zu beschreiben, was Sie tun möchten, damit wir darüber diskutieren können, falls nötig. Dies wird verhindern, dass Sie viel harte Arbeit an viel Code machen, für Änderungen, die wir schließlich nicht zusammenführen können.
  • Wenn es auf Ihrem Pull-Request Build-Fehler gibt, schauen Sie sich die Travis-Protokolle an und beheben Sie die relevanten Fehler.

Darüber hinaus, wenn Sie Zeit für die Codeüberprüfung, das Zusammenführen von Releases usw. haben, senden Sie eine E-Mail an contact@thoteam.com, um Kontakt aufzunehmen.

Testing

Diese Rolle umfasst Tests und CI-Integration über Travis. Derzeit testen wir:

  • Groovy-Skriptsyntax
  • YAML-Syntax und Codierungsstandard (yamllint)
  • Ansible gute Praktiken (ansible lint)
  • Eine Reihe grundlegender Bereitstellungen auf 2 verschiedenen Linux-Plattformen
    • Rockylinux 9 (als enger Verwandter der RHEL-Produkte, da CentOS obsolet ist)
    • Debian 12 Bookworm

Andere Tests sind für ältere/differentielle Plattformen verfügbar, aber aus Leistungsgründen nicht auf CI ausgeführt:

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

Groovy-Syntax

Diese Rolle enthält eine Reihe von Groovy-Dateien, die zur Bereitstellung von Nexus verwendet werden.

Wenn Sie Änderungen an Groovy-Dateien einreichen, führen Sie bitte lokal die Groovy-Syntaxüberprüfung aus, bevor Sie Ihre Änderungen pushen:

./tests/test_groovySyntax.sh

Dies stellt sicher, dass Sie Groovy-Dateien mit korrekter Syntax pushen, um die Anzahl von Checkfehlern auf Travis zu minimieren.

Sie müssen das Groovy-Paket lokal installiert haben, um diesen Test auszuführen.

Molecule default-xxxx Szenarien

Die Rolle wird auf Travis mit Molecule getestet. Sie können diese Tests lokal ausführen. Der beste Weg, dies zu erreichen, ist über ein Python-Virtualenv. Sie finden weitere Einzelheiten in requirements.txt.

# Hinweis: Der folgende Pfad sollte außerhalb des Arbeitsverzeichnisses liegen
virtualenv /path/to/some/pyenv
. /path/to/some/pyenv/bin/activate
pip install -r requirements.txt
molecule [create|converge|destroy|test] -s <szenarienname>
deactivate

Bitte beachten Sie die Molecule-Dokumentation (ein guter Ausgangspunkt ist molecule --help) für weitere Verwendung.

Die derzeit vorgeschlagenen Szenarien beziehen sich auf die getesteten Plattformen (siehe Verzeichnis molecule/). Wenn Sie ein Szenario starten und den Container laufen lassen (d.h. converge für eine einfache Bereitstellung verwenden), können Sie auf die laufende Instanz über Ihren Browser unter https://localhost: zugreifen. Siehe die Datei molecule/<scenario>/molecule.yml für Details. Als Bequemlichkeit hier ist die Zuordnung zwischen Szenarien und konfigurierten Ports:

Um die Tests zu beschleunigen, verwendet Molecule vorgefertigte Docker-Hub-Images.

Bitte beachten Sie, dass diese Images nach bestem Bemessen gebaut und gepusht werden, wann immer es für Änderungen an diesem Repository erforderlich ist.

Lizenz

GNU GPLv3

Autorinformationen

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

Über das Projekt

Nexus Repository Manager 3.x (Sonatype)

role nexus nexus3 java maven npm nuget yum docker pypi web
Installieren
ansible-galaxy install ansible-ThoTeam.nexus3-oss
GitHub Repository
296 Sterne
208 Forks
33 Offene Issues
Lizenz
gpl-3.0
Downloads
1.1M
Besitzer
Ansible collections and roles by ThoTeam
Ansible public collections and roles by ThoTeam. Contributions welcome