LibreNMS – backups con Oxidized.

LibreNMS – backups con Oxidized.

Si cuentas con una red con más de dos dispositivos (router o switch), debes considerar realizar respaldos de manera automatizada a esos equipos, está de más decir que también tenemos que monitorear el comportamiento de estos equipos. Podemos monitorear valores tales como CPU, memoria, estado de las interfaces de red y cantidad de tráfico que pasa por estas, esto es solo por mencionar algunos de los objetos disponibles en un equipo de red.

Sorpresa, todo esto se puede hacer con LibreNMS.

Esta plataforma de monitoreo es un fork de Observium el cual cambio su modo de distribución a uno más cerrado y esto causo que usuarios como YO se movieran a LibreNMS. Recuerdo haber usado un paso a paso de cómo mover la data de un software al otro.

En esta entrada nos saltaremos la parte donde instalamos LibreNMS, en la página del proyecto oficial se puede encontrar esta información.

Oxidizedhttps://github.com/ytti/oxidized

Como dice su README en GitHub, este es un intento de reemplazar RANCID, en mi opinión este proyecto ha logrado su cometido, mi experiencia con RANCID no fue la más hermosa o placentera.

Debian es la distribución en la cual está instalado LibreNMS, en la sección de instalación tienen varias distros, FreeBSD y Docker. Los pasos de instalación de Debian aplican para Ubuntu.

Cuando toco instalar oxidized-web, este fallaba y al final pude determinar que faltaba g++, cuando instale Debian seleccione el mínimo de paquetes, lo extraño fue que también paso lo mismo cuando realice la misma instalación en Ubuntu.

Configurando Oxidized –

Una vez instalado los tres componentes, podemos proceder a generar una configuración por defecto la cual podemos editar más adelante. Es recomendado no ejecutar Oxidized como root, debemos crear una cuenta para este servicio.

useradd oxidized

Luego ejecutamos oxidized una vez para que sea creado el directorio y en este los archivos necesarios, aunque no usaremos algunos de ellos.

Los Outputs son una parte esencial de la configuración, debemos seleccionar Git para contar con la funcionalidad de versiones dentro de LibreNMS.

Aquí un ejemplo de configuración para Oxidized que funciona en LibreNMS, este es el usado en mi entorno actualmente.

https://gist.github.com/aredan/8e44cb0485d196020472c9c870f1a60c

En router.db no necesitamos colocar equipos, la integración de LibreNMS se encarga de eso y para que esta funcione debemos decirle a Oxidized cuál es la URL del API y crear un usuario, al mismo usuario debemos asignarle un Token para ser usado desde Oxidized.

Oxidized como servicio –

Muchas veces instalamos componentes que necesita inicializar con el sistema y este se encarga de colocar lo necesario, ya sea en init.d o en system.d, en el caso de Oxidized debemos hacerlo nosotros.

https://github.com/ytti/oxidized#extra

Para este momento debemos tener un Oxidized configurado y corriendo como servicio, ya que la manera de acceder estos respaldos será usando LibreNMS, podemos dejar oxidized-web escuchando solo en 127.0.0.1 siempre y cuando ambas plataformas están instaladas en el mismo equipo.

Configurando LibreNMS –

Usando la opción de configuración mediante Global Settings -> External Settings no funciono, ni siquiera presento errores en el log de LibreNMS, cuando introduje la configuración directamente en config.php, automáticamente apareció la opción de Oxidized en Overview -> Tools. Pasados unos minutos ya podía ver intentos de conexión desde la maquina con LibreNMS/Oxidized a los equipos de red que fueron definidos en la configuración de Oxidized.

$config['oxidized']['enabled'] = TRUE;
$config['oxidized']['url'] = 'http://127.0.0.1:8888';
$config['oxidized']['features']['versioning'] = true;
$config['oxidized']['group_support'] = true;
$config['oxidized']['default_group'] = 'default';
$config['oxidized']['reload_nodes'] = true;
$config['oxidized']['group']['os'][] = array('match' => 'nxos', 'group' => 'nxos');
$config['oxidized']['group']['os'][] = array('match' => 'ios', 'group' => 'ios');
$config['oxidized']['group']['os'][] = array('match' => 'fortigate', 'group' => 'fortinet');
$config['oxidized']['group']['os'][] = array('match' => 'routeros', 'group' => 'routeros');

