When describing “charms” to people unfamiliar with the juju ecosystem, we often say things like:
A charmed operator (‘charm’) is an expansion and generalization of the Kubernetes notion of an operator
Software that drives other software on hybrid/multicloud environments
A package of expert knowledge in a reusable and shareable form that hugely simplifies software management and operations
But when juju admins and charm developers talk about charms, they could mean several different things, depending on context.
A “charm” is a zip file but with a
.charm extension, which is the product of a
charmcraft pack command inside a charm repo (project).
*.charmfile can be uploaded to charmhub or deployed directly.
*.charmfile does not include resources such as the workload image(s).
- When we deploy
*.charmfiles directly, we need to specify resources explicitly (if any).
*.charmfile is an archive of the operator code.
Charm repo (project)
A “charm” is a repository containing the entrypoints’ code (typically
src/charm.py, but depends on the charm type), tests, charm libraries, metadata, CI, etc.
- We run
charmcraft packinside a charm repo (project) to obtain a
- A charm repo may be dedicated for a charm relation, in which case the charm is a dummy operator or functions as a relation tester. This is due to a current charmhub limitation that requires charm libraries to be nested under a charm.
Charmhub store item
A “charm” is a versioned item in the charmhub store, which may have charm libraries or resources (such as workload images) attached to it.
- First, a charm name is registered on charmhub. Charm names on charmhub are unique and are not namespaced.
- When we deploy charms from charmhub, they are deployed with the same resources they were published (released) with (unless overridden).
- A charm without a workload is still a charm - a workloadless charm. Some can run on both machine or kubernetes, and some assume a specific platform.
- A charm with a workload is what we call a charmed application - an application whose configuration, lifecycle etc. are driven by a charmed operator (an operator in the juju ecosysem).
A “charm” is an entity in the juju model representing a set of containers and their dedicated pod. The unit is named after the pod, the pod is named after the app, and by default the app is named after the charm. For example, if we
juju deploy prometheus-k8s prom, then we’d have:
|Charm name||App name||Pod name||Unit name|
- A unit is a kubernetes pod made up of a charm container and usually one or more workload containers.
- Each unit runs its own copy of the
- A deployed unit is an operator-in-action.
juju statuslists deployed units and their status
- The unit is the subject of juju commands such as
A “charm” is an entity in the juju model representing a set of deployed units of the same app (deployed from a
*.charm or charmhub). For example, if we
juju deploy prometheus-k8s prom --num-units 3 then we’d have one
prom app (comprised of three units).
- The app is the subject of juju commands such as
juju statuslists deployed charms and their status
A “charm” is the operator’s container that is provisioned next to the workload container.
- A charm container that drives an application (a workload) is what we call a charmed operator - an operator (in the broad sense), but with extra powers, and that is part of the juju ecosystem.
- Every deployed unit of a kubernetes charm always has a “charm” container.
- The charm container makes use of pebble to (re)start/stop the workload.
- You can
sshinto the charm container of a given unit (pod) with
juju ssh app/0.
A “charm” is the code that juju triggers to run on various event hooks. In kubernetes charms, it is typically the
src/charm.py file that is packed into a
- At Canonical, modern charms are written in python, but technically, charms could be written in any language as they use environment variables and hook tools to communicate with juju.
- The entrypoint of a charm can be customized in the charmcraft.yaml file.