deployment strategies · 2017-03-17 · Deployment vs. Integration • integration, deployment,...

Deployment Strategies

Ben Kimim

• Aybars Badur

• Evli, 2 cocuk babasi

• Backend Lead @adphorus

• aybars.badur@gmail.com

• twitter: @aybarsbadur

deployment nedir ?

Kullanıcılarınıza/müşterilerinize iyi kalitede yazılımları ulaştırmak için yaptığınız süreçlerin tümü

Strateji nedir ?önceden belirlenen bir amaca ulaşmak için tutulan yolların ve uygulanan

yöntemlerin tümü. synonyms: master plan, game plan...

Deployment vs. Integration• integration, deployment, delivery… aşağı yukarı

aynı şeyler

• ürettiğiniz bir yazılımı, var olan bir codebase e entegre ediyorsanız, Integration

• son kullanıcıya müşteriye ulaştırıyorsanız, Delivery / deployment

• bunları otomatize ediyorsanız, continous delivery, continous integration, continous deployment…

Delivery PipelineToyota production line

Delivery Pipelinecheckout code > test > deploy to staging > test ….

Reliability

• Güvenilirlik

• “Paranoyaklar uzun yaşar” şeklinde özetleyebileceğimiz çalışmaların tümü

• single point of failures lardan kaçınmak

• Riski dağıtmak

Reliability

• Tek sunucu kabustur

• diskler patlayabilir - daha fazla disk ekle

• işlemci yanabilir - ek işlemci ekle

• anakart patlayabilir ?

• daha fazla sunucu ekle

Reliability• tek datacenter problemlidir

• fırtınalar, depremler…

• tek servis sağlayıcı sorunludur

• dyn dns servisi ddos a uğradı, twitter a ulaşılamadı

• dünyanın en büyük dns sağlayıcısı

Reliability• failover, sharding, partitioning, clustering

• failover: eğer biri patlarsa diğerine geç.

• sharding/partitioning: bazı veriler bir sunucuda, bazıları diğerinde. uygulamanız hangisinde olduğunu bilir.

• clustering: partitioning le aynı şey ama her node diğerinden haberdardır.

• replication: bir sunucudaki verinin kopyası diğer sunucudadır.

Failover

• Failover on loadbalancer

• Failover over ip (using virtual ip)

• DNS failover

• Failover with task queue/workers

Failover

• Failover on loadbalancer

• Hosted load balancer (ELB) failover

• hardware load balancer (F5)

Failover

• Failover over ip (using virtual ip)

• keepalived, corosync …

• bazı servis sağlayıcıları bunu direk sunuyor (örn. Hetzner virtual ip )

Failover

• DNS Failover

• active/passive, active/active

• active/passive: bazı ipler sadece standby durumunda

• AWS Route53 çok ucuza sağlıyor

Failover• Task Queue / Pub-Sub / Message Bus

• app sunucu uygulamasi dummy olur, geleni kuyruga (kafka, rabbitmq etc.) atar

• kuyruk isi yapar cevabini datastore a yazar (redis, memcache)

• app sunucu cevabi kullaniciya gonderir

• celery, kuyruk, activemq …

Routing• bazı istekleri bir sunucuya, diğerlerini öteki sunucuya

yönlendir

• Routing algorithms

• Roundrobin

• Weighted round robin

• least connected

• sticky (on session cookie, ip_hash)

Deploy

• this page intentionally left blank

Deploy

• Deploy to PAAS

• bir platform as a service kullanın

• Heroku

• git push heroku master

Deploy

• Going serverless

• sunucu kullanmazsanız, sunucu problemi yaşamazsınız.

• eg: use S3 for static files

• look for Heroku, AWS Lambda etc.

Deploy• Tek sunucuya deploy

• git pull origin master

• sudo service myapplication restart

• (yada sudo supervisorctl restart all)

• derin bir nefes alır ve şanslı gününde olduğunu umarsın

Tek sunucuya deploy• graceful restart

• yeni child processes ateşle

• smoke test yap - eg: did they spawn, are they alive, crash early

• ping redis, ping database in bootstrap

• yeni connectionları yeni child processlere gönder (master has the socket)

• üzerlerinde bağlantı kalmadığında eski child processleri öldür

Deploy to a single server• graceful restart

• spawn new set of processes

• smoke test yap - eg: düzgün başladılar mı, cevap verebiliyorlar mı vs..

• ping redis, ping database…

• python app.py —port=8081 & && APP_PID=$! && ! curl localhost:8081 && kill $APP_PID

• loadbalancer (nginx/haproxy vs.) routingi değiştir

• loadbalancerın configi değiştir, sonra reload, kill -HUP

• üzerlerinde bağlantı kalmadığında eski processleri öldür.

• https://github.com/kelseyhightower/confd

Deploy to a single server• Graceful restart, diğer alternatif - mesela bir uygulama sunucunuz

yoksa (uwsgi, gevent gibi)

• child process socketi tekrar kullanılabilir olarak açar. yeni child processler forklarsınız, yeni child process ayağa kalkınca, parentına bir sinyal gönderir, parent eski çocuklarını öldürür.

• anahtar kelime: SO_REUSEPORT

• https://github.com/facebookgo/grace

• https://github.com/zimbatm/socketmaster

• https://github.com/pusher/crank

• http://grisha.org/blog/2014/06/03/graceful-restart-in-golang/

Deploy to a single server• graceful restart

• bazı uygulama sunucularında bu yeni kodu çalıştır, sonra eskisini öldür dansı hazır geliyor. dökümantasyonuna bakmalısınız.

• örn: uwsgi touch reload

• fork new processes

• accept new requests to new processes

• wait until there is no connection on old processes

