Ansible Rolle :computer: :link: Geth

Inhaltsverzeichnis

• Unterstützte Plattformen
• Voraussetzungen
• Rollenvaiablen
  • Installation
  • Konfiguration
  • Start
  • Deinstallation
• Abhängigkeiten
• Beispiel-Playbook
• Lizenz
• Autoreninformationen

Ansible Rolle, die Geth installiert, konfiguriert und ausführt: eine Kommandozeilenoberfläche und API-Server für den Betrieb eines Ethereum-Knotens.

Unterstützte Plattformen:

* Debian
* MacOS
* Redhat (CentOS/Fedora)
* Ubuntu

Voraussetzungen

Benötigt das Dienstprogramm unzip/gtar, das auf dem Zielhost installiert sein muss. Siehe die Anmerkungen im Ansible unarchive Modul hier für Details.

Rollenvaiablen

Variablen sind verfügbar und nach den folgenden Phasen der Software- und Maschinenbereitstellung organisiert:

• installation
• konfiguration
• start
• deinstallation

Installation

geth kann über die Paketverwaltungssysteme des Betriebssystems (z.B. apt, homebrew) oder über komprimierte Archive (.tar, .zip) installiert werden, die aus verschiedenen Quellen heruntergeladen und entpackt werden.

Die folgenden Variablen können angepasst werden, um verschiedene Aspekte des Installationsprozesses zu steuern, von der Softwareversion und dem Speicherort der Binärdateien bis hin zum Installationsverzeichnis, in dem sie gespeichert werden:

geth_user: <service-user-name> (Standard: geth)

• dedizierter Dienstbenutzer und Gruppe, die von geth zur Trennung von Berechtigungen verwendet werden (siehe hier für Details)

install_type: <package | archive> (Standard: archive)

• package: NUR unterstützt von Ubuntu und MacOS. Die Paketinstallation von Geth bezieht das neueste Paket, das für jede Plattform aus dem Ubuntu PPA (Persönliches Paketarchiv) oder dem Mac Homebrew Formeln Repository.
  • Beachten Sie, dass das Installationsverzeichnis vom Paketverwaltungssystem bestimmt wird und derzeit standardmäßig auf /usr/bin/geth für Linux und /usr/local/bin/geth für MacOS eingestellt ist.
• archive: kompatibel mit tar und zip Formaten. Bei der Archivinstallation können die Binärdateien aus lokalen und entfernten komprimierten Archiven von der offiziellen Download-/Release-Seite oder von eigenen, entwickelten oder benutzerdefinierten Versionen des Tools bezogen werden.

archive_url: <path-or-url-to-archive> (Standard: siehe defaults/main.yml)

• Adresse eines komprimierten tar oder zip Pakets, das die geth Binärdateien enthält. Diese Methode unterstützt technisch die Installation jeder verfügbaren Version von geth. Links zu offiziellen Versionen finden Sie hier.

install_dir: </path/to/installation/dir> (Standard: siehe defaults/main.yml | vars/...)

• Pfad auf dem Zielhost, wohin die geth Binärdateien extrahiert werden sollen.

Konfiguration

Die Konfiguration des geth Clients kann in einer Konfigurationsdatei, die in TOML geschrieben ist, ausgedrückt werden. Diese minimalistische Markupsprache wird als Alternative zum Übergeben von Kommandozeilen-Flags zur Laufzeit verwendet. Um eine Vorstellung davon zu bekommen, wie die Konfigurationsdatei aussehen sollte, können Sie den Befehl geth dumpconfig verwenden, um die bestehende Konfiguration eines Clients zu exportieren.

Die folgenden Variablen können angepasst werden, um den Ort und den Inhalt dieser TOML-Konfiguration zu verwalten:

config_dir: </path/to/configuration/dir> (Standard: /etc/geth)

• Pfad auf dem Zielhost, wo die geth TOML-Konfiguration gespeichert werden sollte.

geth_config: {"<config-section>": {"<section-setting>": "<setting-value>",..},..} Standard: siehe defaults/main.yml

• Jedes Konfigurationseinstellung/Wert-Paar, das von geth unterstützt wird, sollte innerhalb des geth_config Hashs ausdrückbar sein und entsprechend in der zugehörigen TOML-Konfiguration dargestellt werden. Werte können in typischer yaml/ansible Form ausgedrückt werden (z.B. Strings, Zahlen und true/false Werte sollten so geschrieben werden, wie sie sind, ohne Anführungszeichen).

  Darüber hinaus ist die Konfiguration nicht durch fest kodierte von Autoren definierte Standardwerte oder durch vorgefertigte Vorlagen eingeschränkt. Wenn der Konfigurationsabschnitt, die Einstellung und der Wert von dem geth Tool erkannt werden, :thumbsup: definiert innerhalb von geth_config.

  Eine Liste von konfigurierbaren Einstellungen finden Sie hier.

  Die Schlüssel des geth_config Hashs repräsentieren TOML Konfigurationsabschnitte:

  geth_config:
    # [TOML Abschnitt 'Shh']
    Shh: {}
  

  Werte von geth_config[<key>] repräsentieren Schlüssel-Werte-Paare innerhalb eines eingebetteten Hashs, der Konfigurationseinstellungen ausdrückt:

  geth_config:
    # TOML Abschnitt '[Shh]'
    Shh:
      # Abschnittseinstellung MaxMessageSize mit dem Wert von 1048576
      MaxMessageSize: 1048576
  

