DevOps на Amazon AWS
Ефективността, която дава използването на облачните услуги, е една от основните тенденции за трансформация на много ИТ компании днес. Автоматизация на всички процеси по пътя от кода на GIT до внедряването доРазработванеи / илиПроизводство, както и последващо наблюдение, реакция при инциденти и др. (което също може и трябва да бъде автоматизирано) - всичко това, ако не отменя, то значително променя много общопризнати ITIL практики. Поглед към процесите DevOps от гледна точка на Amazon AWS: как те могат да бъдат внедрени в неговите услуги в рамките на концепцията IaaC (Инфраструктура като код) - всичко това ще бъде дадено по-късно в поредица от статии заCode-услуги на Amazon AWS:CodeCommit,CodeBuild,CodeDeploy,CodeDeploy3>CodePipeline ,CodeStar.
Целта на тази статия не е образователна програма за DevOps, а не банално дублиране на вече налични материали от оригиналния източник. Целта е да се представи внедряването на DevOps в услугите на Amazon AWS в общ вид, от който всеки е свободен да избере желаната опция. Целевите читатели са тези, които са запознати поне със съществуването на Amazon AWS, планират да използват неговите възможности в работата си, да прехвърлят своите процеси там частично или изцяло. Предоставените услуги на Amazon AWS се умножават с висока скорост, броят им вече надхвърли кръглата граница от 100 броя, така че дори и тези с добър опит с AWS могат да намерят полезно да разберат какво е новото, нещо, което може би просто са пропуснали, и това може да се използва успешно в работата им.
Не (само) кубчета
Няколко общи, но важни думи за някой, особено за тези, които нямат достатъчно опит с Amazon AWS. Кубчетата, изобразени в логото, логически правилно предават основната идея: Amazon AWS -това е конструктор, който дава набор от услуги и от който всеки може да сглоби каквото му трябва. Но точно този момент на „кубоцентричност” може да отблъсне някои, ако желаният куб (услуга) не задоволява нуждите му. В този случай трябва да запомните, че една и съща задача може да бъде решена с помощта на различни услуги, много услуги могат до голяма степен да се дублират една друга и следователно услугата Amazon AWS, която не отговаря на вашите заявки, не отменя използването й по никакъв начин, а само дава причина да намерите подходяща. В крайна сметка услугите на Amazon AWS се появиха в резултат на експлоатация предимно за собствени нужди. Има хиляди малки екипи, работещи в Amazon AWS (наричат гидва пица екипа), всеки от които е свободен да избира свой собствен начин на работа (език, операционна система, структура, протоколи и т.н.), което означава, че услугите, налични в Amazon AWS, трябва първоначално да поддържат цялото разнообразие от такива зоопарк, работещи само в рамките на самата компания Amazon AWS.
Това е особено важно за Amazon AWSCode-услугите, които не са предназначени просто да ви кажат какво да използвате, но да ви дадат, от една страна, възможност да се интегрирате с вашите вече познати, съществуващи и дебъгвани процеси и инструменти, от друга страна, да предложите собствена реализация, която обикновено е най-ефективна в рамките на използването на функционалността на Amazon AWS.
Amazon AWS DevOps Builder
Дори да имате добро разбиране на всеки куб поотделно, далеч не винаги е ясно коя къща може да бъде построена от тях. Затова нека се опитаме да съберем тези услуги в една снимка, за да получим обща представа за това какво може да се сглоби от такъв конструктор. Ако изберетеCode-услуги и ги свържете с познати процеси, получаватенещо като този дизайн:
AWS CodeCommit
Най-очевидната и разбираема услуга е изпълнението на GIT от Amazon, което напълно го повтаря. Няма разлики от GIT по отношение на работа и взаимодействие (екип), всъщност е необходим за директна интеграция в структурата на услугите на AWS, включително за организиране на достъп чрез услугиIAM. Самият код се съхранява наS3.
AWS CodeBuild
Сървър за изграждане - за проекти, които изискват изграждане преди внедряване, като Java. По подразбиране той стартира базиран на Ubuntu контейнер, но можете да посочите свой собствен.
Поддържа интеграция с Jenkins чрез плъгин.
В допълнение към сглобяването могат да се извършват тестове по подобен начин. И въпреки че това не е основната му цел, тя може да бъде избрана за такава.
Следователно AWSCodeBuildсъщо присъства във фазата „Тест“.
AWS CodeDeploy
Услуга за внедряване на код, който с помощта на предварително инсталиран агент и гъвкави настройки работи във всяка среда. Специална разлика е, че агентът работи не само с виртуални машини на Amazon AWS, но и с „външни“, което ви позволява централно да разполагате с най-разнообразен софтуер, вкл. и локално.
AWS CodePipeline
Както можете да видите от основната диаграма, той взаимодейства с предишните три услуги, като ги стартира в правилната последователност и всъщност автоматизира процесите на DevOps.
Позволява ви да организирате разклонения на процеси, да изпълнявате услуги на трети страни (например за тестване), да правите паралелни разклонения, да изисквате потвърждение (Действия за одобрение), преди да започнете следващия етап. Като цяло това е централният инструмент за организиране на DevOps на Amazon AWS.
AWS CodeStar
Услуга, която по същество дублираCodePipeline, но изострена за по-лесно стартиране и конфигуриране, което се решава с помощта на широк набор от готови шаблони (за пакета език на приложението) и наистина удобно табло за управление с плъгини, които имат известна интеграция с услугата за наблюдение (CloudWatch) и плъгин за интегриране с Jira.
Amazon AWS IaaC услуги
Услугите на Amazon AWS, които прилагат концепцията Infrastructure as Code са:
Доста често възникват въпроси коя от тях да изберете и защо трите услуги са предназначени за едно и също нещо (разгръщане на инфраструктура и приложения), разположено в основната диаграма на етапВнедряване. Накратко, тяхното използване може да бъде представено като:
Тоест, за да направите нещо бързо (и това не означава, че е лошо), това е някаква стандартна функционалност (например прост уебсайт) - удобно е да използватеElastic Beanstalk. Ако това е сложен проект с множество вложени елементи и сериозни изисквания за мрежови настройки, тогава използването наCloudFormationе незаменимо. Като нещо средно - изглежда, че използваOpsWorks, базиран на Chef.
В действителност обаче (и обикновено се използва при сложни проекти) комбинация от трите (или комбинация):CloudFormationиздига основната инфраструктура (VPC, подмрежи, хранилища, създава необходимите роли в IAM за достъп и т.н.), след което стартираOpsWorks-стека, който вече може гъвкаво да конфигурира вътрешния компонент за работещи виртуални машини. И за удобство на процеса на разработка,CloudFormationможе също така да увеличи стека за компонентиElastic Beanstalk, така че разработчиците, използващи .ebextensions, да могат самипроменете някои параметри на работещо приложение (броя и вида на използваните виртуални машини, използването наБалансиране на натоварванетои т.н.) просто чрез промяна на прост конфигурационен файл в папката с код, когато промените се прилагат (включително в инфраструктурата на приложението) автоматично след извършване.
AWS Lambda
В допълнение към изброените услуги, други услуги могат да бъдат включени в процесите на DevOps. Ето защо, ако се опитате да си представите общата схема на използваните услуги, тогава картината може да се окаже много объркваща (по-долу е само условен пример).
Освен това, тъй като отделните услуги се разглеждат по-подробно, ще се появи объркваща и неразбираема схема в разбираем набор от инструменти, където всеки може да избере това, от което се нуждае.
Общо за схемата за общи услуги на Amazon AWS,които могат да бъдат включени в процесите на DevOps. Най-популярното обвързване е нещо като:CodePipeline/CodeCommit+ElasticBenstalk/OpsWorksкатоDeploy. И за "бърз поглед" -CodeStarе добър. Вярно е, чеAWS CodeStarе платен, но факторът цена целенасочено не е взет предвид тук, за да се даде най-напред обща представа за избора, тъй като всеки компонент може да бъде взет по желание, включително използване на необходимия чрез плъгини на популярни CI / CD проекти като Jenkins comrades.