Libral은 시스템 리소스와 서비스에 대한 통합 관리 API를 제공합니다!

소개	Unix를 계승한 전통적인 Linux 운영 체제로서 포괄적인 시스템 관리 API 인터페이스가 없습니다. 반대로 관리 작업은 각각 고유한 규칙과 규칙이 있는 다양한 특정 목적의 도구와 API를 통해 구현됩니다. 독특한 스타일. 이로 인해 간단한 시스템 관리 작업에 대한 스크립트 작성도 어렵고 취약해집니다.

예를 들어 "app" 사용자의 로그인 셸을 변경하려면 usermod -s /sbin/nologin app를 실행하세요. 이 명령은 시스템에 "app" 사용자가 없는 경우를 제외하고 일반적으로 잘 작동합니다. 이 예외 오류를 해결하기 위해 혁신적인 스크립트 작성자는 다음과 같이 작성할 수 있습니다.

으아아아

이런 방식으로 시스템에 "앱" 사용자가 있으면 로그인 셸을 변경하는 작업이 수행되고, 이 사용자가 없으면 이 사용자가 생성됩니다. 불행하게도 시스템 관리 작업을 스크립팅하는 이러한 방식은 부적절합니다. 각 리소스에는 서로 다른 도구 세트가 있고 각각 고유한 사용 규칙이 있습니다. 완전한 오류 보고로 인해 오류 처리가 더욱 어려워집니다. 또한 도구 자체의 특성으로 인한 오류로 인해 실행 실패가 발생할 수도 있습니다.

사실 위의 예도 올바르지 않습니다. grep은 "app" 사용자를 찾는 데 사용되지 않습니다. 단순히 /etc/passwd 파일의 일부 줄에 "app" 문자열이 있는지 여부만 찾을 수 있습니다. 대부분의 경우 가장 중요한 순간에 문제가 발생할 수 있습니다.

분명히 단순한 작업을 수행하는 스크립트 관리 도구는 대규모 관리 시스템의 기초가 될 수 없습니다. 이를 인식하면 Puppet, Chef 및 Ansible과 같은 기존 구성 관리 시스템은 기본 운영 체제 리소스 관리를 중심으로 내부 API를 구축하기 위해 많은 노력을 기울이는 것이 현명할 것입니다. 이러한 리소스 추상화는 필요한 해당 도구와 밀접하게 연결된 내부 API입니다. 그러나 이로 인해 작업이 많이 중복될 뿐만 아니라 새롭고 혁신적인 관리 도구를 시도하는 데 강력한 장벽이 됩니다.

가상 머신 또는 컨테이너 이미지 생성 분야에서 이러한 장애물은 매우 분명해집니다. 예를 들어 이미지 생성 과정에서 이미지에 대한 간단한 질문에 답하거나 간단한 변경을 수행해야 합니다. 그러나 모든 도구에는 특별한 처리가 필요하며 발생한 문제와 변경 사항은 스크립트를 사용하여 하나씩 처리해야 합니다. 따라서 이미지 구축에는 특정 스크립트에 의존하거나 상당히 강력한 구성 관리 시스템의 사용(및 설치)이 필요합니다.

Libral은 시스템 리소스에 대한 공통 관리 API를 제공하고 이를 명령줄 도구인 ralsh를 통해 사용할 수 있도록 하여 관리 도구 및 작업에 대한 안정적인 보장을 제공합니다. 이를 통해 사용자는 동일한 방식으로 시스템 리소스를 쿼리하고 수정할 수 있으며 예측할 수 있습니다. 오류 보고서. 위의 예에서는 ralsh -aq user app 명령을 사용하여 "app" 사용자가 존재하는지 확인할 수 있습니다. 일반적으로 "foo" 소프트웨어 패키지가 설치되었는지 확인하려면 ralsh -aq package foo 명령을 사용하십시오. ralsh -aq TYPE NAME 명령을 사용할 수 있습니다. "NAME"이 "TYPE" 유형의 리소스인지 확인하세요. 마찬가지로 기존 사용자를 생성하거나 변경하려면 다음을 실행하세요.

으아아아

또한 /etc/hosts 파일에서 항목을 생성하고 수정하려면 다음 명령을 실행할 수 있습니다.

으아아아

이런 방식으로 실행하면 "ralsh" 사용자는 실제로 두 명령 내부의 다양한 작업 메커니즘으로부터 완전히 격리됩니다. 첫 번째 명령에는 useradd 또는 usermod 명령에 대한 적절한 호출이 필요하고 두 번째 명령에는 적절한 useradd 명령이 필요합니다. 또는 usermod.conf를 편집하십시오. 이 사용자의 경우 모두 동일한 모델을 채택하는 것 같습니다. "리소스가 필요한 상태인지 확인하세요."

Libral을 어떻게 구하고 사용하나요? Libral은 이 Git 저장소에서 찾아 다운로드할 수 있습니다. 코어는 C++로 작성되었으며 이를 빌드하기 위한 지침은 이 저장소에서 찾을 수 있지만 Libral의 C++ 코어에 기여하려는 경우에만 이를 살펴보면 됩니다. Libral의 웹사이트에는 "glibc 2.12" 이상을 사용하는 모든 Linux 시스템에서 사용할 수 있는 사전 구축된 tarball이 포함되어 있습니다. 이 "tarball"의 내용은 ralsh를 더 자세히 탐색하고 Libral이 새로운 유형의 리소스를 관리할 수 있도록 하는 새로운 공급자를 개발하는 데 사용될 수 있습니다.

