Was ist ein guter Devops-Ansatz für einen einzelnen Entwickler, der Python-Webanwendungen schreibt?


8

Ich vermute, diese Frage wird für einige Leser unglaublich trivial erscheinen, aber als jemand, der Entwickler ist, aber wenig Erfahrung mit der Bereitstellung von Apps in etwas anderem als einem Handbuch hat, hoffe und hoffe, dass Sie verstehen, dass dies der Fall ist Es ist ziemlich entmutigend, die Anzahl der verschiedenen Ansätze und Tools zu sehen, daher könnte ich ein paar Ratschläge gebrauchen, um mich in die richtige Richtung zu bewegen.

Ich bin Entwickler, jetzt nur in meiner Freizeit, die begrenzt ist. Bis jetzt habe ich mit Java gearbeitet, Webanwendungen erstellt und war einigermaßen zufrieden mit der Bereitstellung einer Kriegsdatei in einer Tomcat-Umgebung, in der die Dinge gut gekapselt sind.

Ich arbeite jetzt in Python und Django, aber wenn ich mich dem Punkt nähere, an dem ich bereitstellen muss, möchte ich einen soliden Devops-Workflow einrichten, um so viel wie möglich zu automatisieren und sicherzustellen, dass ich zuverlässig bereitstellen kann Der Anwendungsfall ist relativ einfach. Ich möchte vermeiden, ein umfangreiches Toolset zu erlernen, das für meine Anforderungen überarbeitet wurde und viel Zeit erfordert. Ich würde lieber meine App codieren.

Daher suche ich nach einem Mittelweg, mit dem ich meine App (s) zuverlässig bereitstellen und verwalten kann, ohne viel Zeit für die Einrichtung und das Erlernen eines großen Devops-Ökosystems zu investieren.

Noch ein paar Details ...

Kontext

  1. Ich entwickle auf einem Mac mit PyCharm, um Django 2, Python 3 zu erstellen.
  2. Ich verwende git (aber nicht auf github), um die Softwareversionierung zu verwalten.
  3. Ich bin mit anderen Sprachen und Skriptsprachen vertraut und habe ein paar (wahrscheinlich ziemlich amateurhafte) Bash-Skripte geschrieben, obwohl ich Bash nicht mag. Ich habe mich auch mit Perl beschäftigt, was mir klar wurde, dass es keine wirkliche Sprache zum Spielen ist (dh Sie müssen Zeit damit verbringen, es richtig zu lernen).
  4. Ich beabsichtige, in einer VPS-Umgebung, wahrscheinlich DigitalOcean, bereitzustellen.
  5. Meine App ist nicht geschäftskritisch, aber es ist wichtig, dass ich weiß, ob die Site ausfällt, und eine Möglichkeit zur zuverlässigen Wiederherstellung haben muss, wenn dies der Fall ist, ob dies ein Neustart der App, ein Neustart des Servers oder ein Wechsel zu einem anderen Server ist ( oder andere).

Spezifische Anforderungen

  1. Möglichkeit, eine neue Umgebung für den Empfang der App einzurichten.

    Bis jetzt, während ich lerne, war dies manuell und jedes Mal, wenn ich es getan habe, habe ich mit einem neuen Droplet von vorne angefangen. Ich möchte, dass dies viel einfacher (automatisiert) ist, damit ich dies zuverlässig tun kann, wenn ich im Notfall eine neue Umgebung einrichten muss.

  2. Möglichkeit, die App in einer Staging-Umgebung bereitzustellen, die so identisch wie möglich mit dem Live ist, idealerweise als automatisierter Prozess, der durch einen Git-Push unter Verwendung eines kontinuierlichen Integrationsansatzes ausgelöst wird (was ich noch nie zuvor getan habe).

  3. Möglichkeit zum "Drücken der Taste", wenn ich mit der App in der Staging-Umgebung zufrieden bin, um idealerweise automatisch in eine Live-Umgebung zu wechseln.

  4. Möglichkeit, die Site zu überwachen (nur eine Umfrage auf einer Seite reicht aus)

  5. Möglichkeit, die Live-Site auf einen anderen Server umzustellen, wenn ich nach einem App- oder Serverfehler auf der Live-Site eine Wiederherstellung durchführen muss. Ich denke, vielleicht würde ein blau-grüner Ansatz für mich funktionieren?

