{"id":154,"date":"2019-03-18T12:58:20","date_gmt":"2019-03-18T12:58:20","guid":{"rendered":"http:\/\/tachi-it.com\/?p=154"},"modified":"2019-03-22T12:31:37","modified_gmt":"2019-03-22T12:31:37","slug":"azure-arm-und-azure-cli-in-der-praxis","status":"publish","type":"post","link":"https:\/\/tachi-it.com\/azure-arm-und-azure-cli-in-der-praxis\/","title":{"rendered":"Azure ARM und Azure CLI in der Praxis"},"content":{"rendered":"\n

<\/p>\n\n\n\n

In diesem Beitrag m\u00f6chten wir kurz aufzeigen wie einfach es ist, Enwicklungs- und Testumgebungen mit Azure ARM Templates und Azure CLI aufzusetzen. Dadurch wird es m\u00f6glich, autarke Umgebungen zur Featureentwicklung zu erzeugen ohne mit parallelen Entwicklungsarbeiten zu kollidieren.<\/p>\n\n\n\n

Daf\u00fcr haben wir Ausz\u00fcge unserer Procy Infrastruktur Skripte auf GitHub<\/a> bereit gestellt. Das Procy Backend besteht aus verschiedenen Services sowie einer SQL Server Datenbank. Die Services werden in einer Azure Web App<\/a> deployed und die Datenbank in einer SQL Azure<\/a> Instanz angelegt. Beide Services sind Azure bereitgestellte PaaS<\/a> Angebote, so dass unserer Focus auf der Verwendung und nicht der Konfiguration dieser Services liegt. Um den Beispielen folgen zu k\u00f6nnen, ben\u00f6tigt man einen Azure Account<\/a> mit g\u00fcltiger Subscription. Au\u00dferdem m\u00fcssen die Azure CLI<\/a> Tools installiert sein.<\/p>\n\n\n\n

\n\n\n\n

SQL Azure<\/h2>\n\n\n\n

Zum Erzeugen der SQL Azure Umgebung greifen wir auf ein Azure Resource Manager (ARM<\/a>) template zur\u00fcck. In solch einem Template k\u00f6nnen mehrere Ressourcen mit individuellen Einstellungen definiert werden. Unter SQL Azure sind alle Ressourcen definiert, die wir f\u00fcr unsere Umgebung ben\u00f6tigen. Der Output umfasst f\u00fcr uns wichtige Ressourcen wie SQL server und SQL database. Diese beiden Ressourcen werden zu einer Ressource Group hinzugef\u00fcgt. <\/p>\n\n\n\n

Au\u00dferdem ist es m\u00f6glich, Parameter in separaten Files zu hinterlegen, wobei hier die SKU, Leistung, Name usw. ge\u00e4ndert werden k\u00f6nnen. Diese Parameter k\u00f6nnen dann ebenfalls w\u00e4hrend des Deployments \u00fcberschrieben werden. Das Deployment kann mit dem az group deployment create<\/a> command gestartet werden. <\/p>\n\n\n\n

F\u00fcr unser spezielles Beispiel m\u00fcssen wir mindestens folgendes Command absetzen, um das Deployment zu triggern. Vorher sollte man sich mit az login<\/strong> angemeldet sowie die resource group erstellt haben.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Erstellen einer Resource Group<\/h4>\n\n\n\n
az group create \n--name myResourceGroup \n--location myResourceGroupLocation<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Erstellen der SQL Azure Umgebung<\/h4>\n\n\n\n
az group deployment create  
--resource-group myResourceGroup  
--template-file azuredeploy.json  
--parameters @basic.parameters.json  
--parameters sqlserveradminpw=myPassword<\/pre>\n\n\n\n
<\/div>\n\n\n\n
Dabei muss zwingend die Resource Group sowie ein admin password f\u00fcr den SQL server angegeben werden. Au\u00dferdem ist im Beispiel nur ein Paramters File hinterlegt, welches angegeben werden muss, da keine default Werte hinterlegt sind. <\/p>\n\n\n\n
Werden beide oben dargestellten Befehle f\u00fcr die Ressourcengruppe sql-example-basic-rg <\/strong>ausgef\u00fchrt, sollten wir im Azure Portal<\/a> die Ressourcengruppe samt beider Resourcen sehen k\u00f6nnen. Basic im rg Namen bezieht sich hierbei auf das Prameterfile bzw. die Stage, die damit erzeugt wurde.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n
Ben\u00f6tigen wir f\u00fcr ein Feature FeatureXYZ\u00a0<\/strong>eine weitere Datenbank mit gleichen Zugangsdaten, dann k\u00f6nnen wir einfach einen anderen Datenbanknamen w\u00e4hlen und Skript erneut ausf\u00fchren. Im konkreten Beispiel k\u00f6nnen wir f\u00fcr die Datenbank ProcyFeatureXYZ\u00a0<\/strong>folgenden Command absetzen.<\/p>\n\n\n\n
<\/div>\n\n\n\n
az group deployment create  \n--resource-group blog-example-basic-rg  \n--template-file azuredeploy.json  \n--parameters @basic.parameters.json  \n--parameters database_name=ProcyDBFeatureXYZ<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Werfen wir wieder einen Blick auf unsere Resource Group, ist nun eine weitere Datenbank zu sehen, welche mit den gleichen Credentials verwendet werden kann. Einzig der Name der Datenbank muss im Connectionstring getauscht werden. <\/p>\n\n\n\n
<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n
Das wir kein Passwort \u00fcbergeben mussten, ist der Condition(al) Property<\/a> im azuredeploy.json<\/em> file geschuldet. Wird kein Passwort \u00fcbergeben, wird das Deployment des Servers nicht beachtet, was in unserem Fall einer weiteren Datenbank auch nicht notwendig ist. <\/p>\n\n\n\n
<\/div>\n\n\n\n
\"condition\": \"[greater(length(parameters('sqlserveradminpw')) , 0)]\",<\/pre>\n\n\n\n
Das Deployment der Datenbank kann auch \u00fcber Azure CLI commands durchgef\u00fchrt werden. Das ist ausreichend, falls sich die Menge an Konfigurationen in Grenzen h\u00e4lt.  <\/p>\n\n\n\n
<\/div>\n\n\n\n
az sql db create \n-g sql-example-basic-rg \n-s procydbserver \n-n ProcyDBFeatureXYZ \n--service-objective Basic \n--catalog-collation SQL_Latin1_General_CP1_CI_AS<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
M\u00f6chte man Auditing, Azure Advisor, Firewallsettings usw. f\u00fcr alle Datenbanken verwenden, empfiehlt sich die Verwendung des ARM templates wie weiter oben beschrieben. Dadurch wird sicher gestellt, dass alle Datenbanken auf den gleichen Settings basieren.<\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n
Azure Web App<\/h2>\n\n\n\n
Um die notwendigen Backendservices zu deployen, greifen wir auf den Azure Service Azure Web App<\/a> zur\u00fcck. Daf\u00fcr muss ein App Service Plan ausgew\u00e4hlt werden, unter dem die einzelnen Apps erstellt werden k\u00f6nnen. Solange Apps zu einem App Service Plan geh\u00f6ren, werden die Ressourcen geteilt. Im Gegensatz zum SQL Deployment, bestimmen wir hier die Leistung anhand des \u00fcbergeordneten App Service Plans und k\u00f6nnen es nicht je App konfigurieren. Daf\u00fcr k\u00f6nnen verschiedene Entwicklungssysteme aufgesetzt werden, wobei nur f\u00fcr einen App Service Plan bezahlt werden muss.<\/p>\n\n\n\n
F\u00fcr unseren Zweck gen\u00fcgen wenige Einstellungen, so dass wir auf die Verwendung der ARM Templates verzichten und alles mit Hilfe der Azure CLI deployen k\u00f6nnen. Im Infrastructure<\/a> Repository sind alle notwendigen Commands im File deploy-webapp.sh<\/em> im Ordner WebApp <\/em>zu finden.  <\/p>\n\n\n\n
Auch hier sollten wir mit einer separaten Resource Group beginnen, einen App Service Plan und letztendlich die zugeh\u00f6rige App erstellen. Durch die Verwendung von Resource Gruppen erhalten wir eine einfache Kosten\u00fcbersicht und sind in der Lage alle Ressourcen zu l\u00f6schen.<\/p>\n\n\n\n
<\/div>\n\n\n\n
az group create  --name webapp-example-rg --location \"West Europe\"\n\naz appservice plan create --name webapp-example-plan --resource-group webapp-example-rg --sku F1<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Auf Grundlage des erstellten Service Plans, kann nun die erste App angelegt werden. Da wir in diesem Beispiel keine weiteren Settings, wie Programmiersprache, Runtime usw. ben\u00f6tigen, gen\u00fcgt ebenfalls ein einfacher Azure CLI command.<\/p>\n\n\n\n
<\/div>\n\n\n\n
az webapp create --name webapp-example-app --resource-group webapp-example-rg --plan webapp-example-plan<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Nachdem absetzen der Commands sollte im Portal folgendes zu sehen sein. In der Resource Group sind sowohl die App als auch der App Service Plan als eigenst\u00e4ndige Ressource zu sehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n
Bisher konnten wir sowohl die Infrastruktur f\u00fcr die Datenbank als auch das Backend provisionieren. Was aktuell fehlt, ist die Verbidnung zwischen den beiden Services. Daf\u00fcr m\u00fcssen wir den Connection string zur Datenbank setzen. Das k\u00f6nnen wir entweder manuell vornehmen oder auch \u00fcber die Azure CLI abbilden. <\/p>\n\n\n\n
<\/div>\n\n\n\n
az webapp config connection-string set -g webapp-example-rg -n webapp-example-app -t SQLAzure --settings ProcyDbConnectionString=\"yourConnectionString\"<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Unsere Anwendung sucht konkret in den Appsettings bzw. unten den Environment Variablen nach dem ProcyDbConnectionString.<\/em> Der Bezeichner kann nat\u00fcrlich frei gew\u00e4hlt werden und muss mit der App \u00fcbereinstimmen. <\/p>\n\n\n\n
<\/p>\n\n\n\n
Staging Slots f\u00fcr Produktivbetrieb<\/h4>\n\n\n\n
Da es sich lediglich um Entwicklungs-  und Testumgebungen handelt, werden keine Staging Slots<\/a> verwendet. F\u00fcr den Produktivbetrieb sollten jedoch wenigstens zwei Slots verwendet werden. Einen f\u00fcr dir produktiven Betrieb und einen f\u00fcr das letzte stabile System als Backup. Dadurch k\u00f6nnen Rollbacks einfach durchgef\u00fchrt werden.<\/p>\n\n\n\n
\n\n\n\n
Orchestrierung durch Skripte<\/h2>\n\n\n\n
Um die ganzen Commands nicht alle manuell ausf\u00fchren zu m\u00fcssen, haben wir diese in ein einfaches Shell Skript gepackt. In diesem Skript wird ebenfalls der Connectionstring zusammen gebaut und gesetzt. Die Beispiele sind stark Procy<\/em> (urspr\u00fcngliche App) lastig, was bedeutet, dass diese Bezeichner in den Skripten umbenannt werden m\u00fcssten. <\/p>\n\n\n\n
Weiter ist es notwendig, sowohl f\u00fcr das SQL Azure Skript als auch f\u00fcr das WebApp Skript die Parameter DatabaseServer, DatabaseName und SQLAdminPassword zu \u00fcbergeben. Der Datanbankbenutzer (User) kann aktuell nicht ge\u00e4ndert werden! F\u00fcr lokale Zwecke k\u00f6nnte ein weiteres Shell Skript verwendet werden, welches die beiden Skripte nacheinander aufruft und so die komplette Infratsruktur erzeugt. Dabei w\u00e4re die Eingabe bestimmter Parameter nur einmalig notwendig. Wir verwenden daf\u00fcr jedoch AzureDevOps<\/a>. <\/p>\n\n\n\n
Zusammenfassung<\/h2>\n\n\n\n
In diesem Beitrag konnten wir aufzeigen, wie einfach Services in Azure provisioniert werden k\u00f6nnen. Durch die Verwendung von Azure ARM templates sowie der Azure CLI k\u00f6nnen solche Prozesse stark automatisiert und vereinheitlicht werden. <\/p>\n\n\n\n
Durch die Verwendung und Zuordnung von Resource Group’s erhalten wir  zum Einen eine einfache \u00dcbersicht aller Kosten je Gruppe und zum Anderen k\u00f6nnen die Ressourcen leicht entfernt werden, sobald der Kunde beispielsweise den Test des Features abgeschlossen hat.  Somit fallen keine unn\u00f6tigen Kosten an.<\/p>\n\n\n\n
Des Weiteren kann das Thema role-based access control (RBAC<\/a>) in der Praxis sehr wichtig werden, wobei Resource Groups ein wichtige Rolle spielen. F\u00fcr unser Beispiel ben\u00f6tigen wir es nicht zwingend, da der Zugriff auf die spezifischen Azure Resourcen nicht freigegeben wird, sondern der Fokus ausschlie\u00dflich auf dem Testen der deployten Software liegt.<\/p>\n\n\n\n
Im n\u00e4chsten Beitrag werden wir aufzeigen, welche Rolle AzureDevOps, ehemals Visual Studio Team Services (VSTS), dabei spielen kann, eine komplett neue Infrastruktur f\u00fcr einen neuen Kunden aufsetzen zu lassen.<\/p>\n","protected":false},"excerpt":{"rendered":"
In diesem Beitrag m\u00f6chten wir kurz aufzeigen wie einfach es ist, Enwicklungs- und Testumgebungen mit Azure ARM Templates und Azure CLI aufzusetzen. Dadurch wird es m\u00f6glich, autarke Umgebungen zur Featureentwicklung zu erzeugen ohne mit parallelen Entwicklungsarbeiten zu kollidieren. Daf\u00fcr haben wir Ausz\u00fcge unserer Procy Infrastruktur Skripte auf GitHub bereit gestellt. Das Procy Backend besteht aus … 
Weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[17,104,20],"tags":[],"_links":{"self":[{"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/posts\/154"}],"collection":[{"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/comments?post=154"}],"version-history":[{"count":44,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/posts\/154\/revisions"}],"predecessor-version":[{"id":207,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/posts\/154\/revisions\/207"}],"wp:attachment":[{"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/media?parent=154"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/categories?post=154"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tachi-it.com\/wp-json\/wp\/v2\/tags?post=154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}