Habilitar Content trust en Azure ACR (Azure Container Registry)

ACR content trust te permite firmar las imágenes que se envían a tu registro. Los consumidores de tus imágenes (personas o sistemas que obtienen imágenes de tu registro) pueden configurar a sus clientes para que solo obtengan imágenes firmadas. Cuando un consumidor de imágenes extrae una imagen firmada, el cliente Docker verifica la integridad de la imagen. En este modelo, los consumidores están seguros de que las imágenes firmadas en su registro fueron efectivamente publicadas por uno mismo, y que no se han modificado desde su publicación

Como primeros pasos para habilitar esto es necesario utilizar el SKU Premium de ACR, esto se puede configurar tanto para un ACR nuevo como para uno existente:

Podemos verificar que se encuentra correctamente habilitado mediante el CLI de Azure ejecutando:

az acr config content-trust show -n cibiriregistry

Para que esto funcione tiene que estar habilitado desde el lado cliente para poder trabajar con imágenes firmadas, en palabras mas sencillas en el cliente Docker tiene que estar habilitado. Esto se puede realizar mediante el siguiente comando:

export DOCKER_CONTENT_TRUST=1

En el caso que no se quiera habilitar a nivel global de Docker se puede hacer a nivel de cada build mediante el siguiente comando

docker build --disable-content-trust=false -t cibiriregistry.azurecr.io/test-apache:latest .

Elegimos la opción anterior y hacemos el push de la imagen hacia ACR:

docker push cibiriregistry.azurecr.io/test-apache:latest

Durante el proceso nos va a solicitar una contraseña para poder subirla a ACR, esta contraseña sera utilizada luego para hacer el pull de la imagen

Luego cuando queramos hacer el pull de la imagen solo nos va a permitir hacer el mismo si la imagen esta firmada, caso contrario vamos a obtener un error como el siguiente:

No valid trust data for unsigned

Es importante destacar que esta característica esta en vista previa y puede sufrir modificaciones.

Espero que les sirva la información.

Instalar Docker CE en Debian 9 "Stretch"

En este post vamos a ver la instalacion de Docker CE en sistemas operativos Debian version 9 "Stretch", al final de post vamos a ver una serie de mejores practicas y solucion de errores comunes post instalacion.

Previo a la instalacion de cualquier paquete en los sistemas operativos es recomendable contar con todo actualizado antes de empezar, para esto ejecutaremos:

apt-get update

aptg-get upgrade -y

Una vez realizado esto estamos en condiciones de instalar Docker, para esto primero instalamos estas dependencias:

sudo apt-get install apt-transport-https ca-certificates software-properties-common curl -y

Ahora bajamos la key para acceder a los repositorios de Docker:

curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg | sudo apt-key add -

Agregamos el repositorio de Docker.

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") $(lsb_release -cs) stable"

Actualizamos los repositorios y procedemos a instalar Docker:

sudo apt-get update

sudo apt-get install docker-ce -y

Hasta aca todo bien, ya tenemos Docker instalado y funcionando en nuestro Servidor:

Puede funcionar de manera default, pero sugiero hacer modificaciones para la gestion remota y la rotacion de logs (me paso que los logs nunca se rotan y da como consecuencia un disco lleno que se pone en solo lectura y termina afectando a las aplicaciones)

A continuacion dejo unos comandos para configurar esto, el mismo crea el archivo daemon.json dentro del directorio /etc/docker

echo '{' > /etc/docker/daemon.json

echo '        "hosts": [ "tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"],' >> /etc/docker/daemon.json

echo '        "log-driver": "json-file",' >> /etc/docker/daemon.json

echo '        "log-opts": {' >> /etc/docker/daemon.json

echo '            "max-size": "10m",' >> /etc/docker/daemon.json

echo '            "max-file": "2"' >> /etc/docker/daemon.json

echo '        }' >> /etc/docker/daemon.json

echo '}' >> /etc/docker/daemon.json

