Wenn Sie mit Ihrem Team an Code arbeiten, tauchen immer wieder die gleichen Probleme auf. Sich wiederholende, zeitaufwändige Tests und das Zusammenführen von Codes können zu chaotischen Bereitstellungen führen und nehmen viel Zeit in Kauf. Es gibt jedoch einen DevOps-Trend, der sich immer größerer Beliebtheit erfreut, weil er die Workflows der Entwickler vereinfacht: Continuous Integration/Continuous Deployment (CI/CD).

CI/CD ist eine automatisierte Bereitstellungspipeline, die unter anderem automatisierte Tests ermöglicht und das Zusammenführen von Codes vereinfacht. Sie können Ihre CI/CD-Einstellungen sogar so konfigurieren, dass der bereitgestellte Code mit Ihren zuvor festgelegten Anwendungsstandards übereinstimmt. Am Ende können Sie und Ihre Teams kleine Teile des Codes schnell bereitstellen, um Ihr Projekt effizient voranzubringen.

Sie möchten ein CI/CD testen, bevor Sie es in Ihrer Produktionsumgebung einsetzen? Wir haben ein Tutorial zusammengestellt, wie Sie es mit GitLab CI/CD und Docker ganz einfach ausprobieren können.

GitLab CI/CD ist ein gängiges Tool zur Erstellung einer CI/CD-Pipeline. Es ermöglicht das automatische Erstellen, Testen, Bereitstellen und Monitoring von Anwendungen mit Auto DevOps. Wir haben Docker verwendet, weil es eine der ersten und beliebtesten Plattformen für die Containerisierung ist. Das ist zu einem großen Teil auf die Portabilität von Docker zurückzuführen. Erfahren Sie hier, wie Sie eine CI/CD-Pipeline mit Docker und Instances erstellen können:

Eine GitLab CI/CD mit Docker erstellen

GitLab-Benutzer können mithilfe der GitLab InstantApp eine Instance mit nur wenigen Klicks einrichten.

  1. Installieren Sie den GitLab-Server.
  2. Installieren Sie einen oder mehrere GitLab-Runner und integrieren Sie die Konfigurationsdatei(en).
  3. Ein Runner ist eine Anwendung, die Aufgaben innerhalb der CI/CD-Pipeline von GitLab ausführt, sich im Docker-Container befindet und so den Erstellungsprozess von der Ausführungsumgebung isoliert.
  4. Es empfiehlt sich, den GitLab-Runner auf einem anderen Rechner zu installieren als die GitLab-Instance. Denn wenn Sie den Runner und die Instance getrennt voneinander installieren, erhalten Sie eine bessere Leistung und Sicherheit.
  5. Sie können, wenn Sie möchten, auf jeder Instance unterschiedliche Betriebssysteme und Tools verwenden.
  6. Sobald Ihr GitLab-Runner mit seiner Konfigurationsdatei (gitlab.toml) bereitgestellt wurde, können die CI/CD-Aufgaben diesen nun verwenden.
  7. Zudem kann die Bereitstellung des Runner als Container diesen Prozess vereinfachen.
  8. Anschließend fügen Sie dem Repository Ihrer Anwendung eine .gitlab-ci.yml-Datei hinzu, die den Quellcode enthält.
  9. Die .gitlab-ci.yml-Datei ist eine Konfigurationsdatei, die den zu verwendenden GitLab-Runner und die Schritte der CI/CD-Pipeline (Erstellen, Testen, Bereitstellen in Staging, Bereitstellen in Produktion) beschreibt.
  10. Legen Sie die gewünschten Tests fest, die Ihr Code durchlaufen soll, bevor die CD ihn in Ihre Produktionsumgebung überträgt. In jedem Schritt der CI/CD-Pipeline können verschiedene Aufgaben gleichzeitig ausgeführt werden - eine sehr praktische Funktion für Tests.
  11. Ihr CI/CD ist einsatzbereit!

Was Sie nach der Erstellung Ihrer CI/CD-Pipeline erwartet

