Microsoft Azure

01Մտածողության մոդելը՝ tenant, subscription-ներ, resource group-եր

Ամենավերևում tenant-ն է՝ քո կազմակերպության Entra ID directory-ն, որը պահում է օգտատերերին, խմբերը և app registration-ները։ Դրա տակ subscription-ներն են, որոնք billing-ի և quota-ի սահմաններ են․ տարածված օրինաչափություն է մեկ subscription production-ի և մեկը non-production-ի համար։ Management group-երը subscription-ներից վեր են՝ policy-ն միանգամից շատերի վրա կիրառելու համար։ Subscription-ի ներսում ամեն ռեսուրս ապրում է resource group-ում՝ մի folder նույն կյանքի ցիկլը կիսող բաների համար, օրինակ՝ մեկ միջավայրի հավելվածը, նրա բազան և Key Vault-ը։ Resource group-ը ջնջելը ջնջում է դրա ներսի ամեն ինչ, ինչը շատ հարմար է test միջավայրերը մաքրելու համար։ Ամեն create, update և delete անցնում է Azure Resource Manager-ով (ARM)՝ անկախ նրանից՝ portal ես օգտագործում, az CLI, Bicep թե Terraform։ AWS-ի համեմատ subscription-ը մոտ է AWS account-ին, իսկ resource group-ը ճշգրիտ համարժեք չունի․ այն ավելի մոտ է tag-ների վրա հիմնված խմբավորման, որի հետ կարող ես գործողություններ անել։

• Tenant (Entra ID) → management group-եր → subscription-ներ → resource group-եր → ռեսուրսներ։
• Մեկ resource group յուրաքանչյուր հավելվածի և միջավայրի համար պարզ է պահում մաքրումն ու թույլտվությունները։
• Ամեն ինչ ARM ռեսուրս է ID-ով, ուստի կարելի է նկարագրել որպես կոդ։

02Hosting-ի տարբերակներ՝ App Service, Container Apps, AKS, Functions

App Service-ը վեբ հավելվածների դասական պլատֆորմն է․ ընտրում ես runtime (Node, PHP, .NET, Python, Java) կամ container, և այն հոգում է սերվերները, TLS-ը և scaling-ը։ Վճարում ես App Service plan-ի համար՝ VM-ների հավաքածու, որը կարող է host անել մի քանի հավելված, ուստի արժեքը ֆիքսված է ըստ plan-ի չափի, ոչ թե ըստ request-ի։ Deployment slot-երը թույլ են տալիս deploy անել staging slot, տաքացնել այն և swap անել production-ի հետ՝ առանց downtime-ի։ Azure Container Apps-ը container-ները գործարկում է serverless ձևով Kubernetes-ի վրա՝ առանց այն բացահայտելու․ autoscaling KEDA կանոններով (HTTP, queue-ներ, cron), scale մինչև զրո, revision-ներ և traffic splitting։ Սա Google Cloud Run-ի ամենամոտ համարժեքն է։ AKS-ը լիարժեք managed Kubernetes է այն թիմերի համար, որոնց պետք է Kubernetes API-ն։ Azure Functions-ը գործարկում է event-driven կոդ․ նոր serverless հավելվածների համար Microsoft-ը խորհուրդ է տալիս Flex Consumption plan-ը, իսկ Linux Consumption plan-ը դադարեցվում է 2028-ի սեպտեմբերին։

03Container-ի deploy Azure Container Apps-ում

Տիպիկ հոսքը՝ ստեղծիր resource group, Azure Container Registry և Container Apps environment (ընդհանուր ցանցի և logging-ի սահման հավելվածների խմբի համար)։ Build և push արա image-ը registry, ապա ստեղծիր container app-ը։ Հավելվածին տուր managed identity և registry-ի վրա AcrPull, որպեսզի registry-ի գաղտնաբառ պետք չլինի։ Ingress-ը այն հասանելի է դարձնում HTTPS-ով գեներացված domain-ի վրա, և կարող ես ավելացնել custom domain անվճար managed certificate-ով։ Scale կանոնները որոշում են replica-ների նվազագույն և առավելագույն քանակը․ զրո նվազագույնը ամենաէժանն է, մեկը՝ խուսափում է cold start-երից։ Secret-ները կարող են ուղիղ հղվել Key Vault-ին, ուստի հավելվածը դրանք կարդում է որպես environment variable-ներ՝ առանց դրանք երբևէ քո pipeline-ում հայտնվելու։

1az group create --name rg-app-prod --location westeurope
2az acr create --resource-group rg-app-prod --name exampleappacr --sku Basic
3az acr build --registry exampleappacr --image api:1.4.2 .
4 
5az containerapp env create --name cae-app-prod \
6  --resource-group rg-app-prod --location westeurope
7 
8az containerapp create --name api \
9  --resource-group rg-app-prod --environment cae-app-prod \
10  --image exampleappacr.azurecr.io/api:1.4.2 \
11  --registry-server exampleappacr.azurecr.io --registry-identity system \
12  --target-port 3000 --ingress external \
13  --min-replicas 0 --max-replicas 10

