Charm architecture

The HTTP request lego provider is, at its core, a Juju charm deploying and managing HTTP request Lego provider as defined by ACME to manage DNS records.

It leverages the 12-factor support to pack a Django application providing the functionality as defined by the standard.

For a complete view on the architecture of a 12-factor charm, refer to the 12-factor architecture documentation. The rest of this document details the HTTP request Lego provider specifics.

OCI images

We use Rockcraft’s Django framework extension to build OCI Images for HTTP request LEGO provider. The images are defined in HTTP request Lego provider rock. They are published to Charmhub, the official repository of charms.

See more: How to publish your charm on Charmhub

Juju events

For this charm, in addition to the event handling provided by the framework, the following Juju events are observed:

1. pebble_ready: fired on Kubernetes charms when the requested container is ready. Action: copy the necessary configuration files and trigger the default handler as defined by the framework.
2. config_changed: usually fired in response to a configuration change using the CLI. Action: copy the necessary configuration files and trigger the default handler as defined by the framework.

See more in the Juju docs: Hook

Charm code overview

The src/charm.py is the default entry point for a charm and has the DjangoCharm Python class which inherits from paas_app_charmer.django.Charm, the base class from which all Django 12-factor charms are formed, defined by the Django framework extension for Charmcraft.

See more in the Charmcraft docs: Django framework extension

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 configuration command:

juju config git-repo=https://example.repository.git

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 containers.