CI/CD-Pipeline für die Entwicklung und Bereitstellung containerisierter Anwendungen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Last reviewed 2022-11-18 UTC
In diesem Dokument wird eine integrierte Reihe von Google Cloud-Tools beschrieben, mit denen Sie ein System für die Entwicklung, für Continuous Integration (CI) und für Continuous Delivery (CD) einrichten können, mit denen Sie Anwendungen entwickeln und in Google Kubernetes Engine (GKE) bereitstellen können.
Dieses Referenzarchitekturdokument richtet sich sowohl an Softwareentwickler als auch an Operatoren. Es wird davon ausgegangen, dass Sie mit dem Ausführen von gcloud-Befehlen in Google Cloud und mit dem Bereitstellen von Anwendungscontainern in GKE vertraut sind.
Architektur
Das folgende Diagramm zeigt die in dieser Architektur verwendeten Ressourcen:
Diese Architektur umfasst die folgenden Komponenten:
Cloud Code als Entwicklungsarbeitsbereich
In diesem Arbeitsbereich können Sie Änderungen im Entwicklungscluster ansehen, der in minikube ausgeführt wird.
Sie führen Cloud Code und den minikube-Cluster in Cloud Shell aus.
Cloud Shell ist eine Online-Entwicklungsumgebung, auf die Sie über Ihren Browser zugreifen können. Sie enthält Rechenressourcen, Arbeitsspeicher und eine integrierte Entwicklungsumgebung (IDE) und Cloud Code ist darin installiert.
Cloud Build zum Erstellen und Testen der Anwendung (der "CI"-Teil der Pipeline)
Dieser Teil der Pipeline umfasst die folgenden Aktionen:
Cloud Build überwacht Änderungen am Quell-Repository mithilfe eines Cloud Build-Triggers.
Wenn für eine Änderung ein Commit im Hauptzweig durchgeführt wird, führt der Cloud Build-Trigger folgende Schritte aus:
Erstellt den Anwendungscontainer neu.
Platziert Build-Artefakte in einem Cloud Storage-Bucket.
Platziert den Anwendungscontainer in Artifact Registry.
Führt Tests für den Container aus.
Ruft Cloud Deploy auf, um den Container in der Staging-Umgebung bereitzustellen. In diesem Beispiel ist die Staging-Umgebung ein Google Kubernetes Engine-Cluster.
Wenn der Build und die Tests erfolgreich sind, können Sie den Container mithilfe von Cloud Deploy vom Staging zur Produktion hochstufen.
Cloud Deploy zum Verwalten der Bereitstellung (der "CD"-Teil der Pipeline) In diesem Teil der Pipeline führt Cloud Deploy Folgendes aus:
Erstellt einen Cloud Storage-Bucket und speichert die Skaffold-Rendering-Quelle und die gerenderten Manifeste in diesem Bucket.
Erzeugt für jede Änderung des Quellcodes einen neuen Release.
Stellt die Anwendung in der Produktionsumgebung bereit. Für diese Bereitstellung in der Produktion genehmigt ein Betreiber (oder eine andere dafür bestimmte Person) die Bereitstellung manuell. In dieser Architektur ist die Produktionsumgebung ein Google Kubernetes Engine-Cluster.
In dieser Architektur wird die Konfiguration von den Entwicklungs-, Staging- und Produktionsumgebungen über Skaffold gemeinsam genutzt. Dieses Befehlszeilentool ermöglicht die kontinuierliche Entwicklung für Kubernetes-native Anwendungen.
Google Cloud speichert den Quellcode der Anwendung in GitHub.
In dieser Architektur werden Google Cloud-Produkte für die meisten Komponenten des Systems verwendet, wobei Skaffold die Integration des Systems ermöglicht. Da Skaffold ein Open-Source-Tool ist, können Sie mithilfe dieser Prinzipien ein ähnliches System erstellen. Dazu verwenden Sie eine Kombination aus Google Cloud-, internen und Drittanbieterkomponenten.
Die Modularität dieser Lösung bedeutet, dass Sie sie schrittweise als Teil Ihrer Entwicklungs- und Bereitstellungspipeline übernehmen können.
Anwendungsfälle
Im Folgenden sind die wichtigsten Features dieses integrierten Systems aufgeführt:
Schnelleres Entwickeln und Bereitstellen.
Die Entwicklungsschleife ist effizient, da Sie Änderungen im Entwicklerarbeitsbereich validieren können. Die Bereitstellung ist schnell, da Sie durch das automatisierte CI/CD-System und die erhöhte Parität zwischen den Umgebungen mehr Probleme erkennen, wenn Sie Änderungen in der Produktion bereitstellen.
Sie profitieren von einer höheren Parität bei Entwicklung, Staging und Produktion.
Die Komponenten dieses Systems verwenden einen gemeinsamen Satz von Google Cloud-Tools.
Wiederverwendung von Konfigurationen in verschiedenen Umgebungen.
Die Wiederverwendung erfolgt über Skaffold, das ein gemeinsames Konfigurationsformat für die verschiedenen Umgebungen ermöglicht. Außerdem können Entwickler und Betreiber dieselbe Konfiguration aktualisieren und verwenden.
Governance frühzeitig im Workflow anwenden.
Dieses System wendet Validierungstests für Governance in der Produktion, im CI-System und in der Entwicklungsumgebung an. Wenn Sie die Governance in der Entwicklungsumgebung anwenden, können Probleme früher erkannt und behoben werden.
Lassen Sie Ihre Softwarebereitstellung von speziell darauf ausgerichteten Tools verwalten.
Continuous Delivery ist vollständig verwaltet und trennt die Phasen Ihrer CD-Pipeline von den Details des Renderings und der Bereitstellung.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2022-11-18 (UTC)."],[[["\u003cp\u003eThis architecture uses Google Cloud tools (Cloud Code, Cloud Build, Cloud Deploy) to set up a continuous integration and continuous delivery (CI/CD) system for developing and deploying applications to Google Kubernetes Engine (GKE).\u003c/p\u003e\n"],["\u003cp\u003eCloud Code serves as the development workspace, running in Cloud Shell, where developers can see changes in the minikube development cluster.\u003c/p\u003e\n"],["\u003cp\u003eCloud Build automates building and testing, using triggers to monitor source code changes, rebuild the application container, and run tests before deploying to the staging environment.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy manages the continuous delivery pipeline, registering delivery pipelines and targets, storing Skaffold rendering source and manifests, and deploying the application to production with manual approval.\u003c/p\u003e\n"],["\u003cp\u003eSkaffold facilitates shared configuration across development, staging, and production environments, enabling a common configuration format and allowing for the reuse of configurations.\u003c/p\u003e\n"]]],[],null,["# CI/CD pipeline for developing and delivering containerized apps\n\nThis document describes an integrated set of Google Cloud tools\nto set up a system for development, for continuous integration (CI), and\nfor continuous delivery (CD) that you can use to develop and deploy applications to\n[Google Kubernetes Engine (GKE)](/kubernetes-engine).\nThis reference architecture document is intended for both software developers\nand operators. It assumes that you're familiar with running `gcloud` commands on\nGoogle Cloud and with deploying application containers to\nGKE.\n\nArchitecture\n------------\n\nThe following diagram shows the resources that are used in this architecture:\n\nThis architecture includes the following components:\n\n1. **Cloud Code** as a development workspace. As part of this workspace, you can see changes in the development cluster, which runs on [minikube](https://minikube.sigs.k8s.io/docs/). You run Cloud Code and the minikube cluster in [Cloud Shell](/shell). Cloud Shell is an online development environment accessible from your browser. It has compute resources, memory, an integrated development environment, (IDE), and it also has Cloud Code installed.\n2. **Cloud Build** to build and test the application---the \"CI\"\n part of the pipeline\n\n This part of the pipeline includes the following actions:\n - Cloud Build monitors changes to the source repository, using a Cloud Build trigger.\n - When a change is committed into the main branch, the Cloud Build trigger does the following:\n - Rebuilds the application container.\n - Places build artifacts in a Cloud Storage bucket.\n - Places the application container in Artifact Registry.\n - Runs tests on the container.\n - Calls Cloud Deploy to deploy the container to the staging environment. In this example, the staging environment is a Google Kubernetes Engine cluster.\n - If the build and tests are successful, you can then use Cloud Deploy to promote the container from staging to production.\n3. **Cloud Deploy** to manage the deployment---the \"CD\" part of the\n pipeline. In this part of the pipeline, Cloud Deploy does the\n following:\n\n - Registers a [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) and [targets](/deploy/docs/terminology#target). The targets represent the staging and production clusters.\n - Creates a Cloud Storage bucket and stores the Skaffold rendering source and rendered manifests in that bucket.\n - Generates a new [release](/deploy/docs/terminology#release) for each source code change.\n - Deploys the application to the production environment. For this deployment to production, an operator (or other designated person) manually approves the deployment. In this architecture, the production environment is a Google Kubernetes Engine cluster.\n\nIn this architecture, configuration is shared among the development, staging,\nand production environments through\n[Skaffold](https://skaffold.dev/),\na command-line tool that facilitates continuous development\nfor Kubernetes-native applications.\n\nGoogle Cloud stores the application's source code in GitHub.\n\nThis architecture uses Google Cloud products for most of the components of\nthe system, with Skaffold enabling the integration of the system. Because\nSkaffold is open source, you can use these principles to create a similar system\nusing a combination of Google Cloud, in-house, and third-party components.\nThe modularity of this solution means that you can adopt it incrementally\nas part of your development and deployment pipeline.\n\nUse cases\n---------\n\nThe following are the key features of this integrated system:\n\n- **Develop and deploy faster**.\n\n The development loop is efficient because you can validate\n changes in the developer workspace. Deployment is fast because the\n automated CI/CD system and increased parity across the environments allow you\n to detect more issues when you deploy changes to production.\n- **Benefit from increased parity** across development, staging, and production.\n\n The components of this system use a common set of Google Cloud tools.\n- **Reuse configurations** across the different environments.\n\n This reuse is done with [Skaffold](https://skaffold.dev/),\n which allows a common configuration format for the different environments. It\n also allows developers and operators to update and use the same configuration.\n- **Apply governance** early in the workflow.\n\n This system applies validation tests for governance at production and in the\n CI system and development environment. Applying governance in the development\n environment allows problems to be found and fixed earlier.\n- Let **opinionated tooling** manage your software delivery.\n\n Continuous delivery is fully managed, separating the stages of your CD\n pipeline from the details of rendering and deploying.\n\nDeployment\n----------\n\nTo deploy this architecture, see\n[Develop and deploy containerized apps using a CI/CD pipeline](/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke/deployment).\n\nWhat's next\n-----------\n\n- To learn how to deploy into a private GKE instance, see [Deploying to a private cluster on a Virtual Private Cloud network](/deploy/docs/execution-environment#deploying_to_a_private_cluster_on_a_network).\n- For information about how to implement, improve, and measure deployment automation, see [Deployment automation](https://dora.dev/devops-capabilities/technical/deployment-automation/)."]]