Esto configura el tamaño maximo de los logs y la cantidad de archivos de logs a mantener, tambien expone la API de administracion a traves de su puerto default (2375) *

Si hacemos un CAT del archivo previamente mencionado podemos ver que los valores se escribieron correctamente en el:

Concluido esto reiniciamos el servicio de docker mediante service docker restart
En el caso que el servicio falle al iniciar ejecutar estos comandos y Docker volvera a funcionar con los cambios anteriores guardardos:

sudo cp /lib/systemd/system/docker.service /etc/systemd/system/
sudo sed -i 's/\ -H\ fd:\/\///g' /etc/systemd/system/docker.service
sudo systemctl daemon-reload
sudo service docker restart

(*) La API de administracion permite administrar Docker de manera remota, ya sea por linea de comando o utilizando aplicaciones como Portainer. Es importante destacar que esta API debe estar protegida mediante certificados TLS para evitar su mal uso.

En el caso de no poder segurizarla con certificados recomiendo bloquear acceso a este puerto desde todos los host de la red, especialmente desde Internet. En el caso de necesitar acceder a este puerto permitir mediante IPTABLES u otro Firewall unicamente la IP desde donde se administrara este equipo.

Espero que les sirva esta informacion.

Como usar el dashboard de Kubernetes en AKS

En este post vengo a mostrar como podemos utilizar el dashboard de Kubernetes, el cual nos permitira realizar operaciones sobre nuestro cluster ejecutandose en AKS.

Para poder hacerlo es necesario tener instalado en nuestro equipo la ultima version de Azure CLI.

Esta la podes descargar desde el siguiente link:

https://aka.ms/installazurecliwindows

La instalacion no tiene nada de complicado y no es necesario especificar ningun valor de configuracion.

Una vez instalado ejecutamos Windows Powershell como administrador:

az login

Este comando nos llevara al portal de Microsoft Azure para autenticarnos

Bien, ya estamos autenticados en Microsoft Azure. El paso siguiente es ejecutar el siguiente comando para autenticarse hacia AKS y luego hacer el tunel hacia Kubernetes y con esto poder acceder al dashboard

az aks get-credentials --resource-group cibiri-demo --name cibiri-cluster-demo

az aks browse --resource-group cibiri-demo --name cibiri-cluster-demo

Al ejecutar el comando anterior deberia abrirse automaticamente el dashboard en nuestro navegaodr predeterminado, pero en el caso que esto no pase podemos acceder a la URL: http://127.0.0.1:8001

Mediante este simple procedimiento podemos operar nuestro cluster de Kubernetes a traves del Dashboard.

Espero que les sirva.

Como crear un cluster AKS en Microsoft Azure

El servicio Azure Kubernetes (AKS) es un servicio administrado de orquestación de contenedores, basado en el sistema de código abierto Kubernetes, que está disponible en la nube pública de Microsoft Azure. Una organización puede usar AKS para implementar, escalar y administrar los contenedores de Docker y las aplicaciones basadas en contenedores en un clúster de hosts de contenedores.

Al igual que todos los servicios disponibles en Microsoft Azure, se puede crear y administrar un cluster tanto por CLI como por GUI. En este post veremos como crear y administrar un cluster mediante CLI

Empezamos con mi metodo favorito que es CLI y para esto se puede usar Microsoft Azure Shell basado en bash:

Como primer medida necesitamos crear un grupo de recursos nuevo (Se puede usar uno existente pero para mantener mi entorno de laboratorio ordenado vamos a usar uno nuevo)

az group create --name cibiri-demo --location westus

Creado el grupo de recursos procedemos a crear el cluster de AKS:

az aks create --resource-group cibiri-demo --name cibiri-cluster-demo --node-count 1 --generate-ssh-keys

(*) Para este ejemplo solo estaremos creando un nodo, pero tengan en cuenta que la buena practica es crear al menos 3.