04Տվյալներ՝ Azure SQL, PostgreSQL Flexible Server, Cosmos DB, Storage

Azure SQL Database-ը managed SQL Server է cloud-ում։ Այն գնում ես vCore կամ ավելի հին DTU մոդելներով․ serverless tier-ը կարող է ավտոմատ pause լինել պարապ ժամանակ և compute-ը գանձել վայրկյանով, ինչը հիանալի է dev բազաների համար։ Open-source stack-երի համար Azure Database for PostgreSQL Flexible Server-ը և MySQL Flexible Server-ը managed instance-ներ են ավտոմատ backup-ներով, zone-redundant high availability-ով և non-production-ի համար stop/start-ով։ Cosmos DB-ն գլոբալ բաշխված NoSQL բազա է մի քանի API-ով (NoSQL, MongoDB, Cassandra)․ այն գանձվում է request unit-ներով, ուստի վատ նախագծված query-ն կամ partition key-ը իրական փող արժե։ Azure Storage account-ները պահում են blob-եր (ֆայլեր), queue-ներ, table-ներ և file share-եր՝ hot, cool, cold և archive tier-երով։ Azure Cache for Redis-ին փոխարինում է Azure Managed Redis-ը, ուստի նոր project սկսելուց առաջ ստուգիր, թե որն է արդիական։

• .NET + SQL Server → Azure SQL Database։
• Laravel / Node + Postgres → PostgreSQL Flexible Server։
• Գլոբալ, ցածր latency-ով NoSQL կանխատեսելի partition-ներով → Cosmos DB։

05Identity՝ Entra ID, RBAC և managed identity-ներ

Entra ID-ն (Azure Active Directory-ի նոր անունը) և՛ քո աշխատակիցների directory-ն է, և՛ քո հավելվածների identity provider-ը։ Մարդկանց համար այն անում է single sign-on, MFA և conditional access, իսկ հավելվածների համար՝ OAuth 2.0 / OpenID Connect app registration-ների միջոցով։ Azure ռեսուրսների վրա թույլտվությունները օգտագործում են Azure RBAC․ role (Reader, Contributor, Storage Blob Data Reader…) նշանակում ես principal-ին որոշակի scope-ում (management group, subscription, resource group կամ առանձին ռեսուրս)։ Developer-ների համար ամենաօգտակար հնարավորությունը managed identity-ն է․ Azure-ը քո App Service-ին, Container App-ին կամ Function-ին տալիս է identity, որը կարող է ավտոմատ token-ներ ստանալ։ Այդ identity-ին role տուր Key Vault-ի, Storage-ի կամ բազայի վրա, և քո կոդը միանում է DefaultAzureCredential-ով՝ առանց որևէ գաղտնաբառի։ CI-ի համար GitHub Actions-ը կարող է login լինել workload identity federation-ով (OIDC)՝ պահված client secret-ի փոխարեն։

1import { DefaultAzureCredential } from "@azure/identity";
2import { SecretClient } from "@azure/keyvault-secrets";
3 
4// Works locally (az login) and in Azure (managed identity), no secrets in code
5const credential = new DefaultAzureCredential();
6const vault = new SecretClient("https://kv-app-prod.vault.azure.net", credential);
7 
8const secret = await vault.getSecret("stripe-api-key");
9console.log(secret.name, "loaded");

06Production խորհուրդներ և գնային թակարդներ

Azure-ը շատ բաներ գանձում է ժամով՝ անկախ նրանից՝ օգտագործում ես, թե ոչ։ App Service plan-ը նույնն արժե զրո կամ տասը հավելվածով։ VM-ը, որը անջատված է OS-ի ներսից, դեռ գանձվում է․ այն պետք է deallocate անես։ Premium հնարավորությունները կարող են զարմացնել․ Application Gateway-ը, Azure Firewall-ը, Front Door-ի premium tier-երը, Bastion-ը և NAT Gateway-ը բոլորն ունեն ֆիքսված ժամավճարներ, որոնք կարող են գերազանցել փոքր հավելվածին։ Log Analytics-ը գանձում է ըստ ingest արված GB-ի, ուստի verbose logging-ով «շատախոս» հավելվածը log-երի վրա կարող է ավելի շատ ծախսել, քան compute-ի․ սահմանիր daily cap և retention։ Առաջին իսկ օրից օգտագործիր Cost Management budget-ներ և alert-ներ, ռեսուրսները tag արա owner-ով և environment-ով, և test միջավայրերը դիր առանձին resource group-երում, որպեսզի մեկ հրամանով ջնջվեն։ Reservation-ները և savings plan-ները իջեցնում են կայուն compute-ի գինը՝ մեկ կամ երեք տարվա պարտավորությամբ։

