Libral は、システム リソースとサービスの統合管理 API を提供します。

＃＃＃導入＃＃＃ Unix を継承した従来の Linux オペレーティング システムには、包括的なシステム管理 API インターフェイスはなく、管理操作はさまざまな専用ツールや API を通じて実装されます。独自の慣例とユニークなスタイル。このため、単純なシステム管理タスクのスクリプトを作成することさえ難しく、脆弱になります。

たとえば、「app」ユーザーのログイン シェルを変更するには、usermod -s /sbin/nologin app を実行します。このコマンドは、システム上に「app」ユーザーが存在しない場合を除いて、通常は正常に機能します。この例外エラーを解決するために、革新的なスクリプト作成者は次のように書くかもしれません:

リーリー

このように、システム内に「app」ユーザーが存在する場合にはログインシェルの変更操作が行われ、このユーザーが存在しない場合にはこのユーザーが作成されます。残念ながら、システム管理タスクをスクリプト化するこの方法は不十分です。リソースごとに異なるツール セットがあり、それぞれに独自の使用規則があるため、不一致や頻繁な不一致が発生します。完全なエラー報告はエラー処理を困難にします。さらに、また、ツール自体の特性に起因する不具合により実行に失敗する場合もあります。

実際には、上記の例も間違っています。grep は "app" ユーザーの検索に使用されません。ファイル /etc/passwd のいくつかの行で文字列 "app" を検索するだけです。」と表示される可能性があります。ほとんどの場合は機能しますが、最も重要な瞬間に問題が発生する可能性もあります。

単純なタスクを実行するスクリプト管理ツールが大規模な管理システムの基盤になることはほとんどありません。これを認識すると、Puppet、Chef、Ansible などの既存の構成管理システムは、基本的なオペレーティング システム リソースの管理を中心とした内部 API を構築するために多大な労力を費やすことが賢明です。これらのリソース抽象化は、必要な対応ツールと密接に結びついている内部 API です。しかし、これにより多くの重複作業が発生するだけでなく、新しく革新的な管理ツールを試すことに対して強力な障壁が生じます。

仮想マシンまたはコンテナイメージの作成の分野では、この障害は非常に明白になります。たとえば、イメージの作成プロセスでは、イメージに関する簡単な質問に答えるか、イメージに簡単な変更を加える必要があります。わかりました。ただし、これらのツールはすべて特別な処理を必要とするため、発生した問題や変更はスクリプトを使用して 1 つずつ処理する必要があります。したがって、イメージの構築は特定のスクリプトに依存するか、かなり強力な構成管理システムの使用 (およびインストール) を必要とします。

Libral は、システム リソースに共通の管理 API を提供し、コマンド ライン ツール ralsh を通じて利用できるようにすることで、管理ツールとタスクの信頼できる保証を提供します。これにより、ユーザーは同じ方法でシステム リソースのクエリと変更を行うことができます。予測可能なエラー報告が可能です。上記の例では、コマンド ralsh -aq user app を使用して「app」ユーザーが存在するかどうかを確認でき、コマンド ralsh -aq package foo を使用して「foo」ソフトウェア パッケージがインストールされているかどうかを確認できます。一般に、コマンド ralsh -aq TYPE NAME を使用できます。 「NAME」がタイプ「TYPE」のリソースかどうかを確認します。同様に、既存のユーザーを作成または変更するには、次を実行します:

リーリー

また、ファイル /etc/hosts 内のエントリを作成および変更するには、次のコマンドを実行します。

リーリー

この方法で実行すると、「ralsh」のユーザーは実際、これら 2 つのコマンド内のさまざまな操作メカニズムから完全に分離されます。最初のコマンドでは useradd または usermod コマンドへの適切な呼び出しが必要ですが、2 番目のコマンドでは編集が必要です。 /etc/hosts ファイル。このユーザーの場合、すべてが同じモデルを採用しているようです。「リソースが必要な状態であることを確認してください。」

Libral の入手方法と使用方法?

Libral は、この git リポジトリで見つけてダウンロードできます。コアは C で書かれており、それを構築する手順はこのリポジトリにありますが、Libral の C コアに貢献したい場合にのみ参照する必要があります。 Libral の Web サイトには、「glibc 2.12」以降を使用する Linux マシンで使用できる、事前に構築された tarball が含まれています。この「tarball」の内容は、ralsh をさらに調査し、Libral が新しいタイプのリソースを管理できるようにする新しいプロバイダーを開発するために使用できます。

tarball をダウンロードして解凍すると、ral/bin ディレクトリに ralsh コマンドが見つかります。パラメータを指定せずに ralsh コマンドを実行すると、すべての Libral リソース タイプがリストされます。 ralsh に関する詳細情報を出力するには、--help オプションを使用します。

構成管理システムとの関係

Puppet、Chef、Ansible などのよく知られた構成管理システムは、Libral が解決するのと同じ問題のいくつかを解決します。 Libral と対応する企業の違いは、主に、彼らが Libral とは異なる仕事をしていることです。構成管理システムは、多数のノードにわたるさまざまなものを管理する多様性と複雑さに対処するために構築されています。一方、Libral は、特定のツールに依存せず、さまざまなプログラミング言語で使用できる、明確に定義された低レベルのシステム管理 API を提供することを目的としています。

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

