¿Cuál es un buen enfoque de DevOps para un único desarrollador que escribe aplicaciones web de Python?

Supongo que esta pregunta parecerá increíblemente trivial para algunos lectores, pero como alguien que es desarrollador pero con poca experiencia en la implementación de aplicaciones en otra cosa que no sea un manual, golpear y esperar de alguna manera, espero que entiendan que es bastante desalentador ver la cantidad de enfoques y herramientas diferentes que existen, por lo que podría hacer un pequeño consejo para comenzar en la dirección correcta.

Soy desarrollador, ahora solo en mi tiempo libre, que es limitado. Hasta ahora he trabajado con Java, creando aplicaciones web, y he estado razonablemente contento con la implementación de un archivo war en un entorno Tomcat que mantiene las cosas bien encapsuladas.

Ahora estoy trabajando en Python y Django, pero a medida que me acerco al punto donde necesito implementar, quiero configurar un flujo de trabajo devops sólido para automatizar todo lo que pueda y asegurarme de que pueda implementar de manera confiable, pero dado que mi el caso de uso es relativamente simple, quiero evitar aprender un conjunto de herramientas grande y gordo que está diseñado en exceso para mis necesidades y que requiere una gran inversión de tiempo. Preferiría usar la codificación de mi aplicación.

Por lo tanto, estoy buscando un término medio que me permita implementar y administrar mis aplicaciones de manera confiable sin invertir una gran cantidad de tiempo en configurar y aprender un gran ecosistema de DevOps.

Algunos detalles más ...

Contexto

1. Desarrollo en una Mac, usando PyCharm para construir Django 2, Python 3.
2. Uso git (pero no en github) para administrar el control de versiones del software.
3. Me siento cómodo con otros idiomas y lenguajes de scripting y he escrito algunos scripts de bash (probablemente bastante aficionados), aunque no disfruto bash. También he incursionado con Perl, que me di cuenta de que no es realmente un lenguaje para incursionar (es decir, debes pasar tiempo aprendiéndolo correctamente)
4. Tengo la intención de implementar en un entorno VPS, probablemente DigitalOcean.
5. Mi aplicación no es crítica para la misión, pero es importante que sepa si el sitio deja de funcionar, y necesito tener una forma de recuperación confiable si lo hace, ya sea reiniciando la aplicación, reiniciando el servidor o moviéndome a otro servidor ( u otro).

Requisitos específicos

1. Posibilidad de configurar un nuevo entorno para recibir la aplicación.

   Hasta ahora, mientras estoy aprendiendo, esto ha sido manual, y cada vez que lo hice, comencé desde cero con una nueva Droplet. Me gustaría que esto sea mucho más simple (automatizado) para que si tengo que configurar un nuevo entorno en caso de emergencia, pueda hacerlo de manera confiable.

2. Capacidad para implementar la aplicación en un entorno de preparación que sea lo más idéntico a la vida posible, idealmente como un proceso automatizado desencadenado por un impulso de git utilizando un enfoque de integración continua (que nunca he hecho antes).

3. Posibilidad de "presionar el botón" cuando estoy satisfecho con la aplicación en el entorno de preparación para impulsar automáticamente a un entorno en vivo.

4. Manera de monitorear el sitio (solo una encuesta a una página servirá)

5. Manera de cambiar el sitio en vivo a otro servidor si necesito recuperarme de una aplicación o falla del servidor en el sitio en vivo. ¿Creo que un enfoque azul-verde podría funcionar para mí?

¿Qué he intentado o considerado?

• Configuración manual del entorno en vivo con la aplicación Django, luego copie manualmente la nueva base de código cuando haya un cambio. Esto parece propenso a errores humanos y me temo que cometer un error en un despliegue provocando una falla irrecuperable.

• Estibador. Admito que cuando me enteré de Docker parecía un sueño hecho realidad, pero después de un poco de experimentación e investigación, me siento intimidado por lo mucho que necesito aprender y saber para poner esto en marcha y administrarlo. Puede ser que esto valga la pena porque una vez que está funcionando es de muy bajo riesgo, pero en este momento se siente como una mayor inversión de mi tiempo de lo que esperaba.

• Bash scripts. Úselos para configurar el entorno original y para tareas específicas como actualizar la aplicación. Mi preocupación acerca de esto es que los scripts serán código que necesita pruebas y me temo que tomaría mucho tiempo construir un conjunto de herramientas confiable de esta manera.

• He examinado las opciones de Digital Ocean para las direcciones IP flotantes y la capacidad de tener dos servidores para un enfoque "azul verde" que parece bastante sensato. Si sigo esta ruta, todavía necesito poder automatizar la implementación.