En las últimas cuatro líneas están definidos los equipos que quiero que LibreNMS compare contra Oxidized, por lo menos así lo entendí yo.

 

 

Aquí algunas capturas de pantalla de LibreNMS accediendo a los respaldos realizados por Oxidized.

 

Fortigate – usando un modem 3G como failover Internet.

Fortigate – usando un modem 3G como failover Internet.

Desde los inicios del uso de pfSense en mi casa, me gustaba la idea de tener dos conexiones a Internet y varias veces así fue. Alta disponibilidad en la conexión a Internet, como no era un requerimiento este fácilmente se retiraba y terminaba con una sola conexión.

¿Porque hacerlo nuevamente? ¿Y esta vez sin pfSense?

Últimamente la infraestructura de conectividad en nuestro país está cada vez más robusta, pero eso no quita una falla física, ya han sido tres las veces que de una u otra manera un camión se las arregla para romper la fibra que conecta mi modem Huawei con Claro. Ni modos, estoy tratando de justificar por qué he conseguido un modem USB 3G y comprado un SIM de VIVA con data ilimitada.

Materiales:

FortiWiFi 60D

Huawei E397 – unlocked

Paciencia ¡

Después de varios intentos con otros equipos usb, resulto que el menos pensado fue el usado al final ya que soporta las bandas empleadas por VIVA en su red 3G/4G.

Esta es la configuración del dispositivo usb:

Nota: no sé si el valor de la entrada extra-init1 debe ser en mayúscula, por lo menos la parte de AT+CGDCONT, cuando estaba en minúscula no funciono.

Un dato importante es distance y priority, estos valores deben ser iguales a los de la otra conexión a Internet si queremos usar SD-WAN sin jugar mucho con Policy Routes.

Una vez que se habilita la funcionalidad (set status enable), tendremos una nueva opción Network -> Modem.

Aquí se puede ver formando parte del servicio de SD-WAN.

SD-WAN Status Check:

Para que la configuración de failover tenga efecto y no sea un balanceo de conexión, debemos asignar prioridad a la WAN1, en mi caso:

Listo, ahora Gabriela y Abigail podrán ver sus videos en YouTube en caso de un corte en la fibra de Claro.

 

Kubernetes – usando Rancher 2.0 para crear y administrar clusters de k8s!

Kubernetes – usando Rancher 2.0 para crear y administrar clusters de k8s!

Desde hace semanas estoy jugando con Kubernetes. La idea inicial ha sido armar un cluster usando herramientas nativas de k8s (kubeadm), de esta forma aprendería el funcionamiento base de la plataforma, lo gracioso es que pensé que lo estaba haciendo “de la manera difícil”, pero creo que no era así. Al parecer existe la manera “The hard way” la cual asusta por el simple hecho que todas las configuraciones e instalaciones son de manera manual, sin usar herramientas que autogeneran como es el caso de kubeadm. Al final, la razón de realizar la instalación de esta manera es con fin educativos, es recomendable conocer el porqué de las cosas.

Kubernetes the hard way.

https://github.com/kelseyhightower/kubernetes-the-hard-way

Con Kubernetes, aprender como funcionan los componentes se ha alargado más de la cuenta ya que el ecosistema es inmenso, y cada vez que pensé “Ya está instalado, ahora a desplegar algunos contenedores”, me topaba con que tenía que instalar otras herramientas antes de (¡nginx-ingress, te miro a ti!). otro factor fue que intente mezclar arquitecturas, quería tener adm64 y arm64.

Por ejemplo, cuando ya tenía el cluster creado, surgió la necesidad de acceder a las aplicaciones desde el exterior (¿Internet?), esto se resuelve muy fácil, Ingress Controller! Luego tenemos el tema del almacenamiento y así surgieron otras necesidades que cubrir para tener una solución que funcionara completamente.

