En Busca de la Paridad de Entornos
A partir de la adopción de contenedores linux podemos observar la realidad en términos de "build, ship & run any app, anywhere" .
Este precepto nos permite perfeccionar el arte reduciendo casi a la nulidad, los problemas de disparidad de entornos entre nuestra comunidad de desarrolladores e integradores, ya que bajo este esquema ambos mundos lanzan instancias de la App usando los mismos contenedores.
BUILD
SHIP
RUN
Para ir compartiendo con nuestra comunidad la experiencia de esta transición hacia el uso de contenedores y buscando siempre en ella el feedback que nos motiva a seguir forjando la Aplicación Web para Contact Center mas amigable e intuitiva del mercado, es que vamos a ir generando una serie de entradas en nuestro blog & foro.
¿Qué son los contenedores Linux?
Los contenedores de Linux permiten empaquetar y aislar las aplicaciones junto con todo el entorno de tiempo de ejecución, es decir, con todos los archivos (directorio, binarios, dependencias) que requieren para ejecutarse. Esto permite mover la aplicación que se encuentra entre los entornos (de desarrollo, de prueba, de producción, etc.), sin perder ninguna de sus funciones.
Un contenedor (Linux container) es un conjunto de uno o más procesos separados del resto del sistema. Todos los archivos (binarios, directorios, dependencias) que se necesitan para ejecutarlos provienen de una imagen diferente, lo cual significa que los contenedores de Linux se pueden trasladar desde la etapa de desarrollo hasta la de prueba y producción, sin perder uniformidad.
Podemos plantear a las imágenes de un contenedor como «binarios» instanciados a la hora de ser invocados por la ejecución de un contenedor, por lo que el contenedor en cuestión lo podemos pensar como el componente o servicio «en tiempo de ejecución».
Por ultimo acudimos a un diagrama de bloques totalmente diseminado por la web.
A la izquierda un esquema de App virtualizada directamente sobre un Host OS, mientras que a la derecha vemos una App corriendo dentro de un contenedor.
Desde Dev hacia Ops
OMniLeads adoptó el esquema de contenedores como una tecnología utilizada para facilitar a los desarrolladores los despliegues de sus entornos y su posterior uso a la hora de codificar. Con el paso del tiempo y habiendo ganado experiencia el área de QA comenzó a realizar las verificaciones de cada rama de código sobre un entorno de contenedores, hasta que finalmente todo el Pipeline se volcó sobre el paradigma de contenedores linux.
El proyecto OMniLeads mantiene las imágenes de cada componente disponibles en Docker-Hub por un lado, mientras que se facilita un repositorio de código destinado a la gestión de instancias de la App, siendo una de las opciones el despliegue a través de docker-compose.
Ejecución de OMniLeads con docker-compose
Uno de los nuevos formatos soportados oficialmente para desplegar OMniLeads es docker-compose. De esta manera se obtiene una instancia de la la App parametrizada a través de un simple archivo de variables de entorno. Desde cualquier Sistema Operativo (Mac, Linux o Windows) se puede ejecutar, solo es requisito que se ejecute el Container Engine Docker.
Vamos a ejemplificar sobre Docker-Desktop en MAC.
Toda la documentación necesaria la encontraremos en el repositorio OMniLeads Deploy Tool.
Luego de contar con Docker en nuestra estación de trabajo, debemos descargar el repositorio de gestión de OMniLeads para luego nos paramos sobre la sub-carpeta docker-compose y generar el archivo de variables que se va a utilizar para levantar la App.
git clone https://gitlab.com/omnileads/omldeploytool.git
cd omldeploytool/docker-compose
cp env .env
Podemos echar un vistazo sobre algunas secciones del archivo .env, por ejemplo a la hora de editar las versiones de cada componente que se desean ejecutar:
A decir verdad no hace falta indagar demasiado en las variables para lanzar una instancia sobre nuestra estación de trabajo, así que vamos a dejar el análisis de las variables para otra entrada orientada al deploy de OMniLeads en Producción.
Por lo tanto pasamos a la acción directamente lanzando el comando.
docker-compose up -d
La primera ejecución puede demorar porque se van a descargar todas las imágenes de OMniLeads, pero luego release a release solo baja el diferencial en el orden de los MB.
Una vez finalizada la descarga, deberíamos observar que el comando nos devuelve el prompt.
Finalmente podemos acceder a la aplicación https://localhost
Se dispone de un nuevo script para la gestión de varios aspectos, entre ellos ejecutar un blanqueo de la contraseña de admin para iniciar sesión. Por lo que tanto la primera vez que se lanza el entorno asi como también cada vez que se desee resetear el password de admin debe ejecutarse.
oml_manage.sh --reset_pass
Como paso posterior podemos generar usuarios, campañas, troncales y rutas de manera tal que sea posible ingresar con un usuario y comenzar a probar todo.
./manage.sh --init_env
Esto nos genera un usuario tipo agente (agent, agent1*)
A partir de ahora es posible realizar un login (con el usuario mencionado) y comenzar a efectuar llamadas ya que nuestro entorno levanta un emulador de PSTN, por lo que también es viable simular llamadas entrantes utilizando nuevamente el script de manage.
./manage.sh --generate_call
Conclusiones
El nuevo pipeline de OMniLeads basado en el uso de contenedores Linux y el lema build, ship & run, salió lanzado finalmente en este 2023, para hacer seguir forjando una App intuitiva, amigable y en consonancia con el mercado. Hay un nuevo mundo mas allá de CentOS7 AIO y lo vamos a estar compartiendo con nuestra comunidad.