Tengan en cuenta que la creacion puede tardar hasta 15 minutos en completarse:

El cluster se encuentra creado correctamente, en este caso tardo solo 7 minutos la operacion, pero se debe tener en cuenta que solo se desplego un solo nodo. Aqui se encuentra el output de la creacion con toda la informacion pertinente:

Obtenemos las credenciales para operar el cluster mediante el siguiente comando:

az aks get-credentials --resource-group cibiri-demo --name cibiri-cluster-demo

Estando logueados ya podemos hacer operaciones sobre el cluster, por ej. obtener informacion de los nodos que forman parte de la solucion y su correspondiente version:

kubectl get node

Los comandos arriba indicados son base, se pueden alternar y mezclar con diferentes opciones, como por ej. la version de Kubernetes deseada o bien el rango de IPs a utilizar dentro la solucion. En el siguiente link se encuentrand detalladas todas estas opciones:

https://docs.microsoft.com/en-us/cli/azure/aks?toc=%2Fen-us%2Fazure%2Faks%2FTOC.json&bc=%2Fen-us%2Fazure%2Fbread%2Ftoc.json&view=azure-cli-latest#az-aks-create

Algo a destacar que luego de implementado podemos hacer operaciones sobre el cluster tanto mediante GUI como CLI, pero van a encontrar muchas mas configuraciones disponibles a traves de este ultimo.

Hasta aca llegamos con la implementacion, en futuros posts veremos como desplegar servicios dentro de AKS

Espero que les sirva

Kubernetes vs. Docker Swarm: Cual es la diferencia?

Hoy en día, los containers han transformado la forma en que implementamos el software y trabajamos con microservicios. A medida que la tendencia de trabajar con contenedores virtuales basados ​​en Linux o Windows para el desarrollo de aplicaciones continúa evolucionando, ha generado mayores demandas para su administración y despliegue.

Kubernetes y Docker son dos de los principales actores en la orquestación de contenedores. Ellos Han generado una buena reputación para ellos mismos y han consolidado sus posiciones en el mercado. Ambas herramientas permiten manejar un grupo de servidores que ejecutan uno o más servicios en ellos. Entonces, antes de saltar a la parte de comparación, veamos una visión general de estas dos herramientas.

Kubernetes

Kubernetes es una plataforma de código abierto creada por Google para las operaciones de implementación de contenedores, la elasticidad, y la automatización en los grupos de hosts. Esta plataforma esta lista para producción, de grado empresarial, autorreparable (auto escalable y auto replicable) es modular, por lo que puede utilizarse para cualquier implementación de arquitectura.

Kubernetes también distribuye la carga entre contenedores. Su objetivo es liberar a las soluciones y sus componentes a los problemas que se pueden encontrar en entornos de nubes privadas y públicas. Su poder radica en el escalamiento fácil, la portabilidad independiente del entorno y el crecimiento flexible.

Docker Swarm

Como plataforma, Docker ha revolucionado la forma en que se empaqueta el software. Docker Swarm es una plataforma de orquestación de contenedores de código abierto y es el motor de agrupación de contenedores en clúster nativo de y por Docker. Cualquier software, servicio o herramienta que se ejecute con contenedores Docker funciona igual de bien en Swarm. Además, Swarm utiliza la misma línea de comando de Docker.

Swarm convierte un grupo de Hosts de Docker en un único host virtual. Swarm es especialmente útil para las personas que están tratando de sentirse cómodos con un entorno orquestado o que necesitan adherirse a una técnica de implementación simple.

Kubernetes vs. Docker Swarm

Aunque ambas plataformas de orquestación de código abierto ofrecen muchas de las mismas funcionalidades, existen algunas diferencias claves fundamentales entre cómo operan. A continuación se presentan algunos de los puntos notables. Esta sección compara las características de Docker Swarm y Kubernetes y las debilidades / fortalezas de elegir una plataforma sobre la otra.

Despliegue de aplicaciones:

