Aprendí estas 6 lecciones de trabajar con la formación en la nube para toda la vida.

Empecé a trabajar con la formación en la nube hace 4 años. Desde entonces, he roto muchas infraestructuras, incluso aquellas que ya estaban en producción. Pero cada vez que estropeaba algo, aprendía cosas nuevas. Gracias a esta experiencia, compartiré algunas de las lecciones más importantes que he aprendido.

Lección 1: Verifique los cambios antes de implementar

Aprendí esta lección poco después de comenzar a trabajar con la formación en la nube . No recuerdo lo que rompí entonces, pero recuerdo exactamente que usé el comando de actualización aws cloudformation . Este comando simplemente despliega la plantilla sin ninguna verificación de los cambios que se implementarán. No creo que se requieran explicaciones, para lo cual es necesario verificar todos los cambios antes de implementarlos.

Después de esta falla, cambié inmediatamente la canalización de implementación , reemplazando el comando de actualización con el comando create-change-set

# OPERATION is either "UPDATE" or "CREATE" changeset_id=$(aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "$OPERATION" \ --parameters "$PARAMETERS" \ --output text \ --query Id) aws cloudformation wait \ change-set-create-complete --change-set-name "$changeset_id" 

Cuando se crea un conjunto de cambios, no afecta a la pila existente. A diferencia del comando de actualización, el enfoque de conjunto de cambios no se implementa realmente. En cambio, crea una lista de cambios que puede revisar antes de la implementación. Puede ver los cambios en la interfaz de la consola aws. Pero si prefiere automatizar todo lo que sea posible, verifíquelo en la CLI:

 # this command is presented only for demonstrational purposes. # the real command should take pagination into account aws cloudformation describe-change-set \ --change-set-name "$changeset_id" \ --query 'Changes[*].ResourceChange.{Action:Action,Resource:ResourceType,ResourceId:LogicalResourceId,ReplacementNeeded:Replacement}' \ --output table 

Este comando debería producir una salida similar a la siguiente:

 -------------------------------------------------------------------- | DescribeChangeSet | +---------+--------------------+----------------------+------------+ | Action | ReplacementNeeded | Resource | ResourceId | +---------+--------------------+----------------------+------------+ | Modify | True | AWS::ECS::Cluster | MyCluster | | Replace| True | AWS::RDS::DBInstance| MyDB | | Add | None | AWS::SNS::Topic | MyTopic | +---------+--------------------+----------------------+------------+ 

Preste especial atención a los cambios en los que Acción es Reemplazar , Eliminar o donde Reemplazo necesario es verdadero . Estos son los cambios más peligrosos y generalmente conducen a la pérdida de información.

Cuando se ven los cambios, se pueden expandir

 aws cloudformation execute-change-set --change-set-name "$changeset_id" operation_lowercase=$(echo "$OPERATION" | tr '[:upper:]' '[:lower:]') aws cloudformation wait "stack-${operation_lowercase}-complete" \ --stack-name "$STACK_NAME" 

Lección 2: use la política de pila para evitar el reemplazo o la eliminación de recursos con estado

A veces, solo mirar los cambios no es suficiente. Todos somos humanos y todos cometemos errores. Poco después de comenzar a usar conjuntos de cambios, mi compañero de equipo realizó una implementación sin saberlo, lo que condujo a una actualización de la base de datos. No pasó nada terrible, porque era un entorno de prueba.

A pesar de que nuestros scripts mostraban una lista de cambios y pedían confirmación, se omitió el cambio de Reemplazar porque la lista de cambios era tan grande que no cabía en la pantalla. Y como se trataba de una actualización periódica en el entorno de prueba, no se prestó mucha atención a los cambios.

Hay recursos que nunca querrás reemplazar o eliminar. Estos son servicios con estado, como una instancia de una base de datos RDS o un clúster elastichsearch, etc. Sería bueno que aws se negara automáticamente a desplegarse, si la operación que se realiza requeriría la eliminación de dicho recurso. Afortunadamente, la formación en la nube tiene una forma integrada de hacer esto. Esto se llama la política de pila, y puede leer más sobre esto en la documentación :

 STACK_NAME=$1 RESOURCE_ID=$2 POLICY_JSON=$(cat <<EOF { "Statement" : [{ "Effect" : "Deny", "Action" : [ "Update:Replace", "Update:Delete" ], "Principal": "*", "Resource" : "LogicalResourceId/$RESOURCE_ID" }] } EOF ) aws cloudformation set-stack-policy --stack-name "$STACK_NAME" \ --stack-policy-body "$POLICY_JSON" 

Lección 3: use UsePreviousValue al actualizar una pila con parámetros secretos

Cuando crea una entidad RDS, mysql AWS requiere que proporcione MasterUsername y MasterUserPassword. Dado que es mejor no guardar secretos en el código fuente, y quería automatizar absolutamente todo, implementé un "mecanismo inteligente" en el que se obtienen las credenciales de s3 antes de la implementación, y si no se encuentran credenciales, se generan y almacenan nuevas credenciales en s3 .

