5. Charm architecture

Web app support in Charmcraft and Rockcraft is a framework to easily deploy and operate your Flask, Django, FastAPI or Go workloads and associated infrastructure, such as databases and ingress, using open source tooling.

The resulting charm design leverages the sidecar pattern to allow multiple containers in each pod with Pebble running as the workload container’s entrypoint.

Pebble is a lightweight, API-driven process supervisor that is responsible for configuring processes to run in a container and controlling those processes throughout the workload lifecycle.

Pebble services are configured through layers, and the following containers represent each one a layer forming the effective Pebble configuration, or plan:

  1. An app container, which contains the workload to run in any of the supported web frameworks.

As a result, if you run a kubectl get pods on a namespace named for the Juju model you’ve deployed the web app charm into, you’ll see something like the following:

NAME                          READY   STATUS    RESTARTS   AGE
web-app-0                     2/2     Running   0          6h4m

This shows there are 2 containers - the named above, as well as a container for the charm code itself.

And if you run kubectl describe pod web-app-0, all the containers will have as Command /charm/bin/pebble. That’s because Pebble is responsible for the processes startup as explained above.

5.1. Charm architecture diagram

        C4Container
System_Boundary(web_app_charm, "Web app charm") {
   Container_Boundary(charm_container, "Charm Container") {
      Component(charm_logic, "Charm Logic", "Juju Operator Framework", "Controls application deployment & config")
   }
   Container_Boundary(web_app_container, "Workload Container") {
      Component(workload, "Workload", "Web Application", "Serves web requests")
   }
}
Rel(charm_logic, workload, "Supervises<br>process")
    

5.2. OCI images

We use Rockcraft to build OCI Images for the web app charm.

5.3. Metrics

The provided support for metrics and tracing depends on the enabled extension.

5.4. Integrations

The available integrations, including those that are already pre-populated, varies between extensions.

5.5. Juju events

See Juju events.

5.6. Charm code overview

The src/paas_charm/charm.py contains the charm logic that all supported frameworks will inherit and extend. Each framework will define its entry point in its own charm.py file, defining a class that will extend from PaasCharm.

PaasCharm is the base class from which all Charms are formed, defined by Ops (Python framework for developing charms).

See also

Charm

The __init__ method guarantees that the charm observes all events relevant to its operation and handles them.

Take, for example, when a configuration is changed by using the CLI.

  1. User runs the command

    juju config sample_config=sample_value
    
  2. A config-changed event is emitted.

  3. In the __init__ method is defined how to handle this event like this:

    self.framework.observe(self.on.config_changed, self._on_config_changed)
    
  4. The method _on_config_changed, for its turn, will take the necessary actions such as waiting for all the relations to be ready and then configuring the container.