Juju - quick tour

The other day I came across a Canonical Juju tool.

Scrap information from the Internet states that it is a configuration management tool like Chef, Ansible or Puppet.

I read the docks diagonally over it, looked into the repositories with charms-modules (analogue kukbukov or playbooks) and claim that it is not.

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

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

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

How does all this 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 look at Juju and help navigate the documentation.

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

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

• The controller is the server part that allocates virtuals. For each [cloud] provider there is a controller (including for not quite cloudy ones, such as local LXD or Metal as a Service ).
  The controller is a monolithic application of one component. At least one copy of the controller in each provider must be running. There is some HA, but I didn’t go into it.
• Agent - put on each virtualku. There are two types of agents - for the machine and for the unit. It seems that one of them is placed on the host machine, and one in the virtual machine - I did not go into it in detail either.
• The client is a CLI tool for managing all this housekeeping.
• GUI
• Declarative description of all user components (applications, machines, etc.)
• Custom code to configure a separate virtuals, it is called Charms

(Actually, there is more tree components, but for this narration we will make simplification, to make it easier to understand what was happening)

On the declarative description, you can build approximately the following structure of components (graphs are drawn automatically via the GUI):

The server part somehow creates virtuals there, pulls out dependencies, establishes connections between them, tracks the emerging signals - everything seems to be pretty standard for me like other orchestrators.

But the virtualok configuration modules, 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. Juju creators did not begin to create DSL for the declarative description of resources in the system. Instead, they created a framework that allows quite ordinary code on python or bache to make it idempotent and associate it with the Juju controller.

Charm device

The charms themselves are not very simple. By structural complexity resemble kukbuki chef or the role of ansibla. And as a matter of fact they are more likely an analogue of resources, and not kukbuk.

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

In the declarative part, the charm dependencies are described (for example, wordpress charm depends on mysql, and mysql charm provides this interface), compatibility with systems, tags, configuration parameters (such as kukbook attributes) and program layers (dependencies) on other charms ( for example, most charms include a layer:basic ).

Imperative huk also describes the reaction to any external events. For example, install necessary package for the install event, configure it for the configure event, and start service for the start event.

This is all written in the usual python with decorators (I read somewhere the statement that you can write on anything, even though it was on the bash, but I did not see any examples).

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

What is interesting, apparently, when compiling a charm, you get a completely standalone application that can be run on the server without additional dependencies - in the compiled version I saw that it contained the contents of all the 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 the description and configuration of the infrastructure.

Most likely, juju has a higher entry threshold than a chef, most likely charms are slower in development compared to cookbooks and playbooks and require large programming qualifications.

On the other hand, I suppose that the model with events-hukami pushes to write more correct code.

It seemed to me that Juju is more focused on infrastructure programmers (those who wrote many CLI tools on python in Linux 5-7 years old), who now need to set up servers, while Chef / Ansible - on admins, who instead of one -two now need to configure hundreds of other servers.

Should I use Juju in 2019?
Not sure:

• New (cloud native) applications you wrap up in docker and run on docker or ECS
• For "old" applications, you probably already have deployment scripts written on ansible or boss.
• For new projects with the "old" architecture - maybe. BUT :
• Almost nobody 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 docks to it for 2-3 hours.