ñ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
-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:
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:
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:
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.