Entonces ... estoy buscando consejos sobre un enfoque de DevOps que encuentre el equilibrio adecuado entre minimizar el riesgo (por ejemplo, el riesgo de romper la aplicación en vivo con una actualización o el riesgo de no poder recuperarse de una falla) y minimizar el tiempo inversión que necesito hacer para configurar los entornos y el flujo de trabajo.

No estoy familiarizado con el desarrollo de Python ni con DigitalOcean, así que solo ofreceré algunos consejos:

• El objetivo es automatizar. Todo. Cómo lograrlo depende realmente de usted, y crear sus propias herramientas no es descabellado, muchos lo hacen de esa manera. Una fruta colgante concreta y bastante baja (ish) es obtener un gancho git posterior a la recepción que implemente y reinicie su entorno de prueba. Si tienes eso, el resto debería ser simple.
• "Mi preocupación acerca de esto es que los scripts serán código que necesita pruebas", esa preocupación es infundada. Usted está probando a los guiones cada vez que se implementa en el entorno de prueba, después de todo. Especialmente junto con un enfoque azul-verde, estará bien tener scripts de bash.
• "No me gusta la fiesta". - luego encuentre otro lenguaje de script que disfrute. ¿Quizás probar Ruby? El lenguaje y las bibliotecas principales están muy limpias y bien documentadas, y diría que son bastante fáciles de aprender. O, solo por diversión, Go (lang), que parece ser adecuado para tareas de herramientas de DevOps. Y finalmente, como parece que le gusta Python, ciertamente también puede hacer tareas de instalación con eso. A partir de estos, Go tiene la ventaja de que crea binarios independientes y no necesita un entorno complejo instalado primero, por lo que el arranque puede ser más fácil.
• "un entorno de ensayo que sea lo más idéntico posible al live": si tiene un script que hace girar un entorno desde cero, es decir, desde una imagen base más o menos vacía, sus entornos serán idénticos, salvo los deltas codificados en tu guion Ese es el punto de todo esto.
• "Forma de cambiar el sitio en vivo a otro servidor": lo único que debe reflexionar es qué sucede con sus datos persistentes. Es decir, querrá hacerlo para poder vincular sus aplicaciones con diferentes volúmenes / tiendas persistentes sobre la marcha, para poder cambiar de un lado a otro.
• "Docker - intimidado" - para ser honesto, no debería ser tan malo. Si sabe cómo crear un entorno desde cero con herramientas de línea de comandos (sin herramientas GUI), colocarlas en un Dockerfile debería ser bastante fácil. Los detalles preocupantes aparecen cuando es hora de sintonizar (es decir, reducir el tamaño de las imágenes), pero aparte de eso, no debería ser tan malo. Primero haga que funcione de alguna manera , luego descubra cómo hacerlo hermoso. Lo bueno es que el conocimiento que obtenga se transferirá a muchos otros entornos.

¡Buena suerte!

Gracias por la gran pregunta. Nada es realmente trivial la primera vez que lo haces y todos fuimos nuevos en algo una vez.

Mi primera recomendación es volver a visitar la ventana acoplable. Pruebe algunas guías y tutoriales diferentes. Es muy simple Tiene un archivo acoplable que se "construye", literalmente solo los comandos que desea ejecutar en el "contenedor" o "imagen". Empujas esa imagen a un registro que puede ser público o privado. Luego ejecuta esa imagen en una máquina host. Docker es realmente importante con node.js y python, donde tienes muchas dependencias y a veces puede ser muy difícil administrarlas. Si está utilizando pip, y debería hacerlo, puede generar un requirements.txtarchivo para alimentar a su contenedor acoplable.

Ahora dijiste que estás usando git, así que usaría ganchos locales de git. Puede usarlos para construir el contenedor acoplable, ejecutar pruebas automatizadas y luego implementar su contenedor. Puede buscar muchas guías y tutoriales diferentes sobre este tema.

Para administrar su infraestructura, usaría Terraform. Terraform es excelente porque puede activar un entorno a pedido y eliminarlo cuando haya terminado. Mi recomendación sería comenzar de forma simple y una vez que domine la plataforma acoplable y la terraforma, puede probar las implementaciones azules / verdes.

Ahora, si está utilizando Gitlab o está dispuesto a cambiar, también ofrece un servicio ci / cd gratuito. Esto incluye muchas funciones interesantes y es realmente fácil de usar. Lo uso personalmente para todas mis aplicaciones. Puede omitir por completo los ganchos locales de git y probarlos en la tubería de gitlab o conservarlos para probar cada confirmación localmente y usar gitlab para construir y desplegar.

