Infrastruktur als Code gewinnen wir auf einer Skala (Kirill Vetchinkin, TYME)

    Das Modell "Infrastruktur als Code (IaC)", das manchmal als "programmierbare Infrastruktur" bezeichnet wird, ist das Modell, nach dem der Aufbau der Infrastruktur dem Prozess der Programmiersoftware ähnelt. Tatsächlich war dies der Beginn der Aufhebung der Grenzen zwischen dem Schreiben von Anwendungen und dem Erstellen von Umgebungen für diese Anwendungen. Anwendungen können Skripts enthalten, die ihre eigenen virtuellen Maschinen erstellen und verwalten. Dies ist die Grundlage von Cloud Computing und ein wesentlicher Bestandteil von DevOps.


    Mit Infrastruktur wie Code können Sie virtuelle Maschinen auf Programmebene verwalten. Dadurch entfällt die manuelle Konfiguration und Aktualisierung der einzelnen Hardwarekomponenten. Die Infrastruktur wird extrem belastbar, d. H. Reproduzierbar und skalierbar. Ein Operator kann einen und 1000 Computer mit demselben Codesatz bereitstellen und verwalten. Zu den garantierten Vorteilen von Infrastruktur als Code zählen Geschwindigkeit, Effizienz und Risikominderung.


    So ungefähr die Dekodierung des Berichts von Kirill Vetchinkin über DevOpsDays Moscow 2018. In dem Bericht: Wiederverwendung von Ansible-Modulen, Speicherung in Git, Überprüfung, Wiederzusammenbau, finanzieller Nutzen, horizontale Skalierung mit einem Klick.



    Wen kümmert's, frage ich unter der Katze.


    Hallo allerseits Wie gesagt, ich bin Kirill Vetchinkin. Ich arbeite in der Firma TYME und heute werden wir über Infrastruktur als Code sprechen. Wir werden auch darüber sprechen, wie wir gelernt haben, bei dieser Praxis zu sparen, weil sie recht teuer ist. Es ist ziemlich teuer, viel Code für die Einrichtung der Infrastruktur zu schreiben.


    Erzählen Sie kurz von der Firma. Ich arbeite für TYME. Wir hatten ein Rebranding. Jetzt heißen wir PaySystem - wie der Name schon sagt, beschäftigen wir uns mit Zahlungssystemen. Wir haben sowohl unsere eigenen Lösungen - diese sind Verarbeitung und kundenspezifische Entwicklung. Kundenspezifische Entwicklung ist E-Banking, Rechnungsstellung und dergleichen. Und wenn Sie wissen, dass dies eine kundenspezifische Entwicklung ist, dann ist dies jedes Jahr eine große Anzahl von Projekten. Das Projekt folgt dem Projekt. Je mehr Projekte, desto mehr Infrastruktur muss geschaffen werden. Da die Projekte oft stark ausgelastet sind, verwenden wir die Microservice-Architektur. Daher gibt es in einem Projekt noch viele kleine Teilprojekte.



    Dementsprechend ist es sehr schwierig, diesen ganzen Zoo ohne vollwertige DevOps zu schaffen. Daher haben wir in unserem Unternehmen verschiedene Praktiken von DevOps eingeführt. Natürlich arbeiten wir an Kanban, bei SCRUM lagern wir alles in Git. Nach zakommitili findet eine kontinuierliche Integration statt, es werden Tests ausgeführt. Tester schreiben PyTest-End-to-End-Tests, die jede Nacht beginnen. Der Unit-Test beginnt nach jedem Commit. Wir verwenden einen separaten Montage- und Bereitstellungsprozess: Er wird gesammelt und dann mehrfach in verschiedenen Umgebungen bereitgestellt. Wir waren am Fenster. Unter Windows setzen wir mit Octopus Deploy ein. Dieses Jahr entwickeln wir DotNet Core. Daher können wir jetzt Software auf Linux-Systemen ausführen. Wir verließen den Octopus und kamen zu Ansible. Heute werden wir über diesen Teil sprechen, eine neue Praxis, die wir in diesem Jahr entwickelt haben. das, was wir vorher nicht hatten. Wenn Sie Tests haben, eine Anwendung gut erstellen und sie irgendwo bereitstellen können, ist alles in Ordnung. Wenn Sie jedoch zwei Umgebungen unterschiedlich eingerichtet haben, fallen Sie immer noch und Sie werden auf die Produktion zurückfallen. Daher ist das Verwalten von Konfigurationen eine sehr wichtige Praxis. Hier werden wir heute darüber sprechen.



    Ich erkläre Ihnen kurz, wie eine Produktökonomie in Bezug auf die Arbeitskosten aufgebaut ist: 60 Prozent werden für die Entwicklung aufgewendet , für die Analyse werden etwa 10 Prozent benötigt, für die Qualitätssicherung (Testen) etwa 20 Prozent und alles andere für die Konfiguration. Wenn Systeme als vollständiger Stream ausgeführt werden und viele Drittanbieter-Software in ihnen läuft, werden die Betriebssysteme selbst fast gleich konfiguriert. Wir verbringen zu viel Zeit damit und machen im Wesentlichen dasselbe. Die Idee war, alles zu automatisieren und die Kosten für die Infrastrukturkonfiguration zu reduzieren. Aufgaben desselben Typs sind automatisiert, gut debuggt und enthalten keine manuellen Vorgänge.



    Jede Anwendung funktioniert in einer bestimmten Umgebung. Mal sehen, woraus alles besteht. Wir sollten zumindest ein Betriebssystem haben , es muss konfiguriert werden, es gibt einige Anwendungen von Drittanbietern , die ebenfalls konfiguriert werden müssen. Die Anwendung selbst muss konfiguriert werden. Damit das gesamte Produkt funktioniert, wird die Anwendung selbst ausgeführt, die im gesamten System ausgeführt wird. Es gibt noch ein Netzwerk, das muss auch konfiguriert werden, aber wir werden heute nicht über das Netzwerk sprechen, da wir unterschiedliche Kunden und unterschiedliche Netzwerkgeräte haben. Wir haben auch versucht, die Konfiguration des Netzwerks zu automatisieren. Da sich die Geräte jedoch unterscheiden, gab es keine besondere Verwendung dafür, sie verwendeten mehr Ressourcen. Wir haben jedoch Betriebssysteme, Anwendungen von Drittanbietern automatisiert und Konfigurationsparameter an die Anwendungen selbst übertragen.



    Es gibt zwei Ansätze, wie Sie den Server konfigurieren können: von Hand: Wenn Sie ihn mit Ihren Händen konfigurieren, kann die Situation eintreten, dass Ihre Produktion auf eine Weise konfiguriert ist, ein Test für andere. Alles ist grün im Test, die Tests sind grün. Sie werden für die Produktion bereitgestellt und es gibt keinen Rahmen - nichts funktioniert für Sie. Ein anderes Beispiel: Drei Anwendungsserver werden von Hand konfiguriert. Ein Anwendungsserver wurde auf eine Weise konfiguriert, ein anderer Anwendungsserver auf eine andere Weise. Server können auf verschiedene Arten arbeiten. Ein anderes Beispiel: Es gab eine Situation, in der ein Stage-Server vollständig nicht mehr funktioniert. Startete die Erstellung eines neuen Servers mit und nach 30 war der Server fertig. Ein anderes Beispiel: Der Server funktioniert nicht mehr. Wenn Sie Ihre Hände einrichten, müssen Sie nach einer Person suchen, die weiß, wie sie eingerichtet wird. Sie müssen die Dokumentation anheben. Wie wir wissen Dokumentation ist kaum relevant. Das ist ein großes Problem. Und das Wichtigste ist, dass dies eine Prüfung ist, dh, grob gesagt, Sie haben zehn Administratoren, die jeweils etwas mit den Händen einrichten. Es ist nicht besonders klar, ob sie richtig oder falsch eingerichtet wurden und wie allgemein zu verstehen ist, ob dann könnten die einstellungen etwas extra stellen, einige unnötige ports öffnen.



    Es gibt eine Alternative - das ist genau das, worüber wir heute sprechen - das ist die Konfiguration aus dem Code. Das heißt, wir haben ein Git-Repository, in dem die gesamte Infrastruktur gespeichert ist. Es enthält alle Skripte, mit denen wir es anpassen werden. Da dies alles in git ist, haben wir alle Vorteile aus der Verwaltung des Codes, da wir in der Entwicklung überprüfen, prüfen, den Verlauf ändern können, wer hat, warum, Kommentare, wir können zurücksetzen. Um mit dem Code arbeiten zu können, müssen Sie eine kontinuierliche Montagepipeline verwenden - eine Implementierungspipeline. Damit ein System Änderungen an den Servern vornimmt, ist es nicht die Person, die etwas mit den Händen tat, sondern das System ausschließlich.



    Als ein System, das Änderungen vornimmt, verwenden wir Ansible. Da wir keine große Anzahl von Servern haben, passt das gut zu uns. Wenn Sie 100 bis 200 Server dort haben, werden Sie kleine Probleme haben, da sie (dh Ansible) immer noch mit jedem Server verbunden sind und diese wiederum anpassen - dies ist ein Problem. Es ist besser, andere Mittel zu verwenden, die nicht drücken (drücken) und Kugel (ziehen). Aber für unsere Geschichte, wenn wir viele Projekte haben, aber nicht mehr als 20 Server - das passt perfekt zu uns. Ansible hat ein großes Plus - eine niedrige Eintrittsschwelle. Das heißt, buchstäblich kann jeder IT-Spezialist dies in drei Wochen vollständig beherrschen. Er hat viele Module. Das heißt, Sie können die Clouds, Netzwerke, Dateien, Softwareinstallation, Bereitstellung verwalten - absolut alles. Wenn es keine Module gibt, können Sie Ihre eigenen schreiben,



    Überlegen Sie sich im Allgemeinen kurz, wie es überhaupt aussieht, dieses Werkzeug. Ansible hat Module, über die ich bereits gesprochen habe. Das heißt, sie können geliefert werden, sie können selbst schreiben, wer etwas tut. Es gibt Inventare - hier werden wir unsere Änderungen durchführen, das heißt, dies sind Hosts, ihre IP-Adressen und für diese Hosts spezifische Variablen. Und dementsprechend die Rolle. Rollen sind das, was wir auf diesen Servern rollen. Wir haben auch Hosts, die in Gruppen gruppiert sind. In diesem Fall sehen wir, dass wir zwei Gruppen haben: einen Datenbankserver und einen Anwendungsserver. In jeder Gruppe haben wir drei Autos. Sie sind über ssh verbunden. So lösen wir die Probleme, über die wir zuvor gesprochen haben, dass wir in unserem ersten Server identisch konfiguriert sind, da dieselbe Rolle auf dem Server läuft. Und auf dieselbe Weise, wenn wir diese Rolle auf mehreren Maschinen ausführen,



    Wenn wir uns genauer ansehen, wie das Ansible-Projekt funktioniert, dann sehen wir hier, dass Lagerbestände für die Produktion akzeptabel sind. Diese Gruppe ist aufgelistet und es gibt zwei Server. Wenn wir zu einem bestimmten Server gehen, wird hier die IP-Adresse dieses Systems angegeben. Es können auch andere Parameter vorhanden sein - Variablen, die für diese Umgebung spezifisch sind. Wenn wir uns die Rollen ansehen. Diese Rolle enthält mehrere Aufgaben (Aufgaben), die ausgeführt werden. In diesem Fall ist dies die Rolle für die Installation von PostgreSQL. Das heißt, wir installieren die notwendige Anwendung, erstellen Datenbanken. Hier benutzen wir eine Schleife. Es gibt mehrere davon (Datenbanken). Dann stellen wir die notwendige Verbindung her - IP-Adressen, die in dieser Datenbank autorisiert werden können. Und entsprechend am Ende der Firewall eingerichtet. Die Einstellungen werden auf alle Server in der Gruppe angewendet.



    Wenn wir uns dem Problem selbst nähern, haben wir gelernt, Server perfekt mit Ansible zu konfigurieren, und alles war in Ordnung. Aber wie gesagt, wir haben viele Projekte. Sie sind fast alle gleich. Ungefähr solche Systeme sind an jedem Projekt beteiligt (k8s, RabbitMQ, Vault, ELK, PostgreSQL, HAProxy). Für jeden haben wir unsere Rolle geschrieben. Wir können es vom Button rollen.



    Aber wir haben viele Projekte, in denen sie sich im Wesentlichen kreuzen. Das heißt, in einem solchen Satz, im zweiten, im dritten. Wir erhalten den Schnittpunkt, an dem gleiche Rollen in verschiedenen Projekten vorhanden sind.



    Wir haben ein Repository mit der Anwendung, es gibt ein Repository mit der Infrastruktur für das Projekt. Das zweite Projekt ist genau das gleiche. Die Fortsetzung der Infrastruktur. Und der dritte. Wenn wir dasselbe implementieren, erhalten wir tatsächlich Copy-Paste. Wir werden an 10 Stellen dieselbe Rolle spielen. Wenn dann ein Fehler auftritt, werden wir an 10 Stellen regieren.



    Was wir getan haben: Wir haben jede Rolle, die allen Projekten und all ihren Konfigurationen, die von außen kommen, gemeinsam ist, in ein separates Repository gebracht und in einen separaten Daddy einer Gitarre namens TYME Infrastructure gestellt. Dort haben wir eine Rolle für PostgreSQL, für ELK, für die Bereitstellung von Kubernetes-Clustern. Wenn wir dasselbe PostgreSQL in ein Projekt einfügen müssen, aktivieren Sie es einfach als Submodul, schreiben Sie die Bestände um, dh, grob gesagt, die Konfiguration, in der diese Rolle ausgeführt werden soll. Wir schreiben die Rolle selbst nicht neu: Sie existiert bereits. Und auf Knopfdruck erscheint PostgreSQL in allen neuen Projekten. Wenn Sie ein Cluster Kubernetes erhöhen müssen - das gleiche.



    Es stellte sich also heraus, die Kosten für das Schreiben von Rollen zu reduzieren. Das heißt, einmal geschrieben - 10 mal verwendet. Wenn ein Projekt einem Projekt folgt, ist es sehr praktisch. Da wir jetzt mit Infrastruktur wie mit Code arbeiten, brauchen wir natürlich Pipelines, über die wir gesprochen haben. Die Menschen bekennen sich dazu, etwas zu tun, sie können eine Art von Unrichtigkeit begehen - wir müssen den Überblick behalten. Deshalb haben wir eine solche Pipeline gebaut. Das heißt, dass der Entwickler in git Ansible-Skripte festlegt. TeamSity verfolgt sie und sendet sie an Ansible. Teamcity wird hier nur aus einem Grund benötigt: Erstens hat es eine visuelle Schnittstelle (es gibt eine kostenlose Version von Ansible Tower - AWX, die dasselbe Problem löst - ed.) Im Gegensatz zu Ansible free und Teamcity haben wir im Prinzip Teamcity als eine CI. Im Prinzip hat Ansible ein Modul, das git selbst verfolgen kann. Aber in diesem Fall haben sie es nur im Bild und in der Ähnlichkeit getan. Sobald er ihn verfolgt hat, sendet er den gesamten Code an Ansible bzw. Ansible, führt sie auf dem Integrationsserver aus und ändert die Konfiguration. Wenn dieser Prozess verletzt wird, verstehen wir, was falsch ist, warum die Skripts nicht gut geschrieben werden.



    Der zweite Punkt ist, dass es eine spezifische Infrastruktur gibt. Hier haben wir die Infrastrukturaufteilungen getrennt, die Anwendung separat. Es gibt jedoch für jede Anwendung eine spezifische Infrastruktur, das heißt, sie muss bereitgestellt werden, bevor wir sie starten. Hier ist es jeweils nicht möglich, in eine andere Pipeline zu gelangen. Sie sollten dies in demselben Container bereitgestellt haben wie die Anwendung selbst. Das heißt, Frameworks sind beispielsweise eine beliebte Angelegenheit, wenn Sie ein Framework für eine neue Anwendung und ein anderes für ein anderes Framework installieren müssen. Hier ist wie mit dieser Situation. Entweder müssen die Caches gereinigt werden. Zum Beispiel kann Ansible auch klettern, den Cache leeren.



    Aber hier verwenden wir Docker in Kombination mit Ansible. Das heißt, die spezifische Infrastruktur, in der wir uns in Andock befinden, ist in Ansible nicht spezifisch. Und so teilen wir sozusagen dieses kleine Delta im Docker, alles andere, das Fundamentale - in Ansible.



    Ein sehr wichtiger Punkt ist, dass wenn Sie die Infrastruktur durch einige Skripts durch Code rollen und Sie dann noch manuelle Manipulationen mit Servern vornehmen, dies eine potenzielle Sicherheitsanfälligkeit darstellt. Angenommen, Sie haben Java auf den Testserver gestellt, die ELK-Rolle geschrieben und gewalzt. Depla war im Test erfolgreich. Bereitstellen in der Produktion, aber es gibt kein Java. Und Sie haben im Skript kein Java angegeben - es wurde in Produktion genommen. Daher müssen Sie die Rechte von allen Servern von Administratoren erhalten, damit diese nicht dorthin klettern und alle Änderungen über git vornehmen. Diesen ganzen Förderer haben wir selbst bestanden. Eines ist hier - die Schrauben müssen nicht festgezogen werden. Das heißt, es ist notwendig, einen solchen Prozess schrittweise einzuführen. Weil es noch undatiert ist. In unserem Fall haben wir bei unvorhergesehenen Vorfällen den Zugriff auf alle Systeme bei der wichtigsten Administrationsleiterin gelassen.



    Wie läuft die Entwicklung? Rollout in Staging, Produktion sollte fehlerfrei sein. Wir können etwas kaputt machen. Wenn der Rollout in der Integrationsumgebung ständig auf Fehler stößt, ist dies schlecht. Dies ist wie das Debuggen von Anwendungen auf einem Remote-Computer. Wenn ein Entwickler zuerst alles auf der Maschine entwickelt, kompiliert. Wenn alles kompiliert wird, wird an das Repository gesendet. Es verwendet den gleichen Ansatz. Entwickler verwenden Visual Studio Code mit den Plug-Ins Ansible, Vagrant, Docker usw. Entwickler testen ihren Infrastrukturcode auf einem lokalen Landstreicher. Dort entsteht ein sauberes Betriebssystem. In diesem Repository befinden sich auch die Skripts selbst, um diese Maschine zu installieren. Die Infrastruktur, über die wir gesprochen haben, ist ebenfalls vorhanden. Der Entwickler beginnt mit der Installation eines FTP-Servers. Wenn etwas schief geht, wird es einfach gelöscht, neu geladen, und versuchen Sie erneut, die erforderliche Software mithilfe von Implementierungsskripts zu installieren. Nach dem Debuggen von Implementierungsskripts wird eine Zusammenführungsanforderung an den Hauptzweig gesendet. Nach der Zusammenführung der Zusammenführungsanforderung führt CI diese Änderungen auf dem Integrationsserver aus.



    Da alle Skripts Code sind, können wir Tests schreiben. Angenommen, wir haben PostgreSQL installiert. Wir wollen überprüfen, ob es funktioniert oder nicht. Hierzu verwenden wir das Modul Ansible assert. Vergleichen Sie die installierte Version von PostgreSQL mit der Version in den Skripts. Wir wissen also, dass es installiert ist, es läuft im Allgemeinen, es ist die Version, die wir erwartet haben.



    Wir sehen, dass der Test bestanden hat. Unser Spielbuch hat also richtig funktioniert. Sie können so viele Tests schreiben, wie Sie möchten. Sie sind idempotent. Idempotenz (Vorgang, der bei mehrmaliger Anwendung eines Werts immer den gleichen Wert wie in einer einzelnen Anwendung ergibt). Wenn Sie das richtige Skript für die Installation und Konfiguration schreiben, stellen Sie sicher, dass Ihre Skripts immer den gleichen Wert erhalten, wenn Sie sie mehrmals ausführen.



    Es gibt eine andere Art von Tests, die sich nicht direkt auf die Testinfrastruktur bezieht. Aber sie scheinen ihn indirekt zu beeinflussen. Dies sind End-to-End-Tests. Unsere Infrastruktur und die Anwendungen selbst werden auf dem Server installiert, den die Tester testen. Wenn wir eine falsche Infrastruktur aufgerollt haben, werden wir einfach keine komplexen Tests bestehen. Das heißt, unsere Anwendung wird irgendwie fehlerhaft arbeiten. In diesem Beispiel haben wir eine neue Version in der Produktion installiert - die Anwendung läuft. Dann wurden Commits für die Git-und Ende-zu-Ende-Tests, die in der Nacht stattfinden, gemacht, um zu verfolgen, dass hier keine FTP-Datei vorhanden ist. Wir analysieren diesen Fall und sehen, dass das Problem in den FTP-Einstellungen liegt. Wir korrigieren die Skripts im Code, setzen sie erneut ein und alles wird grün. Gleiche Geschichte mit Code. Infrastrukturcode und Infrastruktur werden auf die eine oder andere Weise indirekt getestet. Wir können es dann in der Produktion einsetzen.



    Als wir diesen Ansatz implementierten, fiel CI (Teamcity), das die Änderungen auf dem Integrationsserver einführte, achtmal aus zehn Punkten heraus. Niemand hat darauf geachtet, da es keine Rückmeldungen gab. Für Entwickler wurden diese Prozesse vor langer Zeit eingeführt, und Nachrichten erreichten nicht die OPS (Systemadministratoren). Daher haben wir ein Dashboard mit Baugruppen dieses Projekts zu einem großen Monitor an der prominentesten Stelle im Büro hinzugefügt. Dabei werden verschiedene Projekte grün hervorgehoben - das bedeutet, dass bei ihm alles in Ordnung ist. Wenn rot hervorgehobenEs bedeutet, dass mit ihm alles schlecht ist. Wir sehen, dass einige Tests fehlgeschlagen sind. Bei der Präsentation auf der linken Seite der Sekunde von oben sehen wir das Ergebnis der Infrastruktur-bereitstellbaren Aufgaben. Infrastruktur bereitstellen, grün. Dies bedeutet, dass alle Tests bestanden wurden, dass keine Fehler vorhanden waren und sie erfolgreich gesammelt wurden. Warnung: Angenommen, ein IT-Profi hat ein Skript gestartet und ist gegangen. Wenn kommit alles kaputt gemacht hat. Er erhält im Slack-Kanal eine Warnung, dass ein solcher IT-Spezialist unser Projekt mit einem solchen Engagement gebrochen hat.



    Ok, wir haben gerade darüber gesprochen, wie wir uns entwickeln, wie wir Testumgebungen festlegen und wie wir es allgemein für andere Umgebungen einführen. Wir verwenden den trunk-basierten Ansatz. Daher ist hier der Master-Zweig der Hauptentwicklungszweig. Wenn Sie sich für den Master festlegen, werden die Änderungen vom CI-Serverzweig (Teamcity) auf den Integrationsserver übertragen. Wenn die Task auf dem CI-Server grün ist, schreiben wir Testern, dass wir das Produkt auf dem Integrationsserver testen können. Wir bilden einen Freisetzungskandidaten. Auf dem Testserver wird diese Konfiguration angezeigt. Die Tester können die Anwendungen selbst testen. Wenn alles in Ordnung ist und die End-to-End-Tests bestanden sind, können wir die Konfiguration selbst und die Anwendung bereits für die Staging-Umgebung bereitstellen. Dann können wir zur Produktion rollen. Durch solche mehrstufigen Barrieren erreichen wir, dass die Inszenierungsumgebung immer grün ist.



    Vergleichen wir die Verwaltung der Infrastruktur anhand des Codes und stellen Sie die Infrastruktur von Hand ein Was für eine Wirtschaft? Diese Grafik zeigt, wie wir PostgreSQL installiert haben. Das Infrastrukturmanagement aus dem Code erwies sich früh als 5-mal teurer. Alle Skripte müssen in otaladit-Händen geschrieben werden. Dies dauert 1-2 Stunden. Im Laufe der Zeit können Sie diese Skripts schreiben. Vergleichen wir die Installation und Konfiguration der PostgreSQL-Hände und -Stunden mithilfe des Bereitstellungsskripts. Da die Implementierungsskripts und PostgreSQL-Einstellungen bereits geschrieben wurden, dauert es 4 Minuten, bis die Produktion abgeschlossen ist. Je mehr Umgebungen, desto mehr Maschinen, desto mehr gewinnen Sie beim Aufbau der Infrastruktur an Arbeitskosten. Wenn Sie ein Projekt und eine Datenbank haben, ist es für Sie günstiger, dies von Hand zu tun. Das heißt, es ist nur interessant, wenn Sie große Projekte haben.



    Wir haben ein Git-Submodul implementiert, mit dem wir die Rolle Ansible mehrmals verwenden können. Wir müssen kein zweites Mal schreiben, es ist bereits da. Wir fügen ein Git-Submodul mit der Ansible-Rolle hinzu, die wir dem Projekt hinzufügen. Wir schreiben in die Bestände des Servers, wo die Rolle nachkommt. Es dauert 30 Minuten. Im Falle der Verwendung von git submodul hat der Aufwand zum Schreiben von Implementierungsskripts die manuellen Vorgänge bei weitem übertroffen.



    Zur Medienidentität: Ich bin nicht bereit zu sagen, wie viele Fehler wir zuvor gemacht haben und wie viel später entstanden ist. Aber ich möchte sagen, dass wir, obwohl wir alle Regeln beachtet haben, über die wir heute gesprochen haben, das Staging genauso konfiguriert haben wie der Test. Denn wenn der Test auseinander fällt, zerstören wir das Auto, versuchen es neu zu konfigurieren, und nur wenn es grün wird, wird das Ganze inszeniert. Wie viele Fehler Ihr Team mit Ihren Händen macht - Sie können selbst nachdenken, berechnen, jeder hat eine bestimmte Schwelle.



    Die Grafik zeigt die Ergebnisse für 6 Monate. Arbeit - die Komplexität einer 10-Punkte-Skala. In den ersten zwei Monaten haben wir diese Rollen nur sehr schmerzhaft und lange geschrieben. Weil es ein neues System war. Als wir sie geschrieben haben, ist der Zeitplan gesunken. Irgendwo in der Mitte wurde git submodule eingeführt, als wir bereits die Rollen geschrieben hatten, um verschiedene Projekte wiederzuverwenden. Dies führte zu einem starken Rückgang der Lohnkosten. Wenn wir es mit der manuellen Anpassung des Projekts vergleichen, für das diese Beurteilung vorgenommen wurde, haben wir drei Tage von Hand festgelegt, wobei der Infrastrukturansatz als Code verwendet wird, der für etwa einen Monat festgelegt wurde. In Zukunft ist die Verwendung der Infrastruktur als Code effizienter als das manuelle Einrichten von Servern.



    Schlussfolgerungen.


    Zuerst haben wir die Dokumentation bekommen, das heißt, als der Manager hereinkommt und mich fragt: Auf welchen Port hört die Datenbank zu, öffne ich das Ansible-Skript im git-Repository und sage: "Schauen Sie sich diesen und den Port an". Was sind unsere Einstellungen hier? All dies ist im git-Repository zu sehen. Es kann geprüft werden, Managern gezeigt werden und so weiter. Dies ist 100% zuverlässige Informationen. Die Dokumentation wird obsolet. Und in diesem Fall nichts veraltet.


    Der wichtige Punkt, über den wir nicht gesprochen haben. Über ihn indirekt sagen. Es gibt Entwicklungsteams, die RabbitMQ, ELK auch lokal erhöhen müssen, um verschiedene Ideen zu testen. Wenn sie es mit ihren Händen tun, kann das Heben von ELK mehr als eine Stunde dauern. Wenn der Infrastrukturansatz als Code verwendet wird, hebt der Entwickler die virtuelle Maschine an, drückt die Taste und installiert ELK. Wenn der Entwickler ELK gebrochen hat, kann er die ELK-Installation erneut auf der virtuellen Maschine ausführen.


    Wie gesagt, das ist nur dann günstiger, wenn Sie viele Projekte oder Umgebungen oder viele Autos haben. Wenn Sie dies nicht haben, ist es dementsprechend nicht billiger, es ist teurer. Aus unserer Sicht stellte sich bei unseren Projekten heraus, dass es mit der Zeit günstiger wird. Daher gibt es sowohl Vor- als auch Nachteile.


    Schnelle Notfallwiederherstellung. Wenn Sie fallen, müssen Sie nach einer Person suchen, die diese Maschine einrichten kann, die weiß, wie sie eingerichtet wird, und sich daran erinnert, wie sie eingerichtet werden muss. In diesem Fall sind alle Einstellungen und Implementierungsskripts in git. Auch wenn eine Person gekündigt hat, in ein anderes Projekt umgezogen ist - alles ist in Arsch, alles steht in den Kommentaren, alles ist klar: Warum hat er einen solchen Hafen geöffnet, warum hat er solche Einstellungen gemacht und so weiter. Sie können alles problemlos wiederherstellen.


    Die Anzahl der Fehler nahm ab, da wir unterschiedliche Barrieren hatten, lokale Tracking-Umgebungen, Entwicklung und Code-Überprüfung. Dies ist auch wichtig, da die Entwickler genau sehen, was sie tun. So lernen sie immer noch weiter. Die Komplexität hat zugenommen, weil es sich dementsprechend um ein neues System handelt, dies sind Pipelines, die Menschen müssen geschult werden. Daran gewöhnten sie sich nicht: Sie lasen den Artikel und machten es unter dem Artikel. Hier ist etwas mehr. Im Laufe der Zeit ist es jedoch leicht zu meistern. Wenn Sie die Entwicklung vollständig betrachten, werden es etwa drei oder vier Monate sein.


    Die Frage wird durch die Anwendung gestellt, aber die Frage wird nicht gehört.


    Antwort: Rollen, für die wir die neueste Version verwenden, dh die Rolle wird in einem separaten git-Submodul nur dann zugewiesen, wenn sie für alle Systeme eindeutig ist. Wenn dabei Commits aufgetreten sind, gehen wir zum neuesten Commit. Und die gesamte Konfiguration stammt aus Lagerbeständen. Das heißt, die Rolle ist genau das, was ausgeführt wird. Datenbankname, Login, Passwort usw. kommt nach draußen Eine Rolle ist einfach ein ausführbarer Algorithmus. Alle Konfigurationen stammen aus dem Projekt selbst.


    Frage: Wenn Sie transitive Abhängigkeiten zwischen den Ansible-Rollen haben und wie werden Sie herausgezogen, wenn die Anwendung bereitgestellt wird (Rolle A hängt von B ab, B hängt von C ab und wenn Sie Rolle A ausrollen, sodass die Abhängigkeit immer größer wird). Welches Werkzeug haben Sie, wenn Sie eines haben?


    Antwort: In diesem Paradigma gibt es keine derartigen Abhängigkeiten. Wir haben Konfigurationsabhängigkeiten. Das heißt, wir haben ein System installiert und kennen die IP-Adressen der Server, und gleichzeitig gibt es einen Balancer, der inzwischen geworden ist, sich sozusagen selbst anzutreiben, um diesen abgestimmten Rechner zu balancieren. Dies liegt daran, dass die Configs aufgelöst werden. Wenn Sie jedoch von Modulen abhängig sind, gibt es hier nichts, wir haben eines frei, es hängt nicht von irgendetwas ab, es ist autark. Und wir setzen nicht in allgemeine Rollen, was zumindest eine Art nicht-allgemeiner Struktur hat, das heißt, RabbitMQ kann auch in RabbitMQ in Afrika sein, es hängt nicht von irgendetwas ab. Wir behalten einige Besonderheiten im Docker, während wir die gleichen Rahmenbedingungen speichern.


    PS Ich schlage vor, dass alle, die sich für github interessieren, interessante Berichte von Konferenzen in den Text übersetzen. Sie können in github eine Gruppe für die Übersetzung erstellen. Bisher übersetze ich meinen github-Account in Text - dort können Sie auch eine Pull-Anfrage senden, um den Artikel zu korrigieren.


    Jetzt auch beliebt: