Mejores Recursos para Docker

94 views
Skip to first unread message

Carlos Admirador

unread,
May 7, 2019, 5:54:42 AM5/7/19
to AltNet-Hispano
Hola gente !!!

Basándose en su EXPERIENCIA REAL WORLD, qué recursos recomiendan de Docker de los 148 millones de referencias que proporciona Google?






Gracias!

Kiquenet

unread,
Jan 24, 2024, 10:22:35 AM1/24/24
to AltNet-Hispano

Experiencias con Docker ? buenas prácticas?

Potenten para desarrollo,sí, pero  cómo realizar actualizaciones, migrations, etc en un entorno docker productivo ?

Kiquenet

unread,
Jan 31, 2024, 9:30:15 AM1/31/24
to AltNet-Hispano

Miguel Angel Jimenez Perez

unread,
Jan 31, 2024, 3:08:48 PM1/31/24
to AltNet-Hispano
Sobre docker tengo experiencia en produccion. Manejo alrededor de 6 docker host con aprox 1029 containers en ellos. Estan corriendo en AWS en ec2 instances.

Puedo responder preguntas si tienen alguna. Sobre guias y eso, no te puedo recomendar una porque nunca segui una, todo fue sobre la experiencia y leer documentacion.

Docker en window, no lo recomiendo, nunca ha estado estable, tengo un docker host de windows corriendo en AWS solo por 10 aplicaciones, y fallan cosas de vez en cuando que requerimos reiniciar el server.

Kiquenet

unread,
Feb 5, 2024, 2:38:35 AM2/5/24
to AltNet-Hispano
Gracias! Desde la ignorancia pueden surgir muchas preguntas.

Sql server en contenedores Linux ? versiones Alpine?

Configurar secretos para usar en dockerfile

Cómo mantener la persistencia de los datos en los contendores, ej: migrations de entity Framework, despliegue de proyectos NET

Herramientas de monitorización para los contenedores

Docker Networking: Comprender cómo funcionan las redes en Docker es crucial. Conoce los diferentes tipos de redes y cómo conectar contenedores.

Miguel Angel Jimenez Perez

unread,
Feb 5, 2024, 10:38:46 AM2/5/24
to altnet-...@googlegroups.com
ñla regla dice, en producción nunca uses bases de datos en containers.si las usas para tus ambientes non-prod, es entendible, pero para un ambiente de producción no lo recomiendo. No he usado  sql server en linux, pero entiendo que funciona bien. No se que tan compatible sea con alpine, pero sí alpine tiene los paquetes necesarios para que corra sql server, no debe ser un problema. En sí alpine lo que te da es un OS ligero para que corras de tu entorno en el container.

sobre docker secret, solo funciona si tienes un swarm de docker hosts, si tu docker host esta aislado, vas a tener un error como:
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

Puedes usar alternativas como hashicorp vault y bajar los secretos en tu entrypoint. pero eso ya depende del gusto de cada quien.

Persistencia de datos, generalmente las aplicaciones guardan datos en disco, lo que tienes que hacer en tu docker host, tener un path dedicado a guardar los datos de tus contenedores, por ejemplo: /srv/docker_volumes/app01

