Die Zukunft der Cloud-nativen Softwareentwicklung mit Radius

Der Aufstieg der Plattformtechnik

Im Laufe der Jahre hat sich der Prozess der Softwareentwicklung stark verändert. Die Art und Weise, wie Anwendungen heute erstellt, bereitgestellt und verwaltet werden, ist völlig anders als noch vor zehn Jahren. Ursprünglich setzte unsere Branche auf monolithische Architekturen, bei denen die gesamte Anwendung eine einzige, einfache, zusammenhängende Einheit war. Dieser Ansatz machte den Entwicklungsprozess anfangs einfach, aber mit zunehmender Komplexität der Anwendungen wurde die Wartung und Skalierung immer schwieriger. Jede Änderung erforderte ein komplettes Redeployment, was zu langen Entwicklungszyklen und einem erhöhten Fehlerrisiko führte. Darüber hinaus konnte ein einziger Fehler in der Software ein ganzes System zum Absturz bringen.

Ständig wachsende Komplexität

Um diese Einschränkungen zu überwinden, gingen wir zu einer serviceorientierten Architektur (SOA) über. SOA zerlegt Anwendungen in kleinere, unabhängige Dienste, die über ein Netzwerk miteinander kommunizieren. Dieser modulare Ansatz verbesserte die Wartbarkeit und Skalierbarkeit von Anwendungen, da jeder Dienst unabhängig entwickelt, bereitgestellt und skaliert werden konnte. Allerdings brachte SOA auch eine Reihe komplexer Aspekte mit sich, wie z.B. die Notwendigkeit einer robusten Kommunikation zwischen den Diensten und die Verwaltung der Dienste. Hinzu kommt, dass Dienste, die von mehreren Schichten anderer nachgelagerter Dienste abhängen, zu kaskadierenden Fehlern führen, so dass ein einziges Problem immer noch zu einer weitreichenden Nichtverfügbarkeit führen kann.

DevOps

Die Einführung von DevOps markierte einen kulturellen und operativen Wandel in der Softwareentwicklung. DevOps betonte die Zusammenarbeit zwischen Entwicklungs- und Betriebsteams, brach Silos auf und förderte eine Kultur der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) sowie eine agile Arbeitsweise. Dieser Ansatz ermöglichte eine schnellere, zuverlässigere und effizientere Softwarebereitstellung durch die Automatisierung der Infrastrukturverwaltung und der Bereitstellungsprozesse. Die Konzentration auf Zusammenarbeit und Automatisierung verbesserte die Effizienz der Softwareentwicklung erheblich. Die Einführung einer DevOps-Kultur hat die kognitive Belastung der Teammitglieder erhöht, da sie sich mit CI/CD und Automatisierung vertraut machen müssen.

Microservices

Aufbauend auf den Grundsätzen von SOA wurden mit der Microservices-Architektur Anwendungen weiter in eigenständige, autonome Geschäftsfunktionen zerlegt. Jeder Microservice konzentrierte sich auf eine bestimmte Geschäftsfunktion und konnte unabhängig entwickelt, implementiert und skaliert werden. Diese Granularität verbesserte die Agilität und Skalierbarkeit, brachte aber auch Herausforderungen bei der Verwaltung von Serviceabhängigkeiten, Kommunikation und Datenkonsistenz mit sich, was die kognitive Belastung der Teammitglieder weiter erhöhte.

Container und Orchestrierung

Die Verwendung von Containern vereinfachte die Anwendungsbereitstellung erheblich, indem eine Anwendung zusammen mit ihren direkten Abhängigkeiten wie Bibliotheken, Frameworks und Inhaltsdateien verpackt wurde. Die zuverlässige Ausführung von Containern in großem Maßstab führte zur Einführung von Container-Orchestratoren wie Kubernetes. Kubernetes ist in der Lage, containerisierte Workloads auf einem Cluster virtueller Maschinen auszuführen und bietet viele zusätzliche Funktionen. DevOps-Teams mussten lernen, wie sie ihre Anwendungen containerisieren und in einem Orchestrator bereitstellen können, was die Komplexität nochmals erhöhte.

Wolke

