Kansible

Kansible lets you orchestrate operating system processes on Windows or any Unix in the same way as you orchestrate your Docker containers with Kubernetes by using Ansible to provision the software onto hosts and Kubernetes to orchestrate the processes and the containers in a single system.

<p align="center"> <a href="http://github.com/fabric8io/kansible/"> <img src="https://raw.githubusercontent.com/fabric8io/kansible/master/docs/images/logo.png" height="200" width="200" alt="kansible logo"/> </a> </p>

Kansible uses:

• Ansible to install, configure and provision your software onto machines using playbooks
• Kubernetes to run and manage the processes and perform service discovery, scaling, load balancing together with centralised logging, metrics, alerts and management.

Kansible provides a single pane of glass, CLI and REST API to all your processes whether they are inside docker containers or running as vanilla processes on Windows, AIX, Solaris or HP-UX or an old Linux distros that predate docker.

Kansible lets you migrate to a pure container based Docker world at whatever pace suits you, while using Kubernetes to orchestrate all your containers and operating system processes for your entire journey.

Features

• All your processes appear as Pods inside Kubernetes namespaces so you can visualise, query and watch the status of your processes and containers in a canonical way
• Each kind of process has its own Replication Controller to ensure processes keep running and so you can manually or automatically scale the number of processes up or down; up to the limit in the number of hosts in your Ansible inventory
• Reuse Kubernetes liveness checks so that Kubernetes can monitor the state of your process and restart if it goes bad
• Reuse Kubernetes readiness checks so that Kubernetes can know when your process can be included into the internal or external service load balancer
• You can view the logs of all your processes in the canonical kubernetes way via the CLI, REST API or web console
• Port forwarding works from the pods to the remote processes so that you can reuse Kubernetes Services to load balance across your processes automatically
• Centralised logging and metrics and alerting works equally across your containers and processes
• You can open a shell into the remote process machine via the CLI, REST API or web console; which is either a unix bash or a windows cmd shell as shown in the fabric8 console screenshot below:

<p align="center"> <a href="https://raw.githubusercontent.com/fabric8io/kansible/master/docs/images/kansible-demo.png"> <img src="https://raw.githubusercontent.com/fabric8io/kansible/master/docs/images/kansible-demo.png" height="250" width="600" alt="kansible logo"/> </a> </p>

Ansible perspective on Kansible

If you already use Ansible; then one way to think about Kansible is that you continue to use Ansible however you have been doing; using reusable composable playbooks and so forth. The only change to your playbooks that Kansible introduces is that you don't run Unix or Windows services (e.g. like systemd / init.d). You install and configure the software via Ansible playbooks; setting up whatever directories, users and permissions you require. But you don't create services or run the software.

Then we use Kubernetes (and kansible pods) as the alternative to Unix and Windows services. The reason we do this is that Kubernetes is a better distributed version of systemd/init.d/Windows services as it also includes features like:

• service discovery and load balancing
• health monitoring
• centralised logging, metrics and alerts
• manual and automatic scaling up or down
• a consistent web console, CLI and REST API across processes running via kansible and Docker containers

Kubernetes perspective on Kansible

If you already use Kubernetes then you could look at Kansible as a way of extending the reach of Kubernetes to manage both Docker containers on a host that supports Docker plus remote processes on operating systems that don't support Docker. That then makes Kubernetes the orchestrator of all your software; whether its Dockerized or not!

All your processes are belong to us! :)

Longer term it would be great for Docker to be ported to more operating systems; along with the kubelet. So ideally more operating systems could use native Docker and kubelet; in which case there's less need for kansible. But at the time of writing, that goal is looking some way off for older versions of Windows along with AIX, Solaris and HPUX.

Whats really compelling about using Kubernetes to manage Docker containers and operating system processes via Kansible is that you can mix and match on a per microservice basis - use the right tool for the job right now - but all the while use a single orchestrator platform, Kubernetes, a single REST API, CLI tools and web console - with standard service discovery, load balancing and management functions.

Using Docker is more optimal; so we hope over time that you can use more Docker and less kansible; but its going to take our industry a while to Dockerize all the things and move everything to Linux; or to have fully working Docker + Kubernetes on Windows + all flavours of Unix. Until then, kansible can help! At least we can now pretend everything's Dockerized and running on Linux from an orchestration and management perspective ;)

How to use Kansible

You use kansible as follows:

• create or reuse an existing Ansible playbook to install and provision the software you wish to run on a number of machines defined by the Ansible inventory

• if you reuse an existing playbook, make sure you disable running the unix / windows services; as you will run that command instead in the kansible pods.

• run the Ansible playbook either as part of a CI / CD build pipeline when there's a change to the git repo of the Playbook, or using a command line tool, cron or Ansible Tower

• define a Replication Controller YAML file at kubernetes/$HOSTS/rc.yml for running the command for your process like this example.

• the RC YAML file contains the command you need to run remotely to execute your process via $KANSIBLE_COMMAND

  • you can think of the RC YAML file as like the systemd configuration file, describing the command to run to startup the application. Only its a single file for the entire cluster which is stored in Kubernetes. Plus it can include readiness and liveness probes too .
  • You can use the {{ foo_bar }} Ansible variable expressions in the RC YAML to refer to variables from your global Ansible variables file

• to take advantage of Kubernetes services, you can also define any number of Service YAML files at kubernetes/$HOSTS/service.yml

  • they can be named anything you like so long as they are valid Kubernetes YAML or JSON and are in the same folder as the RC.yml
  • see the Kubernetes Services example and its kubernetes/appservers/service.yml file for how to do this.

• whenever the playbook git repo changes, run the kansible rc command inside a clone of the playbook git repository:

  kansible rc myhosts

where myhosts is the name of the hosts you wish to use in the Ansible inventory.

Then kansible will then create/update Secrets for any SSH private keys in your Ansible inventory and create or update a Replication Controller of kansible pods which will start and supervise your processes, capture the logs and redirect ports to enable liveness checks, centralised metrics and Kubernetes services.

So for each remote process on Windows, Linux, Solaris, AIX, HPUX kansible will create a kansible pod in Kubernetes which starts the command and tails the log to stdout/stderr. You can then use the Replication Controller scaling to start/stop your remote processes!

Working with kansible pods

• As processes start and stop, you'll see the processes appear or disappear inside kubernetes, the CLI, REST API or the console as a kansible pod.
• You can scale up and down the kansible Replication Controller via CLI, REST API or console.
• You can then view the logs of any proc