Безстрашен урок: Опитайте по-интелигентен CLI за AWS

Анри Бинщок е главен директор по иновациите в Wallix и съавтор на проекта с отворен код Awless.

Когато облакът беше само за виртуални машини, инструменти като Chef или Puppet ни помогнаха лесно да подготвим нашите виртуални машини. Единственото нещо, което имаше значение, беше да се осигурят екземпляри, които съдържаха целия необходим код и данни. Но сега, когато Amazon Web Services се увеличи до повече от 90 услуги, взаимодействието с AWS API става основната част от работата.

Как трябва да управляваме инфраструктурата на AWS и какви интерфейси да използваме? Повечето начинаещи започват с AWS Console, графичният интерфейс по подразбиране, докато опитни системни администратори обикновено предпочитат интерфейс за команден ред (CLI). Проблемът е, че AWS CLI не е удобен за потребителя. Тъй като интегрира целия API на AWS, той разкрива огромна повърхност по отношение на команди, флагове и опции.

Awless се ражда от нуждата ни от бърз, мощен и лесен за използване CLI за управление на AWS. С Awless можете да създавате и стартирате AWS инфраструктура, започвайки от нулата, и винаги да получавате четлив изход (както за хора, така и за програми), да изследвате и заявявате всички облачни ресурси (дори офлайн), да се свързвате с екземпляри и да създавате, актуализирате и изтриване на облачни ресурси. Освен единични командни редове, Awless поддържа шаблони, които позволяват по-високи нива на автоматизация. И накрая, но не на последно място, Awless се стреми да гарантира най-добрите практики по подразбиране и сигурността.

Тъй като има толкова много услуги на AWS, често е важно да се намери и покаже йерархия от услуги от командния ред. Можем да групираме услуги по функционалност - като изчисляване и база данни. Но преминаването през всяка от тях изчерпателно е досадно, тъй като към настоящия момент има не по-малко от 15 услуги около съхранение и база данни, без да се броят четири услуги за мигриране на данни и девет услуги за анализ, които са пряко свързани с използването на данни.

Намираме по-лесно групирането на услуги чрез облачна готовност. В тази статия ще разкажем подробно как да използваме Awless за създаване и управление на облачни ресурси за реална употреба, разполагане на готови за производство екземпляри на WordPress. Ще използваме следните ресурси на AWS:

  1. VM услуги EC2 (Elastic Compute Cloud) и ELB (Elastic Load Balancing);
  2. Услуги на високо ниво, които се изпълняват във виртуални машини, но се управляват от AWS, като RDS (услуга за релационна база данни) или ElastiCache (за опашки);
  3. „Безсървърни“ услуги, които се изпълняват във виртуални машини с множество клиенти, като S3 (съхранение на обект) или Lambda (изпълнение с една функция).
Уоликс

Започнете с Awless

Регистрирайте се за AWS и създайте първи акаунт с AdministratorAccessправа. Внимателно отбележете вашия ключ за достъп и секретен ключ.

Инсталирайте Awless

Awless се предлага в GitHub . Ние предлагаме предварително изградени двоични файлове и пакети Homebrew за MacOS:

>brew tap wallix/awless 

>brew install awless

Можете да проверите дали Awless е правилно инсталиран, като стартирате:

>awless version

Awless се моделира след популярни инструменти за команден ред като Git. Повечето команди са под формата на:

>awless verb [entity] [parameter=value ...]

Тази статия ще даде 360-градусов преглед на реалните производствени натоварвания на AWS, започвайки от нулата. За по-голяма яснота пропускаме всички стъпки за потвърждение и някои изходни стъпки, тъй като Awless винаги иска да потвърди команди, които създават, актуализират или изтриват ресурси.

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

Можем да издадем първата си команда Awless, като изброим нашите виртуални частни облаци (VPC). Тъй като това е първото ни изпълнение, ще трябва да въведем някои необходими данни, за да конфигурираме Awless:

>awless list vpcs

Welcome to awless! Resolving environment data...

Please choose an AWS region:

ap-northeast-1, ap-northeast-2, ap-south-1, ap-southeast-1, ap-southeast-2, ca-central-1, cn-north-1, eu-central-1, eu-west-1, eu-west-2, sa-east-1, us-east-1, us-east-2, us-gov-west-1, us-west-1, us-west-2

Value ? > us-west-2

Syncing region ‘us-west-2’...

Cannot resolve AWS credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) Please enter access keys and choose a profile name (stored at /Users/john/.aws/credentials):

AWS Access Key ID? AKIAIINZQI7WIEXAMPLE

AWS Secret Access Key? hYWZBVOusePEPSr5PkscplskB84fjbgUEXAMPLE

Choose a profile name? admin

✓ /Users/john/.aws/credentials created

✓ Credentials for profile ‘admin’ stored successfully

All done. Enjoy!

You can review and configure awless with `awless config`.

Now running: awless list vpcs

|     ID ▲     | NAME | DEFAULT |   STATE   |     CIDR      |

|--------------|------|---------|-----------|---------------|

| vpc-1d1df679 |      | true    | available | 172.31.0.0/16 |

Създайте потребител на AWS

Сега ще използваме Awless, за да създадем нов потребител на AWS и да му дадем достатъчни права, използвайки администраторския профил. Създаваме потребителя Джон и неговия ключ за достъп:

>awless create user name=john 

>awless create accesskey user=john aws_access_key_id = AKIAIOSFODNN7EXAMPLE

aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Do you want to save in your .aws/credentials? (y/n) y

Entry name in .aws/credentials? [default] john

Сега, когато Джон съществува, той се нуждае от набор от разрешения. Ще предоставим на Джон пълен достъп до услугите EC2, RDS, Auto Scaling, CloudFront и S3, които ще използваме в тази статия:

>awless attach policy service=ec2 access=full user=john 

>awless attach policy service=rds access=full user=john

>awless attach policy service=s3 access=full user=john

>awless attach policy service=autoscaling access=full user=john

>awless attach policy service=cloudfront access=full user=john

След като Джон е напълно функционален потребител, ще преминем към неговия профил за следващите стъпки:

>awless config set aws.profile john

Ще използваме AWS, за да създадем високодостъпно, управлявано внедряване на WordPress, съчетаващо виртуални машини, управлявани и безсървърни услуги. Основната ни цел е показана по-долу. Ще трябва да се справим с три „предизвикателства на devops“, за да го постигнем, като използваме съответно инфраструктурни услуги на AWS, управлявани услуги и безсървърни услуги.

Уоликс

Предизвикателство 1: Повдигнете и преместете приложението към EC2

Lift and shift е най-бързият за мигриране на наследени приложения към облака и се възползвайте от гъвкавостта и икономическите предимства на облачните платформи. В този случай ще започнем с внедряването на двигател на WordPress и неговата база данни в една VM. Клиентите ще се свържат директно с виртуалната машина.

Уоликс

Създайте VPC

Преди да продължим със създаването на виртуалната машина, първо трябва да създадем мрежови ресурси:

  • A private network (or VPC)
  • An Internet gateway for this VPC
  • A subnet using the Internet gateway

Awless will prompt for any missing parameters with autocompletion. Here we use a mix of both provided (param=value) and prompted parameters:

>awless create vpc cidr=10.0.0.0/16 name=wordpress-vpc 

>awless create internetgateway

[OK] id=igw-1234567

>awless attach internetgateway

Please specify (Ctrl+C to quit, Tab for completion):

internetgateway.id? [Tab]

internetgateway.id? igw-1234567

internetgateway.vpc? @wo[Tab]

internetgateway.vpc? @wordpress-vpc

Awless puts forward the best practice to use names rather than resource IDs. As such, @resource-name is the identifier of the resource named “resource-name.”

Let’s create a public subnet to host our WordPress instance, and attach a route table that routes the Internet traffic to the VPC’s Internet gateway:

>awless create subnet cidr=10.0.0.0/24 [email protected] name=wordpress-public-subnet 

>awless update subnet [email protected] public=true

>awless create routetable [email protected]

>awless attach routetable [email protected]

        Please specify (Ctrl+C to quit, Tab for completion):

        routetable.id?[tab]

        *select the ID of the routetable you created above*

>awless create route cidr=0.0.0.0/0

        Please specify (Ctrl+C to quit, Tab for completion):

route.gateway? *the ID of the internet gateway you attached to the VPC above*

route.table? *the ID of the routetable you created above*

Note that each action in Awless is about as simple as it can get. Although we follow a comprehensive step-by-step approach, Awless allows us to get through the tedious process of setting up an infrastructure much faster than with the graphical console or the AWS CLI.

Create an SSH keypair and a security group

The cloud network is now ready. Before creating the instance, we need an SSH key pair, to connect to the instance later. In a single command, Awless generates an SSH key pair locally and registers it on AWS:

>awless create keypair name=johnkey

A best practice is to give minimal access to any resource, so we will only accept HTTP connections from all the Internet and SSH from our outgoing IP address. To do that, we create and configure a security group:

>awless create securitygroup [email protected] description=\”HTTP public + SSH access\” name=wordpress-secgroup 

>MY_IP=$(awless whoami —ip-only)

>awless update securitygroup [email protected] inbound=authorize cidr=$MY_IP/32 portrange=22

>awless update securitygroup [email protected] inbound=authorize cidr=0.0.0.0/0 portrange=80

Provision the application with AWS user data

We will now provision our WordPress instance through AWS user data. Here we will use the script available on GitHub:

>awless create instance [email protected] keypair=johnkey name=wordpress-instance userdata=//raw.githubusercontent.com/zn3zman/AWS-WordPress-Creation/16a52aef4f618d558d61197df4e4eca4c015277f/WP-Setup.sh [email protected]

You can use awless show to get information about any resource, such as the public IP address of our WordPress instance:

>awless show wordpress-instance

Можете да се свържете с IP адреса от изхода на командата, за да осъществите достъп до вашата услуга WordPress (макар че може да се наложи да изчакате няколко минути, за да бъде осигурена екземпляра правилно).

Фондация WordPress

По подразбиране Awless ще създаде тип t2.micro (1 vCPU, 1 GB RAM), използвайки Amazon Linux. Можете да актуализирате стойностите по подразбиране, като използвате awless config set:

>awless config set instance.type m4.large 

>UBUNTU_AMI=$(awless search images canonical:ubuntu —id-only —silent)

>awless config set instance.image $UBUNTU_AMI

До този момент сме изградили няколко ресурси. Използвайки awless list, ние можем да изброим потребители, екземпляри, подмрежи и всички други видове ресурси (при условие, че вашият AWS профил има достатъчно права, разбира се). Например можем да изброим екземпляри:

>awless list instances 

|       ID ▲        |   ZONE   |        NAME        | UPTIME  |

|-------------------|----------|--------------------|---------|

|i-00268db26b0d0393c|us-west-1c| wordpress-instance | 57 mins |

[...]

Awless предоставя мощна функция, която позволява лесни връзки към екземпляри със SSH. Зад кулисите Awless автоматично ще получи IP адреса на потребителския модел, ще познае потребителското име и ще се свърже с двойката ключове, която създадохме по-рано:

>awless ssh wordpress-instance

If you want to delete the WordPress instance, you can run awless delete instance [email protected]. You can do it now, as we will create a more advanced deployment in the next challenge.

How to use Awless templates

All the steps in this challenge can be described as a sequence of Awless commands, where the results of previous commands (for instance, the ID of the Internet gateway) are used as inputs to subsequent commands. Because Awless provides a built-in templating system, you could encapsulate all of Challenge 1 in a template and run it with:

>awless run //raw.githubusercontent.com/wallix/awless-templates/bcd0dd41b1524eeac1e53d12b2998bc56689c517/simple_wordpress_infra.aws

Awless offers a powerful feature that enables you to revert most changes applied to an AWS infrastructure. For instance, you can delete the whole infrastructure created by a template in a single command: awless revert revert-id. To find a given revert-id, awless log lists all of the commands previously applied to the cloud infrastructure, with both their output and their ID:

>awless log # find the ID to revert >awless revert 01BM6D1YRZ5SSN5Z09VEEGN0HV

Challenge 2: Use AWS managed services

Предишното ни внедряване е функционално, но доста занаятчийско. Нашият блог се захранва от един екземпляр в една зона за достъпност (AZ). Сега искаме да създадем високодостъпен блог с балансиращ товар, два екземпляра в различни AZ и репликирана база данни, която се споделя от нашите инстанции. Вместо да стартираме собствена база данни в екземпляр, ще използваме AWS RDS, управляваната услуга на Amazon за SQL бази данни. Използването на управлявана услуга предоставя много предимства, включително клъстериране, управлявана защита и архивиране.

Уоликс

За да разполагаме с високодостъпни ресурси, трябва да ги разпределим в подмрежи в различни зони за достъпност (AZ) и да балансираме товара чрез еластично балансиране на натоварването.

Уоликс

За това предизвикателство ще създадем следното:

  • Един балансьор на товара за разпределение на товара между екземплярите
  • Две публични подмрежи, които да се свържат с балансиращия товар интернет
  • Две частни подмрежи в различни AZ (напр. Us-east-1a, us-east-1e) за хостване на инстанциите
  • Една група за автоматично мащабиране за управление на мащабирането на екземпляри на WordPress
  • Един NAT шлюз в една публична подмрежа, за да позволи изходящи повиквания за осигуряване на екземпляри
  • Един публичен фиксиран IP (еластичен IP) за NAT шлюза
  • Един екземпляр RDS за MariaDB се репликира автоматично в частните подмрежи

Ще изградим тази инфраструктура, като стартираме Awless шаблони. Първият шаблон създава подмрежи и маршрутизация. Най- {hole}нотацията позволява параметри, за да се напълни динамично по време на управлението на шаблона. Най- $referenceнотацията позволява обратно номерата на създадените ресурси.