Networking v cloudu: packet capture

Síťaři jistě rádi vzpomínají na doby, kdy servery byly jen fyzické, napojilo se to drátem do switche a dalo se zjistit spoustu věcí, třeba zachytit pakety z konkrétního OS. Virtualizace to všechno zkomplikovala a cloud je jen velký síťový blackbox … ale je to opravdu tak? Azure Network Watcher vám dává náhled do sítě v Azure a několik nástrojů, které vám i v cloudu dopřejí kontrolu nad tím, co se děje. Jedním z nich je packet capture – podívejme se dnes na něj. Pokračovat ve čtení „Networking v cloudu: packet capture“

Očuchávátko, které vám pomůže zjistit co máte a jak s tím do Azure

Bylo pro mě docela překvapení, když jsem zjistil, že Microsoft má volně dostupný nástroj s tajemným názvem Microsoft Assessment and Planning Toolkit (MAP tool). Vyšlo najevo, že je to velmi pěkné očuchávátko, které z vašeho prostředí či z prostředí zákazníka zjistí základní inventární informace (VMka, desktopy, virtualizační platformy, databáze) a k nim řadu dalších zajímavostí jako je využívání uživateli či zátěž a dokáže dát i zajímavé tipy ohledně migrace Oracle do MS SQL nebo VMware do Hyper-V, ale, a to mě zajímá nejvíc, i doporučení k migraci do Azure. Podívejme se jak to funguje a co to umí zjistit. Pokračovat ve čtení „Očuchávátko, které vám pomůže zjistit co máte a jak s tím do Azure“

Infrastruktura jako kód – zrychlete z 0 na 100 s Azure šablonami

Infrastructure as code, tedy schopnost jednotně popsat a automatizovat kompletní infrastrukturu je obvzláště přínosná ve své desired state podobě. Tedy tak, že deklarujete čeho chcete dosáhnout a nějaký robot vás do tohoto stavu uvede. Nemusíte skriptovat krok za krokem ani přidávat „když tohle, pak tohle“ a podobné věci. Váš infrastrukturní předpis je pak dokonalou a spustitelnou dokumentací. Přesně takové jsou ARM šablony. Dnes v jediném článku začneme tou nejjednodušší a na konci už budeme vesele používat vnořené šablony. Pokračovat ve čtení „Infrastruktura jako kód – zrychlete z 0 na 100 s Azure šablonami“

Chef a Azure, úvod do výborné DevOps kombinace

Azure vám umožní perfektně automatizovat svoje infrastrukturní prostředí – virtuální stroje, sítě, firewall pravidla, balancery, storage, a to všechno desired state principy v ARM šabloně. Ale jak se desired state způsobem starat o vnitřek vašich VM? Pro svět Windows se nabízí PowerShell DSC v rámci Azure Automation, ale pro univerzálnější pojetí možná půjdete do Puppet, Chef, Ansible nebo SaltStack. Mám dva oblíbence – Ansible a Chef a ten druhý jmenovaný je s Azure výborně integrovaný. Podívejme se na DevOps s Azure a Chef. Pokračovat ve čtení „Chef a Azure, úvod do výborné DevOps kombinace“

Azure Automation na příkladu změny tieru webové aplikace

Azure platforma v sobě obsahuje obrovské množství automatizace. Škálování počtu VM či nodů hostujících webové aplikace, začleňování do balanceru a asi tisíc dalších věcí. Někdy ale můžete chtít svoje vlastní automatizace a pak můžete například napsat velmi mocné PowerShell skripty, které kromě Azure rozhýbou i vaše operační systémy či aplikace. Jedna věc je ale poslat z notebooku skript do Azure a druhá mít centralizovaný orchestrovaný rámec, který funguje i když se veze váš notebook v metru. To je Azure Automation a dnes si ho vyzkoušíme.

Azure Automation

O co jde? V nejjednodušší podobě si to představte jako sdílený server, kde máte svoje uzavřené PowerShell prostředí (tam si můžete instalovat různé další moduly a jste odděleni od ostatních) a nad tím je systém, který spouští vaše skripty jak potřebujete. Možná v pravidelných časech, možná jako reakci na nějaký alert nebo čeká na webhook na REST zavolání z jiného libovolného nástroje či je integrován s OMS. Tyto skripty mohou nejen ovládat Azure jako takový, ale samozřejmě dělat další operace – přistupovat do operačních systémů, exportovat data z databáze, rozesílat emaily a notifikace uživatelům a tak podobně.

