Está en la página 1de 7

Grupo San Cristobal / … /

Share
AMI Management / OS Patching

Definitions - AMI Baking / OS Patching


Creado por Julian Dario Gonzalez
Actualizado por última vez el Apr 23, 2019

Diseño de AMI Baking


A continuación se definen las estrategias de generación de Imagenes (AMI) y proceso de parcheo en
AWS, realizado en conjunto con el equipo de San Cristobal y Asociart, describiendo su participación
en el flujo de release management y proceso de backup y restore.

Utilidad
Utilizar AMI baking como estrategia de Release Management es una de las utilidades que el manejo
automatizado de creación de AMI brinda. El flujo mencionado a continuación es utilizable con
mecanismos contemporaneos de despliegue como Blue/Green (Red/Black), o bien para procesos
estandar de implementación (detención de servicio - generación de nueva versión - despliegue -
subida de servicio)

Requerimientos:
Para poder utilizar esta estrategia en el flujo de Release Management, con una estrategia de
Blue/Green (Red/Black) a fines de garantizar continuidad del servicio, es necesario primero
evaluar los componentes del servicio a desplegar que participan dentro de la instancia EC2
contenida.
Los mismos deben contener elementos de la aplicación inmutables (Ej: archivos de
recursos estaticos, binarios de la aplicación, servicios que consumen capas de datos
alojadas en otro lugar). Caso contrario se generaría un delta de datos/información a partir
del momento en que se empieza a realizar el proceso de clonado de la instancia EC2.
Nuevas versiones de la versión deben ser retrocompatibles con la anterior, es decir La
aplicación debe poder garantizar integridad de datos, aun con nodos en versiones
distintas de la aplicación. 
Si las AMI creadas serán utilizadas como elementos de restauración en los procesos de backup
y restore, y los elementos de la aplicación que contienen no son inmutables, requerirá agregar
pasos de backup y restore extras para recomponer la diferencia de datos/información, entre el
incidente y el punto de recuperación en el tiempo.

Contexto general:
Instancia EC2 (nombre: "EC2-App1-v1") con App1 v1. La app es accesible a traves del nombre de
dominio app1.mypublicdomain.com.ar 
"AMI App v1" existente, la misma contiene:
El sistema operativo,
Politicas internas de seguridad/compliances deseadas (ya sea a traves de scripting, o
desplegadas por GPO que la instancia obtendra al unirse al dominio)
Reglas de monitoreo de cloudwatch de recursos
Tags aplicados
Politicas de encripción de EBS aplicadas
Aplicación correctamente instalada y configurada en su version 1

El cloudformation stack "EC2Deploy", será desarrollado y entregado. El mismo permitirá


generar una instancia EC2 basada en las caracteristicas antes mencionadas.

Estrategia 1: AMI Baking - Implementacion a traves de Blue/Green


(continuidad de servicio)
Restricciones:

AMI a crear debe tener solo aspectos inmutables de la aplicación (ej: binarios, contenido
estático, etc.).
La aplicación debe poder manejar múltiples nodos
La nueva versión de la aplicación debe poder coexistir junto a nodos con la versión anterior

Secuencia:

1. Requerimiento de despliegue de nueva version (v2) de App1


2. Proceso de creación de nueva AMI (AMI Baking) 
a. Nueva instancia de EC2 (nombre: "EC2-App1-cooking") originada de la AMI origen "AMI
App1 v1"
b. Despliegue de: la versión App1 v2 en nueva instancia EC2 (nombre: "EC2-App1-cooking")
c. (OPCIONAL) Se realizan test exploratorios automatizados
d. (OPCIONAL) Se aplica parches de seguridad pendientes
e. Creación de la AMI  "AMI App1 v2" a partir de la instancia "EC2-App1-cooking"
f. Destrucción de la instancia EC2 "EC2-App1-cooking"

El SSM automation command "AWS-UpdateWindowsAmi", será utilizado


generar una nueva AMI a partir de una definida, agregando el proceso de
deployment de la aplicación

3. Proceso despliegue de version 2. Estrategia Blue/Green