Y en tu container tienes que hacer un bind mount(https://docs.docker.com/storage/bind-mounts/), donde mapeas un folder interno del contenedor a un folder externo en el disco del docker host, por ejemplo:
-v /srv/docker_volumes/app01/logs:/var/log

Para monitorear, tienes que exponer las metrics del docker host y los containers, puedes usar prometheus, configurar un server de prometheus que este leyendo las metrics y las exporte con un endpoint, y tu con un prometheus server las jales:
Otra manera es con opentelemetry, pones el otel-collector, que use un reader de docker, hay uno oficial por ahi, lee las metrics y pudes hacer un write a un server de prometheus. Ya tus metricas en prometheus puedes usar grafana para hacer tus dashboards y alarmas.

Como funciona la red en docker no es tan complejo.
Docker internamente cuando un container se crea, se crea un adaptador ethernet virtual:
image.png
Ese adaptador es el que proporciona una ip a tu container.Dependiendo la network que uses(bridge es la de default), es el rango de ip que te da, normalmente da ips en el rango 172.17.0.0/16, pero es configurable:
image.png
Bueno, esa ip, es una red interna, y a esa ip se attachan tus servicios, para exponer los puertos que se necesitan.
cuando tu expones tus services, tienes que indicar en que ip del docker host vas a exponer tu servicio y en que puerto:
-p 10.69.12.85:9743:443

Que significa, el puerto 443 interno, lo voy a exponer en el puerto 9743 en la ip: 10.69.12.85
Entonces docker automaticamente, crea una regla en iptables para que cuando se reciban paquetes en esa ip y en ese puerto, se manden a esa otra red a ese puerto en especifico:
image.png
image.png


Puedes crear una red propia y definir un CIDR block en especifico y hacer otras cosas mas complejas, pero no valen tanto la pena al final, porque solo complicas el troubleshooting cuando algo malo pasa.

Por ultimo, mi recomendacion es siempre manten el puerto de docker(2375 o 2376 si usas https), protegido detras de un reverse proxy como nginx o haproxy, crea un whitelist y solo deja pasar las ips que te interese.
Hay una forma de poner un RBAC a docker, antes usaba twistlock pero es de pago. Donde trabajo, otras personas estuvieron antes que yo a cargo de los docker hosts, y uno de ellos creo una herramienta llamada docker enforcer, que precisamente se trata de crear reglas y si un container no la cumple, lo detiene:

Que reglas te recomiendo:
  • Limites de CPU y memoria, si un container es comprometido, nada evitara que colapse el server consumiendo todos los recursos
  • Labels: tienen que etiquetar sus container, quien es el dueño, a quien contactar si falla algo o comienza a hacer cosas raras
  • Naming: que los nombres tengan sentido, nosotros usamos: {environment}_{company}_{product}_{service}
  • No usar privileged mode. No hay justificación de usar el  privileged mode. No hay razon para que un container tenga acceso al host y menos al filesystem del server. Hay contadas excepciones, pero para un container de wordpress, no.
  • Docker capabilities, hay contenedores que puede que necesiten ciertas capabilities, que son accesos a servicios kernel en el server. No deben tomarse a la ligera porque en caso del container sea comprometido, va a provocar un desastre.
Por ultimo, nunca expongas el puerto de administración del docker daemon al internet, por muy cómodo que sea. Mejor usa un jumpbox o una VPN para administrarlo si tu red esta en cloud o un sitio remoto. He tenido casos de gente que expone el puerto y en cuestion de minutos ya tiene contenedores minando y haciendo escaneos de la red y ddos attacks.

Preguntas relacionadas de como usar tecnologías de microsoft en docker y demas, no te las puedo contestar porque ya desde hace como 8 años me aleje de ellas. Tengo un dockler host en windows 2019 por cuestiones legacy, y de vez en cuando tengo que reiniciarlo por un bug que tiene windows con la hyper-v, y son solo sitios web en iis. Asi que una experiencia de 1era mano como funciona con X tecnología o con el último framework de .Net, no tengo idea.

Saludos.






--
Has recibido este mensaje porque estás suscrito a un tema del grupo "AltNet-Hispano" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/altnet-hispano/688Hxe7pK5c/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/altnet-hispano/275d6e31-8545-46a8-addd-8ec9538a90a6n%40googlegroups.com.

Kiquenet

unread,
Feb 13, 2024, 6:37:32 AM2/13/24
to AltNet-Hispano

 Muchísimas gracias, una información muy valiosa!!!

Entiendo que de alguna forma se podría utilizar SSH (necesario abrir puerto) para ejecutar comandos hacia el contenedor.
Es la única forma de ver lo que tiene el container, no? (docker exec ??)

Ni MongoDB, ni postgresql, etc. en producción nunca

docker desktop para Windows requiere licencia?

habrá alguna forma de recuperar los logs STDOUT  de los container?


 

Miguel Angel Jimenez Perez

unread,
Feb 13, 2024, 5:32:29 PM2/13/24
to altnet-...@googlegroups.com
No se recomienda poner un servidor ssh en un contenedor. Si necesitas conectarte al contenedor, docker exec debe ser suficiente: https://docs.docker.com/engine/reference/commandline/container_exec/

El problema es que muchos piensan que un contenedor es una especie de mini máquina virtual. Cuando más bien es un conjunto de procesos enjaulados en un cgroup en un servidor. Entonces, un contenedor debe correr un solo proceso normalmente. Ahora si necesitas varios procesos corriendo en un contenedor, se pueden usar controladores de procesos como supervisord, chaperon o multirun.Pero de nuevo, si necesitas ssh para albergar un server de sftp, es entendible, pero solo para dar acceso a verificar los procesos dentro de un contenedor, es una mala práctica, por cuestiones de seguridad.

Respecto a bases de datos, de nuevo, es decision de cada quien, pero a mi se me hace una mala práctica, y en producción las veces que he visto deployado bases de datos, en la mayoría de los casos deciden migrarlas a instancias en máquinas virtuales, RDS instances o servidores dedicados a base de datos. Muchas veces por complicaciones que surgen durante el parcheo o deployment de nuevas versiones.

Docker desktop si necesitas licencia, o sea no te van a forzar a que la compres, pero quizás te están enviando correos o contacted a tu compañía si detectan algo.

Lo que se aviente al stdOut o stdError, lo puedes ver con el comando docker logs(https://docs.docker.com/engine/reference/commandline/container_logs/). El docker daemon tiene la configuracion(/etc/docker/daemon.json) de cuanto se queda almacenado de log y por cuanto tiempo. Normalmente se almacena en archivos json, pero existen plugins para mandar tus logs a otro lado, rsyslog o grafana loki. Ahi es cosa que analices si te conviene tener los logs centralizados o en cada server.

Aca listan un conjunto de anti-patterns en docker:

Algo que tienes que tomar en cuenta es que una docker image tiene que se idempotente. Es decir, es como congelar un punto en el tiempo la aplicacion, con sus dependencias, archivos estaticos, etc. Logicamente hay configuraciones dinamicas, pero lo que quiero dar a entender es que por ejemplo si tienes un esquema de pruebas donde 1ero deployas la imagen a development, cambiando los valores de configuracion para apuntar a tu ambiente dev, debe funciona igual que si la configuras con los valores de staging o prod. O sea la imagen es idempotente en cada ambiente, lo que cambia es la configuracion.

Yo me he topado con muchos casos donde las personas deployan una imagen, y dentro de la imagen, dependiendo del ambiente, comienzan a hacer configuraciones o modificar al vuelo el contenido del contenedor, no es malo, pero es una mala práctica. Porque si usas ese container en kubernetes y tienes un esquema de escalabilidad, tu contenedor no va a poder se deployado tan rapido en caso de hacer un scale up de la infrastructura por demanda de trabajo.Igual pasa con upgrades, tienden a hacer upgrades dentro de la instancia corriendo, eso esta mal porque afectas los layers y lo unico que provocas es una diferencia es lo que tiene el container con lo que tiene la imagen. Si necesitas hacer upgrade de paquetes, de los binarios de tu aplicacion o de los archivos estaticos, genera otra docker image, y la deployas. Pero es una mala practica es hacer upgrade dentro de un contenedor que esta corriendo, porque si el server truena y no puedes recuperar esos cambios, cuando intentes deployar tu imagen en otro lado, no vas a tener todos esos cambios.




--
Has recibido este mensaje porque estás suscrito a un tema del grupo "AltNet-Hispano" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/altnet-hispano/688Hxe7pK5c/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a altnet-hispan...@googlegroups.com.

Kiquenet

unread,
Feb 15, 2024, 7:13:15 AM2/15/24
to AltNet-Hispano
Grandioso, toda una clase magistral, GRACIAS!

Entiendo que hay que cambiar la mentalidad y no pensar con VMs.
Entender docker image y la instancia de la misma (contenedor con su configuración), docker exec, los volúmenes, docker networking son la clave.

dudas:
qué editor recomendado para los ficheros dockerfile y los YML de docker compose? Visual Studio Code con extensiones?

varios procesos corriendo en un contenedor, se pueden usar controladores de procesos como supervisord, chaperon o multirun,
no es lo mismo que Kubernetes, no?

Relación docker con DevContainers?

  1. Install Docker Desktop
  2. Install an IDE capable of connecting to a remote development environment (Visual Studio Code has the best support for this today)
  3. Download your source code
  4. Two clicks to build your development environment in a container


1. Install Docker Desktop

2. Install Visual Studio Code

3. Install the Visual Studio Code Dev Containers extension

4. Install Git and clone the devcontainer-java-example

  • If you’re on Windows, we recommend you do this within WSL2 for disk-I/O performance reasons.
    wsl --install -d Ubuntu + wslconfig /setdefault Ubuntu in your terminal
    - Install the WSL extension in Visual Studio Code too.

5. Open the repo folder in Visual Studio Code and run the Reopen in Container action. You can do this in three different places


Reproducible Local Development with Dev Containers
https://medium.com/cwan-engineering/reproducible-local-development-with-dev-containers-0ed5fa850b36




Captura de pantalla 2024-02-15 125933.png

Miguel Angel Jimenez Perez

unread,
Feb 15, 2024, 1:08:31 PM2/15/24
to AltNet-Hispano
Editor, como siempre, cualquiera te sirve. VS code te da syntax highlight como sublime text, nano o vim. VS code te bajas la extension de docker y te da ciertas herramientas pero sinceramente no las uso, solo el syntax highlight.
Si necesitas un editor que te ayude a comenzar a crear Dockerfiles o yamls, trata con cursor, esta basado en VS code y tiene asistencia por AI, y con AI te guia un poco al momento de crear estos archivos.

Kubernetes es otro tema, kubernetes es mas bien un orquestador de contenedores. La idea con kubernetes es que puedas correr contenedores de manera escalable en multiples nodos, los nodos adentro tienen docker o containerd y ahi corren los contenedores. Es kubernetes que se encarga que cuando alguien quiere que corra un contenedor(en kubernetes son pods, un pod puede tener multiples contenedores). El pod se puede deployar a cualquier nodo del cluster de kubernetes.

Ahora, en un cluster de kubernetes, los pods son deployados por un deployment, un deployment puede tener muchos pods, y un pod puede tener replicas. Entonces un pod puede tener muchas replicas por temas de escalabilidad.
Por ejemplo, tengo un pod que tiene el frontend de mi aplicacion, como tengo muchos requests a cierta hora del dia, hay algo llamado vertical scaler, que puedo configurar que si detecta ciertas metricas, como por ejemplo numero de request por segundo, y si pasa de cierto nivel, automaticamente cambia el deployment y aumenta las replicas, por ejemplo a 5. Entonces kubernetes va y crear 5 replicas para balancear la carga de esa aplicacion, crea 5 pods.

A su vez kubernetes puede tener un horizontal scaler, donde dependiendo de la carga de trabajo del cluster, puede aumentar o disminuir los nodos del mismo a discrecion, en donde estoy esto lo combinamos con el uso de spot nodes en AWS, eso reduce mucho tu costo, pero tienes que tener al menos 3 replicas de tus servicios, porque AWS de la nada te termina un nodo y en lo que otro se crea y los pods se deployan, vas a tener situaciones de lentitud. Pero es relativo, porque se compensa en el tema de costos.

Devcontainers entiendo que lo que hace es correr VS code o tu set de tools en un contenedor para aislar tu ambiente de desarrollo. No lo he usado, la verdad no me gustan, hay otros como devspaces y similares. Pero no te puedo dar opiniones de ellos por de nuevo, una vez intente usarlos, no me gustaron, y la verdad siempre me es mas facil iniciar una VM en hyper-v o en mi cluster de vmware con terraform, y ahi hacer mis cosas.

 Kubernetes es un herramienta interesante, pero te recomiendo 1ero empieza con un docker host, deploya cosas, acostumbrate a la idea de contenerizar aplicaciones, y de ahi ya con un problema a resolver(temas de escalabilidad de una aplicacion, administrar muchos microservicios, etc) analiza si kubernetes es aplicable o no. Adicional, kubernetes demanda recursos, al menos necesitas 3 nodos para empezar y eso cuesta.

Otra sugerencia, si vas a tener tus aplicaciones en docker(o kubernetes), explorar temas como prometheus, open telemetry, grafana y grafana loki. Porque es muy util tener todas esas metricas y logs en un solo lugar.

Miguel Angel Jimenez Perez

unread,
Feb 15, 2024, 1:23:33 PM2/15/24
to AltNet-Hispano
Me falto agregar algo, la diferencia sustancial entre docker y kubernetes en un tema que muchos no toman en cuenta: storage

En docker, tu puedes configurar el storage, usar bind volumes y mapear casi cualquier tipo de storage como un filesystem normal, un LVM, NFS o un s3 bucket. Tengo contenedores que usan solr y usan como 45TB de storage.

El problema con kubernetes es que el storage tiene que irse acarreando o pasando entre nodos, y si tienes muchas replicas no puedes compartir el storage. En AWS hay maneras de hacer un multi attachmente de EBS volumes, puedes usar NFS o AWS EFS, pero hay detalles con el perfomance. Adicional el storage en kubernetes por default es efimero, es decir cuando por x o y el pod muere. Todos se va con el, lo que hayas almacenado se desaparece. En docker si detienes el container, todavia queda almacenado en los layers los datos(si lo remueves, es decir: docker rm <container>, si borra los layers).

Lo que quiero decir es, si tu aplicacion necesita mucho storage o hace mucha escritura al disco, lo mejor es usar docker hosts si vas a tener ese workload en containers. Si quieres usar kubernetes, si puede funcionar pero vas a tener una implementacion mas complicada. Puedes usar statefulsets, pero siempre hay detalles. No es imposible, pero si vas apenas comenzando, no lo recomiendo.

por ultimo, en docker puedes tener un sistema de replicas igual, por ejemplo deployar multiples veces el mismo contenedor exponiendo el puerto http en diferentes numero de puerto. Eso en kubernetes se le conoce como ingress controller, es decir un controller que recibe notificaciones de a donde tiene que redirigir requests que le lleguen a manera de un reverse proxy y balancear los requests entre las diferentes replicas.

En docker puedes hacer algo asi con nginx-proxy: https://github.com/nginx-proxy/nginx-proxy

entonces, en docker, inclusive en el mismo nodo, puedes tener 2 contenedores atendiendo tu website(por ejemplo, pueden compartir el bind volume donde se guardan los attachments que suben), y con nginx-proxy expones en un solo endpoint tu website, y las cargas van a ser balanceadas entre los dos contenedores. inclusive podrias tener 2 docker hosts, en cada uno un contenedor y balancear la carga entre ellos 2. Ya ahi el tema de un volumen compartido puede varias, EBS volumes multi attached o puedes usar un NFS, etc etc.

Espero esto te ayude a tener un panorama general que evite que si propones docker o kubernetes, el que te topes una situacion asi provoque que tu propuesta se venga a abajo o que piensen que es una tecnologia endeble. Que no lo es, ya tiene muchos años en el mercado y yo tengo ambientes de produccion desde el 2017 a la fecha corriendo ahi.

Roger Isaac Navarro Perez

unread,
Feb 20, 2024, 11:01:51 AM2/20/24
to altnet-...@googlegroups.com
En varios proyectos donde e estado usan docker con kubernetes para levantar microservicios en la base de datos usa un rds mejor, ya que si es levantan nodos dinámicamente seguramente vas a querer que tus datos sean independientes de tus instancias, para desarrollo puedes levantar un contenedor con la base de datos y solo hacer el migrate del esquema cuando se levanta el contenedor, ademas que tambien manejas secrets los cuales se gestiona desde el cluster, si todo esto lo juntas con devops es una maravilla, lo cual genera varias configuraciones tanto para dev como prod.

Saludos.


--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/altnet-hispano/636715a7-7bb9-4d54-aec8-932f80456b41n%40googlegroups.com.


--
AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo, pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atencion única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito esta prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualesquiera copia del mismo.

CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended only for the person or entity to which it is addressed and may contain confidential and /or privileged material. Any review, use, disclosure or distribution of such confidential information without the written authorization is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Kiquenet

unread,
Jan 30, 2026, 5:36:09 PM (8 days ago) Jan 30
to AltNet-Hispano
Experiencias con  devcontainers ?
Leí algún comentario: "Ya no trabajamos sobre Windows usamos devcontainer y trabajamos sobre wsl. La verdad me gusta más porque no marraneas el sistema. "

Windows 11 con Stack: NET 7 c# para microservicios rest api, visual studio code, activemq para colas, sql server en docker compose ,... docker desktop no se instala, por licencias, se instala manual el docker engine.
WSL2 configurado con Ubuntu.
GIT con GitLab

Aplicaría devcontainers + testcontainers + PACT + kubernetes? tiene todo esto sentido ?

 Qué NO hacer ?
  • ❌ Git en Windows

  • ❌ Docker en Windows sin Desktop

  • ❌ .NET SDK instalado en host

  • ❌ Abrir proyectos desde /mnt/c

  • ❌ Mezclar toolchains host/container


  1️⃣ Multi-devcontainer (uno por microservicio)
   3️⃣ GitLab CI/CD (build + test + docker)
  4️⃣ Debugging cross-container

  • Un repo = N devcontainers

  • Tests corren igual en local y CI

  • Debug real entre contenedores

  • Docker Desktop innecesario

  • Cero tooling en host

     1️⃣ Contract Testing (PACT)   

   2️⃣ Testcontainers (.NET)
  3️⃣ GitLab CI — contracts + integration
   4️⃣ Observabilidad 
  • OpenTelemetry

  • Prometheus

  • Grafana

  • Jaeger

  1️⃣ Chaos testing (Docker / local / CI)
2️⃣ Chaos load + assertions (k6)
3️⃣ SLOs (Prometheus
4️⃣ Error Budget Burn
5️⃣ Alerting por trazas (Grafana Tempo)      

Reply all
Reply to author
Forward
0 new messages