Kısım II · İnşaat · Bölüm 43

Yayına Alma: Sunucu, Konteyner, Bulut

Koddan çalışan hizmete geçiş (Deployment, containers, cloud)

1. Kat 10Bizim uygulamamızUygulamanın sürümü ve işletimi. Kat 7'deki süreçler ile Kat 8'deki ağ adlandırması, Kat 10'daki hizmetin herkesçe erişilmesini sağlar. Kat planına dön.
2. Kat 9Web ve tarayıcıWeb istemcisi sunucunun sözleşmesini kullanır.
3. Kat 8Ağ ve internetHTTP istekleri, DNS ve TLS; parçalar ayrı makinelerdeyken aradaki yol.
4. Kat 7İşletim sistemiSüreçler, dosyalar ve izinler; altta Kat 3'ün işlemcisi ve belleği.

Bölüm sonunda ortamı, konteynerin paketlediği şeyi, bulutta sorumluluk paylaşımını ve yayın sonrası hata sinyallerini ayırabileceksin. Gerçek hesap kurmuyor veya yayın yapmıyoruz; yayın öncesi kararları öğreniyoruz.

43.1 Ortamlar: geliştirme, test ve üretim

Bölüm 42: Test ve Kalite sonunda kodun davranışını sınadık. Fakat testin geçtiği kod, herkesin eriştiği bir hizmete kendiliğinden dönüşmez. Yayına alma (deployment), belirli bir yazılım sürümünü belirli bir çalışma ortamına yerleştirip çalışır hale getirmektir. Aynı kaynak kod farklı adres, veri ve izinlerle birden çok yerde çalışabilir. Bu yüzden “hangi kod?” sorusunun yanında “hangi ortam?” sorusunu da sormak gerekir.¹²

Ortam (environment), uygulamanın çalıştığı kod, yapılandırma, hizmetler ve veri bağlamıdır. Geliştirme ortamı (development) kod yazarken kullandığın düzendir. Test ortamı (test environment) otomatik denetimlerin veri ve hizmetlerini taşır. Üretim öncesi ortam (staging) ise yayın adayını üretime benzeyen koşullarda denemeye yarar. Otomatik testin kısa ömürlü veritabanı ile staging aynı şey olmak zorunda değildir.¹²

Üretim ortamı (production), gerçek kullanıcıların gerçek verileriyle çalışan düzendir. Testte soruyu tekrar tekrar cevaplayan kurgu hesap açabiliriz; üretimde bunu gerçek kullanıcı adına yapamayız. Ortam ayrımı yalnız adlandırma değil, yanlış işlemin etki alanını sınırlamadır. Ayrı veritabanı, ayrı hizmet erişimi ve ayrı sırlar kullanmak, bir deneme hatasının gerçek hesaplara taşınmasını önlemeye yardım eder.²³

Tablo, Twelve-Factor ilkelerinin öğretim örneğidir. Benzerlik, gerçek kişisel veriyi test ortamına kopyalamak değildir.¹³

“Bende çalışıyordu” sorusunu şöyle aç: aynı sürüm mü, doğru ortam değişkenleri mi, gerekli şema göçü yapılmış mı? Üretim dosyalarını elle değiştirmek yerine çözümü izlenebilir ve yeniden üretilebilir yayın sürecine taşı.¹¹⁰

43.2 Sunucu, sanal makine ve konteyner

Bölüm 34: Arka Uç ve API sunucuyu istek bekleyen süreç olarak tanımladı. Bu bölümde “sunucu kiralamak” dediğimizde ise o süreci çalıştıracak makine kaynağını kastediyoruz. Kavramları ayıralım: Go sunucu süreci, işletim sisteminin verdiği işlemci zamanı ve belleği kullanır; bu işletim sistemi fiziksel makinede ya da sanallaştırılmış makinede çalışabilir. Bunların üstüne uygulamanın dosyalarını ve bağımlılıklarını nasıl yerleştireceğimiz ayrı bir sorudur.⁴⁵