Etwa zur gleichen Zeit wurde die Cloud als Umgebung für die Ausführung von Software immer beliebter. Wir begannen, Cloud-native Software zu entwickeln. Die Verwendung von IaaS- und PaaS-Diensten anstelle von selbst entwickelten und gehosteten Tools beschleunigte die Arbeit der Teams erheblich. Der Nachteil war, dass sie erst einmal verstehen mussten, welchen Cloud-Dienst sie wann nutzen sollten. Keine leichte Aufgabe, wenn man bedenkt, dass Azure zum Zeitpunkt der Erstellung dieses Artikels mehr als 200 Dienste und Produkte umfasst.

Licht am Ende des Tunnels

Heute sind wir beim Plattform-Engineering angelangt, einem Bereich, der die besten Praktiken und Tools aus früheren Methoden nutzt, um die Entwicklung, Bereitstellung und Verwaltung von Anwendungen zu optimieren. Dies ist ein wichtiger Schritt zur Verringerung der kognitiven Belastung von Produktteams. Platform Engineering bietet eine standardisierte Umgebung, die Tools und Prozesse integriert, um die Zusammenarbeit und Effizienz zu verbessern. Es abstrahiert viele der Komplexitäten der zugrundeliegenden Infrastruktur und ermöglicht es den Entwicklern, sich auf die Bereitstellung von Funktionen und die Wertschöpfung zu konzentrieren, anstatt sich um betriebliche Details zu kümmern. (Wenn Sie mehr über Platform Engineering lesen möchten, lesen Sie den Artikel 'War der Linksruck der richtige Schritt?' von Sander und Chris!) An dieser Stelle kommt Radius ins Spiel. Radius wurde entwickelt, um die Entwicklung und Bereitstellung von Cloud-nativen Anwendungen zu vereinfachen. Die Kernfunktion von Radius ist der Anwendungsgraph, der die Beziehungen und Abhängigkeiten innerhalb von Anwendungen darstellt. Er kann im Radius Portal, das mit dem Produkt installiert wird, oder mit der Radius CLI visualisiert werden. Dies ermöglicht die Zusammenarbeit zwischen Personen mit einer Entwicklungsrolle und Personen mit einer Betriebsrolle.

Was ist Radius und wie hilft es Entwicklern?

Radius wurde ursprünglich von Microsofts Inkubationsteam entwickelt. Heute ist es ein Open-Source-Projekt und Teil der Cloud-Native Computing Foundation (CNCF), einer Organisation, die Open-Source Cloud-native Projekte unterstützt. Radius wurde entwickelt, um die Herausforderungen der modernen Cloud-nativen Softwareentwicklung zu meistern. Da die Cloud-native Architektur für viele IT-Unternehmen zum Standard wird, kann die Verwaltung der Komplexität von Anwendungen in verschiedenen Umgebungen kompliziert sein. Radius bietet eine Plattform, die den gesamten Lebenszyklus von Cloud-nativen Anwendungen vereinfacht. Sie überbrückt die Kluft zwischen Entwicklern und Betreibern und ermöglicht die Zusammenarbeit.

Anwendungen

Eine der wichtigsten Funktionen von Radius ist der Anwendungsgraph. Graphen stellen die Beziehungen und Abhängigkeiten zwischen verschiedenen Komponenten einer Anwendung, wie z.B. Datenverarbeitung, Datenspeicherung, Messaging und Netzwerk, visuell dar. Dieser visuelle Ansatz vereinfacht das Verständnis und die Verwaltung von komplexen Anwendungen. Durch die Darstellung der Interaktion zwischen verschiedenen Diensten können Entwickler schnell verstehen, wie sie funktionieren. Anhand des Anwendungsgraphen lässt sich auch leicht erkennen, wie die Anwendung zu betreiben ist und welche Abhängigkeiten als PaaS-Dienste und welche als Container implementiert werden sollten. In Radius werden Anwendungen mithilfe der Bicep-Sprache definiert. Bislang war Bicep eine domänenspezifische Sprache für die Bereitstellung von Azure-Ressourcen. Jetzt wurde sie erweitert und umfasst nun auch Radius-Ressourcen, Kubernetes-Ressourcen und Dapr-Ressourcen. (Sie unterstützt sogar EntraID, aber das liegt außerhalb des Rahmens dieses Artikels.) In dem Fragment unten sehen Sie eine einfache Radius-Anwendung. Sie definiert eine Umgebung, die eine Lebenszyklusphase für die Anwendung festlegt. Sie enthält auch eine Anwendungsdefinition und als Teil der Anwendung und der Umgebung wird ein containerisierter Webserver ausgeführt. (eine Beispielanwendung, die vom Radius-Team erstellt wurde.)

