Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
Deployment Strategies
Ben Kimim
• Aybars Badur
• Evli, 2 cocuk babasi
• Backend Lead @adphorus
• 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