Ansible Rolle: cis_ubuntu_2004 :computer:

Ansible Rolle zur Anwendung des CIS Benchmarks für Ubuntu Linux 20.04 LTS.

Aktuell unterstützte und verfügbare Versionen sind:

• CIS Benchmark für Ubuntu Linux 20.04 LTS v1.1.0
• CIS Benchmark für Ubuntu Linux 20.04 LTS v1.0.0

Versionierung

Die folgende Tabelle zeigt die verfügbaren Versionen der Rolle auf Ansible Galaxy und GitHub Releases, entsprechend dem CIS Benchmark für Ubuntu Linux 20.04 LTS.

1. Installations-/Download-Anleitungen:

Diese Rolle ist auf Ansible Galaxy verfügbar. Es gibt mehrere Methoden, um die Rolle cis_ubuntu_2004 auf Ihrem Ansible-Controller-Knoten entweder von Ansible Galaxy oder direkt aus dem Repository zu installieren/herunterzuladen.

Ohne eine requirements.yml-Datei:

• Neueste (Standard) verfügbare Tag-Version installieren/herunterladen:

  ansible-galaxy install darkwizard242.cis_ubuntu_2004
  

• Bestimmte verfügbare Tag-Version installieren/herunterladen (mit 3.2.0 als Beispiel):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,3.2.0
  

• Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (mit dem master-Zweig als Beispiel):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,master
  

• Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (mit dem feature/cis_version_1.1.0-Zweig als Beispiel, der mit den neuesten Updates für CIS Ubuntu 20.04 Benchmark Version v1.1.0 übereinstimmt):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.1.0
  

• Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (mit dem feature/cis_version_1.0.0-Zweig als Beispiel, der mit den neuesten Updates für CIS Ubuntu 20.04 Benchmark Version v1.0.0 übereinstimmt):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.0.0
  

Mit einer requirements.yml-Datei:

Fügen Sie zu einer bestehenden requirements.yml-Datei zusammen mit Ihren anderen Rollen hinzu oder erstellen Sie eine neue, um cis_ubuntu_2004 zu installieren.

• Neueste Version direkt von Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
  

• Bestimmte Version direkt von Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
    version: 3.2.0
  

• Bestimmte Branch aus dem Repository.

  - name: cis_ubuntu_2004
    src: https://github.com/darkwizard242/cis_ubuntu_2004
    version: master
  

Installation/Download nach dem Hinzufügen zur requirements.yml :

ansible-galaxy install -r requirements.yml

HINWEIS: Die Installation einer Rolle wie oben beschrieben lädt nur die Rolle herunter, damit sie in Ihren Ansible-Playbooks verwendet werden kann. Weitere Informationen zur Installation und zum Download von Rollen finden Sie hier.

2. Einige Überlegungen:

Die Benchmarks zur Festplattenpartitionierung und ihren Einbindungspunkten aus Abschnitt 1 werden in dieser Rolle nicht angewendet. Der Grund ist einfach, dass sich die Systemarchitektur und das Festplattenlayout jedes Einzelnen/Jeder Organisation wahrscheinlich unterscheiden. Ich empfehle, diese selbst anzuwenden. Hier ist eine Liste dieser Benchmarks:

• 1.1.10 Sicherstellen, dass eine separate Partition für /var existiert (Automatisiert)
• 1.1.11 Sicherstellen, dass eine separate Partition für /var/tmp existiert (Automatisiert)
• 1.1.12 Sicherstellen, dass die /var/tmp-Partition die Option nodev enthält (Automatisiert)
• 1.1.13 Sicherstellen, dass die /var/tmp-Partition die Option nosuid enthält (Automatisiert)
• 1.1.14 Sicherstellen, dass die /var/tmp-Partition die Option noexec enthält (Automatisiert)
• 1.1.15 Sicherstellen, dass eine separate Partition für /var/log existiert (Automatisiert)
• 1.1.16 Sicherstellen, dass eine separate Partition für /var/log/audit existiert (Automatisiert)
• 1.1.17 Sicherstellen, dass eine separate Partition für /home existiert (Automatisiert)
• 1.1.18 Sicherstellen, dass die /home-Partition die Option nodev enthält (Automatisiert)
• 1.1.19 Sicherstellen, dass die nodev-Option auf Wechselmedienpartitionen gesetzt ist (Manuell)
• 1.1.20 Sicherstellen, dass die nosuid-Option auf Wechselmedienpartitionen gesetzt ist (Manuell)
• 1.1.21 Sicherstellen, dass die noexec-Option auf Wechselmedienpartitionen gesetzt ist (Manuell)

