1. 1.- Create an integration flow and automatic deployment for one of the services and/or
applications of the case.

2. 2.- Create an ansible playbook that deploys a static front end application to the cloud.

3. 2.- Create an ansible playbook that deploys a static front end application to the cloud.

4. 2.- Create an ansible playbook that deploys a static front end application to the cloud.
[front]
dev@178.81.241.97 ansible_ssh_private_key_file=~/.ssh/dev.pem
---
- hosts: front
become: yes
become_method: sudo
tasks:
- name: Install pip
apt:
update_cache: yes
name: python3-pip
- name: Install aptitude using apt
apt: name=aptitude state=latest update_cache=yes force_apt_get=yes

5. 1.- El objetivo a corto plazo es de migrar los componentes on-premise a nube, para lo cual se
requiere una automatización básica inicial y modernización de componentes.
Independientemente del proveedor cloud (libertad para utilizar los servicios cloud y open
source), ¿cómo automatizarías esta subida de los dos componentes? *Nota: La compañía ya
es usuaria de contenedores y más de un proveedor cloud.
RPTA: Los componentes serían desplegados a través de Terraform (IaC) dado que puedes elegir
diferentes provider y por tanto es agnóstico al proveedor Cloud, adicionalmente activar el lock para evitar
accidentes destroy. Para las settings de los componentes desplegados podemos hacerlo con Ansible
(CaC).
Si se evaluado el funcionamiento y la adaptación a contenedores con Docker, será necesario crear un
container registry y realizar el Build, Push de la imágen y deployarlo a un cluster de Kuberntes con
AzureDevOps (CI/CD)

6. 2.- Después de tener los recursos en nube, se requiere configurar un flujo de CI/CD para las
actualizaciones posteriores de código para la Single Page Application (la cual está compuesta
por html, css y js), así como de los microservicios que exponen las operaciones CRUD (los
cuáles están desarrollados en java). Según el proveedor cloud elegido en la anterior pregunta,
¿qué servicios incluiría para construir el pipeline (desde control de versiones hasta trigger de
releases, etc.)?
RPTA:
Es necesario crear un ACR (Azure Container Registry) y realizar el Build, Push de la imágen y deployarlo
a un cluster de Kuberntes (AKS), todo esto con AzureDevOps (CI/CD) para los diferentes entornos
aislados de DEV, QA, PRO o los que haya definido la compañía.

7. 3.- Al cabo de unos meses se contempla la oferta de otro proveedor cloud para migrar los
servicios con un periodo de facturación gratuita, entonces se debe migrar los componentes de
una nube a otra, ¿cómo automatizarías este requerimiento?
RPTA:
Actualizamos el provider de cloud en las herramientas de automatización para el caso de basedatos, se
tendrá que definir una ventana para el corte y con ello hacer la migración.

8. 3.- Finalmente, se debe monitorear lo construido, si se sabe que la aplicación es para el flujo de
citas en la clínica y que adicionalmente a los componentes en nube se debe consultar un
servicio on-premise para la consulta del seguro del paciente, ¿cómo monitorearías esta
solución y qué configurarías (alarmas, triggers, etc.)?
RPTA:
NewRelic para monitorear los componentes Cloud y On-premises.
- Configurar Alarmas y definir umbrales de acuerdo al comportamiento.
- Configurar triggers para enviar notificaciones a mesa de ayuda ante un evento anómalo.
- Configurar agentes para matricular los componentes a la herramienta de monitoreo.
- Monitorear, consumo de recursos (Memoria, CPU), espacio libre en disco, healtcheck de los
endpoints de servicio y página web, Tiempo de respuesta de los servicios, Concurrencia de de red.