Rancher 2.0

Ya había escuchado (leído…) de esta plataforma, al principio me había confundido y pensaba que era de pago también la había confundido con RancherOS, este es un Linux con lo necesario para correr contenedores, igual que CoreOS.

Rancher es una plataforma para la administración de cluster de Kubernetes, esto es así en la versión 2.0, está basada totalmente en Kubernetes.

Instalando Rancher.

La instalación de esta plataforma es tan sencilla como correr cualquier otro Docker container, leyendo en Quick Start Guide, podemos ver que se usa Docker run para inicializar el contenedor. En mi caso he agregado varios valores que no están en la guía de inicio.

docker run -d –restart=unless-stopped -p 80:80 -p 443:443 -v /var/lib/rancher:/var/lib/rancher rancher/rancher:latest –acme-domain rancher.aanetworks.org

-v /var/lib/rancher:/var/lib/rancher

Luego de varios días de usar Rancher, me toco reiniciar el contenedor y para mi sorpresa perdí todos los cambios que había hecho, todo muy básico, pero es poco alentador ver algo así. Resulta que toda la configuración generada por etcd es almacenada en /var/lib/rancher/ junto a otras informaciones de la plataforma.

–acme-domain rancher.aanetworks.org

Luego de la aparición de Let’s Encrypt, ¡porque no tener SSL en los dominios de acceso público o privados!

Con esta línea conseguimos que Rancher solicite un SSL para el dominio que usaremos con la plataforma, debemos tener los puertos 80 y 443 accesible desde Internet para que proceda la validación de dicho dominio.

Esperamos varios minutos (5?) y luego procedemos a acceder al portal de administración, en mi caso es https://rancher.aanetworks.org, lo primero que recibiremos es un mensaje solicitando un cambio de password para el usuario admin, luego de especificar el password, tendremos acceso a la plataforma.

Clusters!

La primera opción ofrecida por Rancher luego de hacer login es la creación de un cluster, a diferencia de la versión 1.x la cual no he usado, la versión 2.0 ofrece crear clusters de Kubernetes o importarlos si ya se tiene alguno.

Tenemos opción de crear Google Kubernetes Engine (GKE), Amazon EKS, Azure Container Service (AKS), hasta se puede conectar con Digital Ocean para provisionar VM allí y agregarlas a un cluster. Por el momento solo he podido jugar con la integración de vSphere y Custom. En caso de Custom, luego de crear el cluster, se nos entrega un comando docker run para ser ejecutado en los nodos que deseamos agregar, estos ya deben tener una versión de Linux soportada junto a docker en una de las versiones soportadas.

En esta captura se pueden ver las opciones ofrecidas por Rancher para la creación de un cluster tipo Custom.

En la versión 2.0 GA, se disponen de las versiones de Kubernetes listadas aqui para ser desplegadas a los nodos.

Como CNI (Container Network Interface) tenemos Flannel, Calico y Canal. Tengo entendido que Canal es una mezcla entre Flannel y Calico. Me gustaría que en lo adelante agregaran wave, aunque entiendo que necesito investigar más sobre Canal.

Pod Security, aún no he usado esta opción, entiendo que es un mecanismo para controlar el acceso a pods cuando están en namespace diferentes.

Rancher publica una lista de versiones de Docker soportadas, pero en la creación del cluster podemos elegir si deseamos que las versiones no soportadas puedan ser usadas.

Podemos ver en el mensaje, debemos ejecutar ese docker run en uno o más servidores que deseamos formen parte de este cluster.

Node Role, necesitamos al menos un etcd, un control y un worker para comenzar a jugar con este cluster, los siguientes equipos que agreguemos al cluter pueden tener el role de Worker.

Así es como se ve un cluster de Kubernetes desde el dashboard de Rancher.

Al hacer click “Launch kubectl”, tendremos esta linda ventana que nos permitirá hacer todo tipo de operaciones usando kubectl. Otra opción es descargar el archivo de configuración, colocarlo en una maquina con kubectl para poder interactuar con el cluster de Kubernetes. Debemos tener en cuenta que de esta manera todas las operaciones son atreves del servidor con Rancher.

