Provisioning Azure Managed Redis

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group to hold the cluster:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the cluster

Azure Managed Redis comes in two parts: a cluster, which sets the size and the hostname, and a database inside it, which is what we'll actually connect to. Let's create the cluster first, using the smallest size, a Balanced B0:

Which gives us the cluster's hostname:

{
  "hostName": "sample-managed-redis-1.redis.locally",
  "name": "sample-managed-redis-1",
  "provisioningState": "Succeeded",
  "sku": "Balanced_B0",
  "type": "Microsoft.Cache/redisEnterprise"
}

That redis.locally hostname is served by Locally's own DNS server. Without --no-database the CLI would create a database for us straight away, but doing it separately shows the settings that matter.

4. Create the database

Now we can add the database:

{
  "accessKeysAuthentication": "Enabled",
  "clientProtocol": "Encrypted",
  "clusteringPolicy": "EnterpriseCluster",
  "name": "default",
  "port": 62375,
  "provisioningState": "Succeeded",
  "type": "Microsoft.Cache/redisEnterprise/databases"
}

A few of those flags are worth explaining:

• --client-protocol Encrypted means clients connect over TLS.
• --clustering-policy EnterpriseCluster gives clients a single endpoint, so a plain redis-cli works without cluster mode.
• --access-keys-auth Enabled turns on access keys, which is what we'll connect with. Newer versions of the Azure CLI default this to Disabled, so it's worth being explicit.

Behind the scenes Locally starts a real Redis server in a container, and handles TLS and the access key check in front of it. Azure always uses port 10000, but Locally picks a free port for each database, so read port from the response rather than hard-coding it.

5. Get the connection details

Connecting needs one of the database's access keys:

{
  "primaryKey": "OAOXqDuGYTB9uh24BWPQ6huNiaPg/kxl0aqjqxJrZc39",
  "secondaryKey": "PSSVGXBhQLNbh/XsvmL+mP6MUJk+yNhHh17PBuB9CNpz"
}

Rather than copying values around, let's keep hold of the hostname, the port and the primary key:

redis-cli reads its password from REDISCLI_AUTH, which keeps the key off the command line.

6. Connect with redis-cli

Now we can talk to the database. Locally's certificates are signed by its own local CA, so we point redis-cli at that with --cacert. Let's write a key:

OK

And read it back:

hello from Locally

If the container is still starting, the first command can fail with an I/O error; give it a few seconds and try again. Leave off SET or GET to get an interactive prompt instead. Without the key, the database refuses commands with NOAUTH Authentication required.

7. Tidy up

Finally, we can tidy up. To remove the Resource Group and everything within it, including the Redis container:

There's nothing billable to clean up, since everything ran on your machine, but it's still worth checking your teardown scripts work here before you run them against Azure.

Doing this with other tooling

Whilst this guide used the Azure CLI, Azure Managed Redis works the same way through any of the tooling that Locally supports - Microsoft.Cache/redisEnterprise and Microsoft.Cache/redisEnterprise/databases resources in HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template all provision against Locally in the same way, with only the location changed.

The same goes for your application: any Redis client that supports TLS can connect using the cluster's hostName, the database's port and an access key. Just take the port from your tooling's outputs rather than assuming 10000.

Next steps

To keep the access key out of your app's settings, store it in a Key Vault and read it with a Managed Identity.

Should you encounter any issues, please take a look at the troubleshooting section.

Resource types this guide uses

These are the Azure resource types this guide creates in Locally:

• Microsoft.Cache/redisEnterprise
• Microsoft.Cache/redisEnterprise/databases