Yazılım Mimarisi Deployment - Canlıya Geçirme - Rolling Deployment - Eski Sistem Yavaş Yavaş Kapatılır

Giriş

Açıklaması şöyle

The rolling deployment strategy is the default strategy by Kubernetes that slowly replaces the old pods of the previous version with the pods of the new version. 

Şeklen şöyle

Eski sistemler teker teker kapatılır

Blue sayısı kadar green servis çalıştırılır. İşini bitiren blue servisler teker teker kapatılır. Bunun adımları şöyle. Burada önemli olan blue servisin işlemi bitirdiğini anlayabilmek. Eğer green yani yeni sistemde problem varsa blue sistem kapatılmadığı için rollback edilebilir. Buna aynı zamanda "Rolling Upgrade" de veya "Rolled Updates" deniliyor.

- Standing up a matching number of “green” instances of your microservice that contain the change that you wish to deploy.

- Once you’re happy that those green instances are healthy, adding them into the load balancer so that they receive traffic.

- Removing the blue instances from the load balancer, and once they have finished processing any inflight requests, throwing them away.

Açıklaması şöyle

1. Start a new already upgraded server (server 3).

2. move server 1 clients to server 3.

3. Upgrade server 1

4. Move server 2 clients to server 1.

5. Delete server 2 as you now have servers 1 and 3 running the upgraded software?

Rolling Deployment için açıklama şöyle

 A Rolling deployment deploys progressively with automated validation and health checks in each step. In a rolling deployment model, the new application services are added to the shared load balancer and the traffic will start to be shared between the old and new applications. Automated validation in each new replica helps determine if the release is still on track or if rollback is necessary.

Canary Deployment - Canlıya Geçirme - Yükün Belli Bir Yüzdesi Yeni Sisteme Verilir

Giriş

Açıklaması şöyle.  İki farklı deployment yan yana çalışır. Yükün belli bir yüzdesi yeni sisteme verilir

Canary deployment strategy is used to carry out A/B testing and dark launches. It is similar to the blue-green approach but more controlled. We will see slow-moving traffic from version A to version B in this strategy. Think: canary in the coal mine!

Yüzde ile ilgili açıklam şöyle. 

Finally, in a Canary deployment, a new application replica is added to the load balancer, and the load balancer is configured to pass only a specific percentage of the application traffic to the new replica. Once configured, a full analysis of the traffic volume, response times, or activity on the replica is performed. If the analysis is successful, this deployment generally continues as a Rolling deployment.

Örnek

Şöyle yaparız. Tek path var. 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sample-api-ing
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1 
spec:
  rules:
    - host: sample-api.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: sample-api-svc
                port:
                  number: 8080

Service şöyledir. Bu service Ingress tarafından kullanıldığı için type ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: sample-api-svc
  namespace: default
  labels:
    app: sample-api
spec:
  type: ClusterIP         <----
  selector:
    app: sample-api
  ports:
  - port: 8080
    name: "http"
    protocol: TCP

Birinci deployment şöyle. Bu deployment .net ile gerçekleştiriliyor.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api-app              <----
  namespace: default
spec:
  replicas: 4                       <----
  selector:
    matchLabels:
      app: sample-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 20%
  template:
    metadata:
      labels:
        version: "netcore6"         <----
        app: sample-api
    spec:
      containers:
      - name:  sample-api
        image: localhost:5000/sample-api-netcore
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        env:
        - name: ASPNETCORE_URLS 
          value: http://*:8080

İkinci deployment şöyle. Bu deployment GoLang ile gerçekleştiriliyor.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api-canary-app         <----
  namespace: default
spec:
  replicas: 1                         <----
  selector:
    matchLabels:
      app: sample-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 20%
  template:
    metadata:
      labels:
        version: "golang"             <----
        app: sample-api
    spec:
      containers:
      - name:  sample-api
        image: localhost:5000/sample-api-golang
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

Böylece iki farklı deployment yan yana çalışıyor.

Yazılım Mimarisi Deployment - Canlıya Geçirme Blue/Green Deployment - İki Sistem Yanyanadır, Yük Yenisine Aktarılır

Giriş

Hem microservice hem de monolith ile kullanılabilir. Açıklaması şöyle. Mevcut sisteme blue denilir. Yeni sisteme de green. 

Blue Green deployments (2010) predates cloud computing (2013), microservice architectures (2014) and cloud native software patterns (2019)

Her iki sistem de yan yana kuruludur. Açıklaması şöyle. 

