Tutoriel Awless: essayez une CLI plus intelligente pour AWS

Henri Binsztok est directeur de l'innovation chez Wallix et co-créateur du projet open source Awless.

Lorsque le cloud ne concernait que des machines virtuelles, des outils comme Chef ou Puppet nous ont aidés à préparer facilement nos VM. La seule chose qui importait était de fournir des instances contenant tout le code et les données nécessaires. Mais maintenant qu'Amazon Web Services a atteint plus de 90 services, l'interaction avec l'API AWS devient la majeure partie du travail.

Comment gérer l'infrastructure AWS et quelles interfaces devons-nous utiliser? La plupart des débutants commencent avec AWS Console, l'interface graphique par défaut, tandis que les administrateurs système expérimentés préfèrent généralement une interface de ligne de commande (CLI). Le problème est que l'AWS CLI n'est pas conviviale. Parce qu'il intègre l'ensemble de l'API AWS, il expose une énorme surface en termes de commandes, d'indicateurs et d'options.

Awless est né de notre besoin d'une CLI rapide, puissante et facile à utiliser pour gérer AWS. Avec Awless, vous pouvez créer et exécuter une infrastructure AWS, à partir de zéro, et toujours obtenir une sortie lisible (pour les humains et les programmes), explorer et interroger toutes les ressources cloud (même hors ligne), vous connecter à des instances et créer, mettre à jour et supprimer les ressources cloud. Au-delà des lignes de commande uniques, Awless prend en charge les modèles qui permettent des niveaux d'automatisation plus élevés. Enfin, Awless vise à garantir des valeurs par défaut intelligentes et les meilleures pratiques de sécurité.

Étant donné qu'il y a tellement de services AWS, il est souvent important de rechercher et d'afficher une hiérarchie de services à partir de la ligne de commande. Nous pouvons regrouper les services par fonctionnalité, comme le calcul et la base de données. Mais passer en revue chacun d'entre eux de manière exhaustive est fastidieux car il existe, à ce jour, pas moins de 15 services autour du stockage et de la base de données, sans compter quatre services de migration de données et neuf services d'analyse directement liés à l'utilisation des données.

Nous trouvons plus facile de regrouper les services en fonction de la disponibilité du cloud. Dans cet article, nous détaillerons comment utiliser Awless pour créer et gérer des ressources cloud pour un cas d'utilisation réel, le déploiement d'instances WordPress prêtes pour la production. Nous utiliserons les ressources AWS suivantes:

  1. Services VM EC2 (Elastic Compute Cloud) et ELB (Elastic Load Balancing);
  2. Services de haut niveau qui s'exécutent dans des VM mais sont gérés par AWS, tels que RDS (Relational Database Service) ou ElastiCache (pour les files d'attente);
  3. Services «sans serveur» qui s'exécutent dans des machines virtuelles multi-locataires, telles que S3 (stockage d'objets) ou Lambda (exécution d'une seule fonction).
Wallix

Démarrez avec Awless

Inscrivez-vous à AWS et créez un premier compte avec des AdministratorAccessdroits. Notez soigneusement votre clé d'accès et votre clé secrète.

Installez Awless

Awless est disponible sur GitHub . Nous fournissons des binaires pré-construits et des packages Homebrew pour MacOS:

>brew tap wallix/awless 

>brew install awless

Vous pouvez vérifier qu'Awless est correctement installé en exécutant:

>awless version

Awless est calqué sur des outils de ligne de commande populaires tels que Git. La plupart des commandes se présentent sous la forme de:

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

Cet article donne un aperçu à 360 degrés des charges de travail de production réelles sur AWS, en partant de zéro. Pour plus de clarté, nous omettons toutes les étapes de confirmation et de sortie, car Awless demande toujours de confirmer les commandes qui créent, mettent à jour ou suppriment des ressources.

Premiers pas avec Awless

Nous pouvons émettre notre première commande Awless en listant nos Virtual Private Cloud (VPC). Comme il s'agit de notre première exécution, nous devrons entrer certaines données nécessaires pour configurer 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 |

Créer un utilisateur AWS

Nous allons maintenant utiliser Awless pour créer un nouvel utilisateur AWS et lui donner des droits suffisants en utilisant le profil d'administrateur. Nous créons l'utilisateur John et sa clé d'accès:

>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

Maintenant que John existe, il a besoin d'un ensemble d'autorisations. Nous donnerons à John un accès complet aux services EC2, RDS, Auto Scaling, CloudFront et S3 que nous utiliserons dans cet article:

>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

Maintenant que John est un utilisateur pleinement fonctionnel, nous allons passer à son profil pour les prochaines étapes:

>awless config set aws.profile john

Nous utiliserons AWS pour mettre en place un déploiement WordPress géré hautement disponible, combinant des machines virtuelles, des services gérés et sans serveur. Notre objectif principal est illustré ci-dessous. Nous devrons relever trois «défis de devops» pour y parvenir, en utilisant respectivement les services d'infrastructure AWS, les services gérés et les services sans serveur.

Wallix

Défi 1: soulever et déplacer une application vers EC2

Lift and shift est la solution la plus rapide pour migrer les applications héritées vers le cloud et bénéficier de la flexibilité et des avantages de coûts des plates-formes cloud. Dans ce cas, nous commencerons par déployer un moteur WordPress et sa base de données dans une seule VM. Les clients se connecteront directement à la VM.

Wallix

Créer un VPC

Avant de procéder à la création de la VM, nous devons d'abord créer des ressources réseau:

  • 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

Vous pouvez vous connecter à l'adresse IP à partir de la sortie de la commande pour accéder à votre service WordPress (même si vous devrez peut-être attendre quelques minutes pour que l'instance soit correctement provisionnée).

