Martin Puppo

Este proyecto involucra migrar todas las aplicaciones con sus datos persistentes de openshift 3.11 a openshift 4.7 aprovechando para rediseñar aspectos de la implementación previa.
Se comenzó instanciando un Openshift 4 en desarrollo y se levantaron las aplicaciones core para el servicio que se brinda, y se valido los datos de la base y validamos que el servicio funciona perfectamente en una prueba de concepto.
Actualmente estamos instanciando todas las aplicaciones core a ultimo nivel… Mostrar más

Este proyecto involucra migrar todas las aplicaciones con sus datos persistentes de openshift 3.11 a openshift 4.7 aprovechando para rediseñar aspectos de la implementación previa.
Se comenzó instanciando un Openshift 4 en desarrollo y se levantaron las aplicaciones core para el servicio que se brinda, y se valido los datos de la base y validamos que el servicio funciona perfectamente en una prueba de concepto.
Actualmente estamos instanciando todas las aplicaciones core a ultimo nivel y configurándolas lo cual están surgiendo algunos issues a revisión con los soportes de producto.
A futuro, revisaremos la solución de pipelines, backups, cloud services para ir mejorando la arquitectura existente durante le proceso de migración. Mostrar menos

Comencé este proyecto dada la necesidad de reciclar las credenciales, certificados y claves utilizados en nuestro entorno y ecosistema. Realice un relevamiento de cada uno de los secrets utilizados en el entorno lo cual involucra:
- GitHub
- DB Secrets
- Servicios en Cloud Publica
- Jenkins
- Travis
- Secrets definidos en OpenShift
- Secrets alocados como parte de la config de la aplicación core.

Se armo un mapa que documenta el secret, que tipo de secret es, donde… Mostrar más

Comencé este proyecto dada la necesidad de reciclar las credenciales, certificados y claves utilizados en nuestro entorno y ecosistema. Realice un relevamiento de cada uno de los secrets utilizados en el entorno lo cual involucra:
- GitHub
- DB Secrets
- Servicios en Cloud Publica
- Jenkins
- Travis
- Secrets definidos en OpenShift
- Secrets alocados como parte de la config de la aplicación core.

Se armo un mapa que documenta el secret, que tipo de secret es, donde esta siendo utilizado, de que manera y como deberíamos interactuar para cambiarlo en cada uno, de esta manera se obtuvo un mapa completo de todos los secrets y cada servicio que lo utiliza.
Luego se procedió a realizar una prueba de concepto de Hashicorp Vault apuntado a inyectar secrets dentro de los pods corriendo en Openshift, luego realice una prueba de concepto de IBM Cloud Secret Manager (Servicio publico basado en Hashicorp Vault) para algunas integraciones.
Actualmente estoy comenzando a realizar las pruebas de concepto para cada uno de los componentes que interactúan con algún secret, y buscando la mejor manera de implementarlo para luego pasarlo a producción. Mostrar menos

Dada la necesidad en nuestro entorno de desarrollo de orquestar la asignación y liberación de ip's automáticamente para simular la aplicación productiva que no se encontraba disponible para desarrollo.
Procedí a desarrollar una aplicación en Ruby on Rails con don objetivos:
- Poder gestionar los pool de ips para desarrollo de una manera automatizada.
- Tener una aplicación con el mismo framework de la aplicación core y poder utilizarla para testear integraciones.

La… Mostrar más

Dada la necesidad en nuestro entorno de desarrollo de orquestar la asignación y liberación de ip's automáticamente para simular la aplicación productiva que no se encontraba disponible para desarrollo.
Procedí a desarrollar una aplicación en Ruby on Rails con don objetivos:
- Poder gestionar los pool de ips para desarrollo de una manera automatizada.
- Tener una aplicación con el mismo framework de la aplicación core y poder utilizarla para testear integraciones.

La aplicación consta de una interface web en la cual pueden entrar los Ops del team a validar:
- Las ultimas asignaciones realizadas
- Definir nuevas redes
- Definir nuevos rangos de ips
- Validar los datos de requester, owner, status de cada una de las ips por cada red
- Ver ips libres por cada red.