Kubernetes: Una aplicación se puede implementar en Kubernetes utilizando una combinación de servicios (o microservicios), implementaciones y pods.

Docker Swarm: Las aplicaciones se pueden implementar como microservicios o servicios en un clúster de Docker Swarm. Los archivos YAML (YAML: Ain’t Markup Language) se pueden utilizar para identificar varios contenedores. Además, Docker compose se puede utilizar para definir los servicios.

Redes:

Kubernetes: el modelo de red es una red plana, que permite que todos los pods interactúen entre sí. Las políticas de red especifican cómo los pods interactúan entre sí. La red plana se implementa normalmente como una superposición. El modelo necesita dos CIDR: uno para los servicios y otro para que los pods adquieran una dirección IP.

Docker Swarm: El nodo que se une a un clúster de Swarm genera una red de superposición para los servicios que abarcan cada host en el Swarm de Docker y una red de puente de docker solo para host para contenedores. Los usuarios tienen la opción de cifrar el tráfico de datos de contenedor mientras crean una red en Swarm.

Escalabilidad:

Kubernetes: para sistemas distribuidos, Kubernetes es más bien un marco todo en uno. Es un sistema complejo porque proporciona garantías sólidas sobre el estado del clúster y un conjunto unificado de API. Esto ralentiza la escala y el despliegue de los contenedores.

Docker Swarm: En comparación con Kubernetes, puede desplegar contenedores mucho más rápido y esto permite tiempos de reacción más rápidos para escalar según la demanda.

Alta disponibilidad:

Kubernetes: Todos los pods en Kubernetes se distribuyen entre nodos y esto ofrece una alta disponibilidad al tolerar el fallo de la aplicación. Los balanceadores de carga en Kubernetes detectan pods no disponibles y dejan de enviarles tráfico. Por lo tanto, esto soporta alta disponibilidad.

Docker Swarm: como los servicios se pueden replicar en nodos Swarm, Docker Swarm también ofrece alta disponibilidad. Los nodos master de Swarm son responsables de todo el clúster y manejan los recursos de los nodos de trabajo.

Configuración de los contenedores:

Kubernetes: Kubernetes utiliza sus propias definiciones de YAML, API y cliente, y cada una de ellas difiere de la de los equivalentes estándar. Es decir, no se puede utilizar Docker Compose ni Docker CLI para definir contenedores. Al cambiar de plataforma, las definiciones y los comandos de YAML deben reescribirse.

Docker Swarm: La API de Docker Swarm no abarca por completo todos los comandos de Docker, pero ofrece gran parte de la funcionalidad familiar de Docker. Es compatible con la mayoría de las herramientas que se ejecutan con Docker. 

Balanceo de carga

Kubernetes: Los pods se exponen a través de un servicio, que se puede utilizar como un balanceador de carga dentro del clúster. Generalmente, se utiliza una entrada DNS para equilibrar la carga.

Docker Swarm: El modo Swarm consiste en un registro DNS que puede utilizarse para distribuir solicitudes entrantes a un nombre de servicio. Los servicios pueden asignarse automáticamente o pueden ejecutarse en puertos especificados por el usuario.

Conclusiones

Kubernetes soporta mayores demandas con mayor complejidad, mientras que Docker Swarm ofrece una solución simple que es rápida para comenzar. Docker Swarm ha sido bastante popular entre los desarrolladores que prefieren las implementaciones rápidas y la simplicidad. Al mismo tiempo, Kubernetes se utiliza en entornos de producción por varias empresas de Internet de alto perfil que ejecutan servicios populares.

Tanto Kubernetes como Docker Swarm pueden ejecutar muchos de los mismos servicios, pero pueden necesitar enfoques ligeramente diferentes para ciertos detalles. Entonces, al aprender Kubernetes y Docker y compararlos para varias características, se puede tomar la decisión de elegir la herramienta adecuada para la orquestación de contenedores.