---
description: >
The azure-chroot Packer builder is able to create Azure Managed Images
leveraging
a VM in Azure.
page_title: Azure chroot - Builders
---
# Azure Builder (chroot)
Type: `azure-chroot`
Artifact BuilderId: `azure.chroot`
The `azure-chroot` builder is able to build Azure managed disk (MD) images. For
more information on managed disks, see [Azure Managed Disks Overview](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/managed-disks-overview).
The difference between this builder and the `azure-arm` builder is that this
builder is able to build a managed disk image without launching a new Azure VM
for every build, but instead use an already-running Azure VM. This can
dramatically speed up image builds. It also allows for more deterministic image
content and enables some capabilities that are not possible with the
`azure-arm` builder.
> **This is an advanced builder** If you're just getting started with Packer,
> it is recommend to start with the [azure-arm builder](/docs/builders/azure-arm),
> which is much easier to use.
## How Does it Work?
This builder works by creating a new MD from either an existing source or from
scratch and attaching it to the (already existing) Azure VM where Packer is
running. Once attached, a [chroot](https://en.wikipedia.org/wiki/Chroot) is set
up and made available to the [provisioners](/docs/provisioners).
After provisioning, the MD is detached, snapshotted and a MD image is created.
Using this process, minutes can be shaved off the image creation process
because Packer does not need to launch a VM instance.
There are some restrictions however:
- The host system must be a similar system (generally the same OS version,
kernel versions, etc.) as the image being built.
- If the source is a managed disk, it must be made available in the same
region as the host system.
- The host system SKU has to allow for all of the specified disks to be
attached.
## Configuration Reference
There are many configuration options available for the builder. We'll start
with authentication parameters, then go over the Azure chroot builder specific
options.
### Authentication options
None of the authentication options are required, but depending on which
ones are specified a different authentication method may be used. See the
[shared Azure builders documentation](/docs/builders/azure) for more
information.
@include 'builder/azure/common/client/Config-not-required.mdx'
### Azure chroot builder specific options
#### Required:
@include 'builder/azure/chroot/Config-required.mdx'
#### Optional:
@include 'builder/azure/chroot/Config-not-required.mdx'
#### Output options:
At least one of these options needs to be specified:
- `image_resource_id` (string) - The managed image to create using this build.
- `shared_image_destination` (object) - The shared image to create using this build.
Where `shared_image_destination` is an object with the following properties:
@include 'builder/azure/chroot/SharedImageGalleryDestination-required.mdx'
@include 'builder/azure/chroot/SharedImageGalleryDestination-not-required.mdx'
And `target_regions` is an array of objects with the following properties:
@include 'builder/azure/chroot/TargetRegion-required.mdx'
@include 'builder/azure/chroot/TargetRegion-not-required.mdx'
## Chroot Mounts
The `chroot_mounts` configuration can be used to mount specific devices within
the chroot. By default, the following additional mounts are added into the
chroot by Packer:
- `/proc` (proc)
- `/sys` (sysfs)
- `/dev` (bind to real `/dev`)
- `/dev/pts` (devpts)
- `/proc/sys/fs/binfmt_misc` (binfmt_misc)
These default mounts are usually good enough for anyone and are sane defaults.
However, if you want to change or add the mount points, you may using the
`chroot_mounts` configuration. Here is an example configuration which only
mounts `/prod` and `/dev`:
```json
{
"chroot_mounts": [
["proc", "proc", "/proc"],
["bind", "/dev", "/dev"]
]
}
```
`chroot_mounts` is a list of a 3-tuples of strings. The three components of the
3-tuple, in order, are:
- The filesystem type. If this is "bind", then Packer will properly bind the
filesystem to another mount point.
- The source device.
- The mount directory.
## Additional template function
Because this builder runs on an Azure VM, there is an additional template function
available called `vm`, which returns the following VM metadata:
- name
- subscription_id
- resource_group
- location
- resource_id
This function can be used in the configuration templates, for example, use
```text
"{{ vm `subscription_id` }}"
```
to fill in the subscription ID of the VM in any of the configuration options.
## Examples
Here are some examples using this builder.
This builder requires privileged actions, such as mounting disks, running
`chroot` and other admin commands. Usually it needs to be run with root
permissions, for example:
```shell-session
$ sudo -E packer build example.pkr.json
```
### Using a VM with a Managed Identity
On a VM with a system-assigned managed identity that has the contributor role
on its own resource group, the following config can be used to create an
updated Debian image:
```hcl
source "azure-chroot" "example" {
image_resource_id = "/subscriptions/{{vm `subscription_id`}}/resourceGroups/{{vm `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}"
source = "credativ:Debian:9:latest"
}
build {
sources = ["source.azure-chroot.example"]
provisioner "shell" {
inline = ["apt-get update", "apt-get upgrade -y"]
inline_shebang = "/bin/sh -x"
}
}
```
```json
{
"builders": [
{
"type": "azure-chroot",
"image_resource_id": "/subscriptions/{{vm `subscription_id`}}/resourceGroups/{{vm `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
"source": "credativ:Debian:9:latest"
}
],
"provisioners": [
{
"inline": ["apt-get update", "apt-get upgrade -y"],
"inline_shebang": "/bin/sh -x",
"type": "shell"
}
]
}
```
### Using a Service Principal
Here is an example that creates a Debian image with updated packages. Specify
all environment variables (`ARM_CLIENT_ID`, `ARM_CLIENT_SECRET`,
`ARM_SUBSCRIPTION_ID`) to use a service principal.
The identity you choose should have permission to create disks and images and also
to update your VM.
Set the `ARM_IMAGE_RESOURCEGROUP_ID` variable to an existing resource group in the
subscription where the resulting image will be created.
```hcl
variable "client_id" {
type = string
}
variable "client_secret" {
type = string
}
variable "subscription_id" {
type = string
}
variable "resource_group" {
type = string
}
source "azure-chroot" "basic-example" {
client_id = var.client_id
client_secret = var.client_secret
subscription_id = var.subscription_id
image_resource_id = "/subscriptions/${var.subscription_id}/resourceGroups/${var.resource_group}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}"
source = "credativ:Debian:9:latest"
}
build {
sources = ["sources.azure-chroot.basic-example"]
provisioner "shell" {
inline = ["apt-get update", "apt-get upgrade -y"]
inline_shebang = "/bin/sh -x"
}
}
```
```json
{
"variables": {
"client_id": "{{env `ARM_CLIENT_ID`}}",
"client_secret": "{{env `ARM_CLIENT_SECRET`}}",
"subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
"resource_group": "{{env `ARM_IMAGE_RESOURCEGROUP_ID`}}"
},
"builders": [
{
"type": "azure-chroot",
"client_id": "{{user `client_id`}}",
"client_secret": "{{user `client_secret`}}",
"subscription_id": "{{user `subscription_id`}}",
"image_resource_id": "/subscriptions/{{user `subscription_id`}}/resourceGroups/{{user `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
"source": "credativ:Debian:9:latest"
}
],
"provisioners": [
{
"inline": ["apt-get update", "apt-get upgrade -y"],
"inline_shebang": "/bin/sh -x",
"type": "shell"
}
]
}
```