Bei Kinsta haben wir Projekte aller Gr\u00f6\u00dfenordnungen f\u00fcr Anwendungs-Hosting, Datenbank-Hosting und Managed WordPress Hosting.<\/p>\n
Mit den Cloud-Hosting-L\u00f6sungen von Kinsta kannst du Anwendungen in einer Reihe von Sprachen und Frameworks wie NodeJS, PHP, Ruby, Go, Scala und Python bereitstellen<\/a>. Mit einem Dockerfile kannst du jede Anwendung bereitstellen. Du kannst dein Git-Repository (gehostet auf GitHub, GitLab oder Bitbucket) verbinden, um deinen Code direkt auf Kinsta bereitzustellen.<\/p>\n Du kannst MariaDB-, Redis-, MySQL- und PostgreSQL-Datenbanken<\/a> out-of-the-box hosten. So hast du Zeit, dich auf die Entwicklung deiner Anwendungen zu konzentrieren, anstatt dich mit Hosting-Konfigurationen herumzuschlagen.<\/p>\n Und wenn du dich f\u00fcr unser Managed WordPress Hosting<\/a> entscheidest, profitierst du von der Leistung der Google Cloud C2-Maschinen in ihrem Premium-Tier-Netzwerk und der in Cloudflare integrierten Sicherheit, die deine WordPress-Websites zu den schnellsten und sichersten auf dem Markt macht. Eine der gr\u00f6\u00dften Herausforderungen bei der Entwicklung und Wartung von Cloud-nativen Anwendungen auf Unternehmensebene ist eine konsistente Erfahrung w\u00e4hrend des gesamten Entwicklungslebenszyklus. Dies ist noch schwieriger f\u00fcr Unternehmen mit verteilten Teams, die auf verschiedenen Plattformen, mit unterschiedlichen Setups und asynchroner Kommunikation arbeiten. Wir m\u00fcssen eine konsistente, zuverl\u00e4ssige und skalierbare L\u00f6sung anbieten, die f\u00fcr alle funktioniert:<\/p>\n Bei Kinsta verlassen wir uns stark auf Docker<\/a>, um bei jedem Schritt, von der Entwicklung bis zur Produktion, eine einheitliche Erfahrung zu gew\u00e4hrleisten. In diesem Beitrag f\u00fchren wir dich durch:<\/p>\n Um eine Anwendung lokal auszuf\u00fchren, m\u00fcssen Entwickler\/innen die Umgebung sorgf\u00e4ltig vorbereiten, alle Abh\u00e4ngigkeiten installieren, Server und Dienste einrichten und sicherstellen, dass sie richtig konfiguriert sind. Wenn du mehrere Anwendungen betreibst, kann das m\u00fchsam sein, vor allem wenn es sich um komplexe Projekte mit vielen Abh\u00e4ngigkeiten handelt. Wenn du zu dieser Variable noch mehrere Mitwirkende mit verschiedenen Betriebssystemen hinzuf\u00fcgst, ist das Chaos vorprogrammiert. Um das zu verhindern, verwenden wir Docker.<\/p>\n Mit Docker kannst du die Umgebungskonfigurationen deklarieren, die Abh\u00e4ngigkeiten installieren und Images bauen, bei denen alles da ist, wo es sein soll. Jeder, \u00fcberall, mit jedem Betriebssystem kann die gleichen Images verwenden und genau die gleiche Erfahrung machen wie alle anderen.<\/p>\n Um loszulegen, erstellst du eine Docker Compose<\/a>-Datei, Docker Compose-Dateien sind sehr n\u00fctzlich, wenn du mehr als einen Container laufen hast und es Abh\u00e4ngigkeiten zwischen den Containern gibt.<\/p>\n So erstellst du deine Wenn du alles zusammen nimmst, sieht Zuerst m\u00fcssen wir mit So erstellst du deine Profi-Tipp: Beachte, dass Die meisten unserer Anwendungen und Dienste nutzen CI\/CD f\u00fcr die Bereitstellung. Docker spielt bei diesem Prozess eine wichtige Rolle. Jede \u00c4nderung im Hauptzweig l\u00f6st sofort eine Build-Pipeline aus, entweder \u00fcber GitHub Actions oder CircleCI. Der allgemeine Arbeitsablauf ist sehr einfach: Er installiert die Abh\u00e4ngigkeiten, f\u00fchrt die Tests durch, erstellt das Docker-Image und stellt es in der Google Container Registry (oder Artifact Registry) bereit. Der Teil, den wir in diesem Artikel besprechen, ist der Build-Schritt.<\/p>\n Wir verwenden aus Sicherheits- und Leistungsgr\u00fcnden mehrstufige Builds.<\/p>\n In dieser Phase kopieren wir die gesamte Codebasis mit allen Quellen und Konfigurationen, installieren alle Abh\u00e4ngigkeiten, einschlie\u00dflich der Dev-Abh\u00e4ngigkeiten, und bauen die App. Es wird ein Ordner Die meisten Leute verwenden diese Stufe f\u00fcr die Runtime, da sie sehr nah an dem ist, was wir f\u00fcr den Betrieb der Anwendung brauchen. Allerdings m\u00fcssen wir noch die Abh\u00e4ngigkeiten f\u00fcr die Produktion installieren, was bedeutet, dass wir Fu\u00dfspuren hinterlassen und den Die letzte Phase soll so schlank wie m\u00f6glich sein und m\u00f6glichst wenig Speicherplatz beanspruchen. Also kopieren wir einfach die fertige Anwendung aus der Produktion und machen weiter. Wir lassen den ganzen Kram mit Garn und Dies ist die endg\u00fcltige Beachte, dass wir in allen Phasen zuerst die Dateien Nehmen wir an, du hast etwas in Es gibt mehrere M\u00f6glichkeiten, ein Docker-Image in CircleCI-Pipelines zu erstellen. In unserem Fall haben wir uns f\u00fcr Dank Docker ist nur eine minimale Konfiguration erforderlich, um unsere Anwendung zu erstellen und zu pushen.<\/p>\n Als Alternative zu CircleCI k\u00f6nnen wir GitHub Actions verwenden, um die Anwendung kontinuierlich zu verteilen. Wir richten Bei jeder kleinen \u00c4nderung, die wir am Hauptzweig vornehmen, bauen wir ein neues Docker-Image und pushen es in die Registry.<\/p>\n Fertige Docker-Images f\u00fcr jede einzelne \u00c4nderung zu haben, macht es auch einfacher, sie in die Produktion zu \u00fcberf\u00fchren oder ein Rollback durchzuf\u00fchren, falls etwas schief geht. Wir verwenden Google Kubernetes Engine f\u00fcr die Verwaltung und Bereitstellung unserer Anwendungen und nutzen Google Cloud Deploy und Delivery Pipelines f\u00fcr unseren kontinuierlichen Bereitstellungsprozess.<\/p>\n Wenn das Docker-Image nach jeder kleinen \u00c4nderung erstellt ist (mit der oben gezeigten CI-Pipeline), gehen wir einen Schritt weiter und stellen die \u00c4nderung mit Dadurch wird ein Release-Prozess ausgel\u00f6st, um die \u00c4nderungen in unserem Dev-Kubernetes-Cluster auszurollen. Nachdem wir die \u00c4nderungen getestet und genehmigt haben, \u00fcbertragen wir sie ins Staging und dann in die Produktion. Das alles ist m\u00f6glich, weil wir f\u00fcr jede \u00c4nderung ein schlankes, isoliertes Docker-Image haben, das fast alles enth\u00e4lt, was es braucht. Wir m\u00fcssen dem Deployment nur mitteilen, welches Tag es verwenden soll.<\/p>\n Das QA-Team ben\u00f6tigt meistens eine Vorproduktions-Cloud-Version der zu testenden Anwendungen. Manchmal muss es jedoch eine vorgefertigte Anwendung (mit allen Abh\u00e4ngigkeiten) lokal ausf\u00fchren, um eine bestimmte Funktion zu testen. In diesen F\u00e4llen wollen oder m\u00fcssen sie sich nicht die M\u00fche machen, das gesamte Projekt zu klonen, npm-Pakete zu installieren, die Anwendung zu bauen, mit Entwicklerfehlern zu k\u00e4mpfen und den gesamten Entwicklungsprozess durchzugehen, um die Anwendung zum Laufen zu bringen. Jetzt, wo alles bereits als Docker-Image in der Google Container Registry verf\u00fcgbar ist, brauchen sie nur noch einen Dienst in der Docker Compose-Datei:<\/p>\n Mit diesem Dienst k\u00f6nnen sie die Anwendung auf ihren lokalen Rechnern mit Docker-Containern zum Laufen bringen, indem sie ihn ausf\u00fchren:<\/p>\n Dies ist ein gro\u00dfer Schritt zur Vereinfachung der Testprozesse. Selbst wenn die QA beschlie\u00dft, ein bestimmtes Tag der Anwendung zu testen, kann sie das Image-Tag in Zeile 6 einfach \u00e4ndern und den Docker Compose-Befehl erneut ausf\u00fchren. Selbst wenn sie beschlie\u00dfen, verschiedene Versionen der Anwendung gleichzeitig zu vergleichen, k\u00f6nnen sie das mit ein paar \u00c4nderungen leicht erreichen. Der gr\u00f6\u00dfte Vorteil ist, dass unser QA-Team nicht mit den Herausforderungen der Entwickler konfrontiert wird.<\/p>\n
\n\u00dcberwindung der Herausforderung, Cloud-native Anwendungen in einem verteilten Team zu entwickeln<\/h2>\n
\n
\n
Die Verwendung von Docker Desktop zur Verbesserung der Entwicklererfahrung<\/h2>\n
Deklariere deine Konfiguration mit Docker Compose<\/h2>\n
docker-compose.yml<\/code>. Das ist eine deklarative Konfigurationsdatei im YAML-Format, die Docker mitteilt, wie der gew\u00fcnschte Zustand deiner Anwendung aussieht. Docker nutzt diese Informationen, um die Umgebung f\u00fcr deine Anwendung einzurichten.<\/p>\ndocker-compose.yml<\/code> Datei:<\/p>\n\n
image<\/code><\/a> als Basis f\u00fcr unsere Anwendung. Suche im Docker Hub nach einem Docker-Image, das bereits die Abh\u00e4ngigkeiten deiner Anwendung enth\u00e4lt. Achte darauf, dass du einen bestimmten Image-Tag verwendest, um Fehler zu vermeiden. Die Verwendung des Tags latest<\/code> kann zu unvorhergesehenen Fehlern in deiner Anwendung f\u00fchren. Du kannst mehrere Basis-Images f\u00fcr verschiedene Abh\u00e4ngigkeiten verwenden. Zum Beispiel eines f\u00fcr PostgreSQL<\/a> und eines f\u00fcr Redis<\/a>.<\/li>\nvolumes<\/code><\/a> um Daten auf deinem Host zu persistieren, wenn du sie brauchst. Das Persistieren von Daten auf dem Host-Rechner hilft dir, Datenverluste zu vermeiden, wenn Docker-Container gel\u00f6scht werden oder du sie neu erstellen musst.<\/li>\nnetworks<\/code><\/a> um dein Setup zu isolieren, um Netzwerkkonflikte mit dem Host und anderen Containern zu vermeiden. Au\u00dferdem hilft es deinen Containern, einander leicht zu finden und miteinander zu kommunizieren.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> wie folgt aus:<\/p>\nversion: '3.8'services:\n db:\n image: postgres:14.7-alpine3.17\n hostname: mk_db\n restart: on-failure\n ports:\n - ${DB_PORT:-5432}:5432\n volumes:\n - db_data:\/var\/lib\/postgresql\/data\n environment:\n POSTGRES_USER: ${DB_USER:-user}\n POSTGRES_PASSWORD: ${DB_PASSWORD:-password}\n POSTGRES_DB: ${DB_NAME:-main}\n networks:\n - mk_network\n redis:\n image: redis:6.2.11-alpine3.17\n hostname: mk_redis\n restart: on-failure\n ports:\n - ${REDIS_PORT:-6379}:6379\n networks:\n - mk_network\n \nvolumes:\n db_data:\n\nnetworks:\n mk_network:\n name: mk_network<\/code><\/pre>\nContainerisierung der Anwendung<\/h2>\n
Erstelle ein Docker-Image f\u00fcr deine Anwendung<\/h3>\n
Dockerfile<\/code> ein Docker-Image erstellen und dieses dann von docker-compose.yml<\/code> aus aufrufen.<\/p>\nDockerfile<\/code> Datei:<\/p>\n\n
FROM node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\narm64-based<\/code> Prozessor verwendest, aber ein amd64<\/code> Image erstellen musst. Du kannst das tun, indem du -- platform<\/code> in Dockerfile<\/code> angibst:\nFROM --platform=amd64 node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . .<\/code><\/pre>\n<\/li>\nDockerfile<\/code> von docker-compose.yml<\/code> aus auf:\nservices:\n ...redis\n ...db\n \n app:\n build:\n context: .\n dockerfile: Dockerfile\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\n<\/li>\nservices:\n ... redis\n ... db\n \n build-docker:\n image: myapp\n build:\n context: .\n dockerfile: Dockerfile\n app:\n image: myapp\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n volumes:\n - .:\/opt\/app\n - node_modules:\/opt\/app\/node_modules\n networks:\n - mk_network\n depends_on:\n - redis\n - db\n - build-docker\n \nvolumes:\n node_modules:<\/code><\/pre>\n<\/li>\n<\/ol>\nnode_modules<\/code> auch explizit gemountet wird, um plattformspezifische Probleme mit Paketen zu vermeiden. Das bedeutet, dass der Docker-Container statt der node_modules<\/code> auf dem Host seine eigene verwendet, diese aber auf dem Host in einem separaten Volume abbildet.<\/p>\nInkrementelle Erstellung der Produktions-Images mit Continuous Integration<\/h2>\n
Erstellen der Docker-Images<\/h3>\n
Stufe 1: Builder<\/h4>\n
dist\/<\/code> erstellt und die gebaute Version des Codes dorthin kopiert. Dieses Abbild ist jedoch viel zu gro\u00df und enth\u00e4lt zu viele Fu\u00dfabdr\u00fccke, um f\u00fcr die Produktion verwendet zu werden. Da wir private NPM-Registries nutzen, verwenden wir in dieser Phase auch unsere private NPM_TOKEN<\/code>. Wir wollen also auf keinen Fall, dass diese Phase f\u00fcr die Au\u00dfenwelt sichtbar ist. Das Einzige, was wir in dieser Phase brauchen, ist der Ordner dist\/<\/code>.<\/p>\nStufe 2: Produktion<\/h4>\n
NPM_TOKEN<\/code> ben\u00f6tigen. Diese Stufe ist also noch nicht bereit, um ver\u00f6ffentlicht zu werden. Achte auch auf yarn cache clean<\/code> in Zeile 19. Dieser winzige Befehl reduziert unsere Bildgr\u00f6\u00dfe um bis zu 60%.<\/p>\nStufe 3: Laufzeit<\/h4>\n
NPM_TOKEN<\/code> hinter uns und f\u00fchren nur noch die Anwendung aus.<\/p>\nDockerfile.production<\/code>:<\/p>\n# Stage 1: build the source code \nFROM node:18.15.0-alpine3.17 as builder \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . . \nRUN yarn build \n\n# Stage 2: copy the built version and build the production dependencies FROM node:18.15.0-alpine3.17 as production \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install --production && yarn cache clean \nCOPY --from=builder \/opt\/app\/dist\/ .\/dist\/ \n\n# Stage 3: copy the production ready app to runtime \nFROM node:18.15.0-alpine3.17 as runtime \nWORKDIR \/opt\/app \nCOPY --from=production \/opt\/app\/ . \nCMD [\"yarn\", \"start\"]<\/code><\/pre>\npackage.json<\/code> und yarn.lock<\/code> kopieren, die Abh\u00e4ngigkeiten installieren und dann den Rest der Codebasis kopieren. Der Grund daf\u00fcr ist, dass Docker jeden Befehl als eine Schicht \u00fcber der vorherigen baut. Und jeder Build kann die vorherigen Layer verwenden, wenn sie verf\u00fcgbar sind, und nur die neuen Layer aus Leistungsgr\u00fcnden bauen.<\/p>\nsrc\/services\/service1.ts<\/code> ge\u00e4ndert, ohne die Pakete zu ver\u00e4ndern. Das bedeutet, dass die ersten vier Schichten der Builder-Stufe unangetastet bleiben und wiederverwendet werden k\u00f6nnen. Das macht den Build-Prozess unglaublich schnell.<\/p>\nDie Anwendung \u00fcber CircleCI Pipelines in die Google Container Registry pushen<\/h3>\n
circleci\/gcp-gcr orbs<\/code> entschieden:<\/p>\nexecutors:\n docker-executor:\n docker:\n - image: cimg\/base:2023.03\norbs:\n gcp-gcr: circleci\/gcp-gcr@0.15.1\njobs:\n ...\n deploy:\n description: Build & push image to Google Artifact Registry\n executor: docker-executor\n steps:\n ...\n - gcp-gcr\/build-image:\n image: my-app\n dockerfile: Dockerfile.production\n tag: ${CIRCLE_SHA1:0:7},latest\n - gcp-gcr\/push-image:\n image: my-app\n tag: ${CIRCLE_SHA1:0:7},latest<\/code><\/pre>\nDie Anwendung \u00fcber GitHub-Aktionen in die Google Container Registry pushen<\/h3>\n
gcloud<\/code> ein und bauen und pushen das Docker-Image auf gcr.io<\/code>:<\/p>\njobs:\n setup-build:\n name: Setup, Build\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions\/checkout@v3\n\n - name: Get Image Tag\n run: |\n echo \"TAG=$(git rev-parse --short HEAD)\" >> $GITHUB_ENV\n\n - uses: google-github-actions\/setup-gcloud@master\n with:\n service_account_key: ${{ secrets.GCP_SA_KEY }}\n project_id: ${{ secrets.GCP_PROJECT_ID }}\n\n - run: |-\n gcloud --quiet auth configure-docker\n\n - name: Build\n run: |-\n docker build \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\" \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\" \n .\n\n - name: Push\n run: |-\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\"\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\"<\/code><\/pre>\nBereitstellung von \u00c4nderungen an die Google Kubernetes Engine mithilfe der Google Delivery Pipelines<\/h2>\n
gcloud<\/code> auf unserem Dev-Cluster bereit. Werfen wir einen Blick auf diesen Schritt in der CircleCI-Pipeline:<\/p>\n- run:\n name: Create new release\n command: gcloud deploy releases create release-${CIRCLE_SHA1:0:7} --delivery-pipeline my-del-pipeline --region $REGION --annotations commitId=$CIRCLE_SHA1 --images my-app=gcr.io\/${PROJECT_ID}\/my-app:${CIRCLE_SHA1:0:7}<\/code><\/pre>\nWie das Qualit\u00e4tssicherungs-Team von diesem Prozess profitiert<\/h2>\n
services:\n ...redis\n ...db\n \n app:\n image: gcr.io\/${PROJECT_ID}\/my-app:latest\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n environment:\n - NODE_ENV=production\n - REDIS_URL=redis:\/\/redis:6379\n - DATABASE_URL=postgresql:\/\/${DB_USER:-user}:${DB_PASSWORD:-password}@db:5432\/main\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\ndocker compose up<\/code><\/pre>\nVorteile der Verwendung von Docker<\/h2>\n