Разбиране на регистъра на контейнерите на Azure

Когато стигнете до края на тръбопровода за изграждане на devops, ви остава набор от артефакти: двоични файлове, конфигурационни файлове, уеб страници, дори виртуални машини и контейнери. Те са компонентите, които заедно изграждат модерно приложение. Опаковането на колкото се може повече от тези компоненти в контейнер има много смисъл, като ви дава по-опростен модел за внедряване. Но това оставя нов набор от въпроси: Как управлявате тези контейнери и как ги разполагате в глобално облачно приложение?

Услуги като GitHub предлагат частни и публични регистри за вашите компилационни артефакти, използвайки отворени стандарти и отворен код. Azure направи същото, използвайки Docker Registry 2.0 с отворен код като основа за свой собствен регистър на контейнери, съвместим с Open Container Initiative. Не е предназначен да бъде само за контейнери; с нарастващото значение на базираните на Kubernetes облачни приложения, то е предназначено да бъде едно гише за всички ваши артефакти за компилация, съвместими с OCI. Това вече включва диаграми Helm, така че можете да използвате регистъра на контейнерите на Azure (ACR) като център за разполагане на вашите приложения, като използвате Helm 3.0 за доставка до екземпляри на Kubernetes.

Първи стъпки с ACR

Инструменти като Azure Container Registry се считат за частни регистри. Само вие и вашият екип и услуги имате достъп до вашия регистър, като автоматизирате доставката до услугите на Azure, които използват контейнери. Познати инструменти като Azure DevOps и Jenkins могат да бъдат конфигурирани да използват системния регистър като крайна точка за компилация, така че можете да преминете направо от обединяване на заявка за изтегляне към контейнер на Azure, готов за внедряване.

Понастоящем Microsoft предлага три версии на ACR: Basic, Standard и Premium, на три различни ценови точки. Всички те работят с уеб куки, използват Azure Active Directory за удостоверяване и имат възможност да изтриват изображения. Basic има най-ниския капацитет; Premium включва поддръжка за репликация в различни региони и добавя поддръжка за подписване на изображения. Най-вероятно ще използвате Standard, който ви осигурява 100 GB място за съхранение, 60MBps лента за изтегляне и поддържа до 10 уеб куки. Ценообразуването е за регистър на ден, с допълнителни мрежови разходи и отделно таксуване за използване на процесора при изграждане на нови изображения на контейнери.

Създаването на нов регистър на контейнери е относително лесно, като се използва или Azure CLI, или портал. Екземплярите на ACR са свързани с групи ресурси, така че можете да имате отделен регистър за всяко приложение, което стартирате в Azure. След като регистърът е създаден, получавате URL адреса на сървър за вход. Това е крайната точка за интеграция с инструменти на devops или екземпляри на Docker на работния плот на разработчиците ви.

Взаимодействие с регистър ACR

Командата на Azure CLI acrе може би най-полезният начин за взаимодействие с регистър. Влезте и можете да започнете да избутвате изображенията на контейнери към него. Добре е да започнете от работния плот, за да разберете как работи, като маркирате локално изображение на Docker с името на сървъра за влизане в ACR и след това с помощта на docker pushкомандата изпращате изображението в регистъра на ACR, като автоматично създавате подходящото хранилище в Azure. След като изображението е в хранилище на ACR, използвайте инструментите на командния ред, за да изброите файлове, да ги премахнете и дори да използвате команди Docker, за да ги стартирате.

Автоматизирането на ACR може значително да намали натоварването ви, като използвате ACR Tasks. Задачите обединяват това, което би било набор от скриптове на Azure CLI, в прости работни потоци, които управляват общи операции. Например те предлагат поредица от задействания, които автоматизират изграждането на нови изображения, когато се случат промени във вашия конвейер за изграждане или във вашата система за непрекъсната интеграция / непрекъсната доставка (CI / CD).

