Juju At A Glance

The other day I came across a Canonical Juju tool.

Scraps from the internet claim it is a configuration management tool like Chef, Ansible, or Puppet.

I read obliquely the docks on it, looked into the repositories with charms-modules (analogue of cookbooks or playbooks) and argue that this is not so.

Juju is more like a VM-agnostic orchestra (like Nomad or Kubernetes). It can be used to declaratively describe the infrastructure configuration of an application: which applications we run, on which machines, how many copies, how they are connected with other services.
But unlike Kubernetes, it can work not only with Docker, but also with any kind of virtual machines.

They say that the kernel, agent and client are written in Golang - and I did not look at them.

The part related to the configuration itself is usually described in combination with YAML and Python (the docks say that other languages ​​can be used in addition to python).

How does this all work?

Disclaimer : this article does not claim to be a complete and accurate description, I rather see it as a way to lower the entry threshold for those who want to take a look at Juju and help navigate the documentation.

Full documentation is here: https://docs.jujucharms.com/

As already written above, in Juju there are several components:

• The controller is the server part that allocates virtual machines. Each [cloud] provider has its own controller (including for not quite cloud providers such as local LXD or Metal as a Service ).
  The controller is a monolithic application from one component. At least one controller copy must be running in each provider. There is some HA, but I did not delve into it.
• Agent - put on each virtual machine. There are two types of agents - for machine and for unit. It seems that one of them is put on the host machine, and one of them in the virtual machine - I didn’t go into it in detail either.
• The client is a CLI tool for managing all this economy.
• GUI
• A declarative description of all user components (applications, machines, etc.)
• Custom code for setting up a separate virtual machine, it is called Charms

(Actually, there is a larger tree of components, but for this story we’ll simplify it so that it’s easier to understand what's what)

On the declarative description, you can build approximately the following component structures (graphs are drawn automatically by the GUI):

The server part somehow creates virtual machines there, pulls dependencies, establishes connections between them, monitors the signals that arise - everything seems to be pretty standard there, like for other orchestrators.

And here are the modules for configuring virtual machines called charms (unit - charm), let's take a closer look.

It would seem that I know Chef, Ansible and Puppet, probably there is nothing new here, but this is not so. The creators of Juju did not create a DSL to declaratively describe the resources in the system. Instead, they created a framework that would allow completely normal python or bash code to be idempotent and associate it with a Juju controller.

Charm device

The charms themselves are not very simple. By structural complexity, they remind chef's cookbooks or the roles of ansible. And in fact, they are more likely an analogue of resources, rather than cookbooks.

They consist of metadata / declarative part, peremptory hooks (reaction to events) and all sorts of data files such as additional scripts, documentation or typical configs.

The declarative part describes the charm dependency interfaces (for example, the wordpress charm depends on mysql, and the mysql charm provides this interface), system compatibility, tags, configuration parameters (such as cookie attributes) and program layers depending on other charms ( for example, most charms include a layer layer:basic).

In imperative hooks, a reaction to any external events is described. For example, we installinstall the necessary package for an event, configureconfigure it for an event , and startstart a service for an event .

This is all written on an ordinary python with decorators (somewhere I read the statement that you can write on anything, even on a bash, but I have not seen any examples).

A classic lightweight example is NTP: https://github.com/lampkicking/charm-ntp

Interestingly, apparently, when compiling the charm, a completely standalone application is obtained that can be run on the server without additional dependencies - in the compiled version, I saw that it included the contents of all layers used by it, as well as the tarballs of all used Python modules.

Example for NTP: https://jaas.ai/ntp/32 (see the list of files on the right side of the page).

Summary

Juju has a very interesting and unusual approach to describing and setting up infrastructure.

Most likely, juju has a higher entry threshold than the chef, most likely charms are slower to develop compared to cookbooks and playbooks and require more programming skills.

On the other hand, I suppose that a model with event hooks encourages you to write more correct code.

It seemed to me that Juju is more aimed at infrastructure programmers (those who wrote many CLI tools on python in Linux 5-7 years ago), who now need to configure servers, while Chef / Ansible - at admins, which instead of one -Two now you need to configure a hundred or two servers.

Should I use Juju in 2019?
Not sure:

• You will wrap new (cloud native) applications in docker in docker and launch it on a cuber or ECS
• For "old" applications, you probably already have deployment scripts written on the ensemble or boss
• For new projects with "old" architecture - maybe. BUT :
• Almost no one knows about Juju in RuNet, this is the first article in Russian that describes a little what it is

If you work with Juju, write in the comments where I made a mistake - after all, I only read the docks for her for 2-3 hours.