Libral bietet eine einheitliche Verwaltungs-API für Systemressourcen und -dienste!

Um beispielsweise die Login-Shell des „App“-Benutzers zu ändern, führen Sie usermod -s /sbin/nologin app aus. Dieser Befehl funktioniert normalerweise einwandfrei, es sei denn, es gibt keinen „App“-Benutzer auf dem System. Um diesen Ausnahmefehler zu beheben, könnte ein innovativer Drehbuchautor schreiben:

grep -q app /etc/passwd \
&& usermod -s /sbin/nologin app \
|| useradd ... -s /sbin/nologin app

Wenn der Benutzer „App“ im System vorhanden ist, wird der Vorgang zum Ändern der Anmeldeshell ausgeführt. Wenn dieser Benutzer nicht vorhanden ist, wird dieser Benutzer erstellt. Leider ist diese Art der Skripterstellung für Systemverwaltungsaufgaben unzureichend: Für jede Ressource gibt es unterschiedliche Verwendungskonventionen und es kommt zu häufigen Inkonsistenzen, die die Fehlerbehandlung erschweren kann auch zu Ausführungsfehlern aufgrund von Fehlern führen, die durch die Eigenschaften des Werkzeugs selbst verursacht werden.

Tatsächlich ist das obige Beispiel auch falsch: grep wird nicht verwendet, um den „app“-Benutzer zu finden. Es kann nur herausfinden, ob die Zeichenfolge „app“ in einigen Zeilen der Datei /etc/passwd vorhanden ist Meistens kann es aber in den kritischsten Momenten schief gehen.

Offensichtlich können diese Skriptverwaltungstools, die einfache Aufgaben ausführen, kaum die Grundlage eines groß angelegten Verwaltungssystems werden. Angesichts dieser Tatsache wäre es für bestehende Konfigurationsmanagementsysteme wie Puppet, Chef und Ansible ratsam, große Anstrengungen zu unternehmen, um ihre internen APIs rund um die Verwaltung grundlegender Betriebssystemressourcen aufzubauen. Bei diesen Ressourcenabstraktionen handelt es sich um interne APIs, die eng mit den entsprechenden erforderlichen Tools verknüpft sind. Dies führt jedoch nicht nur zu einer Menge Doppelarbeit, sondern stellt auch eine starke Hürde dar, ein neues und innovatives Managementtool auszuprobieren.

Im Bereich der Erstellung von Images für virtuelle Maschinen oder Container wird dieses Hindernis sehr deutlich: Beispielsweise müssen Sie beim Erstellen von Images entweder einfache Fragen dazu beantworten oder einfache Änderungen daran vornehmen. Die Tools erfordern jedoch alle eine spezielle Handhabung, und die auftretenden Probleme und Änderungen müssen einzeln mithilfe von Skripts behandelt werden. Daher ist die Image-Erstellung entweder auf bestimmte Skripte angewiesen oder erfordert die Verwendung (und Installation) eines recht leistungsfähigen Konfigurationsverwaltungssystems.

Libral bietet eine zuverlässige Garantie für Verwaltungstools und -aufgaben, indem es eine gemeinsame Verwaltungs-API für Systemressourcen bereitstellt und diese über das Befehlszeilentool ralsh verfügbar macht. Dadurch können Benutzer Systemressourcen auf die gleiche Weise abfragen und ändern Fehlerberichte. Für das obige Beispiel können Sie den Befehl ralsh -aq user app verwenden, um zu überprüfen, ob der Benutzer „app“ existiert. Verwenden Sie den Befehl ralsh -aq package foo, um zu überprüfen, ob das Softwarepaket „foo“ im Allgemeinen installiert wurde Sie können den Befehl ralsh -aq TYPE NAME verwenden. Überprüfen Sie, ob „NAME“ eine Ressource vom Typ „TYPE“ ist. Um einen vorhandenen Benutzer zu erstellen oder zu ändern, führen Sie auf ähnliche Weise Folgendes aus:

ralsh user app home=/srv/app shell=/sbin/nologin

Um Einträge in der Datei /etc/hosts zu erstellen und zu ändern, können Sie außerdem den folgenden Befehl ausführen:

ralsh hostmyhost.example.com ip=10.0.0.1 \
host_aliases=myhost,apphost

Auf diese Weise ist der Benutzer von „ralsh“ tatsächlich vollständig von den unterschiedlichen Arbeitsmechanismen innerhalb dieser beiden Befehle isoliert: Der erste Befehl erfordert den entsprechenden Aufruf des Befehls useradd oder usermod, während der zweite Befehl den entsprechenden Befehl useradd erfordert oder usermod. Bearbeiten Sie die Datei /etc/hosts. Für diesen Benutzer scheinen sie alle das gleiche Modell zu übernehmen: „Stellen Sie sicher, dass sich die Ressource in dem Zustand befindet, den ich benötige.“

通过消除大型配置管理系统中包含的应用程序逻辑，Libral 从前面介绍里提及的简单的脚本任务，到作为构建复杂的管理应用的构建块，它在如何使用方面是非常灵活的。专注与这些基础层面也使其保持很小，目前不到 2.5 MB，这对于资源严重受限的环境，如容器和小型设备来说是一个重要考虑因素。

在过去的十年里，Libral API 是在实现配置管理系统的经验下指导设计的，虽然它并没有直接绑定到它们其中任何一个应用上，但它考虑到了这些问题，并规避了它们的缺点。

在 API 设计中四个重要的原则：

• 期望的状态
• 双向性
• 轻量级抽象
• 易于扩展

基于期望状态的管理 API，举个例子来说，用户表示当操作执行后希望系统看起来是什么状态，而不是怎样进入这个状态，这一点什么争议。双向性使得使用（读、写）相同的 API 成为可能，更重要的是，相同的资源可以抽象成读取现有状态和强制修改成这种状态。轻量级抽象行为确保能容易的学习 API 并能快速的使用；过去在管理 API 上的尝试过度加重了学习建模框架的使用者的负担，其中一个重要的因素是他们的接受力缺乏。

最后，它必须易于扩展 Libral 的管理功能，这样用户可以教给 Libral 如何管理新类型的资源。这很重要，因为人们也许要管理的资源可能很多（而且 Libral 需要在适当时间进行管理），再者，因为即使是完全成熟的 Libral 也总是存在达不到用户自定义的管理需求。

目前与 Libral API 进行交互的主要方式是通过 ralsh 命令行工具。它也提供了底层的 C++ API ，不过其仍处在不断的演变当中，主要的还是为简单的脚本任务做准备。该项目也提供了为 CRuby 提供语言绑定，其它语言也在陆续跟进。

未来 Libral 还将提供一个提供远程 API 的守护进程，它可以做为管理系统的基础服务，而不需要在管理节点上安装额外的代理。这一点，加上对 Libral 管理功能的定制能力，可以严格控制系统的哪些方面可以管理，哪些方面要避免干扰。

举个例子来说，一个仅限于管理用户和服务的 Libral 配置会避免干扰到在节点上安装的包。当前任何现有的配置管理系统都不可能控制以这种方式管理的内容；尤其是，需要对受控节点进行任意的 SSH 访问也会将该系统暴露不必要的意外和恶意干扰。

Libral API 的基础是由两个非常简单的操作构成的：“get” 用来检索当前资源的状态，“set” 用来设置当前资源的状态。理想化地实现是这样的，通过以下步骤：

provider.get(names) -> List[resource]
provider.set(List[update]) -> List[change]

“provider” 是要知道怎样管理的一种资源的对象，就像用户、服务、软件包等等，Libral API 提供了一种查找特定资源的管理器provider的方法。

