Liral menyediakan API pengurusan bersatu untuk sumber dan perkhidmatan sistem!

Pengenalan

Sebagai sistem pengendalian Linux tradisional yang mewarisi Unix, ia tidak mempunyai antara muka API pengurusan sistem yang komprehensif Sebaliknya, operasi pengurusan dilaksanakan melalui pelbagai alat dan API tujuan khusus, yang setiap satunya mempunyai konvensyen dan API tersendiri. Gaya yang unik. Ini menjadikan penulisan skrip untuk tugas pentadbiran sistem yang mudah pun sukar dan rapuh.

Sebagai contoh, untuk menukar cangkerang log masuk pengguna “apl”, jalankan apl usermod -s /sbin/nologin. Perintah ini biasanya berfungsi dengan baik, kecuali apabila tiada pengguna "apl" pada sistem. Untuk menyelesaikan ralat pengecualian ini, seorang penulis skrip yang inovatif mungkin menulis:

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

Dengan cara ini, apabila pengguna "apl" wujud dalam sistem, operasi menukar cangkerang log masuk akan dilakukan dan apabila pengguna ini tidak wujud, pengguna ini akan dibuat. Malangnya, cara menskrip tugasan pentadbiran sistem ini tidak mencukupi: untuk setiap sumber akan ada set alat yang berbeza, dan setiap satu mempunyai konvensyen penggunaannya sendiri dan ketidakkonsistenan yang kerap timbul juga boleh menyebabkan kegagalan pelaksanaan disebabkan oleh kerosakan yang disebabkan oleh ciri-ciri alat itu sendiri.

Malah, contoh di atas juga tidak betul: grep tidak digunakan untuk mencari pengguna "aplikasi" Ia hanya boleh mencari sama ada terdapat rentetan "aplikasi" dalam beberapa baris fail /etc/passwd pada kebanyakan masa, tetapi ia mungkin menjadi salah pada saat yang paling kritikal.

Jelas sekali, alatan pengurusan skrip yang melaksanakan tugas mudah tidak boleh menjadi asas kepada sistem pengurusan berskala besar. Menyedari perkara ini, adalah bijak untuk sistem pengurusan konfigurasi sedia ada, seperti Boneka, Chef dan Ansible, berusaha sedaya upaya untuk membina API dalaman mereka di sekitar pengurusan sumber sistem pengendalian asas. Abstraksi sumber ini ialah API dalaman yang berkait rapat dengan alatan sepadan yang diperlukan. Tetapi ini bukan sahaja mengakibatkan banyak pertindihan kerja, tetapi juga mewujudkan halangan yang kuat untuk mencuba alat pengurusan yang baharu dan inovatif.

Dalam bidang mencipta mesin maya atau imej kontena, halangan ini menjadi sangat jelas: sebagai contoh, dalam proses mencipta imej, anda sama ada perlu menjawab soalan mudah mengenainya atau membuat perubahan ringkas padanya. Tetapi semua alatan memerlukan pengendalian khas, dan masalah serta perubahan yang dihadapi itu perlu dikendalikan satu persatu menggunakan skrip. Oleh itu, pembinaan imej sama ada bergantung pada skrip tertentu atau memerlukan penggunaan (dan pemasangan) sistem pengurusan konfigurasi yang cukup berkuasa.

Libral akan memberikan jaminan yang boleh dipercayai untuk alatan pengurusan dan tugasan dengan menyediakan API pengurusan biasa untuk sumber sistem dan menyediakannya melalui ralsh alat baris perintah Ia membolehkan pengguna untuk bertanya dan mengubah suai sumber sistem dengan cara yang sama, dan Terdapat boleh diramal laporan ralat. Untuk contoh di atas, anda boleh menggunakan arahan ralsh -aq aplikasi pengguna untuk menyemak sama ada pengguna "apl" wujud; boleh menggunakan arahan ralsh -aq TYPE NAME Semak sama ada "NAME" ialah sumber jenis "TYPE". Begitu juga, untuk mencipta atau menukar pengguna sedia ada, jalankan:

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

Selain itu, untuk mencipta dan mengubah suai entri dalam fail /etc/hosts, anda boleh menjalankan arahan:

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

