Turns out that my previous InfraKit post was almost a complete duplication of something Docker posted pretty much at the same time .. -> https://blog.docker.com/2016/11/docker-online-meetup-recap-infrakit/
One thing that hasn’t so far been covered in a deep-dive fashion is around the plugins themselves, what they are, how you communicate with them and how they communicate with your infrastructure. So in this post, I aim to cover those pieces of information.
Each plugin for InfraKit is technically its own application, and in most cases can be interacted with directly. As an application it needs to conform to a number of standards defined by InfraKit, and have the following capabilities and behaviours:
- Create a UNIX socket in
- Host a httpd server on that socket
- Respond correctly to a number of URLs dependent on the “type” of plugin
- Respond to the following HTTP Methods:
- GET, typically will be looking at system or instance state
- PUT, will be looking to perform instance provisioning or system configuration
- Handle JSON passed and parse the data for configuration details
The design choices offer the following benefits:
- Adheres to the same API designs of docker.socket -> https://docs.docker.com/engine/reference/api/docker_remote_api/
- The use of UNIX Socket (that lives on the filesystem), allows the capability to place more complex plugins in containers and expose their interfaces through volume mapping.
- As it uses standard http for its communication, it doesn’t tie the plugins to any language. In theory a python plugin could simply be written using the simplehttpserver and bind that to a UNIX Socket.
To see what is happening under the covers, we can create a fake plugin and use the infrakit cli to interact with it. Below I’m creating a socket using netcat-openbsd and placing it in the plugins directory. This would be visible with a
$ build/infrakit plugins ls however that command doesn’t interact with the plugins and just lists the sockets in that directory.
We will now use the infrakit cli to provision an instance by passing it some configuration JSON and asking it to use the “fake” plugin. Immediately afterwards netcat will output the data that was sent to the socket it created, and we can immediately see the URL format along with JSON data that would be sent to a plugin.
$ nc -lU /root/.infrakit/plugins/instance-test &
$ build/infrakit instance provision test.json --name instance-test
POST /Instance.Provision HTTP/1.1
From here we can see that the URLs are in the form of /<plugin type>/<action> e.g.
How to communicate with Plugins
InfraKit gives you the flexibility to go from the simple provisioning of an instance, to having your Infrastructure deployed, monitored, and in the event of mis-configuration or failure, healed. In the simplest example of just needing an instance, through the InfraKit CLI we can explicitly request a new instance and pass the JSON that will contain the configuration needed to define that new instance.
$ build/infrakit instance provision physical_server.json —name instance-physical
However for an end-to-end infrastructure definition a full infrastructure specification would need to be passing to a group plugin for that to ensure that it’s created.
How plugins communicate with your infrastructure
Strictly speaking, the Infrakit architecture covers the design and interaction between plugins (sockets, URL adherence, parsing JSON for configuration information) The plugin itself can be written to use any method that makes sense to provision and destroy the Infrastructure, such as speaking to APIs or even SSH’ing into network switches (it’s 2016, but sadly it’s still the way to interact with some devices 🙁 )
If we look at the vagrant plugin (line 55) we can see that we read all of the properties that were passed through the JSON (CPUs, Memory, networking) and build a
Vagrantfile, the plugin will then call
vagrant up, which will start the guest machine based upon the configuration in the Vagrantfile.
Some examples that could exist in the future
A networking plugin that takes the properties and will ensures that those changes are written to that switch and also makes sure that the switch is compliant to the configuration. Given that a lot of switch configuration and feature sets are identical across vendors, it could be possible to have networking properties that are agnostic and the instance-networking can identify the vendor and provide the configuration that matches their interfaces.
DISCLAIMER, I'm only using HPE OneView as an example as I know the API and it's capabilities. There is no guarantee that HPE would write such a plugin.
A physical server plugin that would make use of the HPE OneView API to deploy Physical Server Instances.
It quickly becomes clear that from the plugins that exist already, to the ideas for the future that InfraKit can really provide Infrastructure as Code. As the plugin ecosystem continues to grow and evolve, InfraKit has the opportunity to provide a great way to help orchestrate your infrastructure.
Find out more about InfraKit and the plugins on the InfraKit GitHub …