Infraestructura informática de Python España

Asociación GT Infraestructura
1

A raíz de las discusiones de https://comunidad.es.python.org/t/publicacion-fotos-pycones-2019/206/6.

@yami ¿Es posible escribir un documento (aunque sea privado en principio) sobre cómo está montada la infraestructura informática de Python España? Entiendo que hay varios servidores donde tenemos varias cosas alojadas, entre ellas la web de Python España y las webs de las diferentes ediciones de PyConES.

Cosas que veo interesantes:

  • Máquinas virtuales que tenemos y qué hay en cada una de ellas.
  • Configuración de backups.
  • Configuración de docker en las que esté así.
  • Configuración de los correos @es.python.org. Tengo entendido que hay algunos problemas con correos que llegan a spam.
  • Configuración de los DNS.
  • Quién tiene acceso a cambiar la configuración o contenidos de lo anterior.

¡Felices fiestas!

1 me gusta
2

buenas, perdón por el silencio administrativo; lo tengo pendiente, y lo tengo previsto para estos días. felices fiestas.

3

Buenas!

por fin saco un rato para explicar esto; no sé si debería ir en un wiki o dónde, así que pongo aquí el contenido (actualizado a día 2.enero.2020) y lo recolocáis donde consideréis.

Lo primero que quiero aclarar es que no tengo control / acceso a toda la infraestructura; así que puedo hablar en detalle de la parte que sí controlo y dar algunos punteros para el resto. Dicho lo cual, voy contestando:

  1. Máquinas virtuales que tenemos y qué hay en cada una de ellas.
    Tenemos 2 máquinas virtuales en scaleway:

  • python-es: donde sólo se despliegan proyectos dockerizados o sitios estáticos; en esta máquina no se puede instalar postgrs ni nada susceptible de dar problemas de versionado, por eso los dockers. Cuando algún evento necesita alojamiento, algún admin (típicamente yo, aunque ojalá el bus factor fuera >1)

    • les da un puerto no privilegiado que será el que exponga su docker (toda su aplicación debe salir a través de ese puerto, normalmente usando un nginx)
    • les configura una entrada en el caddyfile redirigiendo todo el tráfico del dominio x al puerto acordado

    En esta máquina están las webs de la asociación (socios, web, blog), y las webs de los eventos (pydays y pycones que lo solicitan). Las webs dockerizadas deberían usar docker-compose y persistir los volúmenes de la bbdd.

  • ye-olde-pythones: es una máquina con cosas viejunas, como la web de pycones2013 que no está dockerizada por ejemplo y cositas así. Deberíamos recuperar lo que queramos mantener (adaptarlo a un sistema normalizado) y darle fuego pues es un gasto innecesario de recursos.

  1. Configuración de backups.
    (me escondo detrás de una piedra). Vamos con esto: no hay backups. Al menos yo no he montado nunca un sistema de backups; no le he podido dedicar tanto tiempo a esta infra. Si alguien (¿tal vez @marcos ?) la montó, no soy consciente.

  2. Configuración de docker en las que esté así.
    No entiendo bien esta pregunta. A la hora de desplegar, en la máquina se clona el repositorio, se generan 1-n imágenes de docker y se lanzan. Alguien que lo montase bien habría automatizado esto con travis mismamente. No entro a tanto detalle de los despliegues, cuando hay una nueva web, autorizo la clave pública de quien se vaya a encargar.

  3. Configuración de los correos @es.python.org. Tengo entendido que hay algunos problemas con correos que llegan a spam.
    El correo lo gestiona íntegramente Jesús Cea.

  4. Configuración de los DNS.
    El DNS lo gestiona íntegramente Jesús Cea.

  5. Quién tiene acceso a cambiar la configuración o contenidos de lo anterior.
    Yo, por descontado; también Marcos hace de administrador de la máquina. Además damos acceso no privilegiado a quienes despliegan la web de pycones.

  6. Alguna pycones (por ejemplo la de 2019) se desplegó en una máquina fuera de esta infraestructura y que está controlada por @aaloy ya que APSL se encargó de ella.

  7. No sé lo que no sé. Tal vez haya otros recursos que ni sé que existen… Este puede ser un buen hilo donde comentar otros recursos de infra que tengamos como asociación al margen de esto que he contado.