Was habe ich versucht oder in Betracht gezogen?

  • Manuelles Einrichten der Live-Umgebung mit der Django-App, dann kopieren Sie die neue Codebasis manuell, wenn sich etwas ändert. Dies ist anfällig für menschliches Versagen, und ich befürchte, dass bei einer Bereitstellung ein Fehler gemacht wird, der zu einem nicht behebbaren Fehler führt.

  • Docker. Ich gebe zu, als ich von Docker erfuhr, schien ein Traum wahr zu werden, aber nach ein wenig Experimentieren und Nachforschen bin ich entmutigt, wie viel ich lernen und wissen muss, um dies zum Laufen zu bringen und zu verwalten. Es kann sein, dass sich das lohnt, denn sobald es funktioniert, ist das Risiko sehr gering, aber im Moment fühlt es sich wie eine größere Investition meiner Zeit an, als ich es mir erhofft habe.

  • Bash-Skripte. Verwenden Sie sie, um die ursprüngliche Umgebung einzurichten und für bestimmte Aufgaben wie das Aktualisieren der App. Ich mache mir darüber Sorgen, dass es sich bei den Skripten um Code handelt, der getestet werden muss, und ich befürchte, dass es viel Zeit in Anspruch nehmen würde, auf diese Weise ein zuverlässiges Toolset zu erstellen.

  • Ich habe mir die Optionen von Digital Ocean für schwebende IP-Adressen und die Möglichkeit angesehen, zwei Server für einen "blaugrünen" Ansatz zu haben, was durchaus sinnvoll erscheint. Wenn ich diesen Weg gehe, muss ich die Bereitstellung noch automatisieren können.

Also ... ich suche Rat zu einem Devops-Ansatz, der das richtige Gleichgewicht zwischen der Minimierung des Risikos (z. B. dem Risiko, die Live-App mit einem Update zu beschädigen, oder dem Risiko, sich nicht von einem Fehler erholen zu können) und der Minimierung der Zeit findet Ich muss investieren, um die Umgebungen und den Workflow einzurichten.

Antworten:


5

Ich bin weder mit der Python-Entwicklung noch mit DigitalOcean vertraut, daher möchte ich nur einige Hinweise geben:

  • Ziel ist die Automatisierung. Alles. Wie Sie das erreichen, liegt ganz bei Ihnen, und das Erstellen eigener Werkzeuge ist nicht weit hergeholt. Viele tun dies auf diese Weise. Eine konkrete und ziemlich niedrig hängende Frucht besteht darin, einen Git-Post-Receive-Hook zum Laufen zu bringen, der Ihre Testumgebung bereitstellt und neu startet. Wenn Sie das haben, sollte der Rest einfach sein.
  • "Ich mache mir darüber Sorgen, dass die Skripte Code sind, der getestet werden muss" - diese Sorge ist unbegründet. Sie sind testen diese Skripte jedes Mal , wenn Sie Ihre Testumgebung bereitstellen, nachdem alle. Insbesondere in Verbindung mit einem blaugrünen Ansatz ist es in Ordnung, Bash-Skripte zu haben.
  • "Ich mag Bash nicht." - Dann finden Sie eine andere Skriptsprache, die Ihnen gefällt. Vielleicht versuchen Sie es mit Ruby? Die Sprach- und Kernbibliotheken sind sehr sauber und gut dokumentiert, und ich würde sagen, ziemlich einfach zu lernen. Oder, nur zum Spaß, Go (lang), das für Entwickler von Werkzeugaufgaben gut geeignet zu sein scheint. Und schließlich, da Sie Python zu mögen scheinen, können Sie damit sicherlich auch Installationsaufgaben erledigen. Von diesen hat Go den Vorteil, dass es eigenständige Binärdateien erstellt und keine komplexe Umgebung benötigt, die zuerst selbst installiert wird, sodass das Bootstrapping möglicherweise einfacher ist.
  • "Eine Staging-Umgebung, die so identisch wie möglich mit dem Live ist" - Wenn Sie ein Skript haben, das eine Umgebung von Grund auf neu erstellt, dh aus einem mehr oder weniger leeren Basis-Image, sind Ihre Umgebungen bis auf die darin codierten Deltas identisch Ihr Skript. Darum geht es bei alledem.
  • "Möglichkeit, eine Live-Site auf einen anderen Server umzustellen" - das einzige, worüber Sie nachdenken müssen, ist, was mit Ihren persistenten Daten passiert. Das heißt, Sie möchten es so gestalten, dass Sie Ihre Anwendungen im laufenden Betrieb mit verschiedenen dauerhaften Volumes / Stores verknüpfen können, um hin und her wechseln zu können.
  • "Docker - entmutigt" - um ehrlich zu sein, sollte es nicht so schlimm sein. Wenn Sie wissen, wie Sie mit Befehlszeilentools (keine GUI-Tools) eine Umgebung von Grund auf neu erstellen, sollte es ziemlich einfach sein, diese in einer Docker-Datei zu platzieren. Die besorgniserregenden Details erscheinen, wenn es Zeit zum Einstellen ist (dh Bildgrößen reduzieren), aber ansonsten sollte es nicht so schlimm sein. Lassen Sie es zuerst irgendwie funktionieren und finden Sie dann heraus, wie Sie es schön machen können. Das Gute ist, dass das Wissen, das Sie erwerben, auf viele andere Umgebungen übertragen wird.

