Blog de Amazon Web Services (AWS)
Cómo automatizar la instalación de agentes en instancias EC2 basadas en Windows en AWS
Bruno Lopes, Sr. Solutions Architect Specialist, Microsoft Workloads en AWS
Automatizar los procesos repetitivos y rutinarios ya no es un lujo, sino una necesidad básica para cualquier equipo de administradores de sistemas. No solo por la practicidad que traen las acciones automatizadas, sino también para evitar fallas humanas, aumentar la estandarización e incluso, mejorar la postura de gobierno de TI en las organizaciones.
Estas ventajas de la automatización también son aplicables en la nube. En esta, existen varias opciones para optimizar la manera en la que se automatizan los procesos. Sin embargo, con tantas opciones disponibles, puede resultar complicado decidir cuál se adapta mejor a sus necesidades y entorno.
A continuación, podemos ver algunas de las principales opciones que AWS ofrece a sus clientes y una breve comparación:
| Servicio de AWS | Nivel de esfuerzo de uso | Ventajas | Observaciones |
| Datos de usuario (User Data) de EC2 | ⭐⭐⭐ | Nativo en el uso de instancias de EC2, a través de cloud-init. | Descentralizado, es dificil encontrar los errores y acceder a los registros. |
| AWS Systems Manager Distributor* | ⭐⭐ | Preconfigurado, a través del agente previamente instalado en las AMI de AWS. | Requiere la configuración de un rol de IAM para la instancia y las políticas de IAM para el rol. |
|
AWS CodeDeploy
|
⭐⭐⭐⭐ | Admite varios servicios y se puede integrar en el ciclo de vida de auto escalamiento de EC2. | Requiere la instalación del agente y la configuración del rol de IAM. |
|
AWS CloudFormation |
⭐⭐⭐⭐⭐ | Ideal para usar cuando se aprovisiona Infraestructura como código (IaC). | Se requiere un gran esfuerzo para lograr un escenario similar al conseguible con UserData |
| AWS OpsWorks | ⭐⭐⭐⭐⭐ | Ideal para entornos con alta complejidad de automatización y tareas de administración. Funciona con instancias de Puppet y Chef. | Para aquellos que no tienen experiencia con Ruby y el lenguaje de Chef, la curva de aprendizaje es alta. |
* Para paquetes con archivos adjuntos superiores a 1 GB y un tamaño total superior a 20 GB, se recomienda utilizar Run Command en AWS Systems Manager.
El escenario descrito aquí pretende automatizar el proceso de instalación de cualquier tipo de agentes para entornos con servidores Windows, teniendo en cuenta que el conjunto de servidores puede estar en proceso de aprovisionamiento o migración, o ya estar en un entorno productivo en AWS. Teniendo en cuenta que los agentes son recursos necesarios para la comunicación entre el cliente y el servidor en varios tipos de escenarios, como monitoreo, respaldo, seguridad, migración y muchos otros.
Descripción de la solución
De acuerdo al resultado propuesto, nos centraremos en dos soluciones: una de ellas usando EC2 UserData y la otra con el AWS Systems Manager (SSM) Distributor, ya que son las opciones que descritas en la tabla anterior como aquellas que requieren un menor esfuerzo. Estas dos opciones también cubren diferentes necesidades de los entornos, tanto en la automatización de tareas como parte del aprovisionamiento o la migración de nuevos servidores, como en la administración de los entornos existentes.
Distributor, una función de AWS Systems Manager, le ayuda a empaquetar y publicar software hacia las instancias administradas por AWS Systems Manager. Usted puede empaquetar y publicar su propio software, o utilizar el Distributor para buscar e instalar paquetes de software proporcionados por AWS, como AmazonCloudWatchAgent, o paquetes de terceros, como Trend Micro.
Al final de esta publicación, instalaremos el agente de Amazon CloudWatch, que incluso se puede usar para monitorear servidores externos a AWS, como servidores locales o alojados en otros proveedores de servicios en la nube como Azure o Google Cloud. La instalación del agente de CloudWatch amplía la capacidad de monitoreo estándar de instancias de EC2, agregando otras métricas e incluso permitiendo personalizaciones de metricas y logs de aplicaciones.
Pasos para la configuración
Para estos pasos, se requerirán algunas configuraciones previas, por ejemplo en AWS IAM, para crear las funciones y políticas específicas que se utilizarán para proporcionar los permisos necesarios correctamente.
Es importante reforzar que el enfoque siempre es actuar sobre el prencipio del Mínimo Privilegio, con el fin de mejorar la postura de seguridad dentro de cualquier arquitectura de cómputo. Para estos ejemplos, utilizamos políticas administradas de AWS, políticas IAM ya creadas y configuradas por AWS. También puede trabajar con políticas administradas por el cliente, donde la personalización de permisos puede proporcionarle un escenario aún más eficaz, con las Conditions y la granularidad que se ajustan a sus reglas de gobierno.
EC2 User Data
Cuando usted lanza una instancia de Windows en Amazon EC2, puede pasar Datos de usuario (User Data) a la instancia, ésta ultilizará esta información para realizar tareas de configuración automatizadas o ejecutar scripts después de que se inicie. La información de Datos de Usuario de la instancia se trata como datos encapsulados, es decir, depende de la instancia interpretarla. La información de los datos de usuario es procesada por EC2Launch v2 (AMI compatibles o si se ha instalado), por EC2Launch en Windows Server 2016 y posteriores, o por EC2Config en Windows Server 2012 R2 y versiones anteriores.
Para que EC2Config o EC2Launch ejecute scripts, tendrá que añadir un tag especial al script cuando añada Datos de usuario. De la tag utilizada depende si los comandos se ejecutan en una ventana del símbolo del sistema (script de batch) o usando mediante Windows PowerShell.
| Nota: Si especifica un script de batch y un script de Windows PowerShell, el script de batch se ejecuta primero y el script de Windows PowerShell se ejecuta a continuación, independientemente del orden en que aparezcan en los Datos de usuario de la instancia. |
De forma predeterminada, los scripts de Datos de Usuario se ejecutan una única vez al inicializar la instancia. Para ejecutar scripts de Datos de Usuario cada vez que se reinicie o arranque la instancia, agrega <persist>true</persist> a los datos del usuario.
A continuación se muestra un ejemplo de un script que utiliza el tag <powershell> para automatizar la instalación del agente de Amazon CloudWatch.
SSM Distributor
Antes de empezar a usar Distributor, uno de los componentes de AWS Systems Manager, es importante que siga los pasos que se indican a continuación para que se cumplan los requisitos para un funcionamiento correcto.
Paso 1: Requisitos básicos para usar Systems Manager: Funciones de IAM y agente de SSM
Como mencionamos anteriormente, el agente de Systems Manager ya está preinstalado en las AMIs que ofrece AWS, lo que facilita mucho el uso de SSM Distributor. Con esto, uno de los requisitos que sería la instalación del agente de SSM ya no nos preocupa.
A continuación, podemos pasar a la segunda parte de este paso, la configuración del rol de IAM, que se utilizará en el perfil de instancia de EC2. Para quienes no estén familiarizados, el perfil de instancia es la función que les permite “pasar” un rol de IAM a una instancia de EC2 y, por lo tanto, evitar la necesidad de utilizar claves de acceso/claves secretas o incluso de usuarios y contraseñas para interactuar con los recursos de AWS.
Después de crear el rol de IAM y asociarla a la instancia deseada, también debe incluir permisos que permitan que Systems Manager se ejecute en la instancia. Es posible que se requieran otros permisos, según el nivel de uso que planifique para su escenario. Para los fines de este blog, utilizaremos las políticas administradas de AWS sugeridas para Systems Manager. Como mencionamos anteriormente, puede crear políticas administradas por el cliente para limitar los permisos aún mas en su entorno.
Elegimos una política específica para SSM y las otras dos para CloudWatch, ya que es parte de la función que queremos configurar para este escenario.
Como podemos ver en la captura de pantalla anterior, las tres políticas se adjuntan al rol de IAM que se creó y se vinculó a la instancia de EC2.
Paso 2: Cree o seleccione el bucket de Amazon S3
Distributor requiere un bucket de Amazon S3 al crear el paquete de instalación. El bucket utilizado para la configuración del paquete es temporal y solo se necesita hasta que se finalice el paquete. A continuación, Distributor carga los datos en el almacenamiento interno de SSM y el bucket se puede reutilizar para otro propósito o ser removido.
Paso 3: Crear el paquete en Distributor
En la consola de AWS, puede encontrar Distributor dentro de los componentes de Systems Manager, en la sección Administración de nodos del menú de la izquierda. Después, verá varios paquetes existentes, proporcionados por AWS o por terceros.
Queremos crear nuestro propio paquete. Para ello, seleccionamos la opción «Crear paquete». Después de eso, tenemos a dos opciones: Simple y Avanzada. En Simple, Distributor se encargará de crear los scripts de instalación y desinstalación éstandares, y también redactará los manifiestos del paquete de implementación. En la opción Avanzada, tendremos que hacer todo esto manualmente y, al final, ponerlo a disposición en forma de archivo .zip para el Distributor. Este archivo contendrá todos los archivos de instalación, desinstalación y manifiesto (ver imagen a continuación). Si desea obtener más información sobre el modo avanzado, consulte esta documentación de referencia.
Utilizaremos la opción Simple.
Después, elegiremos el bucket de S3 que se utilizará en el proceso. Recuerde que este depósito es temporal y, una vez creado el paquete, se puede vaciar o eliminar.
Ahora cargaremos el instalador del software del agente para que pueda continuar con la creación del paquete de instalación. Recuerde que para este proceso, solo se admiten archivos msi, deb o rpm. Para el escenario del servidor Windows, trabajaremos con msi. Si tiene un instalador .exe como parte de su agente para instalar, busque alternativas para empaquetar o convertir su .exe en un .msi. Hay diferentes formas de hacerlo, y herramientas que pueden ayudarle con esto.
En esta sección hay un punto muy interesante, que es la posibilidad de personalizar los scripts que se ejecutan para instalar el software. De forma predeterminada, trae la instrucción msiexec /i amazon-cloudwatch-agent.msi /quiet como secuencia de comandos de instalación y la instrucción msiexec /x amazon-cloudwatch-agent.msi /quiet como secuencia de comandos de desinstalación.
Puede personalizarlo, de acuerdo con los flags que soporte el software a instalar, e incluso con instrucciones a través scripts de batch o de Powershell. Consulte la documentación de cada producto para obtener más información.
Por último, Distributor crea de mánera automática el manifiesto. El manifiesto puede ayudar a organizar paquetes que están configurados para varios sistemas operativos y arquitecturas, lo que mejora la administración de la infraestructura y el gobierno.
Ahora, simplemente haga clic en la pestaña «Owned by Me» y seleccione el paquete que desea instalar. Después de crear un paquete en el distribuidor, puede instalarlo de una de las siguientes maneras:
- Una vez, con AWS Systems Manager Run Command
- Periódicamente, mediante AWS Systems Manager State Manager
Una vez terminada la instalación del paquete en una instancia, podemos comprobar la instalación del agente en el Panel de control de Windows.
Conclusión
En este blog revisamos algunas de las opciones que existen en AWS para automatizar actividades comunes en la rutina de un administrador de sistemas, como la instalación de agentes y software en los servidores. Notamos que hay diferentes formas de lograr este objetivo, y que algunas de ellas también implican un escenario de mayor complejidad y esfuerzo para logralo. En esta publicación también expusimos las instrucciones paso a paso para ejecutar dos de estas opciones en nuestros entornos: AWS Systems Manager Distribuitor y los Datos de Usuario de EC2.
Acerca del autor
Bruno Lopes es arquitecto de soluciones sénior en el equipo de AWS LATAM. Lleva más de 14 años trabajando con soluciones de TI, teniendo en su cartera numerosas experiencias en cargas de trabajo de Microsoft, entornos híbridos y capacitación técnica de clientes como Technical Trainer y Evangelista. Ahora actúa como arquitecto de soluciones, combinando todas las capacidades para reducir la burocracia en la adopción de las mejores tecnologías con el fin de ayudar a los clientes en sus desafíos diarios
Revisor
Gaston Lyons es arquitecto de soluciones en el equipo de Colombia. Ha estado en el mercado de técnologia durante los ultimos 12 años, trabajando con cargas de trabajo Microsoft y migraciones de infraestrucutura hacia la nube. Actualmente, ayuda a clientes en adoptar servicios de AWS en su infraestructura.