a. Creacion de Instancia EC2 (nombre: "EC2-App1-v2) a partir de AMI "AMI App1 v2"

El cloudformation stack "EC2Deploy", será desarrollado y entregado para


desplegar la instancia EC2 "EC2-App-v2", a partir de la AMI previamente
generada

b. Se utiliza estrategia de enrutamiento para incluir a la instancia de EC2 "EC2-App1-v2" con


weighted strategy en Route 53.
c. Las peticiones van a ir distribuyéndose a la instancia de EC2 "EC2-App1-v2"
d. Se realizan las pruebas. → Exitosas
i. Alternativo: Se realizan las pruebas. → Fallidas. Se detiene el proceso de despliegue
y se analiza las causas 
e. Se configura Route 53 para que toda la carga sea diseccionada a la instancia EC2 "EC2-
App1-v2"
f. Se detiene instancia EC2 "EC2-App1-v1"
g. Opcional: Eliminar la instancia detenida 
Nota: el escenario 1, también pude ser utilizado para la aplicación de parches del sistema
operativo. La restricción respecto a versión nueva retro compatible con la anterior, no
aplica para tal caso.

Estrategia 2: AMI Baking - Implementación a través de proceso


estándar (despliegue con parada de servicio)
Restricciones:

Secuencia:

1. Requerimiento de despliegue de nueva versión (v2) de App1


2. Proceso de despliegue versión v2. Estrategia estandar (parada de servicio)
a. Parada de servicios correspondientes a App1 en instancia "EC2-App1-v1"
b. Tomar backup a través de snapshot EBS (nombre: sn-EC2-App1-v1) del volumen del
filesytem asociado a la instancia "EC2-App1-v1".
c. Despliegue de la versión App1 v2 
d. Se realizan las pruebas. → Exitosas
i. Alternativo: Se realizan las pruebas. → Fallidas.
ii. Se realiza un restore del snapshot tomado en paso 4.a. Se detiene el proceso de
despliegue y se analizan las causas.
e. Tomar backup a traves de snapshot EBS (nombre: sn-EC2-App1-v2) del volumen del
filesytem asociado a la instancia.

El SSM automation command "AWS-CreateImage", será utilizado para tomar el


snapshot y generar una nueva AMI a partir del mismo

f. Reinicio de los servicios correspondientes a App1


3. Proceso de creación de nueva AMI (AMI Baking) 
a. Creacion de la AMI  "AMI App1 v2" a partir del snapshot "sn-EC2-App1-v2"

El SSM automation command "AWS-CreateImage", será utilizado para tomar el


snapshot y generar una nueva AMI a partir del mismo

OS Patching

A continuación se encuentran las definiciones en cuanto a las politicas de parcheo de Windows en


instancias EC2 realizado en conjunto con el equipo de San Cristobal y Asociart, describiendo su
participación en el flujo de release management y proceso de backup y restore.

Utilidad
AWS System Manager (SSM) provee mecanismos de parcheo de sistemas administrados por él. El
proceso de parcheo las siguientes caracteristicas a mencionar:

El proceso de aplicación de parche, incluye el reinicio de la instancia EC2

Componentes de AWS SSM Patching

Nombre Descripcion

Patch Criterios de parches a asignar a un conjunto de EC2 destino, compuesto por


Baseline Classification, Severity y Auto-Approval time

Patch Group Conjunto de instancias EC2, agrupadas por tener el mismo valor del tag "Patch
Group". 

Maintenance Ventana de horaria de mantenimiento en la que los parches serán aplicados a un


Window conjunto de instancias pertenecientes a un "Patch Group"

A un patch group se le asocia una Baseline. Las instancias EC2 contenidas en ese patch group
evaluarian su estado de compliance de acuerdo a la baseline que tengan asociada, indicando cuales
son los parches pendientes de aplicación (que se instalarán potencialmente en una ventana de horaria
mantenimiento previamente definida).

Definiciones:
Tipo Nombre Entorno Definicion
Elemento

Baseline baseline- Desarrollo Clasiffication: CriticalUpdates, SecurityUpdates


nonprod
Testing Severity: Critical,Important

Auto-Approval days: 0
UAT

baseline- Producción Clasiffication: CriticalUpdates, SecurityUpdates


prod
Severity: Critical,Important

Auto-Approval days: 14

Patch Group dev Desarrollo Asignado a las instancias EC2 de Desarrollo

test Testing Asignado a las instancias EC2 de Testing

uat-a UAT Asignado a las instancias EC2 de UAT


correspondientes a la AZ A

uat-b Asignado a las instancias EC2 de UAT


correspondientes a la AZ B
uat-c Asignado a las instancias EC2 de UAT
correspondientes a la AZ C

prod-a Producción Asignado a las instancias EC2 de Producción


correspondientes a la AZ A

prod-b Asignado a las instancias EC2 de Producción


correspondientes a la AZ B

prod-c Asignado a las instancias EC2 de Producción


correspondientes a la AZ C

Maintenance mw-scan- Desarrollo Utilizado para scanear los equipos. Ejecutado


Window all-prod Todo los dias a las 03:00 (GMT-3)
Testing

UAT

mw-scan- Producción Utilizado para scanear los equipos. Ejecutado


all-nonprod Todo los dias a las 03:00 (GMT-3)

mw-patch- Desarrollo Todo los miercoles a las 22:00 (GMT-3)


dev

mw-patch- Testing
test

mw-patch- UAT Todo los Viernes a las 22:00 (GMT-3)


uat-a

mw-patch- Todo los Viernes a las 01:00 (GMT-3)


uat-b

mw-patch- Todo los Viernes a las 04:00 (GMT-3)


uat-c

mw-patch- Producción 4to Martes de cada mes a las 22:00 (GMT-3)


prod-a

mw-patch- 4to Martes de cada mes a las 01:00 (GMT-3)


prod-b

mw-patch- 4to Martes de cada mes a las 04:00 (GMT-3)


prod-c

EBS Patch "S/Y": Tomara un snapshot del sistema antes de


Snapshot Backup aplicar el parche

"N/<vacio>/Sin_Tag": Se aplicará el parche sin


tomar un snapshot del volumen previamente

Se aplicará un ciclo de vida asociado a los


snapshot tomados a través de este
procedimiento. La duración será 4 dias previo a
su eliminación.
En siguientes etapas, se proveerá una siguiente version del stack Cloudformation
"SSMPatching-Base" el cual contendra los SSM documents personalizados para poder
realizar las operatorias definidas de EBS Snapshot previo a la aplicación del parche

PENDING CONFIRMATION: Desplegar parches sin reboot

Scripts de OS Patching
A continuación se adjuntan los 2 scripts de cloudformation encargados de configurar la solución de
patching antes definida a traves de SSM.

 Fichero Edit file  Fichero Edit file

Parametro Tipo Descripcion 


de
Dato

patchGroupTemplateUrl S3 url Path de bucket de S3 donde se encuentra el stack anidado


PatchGroup

ServiceRoleArn Role ARN Rol utilizados (deben existir) para ejecutar los SSM
ARN Documents correspondientes al scan y parcheo

SNSTopic SNS Topico SNS en que se notificara luego de que la ejecucion


Topic del parcheo sea exitosa

SNSRoleArn Role ARN Rol utilizado (debe existir previamente) en caso de


ARN especificar un SNS topic para enviar notificaciones de
parcheo
Aplicación manual de Parches

A traves de la tarea la siguiente linea de comandos (en linux), es posible ejecutar de manera manual el
comando analogo que SSM, realiza para escanear y aplicar los parches:

Para escanear todo las instancias con el tag "Patch Group" = "dev":

aws ssm send-command --document-name "AWS-RunPatchBaseline" --document-


version "1" --targets '[{"Key":"tag:Patch Group","Values":["dev"]}]' --
parameters '{"Operation":["Scan"],"SnapshotId":[""],"InstallOverrideList":
[""]}' --timeout-seconds 600 --max-concurrency "50" --max-errors "0" --
region us-east-1

Para instalar los parches pendientes correspondientes a la baseline asociada a todas las instancias con
el tag "Patch Group" = "dev":

aws ssm send-command --document-name "AWS-RunPatchBaseline" --document-version


"1" --parameters '{"Operation":["Install"],"SnapshotId":[""],"InstallOverrideList":[""]}' --timeout-
seconds 600 --max-concurrency "50" --max-errors "0" --region us-east-1

Para instalar los parches "KB9876543" y "9876543" en todas las instancias con el tag "Patch Group"
= "dev":

aws ssm send-command --document-name "AWS-InstallSpecificWindowsUpdates" -


-document-version "1" --targets '[{"Key":"tag:Patch Group","Values":
["dev"]}]' --parameters '{"KbArticleIds":["KB9876543,9876543"]}' --
timeout-seconds 600 --max-concurrency "50" --max-errors "0" --region us-
east-1

Me gusta Sé el primero al que le gusta esto Sin etiquetas