| toc | prev |
Here we describe alternative approaches to deploying applications that are better suited for more complex applications.
Typically Kubernetes deployments have been defined using HELM charts. These are not widely used in OpenShift largely because of security concerns. We therefore do not cover them in detail here, but for more information on HELM look here.
Ansible is one of a number of open-source Infrastructure As Code (IaC) tools typically used for automated application deployment, configuration and orchestration.
Using YAML-based files, referred to as playbooks, users can configure almost every aspect of a physical machine by defining tasks that use the modules provided by the tool.
For example, the following very simple excerpt defines a task that results
in the command-line execution of oc get pvc with the result (stdout) written
to the variable pvc_result: -
- name: Get known PVCs (current project)
command: oc get pvc
register: pvc_result
apk
to zfs for managing zfs file systemsk8s moduleThe Squonk Computational Notebook is a complex application consisting of numerous container images that also rely on additional infrastructure components that include: -
To orchestrate the suite of containers and configure the database and authentication service a number of playbooks and object templates have been developed, resulting in simple one-click installation of the application and its orchestration formed from: -
The open-source repository contains some interesting OpenShift templates that include: -
Some Ansible k8s module templates that include: -
And Ansible Role playbooks that include orchestrating: -
Roles are a more structured variant of playbooks.
Ansible encourages roles over playbooks as they provide a much more flexible way of configuring a physical machine by imposing a directory structure and naming convention that allows its playbooks to be reused, easily (dynamically) configured and shared with the community.
If properly structured, roles can also be easily shared via a public service Ansible refers to as the Galaxy.
All the advantages of playbooks plus: -
The PySimple application we’ve been deploying during the workshop is available as an Ansible role, published to Galaxy. The role source is available on GitHub.
Variables are typically defined in the defaults/main.yml file where you’ll
find the variables that control the PySimple deployment.
To use a Galaxy role define it with the aid of a requirements.yml
file: -
- src: alanbchristie.pysimple
version: 1.0.0
And install it using the ansible-galaxy tool: -
ansible-galaxy install -r requirements.yml
And execute it, defining any role variables from with a playbook (or role) with a simple YAML construct: -
- hosts: servers
tasks:
- include_role:
name: alanbchristie.pysimple
vars:
image_tag: '2019.5'
Operators provide Kubernetes application orchestration and configuration and are distributed as container images.
Operators are a relatively new concept in Kubernetes but are gaining big traction. They provide a containerised Kubernetes native approach to managing the whole lifecycle of an application, not just its deployment. For instance an operator can handle deploying a database as well as managing procedures for upgrading, backing it up and restoring it from backups.
The PySimple application we’ve been deploying during the workshop is available as a simple Kubernetes ansible operator. The operator is available on GitHub and deploys the PySimple role into Kubernetes or OpenShift.
A description of the operator and example use can be found in the project’s GitHub documentation.
We have plenty more information in the openrisknet/home GitHub repository. In particular you might want to take a look at:
| toc | prev |