“get” 操作能够接收资源名称列表（如用户名），然后产生一个资源列表，其本质来说是利用散列的方式列出每种资源的属性。这个列表必须包含所提供名称的资源，但是可以包含更多内容，因此一个简单的 “get” 的实现可以忽略名称并列出所有它知道的资源。

“set” 操作被用来设置所要求的状态，并接受一个更新列表。每个更新可以包含 “update.is”，其表示当前状态的资源，“update.should” 表示被资源所期望的状态。调用 “set” 方法将会让更新列表中所提到的资源成为 “update.should” 中指示的状态，并列出对每个资源所做的更改。

在 ralsh 下，利用 ralsh user root 能够重新获得 “root” 用户的当前状态；默认情况下，这个命令会产生一个用户可读的输出，就像 Puppet 中一样，但是 ralsh 支持 --json 选项，可以生成脚本可以使用的 JSON 输出。用户可读的输出是：

# ralsh user root
user::useradd { 'root':
ensure => 'present',
comment => 'root',
gid => '0',
groups => ['root'],
home => '/root',
shell => '/bin/bash',
uid => '0',
}

类似的，用户也可以用下面的形式修改：

# ralsh user root comment='The superuser'
user::useradd { 'root':
ensure => 'present',
comment => 'The superuser',
gid => '0',
groups => ['root'],
home => '/root',
shell => '/bin/bash',
uid => '0',
}
comment(root->The superuser)

ralsh 的输出列出了 “root” 用户的新状态和被改变的 comment 属性，以及修改了什么内容（在这种情形下单指 comment 属性）。下一秒运行相同的命令将产生同样的输出，但是不会提示修改，因为没有需要修改的内容。

Einen neuen Anbieter für Ralsh zu schreiben ist einfach und erfordert wenig Aufwand, aber dieser Schritt ist entscheidend. Aus diesem Grund bietet Ralsh eine große Anzahl von Aufrufkonventionen, die es ermöglichen, die Implementierungskomplexität des Managers entsprechend den von ihm bereitgestellten Funktionen anzupassen. Der Manager kann ein externes Skript verwenden, das einer bestimmten Aufrufkonvention folgt, oder es kann in C++ implementiert und in Libral integriert werden. Bisher gibt es drei Aufrufkonventionen:

• Die einfache Aufrufkonvention besteht darin, Shell-Skripte als Manager zu schreiben.
• Die JSON-Aufrufkonvention bedeutet, dass Manager mit den Skriptsprachen Ruby oder Python geschrieben werden können.
• [Interne C++ API8 kann zur Implementierung nativer Manager verwendet werden.

Es wird dringend empfohlen, die „einfache“ oder „JSON“-Aufrufkonvention zu verwenden, um mit der Entwicklung von Managern zu beginnen. Die Datei simple.prov auf GitHub enthält ein einfaches Shell-Manager-Framework, das leicht durch Ihren eigenen Manager ersetzt werden kann. Die Datei python.prov enthält das in Python geschriebene JSON-Manager-Framework.

Ein Problem bei Managern, die in höheren Skriptsprachen geschrieben sind, besteht darin, dass die laufende Umgebung für diese Sprachen alle unterstützenden Bibliotheken auf dem System enthalten muss, auf dem derzeit Libral ausgeführt wird. In manchen Fällen stellt dies kein Hindernis dar; zum Beispiel erfordert der „yum“-basierte Paketmanager die Installation von Python auf dem aktuellen System, da „yum“ in Python entwickelt wurde.

Allerdings wird in vielen Fällen nicht erwartet, dass auf allen Managementsystemen eine andere Designsprache als die Bourne-Shell (Bash) installiert werden kann. Oftmals ist eine leistungsfähigere Skriptkompilierungsumgebung für Managerautoren eine praktische Notwendigkeit. Entgegen den Erwartungen führt die Bindung eines vollständigen Ruby oder Python zur Ausführung als Interpreter jedoch zu einer Vergrößerung von Libral über die Ressourcengrenze der tatsächlichen Nutzungsumgebung hinaus. Andererseits ist die übliche Wahl von Lua oder JavaScript als einbettbare Skriptbearbeitungssprache für diese Umgebung nicht geeignet, da die meisten Autoren von Managern damit nicht vertraut sind und in der Regel viel Arbeit erforderlich ist, um die Anforderungen der Systemverwaltung zu erfüllen . Tatsächlicher Bedarf.

Libral wird mit einer Version von mruby geliefert, einer kleinen, eingebetteten Version von Ruby, die Manager-Autoren eine stabile Grundlage und eine leistungsstarke, umsetzbare Programmiersprache bietet. mruby ist eine vollständige Implementierung der Ruby-Sprache, allerdings mit deutlich eingeschränkter Standardbibliotheksunterstützung. Das mit Libral gebündelte mruby enthält die meisten wichtigen Standardbibliotheken von Ruby für Skriptverwaltungsaufgaben, die im Laufe der Zeit basierend auf den Anforderungen von Manager-Autoren erweitert werden. Der mruby von Libral bündelt API-Adapter, um den Schreibmanager besser für JSON-Konventionen geeignet zu machen. Er enthält beispielsweise einfache Tools (wie Augeas, die Strukturdateien kompilieren und ändern), um die Konvention des Parsens und Ausgebens von JSON zu lösen. Die Datei mruby.prov enthält eine Instanz des in mruby geschriebenen JSON-Manager-Frameworks.

Der wichtigste nächste Schritt für Libral besteht darin, es allgemein verfügbar zu machen – der Start mit einem vorkompilierten Tarball ist ein guter Weg, um den Entwicklungsmanager zu starten und zu vertiefen, aber Libral muss auch auf Mainstream-Distributionen gepackt und in verwendet werden. Dies ist oben zu finden . Ebenso hängt die Leistungsfähigkeit von Libral von der Gruppe der enthaltenen Manager ab und muss erweitert werden, um eine Reihe zentraler Verwaltungsfunktionen abzudecken. Auf der Website von Libral gibt es eine Aufgabenliste, in der die dringendsten Bedürfnisse von Managern aufgeführt sind.

Es gibt mittlerweile viele Möglichkeiten, die Benutzerfreundlichkeit von Libra für verschiedene Zwecke zu verbessern: vom Schreiben von Bindungen für weitere Programmiersprachen, zum Beispiel Python oder Go, bis hin zur einfacheren Verwendung von Ralsh in Shell-Skripten zusätzlich zum vorhandenen, für Menschen lesbaren In Zusätzlich zur Ausgabe und JSON-Ausgabe kann die Ausgabe einfach in einem Shell-Skript formatiert werden. Die Verwendung von Libral bei der Verwaltung großer Mengen kann auch durch das Hinzufügen der oben beschriebenen Remote-API verbessert werden. Dabei werden Transporttools wie SSH genutzt, um die Batch-Installationsanforderungen besser zu unterstützen. Für verschiedene Architekturen werden vorkompilierte Tarballs und Skripte bereitgestellt basierend auf der ermittelten Zielsystemarchitektur.

Libral, seine API und seine Fähigkeiten können sich weiterentwickeln und weiterentwickeln; eine interessante Möglichkeit besteht darin, der API Warnfunktionen hinzuzufügen, die dem System Änderungen an Ressourcen melden können, die außerhalb ihres Umfangs liegen. Die Herausforderung für Libral besteht darin, kleine, leichte und klar definierte Tools für ständig wachsende Anwendungsfälle bereitzustellen und die Leistung zu verwalten – ich hoffe, dass jeder Leser Teil dieser Reise sein kann.

Das obige ist der detaillierte Inhalt vonLibral bietet eine einheitliche Verwaltungs-API für Systemressourcen und -dienste!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!