Este sistema dista mucho de estar bien, así que no tengo ningún inconveniente en que se cambie; el problema es el tiempo que le pueda dedicar yo misma. Este año me había propuesto algunos cambios importantes para la infra de Python España, a saber:

  • migrar las máquinas antedichas a una cuenta en Scaleway que pertenezca a la asociación. Actualmente está en mi cuenta personal; lo único a lo que no accede nadie salvo yo es a la consola de scaleway; no es una restricción crítica, pero sería mejor que la propia asociación fuera dueña de las máquinas. Esto no quita para que yo pueda seguir siendo benefactora de los costes de la infraestructura si es necesario.
  • procedimentar mejor las acciones que se realizan en la máquina (fundamentalmente despliegues, pero como bien señalas, backups serían necesarios)
  • estaría guay tener un grupo de trabajo de infraestructura donde poder documentar y comentar estas cositas, donde tener más de un admin

Creo que nada más por ahora, espero que hayáis tenido unas felices fiestas y un próspero año. Cualquier cosita, sigo disponible.

1 me gusta
4

¡Gracias por el pedazo resumen @yami!

Hace unos días creé el repo https://github.com/python-spain/wiki/wiki con la idea de ir poniendo las cosas ahí; pero planteo la idea de quizá usar el wiki de GitHub del repo https://github.com/python-spain/asociacion en su lugar. No sé cómo de pública queremos que sea toda esta información; en principio la seguridad no debería ser “by obscurity” pero a saber…

Estoy de acuerdo en que deberíamos migrar las máquinas a una cuenta que pertenezca a la asociación. Mirando un poco no he visto que sea posible mover un servidor, ni siquiera un snapshot, de una cuenta de Scaleway a otra. Pero como todo son imágenes de docker, en principio copiando la configuración debería de ser todo bastante fácil de migrar. Quizá podríamos ponernos como objetivo que la web de PyConES 2020 esté en una nueva máquina propiedad de la asociación, y a partir de ahí ir migrando el resto de contenido antiguo.

Sobre que siguieses siendo la benefactora, entiendo que Python España tiene dinero de sobra para pagar la infraestructura. :slight_smile:

Sobre el grupo de trabajo de infraestructura, estoy súper de acuerdo en que no sea una única persona la que gestiona el tema. Además de que imagino que tú has sido la administradora principal desde tiempos inmemoriales… No sé si merece la pena crear un grupo de trabajo separado del de “web” (en el que ahora mismo informalmente sólo estoy yo) o simplemente juntar la gente que trabaje en la administración de los recursos tecnológicos de Python España (web + foros + infra, etc.). Yo apuesto por lo segundo de momento.

Para el tema backups, he visto que en Scaleway se pueden hacer backups manuales de todo un servidor: https://www.scaleway.com/en/docs/how-to-backup-your-data/ No son backups periódicos automáticos, que es lo que sería ideal, pero al menos tendríamos algo. ¿Puedes crear al menos un backup del estado actual? Después, como el backup se puede crear mediante API, quizá podríamos programar algún tipo de función cron que se encargue de crear backups periódicamente.

Sobre la gestión de los correos @es.python.org y el DNS, intentaré contactar con Jesús Cea para entender mejor si se pueden gestionar de forma comunitaria.

Pregunta: ye-olde-pythones, además de la web de pycones2013, ¿qué más tiene? Por saber cómo de fácil sería migrar lo que tiene y desconectarla.

Sobre la automatización de despliegues, entiendo que por ejemplo la propia web de Python España tiene ya el despliegue automatizado con Travis. Supongo que se puede copiar la forma de despliegue para otros servicios, ¿no?

De nuevo, muchas gracias por el resumen tan currado. A ver si de cara a la asamblea de febrero comenzamos a elaborar un plan de mejora para la infra, empezando por los cambios que sugieres. Podemos buscar aliadas entre la gente que se encarga de la gestión de la infra en las comunidades locales. :smiley:

¡Buen año!

5