Jalankannya dengan cara ini, pengguna "ralsh" secara berkesan diasingkan sepenuhnya daripada mekanisme kerja yang berbeza di dalam kedua-dua arahan tersebut: arahan pertama memerlukan panggilan yang sesuai kepada perintah useradd atau usermod, manakala arahan kedua memerlukan arahan yang sesuai useradd atau usermod. Edit fail /etc/hosts. Bagi pengguna ini, mereka semua nampaknya menggunakan model yang sama: "Pastikan sumber berada dalam keadaan yang saya perlukan

Bagaimana untuk mendapatkan dan menggunakan Libra?

Libral boleh didapati dan dimuat turun dalam repositori git ini. Teras ditulis dalam C++, dan arahan untuk membinanya boleh didapati dalam repositori ini, tetapi anda hanya perlu melihatnya jika anda ingin menyumbang kepada teras C++ Libral. Tapak web Libral termasuk tarball pra-bina yang boleh digunakan pada mana-mana mesin Linux menggunakan "glibc 2.12" atau lebih tinggi. Kandungan "tarball" ini boleh digunakan untuk meneroka lebih lanjut ralsh dan untuk membangunkan penyedia baharu yang membolehkan Libra mengurus jenis sumber baharu.

Selepas memuat turun dan membuka zip tarball, anda boleh mencari arahan ralsh dalam direktori ral/bin. Menjalankan arahan ralsh tanpa sebarang parameter akan menyenaraikan semua jenis sumber Libra. Gunakan pilihan --help untuk mencetak maklumat lanjut tentang ralsh.

Hubungan dengan sistem pengurusan konfigurasi

Sistem pengurusan konfigurasi yang terkenal, seperti Boneka, Chef dan Ansible, menyelesaikan beberapa masalah yang sama yang diselesaikan oleh Libra. Apa yang membezakan Libra daripada rakan sejawatannya ialah mereka melakukan kerja yang berbeza daripada Libra. Sistem pengurusan konfigurasi dibina untuk mengendalikan kepelbagaian dan kerumitan mengurus pelbagai perkara merentasi sejumlah besar nod. Libral, sebaliknya, bertujuan untuk menyediakan API pengurusan sistem peringkat rendah yang jelas dan bebas daripada sebarang alat khusus dan boleh digunakan dalam pelbagai bahasa pengaturcaraan.

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

Pengurus Penulisan

Menulis penyedia baharu untuk ralsh adalah mudah dan memerlukan sedikit usaha, tetapi langkah ini penting. Oleh sebab itu, ralsh menyediakan sejumlah besar konvensyen panggilan yang memungkinkan untuk melaraskan kerumitan pelaksanaan pengurus mengikut keupayaan yang boleh disediakannya. Pengurus boleh menggunakan skrip luaran yang mengikut konvensyen panggilan tertentu, atau ia boleh dilaksanakan dalam C++ dan dibina ke dalam Libral. Setakat ini, terdapat tiga konvensyen panggilan:

• Konvensyen panggilan mudah ialah menulis skrip shell sebagai pengurus.
• Konvensyen panggilan JSON bermakna pengurus boleh ditulis menggunakan bahasa skrip Ruby atau Python.
• [Internal C++ API8 boleh digunakan untuk melaksanakan pengurus asli.

Adalah sangat disyorkan untuk menggunakan konvensyen panggilan "mudah" atau "JSON" untuk mula membangunkan pengurus. Fail simple.prov pada GitHub mengandungi rangka kerja pengurus shell ringkas yang sepatutnya mudah diganti dengan pengurus anda sendiri. Fail python.prov mengandungi rangka kerja pengurus JSON yang ditulis dalam Python.

Masalah dengan pengurus yang ditulis dalam bahasa skrip peringkat tinggi ialah untuk bahasa ini, persekitaran berjalan perlu menyertakan semua perpustakaan sokongan pada sistem yang sedang menjalankan Libra. Dalam sesetengah kes, ini bukan penghalang; contohnya, pengurus pakej berasaskan "yum" memerlukan Python dipasang pada sistem semasa, kerana "yum" dibangunkan dalam Python.

Walau bagaimanapun, dalam banyak kes, bahasa reka bentuk selain Bourne shell (Bash) tidak dijangka boleh dipasang pada semua sistem pengurusan. Selalunya, persekitaran kompilasi skrip yang lebih berkuasa adalah keperluan praktikal untuk penulis pengurus. Walau bagaimanapun, bertentangan dengan jangkaan, mengikat Ruby atau Python penuh untuk dijalankan sebagai penterjemah akan meningkatkan saiz Libral melebihi had sumber persekitaran penggunaan sebenar. Sebaliknya, pilihan biasa Lua atau JavaScript sebagai bahasa penyuntingan skrip yang boleh dibenamkan tidak sesuai untuk persekitaran ini, kerana kebanyakan penulis pengurus tidak biasa dengan mereka, dan biasanya memerlukan banyak kerja untuk memenuhi keperluan pengurusan sistem Keperluan sebenar.

Libral disertakan dengan versi mruby, versi kecil Ruby yang dibenamkan yang menyediakan asas yang stabil kepada penulis pengurus dan bahasa pengaturcaraan yang boleh dilaksanakan yang berkuasa. mruby ialah pelaksanaan lengkap bahasa Ruby, walaupun dengan sokongan perpustakaan standard yang jauh berkurangan. Pengikatan mruby dengan Libral mengandungi kebanyakan perpustakaan standard penting Ruby untuk tugas pengurusan skrip, yang akan dipertingkatkan dari semasa ke semasa berdasarkan keperluan penulis pengurus. Mruby Libral menggabungkan penyesuai API untuk menjadikan pengurus penulisan lebih sesuai untuk konvensyen JSON Contohnya, ia termasuk alat mudah (seperti Augeas yang menyusun dan mengubah suai fail struktur) untuk menyelesaikan konvensyen menghurai dan mengeluarkan JSON. Fail mruby.prov mengandungi contoh rangka kerja pengurus JSON yang ditulis dalam mruby.

Langkah seterusnya

Langkah seterusnya yang paling kritikal untuk Libral ialah menyediakannya secara meluas - tarball yang telah disusun sebelumnya ialah cara yang baik untuk memulakan dan mendalami pengurus pembangunan, tetapi Libral juga perlu dibungkus pada pengedaran arus perdana dan digunakan dalam Ia boleh didapati di atas. Begitu juga, kuasa Libra bergantung pada set pengurus yang disertakan, dan perlu diperluaskan untuk merangkumi set teras fungsi pengurusan. Tapak web Libra termasuk senarai tugasan yang menyenaraikan keperluan pengurus yang paling mendesak.

Kini terdapat banyak cara untuk meningkatkan kebolehgunaan Libra untuk tujuan yang berbeza: daripada menulis binding untuk lebih banyak bahasa pengaturcaraan, contohnya, Python atau Go kepada menjadikan ralsh lebih mudah digunakan dalam skrip shell, sebagai tambahan kepada In yang boleh dibaca manusia sedia ada; Selain output dan output JSON, output boleh diformatkan dengan mudah dalam skrip shell. Penggunaan Libral dalam pengurusan berskala besar juga boleh dipertingkatkan dengan menambahkan API jauh yang dibincangkan di atas menggunakan alat pengangkutan seperti SSH untuk menyokong keperluan pemasangan kelompok yang lebih baik dan skrip yang telah disusun untuk pelbagai seni bina berdasarkan seni bina sistem sasaran yang ditemui.

Libral, APInya dan keupayaannya boleh terus berkembang dan berkembang, kemungkinan yang menarik ialah menambah keupayaan memberi amaran kepada API, yang boleh melaporkan kepada sistem perubahan dalam sumber yang berada di luar skopnya. Cabaran untuk Libral adalah untuk mengekalkan alat yang kecil, ringan dan jelas terhadap kes penggunaan yang semakin meningkat dan mengurus prestasi - Saya berharap setiap pembaca boleh menjadi sebahagian daripada perjalanan ini.

---

Atas ialah kandungan terperinci Liral menyediakan API pengurusan bersatu untuk sumber dan perkhidmatan sistem!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!