Start

Das Ausführen des geth Clients und des API-Servers, entweder in seiner RPC-, IPC- oder WS-RPC-Form, erfolgt mit den Service-Management-Tools systemd oder launchd für Linux- und MacOS-Plattformen. Sie werden als Hintergrundprozesse oder Daemons gestartet, die den Konfigurationen und Ausführungsmöglichkeiten entsprechen, die von den zugrunde liegenden Verwaltungsframeworks bereitgestellt werden. Der geth Client und die API-Server können so konfiguriert werden, dass sie den administrativen Richtlinien des Systems entsprechen, die für Ihre Umgebung und Organisation geeignet sind.

Die folgenden Variablen können angepasst werden, um das Ausführungsprofil/ die Ausführungsrichtlinien von Geth zu steuern:

extra_run_args: <geth-cli-options> (Standard: siehe defaults/main.yml)

• Liste der geth Kommandozeilenargumente, die zur Laufzeit an die Binärdatei übergeben werden, um den Start anzupassen.

Diese Variable ermöglicht die vollständige Ausdrucksform von geth's cli und ermöglicht es der Rolle des Zielhosts, entsprechend der Spezifikation des Benutzers angepasst zu werden; ob es darum geht, einen bestimmten API-Protokollhörer zu aktivieren, sich mit einem vorkonfigurierten Ethereum-Test- oder Produktionsnetzwerk zu verbinden oder was auch immer von geth unterstützt wird.

Eine Liste der verfügbaren Kommandozeilenoptionen finden Sie hier.

Beispiele

Verbinden Sie sich entweder mit dem Ropsten PoW (Proof of Work) oder dem Rinkeby PoA (Proof of Authority) vorkonfigurierten Testnetzwerk:

extra_run_args:
  - '--ropsten' # PoW
# ...oder...
extra_run_args:
  - '--rinkeby' # PoA

Verbessern Sie die Protokollierungs- und Debugging-Funktionen zum Troubleshooting:

extra_run_args:
  - --debug
  - '--verbosity 5'
  - '--trace /tmp/geth.trace'

Aktivieren Sie die Profilierung von Client und Server für Analyse- und Testzwecke:

extra_run_args:
  - --pprof
  - '--memprofilerate 1048576'
  - '--blockprofilerate 1'
  - '--cpuprofile /tmp/geth-cpu-profile'

custom_unit_properties: <hash-of-systemd-service-settings> (Standard: [])

• Hash von Einstellungen zur Anpassung der [Service] Einheitenskonfiguration und der Ausführungsumgebung des Geth systemd Dienstes.

Deinstallation

Die Unterstützung für die Deinstallation und das Entfernen von Artefakten, die zur Bereitstellung erforderlich sind, ermöglicht es Benutzern/Betriebsmitarbeitern, einen Zielhost in den konfigurierten Zustand vor der Anwendung dieser Rolle zurückzuversetzen. Dies kann nützlich sein, um Knoten und Rollen wiederzuverwerten und möglicherweise eine sanftere/gesteuerte Übergänge zwischen Tool-Upgrades zu bieten.

Die folgenden Variablen können angepasst werden, um diesen Deinstallationsprozess zu verwalten:

perform_uninstall: <true | false> (Standard: false)

• ob alle Artefakte und Überreste dieser geth Installation auf einem Zielhost deinstalliert und entfernt werden sollen (siehe: handlers/main.yml für Details)

Abhängigkeiten

• 0x0i.systemd

Beispiel-Playbook

Grundlegende Einrichtung mit Vorgaben:

- hosts: all
  roles:
  - role: 0x0I.geth

Starten Sie einen Ethereum Light-Client und verbinden Sie ihn mit dem Rinkeby PoA (Proof of Authority) Testnetzwerk:

- hosts: light-client
  roles:
  - role: 0x0I.geth
    vars:
      geth_config:
        Eth:
          SyncMode: light
      extra_run_args:
        - --rinkeby

Führen Sie einen vollständigen Ethereum-Knoten im "fast" Synchronisationsmodus aus (verarbeitet nur die letzten Transaktionen), aktiviert sowohl die RPC-Serveroberfläche als auch den Client-Miner und überschreibt das (Block-)Dataverzeichnis:

- hosts: full-node
  roles:
  - role: 0x0I.geth
    vars:
      geth_config:
        Eth:
          SyncMode: fast
        Node:
          DataDir: /mnt/geth
      extra_run_args:
        - --rpc
        - --nousb
        - '--rpcaddr="12.34.56.789"'
        - '--mine --miner.threads 16'

Lizenz

MIT

Autoreninformationen

Diese Rolle wurde 2019 von O1.IO erstellt.