07Networking՝ VNet-ներ, private endpoint-ներ և public access-ի թակարդը

Default-ով Azure-ի շատ PaaS service-ներ (Storage, SQL, Key Vault, Cosmos DB) ունեն public endpoint-ներ, որոնք պաշտպանված են միայն authentication-ով և ըստ ցանկության IP firewall-ներով։ Production տվյալների համար ավելի ուժեղ օրինաչափությունը private endpoint-ներն են․ service-ը ստանում է private IP քո VNet-ի ներսում, private DNS zone-ը նրա սովորական hostname-ը resolve է անում դեպի այդ IP, և դու անջատում ես public network access-ը։ Հավելվածները հասնում են VNet-ին VNet integration-ով (App Service, Functions Flex և Premium) կամ Container Apps environment-ը VNet-ի ներսում գործարկելով։ Տարածված ձախողումը DNS-ն է․ եթե privatelink zone-ը կապված չէ VNet-ին, հավելվածը դեռ resolve է անում public IP-ն և արգելափակվում է։ Hub-and-spoke տոպոլոգիաները ընդհանուր service-ները (firewall, VPN, DNS) դնում են hub VNet-ում, որը peer է արված հավելվածների spoke-երի հետ։ Յուրաքանչյուր մաս արժեք ունի․ private endpoint-ները գանձվում են ժամով և ըստ GB-ի, Azure Firewall-ը թանկ է փոքր project-ների համար։

1# Private endpoint for a PostgreSQL Flexible Server is set at creation;
2# for Key Vault, deny public access and add a private endpoint:
3az keyvault update --name kv-app-prod --public-network-access Disabled
4 
5az network private-endpoint create --name pe-kv-app-prod \
6  --resource-group rg-app-prod --vnet-name vnet-app-prod --subnet snet-private \
7  --private-connection-resource-id $(az keyvault show -n kv-app-prod --query id -o tsv) \
8  --group-id vault --connection-name kv-conn

08Azure Policy և landing zone-եր

Azure Policy-ն յուրաքանչյուր ARM request գնահատում է կանոնների դեմ՝ մերժել թույլատրված region-ներից դուրս ռեսուրսները, պահանջել tag-եր, մերժել public IP-ները, պարտադրել TLS 1.2, ավտոմատ deploy անել diagnostic setting-ներ։ Effect-ների թվում են Deny, Audit, Modify և DeployIfNotExists, ուստի policy-ները կարող են և՛ արգելափակել, և՛ ուղղել։ Նշանակիր դրանք management group-ի մակարդակում, որպեսզի յուրաքանչյուր նոր subscription ժառանգի դրանք։ Microsoft-ի Cloud Adoption Framework-ը նկարագրում է «landing zone»-եր՝ management group-երի, policy-ների, կենտրոնացված logging-ի, networking-ի և identity-ի նախապես կառուցված կառուցվածք, որին միանում են նոր workload-ները։ Փոքր ընկերության համար դա չափազանց է, բայց հիմնական գաղափարները լավ են փոքրանում՝ platform subscription ընդհանուր բաների համար, առանձին application subscription-ներ, policy-ներ վերևում և infrastructure as code ամեն ինչի համար։ Այնուհետև Defender for Cloud-ը գնահատում է քո անվտանգության վիճակը և նշում սխալ կոնֆիգուրացիաները։

09AKS-ը գործնականում՝ tier-եր, upgrade-ներ և identity

AKS-ն ունի անվճար control plane tier փորձերի համար և Standard tier uptime SLA-ով, ինչպես նաև AKS Automatic, որը նախապես կարգավորում է node autoscaling-ը, անվտանգությունը և monitoring-ը՝ GKE Autopilot-ի ոգով։ Standard cluster-ներում դեռ վճարում ես node VM-ների համար։ Նոր cluster-ների մեծ մասի համար ընտրիր Azure CNI Overlay networking․ pod-երը IP-ներ են ստանում private overlay տիրույթից, ուստի VNet հասցեները չեն սպառվում։ Օգտագործիր Microsoft Entra Workload ID, որպեսզի pod-երը Kubernetes service account-ի միջոցով token ստանան իրենց սեփական managed identity-ի համար՝ secret-ներ mount անելու փոխարեն։ Upgrade-ները կարևոր են․ AKS-ը աջակցում է Kubernetes տարբերակների միայն որոշակի պատուհան, ուստի սահմանիր auto-upgrade channel և planned maintenance window-ներ, օգտագործիր մի քանի node pool (system և user) և upgrade-ները թեստավորիր staging-ում։ Container Insights-ը և managed Prometheus-ը monitoring են տալիս, բայց հետևիր Log Analytics-ի ingestion-ի արժեքին։