Kam s kontejnerovými obrazy? Do registru. Zní to dost triviálně. Azure Container Registry ale není jen o uložení diskového obrazu. K dispozici máte řízení přístupu integrované do Azure Active Directory (a potažmo vašeho AD), build as a service (sestaví vám kontejner rovnou v cloudu, nemusíte to dělat na svém notebooku), automatizované buildy, webhooky nebo globální replikaci. ACR můžete integrovat do svých vývojových nástrojů, CI/CD nebo navázat na akce třeba s Logic App a posílat si zprávy emailem nebo do nějakého moderního komunikačního nástroje jako jsou Microsoft Teams.
Ruční práce s registrem a integrace Azure Active Directory
Nejprve si vytvořme registr. Bude samozřejmě kompatibilní s docker protokolem, takže vám bude fungovat prakticky s čímkoli.
az group create -n acr -l westeurope az acr create -n tomasacrdemo -g acr --sku Standard
To šlo rychle. Jak se k němu ale připojit? Můžete využít jeden zabudovaný administrátorský účet, ale toho se pokuste vyvarovat (ostatně ve výchozím stavu je zakázaný). ACR totiž má řízení přístupu na základě Azure Active Directory. Práva přidělujete stejně jako jiným zdrojům v Azure (RBAC), tedy dáváte je uživatelům či skupinám. Vybrat si můžete Reader (může stahovat image), Contributor (stahovat i publikovat image) a Owner (všechno co předchozí a navíc přidělovat práva dalším).
Pro lidské potřeby použijte přihlášení do registru takto:
az acr login -n tomasacrdemo
Stačí tedy být přihlášen do Azure CLI 2.0 a s tím je spojená celá hora možností zabezpečení včetně vícefaktorového ověřování, identifikace rizikových loginů, podmíněné přístupy (například podle zařízení z kterého se připojujete) a tak podobně. CLI potom vygeneruje časově omezený token a ten uloží bezpečně tak, aby ho příkazová řádka dockeru našla (používá se Docker Credential Helper).
Pokud potřebujete pracovat s obrazy nějakým robotem (ve skriptu, v rámci CI/CD pipeline), použijte AAD service principal. Jde o systémové účty, které rovněž podporují RBAC a které můžete použít přímo v příkazu docker login.
Začneme tedy ručně. Použiji podklady uložené zde: https://github.com/tkubica12/acrdemo-base
Mám tedy velmi jednoduchý Dockerfile:
FROM python:3-alpine RUN pip3 install flask==1.0.1
Ten můžu lokálně buildovat, otagovat identifikátory mého repozitáře a následně odeslat do ACR.
docker build --tag tomasacrdemo.azurecr.io/base:flash . docker push tomasacrdemo.azurecr.io/base:flask
To je celé, kontejnerový obraz je na svém místě.
Build as a Service
Co když potřebujete vybudovat kontejner, ale nemáte na právě používaném zařízení Docker? Zní to nepravděpodobně? Možná máte něco ve Windows Subsystem for Linux (a v tom Docker nejde), něco ve Windows, něco s použitím Docker for Windows. Není problém mezera v cestě? Nechybí vám od administrátora práva, aby váš Docker for Windows mohl natahovat zdrojové soubory s aplikací? Nebo jste aktuálně na tabletu a využíváte Azure Cloud Shell?
ACR nabízí v preview (zatím pouze pro Linux kontejnery) build as a service. Všechno vyřešíme jedním příkazem:
az acr build --registry tomasacrdemo --image base:flask .
Co se stane? Azure CLI zabalí obsah adresáře do build kontextu (aby vám fungovalo třeba COPY), ten včetně Dockerfile odešle do Azure, který během chvilky získá volného agenta, na kterém pro vás provede docker build a výsledek uloží do ACR.
Automatizovaný build
V předchozím odstavci jsme použili build as a service pro sestavení základního image s nainstalovaným Flask pro Python. Berme to jako základní obraz, který pro aplikační týmy připravuje třeba IT se zvláštním zřetelem na bezpečnost (integraci bezpečnostních systémů jako je Aqua Security si ukážeme někdy příště). Teď nad ním vybudujeme aplikační kontejner. Ukázka je tady: https://github.com/tkubica12/acrdemo-app
Tentokrát ale použijeme automatizaci. ACR je připravena pracovat s veřejným i privátním GitHub nebo VSTS a další podporující PAT tokeny pro Git. Funguje to tak, že ACR dostane informaci, že došlo ke změně kódu a automaticky provede vybudování kontejneru. Nejprve tedy na GitHub musím získat osobní token:
S ním pak založíme automatizovaný build task a navážeme ho na můj GitHub repozitář a master branch. Jako image tag použijeme unikátní číslo buildu, které pro nás ACR vygeneruje.
az acr build-task create \
--registry tomasacrdemo \
--name appautobuild \
--image app:{{.Build.ID}} \
--context https://github.com/tkubica12/acrdemo-app.git \
--branch master \
--git-access-token $GIT_PAT
Začneme tím, že trigger vyvoláme ručně.
az acr build-task run --registry tomasacrdemo --name appautobuild
Po chvilce uvidíme svůj aplikační kontejner. ACR provede klon GitHub repozitáře s aplikací a Dockerfile a sestaví obraz. Na logy z buildování se můžeme podívat.
az acr build-task logs --registry tomasacrdemo
Ted už můžeme změnit kód a dát commit do master branch. To automaticky spustí vytvoření nového buildu kontejneru. Protože základní image aplikačního kontejneru je veden ve stejném ACR, změna základního image rovněž udělá automatický trigger a aplikační kontejner se přebuilduje. V okamžiku kdy třeba IT tým zavede nové patche do základního image, ACR vám vytvoří nové verze aplikačních kontejnerů, které na něm staví.
Podívejme se na seznam našich buildů.
az acr build-task list-builds --registry tomasacrdemo -o table BUILD ID TASK PLATFORM STATUS TRIGGER STARTED DURATION ---------- ------------- ---------- --------- ------------ -------------------- ---------- abh appautobuild Linux Succeeded Image Update 2018-07-02T13:57:57Z 00:01:05 abg Linux Succeeded Manual 2018-07-02T13:57:16Z 00:00:40 abf appautobuild Linux Succeeded Git Commit 2018-07-02T13:55:05Z 00:00:50 abe appautobuild Linux Succeeded Manual 2018-07-02T13:53:02Z 00:00:50 abd Linux Succeeded Manual 2018-07-02T13:50:39Z 00:00:55
Nejprve vidíme dva manuální buildy - to je můj base a mnou vyvolaný build aplikačního kontejneru. Dál tam je aplikační build v reakci na Git Commit. Následuje manuální build základního image a aplikační build vyvolaný Image Update, tedy aktualizací základního (FROM) image.
Změna v ACR jako trigger
Triggery fungují i opačně, tedy ACR dokáže zavolat webhook v okamžiku, kdy dojde ke změně, například push nového image. V sekci Webhook si je můžete zaregistrovat a omezit scope třeba jen na vybrané repozitáře (třeba jen pro aplikační kontejner). Vyzkoušel jsem poslat na Requestbin, abych se podíval na strukturu zprávy.
Přistálo mi tohle:
{
"id": "0df7389b-8905-498f-989d-9f80568b9b71",
"timestamp": "2018-07-02T18:35:07.571430398Z",
"action": "push",
"target": {
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1579,
"digest": "sha256:bcd0588795040673a589dea695b5902ffb9f83c2338efdbaeadefec4d935c794",
"length": 1579,
"repository": "base",
"tag": "flask"
},
"request": {
"id": "67a46a97-cec3-4200-adcf-0b39e366db64",
"host": "tomasacrdemo.azurecr.io",
"method": "PUT",
"useragent": "docker/18.03.1-ce go/go1.9.5 git-commit/9ee9f40 kernel/4.13.0-38-generic os/linux arch/amd64 UpstreamClient(Docker-Client/17.12.0-ce \(linux\))"
}
}
Co kdybychom na ACR navázali Azure Logic App a změny publikovali třeba do ChatOps kanálu v Microsoft Teams? Nic složitého. Logic App bude reagovat na request (URL zadáme do ACR) a předchozí výstup použiji pro definici přijímaného schématu, takže mi to Logic App pěkne rozparsuje. Pak už jen napojím svůj Teams kanál a upravím zprávu.
Výsledek vypadá nějak takhle:
Publikování do ACR (nejen) z Microsoft vývojářských nástrojů
Azure Container Registry můžete využívat s naprosto libovolného vývojového nástroje typu IDE, build manager nebo CI/CD. Eclipse, Maven Jenkins, Visual Studio Code, zkrátka cokoli. Samozřejmě ucelené řešení z dílny Microsoft nejen nesmí chybět, ale určitě očekáváte ještě lepší integraci. Třeba nestarat se o přihlašování (vytváření service principal apod.), zakládání registru a tak podobně. Je to jak čekáte. Ve Visual Studio 2017 můžete například vytvořit .NET Core projekt, ten vám rovnou připraví Dockerfile (a vybíráte si jestli Windows nebo Linux), při zmáčknutí F5 rovnou debuggujete v kontejneru a máte k dispozici tlačítko Push:
Stejně tak CI/CD s Visual Studio Team Services dokáže v rámci CI buildu výsledek poslat do ACR.
Přístup z Kubernetes ve stejné subscription
Máte Azure Kubernetes Service ve stejné subscription? Při vytváření AKS jste zadávali (nebo si nechali generovat) service principal účet v AAD. Ten můžete využít k přístupu do registru - netřeba tedy v Kubernetes nic složitě zadávat! Pokud jste si nechali service principal generovat, vytvořil se vám pravděpodobně tak, že má ve scope resource group s Kubernetes zdroji (začíná na písmena MC). Pokud nasadíte ACR to této resource group nemusíte nic dalšího řešit. Pokud chcete ACR do jiné (což mi dává větší smysl), nezapomeňte service principála ACRku přiřadit minimálně v roli Reader.
Přístup z Kubernetes mimo vaši subscription
Pokud máte Kubernetes třeba u sebe a chcete použít ACR, není to problém, ale nedojde k autentizaci na pozadí. Musíte tedy vytvořit ideálně dalšího service principal, dát mu práva na ACR a tento login v Kubernetes založit jako Secret a následně ji přiřadit pri definici Podu použitím imagePullSecrets.
Globální replikace
Co když provozujete globální aplikaci, které běží ve víc regionech? Můžete samozřejmě přistupovat k ACR v jiném regionu, ale to znamená nějakou latenci a poplatky za odchozí data. Dávalo smysl mít repozitář v každém regionu. Jak ale zajistit distribuci obrazů do všech regionů? Pokud zvolíte ACR v SKU Premium je tato funkce pro vás připravena. Provedete Push v jednom regionu a systém sám zajistí replikaci do dalších.
Správa vašich Docker image je zásadní komponta vašeho života s kontejnery. Azure Container Registry vám nabídne službu integrovanou s Azure Active Directory, příjemné SLA i funkce jako jsou build as a service, automatizace, replikace či integrace do dalších nástrojů. Zkuste si to.