Fondation WordPress

Par défaut, Awless créera un type t2.micro (1 vCPU, 1 Go de RAM) à l'aide d'Amazon Linux. Vous pouvez mettre à jour les valeurs par défaut en utilisant 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

À ce stade, nous avons construit plusieurs ressources. En utilisant awless list, nous pouvons répertorier les utilisateurs, les instances, les sous-réseaux et tous les autres types de ressources (à condition que votre profil AWS dispose bien sûr de droits suffisants). Par exemple, nous pouvons lister les instances:

>awless list instances 

|       ID ▲        |   ZONE   |        NAME        | UPTIME  |

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

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

[...]

Awless fournit une fonctionnalité puissante qui permet des connexions faciles aux instances avec SSH. Dans les coulisses, Awless obtiendra automatiquement l'adresse IP de l'instance, devinera le nom d'utilisateur et se connectera avec la paire de clés que nous avons créée précédemment:

>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

Notre déploiement précédent est fonctionnel, mais assez artisanal. Notre blog est alimenté par une seule instance dans une seule zone de disponibilité (AZ). Nous souhaitons maintenant créer un blog hautement disponible, avec un équilibreur de charge, deux instances dans différentes zones de disponibilité et une base de données répliquée partagée par nos instances. Au lieu d'exécuter notre propre base de données dans une instance, nous utiliserons AWS RDS, le service géré d'Amazon pour les bases de données SQL. L'utilisation d'un service géré offre de nombreux avantages, notamment la mise en cluster, la sécurité gérée et les sauvegardes.

Wallix

Afin de disposer de ressources hautement disponibles, nous devons les répartir dans des sous-réseaux dans différentes zones de disponibilité (AZ) et équilibrer la charge via Elastic Load Balancing.

Wallix

Pour ce défi, nous allons créer les éléments suivants:

  • Un équilibreur de charge pour répartir la charge entre les instances
  • Deux sous-réseaux publics à associer à l'équilibreur de charge accessible sur Internet
  • Deux sous-réseaux privés dans différentes zones de disponibilité (par exemple, us-east-1a, us-east-1e) pour héberger les instances
  • Un groupe de mise à l'échelle automatique pour gérer la mise à l'échelle des instances WordPress
  • Une passerelle NAT dans un sous-réseau public pour activer les appels sortants pour l'approvisionnement des instances
  • Une adresse IP publique fixe (IP Elastic) pour la passerelle NAT
  • Une instance RDS pour MariaDB répliquée automatiquement dans les sous-réseaux privés

Nous allons construire cette infrastructure en exécutant des modèles Awless. Le premier modèle crée des sous-réseaux et un routage. La {hole}notation permet de renseigner les paramètres de manière dynamique lors de l'exécution du modèle. La $referencenotation autorise les références arrière des ressources créées.