Wenn Sie praktische Erfahrungen mit Radius sammeln möchten, besuchen Sie bitte mein GitHub-Repositorium, um sicherzustellen, dass Sie Zugriff auf die neueste Version der Radius-Dateien haben: https://github.com/loekd/radius-demos

//import Radius resource types
extension radius

//define radius environment
resource env 'Applications.Core/environments@2023-10-01-preview' = {
    name: 'test'
    properties: {
    compute: {
        kind: 'kubernetes'
        namespace: 'test'
        }
    }
}

//define radius application
resource app 'Applications.Core/applications@2023-10-01-preview' = {
name: 'demo01'
    properties: {
    environment: env.id
    }
}

//define container that runs the application
resource container01 'Applications.Core/containers@2023-10-01-preview' = {
    name: 'container01'
    properties: {
        application: app.id
        environment: env.id
        container: {
        image: 'ghcr.io/radius-project/samples/demo:latest'
        imagePullPolicy: 'IfNotPresent'
        ports: {
            web: {
                    containerPort: 3000
                }
            }
        }
    }
}

Umgebungen

In Radius werden Umgebungen verwendet, um den Lebenszyklus von Cloud-nativen Anwendungen zu verwalten. Umgebungen in Radius repräsentieren verschiedene Phasen wie Entwicklung, Test, Staging und Produktion, die jeweils auf eine bestimmte Phase des Lebenszyklus einer Anwendung zugeschnitten sind.

Ressourcengruppen

Radius-Ressourcengruppen sind logische Container, die bei der Verwaltung und Organisation der für die Bereitstellung und Ausführung von Anwendungen erforderlichen Ressourcen helfen. Diese Gruppen enthalten verschiedene Ressourcen wie Umgebungen, Container, Datenbanken und Netzwerkkomponenten, die alle für die Ausführung einer bestimmten Arbeitslast erforderlich sind. Radius nutzt Ressourcengruppen, um den Bereitstellungsprozess zu rationalisieren und die Verwaltung von Ressourcen in Gruppen statt einzeln zu erleichtern. In Zukunft werden Radius-Ressourcengruppen auch als Sicherheitsgrenze fungieren, indem sie rollenbasierte Zugriffskontrollrichtlinien auf dieser Ebene anwenden. Die folgende Abbildung stellt die Beziehung zwischen Anwendungskomponenten, Umgebung und Ressourcengruppe visuell dar. (Die erste Demo-Anwendung verfügt noch nicht über eine Datenbank, aber wir werden sie später hinzufügen).

Ausführen der Demo

Wenn Sie dieses und andere Beispiele selbst ausführen möchten, können Sie am schnellsten loslegen, indem Sie hier einen GitHub Codespace anlegen: https://github.com/codespaces/new/radius-project/samples. Dieser Artikel verwendet v0.37. Führen Sie diesen Befehl aus, um ein Problem im Codespace zu beheben:

@loekd ➜ /workspaces/samples (v0.37) $ sh ./.devcontainer/on-create.sh

Dies sollte die richtige Radius CLI-Version installieren. Die Bicep-Datei der obigen App finden Sie hier: https://github.com/loekd/radius-demos/blob/main/01-Bicep/app_v1.bicep Kopieren Sie die Dateien in Ihren Codespace, bevor Sie sie bereitstellen. Verwenden Sie zum Beispiel curl:

@loekd ➜ /workspaces/samples (v0.37) $ curl -O https://raw.githubusercontent.com/loekd/radius-demos/main/01-Bicep/app_v1.bicep

Stellen Sie außerdem sicher, dass Sie die Vorschau der Erweiterungen für Bicep in der Datei 'bicepconfig.json' aktivieren. Beispiel:

{
    "experimentalFeaturesEnabled": {
        "extensibility": true,
        "extensionRegistry": true,
        "dynamicTypeLoading": true
    },
    "extensions": {
    "radius": "br:biceptypes.azurecr.io/radius:0.37"
    }
}

Überprüfen Sie die Image-Version für die Radius-Erweiterung.

