Ubuntu LXD, Alternativa ligera?

Ubuntu LXD, Alternativa ligera?

Containers!

LXD

Si se hace una búsqueda en Internet relacionada a Docker, contenedores y demás, podremos notar que se ha convertido en algo muy aceptado. Desde hace un tiempo estoy sacando provecho de Docker en mi NAS. unRAID es actualmente mi sistema de preferencia para servicios de filesharing y un beneficio adicional es la facilidad con la que se pueden lanzar contenedores con Docker y tener servicios funcionales y fáciles de mantener.

Pero en este post me gustaría hablar de LXD, esto es un desarrollo realizado por Canonical, los creadores de Ubuntu. Durante un tiempo, no era atraído por esta distribución de Linux, pero eso está cambiando gracias a las utilidades que han creado y liberado para la comunidad. Todo comenzó con LXC, lo usé para solucionar un impase en una implementación relacionada al manejo de datos .xml que necesitaban ser recibidos de manera segura, el proveedor solicitaba SFTP en un entorno aislado, en ese momento probé LXC y se crearon varios contenedores para cada proveedor. Todo funciono de maravilla y decidí seguir investigando.

De manera casi inmediata encontré un caso de uso para tenerlo en mi casa y este fue, tener pequeños Ubuntus corriendo servicios claves (DNS, MySQL, PHP, AD Blocking…), todo fue de maravilla. Hace unos días pude terminar de completar una “nueva máquina” con un board Mini-ITX + 6GB de RAM y varios SSD de tamaños entre 120GB y 60GB. Teniendo un consumo de apenas 20Watts, esta pequeña maquina es ideal para estar encendida 24/7.

Investigando la mejor manera de tener LXC, veo que Ubuntu ahora hace referencia a LXD como el siguiente paso de LXC, tomar en cuenta que LXD no es un reemplazo y es más que un complemento.

Info: https://linuxcontainers.org/lxd/introduction/#relationship-with-lxc

“ LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding to create and manage the containers.

It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network. “

 

Instalando LXD.

Los siguientes pasos son basados en el documento oficial de LinuxContainers en la sección de LXD:

Nota: LXD puede ser instalado en las siguientes distribuciones:

  • ArchLinux
  • Fedora
  • Gentoo
  • Ubuntu
  • Debian

 

En este caso he seleccionado Ubuntu por que debería ser la distribución mejor soportada, ¿cierto?

apt install lxd lxd-client
sudo lxd init

 

Una serie de preguntas deben ser contestadas luego de ejecutar el lxd init. Siendo las más importantes la relacionada a redes, aquí se podría seleccionar crear un Bridge o utilizar uno ya existente, en mi caso opte por utilizar uno que ya había creado. La segunda opción con relevancia es el Storage, inicialmente seleccione dir como Storage backend, luego adicione un segundo disco usando ZFS.

 

Validando la instalación de LXD.

Luego de realizar la instalación podemos verificar que nuestro manejador de contenedores está operando de manera correcta con los siguientes comandos:

lxc info
lxc image list - en un entorno recién instalado este comando no presenta información.
lxc storage list
lxc network list
lxc list – en un entorno recién instalado este comando no presenta información.

 

Iniciando un contenedor.

Un nuevo contenedor puede ser creado desde una imagen, un contenedor existente o un snapshot. Por defecto LXD viene con tres repositorios de imágenes que podemos usar para crear contenedores.

  • ubuntu
  • ubuntu-daily
  • images

podemos investigar cuales imágenes están disponibles de la siguiente manera:

lxc image list ubuntu:

en pantalla nos mostrara la lista de imágenes disponibles para ser usadas, en este repositorio tenemos las versiones de Ubuntu.

Si cambiamos “ubuntu:” por “ubuntu-daily: podemos ver los snapshots generados diariamente. Si en lugar de Ubuntu usamos “images:”, tendremos una lista de todas las distribuciones que han generado imágenes y enviado al repositorio de Linux Containers, incluyendo a Ubuntu.

El resultado de este comando puede ser abrumador ya que contiene bastante información, en cambio si queremos ver la lista de una versión de Ubuntu o una distribución específica, podemos hacer:

lxc image list ubuntu:xenial

De esta manera solo tendremos las imágenes de Xenial.

Por otro lado, si queremos buscar imágenes de Debian:

lxc image list images:debian

lxc image list images:debian/9/

–  tendremos solo las versiones de Stretch.

La lista de imágenes está disponible vía web en: https://uk.images.linuxcontainers.org/

 

Ya sabemos el nombre de la imagen que queremos usar como base de nuestro contenedor. Usando los siguientes comandos podemos crear contenedores.

lxc init ubuntu:xenial cont1

– un nuevo contenedor será creado usando Xenial como base.

lxc launch ubuntu:xenial cont2

– a diferencia del anterior, de este modo podemos crear e inmediatamente iniciar el nuevo contenedor.

 

Interactuando con los contenedores.

Bien, ya tenemos nuestros contenedores. Necesitamos actualizarlo, instalar aplicaciones, usarlo tal cual usaríamos un servidor en físico o una máquina virtual que ya conocemos y queremos.

lxc exec cont1 – bash

– inmediatamente ejecutado este comando estaremos en el contenedor llamado cont1, el acceso es otorgado directamente con permisos de root. En lo adelante todo es exactamente igual que cualquier instalación de Ubuntu. Para salir del contenedor escribimos exit.

 

Aquí termina esta pequeña introducción a LXD, la capacidad de esta herramienta es bastante amplia, tengo varios planes y pruebas para realizar. Entre ella están tales como correr Kubernetes en LXD o crear un Docker Swarm usando contenedores en LXD y Raspberry Pi3.

Más información puede ser encontrada en:

 

IPv6 en la casa, al estilo Homelab!

Hablar de IPv6 es como tirarle piedras a la Luna. Estuve cerca??

nota: esto no es un tutorial, es solo una descripción del enredo al cual llamo “Conexión IPv6”.

Ahora en serio, no voy a decir que en .DO no se está haciendo nada, a nivel residencial y a nivel empresarial creo que menos. Pero en el ámbito educativo podemos ver a PUCMM como el número uno en .DO con relación a conectividad IPv6, creo que al menos el 70% de sus servicios son accesibles vía IPv6, y esto lo digo por el simple hecho de que he intentado usar esos servicios y responden.

Vamos al tema, ya que los proveedores no se han decidido a llevar IPv6 a las casas, tuve que salir a buscar IPv6 por mi cuenta. Ya desde hace años estaba jugando con el “nuevo” direccionamiento gracias a un túnel, TunnelBroker de Hurricane Electric para ser exacto. Y el problema con este era que mi dirección IPv4 en la casa no es fija y sé que tienen un método para poder establecer el túnel con direcciones dinámicas pero ya era un poco complicado simplemente mantener el túnel, además de esto se sumó que servicios como Netflix comenzaron a bloquear esas direcciones IPv6 de HE cuando detectaban que eran parte de TunnelBroker.

Después de un tiempo sin tener conectividad de IPv6 de juguete en la casa me topé con que podía hacerme de un numero autónomo (ASN) y de un IPv6 PA.

Let’s the game begins!!

 

Según HE, soy mi propio ISP.

 

Lo primero fue registrar una organización en RIPE:

Luego realizar el proceso necesario para la asignación de ASN, para esto tenemos que enviar copias de documentos personales al LIR.

 

En este punto ya tenemos el numero autónomo (ASN) que es el pilar de todo el proceso que realizaremos más adelante. Nos toca conseguir un /48 de IPv6 para poder anunciarlo, cualquier asignación más grande de 48 será filtrada por los proveedores de upstream, puede ser que tu peer directo la deje pasar pero es posible que sea filtrada más adelante y no llegue al DFZ de IPv6.

Yo adquirí un /44 con SnapServ del cual solo estoy anunciando un /48 por el momento.

https://www.snapserv.ch/pricing.html

 

Pasemos inventario:

Tenemos número autónomo.

Tenemos direcciones IPv6 para anunciar.

 

Ahora necesitamos routers donde realizar las configuraciones de lugar y que todo este enredo funcione!

En mi caso fue bastante fácil ya que tenía equipos haciendo BGP con otros routers desde hace tiempo gracias a DN42.net, inicialmente lo que hice fue detener el proceso Quagga(BGPd), editar el archivo de configuración y cambiar 64635 -> 207036, reiniciar el proceso y listo!

En caso de ser desde cero, lo primero sería instalar un motor de enrutamiento dinámico (en el caso que sea Linux el router) o habilitar/configurar esta funcionalidad en el router o router que planeemos usar.

Linux – he decidido usar Quagga por la similitud que tienen con el CLI de Cisco.

Mikrotik RouterOS – en la casa tengo varios de estos equipos que soportan BGP.

 

Como se conectan estos equipos y pueden establecer una sesión BGP?

VPN!

