En el artículo anterior de como Monitorizar una web con Python y que nos avise por Telegram (Monitorizar web con Python y Telegram 1), hemos hablado de como crear un bot de Telegram que nos avisará si la web cae, y nos permite a su vez ejecutar un comando que remedie el problema. Crear el script en Python En estos punto vamos a proceder a crear el script, es importante ya que la intención no es llegar a desplegar una aplicación, sino tener un ejemplo de como con un script se pueden realizar tareas sin necesidad de desplegar aplicaciones que nos pueden llevar incluso más tiempo el asegurar su comportamiento. Dependencias Lo primero son las dependencias, este script tiene varios componentes que se reflejan en las librerías que va a usar: urllib3 para comprobar el estado web, psutil para comprobar si el script está en ejecución, daemon para que funcione como demonio, yaml para guardar la configuración de forma cómoda, pip para poder instalar la librería telegram-bot que nos permitirá usar Telegram. Una instalación de dependencias en Debian/Ubuntu sería: Más documentación sobre la librerías en: Argumentos La aplicación se ha configurado para que tenga el formato: Este formato nos permitirá integrarlo con systemd para poder, por ejemplo, ejecutarlo al iniciar el equipo. Configuración CONFIGFILE.yml es la ruta completa del archivo de configuración que tendrá formato siguiente: Podemos ver los siguientes valores de configuración: La potencia de disponer de una configuración en yaml es que el proceso de carga es realmente simple, siendo el principal componente un simple “yaml.load(file)”, en el siguiente trozo de código vemos una función con parámetro el fichero yaml y que nos devuelve un hash con los valores. Registrar eventos Un punto importante en cualquier script es que vuelque la suficiente información como para identificar que se está haciendo. La siguiente función devuelve un manejador de eventos, que llamaremos con logger = getLogger() y que usaremos con logger.info(cfg[‘MONITOR_NAME’] + ” mensaje”) Funcionando como demonio Muchas veces es interesante que el script funcione de manera autónoma sin tener que ejecutarlo de manera periódica, para ello lo ejecutaremos en modo demonio, comprobando de manera periódica tanto la monitorización como la gestión del bot de Telegram. Hemos elegido la librería python-daemon por ser muy sencilla de utilizar y permitir un control sencillo sobre las señales (que usaremos para gestionar el ciclo de vida del script) y el contexto (donde realmente […]
Categoría: Series
Series de artículos explicativos sobre un tema tecnológico con un objetivo común.
Monitorizar web con Python y Telegram 1
Hace tiempo decidí monitorizar este sitio web con Python y que enviase avisos a Telegram cuando estuviese caída. La infraestructura del sitio está formada por una combinación de contenedores y realmente me basta con saber si la web es accesible y algún método de reiniciar toda la infraestructura si se detecta un problema. En esté artículo y el siguiente voy a explicar como lo he realizado, aunque debemos de tener en cuenta que por comodidad he creado un script en Python y no una aplicación. Los componentes que conforman la solución son: Un bot y un canal privado de Telegram y un script en Python que use python-bot-telegram y urllib3. Dicho script va a estar ejecutándose continuamente y se podrá desplegar como si fuese un servicio. El código de este artículo es accesible en https://github.com/aescanero/disasterproject/tree/master/python Dar de alta un bot en Telegram El primer paso es la creación del bot de Telegram que utilizaremos en el script, para ello ya deberíamos disponer de una cuenta en Telegram y buscamos @BotFather para la creación del bot Una vez accedemos al mismo nos saldrá un mensaje informativo sobre la utilidad principal de este bot y que no es otra que gestionar la creación, mantenimiento y eliminación de los bots de los usuarios de la plataforma. Lo primero que vamos a hacer es iniciar en este bot con el comando “/start“: Además de los mostrados, existe una larga lista de comando para gestionar los bots, a nosotros lo que nos interesa es crear uno, por lo que usamos el comando “/newbot“: En este paso anterior nos pedirá primero un nombre descriptivo (en mi caso “disasterproject”, después el nombre del bot (debe acabar en “bot”, hemos seleccionado “disasterproject_bot”) y nos devolverá un mensaje de creación del bot donde tenemos después del texto “Use this token to access the HTTP API:” dos bloques de código separados por “:”, la cadena entera (incluyendo los “:”) es el token que se necesita para utilizar el bot. Crear un canal privado y añadir el bot Por ahora tenemos un bot y el token correspondiente, pero necesitamos un lugar donde el bot nos envíe la información que solamente nosotros debemos ver del mismo. Es importante tener en cuenta que el bot es accesible vía comandos (/start, /status, etc.) y que los mismos se le van a enviar directamente en un chat. El bot puede responder en ese mismo chat, […]
Entorno de pruebas en AWS 1: Elegir Ansible o Terraform
Vamos a plantear un entorno de pruebas en AWS ya que el diseñado en anteriores capítulos está al límite de lo que es un portátil y muchas veces vamos a necesitar que dicho entorno sea accesible por un cliente al que no tenemos acceso. Hablaremos de un entorno en Amazon Web Service, aunque la idea es utilizar herramientas que puedan adaptarse a otros proveedores, intentando no casarnos de ninguna manera con el proveedor, pensando especialmente en lo que sería un entorno de demostración. Diseño de referencia Para empezar plantemos una arquitectura de referencia, para ello tomamos lo que es un diseño tradicional con MZ y DMZ, evitando en lo posible elementos que salgan fuera de lo que sería un entorno de demostración (por ejemplo balanceadores, CDN, caché, etc) ya que nos interesa que el despliegue sea rápido y la pretensión es que dure poco en el tiempo (y por lo tanto reducir en lo posible sus costes). De manera resumida tenemos los siguientes elementos: En este primer capítulo vamos a plantear dos posibles opciones de infraestructura como código (IaC) para desplegar el entorno y las ventajas/desventajas de cada una. Las soluciones que vamos a plantear son Ansible y Terraform. En el segundo artículo iremos revisando como son los elementos en cada una de las soluciones y que opciones tenemos ante las deficiencias de cada uno. Los ejemplos de código se basan en el disponible en https://github.com/aescanero/disasterproject, tanto para Ansible como para Terraform. Instalar Para instalar Ansible lo haremos como se han indicado en artículos anteriores (como KVM, Ansible y como hacer un entorno de pruebas), para el caso de Terraform, simplemente lo descargamos de https://releases.hashicorp.com/terraform/ para nuestro sistema operativo, para ubuntu, para instalar la versión 0.12.18 seguimos lo siguiente: En este punto podemos ver que efectivamente es más fácil la instalación inicial de Terraform, pero hemos de tener en cuenta que Ansible trae en el paquete todas las librerías necesarias para trabajar con AWS. Para poder trabajar con Terraform y AWS vamos a necesitar en el directorio de trabajo de un archivo “provider.tf” donde indiquemos el proveedor (provider) de servicio con el que vamos a trabajar, el contenido del archivo debe ser parecido al siguiente: Para instalar las librerías necesarias para el acceso a AWS ejecutaremos terraform init. Un detalle importante que diferencia ambas herramientas es la forma de conectarse, mientras Terraform puede utilizar el archivo ~/.aws/credentials o variables de […]
Dashboards de Kubernetes 3
Tras un primer artículo (Dashboards de Kubernetes 1) sobre Dashboards de Kubernetes generalistas, y un segundo (Dashboards de Kubernetes 2) centrado en dashboards específicos. Vamos a analizar aquellas herramientas que aunque no son exactamente dashboards integrados en kubernetes si que van a funcionar como clientes externos que dan acceso a la plataforma. Dashboards de Kubernetes Octant Está herramienta opensource de VMware (Con más de 3100 estrellas en github) y dentro del marco de herramientas VMware-Tanzu, está orientada a servir de herramienta explicativa de como está configurado y diseñado un entorno Kubernetes. La herramienta funciona como un servicio web, por lo que puede ponerse como un servicio o ejecutarse en la máquina local con la condición de que se disponga de un .kube/config configurado con un usuario con permisos suficientes. Tanto en octant como en el resto de entornos probados hemos usado el usuario admin. Como se instala Nos descargamos el .deb o el .rpm de https://github.com/vmware-tanzu/octant/releases y lo instalamos con las herramientas del sistema operativo, si tenemos el .kube/config para acceder al cluster a revisar basta con ejecutar octant desde la linea de comandos. Características Dispone de un limitado conjunto de los objetos de Kubernetes, suficiente para los objetivos de dicha aplicación, pero incompleto para un gestor de Kubernetes. En el siguiente gráfico podemos ver la lista de eventos que se muestra como un elemento más del menú de objetos. Pese a la limitación anterior y que no permite la modificación de los elementos, si dispone en cada elemento de una pestaña “Resource Viewer” donde se nos mostrará el estado del objeto examinado y de todos aquellos relacionados, algo que se ella a faltar en los gestor que hemos visto anteriormente y que nos permite discernir de un solo vistazo donde tenemos un problema con un servicio, como puede ser en el siguiente ejemplo: Otro ejemplo más de Resource Viewer Facilidad de uso Cumple sin problemas con su capacidad de herramienta de demostración, pero a la espera de que su diseño basado en plugins de frutos (extensiones que nos permita una gestión de Kubernetes), no es una herramienta que salga de su planteamiento original. Kontena Aplicación de escritorio no opensource, actualmente tiene versión gratuita. Sin embargo la versión que vamos a tratar es bastante completa. Como se instala Directamente desde la web del proyecto podemos descargar un archivo .appimage que es un autocontenido que puede ejecutarse en cualquier plataforma (es […]
Dashboards de Kubernetes 2
Tras un primer artículo (Dashboards de Kubernetes 1) sobre Dashboards de Kubernetes generalistas, este artículo se centra en aquellos dashboards que están orientados a ciertas necesidades. Concretamente nos centraremos en tres dashboards que van a tres necesidades: Ver el estado de un gran número de pods, ver las relaciones entre objetos y obtener una visión de conjunto sobre una plataforma kubernetes sobre docker. Dashboards de Kubernetes Kube-ops-view Con 1200 estrellas en Github este proyecto nos presenta un dashboard muy básico pensando en grandes granjas de servidores, en donde tengamos un importante volumen de pods que necesitemos revisar de un vistazo. Como se instala Creamos un espacio de nombres para instalar kube-ops-view: Creamos una cuenta de sistema con capacidades de administrador Y realizamos la ejecución de un despliegue junto con un servicio para su publicación Pese a ser un único servicio (sin autenticación, importante) su contenedor tiene un tamaño parecido al de las soluciones anteriormente mostradas: Por lo que su despliegue ha de ser rápido. Características Su interfaz, mostrado en la siguiente figura es mínimo: Sin opciones de entrar en los objetos o de editar, la información aparece al pasar por encima de las “cajas”. Facilidad de uso Claramente limitado para el que se inicia en Kubernetes o quiere información adicional sobre los objetos, pero muy útil para el que quiere visualizar de golpe grandes volúmenes de pods. Kubeview Aunque con solo 150 estrellas en github, este proyecto se centra en representas las relaciones entre objetos en Kubernetes. Siendo muy interesante para demostraciones. Como se instala Hasta que se desarrolle el Helm Chart (https://github.com/benc-uk/kubeview/tree/master/deployments/helm) Se instala en el espacio de nombre “default” instalando dos ficheros: El primer fichero incluye la cuenta de usuario kubeview y los permisos correspondientes, el segundo el despliegue junto con un servicio tipo “LoadBalancer”. El tamaño de la imagen es pequeño y su despliegue es rápido. Características Kubeview es simple y su configuración gráfica lo hacen muy interesante para enseñar Kubernetes o presentaciones. Su menú está unicamento conformado por un selector de espacio de nombre y un tiempo de refresco de la ventana. Cuando seleccionamos un espacio de nombres nos va a mostrar todos los objetos que dicho espacio de nombres posee. De está manera podemos de un solo vistazo ver las relaciones y elementos como las IPs de publicación de los servicios. Cuando seleccionamos un objeto (por ejemplo un servicio) muestra información descriptiva del mismo. Facilidad […]
Dashboards de Kubernetes 1
Uno de los principales problemas al empezar a trabajar con Kubernetes es la falta de herramientas comprensibles sobre Kubernetes. Los dashboards de kubernetes (las herramientas de gestión de la plataforma) se convierten en el punto de entrada para muchos que quieren aprender Kubernetes. En esta serie de articulos vamos a examinar algunos de los dashboards más usados, inluyendo algunos más específicos (octant, kontena) y dejando aquellos orientados a PaaS/CaaS (Rancher, Openshift) ya que en ambos casos se sobrepasa el alcance de herramientas de entrada a Kubernetes. Dashboards de Kubernetes Kubernetes Dashboard Con más de 6000 estrellas en GitHUb, el dashboard oficial de Kubernetes es la opción estándar de este tipo de soluciones, a causa de las dependencias del mismo y su falta de compatibilidad con las versiones actuales de Kubernetes nos vamos a centrar en las versión v2-beta3. Como se instala Ejecutando el comando: Se instala en el espacio de nombre “kubernetes-dashboard” y para obtener las métricas utiliza el servicio “dashboard-metrics-scraper” que se instala en el mismo espacio de nombres. Se debe acceder vía IP external (servicio LoadBalancer o kubectl proxy), o configurar un Ingress con los mismos certificados SSL que la consola (lo que complica su despliegue). Los contenedores que forman parte de esta solución son: Por lo que su despliegue ha de ser rápido, ya que aunque son dos servicios son de reducido tamaño. Características Dispone de un interfaz limpio y claro, autenticación por token y un cuadro de mandos donde a un lado tenemos todos los elementos principales de Kubernetes y en la parte principal del panel una lista de los elementos seleccionados en el nombre de espacios seleccionado. Panel principal: Por comodidad dispone de un tema oscuro, de los elementos a los que permite acceder tenemos los roles de seguridad. Además cada elemento seleccionado dispone de dos acciones: editar y eliminar. Edición de roles: La acción editar nos da acceso al objeto que define el elemento seleccionado en formatos yaml o json. En ningún elemento hay definido un editor especifico que permita la gestión del objeto para los no conocedores de su estructura. Información del nodo: Cuando seleccionamos un nodo nos vuelca una gran cantidad de información sobre el mismo. Panel de control sobre un espacio de nombres: Al seleccionar un espacio de nombre sin seleccionar ningún elemento nos mostrará un cuadro de estado de dicho espacio de nombre con los elementos que lo forman y […]