Hi all, Gosuke Miyashita here at ATL.

Today, I’ll introduce our recently started OSS project, libspecinfra, and discuss the project’s prospects moving forward.

What is Specinfra?

As the libspecinfra project was developed as an outgrowth of the Specinfra OSS, I’ll begin with an explanation of Specinfra.

Specinfra is a library made from Ruby which serves the following roles:

  • Provides abstraction of command differences across OS and distributions
  • Provides abstraction of command execution via SSH, WinRM, Docker API, locally, etc.

For example, when running the following test using Serverspec implemented in Specinfra, in the background Specinfra will automatically select the suitable command for each OS and distribution, then execute according to the pre-specified method (via SSH, Docker API, etc.)

Specinfra’s functionality was originally encompassed by Serverspec. However, we felt that the ability to abstract execution and command differences would also be useful when developing tools outside of Serverspec, especially server configuration management tools such as Puppet and Chef. In this sense, Specinfra was born as the isolation of select functionality from Serverspec. As a result, server configuration management tools such as Itamae and Serverkit have been developed using Specinfra.

Specinfra Registration: Background and Challenges

Specinfra registration was predicated on the following:

  1. Methods for server operation and information acquisition differ depending on OS and distribution, even if the target is the same.
  2. Methods for execution of server operation and information acquisition differ depending on whether executed from within or outside the target server.

As an example of the former, when performing package management operations, differences come into play on an OS and distribution basis, such as yum and rpm commands in RedHat or apt-get and dpkg commands in Debian).

As an example of the latter, when executing commands, there are differences such as whether a command is executing directly on the server, via SSH, or via the Docker API.

Based on the above premises, the current challenges are as follows:

  1. System management tools are subject to individual OS/distribution and execution abstraction, thus are not reusable.
  2. Although Specinfra was developed with reusability in mind, it is still not widely used.

Regarding the former, server configuration management tools filling a similar objective (Chef, Puppet, Ansible, Itamae (Specinfra) all respectively implement their own comparable abstraction.

Regarding the latter, one significant problem is that Specinfra was created in Ruby, thus cannot be used in non-Ruby projects. In actuality, MItamae is the reimplementation of Specinfra in mruby.

Problem-Solving Solutions: Proposals and Implementation

A solution to these and other issues would be to provide a library that conducts OS/distribution and executable abstraction from a shared library usable with various languages, rather than RubyGems as with Specinfra.

This implementation will be handled by the libspecinfra project. The libspecinfra project consists of the following OSS:

  1. Specinfra frame providing the shared library
  2. Assorted language binding to call the shared library provided by the Specinfra frame

The former is currently still being implemented. While it still lacks functionality, at least it’s operable. While implementation has taken the form of the reimplementation of Specinfra in Rust, the name will be kept as Specinfra for the time being.

The latter still hasn’t been implemented. The plan is to first implement Ruby and mruby binding, then expand the scope to other languages.

Sample code can be found on GitHub in the libspecinfra organization examples repository. At present, only Rust sample code is available, but further sample code will be added once other language bindings are implemented.

libspecinfra Goals

The libspecinfra project has the following objectives:

  • Facilitate the creation of tools that will better solve the increasing complexity of system operation and management.
  • Make is easier to use extant tools with new servers such as containers and Unikernels.
  • Serve as the base for all forthcoming system management tools.

Granted, these are lofty goals, and the project hasn’t been undertaken without some degree of trepidation. (Will it be possible to complete the project in an ideal form? Once it’s completed, will there even be demand?) Nonetheless, we’ll keeping munching on our dogfood and develop a libspecinfra version of Serverspec while pushing forward with future development.