search

python-spain / asociacion

Repositorio con issues para gestionar el trabajo que realiza la asociación de Python España.
17 stars 3 forks source link

Estandarizar gestión de docker containers en instancias #146

Closed dukebody closed 1 year ago

dukebody commented 2 years ago

Ahora mismo tenemos 4 instancias en Scaleway con varios servicios, que se despliegan de formas diferentes cada uno.

Queremos estandarizar en la medida de lo posible la gestión de estos recursos, simplificando lo máximo posible.

Tareas:

dukebody commented 1 year ago

Que yo recuerde, tenemos:

dukebody commented 1 year ago

Quien colabora necesita acceso. Nos puede pasar las claves públicas para que las metamos para acceder.

dukebody commented 1 year ago

La base de datos está en la misma instancia, no administrada por Scaleway.

aalmiramolla commented 1 year ago

Hola @dukebody, Hemos estado hablando @alexgmin y yo, y hemos acordado el siguiente plan de acción para este issue:

alexgmin commented 1 year ago

Hola, @dukebody

@aalmiramolla Ya hemos analizado las instancias y hemos visto que hay en cada una..

Tenemos varias opciones de como mantener y estandarizar todo, por listar algunas:

  1. Montar un kubernetes con todo.
  2. Migrar a un servicio de contenedores autogestionados, tipo AWS ECS o Scaleway Serverless Containers.
  3. Ponerlo todo en una instancia dedicada grande en lugar de tener una para cada servicio, en Hetzner, por ejemplo.
  4. Otras opciones

Luego para la base de datos de la página de socios también es contemplar si vale la pena tener algún servicio de managed postgres, tipo AWS RDS, Crunchydata, o las managed databases de Scaleway.

Nuestra idea es hacer una lista de las opciones que vemos, hacer un cálculo de cuanto costaría cada una con los servicios actuales y sus pros/contras. Por ejemplo, el punto 2 es probablemente menos barata que 1 o 3, pero al mismo tiempo es probablemente la que menos mantenimiento requeriría con mantener los sistemas actualizados, que es también algo a tener en cuenta.

Así que las preguntas son:

dukebody commented 1 year ago

Hola @alexgmin .

Gracias por la investigación. Te contesto abajo.

¿Seguimos por esta ruta de hacer una lista de varias opciones?

Sí, por favor.

¿Quien/quienes tendrían que tomar la decisión?

Podéis tomarla vosotros, con autorización de la Junta si hay cambio significativo en el coste mensual.

¿Hay algún factor que sea mucho más importante que el resto? Por ejemplo, es coste mensual más importante que el tiempo que luego requiera el mantenimiento?

Para mí el factor más importante es el bajo coste temporal de mantenimiento y sencillez. No importa pagar unos €s de más mensuales si así se simplifica todo, dentro de lo razonable. Por eso lo mejor es hacer la lista de alternativas con su coste y ver si la simplificación merece la pena el coste monetario extra.

¿Podemos contemplar otras opciones fuera de Scaleway?

Sí, pero en ese caso, tened en cuenta los costes y riesgos de migración. A mi parecer, si no existen mejoras sustanciales en la simplificación del sistema, mejor no invertir el tiempo en migrarlo.

Algunas consideraciones propias Así de primeras, la opción más lógica me parece meter todo en la misma instancia y así evitar tener que pagar y mantener cuatro.

Montar un Kubernetes o similar para los pocos servicios y tan pocas necesidades de alta disponibilidad que tenemos me parece un esfuerzo de difícil justificación.

Por otra parte, tened en cuenta que Discourse es un sistema algo raro por como se configura e inicia, lo que puede crear algún problema con estandarizaciones en contentedores. Echadle un ojo a la instancia y veréis de lo que hablo.

sincorchetes commented 1 year ago

Buenas, siento haberme desvinculado tanto de la organización, me pasó este issue @alexgmin via Telegram.

Por lo que vi en el documento de infra:

Hay 3 instancias corriendo y 1 en standby:

Creo que para las instancias estáticas simplemente sirve el GitHub Actions. Para el moodle y discourse se puede contenirizar. La máquina vieja se puede copiar con borg y mantenerla guardada en algún sitio como un S3 si no se ha echado en falta en este tiempo.

Kubernetes -> Coincidiría con @dukebody, sería tener una déuda altísima para lo que tenemos. Hay que crear las automatizaciones con Ansible, integrar el CI/CD no sé si con un Jenkins o GitHub Actions si lo permite, meter monitorización con Grafana, Prometheus...

Yo creo que simplemente una VPS en Hetzner, que sea una instancia con Docker o Podman (según se mire) valdría suficiente. Los pases se pueden hacer mediante un simple script y un servicio que compruebe que hayan cambios en el directorio de la máquina, o mirar de hacerlo con GitHub Actions.

Tendríamos un snapshot de la máquina virtual, por si hay que reemplazar. Se podría hacer backups de la máquina con el Storage Box que da el propio Hetzner que no es caro y utlizando Borg para las copias.

Para el enrutamiento, configuraríamos Traefik con Let's Encrypt para dirigir las peticiones hacia los contenedores correspondientes.

Los yamls de configuración de la infra, la dejaríamos en un repositorio aparte. Para la base del SO propongo utilizar AlmaLinux o RockyLinux ya que son las distribuciones a nivel clónicas de RHEL siendo esta la más utilizada por la industria como base estable y sin tanto relleno (configuraciones adicionales, extras...etc) en la instalación de servicios.

dukebody commented 1 year ago

¡Hola @sincorchetes ! Gracias por un comentario con tanta información tan útil.

python-es: una instancia que solo sirve containers o webs estáticas. El servicio principal que tiene es el panel de socies. El panel de socies no es estático, es una app de Django. He hecho una propuesta a la Junta de sustituir este panel de socies por un Excel para simplificar y tener un servicio menos que migrar y mantener.

