Enterprise Scale Azure Landing Zones via Azure DEVOps using Terraform and CAF Modules: Rover

5 min readSep 28, 2021

TL:DR Rover is a GitHub project that can be used to create a Docker container with all the tools you need on it to implement the Microsoft Cloud Adoption Framework — Enterprise Scale Framework via Terraform. It is the glue that holds everything together.

This series of stories is a practical set of written instructions for Microsoft Cloud Adoption Framework for Azure documentation — Cloud Adoption Framework | Microsoft Docs.

This story carries on from Enterprise Scale Azure Landing Zones Azure DEVOps using Terraform and CAF Modules: Structure.

What is Rover?

Rover is a Docker Container and Terraform wrapper that gives a consistent set of tools to implement CAF and allows you to specify which branch of the various CAF Repos to use at runtime. — Paul Matthews, September 2021

The person I know who has the most knowledge of Rover is Paul Matthews, hats off to him he was the one at Simple Innovation who got to grips with and understood what Rover is and how to use it.

Rover is key to implementing the Cloud Adoption Framework — Enterprise Scale via Terraform using the community project.

In the last part of this series I talked about the structure and where its stored but what is it that actually collates and runs the code? This is a Rover Instance’s job. This is the engine behind everything, the platform where the logic uses the configuration to build the resources.

Ambiguous Rover

In discussions at Simple Innovation we discovered that the word Rover was being used ambiguously and this was causing confusion.

Never use the word Rover on its own always qualify it so its context is clear.

Rover Project

This is the GitHub project that contains the source for creating Rover Images.

You may never visit it as the community project hides it from you to a certain extent but this the glue that binds everything else together.

In a CAF — ES Modules community call recently they talked about the Terraform community project which they, rightly, called a Docker Image that manages the deployment for you.

If this were a coding project the Rover Project would be the Project Repo.

Rover Container

You can use the Rover Project to build your own Docker Images but the community project maintain a set of them that you can use directly. Which is one reason why you may never actually go to the Rover Project and why Rover can feel ‘hidden’.

The ‘public’ Rover Images are available as containers from the aztfmod/rover set on dockerhub.

You can create and host your own if you want to make modifications.

If this were a coding project then a Rover Container would be a class file in that it contains the definition of the functionality, the public interfaces and links to other source files but it cannot be directly executed.

Rover Instance

A Rover Host downloads a Rover Container and creates a Virtual Machine that acts as a Rover Instance, this is what will execute your code.

This is what most people seem to mean when they say a Rover.

A Rover Instance needs a Rover Host to run on.

If this were a coding project then a Rover Instance would be an instance in that it uses a class to create something that can carry out tasks and act on data, in this case Azure Resources.

Rover Host

A Rover Host is a program that takes a Virtual Machine with a Rover Instance and allows it to execute.

If this were a coding project then a Rover Host would be the Interpreter or Byte Code Engine that allows an instance to affect resources.

Hosting Rover Instances

You have several options for hosting Rover Containers to supply Instances

Azure Virtual Machines

This is the preferred mechanism as it means the machines are being hosted inside the environment they are managing and they not explicitly associated with any particular user.

Azure Container Services

This converts the Infrastructure as a service approach of the Azure Virtual Machines into a Platform as a Service approach.

This should be the preferred approach but is not currently explicitly supported by the community project.

Docker Desktop

This is the one the Community Project talks about but it is best avoided.

It has hardware requirements that mean you need to run it on a physical machine, or an expensive virtual machine.
Physical machine id bad because if its not available then you can’t manage the Azure Landing Zones.
Virtual machines are better in that they are always available but our experience with them has been poor.
Its no longer free if you are in Government or a Medium or Large Enterprise

Using Rover Instances

There are three ways you will make use of the Rover Instances.

Azure DEVOps Pipelines

This is the preferred way to run a Rover Instance as it does not rely on a specific user or physical hardware. When configuring production, other than bootstrapping, it is the only way you should access a Rover Instance.

When running a DEVOps pipeline its YAML file, probably a modified copy of one of the ones in yaml caf-terraform-landingzones-starter/configuration/sandpit/pipelines at starter · Azure/caf-terraform-landingzones-starter (github.com) will determine which Azure Container the Azure Virtual Machine in your Azure Tenant will use.

In the file there will be a section as follows:

resources:
  containers:
    container:

Docker CLI

Only for use in trying things out outside of your production environment, its a way of avoiding needing a Docker Desktop license when used in conjunction with Azure Container Services.

Visual Studio Code

You can open the Rover Container remotely in Visual Studio Code and interact with it.

Whilst useful to understand how things work this is not a good way to run in practice as again you will be dependent on an actual user and a machine.

Dynamic Container Selection

This also caused confusion so to explain the Docker Host, such as Docker Desktop or Azure Container Services or an Azure Virtual Machine when it is invoked checks if the version of the Rover Container it has been requested to host is the same as the one it is currently hosting.

If it is then it uses it.

If not it dynamically downloads the requested version and uses that. This can take some time.

Operating System ‘Stacks’

Lets be clear about it:

A Rover Container is a Docker Container based on Linux

You may be accessing it from a Windows Device but it is running Linux.

As an example of how nested this can get:

I run Visual Studio Code on a Windows Physical Laptop
Visual Studio Code connects to a Rover Container running Linux
The Rover Container is Hosted on Azure Container Services which are Azure Virtual Machines running Linux
The Azure Virtual Machines are hosted on Physical Hardware also running Linux

Remember:

A Rover Instance is running Linux and so is Case Sensitive and uses Linux Pathing always

This is one ‘gotcha’ that has tripped several of our staff up.