Libral API

在过去的十年里，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 属性）。下一秒运行相同的命令将产生同样的输出，但是不会提示修改，因为没有需要修改的内容。

ライティングマネージャー

ralsh の新しいプロバイダーの作成は簡単で、それほど手間はかかりませんが、このステップは非常に重要です。このため、ralsh は多数の呼び出し規約を提供し、提供できる機能に応じてマネージャーの実装の複雑さを調整できるようにします。マネージャーは、特定の呼び出し規則に従う外部スクリプトを使用することも、C で実装して Libral に組み込むこともできます。これまでのところ、呼び出し規則は 3 つあります。

• 単純な呼び出し規則は、マネージャーとして使用するシェル スクリプトを作成することです。
• JSON 呼び出し規約は、Ruby または Python スクリプト言語を使用してマネージャーを作成できることを意味します。
• [内部 C API8 を使用してネイティブ マネージャーを実装できます。

マネージャーの開発を開始するには、「単純」または「JSON」呼び出し規則を使用することを強くお勧めします。 GitHub の simple.prov ファイルには、独自のマネージャーと簡単に置き換えることができるシンプルなシェル マネージャー フレームワークが含まれています。 python.prov ファイルには、Python で記述された JSON マネージャー フレームワークが含まれています。

高級スクリプト言語で書かれたマネージャーの問題の 1 つは、これらの言語の実行環境には、現在 Libral を実行しているシステム上のすべてのサポート ライブラリが含まれている必要があることです。場合によっては、これが障壁にならない場合もあります。たとえば、「yum」は Python で開発されているため、「yum」ベースのパッケージ マネージャーでは、現在のシステムに Python がインストールされている必要があります。

ただし、多くの場合、Bourne シェル (Bash) 以外の設計言語をすべての管理システムにインストールできることは期待されていません。多くの場合、マネージャー作成者にとって、より強力なスクリプト コンパイル環境は実際に必要です。ただし、予想に反して、完全な Ruby または Python をバインドしてインタプリタとして実行すると、Libral のサイズが実際の使用環境のリソース制限を超えて増加します。一方、埋め込み可能なスクリプト編集言語として通常選択される Lua または JavaScript は、この環境には適していません。これは、ほとんどの管理者の作成者が Lua または JavaScript に精通しておらず、通常、システム管理の要件を満たすために多大な作業が必要になるためです。 . 実需。

Libral には、mruby のバージョンがバンドルされています。これは、管理者ライターに安定した基盤と強力な実装可能なプログラミング言語を提供する、Ruby の小型の組み込みバージョンです。 mruby は Ruby 言語の完全な実装ですが、標準ライブラリのサポートは大幅に制限されています。 Libral にバンドルされている mruby には、管理タスクをスクリプト化するための Ruby の重要な標準ライブラリのほとんどが含まれており、これらはマネージャー作成者のニーズに基づいて時間の経過とともに強化されます。 Libral の mruby には、JSON 規則に適した書き込みマネージャーを作成するための API アダプターがバンドルされており、たとえば、JSON の解析と出力の規則を解決するための簡単なツール (構造ファイルをコンパイルおよび変更する Augeas など) が含まれています。 mruby.prov ファイルには、mruby で書かれた JSON マネージャー フレームワークのインスタンスが含まれています。

仕事の次のステップ

Libral にとって最も重要な次のステップは、Libral を広く利用できるようにすることです - プリコンパイルされた tarball は、開発マネージャーを開始して深める良い方法ですが、Libral は主流のディストリビューションにパッケージ化する必要もあります。これについては上記を参照してください。同様に、Libral の能力は付属のマネージャーのセットに依存しており、管理機能のコアセットをカバーするには拡張する必要があります。 Libral の Web サイトには、マネージャーの最も差し迫ったニーズをリストした ToDo リストが含まれています。

Libra の使いやすさをさまざまな目的に合わせて向上させる方法はたくさんあります: Python や Go などのより多くのプログラミング言語のバインディングを作成することから、既存のスクリプトに加えて ralsh をシェル スクリプトで使いやすくすることまで人間が判読できる出力と JSON 出力を備えており、出力はシェル スクリプトで簡単にフォーマットできます。大規模な管理での Libral の使用は、上で説明したリモート API を追加することで改善することもできます。Libral は、SSH などのトランスポート ツールを活用して、バッチ インストール要件をより適切にサポートします。さまざまなアーキテクチャ用にコンパイル済みの tarball とスクリプトが提供されています。正しいパッケージを選択してください。発見されたターゲット システム アーキテクチャに基づいて。

Libral、その API、およびその機能は進化し続ける可能性があります。興味深い可能性の 1 つは、API にアラート機能を追加して、その範囲外のリソースに対するシステムの変更を報告できることです。 Libral の課題は、増え続けるユースケースに対して小型、軽量、明確に定義されたツールを維持し、パフォーマンスを管理することです。すべての読者がこの取り組みに参加できることを願っています。

---

以上がLibral は、システム リソースとサービスの統合管理 API を提供します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。