#18 no es necesario contratar un loadbalancer en la nube, puedes montar un loadbalancer muy fácil por software con MetalLB para asignar una IP al ingress controller y para los PVC había un repo que se conectaba con un NFS de esta manera todo se queda inhouse y no hay que pagar tanto como en un cloud provider.
Era solo como curiosidad lo demás estoy de acuerdo al 200%
#61 todo lo que hace la nube puedes hacerlo tú, la gracia de usar el LB es que te quitas de gestionarlo tu, al igual que el storage.
Además, si el load balancer lo montas tu, debes crear un servicio nodeport y que e load balancer haga balancee entre todos los worker al puerto del servicio
En cuanto a lo del NFS ten en cuenta que un NFS es un storage de tipo File (que también te ofrece el Cloud y te gestiona los backups) mientras que el storage por defecto que suelen proveer los clusters Salas es de tipo Block, como por ejemplo la clase gp2 de aws
Te puedes poner traffik que es la leche https://doc.traefik.io/traefik/providers/kubernetes-ingress/
Load Balancer e Ingress Controller
#63 hazle caso a este ioeputah que sabe lo que se hace, actualmente usamos traffik en nuestro proyecto y es una maravilla.
Por otro lado veo que vas fuerte a microservicios ( K8S ), si quieres un punto de potencia en esos pods metele DAPR, usa el principio de sidecar pattern y tienes tracing mucho mas preciso, asi puedes indentificar los cuellos de botella.
#63 #64 Lo tengo en cuenta para pasar de nginx a traffik. Aunque, de momento tengo parado el tema del kubernetes (está funcionando con proxies, grafana y poquito más).
Estoy en proceso de:
Entre estos dos puntos hay cambios muy muy grandes a lo que tengo ahora y me está llevando un tiempo que no esperaba.
Pendiente:
El tema de DAPR se me escapa, y no sé si realmente le puedo sacar provecho en el punto en el que estoy.
Pendiente:
Tengo más de 20 servicios y timers en linux para la ejecución de cada script de python.
Todos servicios llaman a un mismo módulo de python, pero le pasan una variable 'Script 20' que es la que mediante un diccionario obtengo el nombre del módulo de python que he de ejecutar.
Por lo tanto, no le veo beneficio al DAG de Airflow, es decir, no veo que me puede aportar a parte de la interfaz gráfica ya que no trabaja con los servicios de linux. Por lo que me parece que pierdo "robustez".
Actualizo con pocas novedades.
El clúster de kubernetes de oracle no es gratuito, intenté montarlo por mi cuenta pero no conseguí configurar el load balancer de oracle con las instancias. En definitiva, todo borrado y un nuevo server con toda la web, base de datos, y otras app todo en contenedores de docker formando "stacks".
Lo mismo en el servidor principal, muchos contenedores formando stacks. La única excepción es el código de scraping que está en el propio linux. En general, mucho mejor tener todo en container con su respecto docker-compose, etc...
La web sigue pendiente de pasar a reactjs (tengo casi todo hecho, pero quería aprovechar para hacer cambios en la DB y al final lo he dejado pendiente).
La recomendación de traefik fue muy acertada, ya lo he desplegado en varios servidores y perfecto.
También, he revisado en detalles reglas de acceso a los servidores e tengo implementado fail2ban para bloquear IPs que hacen intentos de acceso. El acceso ssh solo está habilitado por clave privada, pero el acceso a la DB es otro tema (réplica).
Hago un up. Estado:
Finalmente conseguí montar un clúster de kubernetes en Oracle (Gracias a un terraform the Github)
El resto lo tengo en contenedores docker
Backend -> Python
Frontend -> Nextjs
BD principal -> Postgresql
BD secundaria -> sqlite para pequeñas cosas
Planificador de servicios -> Prefect
Monitorización -> Prometheus, InfluxDB y Grafana (Sí, tengo dos BD diferentes...)
Reserve proxy -> Traefik
Accesos por ssh por identidades
Fail2ban para banear IP's de forma indefinida (quizás exagerado...)
#68 En básico me falta un IPS... yo desde que he metido Snort https://www.snort.org/ ... tengo el servidor 98% más tranquilo xD Lo recomiendo a cualquiera que tenga un servicio en la nube.
** Existen soluciones más modernas como suricata... pero no las he probado.
#69 No es excesivo ? Qué ventajas de lleva aportar para estar más tranquilo ? Imagino que te alertará cada 2x3 de intentos de acceso ? Tendría que investigar sobre cómo funciona...
#70 Puedes, por ejemplo... solo permitir conexiones desde España... o denegar países como Rusia, China, ....
Además, algo a tener en cuenta es como Docker maneja iptables... por lo que tengo entendido fail2ban trabaja en la cadena INPUT (aplicable al host) mientras que Docker trabaja en FORWARD... cuando fail2ban inserta la regla en iptables, realmente no está bloqueando el acceso al docker. No se como tienes fail2ban... si lo tienes fuera del contenedor que pretendes proteger o dentro.
Snort se fo*** todo... te va a filtrar cualquier paquete que llegue al sistema.