Bereiten Sie Radius für die Anwendung vor. Wählen Sie k3d-k3s-default als Ziel-Kubernetes-Cluster (K3d läuft lokal). Erstellen Sie eine Umgebung mit dem Namen 'test' und einen Namensraum mit dem Namen 'test'. Konfigurieren Sie keine Cloud-Funktionen und richten Sie keine Anwendung ein (da dies bereits mit dem obigen Bicep-Code geschehen ist).

@loekd ➜ /workspaces/samples (v0.37) $ rad init --full

Initializing Radius. This may take a minute or two...

✅ Install Radius v0.37.0
- Kubernetes cluster: k3d-k3s-default
- Kubernetes namespace: radius-system
✅ Create new environment test
- Kubernetes namespace: test
✅ Update local configuration

Initialization complete! Have a RAD time  

Anschließend können Sie Ihre Radius-Anwendung mit dem Befehl rad run ausführen:

@loekd ➜ /workspaces/samples (v0.37) $ rad run ./app_v1.bicep --application demo01 --group test
Building ./app_v1.bicep...

Deploying template './app_v1.bicep' for application 'demo01' and environment 'test' from workspace 'default'...

Deployment In Progress...

Completed demo01 Applications.Core/applications
Completed test Applications.Core/environments
... container01 Applications.Core/containers

Deployment Complete

Resources:
demo01 Applications.Core/applications
container01 Applications.Core/containers
test Applications.Core/environments

Starting log stream...

+ container01-b5b9bf6bc-657p4 › container01
container01-b5b9bf6bc-657p4 container01 [port-forward] connected from localhost:3000 -> ::3000
container01-b5b9bf6bc-657p4 container01 No APPLICATIONINSIGHTS_CONNECTION_STRING found, skipping Azure Monitor setup
container01-b5b9bf6bc-657p4 container01 Using in-memory store: no connection string found
container01-b5b9bf6bc-657p4 container01 Server is running at http://localhost:3000
dashboard-5d64c96ff-9jwf7 dashboard [port-forward] connected from localhost:7007 -> ::7007

Die CLI sammelt die vom Container erzeugten Ausgaben und zeigt sie in Ihrem Terminal an. Außerdem hat die CLI die erforderlichen Port-Weiterleitungen erstellt, so dass Sie über localhost auf die auf dem K3d-Cluster laufende Anwendung zugreifen können. Drücken Sie Control und klicken Sie auf die URL http://localhost:3000 in der Ausgabe, um die laufende Webseite zu sehen. Sie sollte den Text 'Willkommen bei der Radius-Demo' anzeigen.

Klicken Sie in Ihrem Codespace auf Control + C, um das Protokoll und die Portweiterleitung zu beenden

. Als nächstes entfernen Sie die Anwendung, indem Sie das folgende Skript ausführen:

rad app delete demo01 --group test -y

Wiederholen Sie diesen Vorgang für die nächsten Demos.

Rezepte

Radius verwendet auch Recipes. Recipes ermöglichen eine Trennung zwischen IT-Mitarbeitern und Entwicklern, indem sie die Bereitstellung der Infrastruktur für Anwendungsabhängigkeiten automatisieren. Entwickler können auswählen , welche Arten von Ressourcen sie in ihren Anwendungen benötigen, z. B. Mongo-Datenbanken, Redis-Caches oder Dapr-Statusspeicher, während IT-Betreiber definieren , wie diese Ressourcen in ihrer Umgebung bereitgestellt und konfiguriert werden sollen, sei es als Container, Azure-Ressourcen oder AWS-Ressourcen. Bevor Entwickler ein Rezept verwenden können, muss es versioniert und in einer OCI-konformen Registry wie Azure Container Registry veröffentlicht werden. Wenn ein Entwickler eine Anwendung und ihre Ressourcen bereitstellt, stellt Recipes automatisch die erforderliche Backing-Infrastruktur bereit und bindet sie an die Ressourcen des Entwicklers. Recipes unterstützt mehrere Infrastructure as Code (IaC) Sprachen, einschließlich Bicep und Terraform, und kann in einer Umgebung referenziert werden. Durch die Verwendung von Recipes kann eine einzelne Anwendungsdefinition in einer nicht produktiven Umgebung mit einem containerisierten Zustandsspeicher und in einer produktiven Umgebung mit einem Cloud-basierten Speicher wie Cosmos DB ohne Änderungen bereitgestellt werden, indem einfach auf verschiedene Recipes verwiesen wird.

