This marks a first, people actually complaining that my somewhat rambling blog post wasn’t ready…
It’s not going to be possible to cover all of the various topics around InfraKit that I aim to cover in a single post, so this is the first of a few posts that will focus on what InfraKit is, and how it connects together.
What is InfraKit
InfraKit was released by Docker quite recently and has already had ample coverage in the tech media and on Wikipedia. However, I guess my take is that it is a framework(or toolkit, I suppose InfraWork doesn’t work as a name) that has the capability to interact with Infrastructure and provide provisioning, monitoring and healing facilities. The fact that it is a framework means that it is completely extendable and anyone can take InfraKit and extend it to provide those Infrastructure capabilities for their particular needs. Basically a Infrastructure vendor can take InfraKit and add in the capability to have their particular products managed by InfraKit. Although thats a rather commercial point of view, and my hope is that overstretched Infrastructure Admins can take InfraKit and write their own plugins (and contribute them back to the community) that will make their lives easier.
Haven’t we been here before?
There has been a lot of politics happening in the world recently, so I choose to give a politicians answer of yes and no. My entire IT career has been based around deploying, managing and monitoring of Infrastructure and over the ~10 years i’ve seen numerous attempts to make our lives easier through various types of automation.
- Shell scripts (I guess powershell, sigh 🙁 )
- Automation engines (with their own languages and nuances)
- Workflow engines (Task 1 (completed successfully) -> Task 2 (success) -> Task 3 (failed, roll back))
- OS Specific tools
- Server/Storage/Network Infrastructure APIs, OS/Hypervisor Management APIs, Cloud APIs … and associated toolkits
All of these have their place and power businesses and companies around the world but where does InfraKit fit? The answer, is that it at has the flexibility to replace or enhance the entire list. Alternatively it can be used in a much more specific nature where it will simply just “keep the lights on” by replacing/rebuilding failed infra or growing and scaling it to meet business and application needs.
What powers InfraKit
There are four components that make up InfraKit that are already well documented on GitHub, however the possibilities for extending them are also discussed in the overview.
This is the component that i’ve focussed on currently and provides some of the core functionality of InfraKit. The Instance plugin provides the foundation of Infrastructure management for InfraKit and as the name suggests, the plugin will provide an instance of Infrastructure resource. The Instance plugins take configuration data in the form of JSON, and provides the properties that are used to configure an instance.
So, a few possible scenarios:
|Hypervisor Plugin||Cloud Plugin||Physical Infrastructure Plugin|
|VM Template: Linux_VM||Instance Type: Medium||Hardware Type: 2 cpu server|
|Network: Dev||Region: Europe||Server Template: BigData|
|vCPUs: 4||SSH_KEY: gGJtSsV8 …||OS build plan: RHEL_7|
|Mem: 8GB||Machine_image: linux||Power_State: On|
I can then use my instance plugin to define 1, 10, 100, as many as needed instances that will provide my Infrastructure resource. But I want 30 servers 20 for web traffic, 7 for middleware and 3 back end for persistent storage, how do I define my infrastructure to be those resources…
The flavor plugin is what provides the additional layer of configuration that takes a relatively simple instance and defines it as providing a specific set of services.
Again some possibilities that could exist:
|WebServer Plugin||Middleware Plugin||Persistent Storage Plugin|
|Packages Installed: nginx||Packages Installed: rabbitmq||Packages Installed: mysql|
|Storage: nfs://http/||Firewall: 5672||Msql_Username: test_env|
|Firewall: 80, 443||Cert: ——– cert —||Msql_Password: abc123|
|Config: nginx.conf||RoutingKey: middleware||Bind: 127.0.0.1|
So given my requirements i’d define 20 virtual machine instances and attach the web server flavor to them and so on, that would give me the capacity and the configuration for my particular application or business needs. The flavor plugin not only provides the configuration control, it is also use to ensure that the instance is configured correctly and deemed healthy.
That defines the required infrastructure for one particular application or use case, however to separate numerous sets of instances I need to group them…
The default group plugin is a relatively simple implementation that currently will just hold together all of your instances of varying flavors allowing you to create, scale, heal and destroy everything therein. However groups could be extended to provide the following:
- Specific and tailored alerting
- Chargeback or utilisation overview
- Security or role based controls
The InfraKit cli is currently the direct way to interact with all of the plugins and direct them to perform their tasks based upon their plugin type. To see all of the various actions that can be performed on a plugin on a specific type use the cli:
$ build/infrakit <group|flavor|instance>
$ build/infrakit instance
describe describe the instances
destroy destroy the resource
provision provisions an instance
validate validates an instance configuration
So if we were to use a hypervisor plugin to provision a virtual machine instance we would do something like the following:
Define the instance in some json:
Then provision the instance using the correct plugin
$ build/infrakit instance instance.json --name instance-hypervisor
… virtual instance is provisioned …
The next post will cover how the architecture of the plugins, the communication methods between them and how more advanced systems can be architected through the use of InfraKit.