Awless Tutorial: Probieren Sie eine intelligentere CLI für AWS aus

Henri Binsztok ist Chief Innovation Officer bei Wallix und Mitentwickler des Awless Open Source-Projekts.

Wenn es in der Cloud nur um virtuelle Maschinen ging, haben uns Tools wie Chef oder Puppet dabei geholfen, unsere VMs einfach vorzubereiten. Das einzige, was zählte, war die Bereitstellung von Instanzen, die den gesamten erforderlichen Code und die erforderlichen Daten enthielten. Jetzt, da Amazon Web Services auf mehr als 90 Dienste angewachsen ist, wird die Interaktion mit der AWS-API zum Hauptteil der Arbeit.

Wie sollen wir die AWS-Infrastruktur verwalten und welche Schnittstellen sollten wir verwenden? Die meisten Anfänger beginnen mit AWS Console, der Standard-GUI, während erfahrene Systemadministratoren im Allgemeinen eine Befehlszeilenschnittstelle (Command Line Interface, CLI) bevorzugen. Das Problem ist, dass die AWS CLI nicht benutzerfreundlich ist. Da die gesamte AWS-API integriert ist, wird eine enorme Oberfläche in Bezug auf Befehle, Flags und Optionen verfügbar gemacht.

Awless entsteht aus unserem Bedürfnis nach einer schnellen, leistungsstarken und benutzerfreundlichen CLI zur Verwaltung von AWS. Mit Awless können Sie eine AWS-Infrastruktur von Grund auf neu erstellen und ausführen und immer lesbare Ausgaben (sowohl für Menschen als auch für Programme) erhalten, alle Cloud-Ressourcen (auch offline) untersuchen und abfragen, eine Verbindung zu Instanzen herstellen sowie erstellen, aktualisieren und Cloud-Ressourcen löschen. Über einzelne Befehlszeilen hinaus unterstützt Awless Vorlagen, die einen höheren Automatisierungsgrad ermöglichen. Zu guter Letzt möchte Awless intelligente Standardeinstellungen und bewährte Sicherheitsmethoden sicherstellen.

Da es so viele AWS-Services gibt, ist es häufig wichtig, eine Hierarchie von Services über die Befehlszeile zu finden und anzuzeigen. Wir können Dienste nach Funktionen wie Computer und Datenbank gruppieren. Es ist jedoch mühsam, jeden einzelnen von ihnen ausführlich durchzugehen, da es zum jetzigen Zeitpunkt nicht weniger als 15 Dienste rund um Speicher und Datenbank gibt, ohne vier Datenmigrationsdienste und neun Analysedienste, die in direktem Zusammenhang mit der Datennutzung stehen.

Wir finden es einfacher, Dienste nach Cloud-Bereitschaft zu gruppieren. In diesem Artikel wird detailliert beschrieben, wie Awless zum Erstellen und Verwalten von Cloud-Ressourcen für einen realen Anwendungsfall, die Bereitstellung produktionsfähiger WordPress-Instanzen, verwendet wird. Wir werden die folgenden AWS-Ressourcen verwenden:

  1. VM-Dienste EC2 (Elastic Compute Cloud) und ELB (Elastic Load Balancing);
  2. High-Level-Services, die in VMs ausgeführt werden, aber von AWS verwaltet werden, z. B. RDS (Relational Database Service) oder ElastiCache (für Warteschlangen).
  3. Serverlose Dienste, die in mandantenfähigen VMs ausgeführt werden, z. B. S3 (Objektspeicher) oder Lambda (Ausführung einzelner Funktionen).
Wallix

Beginnen Sie mit Awless

Melden Sie sich bei AWS an und erstellen Sie ein erstes Konto mit AdministratorAccessRechten. Notieren Sie sorgfältig Ihren Zugangsschlüssel und Ihren geheimen Schlüssel.

Installieren Sie Awless

Awless ist bei GitHub erhältlich . Wir bieten vorgefertigte Binärdateien und Homebrew-Pakete für MacOS:

>brew tap wallix/awless 

>brew install awless

Sie können überprüfen, ob Awless ordnungsgemäß installiert ist, indem Sie Folgendes ausführen:

>awless version

Awless ist nach gängigen Befehlszeilentools wie Git modelliert. Die meisten Befehle haben folgende Form:

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

Dieser Artikel bietet einen 360-Grad-Überblick über die tatsächlichen Produktions-Workloads in AWS, beginnend bei Null. Aus Gründen der Übersichtlichkeit lassen wir alle Bestätigungen und einige Ausgabeschritte aus, da Awless immer nach Befehlen fragt, mit denen Ressourcen erstellt, aktualisiert oder gelöscht werden.

Erste Schritte mit Awless

Wir können unseren ersten Awless-Befehl ausgeben, indem wir unsere Virtual Private Clouds (VPCs) auflisten. Da dies unser erster Lauf ist, müssen wir einige notwendige Daten eingeben, um Awless zu konfigurieren:

>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 |

Erstellen Sie einen AWS-Benutzer

Wir werden jetzt Awless verwenden, um einen neuen AWS-Benutzer zu erstellen und ihm mithilfe des Administratorprofils ausreichende Rechte zu erteilen. Wir erstellen den Benutzer John und seinen Zugangsschlüssel:

>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

Jetzt, wo John existiert, braucht er eine Reihe von Berechtigungen. Wir gewähren John vollen Zugriff auf die Dienste EC2, RDS, Auto Scaling, CloudFront und S3, die wir in diesem Artikel verwenden werden:

>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

Jetzt, da John ein voll funktionsfähiger Benutzer ist, wechseln wir für die nächsten Schritte zu seinem Profil:

>awless config set aws.profile john

Wir werden AWS verwenden, um eine hochverfügbare, verwaltete WordPress-Bereitstellung einzurichten, die VMs, verwaltete und serverlose Dienste kombiniert. Unser Hauptziel ist unten abgebildet. Um dies zu erreichen, müssen wir uns drei „Devops-Herausforderungen“ stellen und dabei AWS-Infrastrukturdienste, verwaltete Dienste bzw. serverlose Dienste nutzen.

Wallix

Herausforderung 1: Heben Sie eine Anwendung an und verschieben Sie sie auf EC2

Lift and Shift ist die schnellste Migration von Legacy-Anwendungen in die Cloud und profitiert von der Flexibilität und den Kostenvorteilen von Cloud-Plattformen. In diesem Fall werden wir zunächst eine WordPress-Engine und ihre Datenbank in einer einzelnen VM bereitstellen. Clients stellen eine direkte Verbindung zur VM her.

Wallix

Erstellen Sie eine VPC

Bevor wir mit der VM-Erstellung fortfahren, müssen wir zunächst Netzwerkressourcen erstellen:

  • 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

Sie können über die Befehlsausgabe eine Verbindung zur IP-Adresse herstellen, um auf Ihren WordPress-Dienst zuzugreifen (obwohl Sie möglicherweise einige Minuten warten müssen, bis die Instanz ordnungsgemäß bereitgestellt wurde).

WordPress Foundation

Standardmäßig erstellt Awless unter Amazon Linux einen Typ t2.micro (1 vCPU, 1 GB RAM). Sie können Standardwerte aktualisieren, indem Sie Folgendes verwenden 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

Bis zu diesem Punkt haben wir mehrere Ressourcen aufgebaut. Mit awless listkönnen wir Benutzer, Instanzen, Subnetze und alle anderen Arten von Ressourcen auflisten (vorausgesetzt, Ihr AWS-Profil verfügt natürlich über ausreichende Rechte). Zum Beispiel können wir Instanzen auflisten:

>awless list instances 

|       ID ▲        |   ZONE   |        NAME        | UPTIME  |

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

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

[...]

Awless bietet eine leistungsstarke Funktion, die einfache Verbindungen zu Instanzen mit SSH ermöglicht. Hinter den Kulissen erhält Awless automatisch die IP-Adresse der Instanz, errät den Benutzernamen und stellt eine Verbindung zu dem zuvor erstellten Schlüsselpaar her:

>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

Unser früherer Einsatz ist funktional, aber ziemlich handwerklich. Unser Blog wird von einer einzelnen Instanz in einer einzelnen Verfügbarkeitszone (AZ) betrieben. Wir möchten jetzt ein hochverfügbares Blog mit einem Load Balancer, zwei Instanzen in verschiedenen AZs und einer replizierten Datenbank erstellen, die von unseren Instanzen gemeinsam genutzt wird. Anstatt unsere eigene Datenbank in einer Instanz auszuführen, verwenden wir AWS RDS, den von Amazon verwalteten Dienst für SQL-Datenbanken. Die Verwendung eines verwalteten Dienstes bietet viele Vorteile, einschließlich Clustering, verwaltete Sicherheit und Sicherungen.

Wallix

Um über hochverfügbare Ressourcen zu verfügen, müssen diese in Subnetzen in verschiedenen Verfügbarkeitszonen (AZs) verteilt und die Last durch elastischen Lastausgleich ausgeglichen werden.

Wallix

Für diese Herausforderung erstellen wir Folgendes:

  • Ein Load Balancer zum Verteilen der Last auf die Instanzen
  • Zwei öffentliche Subnetze, die dem mit dem Internet verbundenen Load Balancer zugeordnet werden sollen
  • Zwei private Subnetze in verschiedenen AZs (z. B. us-east-1a, us-east-1e) zum Hosten der Instanzen
  • Eine automatische Skalierungsgruppe zum Verwalten der Skalierung von WordPress-Instanzen
  • Ein NAT-Gateway in einem öffentlichen Subnetz, um ausgehende Anrufe für die Instanzbereitstellung zu ermöglichen
  • Eine öffentliche feste IP (Elastic IP) für das NAT-Gateway
  • Eine RDS for MariaDB-Instanz wird automatisch in den privaten Subnetzen repliziert

Wir werden diese Infrastruktur aufbauen, indem wir Awless-Vorlagen ausführen. Die erste Vorlage erstellt Subnetze und Routing. Mit der {hole}Notation können Parameter während der Ausführung der Vorlage dynamisch gefüllt werden. Die $referenceNotation ermöglicht Rückverweise auf erstellte Ressourcen.