Možná se ptáte proč zapřísáhlý zastánce desired state, tedy deklarativních automatizačních postupů, propaguje workflow model (imperativní přístup), tedy krok za krokem řešení ve skriptech? Tyto dva světy se totiž výborně doplňují. Pro provisioning infrastruktury v Azure bych určitě šel do ARM šablon, případně Terraformu či CloudForms (a pro jednodušší situace možná Ansible či Chef). Pro provisioning vnitřku VM (OS, aplikace) bych volil Ansible, případně Chef či Puppet a pro Windows svět (pakliže váš tým je zaměřen jen tímto směrem) PowerShell DSC. Jsou ale situace, kdy potřebujete procesní přístup. Udělej tohle, pak tamto. Vyzkoušej něco a podle odpovědi postupuj dál. Zjistit si něco z externích zdrojů a zařid se podle toho. To je také velmi důležité, desired state procesní pohled nezachycuje. Někdy tedy bude naprosto ideální použít jednoduše oboje. Azure Automation bude orchestrovat komplexní proces (třeba DR), ale pro některé úkony se rozhodně nemusí stydět zavolat ARM a PowerShell DSC.

Azure Automation ale dokáže tahat i za vaší on-premises infrastrukturu a pro ten účel existuje koncept Hybrid Runbook Worker. Jde v zásadě o agenta, kterého nainstalujete na VM v on-premises a ten komunikuje s Azure Automation (nemusíte tedy otevírat žádné porty dovnitř do vaší infrastruktury, je to bezpečné). Ten si z Azure stáhne zadanou práci a lokálně ji provede.

Azure Automation kromě klasických PowerShell skriptů umožňuje používat také PowerShell Workflow. V čem je jiné? Především jde o schopnost paralelizace, tedy úkony se neřeší sekvenčně jak u běžného skriptu, ale můžete definovat co může být prováděno současně a dramaticky tak zrychlit běh celého workflow. Druhým aspektem je schopnost vytváření checkpointů, tedy komplexní workflow může v určitém místě uchovat svůj stav a vy máte možnost z tohoto bodu pokračovat dál. To nabízí větší robustnost, která je vhodná zejména pro velmi komplexní operace jako je disaster recovery vašeho datového centra.

Posledním velkým bodem je orchestrace úkonů PowerShell DSC, tedy desired state konfigurace vašich Windows strojů. Definujete co v něm chcete nebo naopak nechcete mít a robot to uvede do požadovaného stavu. I to je možné pořídit v rámci Azure Automation.

Vytvořme si automation účet

Nejprve si pojďme vytvořit Azure Automation účet.

Určíme si jméno a lokalitu a také necháme vytvořit Run As účet. Pod ním bude Azure Automation vykonovávat svoje zásahy do Azure, takže víte přesně co udělal robot a co člověk. Máte možnost si s tím pohrát i ručně a mít ještě víc pod kontrolou, ale to já teď nepotřebuji.

Po pár minutách bude náš automatizační účet připraven. Všimněte si, že nám byly vytvořeny i čtyři příkladové Runbooky. Na stránce vidíme přehled Runbooků (zjednodušeně řešeno skriptů), Joby (spuštěné úlohy), Assety (například nainstalované moduly, časové rámce pro kalendář, proměnné apod.), hybridní „makáči“ a věci kolem desired state konfigurace OS (DSC).

Ukázka – škálujeme App Service

Vyzkoušejme si řešení následující situace. Mám App Service Plan v kategorii Basic 2, kde hostuji web appku, API a funkce. Azure mi nabízí možnost automaticky škálovat přidáváním a ubíráním nodů, což je skvělé a rozhodně ideální cesta. Jenže moje situace je specifická – jde o opravdu malinkatou aplikaci, která se v noci vůbec nebude používat. Vždy jí stačí pouze jeden node a v noci ji navštíví maximálně jeden zbloudilý uživatel. Jak to řešit? Co kdybychom na noc přepnuli aplikaci do Free tieru? Zůstane dostupná (ačkoli bez jakékoli garance výkonu, takže naprosto nevhodná pro produkci – ale to mi nevadí), ale neplatím za ni. Ráno bych zas servisní plán přehodil zase do B2. Tohle Azure sám o sobě nezajišťuje (ono to má totiž konsekvence, protože nižší tier třeba nemá všechny vlastnosti vyššího a ty se před tím musí odkonfigurovat). V mém případě tedy ideální pro vyzkoušení Azure Automation, s kterým se dá dělat úplně cokoli.