¡De nada! Espero que sea un primer paso para seguir mejorando la infra.

  1. Crear una infra de la asociación. Suena genial y sería algo bueno para la asociación, creo. Ir migrando los contenidos poco a poco también estaría bien. Voy a mirar porque igual lo más fácil es que yo deje esta cuenta para la asociación (le cambiamos los datos de contacto, etc) y me llevo mis cosas (que son pocas y en general son mucho más fáciles de mover). Tengo que ver si puedo borrar realmente todos mis datos y volver a dar una cuenta de alta con mi correo

  2. Lo de ser benefactora es un placer, pero sobre todo era lo más operativo cuando no teníamos tarjeta para pagar :sweat_smile: No sé si ahora la asociación lo tiene fácil para gestionar este tipo de pagos (ping @marcos y @astrojuanlu)

  3. Grupo de infraestructura + web. Creo que tiene sentido; no estoy en ningún grupo de trabajo, así que si quieres hacemos que el grupo de web se encargue. Me gustaría seguir involucrada si es posible.

  4. Backups. Done, no sé por qué no lo había hecho hasta ahora, de hecho (ayx).

  5. Acabo de acordarme de una máquina que no mencioné:
    discourse que es la que tiene este discourse que estamos usando. También le he hecho un snapshot.

  6. ye-olde-python-es tiene:

  • pycones2015
  • pycones2016
  1. Otras pycones:
  • pycones2013: He hablado con Jesús Cea y me ha recordado lo que hicimos en su momento. Codigo23.net es una empresa que se ofreció a hospedarla y que aún la mantiene en perfectísimas condiciones. No veo razón para cambiar esto, salvo que la empresa quisiera dejar de dar este soporte porque sea un legacy incómodo; pero nunca han dicho nada así que entiendo que siguen felices apoyando a la comunidad así. Lo que sí deberíamos hacer es documentarlo para nuestros futuros yoes.
  • pycones2014: nunca estuvo en una infraestructura de la que yo tuviera constancia.
  1. No se puede usar el mismo sistema de CI-CD para una web hecha en django con docker (pycones) y para sitios estáticos como la web de python España; en todo caso no es ningún problema, serán un par de pasos más, solo que no es copy&paste.

¡Seguimos!

6

Hola,

A nivel de infraestructura tenemos que añadir una pequeña instancia en AWS que gestiona APSL para las webs de 2019 y 2020. APSL es una empresa y es la que se hace cargo de coste. Con Toni Aloy (gerente de APSL) y conmigo (administro la instancia y los servicios en mi tiempo libre) ambos como socios de la asociación.

A mí me parece mejor que los servicios de la asociación esten unificados en una cuenta de hosting a nombre de la asociación y no tener que depender de benefactores como hasta ahora. No es que sea malo tener los benefactores, se agradece mucho la aportación, pero es más complicado de administrar, más si la gente información va rotando. Creo que el coste anual es poco para los servicios que nosotros tendremos.

Yo puedo aportar en la migración de servicios y tengo algunas ideas como esto:

Para hacer una gestión histórica estática de las webs de años anteriores.
Se sacaría una foto estática de una web y la podemos publicar directamente en bucket s3 por ejemplo o docker simple.

Soy muy pro-aws por simplicidad pero estoy abierto a debatir opciones.

7

@eduherraiz ¡gracias por tu aporte! Se me había pasado el hosting de las dos últimas pycones :see_no_evil:

En mi opinión, en este momento es buena idea unificar la infraestructura y ponerla a nombre de la asociación (1).
Las pycones pasadas se pueden pasar a estático y así calzarnos los djangos viejunos; s3 me gusta pero también significa una nueva cuenta+tarjeta a nombre de la asociación, y para el tráfico que van a tener, mi propuesta es que usemos las mismas instancias de scaleway (por reducir el número de recursos que usamos) sirviendo los estáticos.

(1). Ahora tengo dos cuentas en scaleway

  • la que tenía hasta ahora que ya únicamente contiene cosas de python españa (he borrado mis movidas que se migran fácil)
  • la nueva mía, mía, con mis cosas :stuck_out_tongue:

Es decir, con un número de tarjeta de Python España y un correo, puedo hacer entrega de la infraestructura a la asociación, puedo incluso seguir encargándome yo como hasta ahora pero ya con el permiso de la Asociación; y dando permiso a alguna otra sysadmin a la consola de scaleway.

8

cc @marcos ¿apruebas la moción? :slight_smile: Y lo seguimos por email

9

Apruebo la moción :slight_smile:

1 me gusta
10

A mí me interesa tener acceso a esa cuenta de Scaleway para poder crear recursos!

La web de la pycon de 19 y 20 están en una infraestructura compartida de APSL y no puedo dar acceso a nadie de la asociación así que pondré como tarea futura mover esos servicios a infraestructura de la asociación.

A futuro me gustaría que quedase documentada la gestión y despliegue de las webs dentro del grupo de trabajo de la pycon. Que haya varias personas con conocimiento y acceso al proveedor de infraestructura. Creo que así será más fácil de gestionar para próximos años y no dependa de solo una persona. También el tratamiento histórico de las webs en estático para el futuro sobre esa infraestructura.