Folgende Benchmarks aus Abschnitt 4 wurden ebenfalls nicht implementiert:

• 4.2.1.5 Sicherstellen, dass rsyslog so konfiguriert ist, dass Protokolle an einen entfernten Protokollserver gesendet werden (Automatisiert)
• 4.2.1.6 Sicherstellen, dass entfernte rsyslog-Nachrichten nur auf bestimmten Protokollservern akzeptiert werden. (Manuell)
• 4.3 Sicherstellen, dass logrotate konfiguriert ist (Manuell)

3. Anforderungen

Keine.

4. Rollenvariablen

Standardvariablen der Rolle, die in den Aufgabentasks verwendet werden, befinden sich in defaults/main/.

defaults/main/main.yml enthält Variablen, die sich auf die gesamten CIS-Abschnitte beziehen, sowie die systembrechenden Variablen, die im Abschnitt Wichtige Variablen erwähnt werden:

ubuntu_2004_cis_section1: true
ubuntu_2004_cis_section2: true
ubuntu_2004_cis_section3: true
ubuntu_2004_cis_section4: true
ubuntu_2004_cis_section5: true
ubuntu_2004_cis_section6: true

Der Zweck der oben genannten Variablen ist es, anzuzeigen, dass alle Aufgaben, die sich auf diese Abschnitte beziehen, durch die Rolle cis_ubuntu_2004 angewendet werden sollen.

Variablen für jeden Abschnitt befinden sich in ihren eigenen Dateien.

• Abschnitt 1 Variablen befinden sich in defaults/main/section_01.yml
• Abschnitt 2 Variablen befinden sich in defaults/main/section_02.yml
• Abschnitt 3 Variablen befinden sich in defaults/main/section_03.yml
• Abschnitt 4 Variablen befinden sich in defaults/main/section_04.yml
• Abschnitt 5 Variablen befinden sich in defaults/main/section_05.yml
• Abschnitt 6 Variablen befinden sich in defaults/main/section_06.yml

Die Standardwerte der Rolle für alles in der Rolle cis_ubuntu_2004 können durch das Übergeben in ein Playbook oder eine andere Methode der Variablenpräzenz überschrieben werden.

• Wichtige Variablen

Die CIS Ubuntu 20.04-Hardening-Benchmarks erfordern das Löschen vieler Dienste, die ausgenutzt werden können, bekannte Schwachstellen aufweisen oder deren Deaktivierung erforderlich ist, wenn sie nicht benötigt werden. Laut Benchmark werden standardmäßig all diese Dienste gelöscht und die Werte ihrer Variablen auf false gesetzt. Wenn Sie diese Dienste jedoch aus einem bestimmten Grund weiterhin verwenden möchten, ändern Sie deren Werte auf true, damit beim Anwenden der Rolle in einem Playbook die Rollentasks zum Löschen dieser Dienste übersprungen werden können.

Zusätzlich zur obigen Erklärung für einige Variablen gibt es auch andere Variablen, die definieren, ob ein spezifischer Dienst im System gewünscht ist oder nicht (z. B. SSH-Daemon), Parameter zur Konfiguration verschiedener Werkzeuge (z. B. auditd) usw. Diese können ebenfalls in einem Playbook überschrieben werden.

# Auf true setzen, wenn IPv6 erforderlich ist.
ubuntu_2004_cis_require_ipv6: false

