Libral provides a unified management API for system resources and services!

For example, to change the login shell of the "app" user, run usermod -s /sbin/nologin app. This command usually works fine, except when there is no "app" user on the system. To solve this exception error, an innovative script writer might write:

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

In this way, when the "app" user exists in the system, the operation of changing the login shell will be performed; and when this user does not exist, this user will be created. Unfortunately, this way of scripting system administration tasks is inadequate: for each resource there will be a different set of tools, and each has its own usage conventions; inconsistencies and frequent inconsistencies arise. Complete error reporting will make error handling difficult; moreover, it may also lead to execution failure due to faults caused by the characteristics of the tool itself.

Actually, the above example is also incorrect: grep is not used to find the "app" user. It can only simply search for the string "app" in some lines of the file /etc/passwd. ”, it may work in most cases, but it may also go wrong at the most critical moments.

Obviously, those script management tools that perform simple tasks can hardly become the basis of a large-scale management system. Recognizing this, it would be wise for existing configuration management systems, such as Puppet, Chef, and Ansible, to go to great lengths to build their internal APIs around the management of basic operating system resources. These resource abstractions are internal APIs that are closely tied to the corresponding tools required. But this not only results in a lot of duplication of work, but also creates a strong barrier to trying out a new and innovative management tool.

In the field of creating virtual machine or container images, this obstacle becomes very obvious: for example, in the process of creating images, you either need to answer simple questions about them, or you need to make simple changes to them. OK. But the tools all require special handling, and those problems and changes that are encountered need to be handled one by one using scripts. Therefore, image building either relies on specific scripts or requires the use (and installation) of a fairly powerful configuration management system.

Libral will provide a reliable guarantee for management tools and tasks by providing a common management API for system resources and making it available through the command line tool ralsh. It allows users to query and modify system resources in the same way. , and have predictable error reporting. For the above example, you can use the command ralsh -aq user app to check whether the "app" user exists; use the command ralsh -aq package foo to check whether the "foo" software package has been installed; in general, you can use the command ralsh -aq TYPE NAME Check whether "NAME" is a resource of type "TYPE". Similarly, to create or change an existing user, run:

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

Also, to create and modify entries in the file /etc/hosts, you can run the command:

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

Run in this way, the user of "ralsh" is in fact completely isolated from the different operating mechanisms within those two commands: the first command requires the appropriate call to the command useradd or usermod, while the second command Requires editing in the /etc/hosts file. For this user, they all seem to adopt the same model: "Make sure the resource is in the state I need it to be."

Libral can be found and downloaded in this git repository. The core is written in C, and instructions for building it can be found in this repository, but you only need to look at it if you want to contribute to Libral's C core. Libral's website includes a pre-built tarball that can be used on any Linux machine using "glibc 2.12" or higher. The contents of this "tarball" can be used to further explore ralsh and to develop new providers that enable Libral to manage new types of resources.

After downloading and decompressing the tarball, you can find the ralsh command in the directory ral/bin. Running the ralsh command without any parameters will list all Libral resource types. Use the --help option to print out more information about ralsh.

Well-known configuration management systems, such as Puppet, Chef and Ansible, solve some of the same problems that Libral solves. What separates Libral from their counterparts is primarily that they do a different job than Libral. Configuration management systems are built to handle the variety and complexity of managing a variety of things across a large number of nodes. Libral, on the other hand, aims to provide a well-defined low-level system management API that is independent of any specific tool and can be used in a variety of programming languages.

通过消除大型配置管理系统中包含的应用程序逻辑，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 属性）。下一秒运行相同的命令将产生同样的输出，但是不会提示修改，因为没有需要修改的内容。

Writing a new provider for ralsh is easy and doesn't take much effort, but this step is crucial. Because of this, ralsh provides a large number of calling conventions, making it possible to adjust the implementation complexity of the manager according to the capabilities it can provide. The manager can use an external script that follows a specific calling convention, or it can be implemented in C and built into Libral. So far, there are three calling conventions:

• The simple calling convention is to write a shell script to use as a manager.
• The JSON calling convention means managers can be written using Ruby or Python scripting languages.
• [Internal C API8 can be used to implement native managers.

It is strongly recommended to use the "simple" or "JSON" calling convention to start developing managers. The simple.prov file on GitHub contains a simple shell manager framework that should be easy to replace with your own manager. The python.prov file contains the JSON manager framework written in Python.

One problem with managers written in high-level scripting languages ​​is that for these languages, the running environment needs to include all support libraries on the system currently running Libral. In some cases, this is not a barrier; for example, the "yum"-based package manager requires Python to be installed on the current system, since "yum" is developed in Python.

However, in many cases, it is not expected that a design language other than Bourne shell (Bash) can be installed on all management systems. Often, a more powerful script compilation environment is a practical necessity for manager writers. However, contrary to expectations, binding a full Ruby or Python to run as an interpreter will increase the size of Libral beyond the resource limit of the actual use environment. On the other hand, the usual choice of Lua or JavaScript as an embeddable script editing language is not suitable for this environment, because most managers' writers are not familiar with them, and usually require a lot of work to meet the requirements of system management. Actual demand.

Libral comes bundled with a version of mruby, a small, embedded version of Ruby that provides manager writers with a stable foundation and a powerful implementable programming language. mruby is a complete implementation of the Ruby language, albeit with much reduced standard library support. The mruby bindings with Libral contain most of Ruby's important standard libraries for scripting management tasks, and will be enhanced over time based on the needs of manager writers. Libral's mruby bundles API adapters to make the writing manager more suitable for JSON conventions. For example, it includes simple tools (such as Augeas that compile and modify structure files) to solve the convention of parsing and outputting JSON. The mruby.prov file contains an instance of the JSON manager framework written in mruby.

The most critical next step for Libral is to make it widely available - precompiled tarball is a good way to start and deepen the development manager, but Libral also needs to be packaged into mainstream distributions. and can be found above. Likewise, the power of Libral depends on the set of managers it comes with, and needs to be extended to cover a core set of management functions. Libral's website includes a todo list listing managers' most pressing needs.

There are many ways to improve the usability of Libra for different purposes: from writing bindings for more programming languages, for example, Python or Go; to making ralsh easier to use in shell scripts, in addition to the existing In addition to human-readable output and JSON output, the output can be easily formatted in a shell script. The use of Libral in large-scale management can also be improved by adding the remote API discussed above. Libral leverages transport tools like SSH to better support batch installation requirements. Provide pre-compiled tarballs for various architectures, and scripts Select the correct package based on the discovered target system architecture.

Libral, its API, and its capabilities can continue to evolve; one interesting possibility is to add alerting capabilities to the API, which can report to the system changes to resources outside its scope. The challenge for Libral is to keep small, lightweight, and well-defined tools against ever-increasing use cases and manage performance - I hope every reader can be a part of this journey.

The above is the detailed content of Libral provides a unified management API for system resources and services!. For more information, please follow other related articles on the PHP Chinese website!