About charm types, by destination type

With the Juju SDK you can build three different types of charms. This document introduces these types, explaining their beginnings and purpose.

Contents:

Machine charms

Juju’s beginnings were centered around simplifying the deployment of complex applications and services in a cloud-first world. At the time, many of those applications were run in virtual machines or on bare-metal servers, and deployments to these environments continue to enjoy first-class support. A machine charm can be deployed to a number of different underlying compute/storage resource providers:

  • Bare-metal (using MAAS)
  • Virtual machine (using KVM in Openstack, EC2 in AWS, VMware Environment etc.)
  • Container (using LXD cluster)

Kubernetes charms

More recently, the Juju OLM introduced support for Charmed Operators on Kubernetes. Juju can bring the same benefits to applications deployed on Kubernetes, by placing operators alongside workloads to manage them throughout their lifecycle. When a model is created with Juju, a corresponding Kubernetes namespace is created. When a charm is deployed on Kubernetes, it is deployed as a StatefulSet that manages a set of Pods running the specified application containers alongside a sidecar container containing the charm code.

By definition, the sidecar pattern is designed to allow the augmentation of workloads with additional capabilities and features. The pattern is implemented in this case by a small auxiliary container, located in the same Pod as your application, that provides operations functionality - this is exactly how Juju operates in other environments, and a well-established pattern in the Kubernetes community.

By utilising this pattern, we ensure that there is always an operator right next to every unit of the workload, irrespective of how the application is scaled. The operator will always have direct access to shared memory, the same network namespace and the ability to manipulate the workload as required to keep it running smoothly. This approach simplifies the operation of upstream or third-party application images, enabling administrators to make changes at runtime to suit their environment should they wish, without the requirement to maintain a fleet of bespoke container images.

For charm developers, these benefits are realised by utilising Pebble to manage workloads. Pebble is a lightweight, API-driven process supervisor designed for use with Charmed Operators. Pebble enables charm developers to define how they want workloads to run, and provides an API that enables operations code to manage the workloads throughout their life.

Subordinate charms

Subordinate charms were created to enable the development of charms that could be deployed alongside existing charms, to augment them with specific functionality that may not be included in the original application charm. They are, in many ways, analogous to the sidecars described above. All charms are principal charms, except those that are subordinates. A subordinate charm depends on the creation of a relationship to a principal charm, it is never deployed as a standalone application. This is best explained with an example:

Consider the deployment of a large web application scaled to n replicas. Each instance of the charm comprises a unit, in Juju parlance, and an App is the sum of all units of a given charm with the same name. When a large web application is scaled to n replicas, n units will be started by Juju.

The administrators of the web application will likely want to collect logs from the application server. The developer of the application charm may not have included a mechanism for forwarding logs from the service that is compatible with the administrator’s specific environment. By using a subordinate charm such as rsyslog-forwarder, the administrator can ensure that each deployed unit of their web application is automatically configured to forward logs using rsyslog. To do this, they must simply deploy the subordinate and juju relate their web application to it.

Subordinate charms are written in the same way as other charms, with the addition of an extra subordinate flag in the charm’s metadata.


Last updated a day ago.