Bij Kinsta hebben we projecten van alle groottes voor Applicatie Hosting, Database Hosting en Managed WordPress Hosting.<\/p>\n
Met de cloudhostingoplossingen van Kinsta kun je applicaties deployen<\/a> in een groot aantal talen en frameworks, zoals NodeJS, PHP, Ruby, Go, Scala en Python. Elke applicatie kun je deployen met een Dockerfile. Je kunt je Git repository (gehost op GitHub, GitLab of Bitbucket) koppelen om je code direct op Kinsta te implementeren.<\/p>\n Je kunt MariaDB, Redis, MySQL en PostgreSQL databases<\/a> out-of-the-box hosten, waardoor je tijd overhoudt om je te richten op het ontwikkelen van je applicaties in plaats van je bezig te houden met hosting configuraties.<\/p>\n En als je kiest voor onze Managed WordPress Hosting<\/a>, ervaar je de kracht van Google Cloud C2 machines op hun Premium Tier netwerk en Cloudflare ge\u00efntegreerde beveiliging, waardoor je WordPress websites de snelste en veiligste op de markt zijn. Een van de grootste uitdagingen bij het ontwikkelen en onderhouden van cloud-native applicaties op bedrijfsniveau is een consistente ervaring gedurende de hele levenscyclus van de ontwikkeling. Dit is nog moeilijker voor bedrijven die op afstand werken met remote teams die werken op verschillende platforms, met verschillende setups en asynchrone communicatie. We moeten dus een consistente, betrouwbare en schaalbare oplossing bieden die werkt voor:<\/p>\n Bij Kinsta vertrouwen we sterk op Docker<\/a> voor deze consistente ervaring bij elke stap, van ontwikkeling tot productie. In dit bericht leiden we je door:<\/p>\n Om een applicatie lokaal te runnen, moeten developers de omgeving minutieus voorbereiden, alle dependencies installeren, servers en services instellen en ervoor zorgen dat ze goed geconfigureerd zijn. Als je meerdere applicaties runt, kan dit lastig zijn, vooral als het gaat om complexe projecten met meerdere dependencies. Als je aan deze variabele ook nog eens meerdere medewerkers met meerdere besturingssystemen toevoegt, ontstaat er chaos. Om dit te voorkomen, gebruiken we Docker.<\/p>\n Met Docker kun je de omgevingsconfiguraties aangeven, de dependencies installeren en images bouwen met alles op de plek waar ze horen. Iedereen, waar dan ook, met welk OS dan ook kan dezelfde images gebruiken en precies dezelfde ervaring hebben als ieder ander.<\/p>\n Om te beginnen maak je een Docker Compose<\/a> bestand, Docker Compose bestanden zijn erg handig als je meer dan \u00e9\u00e9n container hebt draaien en er dependencies zijn die je gebruikt voor meerdere containers.<\/p>\n Om je Als we alles samenbrengen, hebben we een Eerst moeten we een Docker image bouwen met behulp van een Om je Pro Tip: Merk op dat De meeste van onze apps en diensten gebruiken CI\/CD voor de deployment. Docker speelt een belangrijke rol in het proces. Elke wijziging in de main branch activeert onmiddellijk een bouwpipeline via GitHub Actions of CircleCI. De algemene workflow is heel eenvoudig: het installeert de dependencies, voert de tests uit, bouwt het docker image en pusht het naar Google Container Registry (of Artifact Registry). Het deel dat we in dit artikel bespreken is de bouwstap.<\/p>\n We gebruiken builds in meerdere fasen om veiligheids- en prestatieredenen.<\/p>\n In dit stadium kopi\u00ebren we de hele codebase met alle broncode en configuratie, installeren we alle dependencies, inclusief dev dependencies, en bouwen we de app. Er wordt een map De meeste mensen gebruiken dit stadium voor runtime, omdat het heel dicht ligt bij wat we nodig hebben om de app te draaien. We moeten echter nog steeds productie-dependencies installeren en dat betekent dat we footprints achterlaten en de De laatste stap moet zo lean mogelijk zijn met minimale footprints. Dus we kopi\u00ebren simpelweg de app uit productie en gaan verder. We laten alle yarn en Dit is de uiteindelijke Let op dat we voor alle stappen eerst de bestanden Stel dat je iets hebt veranderd in Er zijn verschillende manieren om een Docker image te bouwen in CircleCI pipelines. In ons geval hebben we ervoor gekozen om Dankzij Docker is er een minimale configuratie nodig om onze app te bouwen en te pushen.<\/p>\n Als alternatief voor CircleCI kunnen we GitHub Actions gebruiken om de applicatie continu te deployen. We stellen Bij elke kleine wijziging die naar de main branch wordt gepushed, bouwen en pushen we een nieuwe Docker image naar het register.<\/p>\n Het hebben van kant-en-klare Docker images voor elke wijziging maakt het ook gemakkelijker om te deployen naar productie of terug te rollen als er iets mis gaat. We gebruiken Google Kubernetes Engine om onze apps te beheren en te serveren en gebruiken Google Cloud Deploy en Delivery Pipelines voor ons Continuous Deployment proces.<\/p>\n Wanneer de Docker image is gebouwd na elke kleine wijziging (met de CI pipeline hierboven getoond) gaan we nog een stap verder en deployen we de wijziging naar ons dev cluster met behulp van Dit activeert een releaseproces om de wijzigingen uit te rollen in ons dev Kubernetes cluster. Na het testen en het verkrijgen van de goedkeuringen, promoten we de wijziging naar test en vervolgens productie. Dit is allemaal mogelijk omdat we voor elke wijziging een lean ge\u00efsoleerd Docker image hebben dat bijna alles heeft wat het nodig heeft. We hoeven de deployment alleen maar te vertellen welke tag hij moet gebruiken.<\/p>\n Het QA team heeft meestal een pre-productie cloudversie van de te testen apps nodig. Soms moeten ze echter een vooraf gebouwde app lokaal draaien (met alle dependencies) om een bepaalde feature te testen. In deze gevallen willen of hoeven ze niet al die moeite te doen om het hele project te klonen, npm-pakketten te installeren, de app te bouwen, developersfouten tegen te komen en het hele ontwikkelproces te doorlopen om de app werkend te krijgen. Nu alles al beschikbaar is als Docker image op Google Container Registry, hebben ze alleen nog een service nodig in het Docker compose bestand:<\/p>\n Met deze service kunnen ze de applicatie op hun lokale machines opstarten met Docker containers door deze uit te voeren:<\/p>\n Dit is een enorme stap in het vereenvoudigen van testprocessen. Zelfs als QA besluit om een specifieke tag van de app te testen, kunnen ze eenvoudig de image tag op regel 6 wijzigen en het Docker compose commando opnieuw uitvoeren. Zelfs als ze besluiten om verschillende versies van de app tegelijkertijd te vergelijken, kunnen ze dat eenvoudig bereiken met een paar tweaks. Het grootste voordeel is dat ons QA team niet wordt geconfronteerd met de uitdagingen die developers op moeten lossen.<\/p>\n
\nDe uitdaging van het ontwikkelen van cloud-native applicaties binnen een gedistribueerd team overwinnen<\/h2>\n
\n
\n
Docker Desktop gebruiken om de ervaring voor developers te verbeteren<\/h2>\n
Je configuratie declaren met Docker Compose<\/h2>\n
docker-compose.yml<\/code>. Het is een declaratief configuratiebestand geschreven in YAML format dat Docker vertelt wat de gewenste status van je applicatie is. Docker gebruikt deze informatie om de omgeving voor je applicatie in te stellen.<\/p>\ndocker-compose.yml<\/code> bestand te maken:<\/p>\n\n
image<\/code><\/a> als basis voor onze applicatie. Zoek op Docker Hub en probeer een Docker image te vinden die al de dependencies van je app bevat. Zorg ervoor dat je een specifieke image tag gebruikt om fouten te voorkomen. Het gebruik van de tag latest<\/code> kan onvoorziene fouten in je applicatie veroorzaken. Je kunt meerdere base images gebruiken voor meerdere dependencies. Bijvoorbeeld \u00e9\u00e9n voor PostgreSQL<\/a> en \u00e9\u00e9n voor Redis<\/a>.<\/li>\nvolumes<\/code><\/a> om gegevens op je host te bewaren als dat nodig is. Door gegevens op de hostmachine te bewaren voorkom je dat je gegevens kwijtraakt als docker-containers worden verwijderd of als je ze opnieuw moet maken.<\/li>\nnetworks<\/code><\/a> om je opstelling te isoleren om netwerkconflicten met de host en andere containers te voorkomen. Het helpt je containers ook om elkaar gemakkelijk te vinden en met elkaar te communiceren.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> die er als volgt uitziet:<\/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>\nDe applicatie containeriseren<\/h2>\n
Een Docker image bouwen voor je applicatie<\/h3>\n
Dockerfile<\/code>, en die callen vanuit docker-compose.yml<\/code>.<\/p>\nDockerfile<\/code> bestand te maken:<\/p>\n\n
FROM node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\narm64-based<\/code> processor gebruikt, maar je moet een amd64<\/code> image bouwen. Je kunt dat doen door de -- platform<\/code> op te geven in Dockerfile<\/code>:\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> vanaf docker-compose.yml<\/code>:\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> ook expliciet wordt gemount om platform-specifieke problemen met pakketten te voorkomen. Dit betekent dat in plaats van de node_modules<\/code> op de host te gebruiken, de docker container de zijne gebruikt, maar deze op de host in een apart volume mapt.<\/p>\nIncrementeel de productie-image bouwen met continue integratie<\/h2>\n
De Docker images bouwen<\/h3>\n
Fase 1: Builder<\/h4>\n
dist\/<\/code> aangemaakt en de gebouwde versie van de code wordt daarheen gekopieerd. Maar dit image is veel te groot met een enorme set footprints om te gebruiken voor productie. Omdat we private NPM registries gebruiken, gebruiken we in deze fase ook onze private NPM_TOKEN<\/code>. We willen dus absoluut niet dat deze stap wordt blootgesteld aan de buitenwereld. Het enige dat we nodig hebben van deze stap is de map dist\/<\/code>.<\/p>\nStap 2: Productie<\/h4>\n
NPM_TOKEN<\/code> nodig hebben. Dit stadium is dus nog niet klaar voor gebruik. Let ook op yarn cache clean<\/code> op regel 19. Dat kleine commando vermindert de grootte van onze afbeelding met wel 60%.<\/p>\nFase 3: Runtime<\/h4>\n
NPM_TOKEN<\/code> dingen achter ons en draaien alleen de app.<\/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> en yarn.lock<\/code> kopi\u00ebren, de dependencies installeren en dan de rest van de codebasis kopi\u00ebren. De reden hiervoor is dat Docker elk commando bouwt als een laag bovenop de vorige. En elke build kan de vorige lagen gebruiken als die beschikbaar zijn en alleen de nieuwe lagen bouwen omwille van de prestaties.<\/p>\nsrc\/services\/service1.ts<\/code> zonder de pakketten aan te raken. Dat betekent dat de eerste vier lagen van builder fase onaangeroerd zijn en hergebruikt kunnen worden. Dat maakt het bouwproces ongelooflijk veel sneller.<\/p>\nDe app naar Google Container Registry pushen via CircleCI pipelines<\/h3>\n
circleci\/gcp-gcr orbs<\/code> te gebruiken:<\/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>\nDe app naar Google Container Registry pushen via GitHub acties<\/h3>\n
gcloud<\/code> in en bouwen en pushen de Docker image naar 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>\nWijzigingen deployen naar Google Kubernetes Engine met behulp van Google Delivery pipelines<\/h2>\n
gcloud<\/code>. Laten we eens kijken naar die stap in de 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>\nHoe het Quality Assurance team van dit proces profiteert<\/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>\nVoordelen van het gebruik van Docker<\/h2>\n