Por otra parte, la aplicación cuenta con API endpoints con el fin de que nuestra aplicación core pueda interactuar dentro de sus flujos de trabajo con esta aplicación como un microservicio.
Esto involucra por diseño endpoints que permiten:
- Pedir una ip
- Liberar una Ip
- Consultar el numero de requerimiento de la solicitud y su detalle

Adicional a esto la aplicación cuenta con un histórico por diseño.
Esta aplicación utiliza Rspec para Unit Testing y a su vez se utiliza en ocasiones TDD como técnica de desarrollo.
A su vez se integro con SonarQube, NewRelic.
Actualmente me encuentro soportando la aplicación y manteniéndola así como desarrollando nuevas características. Por otra parte esta aplicación la utilizamos para mentoria a nuevos integrantes del equipo interesados en aplicar sus conocimientos en desarrollo. Mostrar menos

Dado la falta de un monitoreo automatisado de la situacion de DRP. Se genero con diversos scripts un control del status de replica para DRP. Dicho control se comunica tanto con el storage, lpars, vios para brindar una informacion precisa de todo el control d discos en LPARs. Controla tanto el equipo viertualizado, como la correcta configuracion es las VIOS y un posterior cruce de informacion con el Storage. Por ultimo se genera una pagina html, la cual es posible consultar diariamente, donde se… Mostrar más

Dado la falta de un monitoreo automatisado de la situacion de DRP. Se genero con diversos scripts un control del status de replica para DRP. Dicho control se comunica tanto con el storage, lpars, vios para brindar una informacion precisa de todo el control d discos en LPARs. Controla tanto el equipo viertualizado, como la correcta configuracion es las VIOS y un posterior cruce de informacion con el Storage. Por ultimo se genera una pagina html, la cual es posible consultar diariamente, donde se detallan todo el status de las replicas en conjunto con la informacion de cada uno de los discos tanto a nivel de LPAR como de las LUNS realmente utilizadas en el Storage productivo y de contingencia, status de replica, etc. Esta informacion es muy util a la hora de istrar. Por otra parte se genera un detalle de errores encontrados y los mismos no solo figuran en la pagina web sino que envia un mail con dicha informacion al soporte. Esto fue una iniciativa mia, la cual fue pensada, desarollada y implementada por mi. Mostrar menos

Debido a la necesidad de relevar y visualizar estadísticas de performance de los equipos. Se trató de encontrar una herramienta apta a las necesidades del área. Así fue como di con la herramienta lpar2rrd la cual monitorea la utilización de procesadores en las plataformas virtuales de Power. Se realizó una implementación de prueba, la misma fue satisfactoria y fue implementado en toda la infraestructura virtual Power. Esto fue una mejora propuesta por mi dado las necesidades.

Como TechLead propuse automatizar el flow de trabajo que se realiza sobre las actualizaciones de seguridad de los sistemas operativos de nuestra infraestructura. Esto demandaba muchas horas hombre y una secuencia que duraba entre 2 o 3 sprints de trabajo con recursos dedicados a dicha tarea.
En dicho proyecto realice el liderazgo técnico donde realizamos sesiones de discovery para evaluar los puntos de falla, donde estaban los pain-points y como podíamos resolverlo.
Luego empezamos… Mostrar más

Como TechLead propuse automatizar el flow de trabajo que se realiza sobre las actualizaciones de seguridad de los sistemas operativos de nuestra infraestructura. Esto demandaba muchas horas hombre y una secuencia que duraba entre 2 o 3 sprints de trabajo con recursos dedicados a dicha tarea.
En dicho proyecto realice el liderazgo técnico donde realizamos sesiones de discovery para evaluar los puntos de falla, donde estaban los pain-points y como podíamos resolverlo.
Luego empezamos a realizar algunas pruebas de las automatizaciones propuestas en servidores de laboratorio y finalmente llegamos a un esquema semiautomático por la complejidad del ecosistema.
Durante el proyecto se implemento un automatismo con Ansible que permite alimentar una lista de parches de seguridad a aplicar que se sustrae manualmente, luego el playbook de Ansible consume la lista y aplica dichos parches de seguridad en el ambiente de desarrollo, se espera una semana de tiempo prudencial y luego se ejecuta en producción. El automatismo excluye los parches que requieren reboot ya que esto requiere de un proceso de bajada manual del cluster y acciones en la aplicación.
Esto redujo de varios días de trabajo dedicado en los parches de seguridad a medio dia, donde solo se valida la lista de parches a aplicar y luego se evalúa el resultado.
Al finalizar cada etapa del proceso se envía una notificación vía email de los resultados por cada server.
LA decisión de mantener una lista manual se debe a mantener exactamente los mismos versionados entre los ambientes y evitar inconsistencias por parches nuevos durante el periodo de testeo en desarrollo. Mostrar menos

