Welche Optionen gibt es für die Implementierung von "Nullkonfiguration" (dh minimale Konfiguration) in einem beliebigen Cloud-Dienst?
Mir ist klar, dass es Tausende von Cloud-Plattformen gibt, die jeweils eine bestimmte Sprache, einen bestimmten Paketsatz und einen speziellen Workflow unterstützen, oft mit proprietären Kommandozeilen-Tools, die die Implementierung weniger schmerzhaft machen.
Aber was, wenn ich nichts über bestimmte Cloud-Plattformen wissen möchte, und ich möchte Code schreiben, der in den nächsten Jahren einfach in einer Cloud bereitgestellt werden kann?
Offensichtlich wäre die konkreteste Antwort einfach: Erstellen Sie ein Image einer virtuellen Maschine mit allem, was Sie wollen, und führen Sie es dann in der Cloud aus (dieser Weg ist praktisch keine Konfiguration und wir können erwarten, dass ein VM-Image, das ich heute erstelle, noch funktioniert) auf den meisten VM-Hosts in 10 Jahren).
Also meine Frage ist: Was ist die nächste Stufe von der VM Bild ideal? Was sind die offensten und am weitesten akzeptierten Standards zum Einbetten einer vollständigen Beschreibung eines willkürlichen Software-Stacks in maschinenlesbarer Form, so dass ich meinen Software-Stack auf jeden beliebigen cloud-ähnlichen Hosting-Service werfen kann, ohne an eine für dieses Hosting spezifische Konfiguration zu denken Service?
Wenn Sie unter "Cloud" einen IaaS (Infrastruktur-as-a-Service-Provider) wie EC2 usw. - verstehen im Gegensatz zu PaaS ( Google App Engine, Heroku, usw. ), dann scheint der Trend in diesen Tagen Infrastruktur-als-Code und DevOps . Dies ist nicht genau 'Null-Konfiguration'; Es ist eher wie configure once und beschreibt die Konfiguration Ihres Stacks als Ganzes in einer DSL, die verwendet werden kann, um Ihren gesamten Stack aus nur einer Reihe von frisch gestarteten VMs in einer beliebigen Cloud zu erstellen oder neu zu erstellen .
Sie verfügen also über ein Konfigurationsmanagementsystem und eine Reihe maschinenlesbarer "Rezepte", die das Konfigurationsmanagementsystem versteht. Es ist üblich, dass die Rezepte in einer Art benutzerdefinierter DSL ausgedrückt werden, obwohl es Systeme gibt, in denen die Sprache tatsächlich XML ist.
Einige bekannte Beispiele für solche Konfigurationsmanagementsysteme sind:
Es gibt viele andere; aber ich habe keine Erfahrung mit ihnen (CFEngine, bcfg2 (verwendet XML))
Diese Werkzeuge sind idempotent . Dies bedeutet, dass Sie die Konfiguration so oft wie gewünscht erneut ausführen können, und nur was getan werden muss, um die in Ihren Rezepten angegebene Beschreibung zu erfüllen, wird durchgeführt. Wenn Sie bestimmte Dateien angegeben haben, die in bestimmten Verzeichnissen mit bestimmten Inhalten abgelegt werden sollen, werden sie nur dann erstellt (oder geändert), wenn sie benötigt werden. Pakete werden nur installiert, wenn sie benötigt werden oder wenn ihre Version von den in den Rezepten angegebenen Versionen abweicht.
Geben Sie in Chef beispielsweise an, dass ein Benutzer tomcat vorhanden sein muss und dass eine bestimmte Version von Java installiert sein muss und dass das Postfix ausgeführt werden muss und dass eine bestimmte XML-Datei zu einem gegebenen Zeitpunkt verfügbar sein muss Ort, Sie würden ein Rezept haben, das wie folgt aussieht:
Koch für einen, bietet eine Reihe von vorgefertigten Rezepten oder "Kochbüchern", die Sie einfach herunterladen, einbinden und als Teil Ihrer Infrastruktur verwenden. In Chef schreiben Sie Ihre Kochbücher basierend auf dem, was die Server sein sollen - dann definieren Sie Rollen , die festlegen, welche Kochbücher auf welche Serverklasse angewendet werden, aus denen Ihr Stack besteht. Sie weisen Ihren Instanzen einfach Rollen zu, booten sie und beobachten, wie sich der gesamte Stack selbst aufbaut.
Ich würde sagen, dass dies die Standardmethode zur Verwaltung ausführbarer Full-Stack-Beschreibungen der Infrastruktur wird (muss nicht nur Cloud sein - ich teste auf VMWare und / oder VirtualBox, sondern stelle sie mit dem gleiche Rezepte.)
Der Nachteil ist, dass Sie die DSL lernen müssen. Und möglicherweise, signifikante Änderungen an Ihrem Workflow. Diese Systeme haben auch ihre individuellen Vor- / Nachteile. Aber die Dinge auf diese Weise zu tun, ist sicherlich die nächste Stufe, da ein benutzerdefiniertes VM-Image beibehalten wird und in vielerlei Hinsicht flexibler ist. Wenn beispielsweise jeder Cloud-Anbieter Ihnen eine NTP-Serveradresse zur Verfügung stellt, um Ihre Instanzen synchron zu halten, müssen die Bilder je nach Anbieter geändert werden. Mit Chef / Puppet kann dies automatisiert und sauber abstrahiert werden.
Während VM-Images eingefrorene Kopien Ihrer gewünschten 'Konfiguration' sind, erfassen sie nicht, wie jede Komponente - jede Instanz im Stapel - miteinander interagieren soll. Ein Anwendungsserver muss zum Beispiel über den Datenbankserver, seine Adresse und verschiedene Verbindungsparameter Bescheid wissen - der Datenbankserver muss über alle Anwendungsserver Bescheid wissen, die eine Verbindung zu ihm herstellen möchten (in einem Cloud-Kontext sogar die Anwendungsserver) wachsen oder schrumpfen in der Anzahl mit der Zeit). Das ist ein dynamisches Zeug, das mit einem System wie Chef sehr einfach zu automatisieren ist.
Ich denke, die Antwort auf Ihre Frage ist Jelastic . Um Ihre Anwendung in der Cloud bleiben zu lassen und anderen die Möglichkeit zu geben, sie zu betrachten, werden Sie mindestens dem http-Protokoll entsprechen und zumindest denke ich, dass PHP dort als Sprache gewinnt. Wenn das wahr ist, gibt es nur eine Plattform auf dem Markt, und es ist Jelastic. Versuche es selbst und lass es mich wissen. Zero Configs und Vendor Lock kostenlos mit super Web-Konsole, es ist einfach die beste.Ich mag wie ein Evangelist klingen, aber ich bin ein zufriedener Kunde ihrer Stack (ich benutze Java als Programmiersprache und habe ein Startup) und wirklich ihre Plattform lieben .
Surya
Die Zero-Konfiguration ist eher eine Eigenschaft, die in "Platform as a Service" als "Infrastructure as a Service" zu finden ist. Vielleicht sollten wir "Minimalkonfiguration" statt "Null" sagen. PAAS gibt Ihnen eine halbfeste Architektur, in der Sie leben können, und zeigt einige Hebel auf, um Dinge zu konfigurieren. Mit IAAS machen Sie alles, vielleicht mit Hilfe einiger Werkzeuge.
Ich kann von meiner Erfahrung mit Google App Engine sprechen, bei der Sie Ihren Code lokal entwickeln, ihn mit einer Deskriptordatei packen und dann in App Engine bereitstellen. Sie sollten sich nicht um die zugrunde liegenden Maschinen kümmern und sich auch nicht darum kümmern, wie man mit Traffic usw. aufsteigt. Die Plattform kümmert sich um dieses Zeug für Sie, ob es nun einen guten oder einen schlechten Job macht. Die Idee ist, dass Sie sich nur auf Ihre App konzentrieren. Obwohl Sie in Wirklichkeit ein bisschen von der zugrundeliegenden Architektur verstehen müssen, die Sie erhalten, um gute Designentscheidungen zu treffen.
AppEngine unterstützt Java, Python und Go.
Heroku und Engine Yard sind ebenfalls PAAS und begannen mit der Unterstützung von Ruby. Heroku unterstützt jetzt auch Java, Python und Node.js.
Es gibt auch die Open-Stack-Initiative von Rackspace, die darauf abzielt, eine Architektur zu definieren, in der Sie leben können, aber sie sollte "tragbar" für verschiedene IAAS-Anbieter sein. Tolles Konzept, aber ich glaube nicht, dass viele es übernommen haben. Ссылка
Ich glaube, die einfachste Antwort auf die Langlebigkeit von Anwendungen ist die Abstraktion.
Beschreiben Sie Ihre Anwendungsanforderungen in abstrakten und einfachen Begriffen, erstellen oder verwenden Sie ein Anwendungsframework, das dies unterstützt, und isolieren Sie die Teile, die Ihren Anwendungsanforderungen entsprechen.
In Python könnte dies dazu führen, dass etwas in Google App Engine erstellt wird. Die Kernidee, die Sie daraus ableiten sollten, ist, dass Sie (oder Google) immer in der Lage sind, die zugrunde liegende Infrastruktur zu verbessern, ohne die Anwendung zu berühren, da sie den Betrieb in Begriffen beschreibt, die keine Annahmen darüber zulassen. Die Kosten, wenn dieser Ansatz das Was und Wie Ihrer Anwendung definiert, können abstrakt und portabel beschrieben werden, aber wenn Sie dies richtig machen, müssen Sie sich nur um Änderungen in der von Ihnen verwendeten Kernsprache kümmern.
Einer der großen Aspekte, die dieser Frage entgehen, ist Veränderung ist gut . Sie sollten nie Angst haben, einen ganzen Anwendungsstapel zu verwerfen. In der Tat ändert sich die Technologie heute so schnell, dass sie eine Voraussetzung dafür ist, im Voraus zu bleiben und relevant zu sein. Aus diesem alleinigen Grund ist es sehr unwahrscheinlich, dass Sie sogar in den kommenden Jahren auf die gleiche Weise schreiben werden.
Jede Cloud-Plattform kann Ihre Frage beantworten und sagen: "Ich habe die beste und universellste Lösung", aber nur die Standards, die von den Entwicklern gewählt werden, bleiben bestehen. Natürlich können Sie Ihre eigene VM-Vorlage erstellen und für Jahre verwenden - das Problem ist, dass Ihr Betriebssystem Unterstützung verliert und eines Tages abgeschrieben und unsicher wird. So werden Sie gezwungen sein, nicht nur Ihre Vorlage, sondern Ihre gesamte Anwendungsinfrastruktur zu aktualisieren (wenn Sie es nicht ständig machen). Also VMs sind in Ordnung, aber es ist keine Antwort, denke ich ... Auf der anderen Seite haben Sie Cloud-Provider-Lösungen wie Jelastic Deployment-Skripte oder Azure Cloud Service-Bereitstellungen (manuell oder über IDE). Aber diese Lösungen können sich in Zukunft so weit ändern, dass Sie Ihre Skripte nicht verwenden können, ohne sie zu refaktorieren. Der dritte Weg besteht darin, einige Devops-Mechanismen wie Chef, Puppet, Docker oder andere zu verwenden, die wir seit heute oder in Zukunft nicht mehr kennen. Die meisten von ihnen sind sehr kraftvoll und großartig. Viele von ihnen haben Cloud-Implementierungen als Chef-Plugins für Amazon oder Azure, Puppet-Server bei Bedarf auf Azure, Docker bei Amazon oder Azure und so weiter. Das Problem ist, dass wir heute nicht wissen, welches in Zukunft Standard sein wird. All das ist eine sehr junge Lösung und (um ehrlich zu sein) nicht so populär und nicht so einfach zu lernen. Und die letzte - standardisiert, geliebt von Devs, geliebt von Admins und Devops - GIT und kontinuierliche Entwicklung / kontinuierliche Integration. GIT ist ein Standard und wird in Zukunft sein, weil es von Wirtschaft und Bildung gut angenommen wird. Viele öffentliche Cloud-Anbieter (und auch private) ermöglichen die Bereitstellung von Anwendungen mit git direkt auf der Cloud-Plattform. Ich verwende Azure PaaS-Lösung für meinen Python-Code. Alles, was ich tun muss, ist, Deployment-Slot zu erstellen und meinen Code zu schieben. Es gibt einen kontinuierlichen Integrationsmechanismus in der Azure Web App-Plattform und Sekunden nach dem Festschreiben wird mein Code bereitgestellt. Solche Lösungen finden Sie in wenigen Wolken, aber nicht überall. Es muss PaaS geben, nicht nur IaaS, wie es in vielen öffentlichen Clouds der Fall ist.
Tags und Links cloud