About Anemos

Table of contents

➟How it works

In addition to its own tooling, Anemos requires a user-supplied payload. The payload is a codified description of the deployment itself. It could for example be a script that runs the installer of your favorite Linux Distribution (though it must be non-interactive). However, the recommended approach is to use makeimg.

Given the payload, the Anemos CLI tool can be used to generate an initramfs by building on the Anemos base initramfs. When run, the initramfs will perform the deploy as described by the payload. Since an initramfs runs entirely from RAM it can exert full control over disk partitioning, file systems, etc. Note that unlike many other systems, Anemos does not rely on PXE-boot to achieve this. The CLI tool can be used to boot the initramfs on the host to be deployed.

Find out more by looking at the demos, reading the documentation, or checking out the source code of the existing demo projects!

➟Design

At its core, Anemos promotes Infrastructure as code (IaC). But there are many ways to do that. Anemos aims to put the user in control.

One major goal of Anemos is to be a viable tool for small infrastructure, even down to just a single host. At the same time, it attempts to be modular and flexible enough that it should fit into larger setup as well (presuming that setup consists of standard/non-proprietary components). This goal directly informs the following design decisions:

  1. Anemos relies only on standard boot mechanisms - it runs on bare metal and virtual machines alike, and should work on machines of most cloud/hosting providers. No PXE-boot infrastructure required (as is often used in datacenter setups).
  2. Anemos is based on an “outside” description of the system rather than an “inside” one (like Chef/Puppet/Ansible), which further reduces overhead in the required infrastructure. This approach might require rapid re-deploys, which Anemos is designed for. But it is not dogmatic about it - nothing prevents you from deploying an image that just contains Chef/Puppet/Ansible/… and have that take over system management.
  3. In larger setups, a pre-built system image is often transferred to the server being deployed, e.g. from a storage server. This being infeasable in smaller settings, Anemos only transfers the “image description”. The building happens on the server itself (which is usually well-connected). This allows clients to trigger deployments even over low-bandwidth links without the need for additional infrastructure like storage servers.

➟Components

The Anemos core consists of two components:

However, other components are being developed as part of project Anemos. They are standalone components that are both optional when using Anemos as well as usable without Anemos. But they are designed to integrate well with the Anemos core: