Local Test Environment Hello World example – Apiconnect & Datapower

Como parte de la automatización de tareas, en el equipo nos encontramos con la necesidad de replicar un entorno local de Api Connect junto a Datapower, con ello necesitamos tener una API básica desplegada de forma desatendida, revisando los ejemplos encuentro que usan la Web UI de API Designer, en tal sentido preparé un repositorio con documentación y los scripts necesarios para desplegar una API de «Hello World» en APIC LTE desatendido.

El código está en el repositorio:

The Unicorn Project – Gene Kim book

En esta ocasión y traes haber leído nuevamente el libro «The Phoenix Project», completé la lectura del libro «The Unicorn Project», el cual me ha dejado algunas lecciones aprendidas muy interesantes. Asimismo mencionar que este libro tiene mucho más contenido literario que técnico, esto lo comento porque revisé reseñas de otros bloggers y vi algunas un tanto disconformes debido al poco contenido técnico. En mi opinión es un libro muy entretenido.

Colocaré los apuntes que realicé durante la lectura del libro:

The Phoenix Project – Gene Kim book

Hace unos años leí el libro en formato físico, esta vez pude hacerlo de forma digital mediante O’reilly (book) lo cual me permitió poder ir traduciendo el contenido utilizando herramientas como DeepL, y así poder entender de forma fluida el contexto de desarrollo de la novela más allá de lo técnico.

En mi opinión es un libro muy ameno, que tiene historias del día a día en las empresas y oficinas que se dedican al mundo de las operaciones y el desarrollo de software.

Está muy influenciado por el libro «La Meta» o «The Goal» de M. Goldratt y hace notar varios puntos interesantes como por ejemplo:

Los tipos de trabajo:

Business Projects/Proyectos Empresariales – Capítulo 05

Son los que ayudan a impulsar los procesos e iniciativas de la empresa. Por lo general, se trata de nuevas funcionalidades destinadas a proporcionar nuevas capacidades o eficiencias a los clientes. Estos proyectos son impulsados por los responsables de la empresa y pueden gestionarse como proyectos, y no suelen tener un seguimiento centralizado, sino que son gestionados por los propietarios de los presupuestos individuales.

Everything as Code – Documentation – Diagram As Code – Python Diagrams

En esta ocasión mostraré un ejemplo sobre como manejar la documentación cómo código de los diagramas, en este cado será un código python utilizando el módulo diagrams del mingrammer.

El repositorio se encuentra en: everything-as-code-docs-example-diagrams

Una breve descripción como lo mencionan en su portal web respectivo es:

Everything as Code – Documentation – Docs As Code – Asciidoc y Asciidoctor example

En esta ocasión mostraré un ejemplo sobre como manejar la documentación cómo código, en este cado será un código de marcas, como lo es HTML, Markdown o como en este caso Asciidoc.

El repositorio se encuentra en: everything-as-code-docs-example-asciidoctor

Una breve descripción como lo mencionan en sus portales web respectivos es:

• asciidoc: AsciiDoc es un lenguaje de marcado de texto plano para escribir contenido técnico. Está repleto de elementos semánticos y equipado con funciones para modular y reutilizar el contenido. El contenido de AsciiDoc puede componerse mediante un editor de texto, gestionarse en un sistema de control de versiones y publicarse en múltiples formatos de salida.

• asciidoctor: Asciidoctor es un procesador de texto rápido y de código abierto para analizar AsciiDoc en un modelo de documento y convertirlo en formatos de salida como HTML 5, DocBook 5, páginas manuales, PDF y EPUB 3. Asciidoctor está escrito en el lenguaje de programación Ruby.

Instalando Ansible AWX/Tower en local mediante Vagrant

No cabe duda que aAnsible es una herramienta que nos facilita realizar las actividades de gestión de la configuración y aprovisionamiento de nuevos servidores, máquinas virtuales, entre otros.

Su amplia colección de plugins, roles nativos, roles en ansible-galaxy, la sencilles para poder elaborar un módulo en Ansible mediante el lenguaje python nos brinda capacidades casi infinitas.

Ansible permite ejecuciones de distintas formas, por ejemplo:

• ad-hoc: mediante el comando ansible
• playbooks: encargas de ejecutar tareas o roles
• AWX: Es un servidor web que permite ejecutar playbooks, mediante un servicio distribuido que puede ser multinodo. En su versión comercial a cargo de Red Hat se llama Ansible Tower (3.7.2)

En el trabajo tras realizar una prueba de concepto sobre la implementación de esta herramienta, ha tocado ejecutar el efecto multiplicador sobre el equipo de la compañía, de esta forma nace la necesidad de poder realizar talleres y dar a los compañeros una segura de probar la herramienta y que mejor manera de hacerla que tener nuestro propio servidor en local de la mano de Vagrant, así de esta manera si algo se rompe se puede volver a ejecutar el aprovisionamiento.

Version Management – Escogiendo «Branching Strategy» en un entorno de Integración continua

http://info.perforce.com/rs/perforce/images/perforce_best_practices_web.pdf

Una de las cosas importantes cuando se inicia el desarrollo de software es escoger la estrategia para mantener las versiones de los distintos componentes, ya sean fuentes, imágenes, código, archivos de configuración, documentación para los cuales tenemos diversas herramientas para realizarlo.

La estrategia de branching es una conducta que el equipo debe tomar respecto al software, que no depende del VCS, porque podemos realizar Trunk Based Development utilizando Git, no necesariamente estamos obligados a utilizar Git-Flow.

Veremos como hay quienes argumentan que la creación de branches aleja a los desarrolladores y los motiva a trabajar desunidos, motivo por el cual modelos más modernos apuntan a reducir la cantidad branches e incluso algunos colocan sólo un branch.

Añadiendo Jenkins al entorno para Integración continua

En el año 2010 cuando tuve por primera vez la necesidad de implementar prácticas de integración continua, continuous delivery y continuous deployment, tras ser sugerido por un colega que se encontraba trabajando en España para el BBVA de implementar éstas prácticas. En ese entonces sólo usábamos Collabnet Subversion para versionar el código, así que tuvimos que realizar muchos cambios al proyecto como convertir el proyecto a Maven, migramos a Gitlab Server, dejábamos los artefactos en Nexus Sonatype OSS, realizamos análisis con Sonarqube, jobs de Hudson CI para las construcciones, delivery y deploy sobre dos servidores de Apache Tomcat 6 con Replication Session. En las estaciones de trabajo teníamos Netbeans, con PMB y JRebel para el reload de código en caliente. A día de hoy ese entorno sigue funcionando tras casi 10 años de implementado.

En esta oportunidad toca añadir Jenkins, el fork de Hudson que tiene una gran acogida como herramienta de Continuous Integration, para ello se propone el siguiente escenario.

Entorno propuesto

Generar nuestra Docker Machine conectada a nuestro Registry Mirror y Private Registry

Buenos días, siguiendo con la serie de post, en esta oportunidad muestro como poder crear nuestro servidor local de docker utilizando la docker-machine que se encuentra de Docker Toolbox, y enlazaremos desde la creación de la VM a nuestros servidores creados en las entradas anteriores:

• icr-mirror-00.registry.com: Servidor Mirror para caché de imágenes docker públicas
• icr-docker-00.registry.com : Servidor de Registro Privado de imágenes docker privadas
• docker-machine-client : Nueva VM creada a partir de la herramienta docker-machine

El entorno quedaría como sigue:

Entorno configurado

Generar nuestro Local Docker Container Registry Mirror (Caché) – SSL autofirmado

Buenos días, en esta oportunidad veremos como modificar la instalación de un Docker Registry que nos sirva como caché de imágenes de docker, esto debido a que es sabido que cuando utilizamos múltiples imágenes de Docker Hub las descargamos de internet en cada estación de trabajo, motivo por el cual si un equipo de desarrollo es grande, dependiendo de la cantidad de veces que realizen ciclos de construcciones y limpieza de las imágenes locales (dentro de la pc del developer) podría estar consumiendo ancho de banda y tiempo innecesario, que puede ser aprovecha de mejor manera.

Utilizaremos como base el pos anterior «Generar nuestro Local Docker Container Registry Server – SSL autofirmado«, para lo cual se plantea el siguiente esquema de configuración de nuestro entorno.

En el esquema planteado se propone utilizar dos servidores de Docker Registry:

• icr-mirror-00.registry.com : Este registry estará configurado como mirror de Docker Hub (podría ser otro servidor), configurado sin autenticación.
  • Cuando realizemos un #docker pull
    • Se buscará la imagen en este servidor y si se encuentra la devolverá al cliente.
    • En caso de no encontrarla descargará la imagen del servidor (Docker Hub) , la devolverá al cliente y guardará una copia dentro de si mismo.
• icr-docker-00.registry.com : Este registry será el que usemos para guardar las imágenes privadas, se encuentra protegido por usuario y contraseña.