• kill old child processes

• more details. http://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html

• touch /tmp/uwsgi-somefile to reload

Birden çok sunucuya deploy

Rolling deploy

Rolling deploy• ilk sunucuyu loadbalancerdan çıkart (app1)

• üzerinde bağlantı kalmayana kadar bekle

• app1 üzerindeki kodu güncelle

• smoke test yap

• app1 i tekrar loadbalancera ekle

• bekle

• ikinci sunucuyu loadbalancerdan çıkart (app2)

• üzerine bağlantı kalmayana kadar bekle

• app2 üzerinde kodu güncelle

• smoke test

• ikinci sunucuyu loadbalancera ekle.

blue/green deployment

• bir grup halindeki sunuculara sırayla deploy et. (örneğin birden çok environment yaratıp, eg: production_1, production_2 yada production_dublin, production_frankfurt)

• smoke test, monkey testing vs. yap

• herşey düzgünse, ikinci environmentı çıkart, ona deploy et, sonra aynı adımlar üçüncü için yap….

canary deployment• bir yada birden çok sunucuda kodu güncelle

• smoke test

• bazı kullanıcıları yeni env. a gönder.

• monitor et

• daha fazla kullanıcı gönder

• monitor et

• eğer herşey düzgünse bütün sunuculara deploy et.

• yeni özellikleri test etmek, bazı şeyleri denemek için kullanışlı

immutable deploys• kod deploy etme, sunucu deploy et.

• bir makine imajı yarat, (aws deki ami) ve bundan yeni makineler yarat.

• yeni bir set halinde yeni instancelar yarat.

• bunlara yönlendir kullanıcıları

• eski sunucuları sil

immutable deploys

• kodu deploy etme, containerları deploy et. (eg: Docker)

• bir docker imajı build edip onu deploy et.

• yeni kontainerlara yönlendir.

• yeni sunucu yaratmaktan çok daha hızlı.

container orchestration

• Docker Swarm

• AWS EC2 Container Service

• kubernetes

• …

immutable infrastructure• sunucu deploy etme, infrastructure ı deploy et.

• bütün ortamı kod yazarak yarat.

• hemen hemen herşeyi, sadece sunucuları değil (ELB, VPC etc.)

• tools: terraform, aws cloud formation

• sunuculara sshla vs. girmeye gerek olmamalı.

continuous deployment• herşeyi otomatize edin

• git push deploy yapsın

• birden çok pushlayın, küçük parçalar halinde deploy yapın.

• daha fazla deploy yapın

• arada sürtünme olmasın.

continuous deployment• ortaya çıkan sonuç şu, daha fazla deploy yapmak

daha az bug anlamına geliyor.

• eg: amazon her 11 saniyede bir yeni deploy yapıyor (2013)

• daha hızlı deploy yapmak için monolitik uygulamalardan mikroservislere geçin

• eg: netflix’in yüzlerce servisi var

• böylece bağımsız ekipler halinde deploy yapabilirsiniz.

continuous deployment

• daha fazlası için…

• Continuous Delivery - Jez Humble, David Farley (ayrıca konuşmaları da güzeldir)

• Adrian Cockcroft un konuşmaları (eskiden netflixte cloud architect) fast delivery

• Fred George un konuşmaları

continuous deployment

• CI/CD Sunucuları

• Jenkins

• Travis CI

• Ve diğerleri… onlarca düzgün seçenek var

relational database deployment

• şema değişikleri - tablo ekleme, kolon silme vs.

• pek kolay yolu yok

relational database deployment

• veritabanı kurulumu

• 1 master - X slaves

• failover, master ölürse, slavelerden birini promote et.

• veritabanı kurulumu

• multi master (biri standby)

• ip failover, address failover

• veritabanı kurulumu

• proxy arkasında multi master (eg: pgbouncer)

• aynı ip,failover uygulamaya transparan

relational database deployment

• veritabanı kurulumu

• AWS RDS servisi

• failoverı kendi yapıyor

• snapshotlara hızla dönebilirsiniz

• herhangi bir zamana dönebilirsiniz

şema değişiklikleri

• mümkünse yapmayın

• alter table users add column bar

• tablonuzu locklayabilir yada belki locklamaz.

• update x set foo='bar';

• tablonuzu locklayabilir.

şema değişikliklerini uygulamak

• mümkünse yapmayın.

• users tablosuna phone_number eklemek

• örneğin:

• create table user_details(user_id int, phone_number varchar(30))

şema değişiklikleri• değişiklikten kaçınma yolları - şemasız tasarımlara gidin

• users:

• id:

• name:

• password:

• email:

• data: JSON {“phone_number”: …}

şema değişiklikleri• değişiklikten kaçınmak.

• users:

• id:

• name:

• user_data:

• user_id:

• key: varchar(…)

• value: text

şema değişiklikleri• değişiklikten kaçınmak.

• users:

1 | ybrs

2 | asdasd

• user_data:

1 | phone_number | 123245

1 | city | Istanbul

2 | phone_number | 123245

applying schema changes• hala şema değişikliği yapmak istiyorsanız.

• slavei offline a alın

• alter table…. çalıştırın

• slave i online yapın, senkronize olsun, replicate, bekleyin.

• masteri offline a alın, slavei mastera promote edin

• alter table ... on master (eski master)

• eski masterı slave olarak bağlayın, bekleyin replikasyon tamamlansın

• eski masterı tekrar master haline promote edin.

applying schema changes

• hala şema değişikliği yapmak istiyorsanız.

• şu araçlara bakabilirsiniz, tek sunucu üzerinde canlı şema değişikliği için

• percona, pt-online-schema-change

• github: https://github.com/github/gh-ost

DON’T PANICjust deploy