Estas credenciales se pasarán como parámetros al comando create-change-set de cloudformation. Durante los experimentos con el script, sucedió que se perdió la conexión con s3, y mi "mecanismo inteligente" lo consideró como una señal para generar nuevas credenciales.

Si comencé a usar este script en un entorno de producción, y el problema de conexión surgió nuevamente, actualizaría la pila con nuevas credenciales. En este caso particular, no pasará nada malo. Sin embargo, abandoné este enfoque y comencé a usar otro, proporcionando credenciales solo una vez, al crear la pila. Y más tarde, cuando la pila requiere actualización, en lugar de especificar el valor secreto del parámetro, simplemente usaría UsePreviousValue = true :

 aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "UPDATE" \ --parameters "ParameterKey=MasterUserPassword,UsePreviousValue=true" 

Lección 4: usar la configuración de reversión

Otro equipo con el que trabajé estaba usando una función de formación en la nube llamada configuración de reversión . No la había visto antes y rápidamente me di cuenta de que esto haría que desplegar mis pilas fuera aún mejor. Ahora uso cada vez que implemento mi código en lambda o ECS usando la formación en la nube.

Cómo funciona: usted especifica la alarma de CloudWatch en el parámetro --rollback-configuration cuando crea el conjunto de cambios. Más tarde, cuando complete el conjunto de cambios, aws sigue la alarma durante al menos un minuto. Revierte el despliegue si durante este tiempo la alarma cambia de estado a ALARMA.

El siguiente es un ejemplo de un extracto de la plantilla de formación de nubes en el que creo una alarma de vigilancia de nubes que rastrea la métrica de la nube del usuario como el número de errores en los registros de la nube (la métrica se crea a través de MetricFilter ):

 Resources: # this metric tracks number of errors in the cloudwatch logs. In this # particular case it's assumed logs are in json format and the error logs are # identified by level "error". See FilterPattern ErrorMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref LogGroup FilterPattern: !Sub '{$.level = "error"}' MetricTransformations: - MetricNamespace: !Sub "${AWS::StackName}-log-errors" MetricName: Errors MetricValue: 1 DefaultValue: 0 ErrorAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: !Sub "${AWS::StackName}-errors" Namespace: !Sub "${AWS::StackName}-log-errors" MetricName: Errors Statistic: Maximum ComparisonOperator: GreaterThanThreshold Period: 1 # 1 minute EvaluationPeriods: 1 Threshold: 0 TreatMissingData: notBreaching ActionsEnabled: yes 

Ahora la alarma se puede usar como un desencadenante de reversión al ejecutar un conjunto de herramientas:

 ALARM_ARN=$1 ROLLBACK_TRIGGER=$(cat <<EOF { "RollbackTriggers": [ { "Arn": "$ALARM_ARN", "Type": "AWS::CloudWatch::Alarm" } ], "MonitoringTimeInMinutes": 1 } EOF ) aws cloudformation create-change-set \ --change-set-name "$CHANGE_SET_NAME" \ --stack-name "$STACK_NAME" \ --template-body "$TPL_PATH" \ --change-set-type "UPDATE" \ --rollback-configuration "$ROLLBACK_TRIGGER" 

Lección 5: Asegúrese de implementar la última versión de la plantilla

No es fácil implementar la última versión de la plantilla de formación en la nube, pero causará mucho daño. Una vez que estuvo con nosotros: el desarrollador no envió los últimos cambios desde Git y desplegó sin saberlo la versión anterior de la pila. Esto condujo a una aplicación simple que usaba esta pila.

Algo simple, como agregar una verificación para ver si una rama es relevante antes de la implementación, estaría bien (suponiendo que git es su herramienta de control de versiones):

 git fetch HEADHASH=$(git rev-parse HEAD) UPSTREAMHASH=$(git rev-parse master@{upstream}) if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then echo "Branch is not up to date with origin. Aborting" exit 1 fi 

Lección 6: no reinventes la rueda

Implementar con formación en la nube puede parecer fácil. Solo necesita un montón de scripts de bash que ejecutan comandos aws cli.

Hace 4 años, comencé con scripts simples llamados aws cloudformation create-stack command. Pronto, el guión ya no era simple. Cada lección aprendida hizo el guión cada vez más complejo. No solo fue difícil, sino también con un montón de errores.

Ahora trabajo en un pequeño departamento de TI. La experiencia ha demostrado que cada equipo tiene su propia forma de implementar pilas de información en la nube. Y esto es malo. Sería mejor si todos usaran un solo enfoque. Afortunadamente, hay muchas herramientas que lo ayudan a implementar y configurar pilas de información en la nube.

Estas lecciones te ayudarán a evitar errores.