Sanal makine (virtual machine, VM), burada kendi işletim sistemi ve çekirdeğiyle çalışan sanallaştırılmış bilgisayardır. Bölüm 21: Programlama Dilleri Haritası içindeki Java Sanal Makinesiyle aynı bağlam değildir: JVM dilin ara kodunu çalıştırıyordu; burada bir işletim sistemi barındırıyoruz. Konteyner (container) ise uygulama dosyalarıyla birlikte yalıtılmış çalışan süreç düzenidir. Aynı Linux çekirdeğinde çalışan konteynerler çekirdeği paylaşır; her biri ayrı çekirdek başlatmaz.⁵

Bu nedenle VM ile konteyner birbirinin rakibi olmak zorunda değildir. Bulutta bir VM kiralayıp üzerinde Go API'sini konteyner olarak çalıştırabilirsin. Konteynerin “her işletim sisteminde aynı makine kodunu doğrudan çalıştırdığı” sonucunu çıkarma; işletim sistemi ve işlemci mimarisi uyumluluğu hâlâ önemlidir.⁵

İmaj tarif değil, hazırlanmış pakettir

Konteyner imajı (container image), çalıştırma için gereken dosyaları, programları ve ilgili düzeni içeren paketlenmiş çıktıdır. İmajdan çalışan bir konteyner başlatılır. Aynı imajdan birden fazla konteyner oluşturulabilir. Docker bu imajları oluşturup konteynerleri çalıştırmak için kullanılan araç ekosistemidir. İmaj oluşturmakla süreci çalıştırmak ayrı aşamalardır.⁶⁷

Kaynak kod + bağımlılık tanımları + Dockerfile
                     ↓ imaj oluşturma
            Sürümü belirli konteyner imajı
                     ↓ yapılandırmayla başlatma
          Çalışan konteyner → Go sunucu süreci

İlk satır girdileri gösterir. Dockerfile (Dockerfile), imajın hangi adımlarla oluşturulacağını tarif eden dosyadır; imajın kendisi değildir. Son okta üretim adresleri ve sırları gibi çalışma yapılandırması devreye girer. Özel sırları imajın içine yerleştirirsen imajı paylaşmakla sırrı da paylaşmış olabilirsin; Bölüm 41: Kimlik Doğrulama ve Güvenlik içindeki sınır burada da korunur.⁷⁸³

Dockerfile'da FROM başlangıç imajını, COPY dosya taşımayı, RUN oluşturma sırasında çalışacak komutu, ENTRYPOINT ise çalıştırma girişini belirtebilir. Bunlar burada üretim tarifi değil, komut adlarını okuyabilmen için açıklamadır.⁸

İmaj sabit, çalışan süreç geçici

Docker belgeleri imajları değişmez katmanlar olarak açıklar: yeni sürüm için yeni imaj oluşturursun. Çalışan konteynerin kendi yazılabilir katmanında değişiklik olabilir; bu, başlangıç imajını değiştirmez. İmaj kayıt defteri (container registry), imajların saklanıp başka makinelere dağıtılabildiği yerdir. Hangi çıktının yayımlandığı izlenebilir olmalıdır.⁷

Veritabanı dosyaları çalışan konteynerin silinen katmanına mahkûm bırakılmaz. Kalıcı birim (volume), verinin tek bir konteynerin yaşamından bağımsız tutulmasını sağlar. Konteyneri silmekle birimi silmek farklı işlemlerdir; ama birimin aynı makinede kalması onu kendiliğinden yedek yapmaz. Disk kaybı veya yanlış veri silme için Bölüm 39: Postgres Pratikte içindeki ayrı yedek ve geri yükleme planı gerekir.⁹

43.3 Bulut: IaaS, PaaS ve sunucusuz

