Juju 2.7.0: creating a new usability standard for infrastructure automation

This is a post that I’m hoping to get up on the Ubuntu.com blog. Have any suggestions? Please add them as comments below!

Juju 2.7.0: creating a new usability standard for infrastructure automation

Canonical’s Juju team released Juju 2.7.0 this week. This has been the culmination of several months of work by a worldwide engineering team.

New Features


Your days of YAML spaghetti are over. Juju is becoming the simplest way to deploy and manage your container-centric workloads. This release has aimed at bringing more Juju features to k8s charms and more k8s features to Juju.

K8s charms can now define actions, introspect agents, and communicate back to Juju via the addition of juju-run within the pod’s PATH. Experienced k8s operators will feel more at home with the ability to set secrets, administer service accounts, and other k8s-native features from their charms directly.

Bulking out bundles

Bundles are a single-file description of a model. A model in the Juju community refers to a set of applications that are delivering a service. The Kubernetes community uses the term deployment. Bundles describe the collection of charms, their relationships and the machine shapes that should be provisioned to host them.

As of 2.7.0, bundles describe cross-model relations. What’s a cross-model relation? They allow applications to be re-used outside of their original model. That allows central services, such as those provided by Keystone or Vault, to be accessible from other models.

Cross-model relations also enable applications to bridge clouds. We can deploy database on bare metal with minimal I/O overhead and application software on Kubernetes where high-density is preferred.

Bundles now support Juju’s trust functionality. “Trust” allows you to delegate programmatic access to cloud APIs to charms. This allows charms to directly provision storage.

Flexible, adaptive networking

Network management is one of the most frustrating parts of deploying applications to the cloud. Juju engineers have reworked the internals of how networking is managed. This has paid off in the form of added flexibility and opens the door for lots of innovation in this area.

The most prominent change has been the inclusion of the juju bind command. Applications can now define application endpoint bindings to network spaces over time. Previously this capability was only available at deployment time.

New charm capability: application-level data

Until now, complex applications with multiple units have needed to coordinate using a peer relation as a side-channel, to ensure that each individual unit sent consistent information to applications they were related to. If that sounds complicated, it’s because it is! Now the leader unit can set application-level data once. Related applications can see that new data directly.

Bringing developer happiness to credential management

2.7.0 introduces several changes to command-line behaviour to make it easier for developers to get their work done (and for Juju to get out of the way as fast of possible!). Managing cloud credentials, account details used to authenticate with cloud providers, has been radically simplified.

Why consider Juju?

Juju is the simplest way to create (and maintain!) digital infrastructure that is stable and secure. It’s particularly good at managing hybrid-cloud services, whether on Kubernetes, VMs, bare metal or any combination. Consider this opinion from community member Zicklag from independent games developer Katharos Technology:

I have experience with Chef, Docker, Packer, Terraform, Rancher, and Docker Swarm and … I felt like there still needed to be a tool that facilitates communication between the applications that are being provisioned. Juju is that tool. Juju allows for a level of orchestration that practically allows you to create your own “orchestrator” that manages your applications in a way that Kubernetes or Swarm would never let you. It is a GAME CHANGER.

What is Juju?

Juju is simple, secure and stable devops software. It keeps operational complexity low and productivity high. It is designed to to manage today’s complex application architectures wherever they are run.

Its target audience is wide. We aim to be the tool of choice for SRE and operations teams, developers and data engineers.

Juju excels at:

  • making your deployment understandable
  • simplifying post-install operations, such as upgrades, updates and configuration management, and
  • managing hybrid-cloud services, whether on Kubernetes, VMs, bare metal or any combination.

Learn more by taking a look at our Getting Started with Juju walkthrough and asking any questions on our Discourse forum.


@zicklag Are you comfortable with being named here? Your last name isn’t provided on your company’s home page. Please let me know how you would like to be referred to.

1 Like

I don’t mind at all. You can just refer to me as Zicklag.

1 Like

Its a great post.

I sometimes say that “Juju is a tool to consume clouds”. Its not completely accurate but it helps in some contexts.


@tkurek has published this post as Juju 2.7: Enhanced k8s experience, improved networking and more | Ubuntu

How is this used with juju?

I don’t think it’s used yet. It’s intended to make charms easier to write, because less coordination is required. Units do not need to agree on a value before sending it to the other side.

1 Like

https://github.com/juju/juju/pull/10794 has a couple of charms that show that basically when you set relation data you can add a --app flag that states that this is part of a single application level data bag that charms can use. I’m not sure where the frameworks are at picking this up yet as it’s just out in the 2.7 but the goal is that this means we can watch for when that application level data changes vs checking unit by unit and hopefully reduce chatter and complexity in charming.


A related thread popped up here Application Level Relation Data Questions

Looking forward to have an example charm published that use this functionality.