Verbindungen

Rezepte müssen einigen Regeln folgen, damit Radius Abhängigkeiten, die mit Rezepten erstellt wurden, mit Anwendungscontainern verbinden kann. Wenn Sie zum Beispiel eine Datenbank mit einem Rezept bereitstellen, muss der Container, der diese Datenbank verwendet, wissen, wie er sich mit ihr verbinden kann. Radius löst dieses Problem, indem es von einem Rezept verlangt, dass es Details über die bereitgestellte Ressource zurückgibt, z. B. Verbindungszeichenfolgen und/oder Anmeldeinformationen. Diese Details werden als Connections bezeichnet. In dem Skript unten sehen Sie eine Dapr-Anwendung, die ein Rezept verwendet, um ihren Dapr-Statusspeicher zu definieren. Das Rezept wird von der Umgebungsdefinition referenziert. Außerdem wird das Konzept der Bicep-Module verwendet, um Ressourcen aus anderen Dateien zu referenzieren, die die Frontend- und Backend-Elemente für die Anwendung definieren.

Wenn Sie dieses Beispiel implementieren möchten, verwenden Sie die Datei app.bicep

. Die folgende Abbildung stellt die Beziehung zwischen Frontend, Backend, Dapr State store und Redis Database visuell dar. In diesem Fall ist die Verbindung für das Backend konfiguriert, so dass es weiß, welche Komponente des Dapr State store zu verwenden ist.

app.bicep:

extension radius

//define explicit radius environment
resource env 'Applications.Core/environments@2023-10-01-preview' = {
    name: 'test'
    properties: {
        compute: {
        }
        //register recipe using Bicep
        recipes: {
            'Applications.Dapr/stateStores': {
            default: {
                templateKind: 'bicep'
                templatePath: 'acrradius.azurecr.io/recipes/statestore:0.1.0'
                }
            }
        }
    }
}

resource app 'Applications.Core/applications@2023-10-01-preview' = {
name: 'demo02'
    properties: {
        environment: env.id
    }
}

module frontend 'frontend.bicep'= {
    name: 'frontend'
    params: {
        environment: env.id
        application: app.id
    }
    dependsOn: [
        backend
    ]
}

module backend 'backend.bicep'= {
    name: 'backend'
    params: {
        environment: env.id
        application: app.id
    }
}

In dem unten stehenden Fragment sehen Sie den Inhalt der Datei backend.bicep. Beachten Sie, dass die Anwendung über eine Verbindung verfügt, die auf den State Store verweist. Die Anwendung muss die konkrete Implementierung des Stores nicht kennen, sondern nur, wie sie eine Verbindung herstellen kann. Der State Store stateStore02 wird bereitgestellt, indem die Ressource deklariert und der Name des Rezepts default referenziert wird. Radius verwendet die Umgebungsdefinition, um die Vorlage zu finden und sicherzustellen, dass sie erstellt wird. backend.bicep:

import radius as radius

@description('Specifies the environment for resources.')
param environment string

@description('The ID of your Radius Application.')
param application string

// The backend container that is connected to the Dapr state store
resource backend02 'Applications.Core/containers@2023-10-01-preview' = {
    name: 'backend02'
    properties: {
        application: application
        container: {
            image: 'ghcr.io/radius-project/samples/dapr-backend:latest'
            ports: {
                orders: {
                    containerPort: 3000
            }
        }
    }
    //connection provides component name, not connection string
    connections: {
    orders: {
        source: stateStore02.id
        }
    }
    extensions: [
        {
        kind: 'daprSidecar'
        appId: 'backend'
        appPort: 3000
        }
    ]
    }
}

// The Dapr state store that is connected to the backend container
resource stateStore02 'Applications.Dapr/stateStores@2023-10-01-preview' = {
    name: 'statestore02'
    properties: {
        // Provision Redis Dapr state store automatically via Radius Recipe
        environment: environment
        application: application
        resourceProvisioning: 'recipe'
        recipe: {
            name: 'default'
        }
    }
}

Das Beispiel hat zwei Rezepte, eines, das einen containerisierten State Store definiert, und eines, das einen Azure CosmosDb State Store definiert. Sehen Sie sich unten die vereinfachte Version eines Rezepts für Dev/Test an. Es verwendet Kubernetes-Ressourcen zur Bereitstellung von Redis und eine Dapr-Komponente zur Beschreibung. Die Dapr-Komponente wird zurückgegeben, damit Radius sie zum Erstellen von Verbindungen verwenden kann.