Viel Glück!


3

Danke für die tolle Frage. Nichts ist wirklich trivial, wenn Sie es zum ersten Mal tun, und wir waren alle einmal neu in etwas.

Meine erste Empfehlung ist, Docker erneut zu besuchen. Probieren Sie verschiedene Anleitungen und Tutorials aus. Es ist wirklich einfach. Sie haben eine Docker-Datei, die "erstellt" wird, buchstäblich nur Befehle, die auf dem "Container" oder "Image" ausgeführt werden sollen. Sie verschieben dieses Bild in eine Registrierung, die öffentlich oder privat sein kann. Anschließend führen Sie das Image auf einem Hostcomputer aus. Docker ist sehr wichtig bei node.js und Python, wo Sie viele Abhängigkeiten haben und es manchmal sehr schwierig sein kann, sie zu verwalten. Wenn Sie pip verwenden und dies sollten, können Sie eine requirements.txtDatei generieren , die in Ihren Docker-Container eingespeist wird.

Jetzt hast du gesagt, dass du Git verwendest, also würde ich lokale Git-Hooks verwenden. Mit diesen können Sie den Docker-Container erstellen, automatisierte Tests ausführen und dann Ihren Container bereitstellen. Sie können viele verschiedene Anleitungen und Tutorials zu diesem Thema nachschlagen.

Für die Verwaltung Ihrer Infrastruktur würde ich Terraform verwenden. Terraform ist großartig, da Sie eine Umgebung bei Bedarf hochfahren und anschließend löschen können. Meine Empfehlung wäre, einfach anzufangen und sobald Sie Docker und Terraform beherrschen, können Sie blau / grüne Bereitstellungen ausprobieren.

Wenn Sie Gitlab verwenden oder wechseln möchten, bietet es auch einen kostenlosen CD / CD-Service. Dies beinhaltet so viele coole Funktionen und ist wirklich einfach zu bedienen. Ich benutze es persönlich für alle meine Apps. Sie können die lokalen Git-Hooks vollständig überspringen und in der Gitlab-Pipeline testen oder sie behalten, um jedes Commit lokal zu testen und Gitlab zum Erstellen und Bereitstellen zu verwenden.

Ich hoffe das war etwas hilfreich.


1
Bei Docker war das Prinzip, Komponenten in verschiedenen Containern zu haben, etwas entmutigend. Also eine für die App, eine für Gunicorn, eine für Nginx usw. Sie müssen dann eine zusätzliche Konfiguration eingeben, damit sie miteinander sprechen. Es scheint das Ziel eines einzigen gekapselten Containers zu besiegen, der auf jede Umgebung übertragbar ist. Da diese Antwort und @ Anoe's jedoch empfohlen haben, einen anderen Blick darauf zu werfen, werde ich es tun.
Auspice

1
@Auspice Das ist eher ein "Micro Services" -Ansatz. Während es für einen Docker-Container eine bewährte Methode ist, nur einen einzigen Prozess zu haben, ist es oft nicht das, was ich sehe. Überprüfen Sie "The Docker way?" hier github.com/just-containers/s6-overlay . Ich würde meine Infra persönlich mit Ansible aufrufen. Ich würde ansible verwenden, um Terraform aufzurufen, um es zu erstellen. Dann würde ich ansible verwenden, um meine Server zu aktualisieren, Docker zu installieren, Nginx zu installieren und meine Docker-Apps als Dienste starten zu lassen. Ich hätte niblex ansible als Proxy für die Container konfigurieren können, in denen sich die App und das Gunicorn befinden.
Levi

0

Die veröffentlichten Antworten waren sehr hilfreich, damit ich mein Problem und verschiedene Ansätze überdenken konnte. Ich habe noch keine Lösung implementiert, aber ich habe mich für einen Ansatz entschieden, also dokumentiere ich das und wähle ihn als Antwort aus. Zusammenfassend ist dies:

Mein gewählter Ansatz

  • Für die Live-Umgebung werde ich zwei virtuelle Maschinen (wahrscheinlich mit DigitalOcean-Tröpfchen) verwenden, auf denen Ubuntu ausgeführt und genau gleich konfiguriert wird.
  • Ich werde einen blau-grünen Ansatz verwenden, der die Floating IP-Funktion in DO verwendet, um meine beiden identischen Server als Live und Pre-Prod / Backup zu warten.
  • Ich werde in meiner Entwicklung eine VM (wahrscheinlich mit VirtualBox) erstellen, die für die Verwendung als Staging-Umgebung eingerichtet ist. Diese VM wird genauso eingerichtet wie meine beiden Live-Server.
  • Ich werde ein einziges allgemeines Skript in Python schreiben, um eine Umgebung von Grund auf neu einzurichten, und ich werde dieses verwenden, um meine Staging-Umgebung und mein Live / Pre-Prod-Paar zu konfigurieren.
  • Ich werde Git-Hooks verwenden, um Updates für die Umgebungen auszulösen (wahrscheinlich manuell ausgelöst).