Por otro lado, creo que hay que revisar la gestión de otros recursos importantes de la misma manera.

Hablo en este caso del email y DNS.

Se que este tema lo lleva Jesús y no quiero crear discordia, ya le he escrito a él con mi opinión personal pero creo que es reticente.

Creo que hacer que esta gestión de servicios importantes no dependa de solo una persona sería lo más práctico y seguro para la asociación, más cuando Jesús no está en los nuevos canales de trabajo o comunicación.

En lo puramente técnico también creo que podemos darle una vuelta.

En el caso del DNS podemos ir hacia algún servicio gestionado, creo que Scaleway lo tiene aunque no lo he probado, pero suelen servicios muy buenos y muy baratos. El de AWS (Route53) que más controlo es hiper-redundante y sencillo de configurar desde un panel web por ejemplo.

Para el caso del email creo que seria mucho mejor tenerlo también en un servicio gestionado, el servicio actual veo que no tiene webmail y es incomodo de trabajar con él. También me ha llegado que hemos tenido problemas años anteriores por emails enviados nuestros que son rebotados o marcados como SPAM. Esto me parece grave, es nuestra vía de comunicación principal con sponsors por ejemplo. Entiendo la visión romántica de querer tener bajo control de software libre el servicio de email, yo la he compartido mucho tiempo, pero hace años que es un infierno mantener un MTA por culpa de la gestión oscura anti-spam que hacen los receptores de email, no es muy deseable tener que lidiar con eso.

Aquí hay muchas opciones, desde mi preferida de llevarlo a Gmail, o otras que puedo recomendar como Zoho, en APSL movimos todos nuestros clientes pequeños de nuestros servidores de correo antiguos a este servicio, al estar bastante bien y ser más barato que Gsuite.

1 me gusta
11

Gracias por traer cuestiones importantes e interesantes :slight_smile:

Me gustaría saber un poco más sobre esto. Hasta ahora hemos tenido una visión bastante espartana de la infra, y creo que aunque la asociación tenga medios, pondría aquí lo justo, al menos mientras no ofrezcamos recursos que consuman mucho tráfico. Las webs de 2019 y 2020 se pueden migrar a la máquina que existe actualmente para ellas (dockerizada la de 2020 y en modo estático si es posible la de 2019). Si me pasas una clave pública te doy acceso de inmediato.

Esto me parece utilísimo, y siendo ambiciosa (aunque no tanto), un pack de PyCon con instrucciones, retro-planning básico, presupuestos, patrocinadores…

Estoy de acuerdo con la premisa; aunque es cierto que en este caso en particular, Jesús siempre responde con muchísima diligencia y el DNS funciona estupendamente. Es una labor que lleva él con ganas y profesionalidad por lo que yo he podido ver en este tiempo.

Desde el punto de vista técnico, me gustaría preguntar qué problemas técnicos le ves al DNS actual para querer cambiar.

Lo cierto es que el email actualmente está funcionando mal; aunque tiene poco o poquísimo uso, es nuestro canal oficial y entre el spam y la moderación los correos llegan tarde y/o mal. Estaría muy bien poder mejorar el servicio de email.

No diría que es una visión romántica; es menos pragmática, qué duda cabe, pero es más libre y apoyar el software libre tiene también estas cosas. No vale apoyarlo solo cuando va estupendamente. Estoy 100% en que el servicio debería mejorar, pero no me gustaría que el punto de partida fuera menoscabar el software libre como si fuera cosa de románticos nostálgicos del pasado. A día de hoy el software libre es una apuesta éticamente importante. Antes de Python 2.7 hubo un Python 1.1 :slight_smile:

12

Muchas gracias por tus comentarios!

Sobre la creación de recursos nuevos en Scaleway. Si ya tenemos una instancia de computación estoy de acuerdo que es mejor no crear otra, y podemos poner la web de 2020 y 2019 con docker ahí. Pero sí que creo mejor que la base de datos este separada en el servicio gestionado que proporciona scaleway, por poder activar el backup suyo y no tener el servicio postgres en una imagen docker. Son como 8 dolares al mes ¿qué opináis? Te paso mi clave pública por email.

