Category Archives: Azure

Connect(); 2017 – přehled oznámených novinek

Od 15. do 17. listopadu proběhla online vývojářská konference Microsoft Connect(); 2017, která přinesla řadu zásadních oznámení a novinek. Pro základní orientaci přináším přehled těch nejdůležitějších. Záznamy jednotlivých session si můžete stále přehrát.

Visual Studio & Developer Productivity

https://blogs.msdn.microsoft.com/visualstudio/2017/11/15/the-latest-in-developer-productivity-and-app-experiences/

Team Foundation Server / Visual Studio Team Services

https://blogs.msdn.microsoft.com/bharry/2017/11/15/connect-announcements/

  • Team Foundation Server 2018 – final release. Přináší pro on-premise funkčnost, kterou již známe z onlinového VSTS:
    • Mobile work item experience – responsivní podoba TFS webu
    • Wiki – jednoduchá Wiki založená na GIT-repository s Markdown soubory (ála GitHub)
    • Git Forks – forking ála GitHub
    • GVFS – viz dále
    • Graphical release definition editor
    • Deployment groups
  • GVFS – Git Virtual File System – umožní efektivní práci s obrovskými repository (ála Windows source codes), kdy jsou na pracovní stanici staženy pouze minimální potřebné soubory a zbytek zůstává „virtuální“ a je stahován dle potřeby
  • Azure DevOps Projects – zjednodušeně řečeno onboarding wizzard pro Azure a VSTS, který pro různé typy projektů (.NET, Java, Node.js, Python, …) založí šablonu aplikace, GIT repo, CI/CD pipeline, atd.
  • YAML – Pipeline as code (public preview) – podpora YAML pro VSTS buildy – víceméně textová podoba vytváření build definic do VSTS.
  • Release management gates – možnost vytváření podmínek pro posun release do dalšího deployment prostředí, např. „žádné nové bugy“ (obecně libovolné Work Item Query), stav Azure Monitoru, či dle výsledku volání libovolného REST API či Azure Function.
  • VSTS Symbol Server (public preview)  – TFS (resp. zatím VSTS) se konečně stává symbol-serverem pro uchovávání a publikování PDB souborů. S každým buildem lze PDB symboly uchovat a následně je získávat do Visual Studia, Windows Debuggeru či jakoukoliv další potřebu.
  • Hosted MacOS Build Agents – ve VSTS se objevila možnost poslat build na Hosted MacOS agenta. Mimochodem je tam nově i Hosted Linux.
  • TFS data import service (general availability) – finální release služby pro import on-premise databáze TFS do online VSTS
  • VSTS CLI (public preview) – command-line tools pro VSTS a TFS, git-like commands, atp.

Data

  • Microsoft SQL Operations Studio (Preview) – odlehčená multiplatformní podoba SQL Server Management Studia
  • Azure Databricks (Preview) – Apache-Spark jako služba na Azure
  • Apache Cassandra API for Azure Cosmos DB (Preview) – jako další možnost připojení na Cosmos DB přibylo API dle Apache Cassandra.
  • Microsoft is joining the MariaDB Foundation – MariaDB – fork MySQL od jejího původního autora, získává podporu Microsoftu coby platinum sponzora tohoto open-source projektu. (Mimochodem věděli jste, že se obě tyto databáze vlastně jmenují po dceři jejich autora? MySQL není „moje“, ale švédská Maruška.)

Xamarin

https://blog.xamarin.com/xamarin-announcements-microsoft-connect-2017/

  • .NET Embedding
  • Xamarin.Forms 2.5
    • Xamarin.Forms Native Forms
    • Xamarin.Forms Layout Compression
    • Xamarin.Forms & XAML Standard
  • Xamarin Live Player
  • Xamarin Workbooks open-sourced

AI – Artificial Intelligence

Zaznělo mnoho dalších drobností a náznaků, spousta produktů releasovalo drobnější updates. Směřující myšlenky se točily rozhodně kolem AI.

Quartz .NET – sekvenční zřetězení jobů [Martin Havel, HAVIT Vzdělávací okénko 2.11.2017]

Záznam z interního vzdělávacího okénka HAVIT z 2.11.2017 je publikován na našem HAVIT YouTube Channel. Téma prezentoval Martin Havel:

Dotčená témata:

  • Co je Quartz
  • Sekvenční spouštění úloh
  • Tři způsoby, jak se zřetězením jobů vypořádat

 

AppService: Nastavení časové zóny pomocí WEBSITE_TIME_ZONE App Setting (a mnoho dalších)

