Това е глава от Ръководството за изграждане с AWS без сървър, което написах. За повече информация относно намерението и фокусите на ръководството, моля, прочетете Въведение.
Съдържание:
- "Въведение"
- „Въведение без сървър“
- Въведение в облака и AWS
- Инфраструктурата като код (Вие сте тук)
- "АЗ СЪМ"
- VPC
- Ламба
- API Gateway
- DynamoDB
- S3
- CloudWatch
- CloudFront
- Път 53
- SNS
- SQS
- кинезис
- „Семейство инструменти за разработчици“
- „Безсървърни контейнери“
Инфраструктурата като код позволява повтарящо се предоставяне и конфигурация на инфраструктура. Тази концепция е това, което ни позволява да се движим бързо и да се абстрахираме от идеи и модели, които използваме често. Родният за AWS метод за писане на инфраструктура като код използва услуга, наречена CloudFormation.
CloudFormation поглъща нашите заявки под формата на „шаблони“, написани на YAML или JSON (предлагам да използвате YAML) и предоставя инфраструктура според това, което шаблонът посочва в нещо, наречено CloudFormation Stack. След това CloudFormation Stack може да бъде актуализиран или изтрит и множество стекове могат да бъдат създадени въз основа на един и същ шаблон. Харесва ми да мисля за шаблоните на CloudFormation като за декларативен начин за извикване на AWS API за осигуряване на инфраструктура с определени настройки за конфигурация. Подобна идея би било да напишете програма без променливи и твърдо кодиране на всяка стойност. Като се има предвид това, има начини да направите шаблоните на CloudFormation „динамични“ чрез заместване в специфични за средата стойности с помощта на параметри, псевдо параметри, AWS Secrets Manager и AWS Systems Manager Parameter Store.
Изучаването на CloudFormation е добра първа стъпка в изучаването на IaC, но след хиляди редове на YAML е почти неизбежно да започнат да се появяват модели, които биха били по-добре абстрахирани. Има начини да направите това естествено в CloudFormation, като използвате нещо, наречено CloudFormation Nested Stacks; въпреки това не препоръчвам да ги използвате. Чувал съм ужасяващи истории от доверени ресурси, когато става въпрос за поддържане и актуализиране на тези вложени стекове. Моето предложение е или да захапете куршума и да копирате и поставите тези стени от YAML текст, или да разгледате IaC, който използва език за програмиране, за да изгради инфраструктурата.
Прекарайте известно време в облачни и DevOps форуми и за нула време ще има споменавания на трети страни IaC доставчици като Serverless Framework, Hashicorp Terraform или Pulumi, за да назовем само няколко. Някои се поддържат по-актуални от други, като Terraform изглежда е преобладаващият доставчик. Моето предложение обаче е да се придържате към решения на първа страна. Най-новото допълнение към тази менажерия от IaC, използващо познат език за програмиране, е собственият на AWS, наречен CDK или Cloud Development Kit.
Откакто научих и експериментирах с CDK, започнах да мигрирам моя IaC към CDK приложения. CDK е начин за дефиниране на инфраструктура с помощта на език за програмиране вместо YAML шаблони. Когато CDK приложение е „синтезирано“, то извежда CloudFormation в YAML или JSON, така че CDK е ефективно слой върху CloudFormation, с който можем да взаимодействаме с помощта на езици за програмиране, които извеждат статични шаблони.
Имайте предвид, че аз съм софтуерен инженер по душа. Когато научих, че мога да комбинирам знанията си в облака с програмирането, бях развълнуван. Абстрахирането на идеите и превръщането им в повторяеми е основна концепция в програмирането, така че способността да използвам това, което вече знаех от тази арена и да го прилагам към дефиниции на облачни ресурси, ще направи живота ми много по-лесен и кратък.
Виждам много уроци за AWS за начинаещи, които започват с помощта на конзолата на AWS. Въпреки че също получавам известна полза от визуалната проверка, направете всичко възможно да започнете да използвате IaC възможно най-бързо. Ползите са твърде големи, за да станете зависими от използването на конзолата. Две от тези предимства, на които разчитам силно, са репликируемостта и програмното внедряване.
Използването на шаблони на CloudFormation означава, че можем да внедрим стек, знаейки точно какви ресурси ще бъдат предоставени от наше име. Създаването на друга версия на приложение се превръща във въпрос на внедряване на нов стек CloudFormation, използвайки същия шаблон(и) както преди. Тази възпроизводимост ми помага да спя добре през нощта. Ако даден ресурс не успее или някой направи критична ръчна промяна (неща, които се случват през цялото време), всичко, което трябва да направим, е да създадем отново или актуализираме нашия стек CloudFormation, за да може всичко отново да функционира по предназначение.
Използването на шаблони на CloudFormation и съхраняването им заедно с кода, който работи в инфраструктурата в контрола на източника, означава, че можем да активираме процеси на DevOps. Това върви ръка за ръка с репликируемостта. Можем да създадем шаблон CloudFormation веднъж и да го внедрим многократно, за да създадем една и съща инфраструктура на приложенията. CodeBuild, CodeDeploy и CodePipeline са всички инструменти за разработчици, предлагани от AWS, които помагат при внедряването и актуализирането на стекове на CloudFormation въз основа на външни тригери като натискане към GitHub или обединяване на заявка за изтегляне.
В следващите раздели, подчертаващи конкретни услуги, насърчавам експериментирането с тях единствено чрез IaC и CloudFormation. Всички услуги, които използвам и ще спомена в това ръководство, са интегрирани с CloudFormation. Документацията на AWS е добра в тази област (не толкова за всички техни услуги), така че бързо търсене, включително „облачно формиране“ плюс услугата, която се опитвате да предоставите, трябва да доведе до съответната документация.
Следваща глава: IAM Предишна глава: Въведение в облака и AWS Категории: ръководство за изграждане с aws без сървър
Първоначално публикувано в https://thomasstep.com на 4 октомври 2021 г.