Bulut (cloud), işlem, depolama ve ağ gibi kaynaklara hizmet olarak eriştiğimiz düzenin genel adıdır. Elektrik, işlemci ve işletim sistemi ortadan kalkmaz; bunların bir bölümünü başka kuruluş işletir. Temel karar “bulutta mıyız?” değil, “hangi sorumluluk bizde, hangisi sağlayıcıda?” sorusudur. Aynı sağlayıcı içinde bile farklı hizmetler farklı iş bölümü yapar.⁴

IaaS/PaaS sınıfları ve sunucusuz sözcüğü tek bir ortak merdivenin kusursuz basamakları değildir. Sunucusuz platformlar da vardır; terimler sorumluluk paylaşımını anlatmak için kullanılır.⁴¹¹¹²

AWS, Google Cloud ve Cloudflare tek birer “sunucu türü” değil hizmet aileleridir. Google Cloud Run belgeleri, HTTP isteklerini yanıtlayan yönetilen konteyner örneklerini açıklar. Cloudflare Workers belgeleri ise V8 içinde yalıtılmış çalışma bağlamlarını anlatır. Dolayısıyla Workers'a sıradan bir Linux Go ikili dosyasını yükleyip aynı net/http sürecini VM'deki gibi başlatacağını varsayamazsın. Aynı sağlayıcının başka ürünleri veya başka hedefe derleme yolları olabilir; onların sözleşmesi ayrıca okunur.¹¹¹²

Sunucusuz “sunucu yok” değil, sunucunun sağlanması ve işletilmesinin önemli bölümünü senin yapmaman demektir. Örnekler değişebildiği için kalıcı veri süreç belleğine bağlanmaz. Konteyner çalıştırmak da otomatik olarak sunucusuz olmak değildir: kendi VM'nde Docker'ı sen işletiyorsan o makinenin işletim yükü hâlâ sendedir.¹⁰¹¹⁵

Seçimde çalışma zamanı, veri bölgesi, yedekleme, izinler ve gözlem ihtiyaçlarına bakılır. Bölüm 41: Kimlik Doğrulama ve Güvenlik içindeki kişisel veri ve yurt dışına aktarım değerlendirmesi de sağlayıcı logosuyla çözülmez. Bir hizmeti seçmek, onun teknik sözleşmesini ve hukuki veri akışını birlikte değerlendirmektir.⁴¹¹

43.4 CI/CD ve GitHub Actions

Bölüm 42: Test ve Kalite sürekli entegrasyonu, ortak değişikliklerin otomatik denetimi olarak kurdu. CD kısaltması iki yakın fakat farklı anlamda kullanılır. Sürekli teslim (continuous delivery), yazılımı güvenilir biçimde yayına alınabilir tutmayı; sürekli dağıtım (continuous deployment) ise denetimlerden geçen değişiklikleri üretime otomatik göndermeyi anlatır. İlkinde üretime geçişte insan kararı bulunabilir. Her yeşil testi kendiliğinden üretim yayını saymayız.¹³

GitHub Actions (GitHub Actions), depodaki olaylarla tetiklenen otomatik işleri çalıştıran hizmettir. YAML dosyasında tanımlanan iş akışı (workflow), bir veya birden çok iş içerir. İşin adımları komut ya da yeniden kullanılabilir action çalıştırabilir. Çalıştırıcı (runner), bu adımları gerçekten yürüten makinedir. Dosyadaki tarif ile onu çalıştıran bilgisayar yine ayrı şeylerdir.¹⁴

Değişiklik → CI denetimleri → yayın çıktısını oluştur
          → staging'e yerleştir → temel sağlık denetimi
          → gerekli onay → aynı çıktıyı production'da çalıştır

Bu, bir hesaba gönderilmiş iş akışı değil, örnek yayın hattıdır. İkinci aşama yayın çıktısı (artifact) üretir: Go ikili dosyası, web dosyaları veya konteyner imajı gibi. Sonraki aşamalar bu belirli çıktının nerede çalıştığını değiştirir. GitHub ortam koruma kurallarıyla onay ve sır erişimi sınırlandırılabilir; kullanılabilir ayrıntılar hesabın ve deponun özelliklerine göre ayrıca denetlenir.¹⁴²¹