Takhle vypadá moje prostředí.

Moje skripty budou potřebovat příslušné Azure moduly, tak se podívejme, jaké máme nainstalované v základu.

Jak vidno AzureRM.Websites, který budeme potřebovat, tam není. Přidáme z galerie.

Nejprve budeme potřebovat nejnovější AzureRM.profile modul. Najděte ho a provedeme instalaci.

Najděte Websites modul a nainstalujeme.

 

Tím jsme připraveni. Nejprve jsem si udělal testovací skriptík, který pouštím z notebooku, a který mi ukazuje, v jakém tieru aktuálně moje aplikace běží a zda odpovídá.

while ($true) {
    $time = Get-Date
    $tier = (Get-AzureRmAppServicePlan -ResourceGroupName automation-demo -Name demo-plan).Sku.Size
    $service = (Invoke-WebRequest "https://automationdemofunkce.azurewebsites.net/api/funkce?code=iChXT3UHOTB05jJ6xJtK9rL9sN6C1mt3VGuRhxZsExWlXzz3oyeIxw==").Content
    Write-Host $time.ToLongTimeString() " -> Tier: " $tier "   Odpoved sluzby: " $service
    sleep 1
}

Aktuálně mi píše tohle:

10:58:26  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
10:58:28  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
10:58:31  -> Tier:  B2    Odpoved sluzby:  "Ziju!"

Běžím tedy v „denním režimu“. Připravil jsem následující skript. Ten jako vstupní parametr má jméno resource groupy a servisního plánu (aby byl trochu univerzálnější). Následně se přihlásí do Azure Run As účtem (s tím si nelamte hlavu, já kód zkopíroval z ukázkového skriptu a nehodlám ho měnit). Na konci pak jsou kroky potřebné ke shození servisního plánu do Free vrstvy. Potíž je, že v Basic mají služby by default nastaveno AlwaysOn, tedy že zůstávají plně aktivní i pokud je nikdo nepoužívá. Free vrstva tohle nepodporuje, tedy musí to být vypnuté (pokud dlouho nikdo nepřistupuje, web se uspí a při první požadavku se musí dostat do paměti, takže první request po dlouhé době může trvat třeba pár vteřin). Musíme tedy AlwaysOn povypínat a pak můžeme změnit tier. Vypadá to celkově takhle:

<#
    .DESCRIPTION
        Scale App Services to Free
#>

Param(
  [string]$rgName,
  [string]$planName
)

$connectionName = "AzureRunAsConnection"
try
{
    $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName         

    "Logging in to Azure..."
    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint 
}
catch {
    if (!$servicePrincipalConnection)
    {
        $ErrorMessage = "Connection $connectionName not found."
        throw $ErrorMessage
    } else{
        Write-Error -Message $_.Exception
        throw $_.Exception
    }
}

$PropertiesObject = @{alwaysOn = $false;}
$sites = Get-AzureRmWebApp -ResourceGroupName $rgName
foreach ($site in $sites) {
    Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName $rgName -ResourceType Microsoft.Web/sites/config -ResourceName ($site.SiteName+"/web") -ApiVersion 2015-08-01 -Force
}
Set-AzureRmAppServicePlan -ResourceGroupName $rgName -Name $planName -Tier Free

 

Založme tedy nový Runbook.

Bude typu PowerShell (existuje i grafický editor, ale pokud vládnete PowerShellem, je to podstatně rychlejší).

Vložte zmíněný kód, klikněte Save a pojďme si to otestovat.

Vyplňte parametry.