Me parece buena idea lo que planteas de un VPS en cualquier sistema cloud (Hetzner o lo que veáis mejor relación calidad, simplicidad y precio) y docker/podman.

No entiendo lo siguiente:

Los pases se pueden hacer mediante un simple script y un servicio que compruebe que hayan cambios en el directorio de la máquina, o mirar de hacerlo con GitHub Actions.

¿A qué te refieres con "los pases"?

Para el moodle y discourse se puede contenirizar.

Al menos Discourse está containerizado ya. Pero tiene un sistema de containers propio que intenta simplificar pero es bastante complejo. Ver https://github.com/discourse/discourse_docker.

Sobre backups, si con Borg es fácil estupendo, pero no sé si hay proveedores que automatizan la creación de backups sin tener que "instalarla" uno mismo. ¿Qué opinas?

Sobre enrutamiento, de nuevo lo que veáis mejor. Ahora mismo me consta que en algún sitio usamos https://caddyserver.com/, pero Traefik suena bien también. No se si están al mismo nivel o son proyectos totalmente distintos :sweat-smile:

SO el que queráis. Yo normalmente he utilizado Debian-based, pero si sabéis manejaros mejor con los tipo RHEL adelante.

¿Cómo tiramos esto adelante? ¿Podéis hablar entre @sincorchetes , @aalmiramolla y @alexgmin y tomar una decisión en cuanto al stack? ¿Necesitáis más información de algún tipo?

Gracias de nuevo por el currazo.

alexgmin commented 1 year ago

Hola @dukebody

La idea es hacer una llamada los 3 la semana del 21, en principio no necesitamos nada más que yo sepa.

Yo creo que con un poco de esfuerzo y organización podemos tenerlo todo organizado en septiembre.

Yo no soy muy fan de usar RHEL para este caso si la idea seria dockerizar todo, de forma que lo único que se usa del host sería docker y poco más.

Además de lo que se ha dicho ya, aporto algunas cosas que idealmente habría que considerar.

dukebody commented 1 year ago

¡Hola!

Hemos estado hablando @alexgmin y yo por Telegram y hemos desviado la conversación un poco a cómo reducir al máximo el coste de mantenimiento de todo esto. Una de las conversaciones más productivas de la historia del IT de Python España jeje.

Con esto, la única infra administrada que quedaría propia serían el registro de dominios y el DNS, con CDMon.

El resultado es que es posible que no haya que montar ningún VPS, sistema de backups ni nada... Puede parecer un poco aguafiestas porque no se podría "cacharrear y jugar", pero esto mejoraría enormemente el futuro de la Asociación al eliminar la necesidad de gente que se encargue en el futuro de administrar los sistemas.

Como bonus, curiosamente nos saldría todo incluso más barato, ya que ahora mismo pagamos unos 55€ al mes por Scaleway, y Moodle y Discourse hosted nos saldría por 20€ en la opción más barata. :tada:

En cualquier caso, el trabajo que sí quedaría seguro sería:

Comento todo esto con la Junta el lunes y os digo algo.

Como apunte final, usamos https://www.freshworks.com/website-monitoring/ para uptime monitoring. Acabo de añadir la actual web de socies.

dukebody commented 1 year ago

Tenemos el OK de la Junta Directiva para el plan de simplificación enunciado más arriba.

Es decir, mover la app de socies a un Excel y el servicio de Discord a hosted. El Moodle de momento no lo movemos, y si en unos meses no se ha hecho nada con él, lo eliminamos y punto.

@alexgmin @sincorchetes @aalmiramolla ¿Podemos crear issues con tareas/subtareas para realizar la extracción de datos y migración de los servicios actuales?

dukebody commented 1 year ago

Sobre migración, la máquina "ye-olde-python" creo que tiene algunos datos como fotos y tal. Lo mejor sería empaquetar lo que haya ahí y subirlo a Google Drive, donde tenemos muchos gigas de espacio gratuito.

sincorchetes commented 1 year ago

Tenemos el OK de la Junta Directiva para el plan de simplificación enunciado más arriba.

Es decir, mover la app de socies a un Excel y el servicio de Discord a hosted. El Moodle de momento no lo movemos, y si en unos meses no se ha hecho nada con él, lo eliminamos y punto.

@alexgmin @sincorchetes @aalmiramolla ¿Podemos crear issues con tareas/subtareas para realizar la extracción de datos y migración de los servicios actuales?

Hola!

He creado este checklist, creo que está muy completo, os lo dejo por aquí: https://github.com/python-spain/asociacion/issues/149

¿Qué más falta?

¿Se me pasa algo? ¿Tenemos un servidor de Discord también?

alexgmin commented 1 year ago

No existen servidores propios de Discord, todo lo hostea la la empresa Discord.

sincorchetes commented 1 year ago

Ah vale como lo había leído en el comentario.

dukebody commented 1 year ago

Perdón, me lío a veces como todo el mundo entre Discord y Discourse. No tienen nada que ver :)

El mié., 16 ago. 2023 12:42, Álvaro Castillo @.***> escribió:

Ah vale como lo había leído en el comentario.

— Reply to this email directly, view it on GitHub https://github.com/python-spain/asociacion/issues/146#issuecomment-1680371915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAKHYLTIQYCAXTHKDTP33LXVSP2DANCNFSM57DF77XQ . You are receiving this because you were mentioned.Message ID: @.***>

aalmiramolla commented 1 year ago

Ya se han creado las tareas como ha recomendado @dukebody, doy por cerrado este issue, ya que no hay nada que estandarizar como dijo @dukebody:

Con esto, la única infra administrada que quedaría propia serían el registro de dominios y el DNS, con CDMon.