Üretim sırrı her test işine verilmez. Özellikle denetlenmemiş kodu çalıştıran adımın üretim erişimi olmamalıdır. “Testleri koşturmak” ile “üretimi değiştirmek” farklı yetkilerdir. Bir yayın adımı yalnız gereken hedefe erişmeli, çıktısında sır basmamalıdır. Bölüm 41: Kimlik Doğrulama ve Güvenlik içindeki en az yetki ilkesini burada otomatik çalışan programlara da uygularız.²

Geri dönüş yalnız eski imajı başlatmak değildir

Geri dönüş (rollback), hatalı yayından önceki çalışan sürüme dönme planıdır. Fakat Bölüm 39: Postgres Pratikte içindeki şema göçünü düşün: yeni sürüm bir sütunu silmişse eski ikili dosyayı başlatmak veriyi geri getirmez. Uygulama sürümü, yapılandırma ve veri şeması birlikte düşünülür. Bir göçü önce ekleyici ve eski sürümle uyumlu yapmak gibi yaklaşımlar geri dönüşü kolaylaştırabilir; veri silen adım ise ayrıca değerlendirilir.²¹

Bu yüzden yayın öncesinde “hangi sürüme döneriz, o sürüm yeni şemayı okuyabilir mi, yedeği geri yüklemek neyi kaybettirir?” soruları sorulur. Eski sürümün kimliği ve yapılandırması saklanmalıdır. Yayın sonrasında temel isteği de sınarız; sürecin açılması yeterli değildir. Burada gerçek bir deploy yapılmadı.¹²

43.5 Alan adı, DNS kaydı ve HTTPS sertifikası

Bölüm 20: İnternet ve Web: HTML'e Varış içindeki haritaya geri dönelim. Alan adı okunabilir addır; DNS bu adla ilgili adres kayıtlarını buldurur; HTTPS bağlantının şifreli ve hedef adla doğrulanmış kurulmasını sağlar. Bunlar aynı ayar ekranında görünebilir ama aynı iş değildir. DNS kaydı yazmak API sürecini başlatmaz, HTTPS sertifikası da veritabanının doğruluğunu garanti etmez.¹⁵¹⁶

DNS kaydı (DNS record) için üç yaygın tür yeterli: A bir adı IPv4 adresine, AAAA IPv6 adresine eşler; CNAME başka bir ada başvurur. Örneğin api.example.com için platformun verdiği hedef ada yönlendirme gerekebilir. Bu örnek bir yapı gösterir; gerçek hizmette hangi kaydın gerektiğini platformun alan adı belgesi belirler. Kayıtlardaki yaşam süresi, DNS önbelleklerinin ne kadar süre cevabı kullanabileceğini etkiler; değişiklik her istemcide aynı anda görünmeyebilir.¹⁵²²

HTTPS sertifikası (TLS certificate), bağlantı kurulan ad için anahtar ve güven zinciriyle ilgili doğrulama sağlar. Let's Encrypt gibi sertifika otoriteleri alan adı denetiminin kanıtlanmasını ister; otomatik istemci DNS ya da HTTP üzerinden bir doğrulama görevini yerine getirebilir. Sertifikanın zamanında yenilenmesi de işletimin parçasıdır. Bu, kullanıcının giriş parolasından ayrı bir anahtar ve güven düzenidir.¹⁶

Arada Cloudflare gibi bir ters vekil varsa iki bağlantı ayağını ayrı düşün: tarayıcı → Cloudflare ve Cloudflare → asıl sunucu. İlki HTTPS iken ikincinin de doğru korunmuş olduğunu varsayma. Cloudflare'ın Full (strict) belgesi asıl sunucu sertifikasının doğrulanmasını açıklar. Tarayıcıda kilit simgesi görünmesi bütün iç ağ yollarının aynı güvenceye sahip olduğunu tek başına göstermez.¹⁷

