Help your imagination - visualizing ARM templates with ARMVIZ

ARM templates are a great tool when you want to automate provisioning of your environment. They're customizable, somehow flexible, easy to store and modify. What they lack - as many text tools - is a touch of abstraction. Most people are sightseers - that's why it's always a good thing to see what you're doing.

I'll paint this!

ARMVIZ is a free and OSS tool, which will visualize and help to validate your ARM template on a very high level. By saying "high level" I mean, that it helps to understand the structure of a template and basic dependencies rather than underlying relations when it comes to provision resources.

The very first visualization you'll see in ARMVIZ

Working with ARMVIZ

Currently there're two possibilities to work with ARMVIZ - either you open a template stored on your disk or write a new one inside the editor. The former helps to validate whether you have all components inside a template and all dependencies work well, the latter is actually a slightly better option when it comes to write JSON than Visual Studio(especially when VS goes mad while validating a JSON schema).

ARMVIZ suggests possible values but it won't limit them to the ones available for a field

When dependencies are removed from a VM, we can clearly see, that there're some problems with our template


In current shape ARMVIZ has very limited capabilities and can act only as a quick support when you have a very complicated ARM template. On the other hand, the possibility to write and see it increases your productivity and really helps when you're struggling to understand what is related to what and why.


Getting serious with Juju - multiple models, management and constraints

In the last introductory post for Juju we'll cover working with multiple models, basic management and setting some constraints. For now you should be familiar with the basic concepts and probably be able to work with a simple model. It's time to check what it's all about.

Multiple models

As I mentioned in the previous posts, by default a bootstrap creates two models - admin and default. The former is designed for managing some internal stuff, the latter is what you have access to and can work with. Initially it seems reasonable, but sooner than later you'll understand, that having everything(web applications, big data, analytics etc.) in on place just muddles things. To separate concerns we can have multiple models residing on the same controller.

Models listed with juju models command show both machines and cores count

You can add a new model easily either with a GUI(with a "Start a new model" button) or with a CLI(using juju add-model <model_name> command). To switch active model you can do the same - either select it from a dropdown or with a juju switch command.

Importing & exporting models

The important thing is Juju is the possibility to import/export a model. With this feature you can easily share an infrastructure you've modeled or use model designed by other experts. The best thing about this is the fact, that you pass only an idea - a physical part is detached from a model. What is more, since models are just YAML files, you can easily version them using a version control system of your choice. Take a look how a simple model is descibed:

series: xenial
    charm: "cs:trusty/wordpress-5"
    num_units: 1
      "gui-x": "300"
      "gui-y": "300"
      - "1"
    charm: "cs:mysql-57"
    num_units: 1
      "gui-x": "695"
      "gui-y": "395"
      - "0"
  - - "mysql:db"
    - "wordpress:db"
    series: xenial
    constraints: "arch=amd64 cpu-cores=1 mem=1792 root-disk=30720"
    series: trusty
    constraints: "arch=amd64 cpu-cores=1 mem=3584 root-disk=30720"

As you can see, all "beings" like charms, relations and machines are here and can be customized without interacting with Juju. 


When it comes to management features, Juju comes with two major concepts - commands restrictions and network spaces.


It's always a good idea to restrict potentially dangerous features of a tool or an application you're using. When it comes to Juju, we have two groups - destroy and remove. A good reference which command falls to which group can be found here. The important thing about this is that in most case a user will be affected by those restriction only when it logs again. If you go with following commands:

juju disable-command destroy-model
juju destroy-model <model>

You won't have problems with removing a model. Another thing is using --force switch with Juju commands. Have in mind that this means, that all your restrictions will be bypassed.

Network spaces

Since infrastructure made with Juju can become quite complicated, some advanced networking features are available. One of those are "spaces", well described in the documentation:

A space is made up of one or more routable subnets with common ingress and egress rules. The Juju operator can model this topology in such a way that applications gain the required network connectivity without generating complex network IP maps that are not portable. This gives the operator much better and finer-grained control over all networking aspects of a model and its application deployments.

To make the long story short - spaces let you orchestrate your subnets and ease connection between them when it comes to communication. What is more, once spaces are configured, you can constraint deploying charms to the particular ones. 

To only downside of this is the fact, that currently spaces are only supported by MAAS so it's not available out of the box. Still, if you're interested in such feature, take a look here.


The last but not least thing are constraints. They allow you to set some limits when it comes to setting a machine. The important thing here is the difference between different cloud vendors - depending on the cloud, some constraints can be available or generating conflicts. 

Constraints have two characteristic:

  • work on "a better" basis - you are passing the minimum requirement for a component
  • can be ignored by passing a null value

You can set constraints either for an environment(controller), a model, an application or a machine.

You may wonder what is the purpose of working on "a better" basis. To understand reasons behind this setting you have to change your mindset a little when working with Juju - it is designed to provide the best performance to coordinated components, not to manage them in terms of used resources. It's all about modeling a solution which works flawlessly.


In this short journey we've learned some basic stuff in Juju. We know what are the main components, how a model is built and how we can manage it. We'll come back to Juju in future to create custom charms with Azure resources.