Copyright @ Lenovo US

    This article is a high level view of Juju's internal modelings. For me it was fairly confusing when looking at its document which has an army of these concepts: charm, bundle, model, unit.... of course, each of them makes sense after a while. Its terminology page helps on understanding individual term. But like other Canonical documents, it needs a design level diagram to help user grasp the structure of this wealth of knowledge.

    So here it is my attemp to show the relationship between these terms. Instead of drawing a tree to reflect 1-N relationship, I used an outer enclosure which can have multiple of its inner enclosures, eg. a bundle can have N charms.

    Juju control models

    A few interesting points besides the 1-N relationships.

    • A single application can be deployed on multiple machines, eg. Application #2 has two units. This is how one application can be scaled out horizontally.
    • One machine, in turn, can host multiple applications, eg. one unit of application #2 and #3 both live on the same machine.

    By default, juju deploy will call for a new machine for each application within the bundle/charm. Of course, there is command flag to switch that so you can specify which machine is to be used.

    — by Feng Xia


    Juju GUI nginx proxy

    In LXD on localhost we introduced using LXD container to bootstrap a Juju controller. But how to access the Juju GUI? Launching it is easy enough with $ juju gui from juju host;...

    Juju local LXD

    Using Juju's LXD provider is the least-hassle way to start an experience of Juju and its charms. However, if you have done charm development for a while, you know making a one line of code...

    Charm Ansible integration

    Let's face it. Ansible has the mouth (and market) share these days. For our modeling purpose, we are to utilize its procedural strength to carry out actions, which provides an abstraction instead of coding in charm's Python files.