En mi caso particular al estar usando el mismo ASN en todos los nodos, estos deben tener la habilidad de alcanzarse mutuamente, quiere decir que deben estar en Mesh. La primera vez que intente esto lo hice usando OpenVPN, que desastre, tenía que establecer alrededor de 6 túneles en cada máquina con Debian. Buscando alternativas me encontré con Tinc, muy buen software con el que dure bastante tiempo en uso hasta que me topé con Zerotier.

https://www.zerotier.com/

Usando zerotier puedo tener una VPN tipo mesh. En otras palabras, mi VPN funciona como un Switch Layer 2. Todas las maquinas tienen un IP de la misma subred y así puedo hacer sesiones BGP entre ellas sin tener que conectarlas directamente.

 

Y así termine con direcciones IPv6 accesibles globalmente en los equipos de mi casa. Pensé que este artículo terminaría como un paso a paso pero me di cuenta de que este enredo es más complicado de lo que pensé. En los próximos días dividiré cada sección y si podre crear un paso a paso.

 

Default Rule NDP – VMware NSX.

Siguiendo con las pruebas de IPv6 en NSX, he notado que una vez tenemos el Manager corriendo y al menos un Controller, si vamos a Firewall -> General, tenemos tres reglas creadas por defecto. En mi caso me ha llamado la atención una llamada Default Rule NDP la cual tiene un Action = Allow.

 

 

Primero, que es NDP?

Es un protocolo usado en IPv6, este opera en el Network Layer (Capa 3 del modelo OSI). Una de las tareas importantes es que este protocolo es el encargado de encontrar (descubrir) otros nodos en el mismo segmento (link).

A mi entender esta es la razón del porque esta regla está en la parte de General cuando entramos a Firewall, la primera prueba que hice fue cambiar el Allow por Block y automáticamente la VM en el cluster que está preparado para NSX y al cual esta política le aplica dejo de alcanzar TODOS los demás host en el mismo link layer. Por ejemplo, si quisiera hacer lo mismo en IPv4 dentro de NSX tendría que crear una regla en la parte de Ethernet tal vez usando la MAC de la VM que no quiero que genere tráfico a ningún otro hosts.

Personalmente pienso que esto no debería ser una política creada por defecto y más bien una opción habilitada en el mismo servicio de Firewall, se puede dar el caso que por equivocación se coloque una regla que interfiera con la comunicación NDP más arriba de esta por defecto y automáticamente tendremos un mal día.

Agregando un APC ATS AP7750 al Homelab.

A mis manos acaba de llegar un AP7750 (Gracias ebay) esta cosa pesa más de 10 libras!

Desde hace tiempo buscaba un equipo APC tipo PDU, bueno en realidad buscaba un PDU con puerto de monitoreo donde pudiera ver Amps o Watts consumidos. El ATS hace gran parte de lo que necesito y otras que no necesitaba.

Output Current: 4.0 Amps …. ouch!

 

Lo primero que he intentado es sacar métricas de este vejestorio. Lamentablemente estamos hablando de un equipo con más de 10 años de fabricación y que ya APC ha declarado EOL, en el área de SNMP solo soporta v1 y no sé si esta es la razón por la cual no me está mostrando los Amps en LibreNMS.

Lo interesante es que si hago un snmpwalk encuentro el OID con el valor de Amps consumidos, seguiré investigando ya que necesito saber el consumo en Amps que esta cosa llamada Homelab está usando.

Aquí una captura de la información generada en LibreNMS la cual no es muy útil aun.

Capturando paquetes en ESXi para diagnosticar errores en flowAnalyzer.

He estado investigando por qué cuando se envían datos IPFIX desde un vDS en vSphere el proceso que supone que recibe estos paquetes simplemente muere y reinicia sus operaciones, nada de la información enviada por el vDS se registra en los Index de Kibana.

Sometí un ticket al desarrollador de flowAnalyzer y quien a su vez me solicito un PCAP de los datos generados, en Linux esto se consigue con tcpdump, en Windows con Wireshark pero en ESXi ¿?

Que tenemos a disposición en ESXi para crear un PCAP?

Tenemos pktcap-uw!

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051814

Entonces, para capturar este tráfico habilite IPFIX (NetFlow) nuevamente en sus respectivos lugares y luego ejecute:

pktcap-uw –uplink vmnic2 -o /vmfs/volumes/ADAPTEC-232GB-JBOD/vmnic2.pcap

nota: actualmente el ESXi donde estoy generando las pruebas tiene un vDS con dos uplink a diferentes Switches, uno de los swtiches está apagado y por esto solo estoy capturando datos en el vmnic2.

Esta es la configuración de IPFIX (NetFlow):

Aquí una captura de pktcap capturando tráfico:

Esperemos que la causa del problema este entre los paquetes capturados!