Teď už stačí kliknout na tlačítko Start. V tento okamžik se vytvoří úloha a je zařazena do fronty. Neznamená to, že se začne provádět hned – Azure řídí zdroje a pokud je moc lidí, budete muset chvilku počkat. SLA na tuto službu zní, že 99,9% vašich jobů bude spuštěno do 30 minut. Většinou jsem zaznamenal čekací doby do deseti minut, v každém případě s tím ale ve svých plánech počítejte (pokud má být něco v 7:00 hotové, skript trvá 10 minut, tak naplánujte spuštění pro jistotu na 6:20).

Tady je výsledek mého sledovacího skriptu.

12:09:51  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
12:09:53  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
12:09:56  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
12:09:58  -> Tier:  F1    Odpoved sluzby:  "Ziju!"
12:10:10  -> Tier:  F1    Odpoved sluzby:  "Ziju!"

Jak vidno vše se povedlo, od teď jedu ve Free tieru. Jsem spokojen, Runbook pojďme publikovat.

Přidejte ještě druhý Runbook, který bude dělat opak:

<#
    .DESCRIPTION
        Scale App Services to B2
#>

Param(
  [string]$rgName,
  [string]$planName
)

$connectionName = "AzureRunAsConnection"
try
{
    $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName         

    "Logging in to Azure..."
    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint 
}
catch {
    if (!$servicePrincipalConnection)
    {
        $ErrorMessage = "Connection $connectionName not found."
        throw $ErrorMessage
    } else{
        Write-Error -Message $_.Exception
        throw $_.Exception
    }
}

$PropertiesObject = @{alwaysOn = $true;}
$sites = Get-AzureRmWebApp -ResourceGroupName $rgName
Set-AzureRmAppServicePlan -ResourceGroupName $rgName -Name $planName -Tier Basic -WorkerSize Medium
foreach ($site in $sites) {
    Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName $rgName -ResourceType Microsoft.Web/sites/config -ResourceName ($site.SiteName+"/web") -ApiVersion 2015-08-01 -Force
}

Výborně. Předpokládejme, že požadavek byl, že se má služba ve všední dny ráno v 7 zapnout a večer v 7 shodit do Free. Založme si tyto časové okamžiky.

Definujme všední dny ráno.

Dále pak večerní vypínání.

Tyto pak nastavíme pro naše dva Runbooky.

Kromě času nastavte také parametry, tedy vstupy našeho Runbooku.

Nastavte pro oba Runbooky a automatizaci máme hotovou. Vyzkoušejme ještě jednu věc. Dejme tomu naše zapínadlo můžeme nechat reagovat na webhook, tedy nespouštět jen na základě času, ale na vyžádání třeba z nějaké jiné aplikace.

Vytvořím webhook s platností jeden rok. URL si skopírujte, budeme ho potřebovat.

Vyzkoušíme si zavolat webhook z notebooku z PowerShellu, ale stejným způsobem to jednoduše udělá vaše aplikace.

Invoke-WebRequest "https://s2events.azure-automation.net/webhooks?token=b0%2fvVr5Xfmukv5URsLmbrZt3rTKbP0lcd9%2b8ZHtye%2fM%3d" -Method Post

Průběh můžete sledovat v GUI. Je tam vidět, že webhook byl úspěšně zavolán a úloha je naplánovaná.

Po chvilce zjišťuji, že moje služba se přepnula do B2. Funguje to.

12:29:05  -> Tier:  F1    Odpoved sluzby:  "Ziju!"
12:29:07  -> Tier:  F1    Odpoved sluzby:  "Ziju!"
12:29:09  -> Tier:  F1    Odpoved sluzby:  "Ziju!"
12:29:12  -> Tier:  F1    Odpoved sluzby:  "Ziju!"
12:29:14  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
12:29:16  -> Tier:  B2    Odpoved sluzby:  "Ziju!"
12:29:18  -> Tier:  B2    Odpoved sluzby:  "Ziju!"

Kolik to bude stát

Nechme pro dnešek stranou PowerShell DSC, který se licencuje na nody (o tomto řešení někdy příště) a podívejme se na orchestrační engine samotný. Jednotkou pro billing je tady čas běhu vašich skriptů. V dnešní ukázce mluvíme o asi 1-2 minutách na spuštění. Pokud se vejdete do 500 minut měsíčně, je pro vás služba zcela zdarma. Placená verze ale není nijak drahá – za 20 hodin čistého času běhu skriptů zaplatíte 2 EUR.

 