Kochrezept 1

(Vollständige Datei: https://github.com/loekd/radius-demos/blob/main/02-Dapr/recipes/stateStoreRecipe.bicep)

extension kubernetes with {
//Kubernetes extension
} as kubernetes

param context object

resource redis 'apps/Deployment@v1' = {
//Kubernetes deployment that deploys Redis containers
}

resource svc 'core/Service@v1' = {
//Kubernetes service that connects to Redis Pods
}

resource daprComponent 'dapr.io/Component@v1alpha1' = {
//Dapr component that describes the State Store
}

//Mandatory output for Radius to connect State Store to App
output result object = {
    resources: [ .. ]
    values: {
    type: daprType
    version: daprVersion
    metadata: daprComponent.spec.metadata
    }
}

Im folgenden Skript sehen Sie eine vereinfachte Version eines Rezepts, mit dem ein Azure Cosmos Db State Store erstellt wird. Indem Sie diese Vorlage in der Umgebung referenzieren, wird die Anwendung mit einem produktionsbereiten State Store bereitgestellt.

Kochrezept 2

(Vollständige Datei: https://github.com/loekd/radius-demos/blob/main/02-Dapr/recipes/cosmos_statestore_recipe.bicep)

param context object
param location string = 'northeurope'
param accountName string = context.resource.name
param databaseName string = context.resource.name
param appId string

// Cosmos DB Account
resource cosmosDbAccount 'Microsoft.DocumentDB/databaseAccounts@2021-06-15' = {
//Azure resource spec
}

resource database 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases@2022-05-15' = {
//Azure resource spec
}

resource container 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2022-05-15' = {
//Azure resource spec
}

resource daprComponent 'dapr.io/Component@v1alpha1' = {
//Dapr component that describes the State Store
}

output result object = {
    resources: [..]
    values: {
        type: daprType
        version: daprVersion
        metadata: daprComponent.spec.metadata
        server: cosmosDbAccount.properties.documentEndpoint
        database: databaseName
        collection: containerName
        port: 443
    }
}

 

Alles zusammenbringen

Sie wissen jetzt, dass Sie verschiedene Umgebungen haben können, die jeweils dieselben Ressourcentypen mit unterschiedlichen konkreten Implementierungen definieren. In Nicht-Produktionsumgebungen können Sie containerisierte Datenspeicher verwenden, wie Redis aus Rezept 1. In Produktionsumgebungen sollten Sie PaaS-Dienste wie Azure Cosmos Db aus Rezept 2 oben verwenden. So würden die Umweltdefinitionen aussehen:

Nicht-Produktionsumgebung