Ve výchozím stavu běží AppServices v UTC. Existuje však téměř nedokumentovaná možnost (nebo minimálně velmi málo známá), kterak časovou zónu aplikace změnit. Stačí přidat konkrétní nastavení mezi Application Settings vaší aplikace (v Azure Portalu) a KUDU se o správný čas postará. Dá se takto nastavit mnoho věcí:

  • WEBSITE_TIME_ZONE, např. Central Europe Standard Time (seznam podporovaných hodnot)
  • SCM_TOUCH_WEBCONFIG_AFTER_DEPLOYMENT = 1/0 – dělá, co říká (default je 1)
  • SCM_TRACE_LEVEL = 1..4 – v rozsahu od 1 do 4 můžete navýšit míru podrobností pro tracing  (default je 1 – nejnižší)
  • Volby pro Build/GIT
  • Volby pro ukládání site na disk a cachování
  • Nastavení verze Node/NPN
  • WEBSITE_LOAD_CERTIFICATES – načtení certifikátů
  • Nízkoúrovňové diagnostické přepínače
  • WEBSITE_DISABLE_SCM_SEPARATION – zajímavě vypadající volba, která vám umožní hostovat vaší aplikaci a SCM (Kudu) ve stejném sandboxu (a potenciálně tak ušetřit zdroje, zejména paměť) – bohužel je tato volba označena jako legacy-obsolete a unsupported (podle všeho funguje, ale ruku do ohně už za to nedávají)
  • …a mnoho dalších

Úplný seznam parametrů najdete v Project KUDU Wiki..

Azure: Ověření existence blobu, pokud mám jeho URI

Pokud máte pouze storage account (CloudBlobClient) a URI blobu v něm, není úplně jednoduché existenci blobu ověřit. Přesněji řečeno při touze použít obvyklou metodu ​​ICloudBlob.Exists()​, musíte mít na daný blob referenci. Pro její získání z URI je tu metoda CloudBlobClient.GetBlobReferenceFromServer(Uri blobUri), která však při svém zavolání dělá HEAD request na blob a snaží se dotáhnout jeho metadata. Pokud blob neexistuje, vyhodí už tato metoda výjimku a na nějaké Exists() se už ani nedostane.

Výjimku lze zachytit s pěkným pattern-matchingem:

ICloudBlob blob;
try
{
    blob = blobClient.GetBlobReferenceFromServer(new Uri(url));
}
catch (Microsoft.WindowsAzure.Storage.StorageException ex)
            when ((ex.InnerException is System.Net.WebException wex)
                    && (wex.Response is System.Net.HttpWebResponse httpWebResponse)
                    && (httpWebResponse.StatusCode == System.Net.HttpStatusCode.NotFound))
{
    // blob does not exist, do whatever you need here
    return null;
}
// further code able to use the blob-reference

Pokud s referencí na blob nepotřebujete dále pracovat, tak samozřejmě můžete jeho existenci ověřit vlastním jednoduchým HTTP HEAD requestem z libovolného HTTP klienta.
Každopádně je zde obskurní už to, že máte na daný blob pouze plné URL. Za příčetných okolností byste měli mít k dispozici strukturovanou informaci o názvu containeru a blobu v něm, což by šlo samozřejmě z URL i vyparsovat.

Azure App Service: Získání full memory dumpu při výskytu určité výjimky

Opakovaně si libuji, co všechno je na Azure App Service z hlediska diagnostiky a správy možné ve srovnání s tradičním webhostingem. Například získat full memory dump je snadné, díky Kudu a SysInternals, které jsou na AppService k dispozici.

