Quelle est la bonne approche Devops pour un seul développeur qui écrit des applications Web en python?

Je suppose que cette question semblera incroyablement triviale pour certains lecteurs, mais en tant que développeur mais avec peu d'expérience dans le déploiement d'applications dans autre chose qu'un manuel, appuyez et espérez en quelque sorte, j'espère que vous comprendrez que c'est assez intimidant de voir le nombre d'approches et d'outils différents, je pourrais donc faire avec quelques conseils pour me lancer dans la bonne direction.

Je suis développeur, maintenant seulement dans mon temps libre, ce qui est limité. Jusqu'à présent, j'ai travaillé avec Java, créé des applications Web et j'ai été raisonnablement satisfait du déploiement d'un fichier de guerre dans un environnement Tomcat qui maintient les choses bien encapsulées.

Je travaille maintenant en Python et Django, mais à mesure que je me rapproche du point où je dois déployer, je veux mettre en place un workflow de devops solide pour automatiser autant que possible et m'assurer de pouvoir déployer de manière fiable, mais étant donné que mon le cas d'utilisation est relativement simple, je veux éviter d'apprendre un gros ensemble d'outils gras qui est trop conçu pour mes besoins et qui nécessite un gros investissement de temps, je préfère utiliser le codage de mon application.

Je suis donc à la recherche d'un terrain d'entente qui me permet de déployer et de gérer mes applications de manière fiable sans investir beaucoup de temps à configurer et à apprendre un écosystème de gros devops.

Quelques détails supplémentaires ...

Le contexte

1. Je développe sur un Mac, en utilisant PyCharm pour construire Django 2, Python 3.
2. J'utilise git (mais pas sur github) pour gérer la gestion des versions des logiciels.
3. Je suis à l'aise avec d'autres langages et langages de script et j'ai écrit quelques scripts bash (probablement assez amateur), bien que je n'aime pas bash. J'ai également essayé Perl, dont je me suis rendu compte que ce n'est pas vraiment un langage pour barboter (c'est-à-dire que vous devez passer du temps à l'apprendre correctement)
4. J'ai l'intention de déployer sur un environnement VPS, probablement DigitalOcean.
5. Mon application n'est pas essentielle à la mission, mais il est important que je sache si le site tombe en panne et que je dois avoir un moyen de récupérer de manière fiable si c'est le cas, qu'il s'agisse de redémarrer l'application, de redémarrer le serveur ou de passer à un autre serveur ( ou autre).

Exigences particulières

1. Possibilité de configurer un nouvel environnement pour recevoir l'application.

   Jusqu'à présent, pendant que j'apprends, cela a été manuel, et chaque fois que je l'ai fait, j'ai recommencé à zéro avec une nouvelle Droplet. Je voudrais que ce soit beaucoup plus simple (automatisé) afin que si je dois configurer un nouvel environnement en cas d'urgence, je puisse le faire de manière fiable.