resource env 'Applications.Core/environments@2023-10-01-preview' = {
    name: 'test'
    properties: {
        recipes: {
        //containerized Dapr State store recipe
        'Applications.Dapr/stateStores': {
        default: {
        templateKind: 'bicep'
        templatePath: 'acrradius.azurecr.io/recipes/localstatestore:0.1.2'
    }
}

Produktionsumgebung

resource env 'Applications.Core/environments@2023-10-01-preview' = {
    name: 'prod'
    properties: {
        recipes: {
            //CosmosDb Dapr State store recipe
            'Applications.Dapr/stateStores': {
                default: {
                    templateKind: 'bicep'
                    templatePath: 'acrradius.azurecr.io/recipes/cosmosstatestore:0.1.0'
                }
            }

Wenn Sie dieselbe Anwendungsdefinition in zwei verschiedenen Umgebungen einsetzen, verwendet sie unterschiedliche Statusspeicher. Beachten Sie, dass der Ressourcentyp stateStore02 mit dem Ressourcentyp des Rezepts übereinstimmt und dass stateStore02.properties.recipe.name ('default') auch mit dem Namen des Rezepts in der Umgebung übereinstimmt. Sie können mehrere Rezepte für denselben Ressourcentyp verwenden, indem Sie unterschiedliche Namen verwenden.

resource stateStore02 'Applications.Dapr/stateStores@2023-10-01-preview' = {
    name: 'statestore02'
    properties: {
        // Provision Redis Dapr state store automatically via Radius Recipe
        environment: environment
        application: application
        resourceProvisioning: 'recipe'
        recipe: {
            name: 'default'
        }
    }
}

Networking

Als Letztes müssen wir uns um die Vernetzung kümmern. Bis jetzt haben wir den Zugriff auf die Anwendung über localhost mit Hilfe von Tunneln realisiert. Hierfür können wir ein Gateway verwenden.

Gateway

Normalerweise hat eine Cloud-native App eine webbasierte Schnittstelle. Oft hat sie auch eine API. Mit einem Radius Gateway können Sie beides in derselben Domäne bereitstellen, indem Sie Regeln für die Weiterleitung des Datenverkehrs erstellen. Es bietet grundlegende Unterstützung für das Umschreiben von Pfaden. Sie können einen Gateway auch für TLS-Offloading verwenden. Unten sehen Sie ein Beispiel für einen Gateway, der den Datenverkehr für einen Host namens 'example.com' weiterleitet. Er prüft den Pfad der eingehenden Webanforderung. Wenn der Pfad /api enthält, sendet er die Anfrage an den Container mit dem Namen green. Wenn der Pfad der Anfrage /blue enthält, wird die Anfrage an einen Container namens blue gesendet. Außerdem wird das übereinstimmende Wort blue wegen des Teils replacePrefix aus dem nachgeschalteten Pfad entfernt. Dies zeigt, wie einfaches Request Rewriting in Radius funktioniert. Alle anderen Anfragen werden an den Container nginx gesendet, in dem ein Web-Frontend läuft.

resource gateway 'Applications.Core/gateways@2023-10-01-preview' = {
    name: 'gateway01'
    properties: {
        application: app.id
        environment: env.id
        internal: true
        hostname: {
            fullyQualifiedHostname: 'test.loekd.com'
        }
        routes: [
            {
            path: '/api'
            destination: 'http://green:8080'
            }
            {
            path: '/blue'
            destination: 'http://blue:8082'
            replacePrefix: '/'
            }
            {
            path: '/'
            destination: 'http://nginx:80'
            }
        ]
    }
}

Wenn Sie eine funktionierende Version eines Gateways einsetzen möchten, sehen Sie sich die Datei hier an: https://github.com/loekd/radius-demos/blob/main/03-Gateway/app_gw.bicep

• blue API aufrufen: curl -HHost:test.loekd.com http://localhost/blue/api/color
• grüne API aufrufen: curl -HHost:test.loekd.com http://localhost/api/color
• rufen Sie die Hauptseite auf: curl -HHost:test.loekd.com http://localhost

Fazit

Radius transformiert den Entwicklungs- und Bereitstellungsprozess, indem es die Komplexität moderner Cloud-Umgebungen abstrahiert. Durch die Verwendung von Anwendungen, Verbindungen und Rezepten können sich die Entwickler auf die Entwicklung von Funktionen konzentrieren, anstatt die Infrastruktur zu verwalten. Durch die Definition von Rezepten können Mitarbeiter mit einer operativen Rolle sicherstellen, dass die Infrastruktur konform ist. Der Anwendungsgraph erleichtert es Personen in beiden Rollen, Anwendungen und ihre Abhängigkeiten zu verstehen und zu diskutieren. Zum Zeitpunkt der Erstellung dieses Artikels befindet sich Radius noch in der Anfangsphase. Vor allem in größeren Unternehmen und sobald es allgemein verfügbar ist, könnte Radius jedoch ein wertvolles Werkzeug für Softwareentwicklungsteams sein. Machen Sie noch heute erste Erfahrungen damit, geben Sie dem Team Feedback oder tragen Sie selbst zum Code bei. Das kann auch bedeuten, dass die Beispiele in diesem Dokument veraltet sind und nicht mehr funktionieren. Während des Aufbaus dieser Plattform sind Änderungen nicht ungewöhnlich. Die Konzepte und Ideen werden jedoch wahrscheinlich die gleichen bleiben. Nützliche Links:

• Radius Dokumentation: https://docs.radapp.io/
• Radius GitHub: https://github.com/radius-project
• Radius Beispielanwendungen aus diesem Artikel: https://github.com/loekd/radius-demos
• Grundlage für Cloud Native Computing: https://www.cncf.io/

  Dieser Artikel ist Bestandteil von XPRT.#17. Laden Sie das Magazin herunter hier.