Se implemento una pipeline en Jenkins para actualizar automáticamente las credenciales de un funcional alojado en un Openshift Secret, adicional a la actualización de secret se automatizo una integración con las instancias de la aplicación que la usa con el fin de actualizar la credencial en la base de datos de la aplicación, Esto nos permitió reducir a 0 el trabajo manual y poder actualizar en menos de 5 minutos todos los entornos de la aplicación y los componentes que integran el… Mostrar más

Se implemento una pipeline en Jenkins para actualizar automáticamente las credenciales de un funcional alojado en un Openshift Secret, adicional a la actualización de secret se automatizo una integración con las instancias de la aplicación que la usa con el fin de actualizar la credencial en la base de datos de la aplicación, Esto nos permitió reducir a 0 el trabajo manual y poder actualizar en menos de 5 minutos todos los entornos de la aplicación y los componentes que integran el end-to-end. Mostrar menos

Se implemento una solución de Velero integrado con Restic a un Object Storage en Cloud Publica con el fin de hacer backup de los namespaces relevantes de los proyectos en Openshift, esto resguarda la definición de los objetos que componen el namespaces y los datos de los volúmenes persistentes. Por otra parte se integro con un CronJob de Openshift el cual utiliza una imagen custom para poder tomar acciones pre/post corrida de los backups y así poder garantizar la consistencia y reducir el… Mostrar más

Se implemento una solución de Velero integrado con Restic a un Object Storage en Cloud Publica con el fin de hacer backup de los namespaces relevantes de los proyectos en Openshift, esto resguarda la definición de los objetos que componen el namespaces y los datos de los volúmenes persistentes. Por otra parte se integro con un CronJob de Openshift el cual utiliza una imagen custom para poder tomar acciones pre/post corrida de los backups y así poder garantizar la consistencia y reducir el impacto al final. Mostrar menos

Se realizo la migracion de todas las lpars de P6 a P7. Para ello durante la migracion mas critica fui enviado a Mexico 15 dias a fines de realizar las migraciones onsite. Se realizaron pruebas de HA, DRP, se fijaron procedimientos frente a contingencias y DRP. Se migrarion las lpar y se realizaron diversas reuniones frente a problematicas existentes y resoluciones.

migración de Storage Shark a V7000 en uno de los principales clientes de IBM Argentina. Análisis técnico y metodología para efectuar las migraciones con el mínimo nivel de impacto en los servicios, presentación de propuesta técnica al cliente y ejecución del proyecto. Duración del proyecto: 2 meses. Finalizado con éxito en tiempo estimado.

Migración de P6 a P7 en uno de los principales clientes de IBM Argentina. En este proyecto realice la planificación, coordinación, istración y ejecución del proyecto. Reuniones semanales de seguimiento del proyecto junto al cliente y al PM para monitorear los avances del plan y resolución de posibles desvios. Duración del proyecto: 10 meses. Finalizado con éxito y en el tiempo estimado.

Reestructuración a nivel contingencia de Storage por PPRC así como la automatización de chequeos e información de errores sobre la contingencia en uno de los principales clientes de IBM Argentina. . Duración del proyecto: 3 meses. Finalizo con éxito dentro del tiempo planificado.

Migración de maquinas físicas de la infraestructura de IBM a virtuales (LPAR) controladas por hmc y vios. Realizando las migraciones a través de mksysb, savevg, restvg, clonado por alt_disk_install a discos externos. Duración del proyecto: 9 mese.

implementación de adsmpipe (sistema de backups por TSM ) en uno de los principales clientes de IBM Argentina. Gestión de requisitos previos. Instalación del producto junto a su configuración y testeo. Duración del proyecto: 2 mes.

Instalaciones de productos NETIQ - CA SRM - IDM. Duración del proyecto: 3 meses.