Ich habe 3 Umgebungen, jede in ihrem eigenen virtuellen Netzwerk mit ihren eigenen Konfigurationen. Muss ich 3 separate Instanzen von Jenkins haben, um fortlaufende Bereitstellungen in jeder der Umgebungen durchführen zu können? Was sind einige bewährte Methoden für die Neubewertung der Bereitstellung in einer Architektur mit mehreren Umgebungen?
Antworten:
Dies ist eine sehr gute Frage, da es ein gängiges Anti-Pattern ist, ci/cdTools mit Umgebungen zu koppeln .
Jenkins ist eine Fabrik. Als solches sollte es völlig unabhängig vom Begriff der Umwelt oder sogar der Lieferung sein.
Am besten ist es, einen Staging-Prozess und / oder eine Schnittstelle zu haben (wenn Sie es sich leisten können: eine dedizierte Bereitstellungssoftware).
Sie sollten versuchen, für jede Umgebung eine Art Staging-Job zu erstellen, in dem Sie die Konfiguration der Umgebung definieren und das endgültige Paket damit bündeln.
Als nächstes haben Sie Lieferaufträge für jede Umgebung.
Um die Inszenierung und Lieferaufträge zu tun erstellen, können Sie sehr einfach Scripting - Tools verwenden, wie shell, aber es gibt mehr angepasst Scripting - Tools, wie Ansible, puppet, chef...
Wenn Sie sich die Kosten leisten können, können Sie in eine Bereitstellungssoftware investieren (ich werde einige erwähnen, mit denen ich im Kommentarbereich gearbeitet habe).
Beachten Sie, dass diese Software einen Staging-Prozess für die Umgebung verwaltet.
Offensichtlich ist es sehr sinnvoll, Bereitstellungssoftware und Skripte zu kombinieren.
Da Sie nach Best Practices gefragt haben, scheint es mir erwähnenswert, ein anderes häufig vorkommendes Anti-Pattern zu erwähnen: die Kopplung von SCM-Tools und den Bereitstellungsprozess.
Es ist eine sehr gute Praxis, die Umgebungskonfiguration (natürlich keine Passwörter oder vertraulichen Informationen) zu speichern und Live-Skripte in SCM-Tools (wie svnoder git...) zu erstellen. Es ist jedoch eine sehr schlechte Praxis, die Umgebungskonfiguration auszuchecken und Live-Skripte während des Go-Live zu erstellen. Es ist möglicherweise einfach nicht verfügbar, wenn Sie es benötigen.
Diese Check-out-Phase sollte Teil des zuvor erwähnten Staging-Prozesses sein.
Eine weitere bewährte Methode besteht darin, dass Ihre Skripte wie folgt lauten sollten idem-potent: Dies bedeutet, dass Sie Ihre Skripte einmal abspielen können sollten, um die Bereitstellung und Bereitstellung durchzuführen. Dann sollten Sie in der Lage sein, sie immer wieder abzuspielen, und sie würden den Status Ihres Systems nur ändern, wenn etwas in der Konfiguration gestört ist.
Als letzte bewährte Methode, die ich aus direkter Erfahrung heraus teilen werde, ist das Schrecken von Jenkins: Verschiedene Teams haben unterschiedliche Bedürfnisse und Verwendungszwecke von Jenkins. Wenn sich zu viele Teams einen gemeinsamen Jenkins teilen, kann es zu Problemen mit den Ressourcen kommen. Der schlimmste Fall ist, wenn ein Team den Jenkins-Master neu starten muss, während ein anderes liefern muss.
Ideal wäre es, einen Jenkins pro Team oder pro Gruppe von Teams zu haben, die dasselbe Ziel und dieselbe Lieferplanung haben.
Ich bin gerade von Jenkins Freestyle-Jobs und einem separaten Job für jede Umgebung auf die Verwendung von Jenkins-Pipelines (deklarative Syntax) übergegangen.
In Jenkins-Pipelines haben wir eine einzelne Datei (Jenkinsfile) und definieren verschiedene Phasen für unsere verschiedenen Umgebungen (Dev / Staging / Prod). In diesen Phasen definieren wir nur unterschiedliche Verhaltensweisen für jede Umgebung. In unserer Phase "Bereitstellen" werden wir beispielsweise in einem anderen Kubernetes-Namespace / -Cluster bereitstellen, je nachdem, ob es sich um die Entwicklungs- oder Staging-Umgebung handelt.
Ich mag diesen Ansatz, da Sie nur eine Jenkins-Datei pro Projekt haben, die in allen Zweigen vorhanden ist.
Die kurze Antwort auf Ihre Frage lautet nein. Jenkins muss nicht mit Ihren Produktionsumgebungen sprechen, kann es aber, wenn Sie es brauchen. Mit anderen Worten, wenn Jenkins diese Umgebungen erreichen kann, kann er wahrscheinlich mit ihnen interagieren.
Ausgehend von einem Best-Practice-Ansatz empfehle ich normalerweise die Verwendung von Software, die Ihre Bereitstellung so einfach und wiederholbar wie möglich macht (z. B. make, Ansible, Terraform, Cloud Formation oder Kubernetes).
Pipelines können parallele Ziele verarbeiten, sodass Sie bei Bedarf alle drei Umgebungen gleichzeitig erstellen und bereitstellen können.
Möglicherweise möchten Sie Ihre Frage präziser oder detaillierter gestalten, um mehr Feedback zu erhalten.
Wir können eine einzelne Jenkins-Datei für verschiedene Umgebungen verwenden. Wir brauchen jedoch etwas, um zwischen dieser Umgebung zu unterscheiden. Möglicherweise handelt es sich um eine Umgebungsvariable oder einen Parameter in einem parametrisierten Job, um zu steuern, was in jeder Umgebung zu tun ist. Möglicherweise möchten wir e2e erstellen, testen, ausführen und das Image in ein Repository in einer Umgebung übertragen. Verwenden Sie dann dasselbe Image und stellen Sie es im nächsten bereit (möglicherweise Staging) und führen Sie einen Rauchtest durch. Verwenden Sie dann dasselbe Image für die Bereitstellung in der Produktion.