search

Pybonacci / pybonacci.github.io

Blog sobre Python científico en español
https://www.pybonacci.org
Other
9 stars 11 forks source link

Automatizar infraestructura #21

Closed astrojuanlu closed 1 year ago

astrojuanlu commented 7 years ago

Ahora mismo pybonacci.org corre en los servidores de @kikocorreoso, por tanto el bus factor de Pybonacci es 1. Una de las medidas para incrementarlo sería que fuese fácil desplegar el blog en otro sitio en caso de que Kiko no pueda, no le dé la gana seguir haciéndolo o se caiga un servidor por el motivo que sea.

Ayer pregunté en un canal de DevOps y me confirmaron que podríamos usar Ansible para automatizar la configuración del servidor. También se podría usar Docker, hay algo de solape:

La configuración debería incluir:

Como veis se puede ir complicando incrementalmente.

Aquí algunos tutoriales en castellano:

Lo primero que necesitaría @kikocorreoso es que describieras un poco el setup que tienes ahora. Si no me equivoco son VPS en WebFaction, ¿verdad? ¿Qué configuración estás usando para WordPress? (Por si podemos reusar algo). ¿Qué precio tienen? ¿Algún otro detalle interesante?

Esta me la asigno yo, de momento :wink:

kikocorreoso commented 7 years ago

webfaction no son VPS, según su web lo definen así:

Hosting for developers, $10/month, 100GB SSD storage, 1GB RAM, 1TB bandwidth. Servers configured, secured, backed up and monitored for you

Es decir, yo no instalo dockers, ni linux, ni tengo que actualizar librerías de sistema, ni me tengo que encargar de asegurar la máquina,...

Ahora mismo, pybonacci corre con Apache. Nunca he perdido mucho tiempo en mirar alternativas. Otras cosas python que tengo ahí corren con Apache también.

Si se opta por otra opción no tengo el más mínimo problema en investigarlo. Me suena que se pueden configurar cosas para que cuando llegue un PR se actualice solo y eso soluciona el blog en sí pero para temas de mantenimiento, instalar cosas, etc, tendría que entrar yo y el Bus Factor es 1, efectivamente.

La opción de tener algo dedicado solo a pybonacci quizá es demasiado siendo un blog estático. Se podría mantener como está a día de hoy e ir viendo en el futuro las necesidades reales basadas en la experiencia que vayamos teniendo.

Opinad!!!

Pros a mantenernos como estamos:

Cons:

astrojuanlu commented 7 years ago

webfaction no son VPS

Gracias por la aclaración, creía recordar lo contrario. Tienen hosting compartido y dedicado, pero no VPS. Ese es el tipo de cosas que quería saber :)

No hay problema en mantenernos en WebFaction, al menos por ahora. La ventaja es que gestionan los servidores por nosotros, como ya has dicho.

Por otro lado, que estemos en WebFaction no invalida lo que he dicho antes:

http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html#webfaction

astrojuanlu commented 7 years ago

Más documentación https://github.com/quentinsf/ansible-webfaction/blob/master/README.md

manugarri commented 7 years ago

estuve leyendo un articulo hace poco sobre como desplegar una web estatica de forma "gratuita" en CloudFlare https://fillmem.com/post/fast-secured-and-free-static-site/

En el ejemplo usan Hugo, pero se podria adaptar a Pelican.

astrojuanlu commented 7 years ago

Gracias @manugarri, pero @kikocorreoso pidió desplegar en un servidor propio: https://github.com/Pybonacci/pybonacci.github.io-source/issues/16#issuecomment-332107604 si no, yo ya sé cómo usar GitHub pages (https://github.com/poliastro/poliastro.github.io/)

manugarri commented 7 years ago

hmm ok, entonces no sé la verdad. yo mi blog lo tengo en digital ocean que son 5 pavos/mes. En cuanto a bus factor, si queremos gestionarlo todo nosotros y a la vez reducir el bus factor se me ocurren dos formas:

