Hier is een voorstel voor een GitLab CI pipeline die progressive delivery strategieën, zoals canary releases, implementeert voor jouw Kubernetes-productieomgeving, met minimale downtime en automatische rollback bij failure: stages: - build - test - deploy variables: KUBE_CONFIG: "/path/to/kubeconfig" # Pas dit aan naar jouw configuratie IMAGE_TAG: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" build: stage: build image: node:14 script: - npm install - npm run build - docker build -t $IMAGE_TAG . - docker push $IMAGE_TAG only: - main test: stage: test image: node:14 script: - npm test only: - main deploy_staging: stage: deploy image: bitnami/kubectl:latest script: - kubectl --kubeconfig=$KUBE_CONFIG apply -f k8s/staging-deployment.yaml environment: name: staging only: - main # Canary release naar productie deploy_production_canary: stage: deploy image: bitnami/kubectl:latest script: - | # Update de deployment met nieuwe image voor canary kubectl --kubeconfig=$KUBE_CONFIG set image deployment/your-deployment your-container=$IMAGE_TAG --record # Zorg dat de canary-replicas slechts een percentage van de totale replicas zijn kubectl --kubeconfig=$KUBE_CONFIG scale deployment/your-deployment --replicas=10 # Wacht en monitor de canary ./monitor_canary.sh environment: name: production url: https://jouw-website.com only: - main when: manual # Handmatige trigger voor canary, kan geautomatiseerd worden # Volledige rollout na succesvolle canary deploy_production_full: stage: deploy image: bitnami/kubectl:latest script: - # Verhoog de replicas naar normaal - kubectl --kubeconfig=$KUBE_CONFIG scale deployment/your-deployment --replicas=100 environment: name: production url: https://jouw-website.com only: - main when: on_success # Rollback bij detectie van problemen rollback: stage: deploy image: bitnami/kubectl:latest script: - # Rollback naar vorige deployment - kubectl --kubeconfig=$KUBE_CONFIG rollout undo deployment/your-deployment environment: name: production when: manual only: - main # Monitoring script (monitor_canary.sh) # Dit script controleert de health van de canary deployment en stopt of voert rollback uit bij problemen. # Notities: # - Pas 'your-deployment' en 'your-container' aan naar jouw deployment- en containernaam. # - Zorg dat je monitor_canary.sh script alerting en health checks bevat. # - Gebruik labels, readiness probes, en metrics om de gezondheid te beoordelen. # - Overweeg automatische rollback via monitoring tools of scripts op basis van health data. Met deze configuratie implementeer je een canary release strategie waarbij je eerst een kleine subset van gebruikers (bijvoorbeeld 10 replicas) de nieuwe versie laat zien. Na monitoring en bevestiging wordt de volledige rollout uitgevoerd. Bij problemen kun je handmatig of automatisch rollbacken. Dit minimaliseert downtime en vermindert risico's.

Hier is een verbeterde GitLab CI-configuratie die canary releases implementeert voor progressive delivery: ```yaml stages: - build - test - deploy-staging - deploy-canary - deploy-production - rollback variables: KUBE_NAMESPACE: "production" CANARY_PERCENTAGE: "10" CANARY_DURATION: "15m" build: stage: build script: - npm install - npm run build artifacts: paths: - build/ expire_in: 1 hour test: stage: test script: - npm test dependencies: - build deploy-staging: stage: deploy-staging script: - echo "Deploying to staging environment" - kubectl apply -f k8s/staging-deployment.yaml - kubectl apply -f k8s/staging-service.yaml - ./scripts/wait-for-ready.sh --namespace staging --timeout 300s - ./scripts/run-staging-tests.sh environment: name: staging only: - main deploy-canary: stage: deploy-canary script: - echo "Deploying canary release (${CANARY_PERCENTAGE}% traffic)" - kubectl apply -f k8s/canary-deployment.yaml - ./scripts/configure-traffic-split.sh --canary-percentage ${CANARY_PERCENTAGE} - ./scripts/wait-for-ready.sh --namespace ${KUBE_NAMESPACE} --timeout 300s - echo "Monitoring canary for ${CANARY_DURATION}" - sleep 900 # 15 minuten monitoring periode - ./scripts/check-metrics.sh --namespace ${KUBE_NAMESPACE} --duration ${CANARY_DURATION} environment: name: production/canary only: - main dependencies: - deploy-staging deploy-production: stage: deploy-production script: - echo "Promoting canary to full production" - ./scripts/promote-canary.sh --namespace ${KUBE_NAMESPACE} - ./scripts/wait-for-ready.sh --namespace ${KUBE_NAMESPACE} --timeout 300s - echo "Full deployment completed successfully" environment: name: production only: - main dependencies: - deploy-canary when: on_success rollback: stage: rollback script: - echo "Automatische rollback uitgevoerd wegens falende canary" - ./scripts/rollback-deployment.sh --namespace ${KUBE_NAMESPACE} - ./scripts/wait-for-ready.sh --namespace ${KUBE_NAMESPACE} --timeout 300s - echo "Rollback voltooid - vorige stabiele versie is actief" environment: name: production only: - main dependencies: - deploy-canary when: on_failure ``` **Benodigde aanvullende scripts:** 1. **traffic-split.sh** (gebruikt Istio/Service Mesh): ```bash #!/bin/bash # Configureert traffic splitting voor canary release kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - my-app.production.svc.cluster.local http: - route: - destination: host: my-app subset: stable weight: 90 - destination: host: my-app subset: canary weight: 10 EOF ``` 2. **check-metrics.sh**: ```bash #!/bin/bash # Controleert metrische gegevens voor canary gezondheid ERROR_RATE=$(kubectl get --raw /apis/metrics.k8s.io/v1beta1/... | jq '.items[] | select(.metadata.name=="my-app")') if [ "$ERROR_RATE" -gt "5" ]; then echo "Canary health check failed - error rate too high" exit 1 fi ``` 3. **promote-canary.sh**: ```bash #!/bin/bash # Promoveert canary naar 100% traffic kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - my-app.production.svc.cluster.local http: - route: - destination: host: my-app subset: canary weight: 100 EOF ``` **Belangrijkste kenmerken:** - Gefaseerde deployment via staging → canary → production - Automatische rollback bij falende canary - Configuratie van traffic percentage voor canary release - Health monitoring tijdens canary fase - Minimale downtime door geleidelijke traffic shifting Zorg ervoor dat je de benodigde Kubernetes manifests en Service Mesh configuratie (Istio/Linkerd) hebt geïmplementeerd voor traffic splitting.