Едната опция, бързата задача, обхваща всички етапи, използвани за изграждане на набор от файлове в контейнер в една команда. Всичко, от което се нуждаете, е работна директория с вашите файлове и съществуващ регистър на ACR и Dockerfile. Една команда взема тези файлове и използва Dockerfile, за да създаде изображение, като автоматично го съхранява в ACR хранилище. Друга бърза задача стартира изображението на избрания от вас хост.

Съберете ги заедно и имате основен набор от инструменти за тестване на изображения на контейнери. По-сложните внедрявания ще се нуждаят от по-сложни скриптове - например разполагане на контейнер в управляван екземпляр Kubernetes с помощта на AKS. Като алтернатива можете да автоматизирате целия процес, като създадете задача, която следи репозитория на GitHub за промени в клон за разполагане, изграждане на нов образ, когато обедините заявка за изтегляне в клона или направите ангажимент.

Осигуряване на контейнери в ACR

Работата с ACR има предимства за сигурността. Един от големите проблеми, пред който е изправен всеки, който създава модерни приложения, е разбирането и управлението на вашето дърво на зависимостите. Как да разберете дали новата версия на библиотека с ключове или неясен компонент е безопасна за използване? Трябва да можете да се доверите на вашите контейнери, а ACR предлага два начина да гарантирате, че винаги ще внедрявате доверен код.

Първо, той предоставя подписани изображения на контейнери, така че вашият клъстер Kubernetes може да провери дали кодът, който се изпълнява, е кодът, който сте изпратили в системния регистър от вашата система за изграждане. Подписаните изображения гарантират, че никой не е фалшифицирал съдържанието на контейнера, докато той е разположен. На второ място, ACR може да се интегрира с Центъра за сигурност на Azure. Това ви позволява да сканирате изображения, тъй като те се съхраняват в системния регистър, като проверявате не само за уязвимости във вашия код и в основното изображение, но и във всички зависимости, които са включени или са препратени от файла с изображението. Използвайки скенера на Qualys, отчетите на Центъра за сигурност ще ви помогнат да идентифицирате уязвимости с препоръки за поправки.

Нещата стават интересни, когато започнете да използвате вашите ACR екземпляри за повече от контейнери. OCI започна да отваря стандарта на системния регистър за артефакти, като Helm, де факто инструментът за внедряване на приложението Kubernetes, го използва в последната версия. В индустрията се наблюдава многобройно увеличаване на регистрите и хранилищата и има смисъл да се стандартизира по един за всички компоненти на вашето приложение, особено когато всички те са част от едно и също приложение, използвано в облака.

ACR вече поддържа OCI Registry As Storage (ORAS). С помощта на инструмент ORAS можете да натискате и издърпвате всичките си артефакти от едно и също хранилище на ACR. Инсталирайте ORAS на вашите машини за разработчици или добавете поддръжка към вашия конвейер за изграждане. След като влезете в системния си регистър с принципал на услуга на Azure Active Directory, който има права за натискане, използвайте инструмента за команден ред ORAS, за да изпратите нови артефакти в системния регистър.

Използването на инструмент за команден ред в Azure CLI ви дава гъвкавост за изграждане на ORAS, като натиснете избрания от вас инструмент за изграждане, като скрипт, който може да бъде извикан при необходимост. Същият инструмент на командния ред може да изтегля артефакти и можете да го вградите във вашите скриптове за внедряване, така че всички компоненти, които съставляват вашите приложения, да могат автоматично да се разгърнат, когато нова компилация се насочи към вашите хранилища ACR.

Частният код се нуждае от частни хранилища и запазването на вашите контейнери и други артефакти за изграждане в Azure ги поставя там, където са необходими. Пълният процес на изграждане на devops трябва да премине от ангажиране на код към работещо приложение без човешка намеса, като инструменти като Azure Container Registry и свързаната с него автоматизация на задачи са важни компоненти във всеки насочен към Azure конвейер. Кодът не само се съхранява и внедрява автоматично в глобален мащаб, той се сканира за рискове за сигурността всеки път, когато има промяна.