Para el DNS no veo inconvenientes técnicos, insisto que solo que me parece malo que dependa de una sola persona.
No dudo de la diligencia de Jesús, me parece genial su labor y trabajo, pero creo que tener este servicio en un proveedor y que podamos hacer los cambios desde un panel web con acceso de varias personas siempre será mejor. Posibilitará documentar el acceso, como hacer el cambio y que el grupo de trabajo sea autónomo en la gestión del servicio. Y sobretodo en el traspaso de esta operativa a otros socios responsables futuros que se vayan a hacer cargo de su gestión. Evidentemente soy consciente que esto solo se modifica una vez al año y no es crítico, pero bueno, es mi visión de ideal del asunto!

Por favor, no saques de contexto mi comentario sobre el software libre, soy partidario de él y por supuesto valoro cualquier opción primera con una gestión de software libre. Mi comentario está relacionado en exclusiva con la gestión del servicio de envío de email.
Lo que quería hacer ver es muy diferente!
Yo se que para el control del servicio de email hay mucho software libre y muy robusto, pero no es un problema del software que tu utilices si no de la gestión que lleva tener un servicio que envia correo. Está a la orden del día tener que lidiar con proveedores que bloquean tu IP, que te incluyen en listas negras o deniegan tus correos por razones muy variopintas. La gestión humana que lleva monitorizar y gestionar todo eso hace que sea mejor no utilizar un software propio para gestionarlo, sino pasar por un proveedor que ya tenga recursos dedicados para solucionar esos problemas. Por eso digo que entiendo el apego al software libre para gestionar el mail, yo lo he vivido, pero ahora no me parece la opción más sana.
También está el tema de poder tener un webmail, que sería una mejora sustancial para los que gestionan los buzones de correo.

13

De hecho el correo de anuncio del PyCamp me llegó a SPAM, cc @humitos

14

buenas! están siendo semanas de mucho curro, pero voy sacando raticos para esta conversación:

Ya te autoricé en la máquina ¿Todo ok?

Totalmente de acuerdo.

100% de acuerdo también en que estamos ante una tarea que requiere mucho esfuerzo, tiempo y gestión para que funcoine bien; te agradezco la aclaración porque había entendido otra cosa y ahora me queda clara tu postura.

15

Hola @yami

Gracias! En cuanto pueda revisaré el acceso!

Desde el grupo de trabajo de la pycones estamos muy preocupados con el tema mailing y he propuesto mover los buzones creados de contact@2020.es.pycon.org y sponsor@2020.es.pycon.org al servicio Zoho que os comentaba. Nos puede servir como primera prueba del servicio de mail externo y ya veremos que hacemos con los buzones de la asociación.

16

¡Hola @eduherraiz! Hoy tenemos reunión de Junta y uno de los temas prioritarios es tomar decisiones respecto a qué hacer con el mail. Tendremos nueva info en breve. Gracias por llamar la atención sobre este problema. :slight_smile:

17

Buenas, aunque a lo mejor debería abrir otro hilo para esto, creo que el contexto será muy útil.

En la última JD decidimos que el correo y el DNS no deberían estar en manos de una persona únicamente, y debería tener a alguien del grupo de trabajo de infra.

Vamos a lanzar varias tareas en paralelo (migración, comunicación, etc) pero quisiera aprovechar este hilo para reunir distintas propuestas para la gestión de email y DNS.

No hablamos del correo de Pycones únicamente, sino de toda la asociación. En su momento se mencionaron varias alternativas pero en el contexto de Pycones. Hay distintas alternativas (self-hosted, externalizado) con pros y contras y creo que sería bueno una “tabla” comparativa. La decisión no está tomada, así que estamos abiertas a soluciones diversas.

Dejo aquí abierto el hilo, y a ver si yo misma también saco un rato para buscar opciones además de las más famosas. ¡Salud!

1 me gusta
18

¡Hola!

Dejo aquí algunas ideas de posibles opciones que he mirado, aunque puede haber muchas más.

Mail:

DNS. Hay que tener en cuenta que tiene que permitir gestionar registros DNS de dominios no registrados con ellos, ya que lo que ocurre es que python.org delegará cualquier resolución de es.python.org a los servidores DNS que digamos (p.ej. Gandi creo que no vale):

¿Más?

1 me gusta
19

Me permito añadir https://disroot.org/

20

Personalmente de servicio de email me gusta gsuite, aunque en APSL nuestra alternativa es zoho para buzones pequeños.
Dado que ya tenemos algunos ficheros compartidos en Drive , ese otro servicio sería aprovechable.

Para el DNS me gusta Route53 de aws, pero creo que cualquiera de los que menciona @dukebody puede funcionar.

Puedo participar en la migración de estos servicios sea cual sea el que se decida.