43.6 Gözlem: kayıt, ölçüm ve alarm

Yayın anında testler geçti; ertesi gün kullanıcı “cevabım kayboldu” dedi. O an neye bakacağız? Gözlem (observability), sistemin dışa verdiği sinyallerden iç durumunu anlamayı mümkün kılan düzenektir. Sadece “süreç açık mı?” göstergesi değildir. Kayıtlar, ölçümler ve gerektiğinde izler farklı soruları cevaplar.¹⁸

Alarm, bu sinyallerden seçilen koşul oluştuğunda sorumluya haber verir.¹⁸¹⁹

Kayıtta örneğin istek kimliği, yolun şablonu, durum kodu ve işlem sonucu tutulabilir. Aynı kimlik farklı parçalardaki olayları ilişkilendirmeye yardım eder. Fakat istek gövdesinin tamamını gelişigüzel yazmak parola, belirteç veya kişisel veri sızdırabilir. Bölüm 41: Kimlik Doğrulama ve Güvenlik içindeki sır ve veri koruma kuralları, hata ayıklama sırasında da geçerlidir. Gerekli bilgi ve kontrollü erişim hedeflenir.¹⁸

Sayısal bir öğretim örneği: bilinen bir aralıkta 10.000 istekten 50'si sunucu hatasıyla bitmişse hata oranı 50 / 10.000 × 100 = %0,5 olur. Bu oran Python ile hesaplandı; gerçek hizmetimizin ölçümü değildir. Sadece toplam hata sayısına bakmak yetmez: 50 hata az trafikte çok, çok büyük trafikte küçük oran olabilir. Gecikmede de yalnız ortalama kullanıcıların yavaş ucunu gizleyebilir; hangi ölçüme neden baktığını belirlemek gerekir.¹⁸

Alarm (alert), müdahale gerektiren durumu bir sorumluya ulaştırmalıdır. Alarmın sahibini ve ilk bakılacak bilgiyi belirleriz. Uygulamamızda temel takip soruları: cevap kaydetme başarısı, API gecikmesi, veritabanı bağlantı sorunları ve yayın sonrası belirgin değişikliklerdir. Bunlar önerilen gözlem başlıklarıdır, kurulu bir izleme sisteminin raporu değildir.¹⁸¹⁹

43.7 Twelve-Factor App ve yapılandırma

Twelve-Factor App (twelve-factor methodology), hizmet olarak çalışan uygulamaların oluşturulması ve işletilmesi için on iki ilke önerir. Yeni bir programlama dili, zorunlu ürün listesi veya Docker kullanma şartı değildir. Şimdiye kadar ayrı ayrı konuştuğumuz kararları bir kontrol çerçevesinde toplar.¹

Tablo, özgün on iki başlığın bu bölümdeki yığına uyarlanmış kısa okumasıdır. Ayrıntılar, her ilkenin özgün sayfasında okunmalıdır.¹

Yapılandırma ile kodun ayrılması

Yapılandırma (configuration, config), sürümler arasında değil çalıştırılan yerler arasında değişmesi beklenen adres, erişim bilgisi ve benzeri ayarlardır. Twelve-Factor bunların ortam değişkenleriyle sağlanmasını önerir. Portu veya veri hizmetini değiştirmek kodu yeniden derlemeyi gerektirmemelidir. İş kuralı ise aynı anlamda ortama özgü yapılandırma değildir.³

PORT=8080 gibi bir örnek gizli değildir; veritabanı erişim bilgisi gizli olabilir. Aynı dağıtım mekanizmasından gelmeleri aynı hassasiyette oldukları anlamına gelmez. Ortam değişkeni bir iletim arayüzüdür, kendi başına güvenli sır kasası değildir. Dahası Expo'nun EXPO_PUBLIC_ önekli değişkenleri derlenmiş istemci içinde açıkça görülebilir: API adresi burada olabilir, sunucu erişim anahtarı olmamalıdır.³²⁰