# Auf true setzen, wenn Wireless erforderlich ist.
ubuntu_2004_cis_require_wireless: false

# Auf true setzen, wenn das System als Router fungieren soll.
ubuntu_2004_cis_require_router: false

# Auf false setzen, wenn der SSH-Daemon nicht benötigt wird.
ubuntu_2004_cis_require_ssh_server: true

# Variable zur Speicherung starker Chiffren für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_ciphers: [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# Variable zur Speicherung starker MAC-Algorithmen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_macs: [email protected],[email protected],hmac-sha2-512,hmac-sha2-256

# Variable zur Speicherung starker Schlüsselverhandlungsalgorithmen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_kexalgorithms: curve25519-sha256,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

# Variable zur Speicherung des ClientAlive-Intervalls in Sekunden für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_clientaliveinterval: '300'

# Variable zur Speicherung der maximalen Anzahl von ClientAlive-Count für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_clientalivecountmax: '3'

# Variable zur Speicherung der Login-Gnadenzeit in Sekunden für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_logingracetime: '60'

# Variable zur Speicherung der erlaubten Benutzer für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_allowusers: ubuntu vagrant

# Variable zur Speicherung der erlaubten Gruppen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_allowgroups: ubuntu vagrant

# Variable zur Speicherung der verweigerten Benutzer für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_denyusers: bogus dummy

# Variable zur Speicherung der verweigerten Gruppen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_denygroups: bogus dummy

# Variable zur Speicherung der minimalen Länge und der Zeichenklassen für die PAM-Passwortqualität.
ubuntu_2004_cis_require_pam_pwquality:
  - key: 'minlen'
    value: '14'
  - key: 'minclass'
    value: '4'

# Variable zur Speicherung des Wertes von PASS_MAX_DAYS für die Passwortablaufzeit.
ubuntu_2004_cis_require_passmaxdays: '365'

# Variable zur Speicherung des Wertes von PASS_MIN_DAYS für die Passwortänderung.
ubuntu_2004_cis_require_passmindays: '1'

# Variable zur Speicherung des Wertes von INACTIVE zur Festlegung des Standardzeitraums für die Passwortinaktivität auf 30 Tage.
ubuntu_2004_cis_require_passwarnage: '7'

# Variable zur Speicherung des Wertes von PASS_WARN_AGE für die Festlegung der Passwortablaufbenachrichtigung in Tagen.
ubuntu_2004_cis_require_passinactive: '30'

# Variable zur Speicherung des Wertes des Shell-Timeouts in Sekunden.
ubuntu_2004_cis_require_shell_timeout: '900'

# Variable zur Speicherung des Gruppennamens, der für die Verwendung von su-Exec benötigt wird.
ubuntu_2004_cis_require_su_group: sugroup

# Variable zur Speicherung des Protokolldateipfads, in dem die Cron-Job-Ausführung für die Aufgabe 6.1.1 Protokollsystemdateiberechtigungen (manuell) speichert.
ubuntu_2004_cis_require_audit_system_file_permissions_logfile: /var/log/6_1_1_cis_audit_system.log

# Kann eines der folgenden sein: 'iptables' oder 'nftables' oder 'ufw'.
ubuntu_2004_cis_firewall: ufw

# WENN 'ufw' verwendet wird, ermöglicht das Setzen auf 'yes' die Konfiguration und Zulassung eines UFW-Git-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_git_profile: yes

# WENN 'ufw' verwendet wird, ermöglicht das Setzen auf 'yes' die Konfiguration und Zulassung eines UFW-HTTP-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_http_profile: yes

# WENN 'ufw' verwendet wird, ermöglicht das Setzen auf 'yes' die Konfiguration und Zulassung eines UFW-HTTPS-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_https_profile: yes

# WENN 'ufw' verwendet wird, wird das Setzen auf 'true' alle eingehenden Verbindungen standardmäßig verweigern. Funktioniert wie `ufw default deny incoming`. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen.
ubuntu_2004_cis_section3_rule_ufw_default_deny_incoming: true

# WENN 'ufw' verwendet wird, wird das Setzen auf 'true' alle ausgehenden Verbindungen standardmäßig verweigern. Funktioniert wie `ufw default deny outgoing`. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen.
ubuntu_2004_cis_section3_rule_ufw_default_deny_outgoing: true

# WENN 'ufw' verwendet wird, wird das Setzen auf 'true' alle gerouteten Verbindungen standardmäßig verweigern. Funktioniert wie `ufw default deny routed`. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen.
ubuntu_2004_cis_section3_rule_ufw_default_deny_routed: true

# WENN 'nftables' verwendet wird, wird das Setzen auf 'true' alle Eingangs-/Weiterleitungs-/Ausgangsverbindungen standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_3_5_2_8: true

# WENN 'iptables' verwendet wird, wird das Setzen auf 'true' alle eingehenden Verbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_input: true

# WENN 'iptables' verwendet wird, wird das Setzen auf 'true' alle ausgehenden Verbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_output: true

# WENN 'iptables' verwendet wird, wird das Setzen auf 'true' alle Weiterleitungsverbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_forward: true

# WENN 'iptables' verwendet wird und ipv6 aktiviert ist, wird das Setzen auf 'true' alle eingehenden Verbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_input: true

# WENN 'iptables' verwendet wird und ipv6 aktiviert ist, wird das Setzen auf 'true' alle ausgehenden Verbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_output: true

# WENN 'iptables' verwendet wird und ipv6 aktiviert ist, wird das Setzen auf 'true' alle Weiterleitungsverbindungen über ipv4 standardmäßig verweigern, was das System unerreichbar macht. Setzen Sie es auf `false`, wenn Sie dies nicht benötigen oder die Verbindung verlieren möchten.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_forward: true

# Kann eines der folgenden sein: 'ntp', 'chrony' oder 'systemd-timesyncd'.
ubuntu_2004_cis_time_synchronization: systemd-timesyncd

# Auditd-Rückstandsgrenze zum Speichern ausreichender Protokolle beim Booten.
ubuntu_2004_cis_auditd_backloglimit: '8192'

# Protokolldateigröße für auditd-Protokolle. Angemessen festlegen.
ubuntu_2004_cis_auditd_maxlogfile: '25'

# Aktion, die ausgeführt werden soll, wenn die auditd-Protokolle die maximale Größe erreicht haben. Angemessen festlegen.
ubuntu_2004_cis_auditd_maxlogfileaction: keep_logs

# Aktion, die bei wenig Speicherplatz für auditd ausgeführt werden soll. Angemessen festlegen.
ubuntu_2004_cis_auditd_spaceleftaction: email

# Wer für auditd benachrichtigt werden soll. Angemessen festlegen.
ubuntu_2004_cis_auditd_actionmailacct: root

# Option zum Anhalten, wenn die Audit-Protokolle voll sind. Angemessen festlegen.
ubuntu_2004_cis_auditd_adminspaceleftaction: halt

# Benutzer, die Cron-Jobs planen dürfen.
ubuntu_2004_cis_cron_allow_users:
  - root
  - ubuntu

# Benutzer, die 'at' verwenden dürfen, um Jobs zu planen.
ubuntu_2004_cis_at_allow_users:
  - root
  - ubuntu

# Auf `true` setzen, wenn das X Windows System benötigt wird.
ubuntu_2004_cis_require_xwindows_system: false

# Auf `true` setzen, wenn CUPS benötigt wird.
ubuntu_2004_cis_require_cups: false

# Auf `true` setzen, wenn ein DHCP-Server benötigt wird.
ubuntu_2004_cis_require_dhcp_server: false

# Auf `true` setzen, wenn ein LDAP-Server benötigt wird.
ubuntu_2004_cis_require_ldap_server: false

