Cooking with Radius - Using recipes to automate infrastructure deployment
Introduction
This was supposed to recorded as a video as part of the Festive Tech Calendar for this year, but unfortunately real life got in the way meaning I was unable to record in time. So rather than waste the effort I thought a blog post was the next best thing.
What is Radius
Radius is a new application platform from the Microsoft Incubation team. The Incubation Team works under Mark Russinovich and are responsible for various open-source projects (KEDA, Dapr and Copasetic) donated to the CNCF (Cloud Native Computing Foundation).
The application platform is designed to help developers and platform engineers deploy and manage their applications. It is open source to allow for further development and enhancement from the community.
The term radius might conjure a range of associations from remote authentication network protocols to geometric principles and even osteology. However, this application platform is not connected to these concepts. The most relevant association might be the logo’s symbolic representation of a circle’s radius. Whilst I could not find a definitive answer, I believe any perceived reference to arm bones is purely coincidental without intentionally linking the platform to Bicep and ARM templates.
Recipes and Environments
Environments serve as a system for configuration management related to the computing platform, network settings, diagnostic systems, and other operational aspects. They facilitate a clear division of responsibilities between developers and the IT teams that support them. Furthermore, environments provide the flexibility to modify configurations based on the type of deployment (such as staging), deployment regions, or even different cloud platforms. Each environment gives the IT team the ability to configure recipes with specific parameters that meet the requirements of that particular environment.
Recipes with Radius, look to define how the infrastructure is configured and deployed for a specific resource. This is meant to give the Infrastructure, Platform and Security teams the ability to create pre-configured resources for use by development teams. These recipes can provide a variety of configurations for the same resource type allowing for multi-cloud deployments (AWS and/or Azure) or variations between different environments (local containers vs cloud services). The main aim of recipes is to allow developers to worry about their applications without having to learn how to configure the associated resources.
Demo
Within the planned demonstration, I deployed three AKS clusters Dev, Test and Production. Each cluster was initialised with Radius with their own environment into their own workspace using the command.
rad init --full -w festivetech-prod
Once deployed a number of services are running within the radius-system namespace.
This allows them to be managed and controlled from a single machine without credentials and configuration settings needed to be applied on each command. Within each environment I created a specific Service Principal user and Resource Group within Azure, so deployed resources would be deployed into known locations.
rad env update festivetech-prod --azure-subscription-id <<SUB-ID>> `
--azure-resource-group resources-festive-tech-prod `
-w festivetech-prod
Once the environment were created, I linked recipes for the redisCache to each environment. This is where the configuration elements change per environment. All the recipes are created with the same default name and Applications.Datastores/redisCaches resource type.
Development
Within the development environment we used the local-dev recipe supplied by the radius test, this creates a redis cache within the AKS cluster which is quick to spin up and down to ensure that any new changes are working as intended.
rad recipe register default -w festivetech-dev `
--template-kind bicep `
--template-path ghcr.io/radius-project/recipes/local-dev/rediscaches:0.27 `
--resource-type Applications.Datastores/redisCaches `
Test
Within the test environment we move to using Azure resources rather than internal containers, this recipe creates the an Azure Redis cache with a Basic 250MB configuration.
rad recipe register default -w festivetech-test `
--template-kind bicep `
--template-path ghcr.io/radius-project/recipes/azure/rediscaches:latest `
--resource-type Applications.Datastores/redisCaches `
Production
Moving to production, I overrode the default settings of the recipe with additional parameters. This would ensure that in production a larger Premium 6GB Redis cache would be used. If using non-string parameters like skuCapacity then using a json file is the only way to override these settings. String parameters can be passed in at the command line too.
rad recipe register default -w festivetech-prod `
--template-kind bicep `
--template-path ghcr.io/radius-project/recipes/azure/rediscaches:latest `
--resource-type Applications.Datastores/redisCaches `
--parameters @production.json
production.json
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"skuCapacity": {
"value": 1
},
"skuFamily": {
"value": "P"
},
"skuName": {
"value": "Premium"
}
}
}
Deployment
Now we can look to deploy the resources into each environment using the command:
rad deploy ./app.bicep -w festivetech-dev
This deploys the resources into the dev environment, which includes the redis cache.
Moving to the test environment, rerunning the command for the test environment
rad deploy ./app.bicep -w festivetech-test
This still deploys the frontend container into the AKS cluster, but the redis cache is now a full Azure resource.
The deployment of the redis cache takes a good 5-10 minutes to deploy when using an Azure resource, but once deployed the application continues to work but the cache is not separate to the cluster.
Finally, we deploy into the production environment.
rad deploy ./app.bicep -w festivetech-prod
Similar to the test environment only the frontend container is running within the cluster.
However, the Redis cache is now running on the premium tier.
We have seen how recipes can help teams deploy their applications to different environments with different configurations. This would allow the developers to concentrate on their own applications rather than the resource configuration needed.