Today, we’re announcing the release of Azure Service Operator v2. Azure Service Operator defines Azure resources as Kubernetes objects, giving you a standardized approach for your Kubernetes native resource deployments, pods, and your Azure resources using YAML as the common language. Azure resources can now be provisioned through the same declarative model as everything else in your Kubernetes environment, reducing onboarding time and increasing developer velocity.
Many of our customers are building self-service deployment platforms using Azure Service Operator. Instead of IT teams needing to interface with various platforms to provision Azure infrastructure resources, they define resources in Kubernetes YAML, have these resources provisioned from within their Kubernetes environments using ASO, and easily connect resources to their applications. This reduces Azure-specific overhead and leverages Kubernetes knowledge your teams already have.
In the past year, we’ve rebuilt Azure Service Operator for higher reliability, easier maintenance, and included the features you need to run ASO at scale. We’ve developed a CRD generator that leverages the Azure OpenAPI schemas of our Azure services to easily create CRDs that cover all ARM-level operations for supported resources. Not only does this let us rapidly add support for a larger set of Azure services, it also standardizes Azure Service Operator across all of these resources, making it easier for new Azure customers to get started. To learn more, check out the Azure Service Operator v2 here.
Adobe is an early adopter of Azure Service Operator, and we’re privileged to have partnered with them to improve ASO. Colin Murphy, engineering manager of Document Cloud Operations at Adobe, says,
“The Azure Service Operator allows Adobe Document Cloud to provide a scalable developer experience. It allows us to provide sensible defaults without restricting developer options and retain control in a centralized manner without stifling creativity.
The Azure Service Operator has increased our velocity in creating new applications. When everything a service needs can be expressed in a handful of Kubernetes API objects, onboarding and change management become much simpler.
I would highly recommend the Azure Service Operator to any organization that needs to build a scalable developer experience."
In the demo below, we'll show how to leverage Azure Service Operator to create Azure PostgreSQL resources using simple YAML definitions. We'll also create a Kubernetes secret to connect the Flexible Server Database to our application. Here's a sneak peak of the YAML we'll be using:
# First, we'll create a namespace for the Kubernetes objects that represent these resources in Azure.
apiVersion: v1
kind: Namespace
metadata:
name: asodemo
---
# Next, we'll create an Azure Resource Group for all of the PostgreSQL Flexible Server resources.
apiVersion: microsoft.resources.azure.com/v1alpha1api20200601
kind: ResourceGroup
metadata:
name: asodemo-rg
namespace: asodemo
spec:
location: westus2
---
# Now, we'll define the Azure PostgreSQL Flexible Server.
apiVersion: microsoft.dbforpostgresql.azure.com/v1alpha1api20210601
kind: FlexibleServer
metadata:
name: ${SERVER}
namespace: asodemo
spec:
location: westus2
owner:
name: asodemo-rg
version: "13"
sku:
name: Standard_D4s_v3
tier: GeneralPurpose
administratorLogin: ${USERNAME}
administratorLoginPassword: ${PASSWORD}
storage:
storageSizeGB: 128
---
# And the database belonging to the server.
apiVersion: microsoft.dbforpostgresql.azure.com/v1alpha1api20210601
kind: FlexibleServersDatabase
metadata:
name: votedb
namespace: asodemo
spec:
owner:
name: ${SERVER}
charset: utf8
---
# We'll also add a firewall rule to allow our cluster to access the server.
apiVersion: microsoft.dbforpostgresql.azure.com/v1alpha1api20210601
kind: FlexibleServersFirewallRule
metadata:
name: asodemo-allow-all
namespace: asodemo
spec:
owner:
name: ${SERVER}
# The following address range allows anybody to connect to this server.
# This should only be used for demo purposes and not in production!
# There are other ways to control server access which are not covered here, you can see more about it here:
# https://docs.microsoft.com/azure/postgresql/flexible-server/concepts-security#network-security
startIpAddress: 0.0.0.0
endIpAddress: 255.255.255.255
---
# Finally, we'll create a Kubernetes secret to connect our application to the Azure PostgreSQL Flexible Server.
apiVersion: v1
kind: Secret
metadata:
name: postgres-secret
namespace: asodemo
stringData:
USERNAME: "$USERNAME"
PASSWORD: "$PASSWORD"
SERVER: "$SERVER.postgres.database.azure.com"
DATABASE: "votedb"
PORT: "5432"
Watch Azure Service Operator and these YAML definitions in action in the quick demo below. If you'd like to walk through this demo on your own, follow this tutorial here.
Learn more about Azure Service Operator.
Walk through tutorials.