Durumsuz süreç ilkesi “uygulamada hiç veri yok” demez. Kalıcı hesap ve puan Postgres'te, ortak oturum gerekiyorsa uygun bir oturum deposunda tutulur. Sürecin belleği kısa ömürlü hesap için kullanılabilir; fakat sonraki isteğin aynı sürece geleceği varsayılmaz. Böylece yeni sürüm başlatmak veya birden çok kopya çalıştırmak daha yönetilebilir olur. Bunun ölçeklenmeyle ilişkisini Bölüm 44: Mimariler içinde kuracağız.¹⁰

Kayıt ilkesi de aynı ayrımdır: uygulama olayını standart çıktıya yazabilir; çalışma ortamı bu akışı toplar, saklar ve aramaya açar. Saklama süresi ve erişim politikası yine tasarlanır.¹⁹

Bu bölümde neler kuruldu

Ortamlar veri ve yetki sınırlarıdır. VM ayrı işletim sistemi, konteyner paylaşılan çekirdekte yalıtılmış süreçtir; imaj paket, Dockerfile tariftir. Bulut sorumluluk paylaşır. CI/CD denetimi yayınla birleştirir; DNS adlandırır, TLS bağlantıyı korur. Gözlem kayıt, ölçüm ve izden işe yarar sinyal çıkarır. Twelve-Factor kodu yapılandırmadan, kalıcı veriyi süreçten ayırır.

Terimler sözlükte, Bölüm 43 başlığı altında.

Kaynaklar

1. The Twelve-Factor App: özgün on iki ilke; özellikle build/release/run, disposability ve dev/prod parity.
2. GitHub Docs, Deployment environments: ortam hedefleri, koruma kuralları ve ortam sırları.
3. The Twelve-Factor App, III. Config: yapılandırmayı ortamda tutma ve koddan ayırma.
4. AWS, Types of Cloud Computing: IaaS/PaaS ve yönetim sorumluluğu ayrımları.
5. Docker Docs, What is a container?: süreç yalıtımı, VM farkı ve birlikte kullanım.
6. Docker Docs, Get started: konteyner ve imaj kavramlarına yazılı giriş.
7. Docker Docs, What is an image?: değişmez katmanlar, imaj paketleme ve dağıtım.
8. Docker Docs, Dockerfile reference: FROM, COPY, RUN, ENTRYPOINT.
9. Docker Docs, Persisting container data: yazılabilir konteyner katmanı ve birim yaşam döngüsü.
10. The Twelve-Factor App, VI. Processes: kalıcı durumun dış hizmette tutulması ve ortak oturum.
11. Google Cloud, What is Cloud Run?: yönetilen konteyner örnekleri ve HTTP hizmetleri.
12. Cloudflare, How Workers works: V8 isolates ve çalışma bağlamının ömrü.
13. Martin Fowler, Continuous Delivery: yayına alınabilir olma ile otomatik üretim dağıtımı ayrımı.
14. GitHub Docs, Understanding GitHub Actions: workflow, job, step ve runner.
15. Cloudflare, DNS record types: A, AAAA, CNAME ve TTL.
16. Let's Encrypt, How It Works: alan adı denetimi ve sertifika yönetimi.
17. Cloudflare, Full (strict): istemci–Cloudflare ve Cloudflare–origin şifreli bağlantıları ve origin sertifikası.
18. AWS Well-Architected, Implement observability: kayıt, ölçüm, iz ve anlamlı göstergeler.
19. The Twelve-Factor App, XI. Logs: olay akışı, standart çıktı ve alarm örnekleri.
20. Expo, Environment variables: EXPO_PUBLIC_ değerlerinin istemci paketinde açık görünmesi.
21. AWS Builders’ Library, Ensuring rollback safety during deployments: veri biçimi ve sürümler arası geriye uyumluluk.
22. Cloudflare, Time to Live (TTL): kayıt değişiklikleri ve DNS önbelleği.