In a blue-green technique, both blue and green versions get deployed simultaneously, but only one version will be active and live at a time. Let’s consider blue as the old version and green as the new version. So, all the traffic is sent to blue by default at first, and if the latest version (green) meets all the requirements, then the old version traffic is diverted to the new version (from blue to green). 

Blue/Green deployment'ı active/passive olarak anlayanlar da var. Açıklaması şöyle. Ama bence bu doğru terminoloji değil.

Blue/Green deployment refers to a software technique which can be used to reduce system downtime by deploying two mirrored production environments, referred to as blue (active) and green (idle). One of the environments is running in production while the other is in active standby.

The Jet client can be configured to switch to the other cluster in case when a connection to the production environment fails.

Downtime Gerektirmeyen Yöntem

Yeni sistem kurulur ve açılır. Her şey tam olarak çalıştıktan sonra load-balancer ayarları değiştirilerek akış yeni sisteme yönlendirilir. Eğer sorun yoksa mavi sistem kaldırılır. 

Downtime Gerektiren Yöntem - Recreate

Bu yöntemde bir miktar downtime olabilir, çünkü mavi sistemi tam olarak tüm işlemlerin bittiği noktada kapatmak mümkün değil dolayısıyla önce sistem ara bir state'e geçiriliyor. Açıklaması şöyle. 

It’s not always possible to have your “green” stack 100% ready to serve customers at the point at which you disconnect “blue”. What if blue is writing state to the database that green will need in order to process subsequent requests? For applications where some downtime is required between the start and end of the cutover, we introduce a third state; some sort of “we’re down for maintenance” stub that can respond to customers gracefully whilst we make the final updates necessary to green. Then, once green is ready, we flip the load balancer back over to the green stack and away we go again.

Downtime Gerektirmeyen Yöntem

Kubernetes ortamında sadece servis'i yeni pod'a yönlendirerek yapılıyor.

Argo Rollouts

İlk defa burada gördüm.  Blue/Green veya Canary Deployment işini kolaylaştıran bir Custom Resource Definition (CRD)

Örnek - Bu Örnek Çok İyi Değil

blue.yaml şöyle olsun. Burada deployment version 1.0 kullanıyor. Service için önemli olan şey selector alanı. "version : 1.0" olmalı

aapiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app: app
      version: "1.0"
  replicas: 2
  template:
    metadata:
      labels:
        app: app
        version: "1.0"
    spec:
      containers:
      - name: service
        image: pkw0301/app:1.0
        imagePullPolicy: Always
        ports:
        - containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  type: LoadBalancer
  ports:
  - name: http
    protocol: TCP
    port: 5000
    targetPort: 5000
  selector:
    app:  app
    version: "1.0"

green.yaml şöyle olsun. Deployment ismi aynı. Burada image ismi değişiyor. Ayrıca LoadBalancer service version 2.0 olan pod'lara yönlendiriliyor

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app: app
      version: "2.0"
  replicas: 2
  template:
    metadata:
      labels:
        app: app
        version: "2.0"
    spec:
      containers:
      - name: service
        image: pkw0301/app:2.0
        imagePullPolicy: Always
        ports:
        - containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  type: LoadBalancer
  ports:
  - name: http
    protocol: TCP
    port: 5000
    targetPort: 5000
  selector:
    app:  app

Örnek - Bu Daha İyi Bir Örnek

Elimizde version v1.0.0 deployment olsun

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: v1.0.0
  template:
    metadata:
      labels:
        app: my-app
        version: v1.0.0
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9101"
    spec:
      containers:
      - name: my-app
        image: containersol/k8s-deployment-strategies
        ports:
        - name: http
          containerPort: 8080
        - name: probe
          containerPort: 8086
        env:
        - name: VERSION
          value: v1.0.0
        livenessProbe:
          httpGet:
            path: /live
            port: probe
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: probe
          periodSeconds: 5

Service şöyle olsun

apiVersion: v1
kind: Service
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: http
  # Note here that we match both the app and the version
  selector:
    app: my-app
    version: v1.0.0

Yeni deployment için şöyle yaparız. Deployment ismi değiştiriliyor

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: v2.0.0
  template:
    metadata:
      labels:
        app: my-app
        version: v2.0.0
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9101"
    spec:
      containers:
      - name: my-app
        image: containersol/k8s-deployment-strategies
        ports:
        - name: http
          containerPort: 8080
        - name: probe
          containerPort: 8086
        env:
        - name: VERSION
          value: v2.0.0
        livenessProbe:
          httpGet:
            path: /live
            port: probe
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: probe
          periodSeconds: 5

