Tutorial de Awless: pruebe una CLI más inteligente para AWS

Henri Binsztok es director de innovación de Wallix y cocreador del proyecto de código abierto Awless.

Cuando la nube se trataba solo de máquinas virtuales, herramientas como Chef o Puppet nos ayudaron a preparar fácilmente nuestras VM. Lo único que importaba era proporcionar instancias que contuvieran todo el código y los datos necesarios. Pero ahora que Amazon Web Services se ha disparado a más de 90 servicios, interactuar con la API de AWS se convierte en la mayor parte del trabajo.

¿Cómo debemos administrar la infraestructura de AWS y qué interfaces debemos utilizar? La mayoría de los principiantes comienzan con la consola de AWS, la GUI predeterminada, mientras que los administradores de sistemas experimentados generalmente prefieren una interfaz de línea de comandos (CLI). El problema es que la AWS CLI no es fácil de usar. Debido a que integra toda la API de AWS, expone una enorme superficie en términos de comandos, indicadores y opciones.

Awless nace de nuestra necesidad de una CLI rápida, potente y fácil de usar para administrar AWS. Con Awless, puede crear y ejecutar una infraestructura de AWS, comenzando desde cero, y obtener siempre resultados legibles (tanto para humanos como para programas), explorar y consultar todos los recursos de la nube (incluso sin conexión), conectarse a instancias y crear, actualizar y eliminar los recursos de la nube. Más allá de las líneas de comando únicas, Awless admite plantillas que permiten niveles más altos de automatización. Por último, pero no menos importante, Awless tiene como objetivo garantizar valores predeterminados inteligentes y mejores prácticas de seguridad.

Debido a que existen tantos servicios de AWS, a menudo es importante buscar y mostrar una jerarquía de servicios desde la línea de comandos. Podemos agrupar los servicios por funcionalidad, como computación y base de datos. Pero revisar cada uno de ellos de manera exhaustiva es tedioso ya que, al momento de escribir este artículo, hay no menos de 15 servicios en torno al almacenamiento y la base de datos, sin contar cuatro servicios de migración de datos y nueve servicios de análisis que están directamente relacionados con el uso de datos.

Nos resulta más fácil agrupar los servicios por disponibilidad para la nube. En este artículo, detallaremos cómo usar Awless para crear y administrar recursos en la nube para un caso de uso real, la implementación de instancias de WordPress listas para producción. Usaremos los siguientes recursos de AWS:

  1. Servicios de VM EC2 (Elastic Compute Cloud) y ELB (Elastic Load Balancing);
  2. Servicios de alto nivel que se ejecutan en máquinas virtuales pero que son administrados por AWS, como RDS (Servicio de base de datos relacional) o ElastiCache (para colas);
  3. Servicios "sin servidor" que se ejecutan en máquinas virtuales multiinquilino, como S3 (almacenamiento de objetos) o Lambda (ejecución de función única).
Wallix

Empiece con Awless

Regístrese en AWS y cree una primera cuenta con AdministratorAccessderechos. Anote cuidadosamente su clave de acceso y clave secreta.

Instalar Awless

Awless está disponible en GitHub . Proporcionamos binarios prediseñados y paquetes Homebrew para MacOS:

>brew tap wallix/awless 

>brew install awless

Puede verificar que Awless esté instalado correctamente ejecutando:

>awless version

Awless se basa en herramientas populares de línea de comandos como Git. La mayoría de los comandos tienen la forma de:

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

Este artículo ofrece una descripción general de 360 ​​grados de las cargas de trabajo de producción reales en AWS, comenzando desde cero. Para mayor claridad, omitimos toda la confirmación y algunos pasos de salida, ya que Awless siempre pide confirmar los comandos que crean, actualizan o eliminan recursos.

Primeros pasos con Awless

Podemos emitir nuestro primer comando Awless enumerando nuestras nubes privadas virtuales (VPC). Debido a que esta es nuestra primera ejecución, necesitaremos ingresar algunos datos necesarios para configurar 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 |

Cree un usuario de AWS

Ahora usaremos Awless para crear un nuevo usuario de AWS y otorgarle derechos suficientes usando el perfil de administrador. Creamos el usuario John y su clave de acceso:

>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

Ahora que John existe, necesita un conjunto de permisos. Le daremos a John acceso completo a los servicios EC2, RDS, Auto Scaling, CloudFront y S3 que usaremos en este artículo:

>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

Ahora que John es un usuario completamente funcional, cambiaremos a su perfil para los siguientes pasos:

>awless config set aws.profile john

Utilizaremos AWS para configurar una implementación de WordPress administrada y de alta disponibilidad, que combine máquinas virtuales, servicios administrados y sin servidor. Nuestro principal objetivo se muestra a continuación. Tendremos que abordar tres "desafíos de devops" para alcanzarlo, haciendo uso de los servicios de infraestructura de AWS, los servicios administrados y los servicios sin servidor, respectivamente.

Wallix

Desafío 1: Levantar y cambiar una aplicación a EC2

Lift and shift es lo más rápido para migrar aplicaciones heredadas a la nube y beneficiarse de la flexibilidad y las ventajas de costos de las plataformas en la nube. En este caso, comenzaremos por implementar un motor de WordPress y su base de datos en una sola VM. Los clientes se conectarán directamente a la VM.

Wallix

Crea una VPC

Antes de continuar con la creación de la máquina virtual, primero necesitamos crear recursos de red:

  • 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

Puede conectarse a la dirección IP desde la salida del comando para acceder a su servicio de WordPress (aunque es posible que deba esperar unos minutos para que la instancia se aprovisione correctamente).

Fundación WordPress

De forma predeterminada, Awless creará un tipo t2.micro (1 vCPU, 1 GB de RAM) utilizando Amazon Linux. Puede actualizar los valores predeterminados mediante 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

Hasta este punto, hemos construido varios recursos. Con awless list, podemos enumerar usuarios, instancias, subredes y todos los demás tipos de recursos (siempre que su perfil de AWS tenga suficientes derechos, por supuesto). Por ejemplo, podemos enumerar instancias:

>awless list instances 

|       ID ▲        |   ZONE   |        NAME        | UPTIME  |

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

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

[...]

Awless proporciona una característica poderosa que permite conexiones fáciles a instancias con SSH. Detrás de escena, Awless obtendrá automáticamente la dirección IP de la instancia, adivinará el nombre de usuario y se conectará con el par de claves que creamos anteriormente:

>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

Nuestra implementación anterior es funcional, pero bastante artesanal. Nuestro blog funciona con una sola instancia en una única zona de disponibilidad (AZ). Ahora queremos crear un blog de alta disponibilidad, con un equilibrador de carga, dos instancias en diferentes zonas de disponibilidad y una base de datos replicada que comparten nuestras instancias. En lugar de ejecutar nuestra propia base de datos en una instancia, usaremos AWS RDS, el servicio administrado de Amazon para bases de datos SQL. El uso de un servicio administrado ofrece muchas ventajas, como la agrupación en clústeres, la seguridad administrada y las copias de seguridad.

Wallix

Para tener recursos de alta disponibilidad, necesitamos distribuirlos en subredes en diferentes zonas de disponibilidad (AZ) y equilibrar la carga mediante Elastic Load Balancing.

Wallix

Para este desafío, crearemos lo siguiente:

  • Un balanceador de carga para distribuir la carga entre las instancias
  • Dos subredes públicas para asociar con el balanceador de carga orientado a Internet
  • Dos subredes privadas en diferentes zonas de disponibilidad (p. Ej., Us-east-1a, us-east-1e) para alojar las instancias
  • Un grupo de escalado automático para administrar el escalado de instancias de WordPress
  • Una puerta de enlace NAT en una subred pública para habilitar las llamadas salientes para el aprovisionamiento de instancias
  • Una IP pública fija (IP elástica) para la puerta de enlace NAT
  • Una instancia de RDS para MariaDB replicada automáticamente en las subredes privadas

Construiremos esta infraestructura ejecutando plantillas Awless. La primera plantilla crea subredes y enrutamiento. La {hole}notación permite que los parámetros se llenen dinámicamente durante la ejecución de la plantilla. La $referencenotación habilita referencias hacia atrás de recursos creados.