1.) Crear un pipeline separado que automatice el test, build etc. Esto me parece overkill.

2.) Añadir las claves publicas de los administradores y orquestrar nosotros. Esto es muy simple, y reduce el bus factor, con el incremento de riesgo (algun admin que no sepa lo que hace y pete el servidor). Inicialmente podemos hacerlo a mano (ssh y correr código) pero para esta opcion lo suyo seria como decís un ansible para que no tengamos snowflake servers, sino phoenix (que sean recreables. al 100% en caso de necesidad).

3.) Un ansible vault encriptado (y por tanto disponible en github por ejemplo) que despliegue un conjunto de containers. Esto lo bueno que tiene es que es relativamente similar a 2), pero mas facil de gestionar.

astrojuanlu commented 7 years ago

1) Pipeline separado: no sé qué quieres decir, yo pienso que toda la publicación, test, build etc puede estar aquí en GitHub y luego hacer push a donde sea.

2) Creo que es lo que yo tengo en mente

3) Ansible Vaults:

New in Ansible 1.5, “Vault” is a feature of ansible that allows keeping sensitive data such as passwords or keys in encrypted files, rather than as plaintext in your playbooks or roles. These vault files can then be distributed or placed in source control.

Respecto a los containers: a lo mejor no van a hacer falta para lo que queremos hacer en principio: un Apache que sirva contenido estático. Aunque si complicamos la web, puede ser interesante.

@manugarri veo que sabes más que yo del tema, ¿lo miramos entre todos?

manugarri commented 7 years ago

@Juanlu001 Un pipeline muy muy sencillo seria.

[Trabajo Previo]

[Pipeline]

astrojuanlu commented 7 years ago

~@kikocorreoso~ @manugarri me parece todo bien pero los últimos pasos los haría automáticos, dejando que Travis CI desplegase a tu servidor directamente, sin necesidad de bajarnos en contenido y hacer todo el rollo. Lo que queremos es trabajar lo menos posible :)

Es como lo hacemos en la web de Python España:

https://github.com/Pybonacci/pybonacci.github.io-source/issues/16#issuecomment-332126961

Incluso lo genial sería que el contenido se viese en algún lado sin necesidad de generarlo. O sea, que el pull request desplegase a testing.pybonacci.org o algo así. Así puedo aprobar artículos con el móvil tumbado en la cama.

astrojuanlu commented 7 years ago

Perdón, el comentario iba para @manugarri.

manugarri commented 7 years ago

Si claro @Juanlu001 , se puede automatizar todo. Lo decía por hacerlo lo más simple posible. Si es posible podemos usar el repo de Python España y replicarlo.

manugarri commented 7 years ago

como quedamos con esto @Juanlu001 ? Voy a estar más o menos desconectado y queria ver si necesitais ayuda,

manugarri commented 6 years ago

@Pybonacci/administradores @Pybonacci/editores esta task en mi opinion es la que tiene una prioridad mas alta. Hasta que no despleguemos está versión del blog, todo el desarrollo va a estar un poco parado (falta de pruebas y de motivación).

astrojuanlu commented 6 years ago

Ahora mismo esto Pybonacci corre en GitHub pages, por lo que no hace falta automatizar nada salvo que queramos desplegar en nuestro servidor. Lo quito del milestone 3.1, ya no es urgente.

manugarri commented 6 years ago

totalmente de acuerdo, creo que mientras seamos los que somos no hay problema si alguien se encarga de ejecutar el deploy desde su maquina

astrojuanlu commented 6 years ago

Ahora el deploy se hace solo, ya está automatizado :)

astrojuanlu commented 1 year ago

Creo que esto está desfasadísimo, lo cierro salvo que alguien opine lo contrario.

manugarri commented 1 year ago

echo de menos pybonacci :(

kikocorreoso commented 1 year ago

Sigue abierto.

Cualquiera que quiera acceso que lo diga.

Por mi parte, no tengo nada de tiempo últimamente...