# Auf `true` setzen, wenn ein NFS-Server benötigt wird.
ubuntu_2004_cis_require_nfs_server: false

# Auf `true` setzen, wenn ein DNS-Server benötigt wird.
ubuntu_2004_cis_require_dns_server: false

# Auf `true` setzen, wenn ein FTP-Server benötigt wird.
ubuntu_2004_cis_require_ftp_server: false

# Auf `true` setzen, wenn ein HTTP-Server (apache2) benötigt wird.
ubuntu_2004_cis_require_http_server: false

# Auf `true` setzen, wenn IMAP- und POP3-Server benötigt werden.
ubuntu_2004_cis_require_imap_pop3_server: false

# Auf `true` setzen, wenn der Samba-Daemon benötigt wird.
ubuntu_2004_cis_require_samba_server: false

# Auf `true` setzen, wenn der Squid-Server benötigt wird.
ubuntu_2004_cis_require_squid_server: false

# Auf `true` setzen, wenn der SNMP-Server benötigt wird.
ubuntu_2004_cis_require_snmp_server: false

# Um zu vermeiden, dass Postfix im Nur-Lokal-Modus arbeitet. Definieren Sie es als `false`, wenn Postfix im Nur-Lokal-Modus arbeiten soll.
ubuntu_2004_cis_require_mail_server: true

# Auf `true` setzen, wenn RSYNC benötigt wird.
ubuntu_2004_cis_require_rsyncd_server: false

# Auf `true` setzen, wenn ein NIS-Server benötigt wird.
ubuntu_2004_cis_require_nis_server: false

# Auf `true` setzen, wenn ein NIS-Client benötigt wird.
ubuntu_2004_cis_require_nis_client: false

# Auf `true` setzen, wenn ein RSH-Client benötigt wird.
ubuntu_2004_cis_require_rsh_client: false

# Auf `true` setzen, wenn ein TALK-Client benötigt wird.
ubuntu_2004_cis_require_talk_client: false

# Auf `true` setzen, wenn ein TELNET-Client benötigt wird.
ubuntu_2004_cis_require_telnet_client: false

# Auf `true` setzen, wenn ein LDAP-Client benötigt wird.
ubuntu_2004_cis_require_ldap_client: false

# Auf `true` setzen, wenn ein RPCBIND-Client benötigt wird.
ubuntu_2004_cis_require_rpcbind_client: false

5. Abhängigkeiten

Keine

6. Beispiel-Playbooks:

Beispiel-Playbooks sind im Ordner playbook-examples bereitgestellt. Es enthält Playbooks mit Standard- und angepassten Anforderungen.

HINWEIS: Da einige der CIS-Kontrollen im Bereich Netzwerk das System beschädigen und den Benutzer möglicherweise daran hindern können, sich wieder am System anzumelden, empfehle ich, dass Sie zuerst das Playbook playbook-examples/playbook_with_custom_firewall_changes.yml anwenden oder testen. Passen Sie den Verbindungstyp und die Hosts im Playbook an Ihre Bedürfnisse an.

Beispiele anwenden:

Wenn Sie eines der bereitgestellten Playbooks im Ordner playbook-examples verwenden, können Sie eines davon auswählen und den folgenden Befehl ausführen, um es anzuwenden:

ansible-playbook playbook_with_defaults.yml

ansible-playbook playbook_with_custom_firewall_changes.yml

ansible-playbook playbook_with_ipv6.yml

ansible-playbook playbook_with_ufw.yml

Wenn Sie Ihr eigenes benutzerdefiniertes Playbook mit dem Namen myplaybook.yml erstellen, können Sie es einfach mit dem folgenden Befehl ausführen.

ansible-playbook myplaybook.yml

Beispiele mit Tags anwenden:

Alle Aufgaben in der Rolle haben Tags, die basierend auf der CIS-Ebene, der规则nummer und der Abschnittsnummer zugewiesen sind. Standardmäßig werden sowohl die Kontrollen der Ebene 1 als auch der Ebene 2 angewendet. Daher können Sie, wenn Sie angepasste Anwendungen für Ebenen, Regelnummern oder Abschnitte ausführen möchten, die folgenden Beispiele verwenden:

Beispiel nur für die Anwendung von Kontrollen der Ebene 1:

ansible-playbook <playbook-name-here>.yml --tags "level_1"

Beispiel nur für die Anwendung von Kontrollen der Ebene 2:

ansible-playbook <playbook-name-here>.yml --tags "level_2"

Beispiel für die Anwendung von Kontrollen eines bestimmten Abschnitts (z. B. Abschnitt 4 des CIS Ubuntu 20.04 Benchmarks):

ansible-playbook <playbook-name-here>.yml --tags "section4"

Beispiel für die Anwendung einer spezifischen Kontrolle (z. B. Kontrolle 6.2.2 des CIS Ubuntu 20.04 Benchmarks):

ansible-playbook <playbook-name-here>.yml --tags "rule_6_2_2"

7. Lokale Entwicklung und CI/CD:

Für die lokale Entwicklung der Rolle cis_ubuntu_2004 führen Sie bitte Folgendes aus:

• Forken Sie das Repository.

• Klonen Sie es lokal.

• Installieren Sie Vagrant auf Ihrem Computer. Installationsanweisungen finden Sie hier oder wenn Sie möchten, können Sie die Rolle darkwizard242.vagrant verwenden, um es zu installieren - aber bitte bestätigen Sie, ob es Ihr Betriebssystem unterstützt.

• Installieren Sie VirtualBox auf Ihrem Computer. Installationsanweisungen sind hier verfügbar oder wenn Sie möchten, können Sie die Rolle darkwizard242.virtualbox verwenden, um es zu installieren - aber bitte bestätigen Sie, ob es Ihr Betriebssystem unterstützt.

• Installieren Sie die erforderlichen Module mit:

  # Um pip-Module global zu installieren, wenn Sie als kein root-Benutzer ausführen.
  sudo -H python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

  ODER

  # Um pip-Module lokal im Benutzerverzeichnis zu installieren, wenn Sie als kein root-Benutzer ausführen.
  python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

• Nehmen Sie Änderungen vor und führen Sie molecule test oder molecule converge aus.

molecule test-Befehl führt die gesamte Suite der konfigurierten Molekül-Testsequenz aus.

molecule converge-Befehl erstellt nur die Vagrant-Instanz und wendet alle Operationen an, die in der Rolle definiert sind.

Natürlich können Sie auch einfach den Code für die Rolle cis_ubuntu_2004 herunterladen, Änderungen vornehmen und sie über ansible-playbook auf einer Testbox ausführen, wenn Sie mit molecule nicht vertraut sind.

Wenn Sie einen Pull Request erstellen - wird automatisch ein TravisCI-Build hier ausgelöst. Die Konfiguration für den TravisCI-Build befindet sich in .travis.yml. Dies führt verschiedene Aufgaben aus:

• Klonen Sie den Code aus der Pull-Anfrage.
• Führen Sie ein Update des Repository-Caches durch.
• Installieren Sie die erforderlichen Pakete.
• Installieren Sie Vagrant und Virtualbox.
• Führen Sie einen SonarCloud-Codequalitätscheck für den gesamten Codebasis des Repositories aus.
• Führen Sie den Molecule-Test aus (was eine Vagrant-Box bereitstellt, den Rollencode anwendet und die TestInfra-Test-Suite für die Rolle cis_ubuntu_2004 ausführt).

8. Mitwirkung:

Beiträge sind sehr willkommen. Die Anleitungen zum Beitrag sind hier aufgeführt.

Inspiration

Inspiriert von der großartigen Arbeit vieler Mitglieder der Ansible-Community (namentlich Florian Utz und ansible-lockdown, um nur einige wenige zu nennen). Mach weiter so :metal:

Lizenz

MIT

Author-Informationen

Diese Rolle wurde von Ali Muhammad erstellt.