타르볼을 다운로드하고 압축을 푼 후 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에 내장할 수 있습니다. 지금까지 세 가지 호출 규칙이 있습니다:

• 간단한 호출 규칙은 관리자로서 쉘 스크립트를 작성하는 것입니다.
• JSON 호출 규칙은 Ruby 또는 Python 스크립팅 언어를 사용하여 관리자를 작성할 수 있음을 의미합니다.
• [내부 C++ API8을 사용하여 기본 관리자를 구현할 수 있습니다.

관리자 개발을 시작하려면 "단순" 또는 "JSON" 호출 규칙을 사용하는 것이 좋습니다. GitHub의 simple.prov 파일에는 자체 관리자로 쉽게 교체할 수 있는 간단한 셸 관리자 프레임워크가 포함되어 있습니다. python.prov 파일에는 Python으로 작성된 JSON 관리자 프레임워크가 포함되어 있습니다.

고급 스크립팅 언어로 작성된 관리자의 문제점은 이러한 언어의 경우 실행 환경에 현재 Libral을 실행 중인 시스템의 모든 지원 라이브러리가 포함되어야 한다는 것입니다. 어떤 경우에는 이것이 장벽이 되지 않습니다. 예를 들어 "yum" 기반 패키지 관리자는 "yum"이 Python으로 개발되었으므로 현재 시스템에 Python을 설치해야 합니다.

그러나 모든 관리 시스템에 Bourne Shell(Bash) 이외의 디자인 언어를 설치할 수 있을 것으로 예상되지 않는 경우가 많습니다. 관리자 작성자에게는 보다 강력한 스크립트 컴파일 환경이 실제로 필요한 경우가 많습니다. 그러나 기대와는 달리 Ruby나 Python 전체를 바인딩하여 인터프리터로 실행하게 되면 실제 사용 환경의 리소스 제한을 넘어 Libral의 크기가 증가하게 됩니다. 반면에 내장 가능한 스크립트 편집 언어로 Lua 또는 JavaScript를 일반적으로 선택하는 것은 이 환경에 적합하지 않습니다. 왜냐하면 대부분의 관리자 작성자가 이에 익숙하지 않고 일반적으로 시스템 관리 요구 사항을 충족하기 위해 많은 작업이 필요하기 때문입니다. .실수요.

Libral에는 관리자 작성자에게 안정적인 기반과 강력한 구현 가능한 프로그래밍 언어를 제공하는 Ruby의 작은 임베디드 버전인 mruby 버전이 번들로 제공됩니다. mruby는 비록 표준 라이브러리 지원이 훨씬 줄어들었지만 Ruby 언어를 완벽하게 구현한 것입니다. Libral을 사용한 mruby 바인딩에는 스크립팅 관리 작업을 위한 Ruby의 중요한 표준 라이브러리 대부분이 포함되어 있으며 관리자 작성자의 요구에 따라 시간이 지남에 따라 향상될 것입니다. Libral의 mruby는 쓰기 관리자를 JSON 규칙에 더 적합하게 만들기 위해 API 어댑터를 번들로 제공합니다. 예를 들어 JSON 구문 분석 및 출력 규칙을 해결하기 위한 간단한 도구(예: 구조 파일을 컴파일하고 수정하는 Augeas)가 포함되어 있습니다. mruby.prov 파일에는 mruby로 작성된 JSON 관리자 프레임워크의 인스턴스가 포함되어 있습니다.

다음 단계

Libral의 가장 중요한 다음 단계는 Libral을 널리 사용할 수 있도록 하는 것입니다. 미리 컴파일된 tarball에서 시작하는 것은 개발 관리자를 시작하고 심화하는 좋은 방법이지만 Libral은 주류 배포판에 패키징되어 사용되어야 합니다. 위에서 찾을 수 있습니다. . 마찬가지로 Libral의 성능은 함께 제공되는 관리자 집합에 따라 달라지며 핵심 관리 기능 집합을 포괄하도록 확장되어야 합니다. Libral의 웹사이트에는 관리자의 가장 긴급한 요구 사항을 나열하는 할 일 목록이 포함되어 있습니다.

이제 다양한 목적으로 Libra의 유용성을 향상시킬 수 있는 방법이 많이 있습니다. 예를 들어 Python 또는 Go와 같은 더 많은 프로그래밍 언어에 대한 바인딩을 작성하는 것부터 기존의 사람이 읽을 수 있는 것 외에도 쉘 스크립트에서 ralsh를 더 쉽게 사용할 수 있게 만드는 것까지; 출력 및 JSON 출력 외에도 출력은 쉘 스크립트에서 쉽게 형식화될 수 있습니다. 위에서 설명한 원격 API를 추가하면 Libral을 사용하여 일괄 설치 요구 사항을 더 효과적으로 지원할 수 있습니다. 검색된 대상 시스템 아키텍처에 대해

Libral, 해당 API 및 기능은 계속 발전하고 발전할 수 있습니다. 한 가지 흥미로운 가능성은 API에 경고 기능을 추가하여 해당 범위 밖의 리소스에 대한 시스템 변경 사항을 보고할 수 있다는 것입니다. Libral의 과제는 계속 증가하는 사용 사례에 맞춰 작고 가벼우며 잘 정의된 도구를 유지하고 성능을 관리하는 것입니다. 모든 독자가 이 여정에 참여할 수 있기를 바랍니다.

---

위 내용은 Libral은 시스템 리소스와 서비스에 대한 통합 관리 API를 제공합니다!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!