…no a pokud ladím konkrétní problém a potřebuji memory dump v momentu výskytu určité výjimky, je to už jenom o správném použití ProcDump ze SysInternals (spustit z Debug Console, kde si aktuální adresář přepnete třeba na LogFiles:


d:\devtools\sysinternals\procdump -accepteula -ma -e 1 -f "FaultException" 9736

…poslední číslo je číslo procesu (získáte z Kudu z Process Exploreru nebo z portálu), v uvozovkách stačí libovolná část názvu typu výjimky (testuje se přes Contains).

Celá věc pak může vypadat třeba takhle:


Kudu Remote Execution Console
Type 'exit' then hit 'enter' to get a new CMD process.
Type 'cls' to clear the console

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

D:\home>
D:\home\LogFiles>d:\devtools\sysinternals\procdump -accepteula -ma -e 1 -f "FaultException" 9736

ProcDump v9.0 - Sysinternals process dump utility
Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

Process: w3wp.exe (9736)
Process image: D:\Windows\SysWOW64\inetsrv\w3wp.exe
CPU threshold: n/a
Performance counter: n/a
Commit threshold: n/a
Threshold seconds: n/a
Hung window check: Disabled
Log debug strings: Disabled
Exception monitor: First Chance+Unhandled
Exception filter: [Includes]
*FaultException*
[Excludes]
Terminate monitor: Disabled
Cloning type: Disabled
Concurrent limit: n/a
Avoid outage: n/a
Number of dumps: 1
Dump folder: D:\home\LogFiles\
Dump filename/mask: PROCESSNAME_YYMMDD_HHMMSS
Queue to WER: Disabled
Kill after dump: Disabled

Press Ctrl-C to end monitoring without terminating the process.

CLR Version: v4.0.30319

[07:57:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:02] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:10] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:20] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:24] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:02] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:10] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:20] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:25] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:59] Exception: E0434F4D.System.ServiceModel.FaultException ("The message with Action '' cannot be processed at the receive
r, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Acti
ons between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and recei
ver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).")
[07:59:59] Dump 1 initiated: D:\home\LogFiles\w3wp.exe_170829_075959.dmp
[08:00:04] Dump 1 writing: Estimated dump file size is 290 MB.
[08:00:11] Dump 1 complete: 290 MB written in 12.1 seconds
[08:00:12] Dump count reached.

D:\home\LogFiles>

Azure PaaS – Praktické zkušenosti, tipy a triky – slides a záznam [TechEd Praha 05/2017]

Slides, dema a záznam z mé přednášky pro TechEd DevCon Praha z 16.5.2017:

Záznam z přednášky je publikován na našem HAVIT YouTube Channel.

Dotčená témata

  • IaaS vs. PaaS vs. XaaS
  • Motivace k Azure PaaS vs. Co vás může odradit
  • Klíčové služby
    • App Service
    • Azure SQL
    • Azure Storage
    • Application Insights
  • Praktické scénáře
    • Deployment (MSDeploy)
    • Práce se soubory IFileStorage
    • Práce s časem (DateTime.Now v UTC vs. ITimeService)
    • Posílání e-mailů (SendGrid)
    • Naplánované úlohy (Quartz.NET, WebJobs, WebJobs SDK, Dashboard)

Azure 4-mins Idle Connection Timeout a jak se s ním vypořádat

Jedna z našich aplikacích migrovaných do Azure začala slavit neúspěchy při volání externí SOAP webové služby – System.Net.WebException: The operation has timed out at… Konkrétně se jednalo o WebJob pro synchronizaci master-dat s ERP systémem zákazníka a pozoruhodné na tom bylo, že z mnoha volaných služeb ERP padala jedna jediná.

Záhy se navíc ukázalo, že volání služby padá pouze z prostředí Azure, volání stejné služby z vývojářského i našeho původního on-premise produkčního prostředí fungovalo. Potvrdilo se to nejenom úspěšným voláním stejné služby z non-Azure prostředí, ale i neúspěšným voláním stejné služby z virtual machine založené pro účely testu v Azure (pro toto se výborně hodí Azure kredit, který je součástí každého MSDN předplatného).

Po chvilce zamyšlení a další chvilce Googlení, se potvrdila hypotéza, že Azure uplatňuje na síťovou komunikaci určité restrikce, zde konkrétně 4-min connection idle timeout a volané webové službě trvalo 5 minut, než nám data z ERP naservírovala. Limit se projevuje a nejenom u příchozích spojení, ale i u spojení odchozích a je potřeba se s ním vypořádat.

Zatímco u příchozích spojení se dá limit konfigurovat na Load Balanceru, u odchozích spojení se předpokládá, že se s ním vypořádáte sami. Principiálně jde totiž o to, že je potřebovat udržovat nějakou aktivitu spojení.

Řešení se nabízí pro různé situace mnoho (např. připravené WCF Azure Net.TCP Keep Alive – net.tcp služba, která periodicky posílá keep-alive signál), v zásadě však většinou není potřeba sahat k ničemu komplikovanému a stačí využít vestavěný keep-alive TCP, který lze v .NET konfigurovat přes ServicePoint.SetTcpKeepAlive(..), resp. ServicePointManager.

Buď můžeme keep-alive konfigurovat globálně pro všechna TCP spojení:

ServicePointManager.SetTcpKeepAlive(true, 5000, 5000);

Nebo nastavení omezit na konkrétní protistranu:

var servicePoint = System.Net.ServicePointManager.FindServicePoint(new Uri(targetWebServiceUrl));
servicePoint.SetTcpKeepAlive(true, 30000, 30000);