2. Possibilité de déployer l'application dans un environnement de mise en scène aussi identique que possible au live, idéalement comme un processus automatisé déclenché par un push git utilisant une approche d'intégration continue (ce que je n'ai jamais fait auparavant).

3. Capacité à "appuyer sur le bouton" lorsque je suis satisfait de l'application dans l'environnement de mise en scène pour passer automatiquement à un environnement en direct.

4. Manière de surveiller le site (juste un sondage sur une page fera l'affaire)

5. Moyen de basculer le site en direct vers un autre serveur si j'ai besoin de récupérer après une panne d'application ou de serveur sur le site en direct. Je pense que peut-être une approche bleu-vert fonctionnerait pour moi?

Qu'est-ce que j'ai essayé ou envisagé?

• Configuration manuelle de l'environnement en direct avec l'application Django, puis copiez-y manuellement la nouvelle base de code en cas de changement. Cela semble sujet aux erreurs humaines et je crains de faire une erreur dans un déploiement provoquant une défaillance irrécupérable.

• Docker. J'avoue que lorsque j'ai découvert Docker, cela semblait être un rêve devenu réalité, mais après un peu d'expérimentation et de recherche, je suis intimidé par tout ce que j'ai besoin d'apprendre et de savoir pour le mettre en place et le gérer. Il se peut que cela en vaille la peine, car une fois que cela fonctionne, le risque est très faible, mais pour le moment, cela me semble être un investissement de mon temps plus important que ce que j'espère.

• Bash scripts. Utilisez-les pour configurer l'environnement d'origine et pour des tâches spécifiques telles que la mise à jour de l'application. Mon inquiétude à ce sujet est que les scripts seront du code qui doit être testé et je crains que cela prenne beaucoup de temps pour créer un ensemble d'outils fiable de cette façon.

• J'ai examiné les options de Digital Ocean pour les adresses IP flottantes et la possibilité d'avoir deux serveurs pour une approche "bleu vert" qui semble tout à fait sensée. Si je choisis cette voie, j'ai encore besoin d'automatiser le déploiement.

Alors ... je cherche des conseils sur une approche devops qui trouve le bon équilibre entre minimiser les risques (par exemple le risque de casser l'application en direct avec une mise à jour, ou le risque de ne pas pouvoir récupérer d'une panne) et de minimiser le temps investissement que je dois faire pour configurer les environnements et le flux de travail.

Je ne suis pas familier avec le développement Python ni DigitalOcean, donc je vais juste proposer quelques conseils:

• Le but est d'automatiser. Tout. La façon dont vous réalisez cela dépend vraiment de vous, et la création de votre propre outillage n'est pas farfelue, beaucoup le font de cette façon. Un fruit suspendu concret et assez bas (ish) est de faire fonctionner un crochet post-réception git qui déploie et redémarre votre environnement de test. Si vous avez cela, le reste devrait être simple.
• "Mon inquiétude à ce sujet est que les scripts seront du code qui doit être testé" - cette inquiétude n'est pas fondée. Vous êtes tester ces scripts chaque fois que vous déployez dans votre environnement de test, après tout. Particulièrement couplé à une approche bleu-vert, il sera bien d'avoir des scripts bash.
• "Je n'aime pas bash." - puis trouvez un autre langage de script que vous aimez. Peut-être essayer Ruby? Le langage et les bibliothèques de base sont très propres et bien documentés, et je dirais plutôt faciles à apprendre. Ou, juste pour le plaisir, Go (lang), qui semble bien adapté aux tâches d'outillage devops. Et enfin, comme vous semblez aimer Python, vous pouvez également effectuer des tâches d'installation avec cela. À partir de ceux-ci, Go a l'avantage de créer des binaires autonomes et n'a pas besoin d'un environnement complexe installé en premier, lui-même, donc l'amorçage peut être plus facile.
• "un environnement de mise en scène qui est aussi identique au live que possible" - si vous avez un script qui fait tourner un environnement à partir de zéro, c'est-à-dire à partir d'une image de base plus ou moins vide, alors vos environnements seront identiques, sauf pour les deltas encodés en votre script. C'est le point de tout cela.
• "Manière de basculer le site en direct vers un autre serveur" - la seule chose à méditer est ce qui se passe avec vos données persistantes. C'est-à-dire que vous voudrez faire en sorte que vous puissiez lier vos applications avec différents volumes / magasins persistants à la volée, pour pouvoir basculer d'avant en arrière.
• "Docker - intimidé" - pour être honnête, ça ne devrait pas être si mal. Si vous savez comment créer un environnement à partir de zéro avec des outils de ligne de commande (pas d'outils GUI), alors les placer dans un Dockerfile devrait être plutôt facile. Les détails inquiétants apparaissent quand il est temps de régler (c'est-à-dire de réduire la taille des images), mais à part cela, cela ne devrait pas être trop mauvais. Faites-le d'abord fonctionner d'une manière ou d'une autre , puis découvrez comment le rendre beau. La bonne chose est que les connaissances acquises seront transférées dans de nombreux autres environnements.

Bonne chance!

Merci pour la grande question. Rien n'est vraiment insignifiant la première fois que vous le faites et nous étions tous nouveaux à quelque chose une fois.

Ma première recommandation est de revoir Docker. Essayez différents guides et tutoriels. C'est vraiment simple. Vous avez un fichier docker qui est "construit", littéralement juste les commandes que vous souhaitez exécuter sur le "conteneur" ou "l'image". Vous poussez cette image vers un registre qui peut être public ou privé. Vous exécutez ensuite cette image sur une machine hôte. Docker est vraiment important avec node.js et python où vous avez beaucoup de dépendances et il peut parfois être difficile de les gérer. Si vous utilisez pip, et vous devriez l'être, vous pouvez générer un requirements.txtfichier à alimenter dans votre conteneur Docker.

Maintenant, vous avez dit que vous utilisez git, donc j'utiliserais des hooks git locaux. Vous pouvez les utiliser pour créer le conteneur Docker, exécuter des tests automatisés, puis déployer votre conteneur. Vous pouvez consulter de nombreux guides et tutoriels différents sur ce sujet.

Pour gérer votre infrastructure, j'utiliserais Terraform. Terraform est génial car vous pouvez faire tourner un environnement à la demande et le supprimer une fois terminé. Ma recommandation serait de commencer simple et une fois que vous maîtrisez docker et terraform, vous pouvez essayer des déploiements bleu / vert.

Maintenant, si vous utilisez Gitlab ou si vous souhaitez changer, il propose également un service ci / cd gratuit. Cela comprend tellement de fonctionnalités intéressantes et est vraiment facile à utiliser. Je l'utilise personnellement pour toutes mes applications. Vous pouvez ignorer complètement les hooks git locaux et tester dans le pipeline gitlab ou les conserver pour tester chaque commit localement et utiliser gitlab pour construire et déployer.

J'espère que cela a été quelque peu utile.

Les réponses publiées ont été très utiles pour me permettre de repenser mon problème et différentes approches. Je n'ai pas encore implémenté de solution mais j'ai décidé d'une approche, donc je documente cela et je le sélectionne comme réponse. En résumé, c'est ceci:

Mon approche choisie

• Pour l'environnement en direct, j'utiliserai deux machines virtuelles (probablement à l'aide de gouttelettes DigitalOcean) exécutant Ubuntu et configurées exactement de la même manière.
• J'emploierai une approche bleu-vert en utilisant la fonction IP flottante au sein de DO pour maintenir mes deux serveurs identiques en tant que Live et Pre-Prod / Backup.
• Je vais créer une machine virtuelle (probablement à l'aide de VirtualBox) dans ma configuration de développement pour l'utiliser comme environnement de transfert. Cette machine virtuelle sera configurée exactement de la même manière que mes deux serveurs en direct.
• J'écrirai un seul script commun en Python pour configurer un environnement à partir de zéro et je l'utiliserai pour configurer mon environnement de transfert et ma paire live / pré-prod.
• J'emploierai des hooks git pour déclencher des mises à jour des environnements (probablement déclenchées manuellement).

Considérations qui ont motivé cette approche

• Docker: J'ai décidé contre. Bien que je prenne au sérieux les réponses (merci @Levi et @Dan) qui disent que je devrais revenir et que ça ne devrait pas être si mal, j'ai eu trop d'expériences dans le passé pour me lancer dans quelque chose de nouveau et réaliser que je suis tombé dans un trou de lapin qui mange du temps et prend un certain temps pour y aller. Je pense que ce serait différent si je travaillais même avec une autre personne mais comme quelqu'un travaillant complètement seul chaque minute est précieuse.

• Machines virtuelles: je n'avais pas vraiment réfléchi à cela avant de commencer à travailler avec certains des didacticiels Docker qui utilisent des machines virtuelles pour démontrer la fonctionnalité Swarm. L'idée de pouvoir créer un tout nouvel environnement dont j'ai le contrôle total est très séduisante.

• Scripting: invité par la réponse utile de @ AnoE, j'ai creusé un peu plus et il semble que Python soit reconnu comme une option viable pour les scripts et comme c'est ce dans quoi j'écris mon application, il semble qu'il devrait y avoir une synergie (si j'ai besoin pour apprendre quelque chose de nouveau pour mon script, ce seront des connaissances que je pourrai utiliser pour écrire mon application)

Je mettrai à jour une fois que j'aurai fait des progrès avec cela et si ça va horriblement mal, je reconnais que j'ai peut-être fait le mauvais choix!).

Mise à jour du 20 octobre 2018.

J'ai décidé d'écrire un script Python, mais cela impliquait souvent d'invoquer une commande bash à partir de Python, puis de récupérer la réponse et j'ai trouvé que cela ajoutait beaucoup au temps de développement. Après quelques semaines de progrès lents, j'ai cherché ailleurs. J'avoue que je l'ai peut-être mal approché, mais j'avais besoin de quelque chose qui allait être plus rapide.

J'ai finalement opté pour Vagrant / Ansible / VirtualBox et après plus de mois que j'aime admettre, j'ai obtenu quelque chose qui fonctionnait bien, mais après beaucoup de travail pour apprendre de nouvelles compétences (Vagrant et Ansible étaient complètement nouveaux pour moi). J'ai ensuite appliqué le script Ansible pour provisionner un Droplet DigitalOcean et j'ai trouvé que cela fonctionnait vraiment bien. Je suis devenu un fan d'Ansible mais même si je suis d'accord (avec les critiques) qu'il est relativement facile à utiliser, c'est toujours un nouveau paradigme et une courbe d'apprentissage assez abrupte.

Au moment de la rédaction de ce document, j'ai fourni deux gouttelettes distinctes sur DigitalOcean dans une configuration bleu-vert, en utilisant des adresses IP flottantes DO pour basculer entre les deux, et sur chacune, l'application se trouve dans une copie de travail git, j'ai donc juste besoin de rafraîchir le Maître pour mettre à jour un environnement.

J'ai un problème pour que les IP flottantes fonctionnent comme je m'y attendais, mais je m'attends à le résoudre bientôt, puis j'aurai un environnement DevOps fonctionnel.

Le gros avantage de cette approche est que, comme Ansible fonctionne, une fois que quelque chose fonctionne, il est relativement facile de le faire fonctionner dans un environnement différent et cela peut ne pas être si facile à réaliser avec un script python (ou du moins vous devez construire ce qui est un travail supplémentaire).

Je pense que la grande leçon est que les choses prennent plus de temps que prévu et l'apprentissage d'une nouvelle technologie apporte toujours des inconnues inconnues. Cela ne devrait pas être une surprise pour moi - mais c'est toujours le cas et en tant que développeur isolé, cela m'arrive beaucoup.