Uzman \u0130pucu: Altyap\u0131n\u0131z\u0131n En Kritik Bile\u015fenlerini Tan\u0131mlay\u0131n<\/div>\n<\/h3>\n
\n Altyap\u0131n\u0131zdaki en kritik kaynaklar\u0131 (veritabanlar\u0131, depolama birimleri, a\u011f yap\u0131land\u0131rmalar\u0131 vb.) belirleyin ve bu kaynaklara \u00f6ncelikli olarak lifecycle kurallar\u0131 uygulay\u0131n. Bu, en b\u00fcy\u00fck riskleri en ba\u015ftan ele alman\u0131z\u0131 sa\u011flar.\n<\/div>\n
Bu b\u00f6l\u00fcm, lifecycle kurallar\u0131n\u0131n temel mant\u0131\u011f\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 oldu. \u015eimdi, en s\u0131k kullan\u0131lan ve en etkili lifecycle arg\u00fcmanlar\u0131n\u0131 detayl\u0131 olarak inceleyelim. Her bir arg\u00fcman\u0131n ne i\u015fe yarad\u0131\u011f\u0131n\u0131, ne zaman kullan\u0131lmas\u0131 gerekti\u011fini ve ger\u00e7ek d\u00fcnya \u00f6rnekleriyle nas\u0131l uyguland\u0131\u011f\u0131n\u0131 ke\u015ffedece\u011fiz. Bu sayede, kendi altyap\u0131 projelerinizde bu g\u00fc\u00e7l\u00fc \u00f6zelliklerden tam anlam\u0131yla faydalanabileceksiniz. K\u0131sacas\u0131, Terraform lifecycle kurallar\u0131, DevOps s\u00fcre\u00e7lerinizin daha sa\u011flam, daha g\u00fcvenli ve daha y\u00f6netilebilir hale gelmesinin anahtarlar\u0131ndan biridir.<\/p>\n
prevent_destroy<\/code>: Yanl\u0131\u015fl\u0131kla Silmeleri Nas\u0131l Engellersiniz?<\/h2>\nAltyap\u0131 y\u00f6netiminde en b\u00fcy\u00fck korkulardan biri, \u00fcretim ortam\u0131ndaki kritik bir kayna\u011f\u0131n yanl\u0131\u015fl\u0131kla silinmesidir. Bir veritaban\u0131, bir depolama kovas\u0131 veya bir a\u011f ge\u00e7idi gibi temel bir bile\u015fenin ortadan kalkmas\u0131, dakikalar i\u00e7inde b\u00fcy\u00fck \u00e7apl\u0131 kesintilere ve veri kay\u0131plar\u0131na yol a\u00e7abilir. \u0130\u015fte bu felaket senaryolar\u0131n\u0131 \u00f6nlemek i\u00e7in Terraform’un prevent_destroy<\/code> lifecycle arg\u00fcman\u0131 devreye girer. Bu arg\u00fcman, belirli bir kayna\u011f\u0131n Terraform taraf\u0131ndan imha edilmesini engeller, b\u00f6ylece kritik kaynaklar\u0131n\u0131z i\u00e7in ek bir g\u00fcvenlik katman\u0131 olu\u015fturur.<\/p>\n
prevent_destroy = true<\/code> olarak ayarland\u0131\u011f\u0131nda, Terraform plan\u0131 \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda ilgili kaynak i\u00e7in bir “imha” (destroy) eylemi alg\u0131larsa, i\u015flemi durdurur ve bir hata mesaj\u0131 d\u00f6nd\u00fcr\u00fcr. Bu, uygulaman\u0131n devam etmesini engeller ve kullan\u0131c\u0131n\u0131n bu potansiyel tehlikeli eylemi g\u00f6zden ge\u00e7irmesini sa\u011flar. Bu \u00f6zellik, \u00f6zellikle \u00fcretim ortamlar\u0131ndaki hassas kaynaklar i\u00e7in vazge\u00e7ilmezdir. Geli\u015ftirme veya test ortamlar\u0131nda genellikle daha az k\u0131s\u0131tlay\u0131c\u0131 olsan\u0131z da, canl\u0131 sistemler s\u00f6z konusu oldu\u011funda, bu t\u00fcr bir koruma hayati \u00f6nem ta\u015f\u0131r. Yanl\u0131\u015f bir refaktoring, bir mod\u00fcl de\u011fi\u015fikli\u011fi veya sadece dikkatsiz bir komut bile bu arg\u00fcman sayesinde kontrol alt\u0131na al\u0131nabilir.<\/p>\n
Uygulama \u00d6rne\u011fi: AWS S3 Kovas\u0131n\u0131 Korumak<\/strong><\/p>\n
Bir e-ticaret sitesinin \u00fcr\u00fcn g\u00f6rsellerini bar\u0131nd\u0131rd\u0131\u011f\u0131 bir AWS S3 kovas\u0131 oldu\u011funu varsayal\u0131m. Bu kovan\u0131n silinmesi, site \u00fczerindeki t\u00fcm \u00fcr\u00fcn g\u00f6rsellerinin kaybolmas\u0131na neden olur. Bu t\u00fcr bir durumu \u00f6nlemek i\u00e7in prevent_destroy<\/code> arg\u00fcman\u0131n\u0131 a\u015fa\u011f\u0131daki gibi kullanabiliriz:<\/p>\n
\nresource \"aws_s3_bucket\" \"product_images\" {\n  bucket = \"my-ecom-product-images-prod\"\n  acl    = \"private\"\n\n  tags = {\n    Environment = \"Production\"\n    ManagedBy   = \"Terraform\"\n  }\n\n  lifecycle {\n    prevent_destroy = true\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Yukar\u0131daki kod blo\u011fuyla, aws_s3_bucket.product_images<\/code> kayna\u011f\u0131n\u0131 Terraform arac\u0131l\u0131\u011f\u0131yla silmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda (\u00f6rne\u011fin, terraform destroy<\/code> komutu veya kayna\u011f\u0131n koddan \u00e7\u0131kar\u0131lmas\u0131 durumunda), Terraform i\u015flemi durduracak ve size bir uyar\u0131 verecektir. Bu, size durumu g\u00f6zden ge\u00e7irme ve olas\u0131 bir hatay\u0131 d\u00fczeltme f\u0131rsat\u0131 sunar. Bu sayede, kritik veri kayb\u0131n\u0131n \u00f6n\u00fcne ge\u00e7ilmi\u015f olur. Geli\u015ftirme s\u00fcrecinde bile, bu t\u00fcr kurallar\u0131n erken a\u015famada uygulanmas\u0131, sonraki a\u015famalarda olu\u015fabilecek sorunlar\u0131n \u00f6nlenmesine yard\u0131mc\u0131 olabilir. Ayr\u0131ca, g\u00fcvenlik denetimleri s\u0131ras\u0131nda bu t\u00fcr korumalar\u0131n varl\u0131\u011f\u0131, altyap\u0131n\u0131z\u0131n olgunlu\u011funu g\u00f6steren \u00f6nemli bir g\u00f6stergedir.<\/p>\n
Vaka Analizi: E-ticaret Platformu ve \u00dcr\u00fcn G\u00f6rsel Korumas\u0131<\/strong><\/p>\n
B\u00fcy\u00fck bir e-ticaret platformu, g\u00fcnl\u00fck milyonlarca ziyaret\u00e7iye hizmet vermektedir. Platformun ana bile\u015fenlerinden biri, \u00fcr\u00fcn g\u00f6rsellerini bar\u0131nd\u0131ran AWS S3 kovas\u0131d\u0131r. Geli\u015ftirme ekibinden birinin, bir temizlik \u00e7al\u0131\u015fmas\u0131 s\u0131ras\u0131nda yanl\u0131\u015fl\u0131kla bu S3 kovas\u0131n\u0131 Terraform kodundan \u00e7\u0131kard\u0131\u011f\u0131n\u0131 ve terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131rmak \u00fczere oldu\u011funu d\u00fc\u015f\u00fcnelim. E\u011fer prevent_destroy = true<\/code> kural\u0131 uygulanmam\u0131\u015f olsayd\u0131, bu komut \u00fcr\u00fcn g\u00f6rsellerinin bulundu\u011fu S3 kovas\u0131n\u0131 silecekti. Sonu\u00e7? Milyonlarca \u00fcr\u00fcne ait g\u00f6rselin kaybolmas\u0131, sitenin i\u015flevselli\u011finin durmas\u0131 ve b\u00fcy\u00fck bir gelir kayb\u0131. Ancak, bu kural sayesinde Terraform i\u015flemi durdurdu, ekibe hatay\u0131 bildirdi ve potansiyel bir felaketin \u00f6n\u00fcne ge\u00e7ildi. Bu \u00f6rnek, k\u00fc\u00e7\u00fck bir lifecycle kural\u0131n\u0131n bile ne kadar b\u00fcy\u00fck bir etki yaratabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Bu t\u00fcr bir koruma, sadece veri kayb\u0131n\u0131 \u00f6nlemekle kalmaz, ayn\u0131 zamanda operasyonel stresi azalt\u0131r ve ekiplerin daha g\u00fcvenle \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.<\/p>\n
ignore_changes<\/code>: Terraform'\u0131n \u0130zlemesini \u0130stemedi\u011finiz De\u011fi\u015fiklikler Nelerdir?<\/h2>\nBazen altyap\u0131n\u0131zdaki baz\u0131 kaynaklar\u0131n belirli \u00f6zelliklerinin Terraform d\u0131\u015f\u0131nda y\u00f6netilmesini isteyebilirsiniz. \u00d6rne\u011fin, bir sanal makinenin etiketleri manuel olarak g\u00fcncellenebilir veya bir veritaban\u0131n\u0131n performans ayarlar\u0131 otomatik izleme sistemleri taraf\u0131ndan optimize edilebilir. Bu gibi durumlarda, Terraform'un bu manuel veya harici de\u011fi\u015fiklikleri alg\u0131lay\u0131p kendi state dosyas\u0131na kaydetmeye \u00e7al\u0131\u015fmas\u0131, istenmeyen durumlara yol a\u00e7abilir. \u0130\u015fte ignore_changes<\/code> lifecycle arg\u00fcman\u0131 tam da bu noktada devreye girer. Bu arg\u00fcman, Terraform'a belirli bir kayna\u011f\u0131n hangi \u00f6zelliklerini g\u00f6z ard\u0131 etmesi gerekti\u011fini bildirerek, istenmeyen \"drift\" alg\u0131lamalar\u0131n\u0131 ve d\u00fczeltme giri\u015fimlerini engeller.<\/p>\n
ignore_changes<\/code>, bir kayna\u011f\u0131n belirli niteliklerini bir listesi olarak al\u0131r. Terraform, plan<\/code> veya apply<\/code> komutlar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, bu listedeki niteliklerdeki de\u011fi\u015fiklikleri tamamen g\u00f6z ard\u0131 eder. Bu, kaynak \u00fczerinde yap\u0131lan manuel de\u011fi\u015fikliklerin Terraform taraf\u0131ndan \u00fczerine yaz\u0131lmas\u0131n\u0131 veya Terraform'un s\u00fcrekli olarak bu de\u011fi\u015fiklikleri geri almaya \u00e7al\u0131\u015fmas\u0131n\u0131 \u00f6nler. Bu durum, \u00f6zellikle \u00e7oklu y\u00f6netim ara\u00e7lar\u0131n\u0131n veya ekiplerin ayn\u0131 kaynak \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131 hibrit y\u00f6netim senaryolar\u0131nda \u00e7ok de\u011ferlidir. \u00d6rne\u011fin, bir g\u00fcvenlik ekibi belirli bir sunucuya g\u00fcvenlik denetim etiketleri eklerken, bir otomasyon arac\u0131 sunucunun di\u011fer \u00f6zelliklerini y\u00f6netebilir. E\u011fer ignore_changes<\/code> kullan\u0131lmazsa, Terraform s\u00fcrekli olarak g\u00fcvenlik etiketlerini silmeye veya eski haline d\u00f6nd\u00fcrmeye \u00e7al\u0131\u015facakt\u0131r, bu da bir \u00e7at\u0131\u015fma yarat\u0131r.<\/p>\n
Uygulama \u00d6rne\u011fi: EC2 Etiketlerini G\u00f6z Ard\u0131 Etmek<\/strong><\/p>\n
Bir AWS EC2 \u00f6rne\u011finin Name<\/code> etiketi Terraform taraf\u0131ndan y\u00f6netilirken, CostCenter<\/code> ve Owner<\/code> gibi etiketlerin manuel olarak veya ba\u015fka bir sistem taraf\u0131ndan g\u00fcncellendi\u011fini varsayal\u0131m. Bu etiketlerdeki de\u011fi\u015fiklikleri Terraform'un g\u00f6z ard\u0131 etmesini sa\u011flamak i\u00e7in ignore_changes<\/code> kullanabiliriz:<\/p>\n
\nresource \"aws_instance\" \"web_server\" {\n  ami           = \"ami-0abcdef1234567890\" # \u00d6rnek AMI ID\n  instance_type = \"t2.micro\"\n  \n  tags = {\n    Name        = \"WebServerProd\"\n    ManagedBy   = \"Terraform\"\n    CostCenter  = \"DevOps\" # Bu ba\u015flang\u0131\u00e7 de\u011feri, sonra manuel de\u011fi\u015febilir\n    Owner       = \"Operations\" # Bu da de\u011fi\u015febilir\n  }\n\n  lifecycle {\n    ignore_changes = [\n      tags[\"CostCenter\"],\n      tags[\"Owner\"],\n    ]\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Bu \u00f6rnekte, e\u011fer EC2 \u00f6rne\u011finin CostCenter<\/code> veya Owner<\/code> etiketleri AWS konsolu \u00fczerinden manuel olarak de\u011fi\u015ftirilirse, bir sonraki terraform plan<\/code> veya terraform apply<\/code> komutu bu de\u011fi\u015fiklikleri \"drift\" olarak alg\u0131lamayacak ve \u00fczerine yazmayacakt\u0131r. Yaln\u0131zca Terraform taraf\u0131ndan y\u00f6netilen di\u011fer etiketler veya \u00f6zellikler ele al\u0131nacakt\u0131r. Bu sayede, farkl\u0131 y\u00f6netim katmanlar\u0131 aras\u0131nda uyumlu bir \u00e7al\u0131\u015fma ortam\u0131 sa\u011flanm\u0131\u015f olur. Ayr\u0131ca, bu \u00f6zellik, kaynaklar\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn belirli y\u00f6nlerini farkl\u0131 ara\u00e7lara veya s\u00fcre\u00e7lere devretmek istedi\u011finizde esneklik sa\u011flar. Bu, \u00f6zellikle karma\u015f\u0131k ve \u00e7ok katmanl\u0131 operasyonel modellerde vazge\u00e7ilmezdir.<\/p>\n
Vaka Analizi: G\u00fcvenlik Ekibinin Dinamik Etiketleme Politikas\u0131<\/strong><\/p>\n
Finans sekt\u00f6r\u00fcnde faaliyet g\u00f6steren bir \u015firket, s\u0131k\u0131 g\u00fcvenlik ve denetim gereksinimlerine sahiptir. G\u00fcvenlik ekibi, yeni ke\u015ffedilen zafiyetlere veya i\u00e7 denetim bulgular\u0131na g\u00f6re sunuculara dinamik olarak etiketler (\u00f6rne\u011fin, SecurityRiskLevel: High<\/code>, PatchRequired: true<\/code>) eklemektedir. Bu etiketler, otomatik tarama ara\u00e7lar\u0131 taraf\u0131ndan okunur ve h\u0131zl\u0131 yan\u0131t s\u00fcre\u00e7lerini tetikler. Ancak, Terraform, bu sunucular\u0131n ana altyap\u0131 bile\u015fenlerini y\u00f6netmektedir. E\u011fer ignore_changes<\/code> kullan\u0131lmasayd\u0131, g\u00fcvenlik ekibinin ekledi\u011fi etiketler her terraform apply<\/code> \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda silinecek ve g\u00fcvenlik protokolleri bozulacakt\u0131. \u015eirket, EC2, RDS ve di\u011fer kaynaklar i\u00e7in tags<\/code> niteli\u011finin bir k\u0131sm\u0131n\u0131 ignore_changes<\/code> listesine ekleyerek bu sorunu \u00e7\u00f6zd\u00fc. B\u00f6ylece Terraform, temel altyap\u0131 \u00f6zelliklerini tutarl\u0131 bir \u015fekilde y\u00f6netirken, g\u00fcvenlik ekibi de kendi \u00f6zel etiketlerini ba\u011f\u0131ms\u0131z olarak uygulayabildi. Bu durum, farkl\u0131 disiplinlerin ayn\u0131 altyap\u0131 \u00fczerinde \u00e7at\u0131\u015fmadan \u00e7al\u0131\u015fabilmesini sa\u011flayan m\u00fckemmel bir \u00f6rnektir.<\/p>\n
create_before_destroy<\/code>: Kesintisiz G\u00fcncellemeler Nas\u0131l Sa\u011flan\u0131r?<\/h2>\nAltyap\u0131 g\u00fcncellemeleri, \u00f6zellikle y\u00fcksek kullan\u0131labilirlik gerektiren sistemlerde hassas bir s\u00fcre\u00e7tir. Geleneksel olarak, bir kayna\u011f\u0131 g\u00fcncellemek genellikle mevcut kayna\u011f\u0131 durdurmay\u0131 veya silmeyi, ard\u0131ndan yeni s\u00fcr\u00fcm\u00fc da\u011f\u0131tmay\u0131 i\u00e7erir. Bu s\u00fcre\u00e7, \u00f6zellikle tek bir kaynak s\u00f6z konusu oldu\u011funda, k\u0131sa s\u00fcreli de olsa bir kesintiye yol a\u00e7abilir. Ancak, bir\u00e7ok uygulama i\u00e7in bu t\u00fcr bir kesinti kabul edilemezdir. \u0130\u015fte burada create_before_destroy<\/code> lifecycle arg\u00fcman\u0131 devreye girer. Bu arg\u00fcman, Terraform'a bir kayna\u011f\u0131 g\u00fcncelleme s\u0131ras\u0131nda, eski kayna\u011f\u0131 silmeden \u00f6nce yeni kayna\u011f\u0131 olu\u015fturmas\u0131 talimat\u0131n\u0131 verir.<\/p>\n
create_before_destroy = true<\/code> olarak ayarland\u0131\u011f\u0131nda, Terraform bir kayna\u011f\u0131n \u00fczerinde \"in-place\" g\u00fcncellenemeyen bir de\u011fi\u015fiklik alg\u0131lad\u0131\u011f\u0131nda (\u00f6rne\u011fin, bir EC2 \u00f6rne\u011finin instance_type<\/code>'\u0131 de\u011fi\u015ftirildi\u011finde), \u00f6nce yeni konfig\u00fcrasyona sahip yeni bir kaynak olu\u015fturur. Yeni kaynak ba\u015far\u0131yla olu\u015fturulup haz\u0131r hale geldikten sonra, Terraform eski kayna\u011f\u0131 siler. Bu yakla\u015f\u0131m, ge\u00e7i\u015f s\u0131ras\u0131nda en az bir \u00e7al\u0131\u015f\u0131r durumda kayna\u011f\u0131n her zaman mevcut olmas\u0131n\u0131 sa\u011flayarak, hizmet kesintisi riskini en aza indirir veya tamamen ortadan kald\u0131r\u0131r. Bu \u00f6zellikle y\u00fck dengeleyiciler arkas\u0131ndaki sunucu gruplar\u0131, veritabanlar\u0131 veya di\u011fer kritik servisler i\u00e7in hayati \u00f6neme sahiptir. Y\u00fcksek trafikli web siteleri, API servisleri ve mikroservis mimarileri gibi s\u00fcrekli eri\u015filebilir olmas\u0131 gereken uygulamalar i\u00e7in bu \u00f6zellik vazge\u00e7ilmezdir.<\/p>\n
Uygulama \u00d6rne\u011fi: AWS EC2 Instance Tipi G\u00fcncelleme<\/strong><\/p>\n
Bir web sunucunuz var ve performans iyile\u015ftirmesi i\u00e7in instance tipini t2.micro<\/code>'dan t2.medium<\/code>'a y\u00fckseltmeniz gerekiyor. Bu, genellikle mevcut instance'\u0131n sonland\u0131r\u0131l\u0131p yenisinin olu\u015fturulmas\u0131n\u0131 gerektiren bir de\u011fi\u015fikliktir. Kesintisiz bir g\u00fcncelleme sa\u011flamak i\u00e7in create_before_destroy<\/code> kullanabiliriz:<\/p>\n
\nresource \"aws_instance\" \"web_server_prod\" {\n  ami           = \"ami-0abcdef1234567890\" # \u00d6rnek AMI ID\n  instance_type = \"t2.medium\" # Eskiden t2.micro idi, \u015fimdi t2.medium\n\n  tags = {\n    Name        = \"ProductionWebServer\"\n    Environment = \"Production\"\n  }\n\n  lifecycle {\n    create_before_destroy = true\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Yukar\u0131daki kod blo\u011funu uygulad\u0131\u011f\u0131n\u0131zda, Terraform \u00f6nce yeni bir t2.medium<\/code> EC2 instance olu\u015fturacak, bu instance tamamen haz\u0131r oldu\u011funda (sa\u011flay\u0131c\u0131n\u0131n kaynak olu\u015fturma mant\u0131\u011f\u0131na ba\u011fl\u0131 olarak), eski t2.micro<\/code> instance'\u0131 sonland\u0131racakt\u0131r. Bu s\u00fcre\u00e7, uygulaman\u0131z\u0131n kesintisiz hizmet vermeye devam etmesini sa\u011flar. Y\u00fck dengeleyicilerle birlikte kullan\u0131ld\u0131\u011f\u0131nda, trafik yeni instance'a y\u00f6nlendirilirken eski instance g\u00fcvenle kald\u0131r\u0131labilir. Bu, bir t\u00fcr \"mavi\/ye\u015fil da\u011f\u0131t\u0131m\" stratejisinin basitle\u015ftirilmi\u015f bir formudur ve hizmet kalitesini art\u0131r\u0131r. Bu \u00f6zellik, altyap\u0131 g\u00fcncellemelerinin daha az riskli ve daha \u00f6ng\u00f6r\u00fclebilir olmas\u0131n\u0131 sa\u011flar, bu da DevOps ekipleri i\u00e7in b\u00fcy\u00fck bir kolayl\u0131kt\u0131r.<\/p>\n
Vaka Analizi: Mikroservis G\u00fcncelleme ve S\u0131f\u0131r Kesinti<\/strong><\/p>\n
B\u00fcy\u00fck bir SaaS \u015firketi, y\u00fczlerce mikroservis kullanarak bulut tabanl\u0131 bir platform sunmaktad\u0131r. S\u00fcrekli geli\u015ftirme ve da\u011f\u0131t\u0131m d\u00f6ng\u00fcs\u00fcnde, her hafta birden fazla mikroservis g\u00fcncellenmektedir. Bu g\u00fcncellemelerin her biri, ilgili servis kaynaklar\u0131n\u0131n (\u00f6rne\u011fin, AWS ECS Fargate servisleri, EC2 auto-scaling gruplar\u0131) yeni versiyonlar\u0131yla de\u011fi\u015ftirilmesini gerektirir. \u015eirket, t\u00fcm mikroservis da\u011f\u0131t\u0131mlar\u0131nda create_before_destroy<\/code> kural\u0131n\u0131 aktif olarak kullanmaktad\u0131r. \u00d6rne\u011fin, bir API gateway hizmetinin temel ald\u0131\u011f\u0131 EC2 instance'lar\u0131n\u0131n AMI'si veya instance tipi g\u00fcncellenmesi gerekti\u011finde, Terraform \u00f6nce yeni konfig\u00fcrasyona sahip instance'lar\u0131 olu\u015fturur. Bu yeni instance'lar, y\u00fck dengeleyicinin arkas\u0131nda sa\u011fl\u0131kl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmaya ba\u015flad\u0131\u011f\u0131nda, eski instance'lar otomatik olarak sonland\u0131r\u0131l\u0131r. Bu sayede, hi\u00e7bir zaman serviste bir kesinti ya\u015fanmaz, kullan\u0131c\u0131lar g\u00fcncelleme s\u00fcre\u00e7lerinden etkilenmez ve \u015firket, s\u0131f\u0131r kesinti hedefini ba\u015far\u0131yla s\u00fcrd\u00fcr\u00fcr. Bu vaka, create_before_destroy<\/code>'un modern, y\u00fcksek \u00f6l\u00e7ekli ve s\u00fcrekli da\u011f\u0131t\u0131m yap\u0131lan ortamlardaki kritik rol\u00fcn\u00fc m\u00fckemmel bir \u015fekilde \u00f6zetlemektedir.<\/p>\n
Geli\u015fmi\u015f Terraform Lifecycle Senaryolar\u0131 ve En \u0130yi Uygulamalar<\/h2>\nTerraform lifecycle kurallar\u0131, sadece tek ba\u015f\u0131na kullan\u0131ld\u0131\u011f\u0131nda de\u011fil, ayn\u0131 zamanda bir araya getirildi\u011finde ve dikkatli bir \u015fekilde uyguland\u0131\u011f\u0131nda ger\u00e7ek potansiyelini ortaya koyar. Geli\u015fmi\u015f senaryolar, karma\u015f\u0131k altyap\u0131 gereksinimlerini kar\u015f\u0131lamak ve daha esnek, dayan\u0131kl\u0131 sistemler kurmak i\u00e7in bu kurallar\u0131n nas\u0131l birle\u015ftirilebilece\u011fini g\u00f6sterir. Bu b\u00f6l\u00fcmde, lifecycle kurallar\u0131n\u0131 daha etkin kullanmak i\u00e7in baz\u0131 ileri d\u00fczey teknikleri ve en iyi uygulamalar\u0131 ele alaca\u011f\u0131z.<\/p>\n
Lifecycle Kurallar\u0131n\u0131 Birle\u015ftirmek: G\u00fcvenlik ve S\u00fcreklilik<\/strong><\/p>\n
Bir kaynak i\u00e7in birden fazla lifecycle kural\u0131n\u0131 birle\u015ftirmek olduk\u00e7a yayg\u0131n bir senaryodur. \u00d6rne\u011fin, kritik bir veritaban\u0131n\u0131n hem yanl\u0131\u015fl\u0131kla silinmesini \u00f6nlemek hem de g\u00fcncellemeleri kesintisiz yapmak isteyebilirsiniz. Bu durumda, prevent_destroy<\/code> ve create_before_destroy<\/code> arg\u00fcmanlar\u0131n\u0131 ayn\u0131 kaynak blo\u011fu i\u00e7inde kullanabilirsiniz:<\/p>\n
\nresource \"aws_rds_instance\" \"production_db\" {\n  allocated_storage    = 20\n  engine               = \"mysql\"\n  engine_version       = \"8.0\"\n  instance_class       = \"db.t3.medium\"\n  name                 = \"mydb\"\n  username             = \"admin\"\n  password             = \"MyStrongPassword123\" # Ger\u00e7ek projelerde Vault gibi bir ara\u00e7 kullan\u0131n!\n  skip_final_snapshot  = true\n  publicly_accessible  = false\n\n  lifecycle {\n    prevent_destroy       = true\n    create_before_destroy = true\n    ignore_changes = [\n      password, # \u015eifrelerin Terraform d\u0131\u015f\u0131nda y\u00f6netildi\u011fi senaryolar i\u00e7in\n    ]\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Bu \u00f6rnekte, production_db<\/code> hem silinmeye kar\u015f\u0131 korunur hem de instance_class gibi in-place g\u00fcncellenemeyen \u00f6zellikler de\u011fi\u015ftirildi\u011finde kesintisiz bir g\u00fcncelleme sa\u011flan\u0131r. Ayr\u0131ca, \u015fifre de\u011fi\u015fikli\u011fi gibi harici y\u00f6netim s\u00fcre\u00e7lerine b\u0131rak\u0131lan nitelikler de Terraform taraf\u0131ndan g\u00f6z ard\u0131 edilir. Bu kombinasyon, hem g\u00fcvenli\u011fi hem de operasyonel s\u00fcreklili\u011fi ayn\u0131 anda sa\u011flaman\u0131n g\u00fc\u00e7l\u00fc bir yoludur. Ancak, bu t\u00fcr bir kombinasyonun her zaman dikkatli bir \u015fekilde test edilmesi gerekti\u011fini unutmamak \u00f6nemlidir, \u00e7\u00fcnk\u00fc farkl\u0131 kurallar aras\u0131ndaki etkile\u015fimler bazen beklenmedik sonu\u00e7lar do\u011furabilir. \u00d6zellikle ignore_changes<\/code> ile birlikte kullan\u0131ld\u0131\u011f\u0131nda, Terraform'un neyi izleyip neyi izlemedi\u011fini net bir \u015fekilde anlamak kritik \u00f6neme sahiptir. Karma\u015f\u0131k altyap\u0131larda, bu t\u00fcr ince ayarlar, sistemin genel istikrar\u0131n\u0131 ve y\u00f6netim kolayl\u0131\u011f\u0131n\u0131 do\u011frudan etkiler.<\/p>\n
Ko\u015fullu Lifecycle Bloklar\u0131 ve Dinamik Y\u00f6netim<\/strong><\/p>\n
count<\/code> veya for_each<\/code> gibi meta-arg\u00fcmanlarla birlikte lifecycle bloklar\u0131n\u0131 kullanarak kaynaklar\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc dinamik olarak kontrol edebilirsiniz. \u00d6rne\u011fin, sadece \u00fcretim ortam\u0131ndaki kaynaklar\u0131 silinmeye kar\u015f\u0131 korumak isteyebilirsiniz:<\/p>\n
\nvariable \"environment\" {\n  description = \"Da\u011f\u0131t\u0131m ortam\u0131 (dev, staging, prod)\"\n  type        = string\n  default     = \"dev\"\n}\n\nresource \"aws_s3_bucket\" \"my_bucket\" {\n  bucket = \"${var.environment}-my-unique-bucket-name\"\n  acl    = \"private\"\n\n  lifecycle {\n    prevent_destroy = var.environment == \"prod\" ? true : false\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Bu \u00f6rnekte, my_bucket<\/code> kayna\u011f\u0131 yaln\u0131zca environment<\/code> de\u011fi\u015fkeni \"prod\" oldu\u011funda prevent_destroy<\/code> korumas\u0131na sahip olacakt\u0131r. Bu yakla\u015f\u0131m, farkl\u0131 ortamlar i\u00e7in farkl\u0131 g\u00fcvenlik politikalar\u0131 uygulamak istedi\u011finizde olduk\u00e7a esneklik sa\u011flar. Geli\u015ftirme veya test ortamlar\u0131nda kaynaklar\u0131 serbest\u00e7e silerken, \u00fcretim ortam\u0131nda kat\u0131 kurallar uygulayabilirsiniz. Bu t\u00fcr dinamik yap\u0131land\u0131rmalar, kod taban\u0131n\u0131z\u0131 daha mod\u00fcler ve yeniden kullan\u0131labilir hale getirir.<\/p>\n
replace_triggered_by<\/code> Kullan\u0131m\u0131<\/strong><\/p>\n
Terraform 1.2 ve sonras\u0131 s\u00fcr\u00fcmlerde tan\u0131t\u0131lan replace_triggered_by<\/code> arg\u00fcman\u0131, dolayl\u0131 ba\u011f\u0131ml\u0131l\u0131klar nedeniyle bir kayna\u011f\u0131n yenilenmesini (create-before-destroy veya destroy-then-create) a\u00e7\u0131k\u00e7a tetiklemek i\u00e7in kullan\u0131l\u0131r. Bu, \u00f6zellikle bir kaynak \u00fczerinde yap\u0131lan bir de\u011fi\u015fikli\u011fin, onunla do\u011frudan ba\u011f\u0131ml\u0131 olmayan ancak yap\u0131land\u0131rmas\u0131n\u0131 etkileyen ba\u015fka bir kayna\u011f\u0131n yeniden olu\u015fturulmas\u0131n\u0131 gerektirdi\u011fi senaryolarda faydal\u0131d\u0131r.<\/p>\n
\nresource \"aws_ami_from_instance\" \"example\" {\n  source_instance_id = aws_instance.example.id\n}\n\nresource \"aws_launch_configuration\" \"example\" {\n  image_id        = aws_ami_from_instance.example.id\n  instance_type   = \"t2.micro\"\n  \n  lifecycle {\n    create_before_destroy = true\n    replace_triggered_by = [\n      aws_ami_from_instance.example.id\n    ]\n  }\n}\n<\/pre>\n<\/code><\/p>\n
Burada, yeni bir AMI olu\u015fturuldu\u011funda, aws_launch_configuration.example<\/code>'\u0131n da yenilenmesi gerekti\u011fini belirtiyoruz, b\u00f6ylece oto-scaling grubu yeni AMI ile yeni instance'lar ba\u015flatabilir. Bu, g\u00fcncellemeler s\u0131ras\u0131nda do\u011fru s\u0131ralaman\u0131n ve tutarl\u0131l\u0131\u011f\u0131n sa\u011flanmas\u0131 i\u00e7in \u00f6nemlidir.<\/p>\n
Mobil Uyumlu Altyap\u0131 Y\u00f6netimi: Responsive Terraform \u00c7\u0131kt\u0131lar\u0131 Nas\u0131l G\u00f6r\u00fcn\u00fcr?<\/h3>\nTerraform do\u011frudan mobil uyumlu \u00e7\u0131kt\u0131lar \u00fcretmese de, Terraform'un y\u00f6netti\u011fi altyap\u0131 bilgilerini g\u00f6steren dashboard'lar veya raporlar mobil uyumlu olabilir. Bu, HTML \u00e7\u0131kt\u0131lar\u0131n veya web aray\u00fczlerinin responsive tasar\u0131m prensipleriyle olu\u015fturulmas\u0131 anlam\u0131na gelir. \u00d6rne\u011fin, Terraform plan \u00e7\u0131kt\u0131lar\u0131n\u0131n, state bilgilerinin veya altyap\u0131 envanterlerinin g\u00f6r\u00fcnt\u00fclendi\u011fi bir web paneli i\u00e7in CSS medya sorgular\u0131 kullan\u0131labilir:<\/p>\n
\n