Kubernetes – montándonos un entorno de pruebas – homeLAB!

Hace ya unas semanas estuve en vBrownBagLATAM mostrando lo fácil que es montarnos un LAB de Kubernetes, si buscamos en Internet podremos ver muchos posts de clusters usando Raspberry Pi. En mi caso intente usar LXD como base para las maquinas (contenedores) que tendrán Kubernetes, tanto el master como los nodos. Resulta que el host con Ubuntu/LXD usado para este proyecto no tiene bastante capacidad de CPU para correr varios contenedores y dentro de estos tener Kubernetes.

Así que termine con un cluster de tres Raspberry Pi y otro sin terminar basado en LXD.

En esta entrada se detalla como iniciar con tres Raspberry Pi + Hypriot + Kubernetes.

Ingredientes!

Hypriot tiene una guía en su propio portal donde describen la inicialización y configuración de un cluster de Kubernetes, es recomendable leer esa guía.

https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

 

 

  1. Luego de introducir la imagen de Hypriot en el SD Card que usaremos en cada RPi, podremos hacer un:
  • Por defecto el RPi solicitara IP median DHCP, es recomendable cambiarlo a estático. Ha diferencia de una imagen Raspbian, la dirección IP puede ser configurada en /etc/network.

 

sudo apt update
sudo apt upgrade -y

 

  1. Lo interesante de Hypriot es que viene con Docker preinstalado, esto nos ahorra algunos minutos ya que no tenemos que hacer cambios como deshabilitar SWAP y editar la opción de cgroups. El siguiente paso es instalar Kubernetes:

 

sudo su -

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

apt update

apt install -y kubeadm kubelet

 

  1. Ahora toca inicializar el master node:

 

kubeadm init --pod-network-cidr 10.244.0.0/16 --service-cidr 10.96.0.0/12 --service-dns-domain "k8s.do" --apiserver-advertise-address 44.164.67.227 --ignore-preflight-errors=all
  • Recibiremos un mensaje de confirmación relacionado a la creación del cluster, un dato importante es el $TOKEN que más adelante usaremos para asociar los nodos.
  • No es recomendable iniciar el cluster con –ignore-preflight-errors=all, esta opción se usaría como última alternativa si tenemos errores que no podemos evitar, tal como Swap en LXD.

 

  1. Usando el Usuario pirate prepararemos el ambiente para usar kubectl sin especificar config o credenciales ya que estas serán cargadas desde el ambiente de usuario.

 

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

echo "export KUBECONFIG=${HOME}/.kube/config" >> ~/.bashrcsource ~/.bashrc

 

  1. Veo que muchos usan flannel como su CNI, en este cluster instalare wave, en el basado en LXD probare nuevamente con flannel. De esta manera tendría ambos CNI para comparar funcionalidades, luego se podría preparar una lista con las diferencias.

 

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

 

  1. Para este momento ya contamos con un master, tenemos listo el CNI, podemos proceder a agregar nodos a nuestro cluster.
  • Validamos que el CNI fue desplegado haciendo un kubectl get nodes, si nuestro nodo master tiene el estado de Ready esto quiere decir que estamos listos para el próximo paso.

 

sudo kubeadm join --token=$TOKEN

 

  • $TOKEN es el valor que recibimos cuando iniciamos nuestro master.
  • Recibiremos un mensaje indicándonos que todo aconteció correctamente y que revisemos nuestro cluster.

 

  1. Verificamos que nuestro cluster cuenta con los nodos en los cuales ejecutamos kubeadm join.
kubectl get nodes
kubectl get pods –all-namespaces

 

 

  1. Validaremos que nuestro cluster puede ejecutar “Pods”.
  • En este ejemplo, utilizare la imagen oficial de nginx y será configurada para escuchar en el puerto 80 de todos los nodos.

 

$ kubectl run nginx --image=nginx --replicas=3 --port=80