Jedes Mal, wenn ein Benutzer Veränderungen im GitLab-Repository vornimmt, führt GitLab Ihre neue CI/CD-Pipeline mit dem GitLab-Runner auf der Instance, auf der der Runner installiert ist, aus.

  • Das Ausführungsprogramm des Runner verarbeitet die Befehle in Docker-Containern.
  • Der Runner führt die Pipeline, die Sie mit der .gitlab-ci.yml-Datei konfiguriert haben, aus. Das CI/CD hat in der Regel eine Phase, in der ein Docker Image mit Ihrer Anwendung erstellt und anschließend in ein Docker-Registry verschoben wird. In diesem Fall wird das Image in das GitLab-Registry Ihres Projekts auf Ihrem GitLab-Server verschoben.
  • In einem weiteren Schritt Ihrer CI/CD wird dieses Image für die automatisierte oder manuelle Bereitstellung in der Umgebung Ihrer Wahl verwendet.

PLAY2: Eine Sandbox-Umgebung für sorgenfreies Ausprobieren

Sie möchten eine CI/CD-Pipeline ausprobieren, aber haben Bedenken bei der direkten Bereitstellung in Ihrer Produktionsumgebung?

Eine Sandbox-Umgebung ist eine isolierte virtuelle Maschine, die Ihre Produktionsumgebung imitiert und Ihnen das Risiko nimmt, dass Ihr Experiment schief gehen könnte. Scaleway hat gerade die neuen PLAY2 Instances mit Funktionen, die insbesondere für Entwickler zur Erstellung einer Sandbox-Umgebung ausgelegt sind, eingeführt.

PLAY2 wurde bewusst als eine kleinere und preiswertere Version einer Produktionsumgebung konzipiert. Deshalb ist die Bereitstellung und Skalierung einer Anwendung von der PLAY2 Entwicklungsumgebung auf eine PRO2 Produktionsumgebung einfach und gewährleistet vollständige Kompatibilität.

Zudem ist PLAY2 mit einer unserer neuesten Funktionen, Boot-on-Block, kompatibel. Boot-on-Block ermöglicht es Ihnen, Block-Volumen zu jeder Zeit und zu jeder Instance hinzuzufügen und ist 2-3 mal so schnell wie ein lokaler Speicher. Zudem werden Ihre Daten automatisch auf drei verschiedene Server dupliziert, wodurch versehentliche Datenverluste verhindert werden.

PLAY2 bietet nicht nur Schnelligkeit und Flexibilität, sondern auch auf die Kunden abstimmbare Optionen, sodass Sie eine zu Ihrer Produktionsumgebung vergleichbare Sandbox-Umgebung erstellen können.

Mit diesen Vorkonfigurationen für Hardware, OS Images und InstantApps (einschließlich GitLab und Docker) können Sie Ihre Experimente freigeben, ohne lange mit weiteren Konfigurationen tüfteln zu müssen.

Und wenn Sie sich davon überzeugt haben, dass Ihr CI/CD wie gewünscht funktioniert - also keine lästigen, mühsamen Tests mehr nötig sind - können Sie einen weiteren Schritt in die Pipeline einfügen und so Ihre Anwendung - genau wie in der Sandbox - in Ihrer Produktionsumgebung bereitstellen.

Was sind die technischen Details?

Auch wenn die PLAY2 Instances so konzipiert wurden, dass Entwickler mit ihnen ausprobieren können, haben wir nicht bei der Leistung gespart. Die PLAY2 Instances basieren auf den neuesten AMD EPYC™ 7003-Serie Prozessoren und die verfügbaren Konfigurationen reichen von 1 vCPU bis 4 vCPU mit 2 GB RAM pro vCPU.

Zudem  haben wir das beste Preis-Leistungs-Verhältnis auf dem Markt. Ab 10 Euro pro Monat oder 0,014 Euro pro Stunde ist unser PLAY2-Angebot bis zu 60 Prozent günstiger als ähnliche Dienste von marktführenden Anbietern.

Sind Sie bereit für Experimente mit den neuesten Lösungen und Upgrades, die Sie in Ihre professionellen Projekte einbinden können? Stellen Sie hier Ihre erste PLAY2 Instance bereit.