Espero que esto haya sido de alguna ayuda.

Las respuestas publicadas han sido muy útiles para permitirme repensar mi problema y varios enfoques. Todavía no he implementado una solución, pero he decidido un enfoque, así que lo estoy documentando y seleccionándolo como la respuesta. En resumen es esto:

Mi enfoque elegido

• Para el entorno en vivo, usaré dos máquinas virtuales (probablemente usando gotitas de DigitalOcean) que ejecuten Ubuntu y estén configuradas exactamente igual.
• Emplearé un enfoque azul-verde usando la instalación de IP flotante dentro de DO para mantener mis dos servidores idénticos como Live y Pre-Prod / Backup.
• Crearé una VM (probablemente usando VirtualBox) en mi configuración de desarrollo para usarla como entorno de preparación. Esta VM se configurará exactamente igual que mis dos servidores en vivo.
• Escribiré un único script común en Python para configurar un entorno desde cero y lo usaré para configurar mi entorno de preparación y mi par en vivo / pre-prod.
• Emplearé git hooks para activar actualizaciones en los entornos (probablemente activadas manualmente).

Consideraciones que impulsaron este enfoque

• Docker: he decidido no hacerlo. Aunque tomo en serio las respuestas (gracias @Levi y @Dan) que dicen que debería volver a visitar y que no debería ser tan malo, he tenido demasiadas experiencias en el pasado de embarcarme en algo nuevo y darme cuenta de que me he caído. por una madriguera de conejo que consume tiempo y toma una edad para ponerse en marcha. Creo que sería diferente si incluso estuviera trabajando con otra persona, pero como alguien que trabaja completamente solo cada minuto es precioso.

• Máquinas virtuales: Realmente no había considerado esto hasta que comencé a trabajar con algunos de los tutoriales de Docker que usan máquinas virtuales para demostrar la funcionalidad de Swarm. La idea de poder crear un entorno completamente nuevo sobre el que tengo control total es muy atractiva.

• Scripting: debido a la útil respuesta de @ AnoE, he cavado un poco más y parece que Python es reconocida como una opción viable para scripting y, como eso es lo que estoy escribiendo, mi aplicación parece que debería haber alguna sinergia (si es necesario para aprender algo nuevo para mi script, será el conocimiento que pueda usar para escribir mi aplicación)

Actualizaré una vez que haya progresado con esto y si sale terriblemente mal, ¡reconoceré que tal vez hice la elección incorrecta!).

Actualización el 20 de octubre de 2018.

Me propuse escribir un script de Python, pero esto a menudo implicaba invocar un comando bash de Python y luego recuperar la respuesta y descubrí que esto se agregaba mucho al tiempo de desarrollo. Después de un par de semanas de lento progreso, busqué en otro lado. Admito que podría haberme enfocado mal pero necesitaba algo que fuera más rápido.

Finalmente me decidí por Vagrant / Ansible / VirtualBox y después de más meses de lo que me gustaría admitir obtuve algo que funcionó bien, pero después de mucho trabajo aprendí algunas nuevas habilidades (Vagrant y Ansible eran completamente nuevas para mí). Luego apliqué el script Ansible para aprovisionar un DigitalOcean Droplet y descubrí que esto funcionó muy bien. Me he hecho fanático de Ansible, pero aunque estoy de acuerdo (con los revisores) en que es relativamente fácil de usar, sigue siendo un nuevo paradigma y una curva de aprendizaje bastante pronunciada.

Al momento de escribir, he provisto dos Droplets separados en DigitalOcean en una configuración azul-verde, usando direcciones IP flotantes DO para cambiar entre los dos, y en cada uno la aplicación está dentro de una copia de trabajo git, así que solo necesito actualizar el Maestro para actualizar un entorno.

Tengo un problema para hacer que las IP flotantes funcionen como esperaba, pero espero resolverlo pronto y luego tendré un entorno DevOps que funcione.

La gran ventaja de este enfoque es que la forma en que funciona Ansible, una vez que tienes algo funcionando, es relativamente fácil hacerlo funcionar en un entorno diferente y esto puede no ser tan fácil de lograr con un script de Python (o al menos tienes que construir esto en lo que es trabajo extra).

Creo que la gran lección es que las cosas tardan más de lo que espero y aprender una nueva tecnología siempre trae incógnitas desconocidas. Esto no debería ser una sorpresa para mí, pero siempre lo es y trabajando como desarrollador solitario, esto me sucede mucho.