Überlegungen, die diesen Ansatz vorangetrieben haben

  • Docker: Ich habe mich dagegen entschieden. Obwohl ich die Antworten (danke @Levi und @Dan) ernst nehme, die besagen, dass ich sie erneut besuchen sollte und es nicht so schlimm sein sollte, habe ich in der Vergangenheit zu viele Erfahrungen mit etwas Neuem gemacht und festgestellt, dass ich gefallen bin in einem Kaninchenbau, der Zeit verschlingt und ein Alter braucht, um loszulegen. Ich denke, es wäre anders, wenn ich sogar mit einer anderen Person zusammenarbeiten würde, aber da jemand jede Minute ganz alleine arbeitet, ist das wertvoll.

  • Virtuelle Maschinen: Ich hatte dies nicht wirklich in Betracht gezogen, bis ich anfing, mit einigen Docker-Tutorials zu arbeiten, die VMs verwenden, um die Swarm-Funktionalität zu demonstrieren. Die Idee, eine brandneue Umgebung schaffen zu können, über die ich die vollständige Kontrolle habe, ist sehr ansprechend.

  • Scripting: Auf die hilfreiche Antwort von @ AnoE hin habe ich ein bisschen mehr gegraben und es scheint, dass Python als praktikable Option für das Scripting anerkannt ist, und da ich meine App darin schreibe, sollte es einige Synergien geben (wenn ich es brauche) Um etwas Neues für mein Skript zu lernen, ist es Wissen, das ich beim Schreiben meiner App verwenden kann.

Ich werde aktualisieren, sobald ich einige Fortschritte gemacht habe, und wenn es schrecklich schief geht, werde ich bestätigen, dass ich vielleicht die falsche Wahl getroffen habe!).

Update am 20. Oktober 2018.

Ich wollte ein Python-Skript schreiben, aber dies beinhaltete oft das Aufrufen eines Bash-Befehls von Python und das anschließende Zurückerhalten der Antwort. Ich fand, dass dies die Entwicklungszeit erheblich verlängerte. Nach ein paar Wochen langsamen Fortschritts schaute ich woanders hin. Ich gebe zu, dass ich es vielleicht falsch angegangen bin, aber ich brauchte etwas, das schneller sein würde.

Ich habe mich schließlich für Vagrant / Ansible / VirtualBox entschieden und nach mehr Monaten, als ich zugeben möchte, etwas bekommen, das gut funktioniert hat, aber nach viel Arbeit, um einige neue Fähigkeiten zu erlernen (Vagrant und Ansible waren für mich völlig neu). Ich habe dann das Ansible-Skript angewendet, um ein DigitalOcean-Droplet bereitzustellen, und fand, dass dies wirklich gut funktioniert hat. Ich bin ein Fan von Ansible geworden, aber obwohl ich (mit Rezensenten) zustimme, dass es relativ einfach zu bedienen ist, ist es immer noch ein neues Paradigma und eine ziemlich steile Lernkurve.

Zum Zeitpunkt des Schreibens habe ich zwei separate Droplets auf DigitalOcean in einer blaugrünen Konfiguration bereitgestellt, wobei DO Floating IP-Adressen verwendet wurden, um zwischen den beiden zu wechseln, und auf jeder befindet sich die Anwendung in einer Git-Arbeitskopie, sodass ich nur die aktualisieren muss Master zum Aktualisieren einer Umgebung.

Ich habe ein Problem damit, dass Floating IPs wie erwartet funktionieren, aber ich erwarte, dass dies bald behoben wird, und dann werde ich eine funktionierende DevOps-Umgebung haben.

Der große Vorteil dieses Ansatzes besteht darin, dass die Funktionsweise von Ansible relativ einfach ist, wenn Sie etwas in einer anderen Umgebung zum Laufen bringen. Dies ist möglicherweise mit einem Python-Skript nicht so einfach zu erreichen (oder Sie müssen es zumindest erstellen) dies ist zusätzliche Arbeit).

Ich denke, die große Lektion ist, dass die Dinge länger dauern als ich erwartet habe und das Erlernen einer neuen Technologie immer unbekannte Unbekannte mit sich bringt. Das sollte mich nicht überraschen - aber es ist immer so und als Einzelentwickler zu arbeiten, passiert mir sehr oft.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.