Automatizaci mám velmi rád a používal bych desired state všude tam, kde je to možné, tedy ARM šablony pro Azure zdroje, PowerShell DSC pro Windows OS nebo univerzální infrastrukturní Terraform či CloudForms nebo konfigurační Ansible, Chef, Puppet. Jsou ale situace, kdy potřebujete orchestrovat víc věcí dohromady a zásadní je workflow, tedy nějaký proces, postup (teď tohle, pak tamto a nakonec něco dalšího), ne desired state. V takovém případě nad to dejte Azure Automation.

Jak nastavit HPE Data Protector pro zálohování do Azure Storage

Zálohování je jak známo důležité. Nejen, že vám mohou on-premise zdroje havarovat a je dobré mít jejich kopii, ale také můžete chytnout ransomware nebo omylem smazat něco důležitého a pak se budete chtít vrátit v čase. Zálohování vašich on-premise zdrojů do cloudu dává obrovský smysl. Podívejme se, jak některé zálohovací nástroje napojit na Azure Storage. Dnes to bude HPE Data Protector. Pokračovat ve čtení „Jak nastavit HPE Data Protector pro zálohování do Azure Storage“

AlwaysEncrypted jako end-to-end šifrování s Azure SQL Database

Potřebujete všechna data v databázi šifrovaná a to včetně jejich záloh? Na to je ideální použít Transparent Data Encryption (o tom v jiném článku). Je to jednoduché a v Azure SQL doslova na kliknutí. Někdy ale potřebujete šifrovat tak, že ani administrátor databáze data nepřečte. Možná to ani nemusí být na všechna data, ale jen vybrané sloupečky. V ten okamžik je dobré zašifrovat data aplikačně, tedy zcela mimo databázový systém. To má ale nevýhodu – musíte tuto funkci napsat ve své aplikaci, což znamená určitou náročnost. Druhá starost je pak s klíči – kde budete držet klíč k dešifrování dat? Azure má na obě starosti odpověď. Pokračovat ve čtení „AlwaysEncrypted jako end-to-end šifrování s Azure SQL Database“

Lepidlo na aplikace a procesy: Azure Logic Apps

Vaše firemní procesy si v naprosté většině případů nevystačí s jedinou aplikací. Klasické řešení (v korporacích poměrně časté) spočívá například v tom, že asistentky každý pátek přes soubor exportují data z jednoho systému do druhého, spočítají se agregované údaje a manažerům obchodních jednotek posílají emailem report za jejich oddělení, takže ti mohou na pondělní poradě náležitě poplácat tým po zádech. Občas jsem se také potkal s tím, že starší aplikace uměla tak akorát zapsat něco každou hodinu do souboru a psal se skript, který si data stáhne, nahraje do nějaké databáze, kde se nad nimi provede nějaké zkoumání. Co třeba situace, kdy týmy používají různé file share služby (DropBox, Box, …) a v rámci zachování dat je chcete současně nakopírovat do SharePointu nebo OneDrive?

Tyto scénáře můžete pohodlně řešit přes Logic Apps a to bez programování – použijete grafický designér a proces si namodelujete. Pokračovat ve čtení „Lepidlo na aplikace a procesy: Azure Logic Apps“

Správa IT je Big Data problém – začněte to řešit novými prostředky

Byly doby, kdy bylo těžké zjistit co se s IT děje, protože nebyla data. Dnes je to jinak. Naprosto běžně vašich pár set VM a aplikací dokáže vygenerovat několik milionů hlášek a měření za jediný den – a to tradičním produktům způsobuje šok vedoucí k jejich pomalosti až nepoužitelnosti. Moderní nástroje pro správu jsou jiné. Jsou postaveny na Big Data systémech, Machine learning a umělé inteligenci. Dokáží v reálném čase nahlížet do ohromného množství dat, korelovat, analyzovat, vnášet řád a inteligentně aplikovat znalostní bázi. Místo komplikované instalace a pravidelných gigabajtových dobrodružných aktualizací jsou vám k dispozici ve formě služby (SaaS). Přesně takové je Microsoft OMS – Operations Management Suite pro hybridní správu světa Azure i on-premise, Windows i Linux, Hyper-V i VMware. Pokračovat ve čtení „Správa IT je Big Data problém – začněte to řešit novými prostředky“