Yeni service için şöyle yaparız

kubectl patch service my-app -p '{"spec":{"selector":{"version":"v2.0.0"}}}'

Eski deployment'ı silmek için şöyle yaparız

kubectl delete deploy my-app-v1

Yazılım Mimarisi Deployment - Canlıya Geçirme

Giriş

Deployment yazılımımızın yeni sürümü hazır ve canlıya geçirmek istiyoruz anlamına geliyor

Continuous Delivery vs Continuous Deployment 

Açıklaması şöyle. Continuous Deployment koddaki değişikliğin hemen canlıya geçirilmesi demek

When someone says CI/CD, the “CD” they’re referring to is usually continuous delivery, not continuous deployment. What’s the difference? In a CI/CD pipeline that uses continuous delivery, automation pauses when developers push to production. A human—your operations, security, or compliance team—still needs to manually sign off before final release, adding more delays. On the other hand, continuous deployment automates the entire release process. Code changes are deployed to customers as soon as they pass all the required tests.

Continuous deployment is the ultimate example of DevOps automation. That doesn’t mean it’s the only way to do CI/CD, or the “right” way. Since continuous deployment relies on rigorous testing tools and a mature testing culture, most software teams start with continuous delivery and integrate more automated testing over time.

Eğer "Continuous Deployment" yoksa önce "Delivery" yapılıyor. Daha sonra elle deployment yapılıyor. Şeklen şöyle

Bir başka şekil şöyle

Continuous Deployment İçin Yöntemler

Belli başlı yöntemler şöyle. Bu yöntemler Downtime gerektirmiyorlar.

Rolling Deployment

Rolling Deployment yazısına taşıdım

Blue/Green Deployment

Blue/Green Deployment yazısına taşıdım

Canary Deployment

Yükün Belli Bir Yüzdesi Yeni Sisteme Verilir. Canary Deployment yazısına taşıdım

Red Black Deployment - Bir Blue/Green Deployment Türevi

Bu yöntemi Netflix kullanıyor. Aslında Downtime gerektirmeyen yöntem ile aynı sadece basit bir kavramsal fark var. Açıklaması şöyle

With Red Black deployments, your existing “red” microservices are running behind the load balancer as before. In order to deploy your change, you stand up new instances of your microservice as more red instances, adding them into the load balancer. Old versions of your instances are then removed from the load balancer; these are the “black” instances, no longer serving traffic but being kept alive so that if anything goes wrong with the new version, they’re ready and waiting to be re-added to the load balancer. Then, once you’re satisfied that the new red instances are performing correctly, the black instances can be destroyed, leaving only the new set of red services containing your latest change.

...

The key difference between Blue Green and Red Black deployments is conceptual, and is in how they describe the point at which both versions of the microservice are running behind the load balancer

...

With Red Black deployments, the services responding to traffic are always red. Red Black focuses on the continuity of service, not the introduction of change.

...

... from an operational perspective, these instances are all the same. Load is being balanced across all of them, all of them need to respond to the same requests from the clients, and no client-facing features in the new version can be leveraged yet as there is no guarantee that a new version of the service will receive the request. It is only after all of the instances of the old version have been removed from the load balancer can any new feature be leveraged by the outside world.

Wicket Deployment Mode

 Wicket Deployment Mode ve ExceptionSettings

Wicket atanan deployment moduna göre yakalanmamış runtime exception'ları işlemektedir.
Eğer deploment mode RuntimeConfigurationType.DEVELOPMENT ise yakalanmamış exceptionlar stack trace bilgisi ile gösteriliyor.

Ancak Eğer deploment mode RuntimeConfigurationType.DEPLOYMENT ise yakalanmamış exceptionların stack trace bilgisi gösterilmiyor.

How can I see stack traces for my Wicket app? başlıklı soruda da cevaplandığı gibi DEPLOYMENT mod ile exceptionları göstermek için uygulamanın ExceptionSettings ayarları değiştirilebilir.

Eğer Wicket filter olarak kullanılıyorsa buradan aldığım şekildeki gibi web.xml dosyasından deployment mod da atanabilir.

Aşağıda bu sınıfın diğer sınıflar ile ilişkisi ve uygulama açılırken nereden okundğunu gösteren bir şekil bulabilirsiniz.