deployment "nginx" created

 

  • exponemos los Pods de nginx.

 

$ kubectl expose deployment nginx --port 80service "nginx" exposed

 

  • validamos que el puerto 80 está escuchando en los IP de nuestros nodos.

 

$ kubectl get endpoints

NAME         ENDPOINTS                                   AGE

kubernetes   192.168.7.220:6443                          37

mnginx        10.244.4.2:80,10.244.4.3:80,10.244.3.2:80   23s

 

  1. Rápidamente usando la herramienta curl, podemos validar que nginx está respondiendo en el puerto especificado.
$ curl 10.244.4.2 | head -n 5

 

  • deberíamos recibir una respuesta como la siguiente:
<DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

<style>

 

  • esto confirma que nuestro Pod está siendo ejecutado correctamente en el cluster de Kubernetes, aun faltarían muchos puntos por cubrir. Acceso desde fuera del cluster es importante ya que esta es la forma que nuestros usuarios/clientes consumirán servicios como nginx.

 

Hasta el momento solo hemos realizado configuraciones básicas en un entorno de Kubernetes y posiblemente algunos lleguen a la conclusión de que es mucho trabajo para simplemente tener un nginx o alguna otra aplicación la cual se puede levantar con Docker on LXC. Lo interesante de Kubernetes es la poca diferencia en administrar un cluster con 3 nodos a uno con 40 nodos.

En las próximas entradas escribiere como instalar y utilizar Helm, así también como instalar Istio para controlar el consumo de los servicios instalados en Kubernetes.

Kubernetes – el orquestrador!

Pido disculpas por el título, fue el primero que me llego a la cabeza.

 

Kubernetes.

Desde hace unos años esta plataforma ha estado disponible para ser usada de manera gratuita, por lo menos el nombre ha estado apareciendo en búsquedas relacionadas a Containers. La instalación de la misma, por lo que he podido investigar era algo complicada, luego aparecieron herramientas para facilitar esto y proveer un método fácil de seguir para montar esta plataforma y poder crear ambientes de prueba para luego poder desplegar en producción.

 

Minukbe:

https://github.com/kubernetes/minikube

Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.”

Kubeadm:

https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

kubeadm is a toolkit that helps you bootstrap a best-practice Kubernetes cluster in an easy, reasonably secure and extensible way. It also supports managing Bootstrap Tokens for you and upgrading/downgrading clusters.”

 

Kubernetes on Ubuntu: Conjure-UP

https://kubernetes.io/docs/getting-started-guides/ubuntu/

https://docs.conjure-up.io/2.4.0/en/walkthrough

There are multiple ways to run a Kubernetes cluster with Ubuntu. These pages explain how to deploy Kubernetes on Ubuntu on multiple public and private clouds, as well as bare metal.”

conjure-up provides the quickest way to deploy Kubernetes on Ubuntu for multiple clouds and bare metal. It provides a user-friendly UI that prompts you for cloud credentials and configuration options

 

 

He iniciado mis pruebas usando kubeadm, debido a que la mayoría de los “blog posts y how to” son para crear un cluster de k8s usando Raspberry Pi. En mi caso he iniciado usando LXD para correr el master y los worker estarían siendo ejecutados en RPi con Raspbian.

Luego de mirar un poco y leer sobre el concepto de k8s decidí probar con Conjure-up, con esta solución terminamos con un Cluster de Kubernetes listo para recibir despliegues de software ya que el “conjuro” usado crea todos los componentes necesarios. El siguiente en mi lista es Minukube.

Mi objetivo final es tener una infraestructura de k8s la cual pueda usar no solo para aprender de que trata todo esto, si no también, ejecutar tareas las cuales serán partes de mi homelab.

Más adelante publicare un post donde explico paso a paso como montarnos un cluster de Kubernetes usando Ubuntu + LXD, de esta manera podremos tener todo ejecutando en una misma máquina, este es el mismo objetivo que se consigue con Conjure-up pero con la ventaja que se hace todo paso a paso y así entendemos mejor el proceso de inicialización de un cluster.