Bulut altyap\u0131n\u0131z\u0131 y\u00f6netirken, s\u00fcrekli yeni kaynaklar olu\u015fturman\u0131n getirdi\u011fi yorgunlu\u011fu ve karma\u015f\u0131kl\u0131\u011f\u0131 hi\u00e7 hissettiniz mi? Mevcut kaynaklar\u0131 tekrar tekrar tan\u0131mlamak yerine, onlar\u0131 ak\u0131ll\u0131ca ke\u015ffetmek ve kullanmak, hem zamandan tasarruf etmenizi hem de altyap\u0131n\u0131z\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rman\u0131z\u0131 sa\u011flar. \u0130\u015fte bu noktada Terraform Veri Kaynaklar\u0131 devreye giriyor ve size “yeniden yaratma” d\u00f6ng\u00fcs\u00fcnden kurtulman\u0131n anahtar\u0131n\u0131 sunuyor.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen dijital d\u00fcnyas\u0131nda, bulut altyap\u0131s\u0131 y\u00f6netimi hi\u00e7 olmad\u0131\u011f\u0131 kadar kritik bir hale geldi. Geli\u015ftiriciler ve operasyon ekipleri, s\u00fcrekli olarak yeni sunucular, veritabanlar\u0131, a\u011f bile\u015fenleri ve di\u011fer hizmetler olu\u015fturmak, g\u00fcncellemek veya silmekle me\u015fgul. Bu s\u00fcre\u00e7lerin manuel olarak yap\u0131lmas\u0131 hem zaman al\u0131c\u0131 hem de hataya a\u00e7\u0131k. \u0130\u015fte bu y\u00fczden “Altyap\u0131 Kod Olarak” (Infrastructure as Code – IaC) yakla\u015f\u0131mlar\u0131, \u00f6zellikle de Terraform gibi ara\u00e7lar, altyap\u0131 y\u00f6netiminde devrim yaratt\u0131. Terraform sayesinde, altyap\u0131m\u0131z\u0131 insan taraf\u0131ndan okunabilir konfig\u00fcrasyon dosyalar\u0131yla tan\u0131mlayabiliyor, s\u00fcr\u00fcm kontrol sistemlerinde saklayabiliyor ve otomatik s\u00fcre\u00e7lerle da\u011f\u0131tabiliyoruz. Bu, kaynaklar\u0131 deterministik bir \u015fekilde olu\u015fturmak, de\u011fi\u015ftirmek ve yok etmek i\u00e7in harika bir yol sunuyor.<\/p>\n
Ancak, her zaman s\u0131f\u0131rdan bir \u015feyler yaratmak zorunda m\u0131y\u0131z? \u00c7o\u011fu zaman var olan bir sanal \u00f6zel a\u011f\u0131 (VPC), bir g\u00fcvenlik grubunu, bir veritaban\u0131 yede\u011fini veya bir depolama kovas\u0131n\u0131 referans almam\u0131z gerekir. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131 da\u011f\u0131t\u0131rken, uygulaman\u0131n \u00e7al\u0131\u015faca\u011f\u0131 VPC’nin ID’sini, uygulaman\u0131n eri\u015fmesi gereken veritaban\u0131n\u0131n endpoint’ini veya kullan\u0131c\u0131lar\u0131n y\u00fckleyece\u011fi dosyalar\u0131n depolanaca\u011f\u0131 S3 kovas\u0131n\u0131n ad\u0131n\u0131 bilmemiz ve kullanmam\u0131z gerekir. E\u011fer bu kaynaklar ba\u015fka bir Terraform mod\u00fcl\u00fc, manuel olarak ya da farkl\u0131 bir ekip taraf\u0131ndan olu\u015fturulduysa, bunlar\u0131 kendi Terraform kodunuzda nas\u0131l g\u00fcvenli ve dinamik bir \u015fekilde kullanacaks\u0131n\u0131z? \u0130\u015fte burada klasik Tam da bu noktada, Terraform’un sundu\u011fu g\u00fc\u00e7l\u00fc bir \u00f6zellik olan “Veri Kaynaklar\u0131” (Data Sources) kurtar\u0131c\u0131m\u0131z oluyor. Veri kaynaklar\u0131, Terraform’a halihaz\u0131rda var olan altyap\u0131 bile\u015fenleri hakk\u0131nda bilgi sorgulama ve bu bilgiyi kendi konfig\u00fcrasyonunuzda kullanma yetene\u011fi sa\u011flar. Bu sayede, ayn\u0131 VPC’yi veya g\u00fcvenlik grubunu tekrar tekrar olu\u015fturmak yerine, basit\u00e7e ona referans verebilirsiniz. Bu yakla\u015f\u0131m, altyap\u0131n\u0131z\u0131 daha mod\u00fcler, daha okunabilir ve daha az hataya a\u00e7\u0131k hale getirir. Mevcut kaynaklar\u0131 dinamik olarak ke\u015ffetmek, ba\u011f\u0131ml\u0131l\u0131klar\u0131 azalt\u0131r ve farkl\u0131 ekipler veya projeler aras\u0131nda i\u015fbirli\u011fini kolayla\u015ft\u0131r\u0131r. B\u00f6ylece, gereksiz “yaratma” s\u00fcre\u00e7lerini durdurarak, daha verimli ve tutarl\u0131 bir altyap\u0131 y\u00f6netimi stratejisi benimseyebiliriz. Bu makalede, Terraform veri kaynaklar\u0131n\u0131n ne oldu\u011funu, nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l kullan\u0131labilece\u011fini ad\u0131m ad\u0131m inceleyece\u011fiz. Haydi, s\u00fcrekli yeniden in\u015fa etme d\u00f6ng\u00fcs\u00fcn\u00fc k\u0131rma yolculu\u011fumuza ba\u015flayal\u0131m.<\/p>\n Terraform d\u00fcnyas\u0131nda, altyap\u0131 bile\u015fenlerini y\u00f6netmenin iki ana yolu vard\u0131r: Peki, bu tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131r? Bir Daha somut bir \u00f6rnekle a\u00e7\u0131klayal\u0131m: Bir AWS EC2 \u00f6rne\u011fi olu\u015fturmak istiyorsunuz ve bu \u00f6rne\u011fin belirli bir VPC i\u00e7inde olmas\u0131 gerekiyor. Bu VPC’yi ba\u015fka bir Terraform mod\u00fcl\u00fc \u00e7oktan olu\u015fturmu\u015f olabilir veya siz onu manuel olarak AWS konsolundan kurmu\u015f olabilirsiniz. E\u011fer bu VPC’yi kendi Terraform dosyan\u0131zda Bu yetenek, altyap\u0131 kodunuzun mod\u00fclerli\u011fini ve yeniden kullan\u0131labilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Farkl\u0131 mod\u00fcller veya projeler, birbirinden ba\u011f\u0131ms\u0131z olarak \u00e7al\u0131\u015fabilir ancak ayn\u0131 temel altyap\u0131 bile\u015fenlerine referans verebilir. Ayr\u0131ca, bu, bir kaynak grubunun veya departman\u0131n payla\u015f\u0131lan altyap\u0131y\u0131 (a\u011f, kimlik y\u00f6netimi gibi) y\u00f6netti\u011fi, di\u011ferlerinin ise bu altyap\u0131y\u0131 kullanarak kendi uygulamalar\u0131n\u0131 da\u011f\u0131tt\u0131\u011f\u0131 senaryolarda i\u015fbirli\u011fini kolayla\u015ft\u0131r\u0131r. Bir veri kayna\u011f\u0131 kulland\u0131\u011f\u0131n\u0131zda, Terraform’un planlama a\u015famas\u0131nda ( Terraform veri kaynaklar\u0131n\u0131n teorik temelini anlad\u0131ktan sonra, \u015fimdi pratik uygulamalar\u0131na ge\u00e7elim. Bir veri kayna\u011f\u0131n\u0131 kullanman\u0131n temel ad\u0131mlar\u0131 olduk\u00e7a basittir, ancak altyap\u0131n\u0131zda b\u00fcy\u00fck bir fark yaratabilir. Amac\u0131m\u0131z, mevcut bir AWS VPC’sini bulmak ve bu VPC’nin ID’sini ba\u015fka bir kaynakta kullanmakt\u0131r. Bu senaryo, a\u011f altyap\u0131s\u0131n\u0131n genellikle merkezi bir ekip taraf\u0131ndan y\u00f6netildi\u011fi ve di\u011fer ekiplerin bu a\u011f \u00fczerinde kendi servislerini da\u011f\u0131tt\u0131\u011f\u0131 b\u00fcy\u00fck kurulu\u015flarda \u00e7ok yayg\u0131nd\u0131r.<\/p>\n \u0130lk olarak, Terraform’un AWS sa\u011flay\u0131c\u0131s\u0131n\u0131 yap\u0131land\u0131rmam\u0131z gerekiyor. Ard\u0131ndan, hedef VPC’yi tan\u0131mlayacak kriterleri belirleyece\u011fiz. \u00d6rne\u011fin, bir VPC’yi ad\u0131 veya etiketleri arac\u0131l\u0131\u011f\u0131yla bulabiliriz. Diyelim ki, “UretimVPC” ad\u0131nda bir VPC’miz var ve biz bu VPC’nin ID’sine ihtiyac\u0131m\u0131z var.<\/p>\n <\/code><\/p>\n Yukar\u0131daki kod blo\u011funda neler oldu\u011funa bir bakal\u0131m:<\/p>\n Bu konfig\u00fcrasyonu uygulad\u0131ktan sonra ( <\/code><\/p>\n Bu zincirleme kullan\u0131m, altyap\u0131n\u0131z\u0131n mod\u00fclerli\u011fini ve okunabilirli\u011fini art\u0131r\u0131r. Mevcut bir VPC'ye veya alt a\u011fa ba\u011fl\u0131 olan her yeni kaynak, kendi i\u00e7inde bunlar\u0131 yeniden tan\u0131mlamak yerine, veri kaynaklar\u0131 arac\u0131l\u0131\u011f\u0131yla bu bilgilere ula\u015fabilir. Bu, \"yaratma\" d\u00f6ng\u00fcs\u00fcn\u00fc durdurarak, \"referans verme\" ve \"yeniden kullanma\" d\u00f6ng\u00fcs\u00fcn\u00fc ba\u015flat\u0131r. Bu yakla\u015f\u0131m, karma\u015f\u0131k altyap\u0131 ortamlar\u0131nda tutarl\u0131l\u0131\u011f\u0131 sa\u011flamak ve manuel hata riskini azaltmak i\u00e7in vazge\u00e7ilmezdir. Dolay\u0131s\u0131yla, bir veri kayna\u011f\u0131n\u0131n g\u00fcc\u00fc, sadece mevcut bir bilgiyi okumakla kalmay\u0131p, bu bilgiyi di\u011fer kaynaklar\u0131n\u0131z i\u00e7in bir girdi olarak kullanarak altyap\u0131 tan\u0131m\u0131n\u0131z\u0131 \u00e7ok daha dinamik hale getirmesidir.<\/p>\n Terraform veri kaynaklar\u0131n\u0131n ger\u00e7ek d\u00fcnyadaki bir di\u011fer g\u00fc\u00e7l\u00fc kullan\u0131m durumu, mevcut bir AWS S3 kovas\u0131n\u0131 referans almakt\u0131r. S3 kovalar\u0131 genellikle statik web siteleri, yedeklemeler veya uygulama verileri i\u00e7in kullan\u0131l\u0131r ve \u00e7o\u011fu zaman farkl\u0131 ekipler veya s\u00fcre\u00e7ler taraf\u0131ndan \u00f6nceden olu\u015fturulmu\u015f olabilir. Diyelim ki, bir uygulaman\u0131z var ve bu uygulama, belirli bir S3 kovas\u0131na eri\u015fmek i\u00e7in bir IAM politikas\u0131na ihtiya\u00e7 duyuyor. S3 kovas\u0131n\u0131n kendisi zaten mevcut ve ad\u0131n\u0131 biliyoruz.<\/p>\n Bu senaryoda, S3 kovas\u0131n\u0131 yeniden olu\u015fturmak yerine, bir veri kayna\u011f\u0131 olarak sorgulayarak onun Amazon Kaynak Ad\u0131'n\u0131 (ARN) veya web sitesi u\u00e7 noktas\u0131n\u0131 alabiliriz. Bu bilgiyi daha sonra bir IAM politikas\u0131 olu\u015ftururken kullanabiliriz, b\u00f6ylece uygulaman\u0131n sadece belirli kovaya eri\u015fimi olur.<\/p>\n <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte:<\/p>\n Bu yakla\u015f\u0131m, g\u00fcvenlik politikalar\u0131n\u0131, kaynak adland\u0131rma standartlar\u0131n\u0131 ve genel altyap\u0131 mimarisini korurken, yeni uygulamalar\u0131n mevcut altyap\u0131 bile\u015fenlerini kolayca kullanmas\u0131n\u0131 sa\u011flar. Uygulama geli\u015ftiricileri veya farkl\u0131 altyap\u0131 ekipleri, bir S3 kovas\u0131n\u0131n nas\u0131l olu\u015fturuldu\u011funu bilmek zorunda kalmazlar; sadece onun ad\u0131na veya belirli bir \u00f6zelli\u011fine g\u00f6re onu sorgulayarak gerekli bilgilere ula\u015fabilirler. Bu, \u00f6zellikle b\u00fcy\u00fck ve da\u011f\u0131t\u0131k ortamlarda \u00e7ok katmanl\u0131 altyap\u0131 y\u00f6netimini basitle\u015ftiren g\u00fc\u00e7l\u00fc bir y\u00f6ntemdir. \u00d6zetle, veri kaynaklar\u0131 sadece bilgi edinmekle kalmaz, ayn\u0131 zamanda farkl\u0131 Terraform mod\u00fclleri ve altyap\u0131 bile\u015fenleri aras\u0131nda esnek ve sa\u011flam ba\u011flant\u0131lar kurman\u0131n temelini olu\u015fturur.<\/p>\n Bulut ortamlar\u0131nda sadece AWS gibi ana sa\u011flay\u0131c\u0131larla de\u011fil, ayn\u0131 zamanda Kubernetes gibi platformlarla da s\u0131k\u00e7a \u00e7al\u0131\u015f\u0131r\u0131z. Kubernetes, kapsay\u0131c\u0131l\u0131 uygulamalar\u0131 y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir orkestrasyon arac\u0131d\u0131r ve s\u0131kl\u0131kla hassas bilgileri (veritaban\u0131 \u015fifreleri, API anahtarlar\u0131 vb.) \"Secret\" objelerinde saklar. Bir\u00e7ok senaryoda, bir Secret'\u0131 manuel olarak veya ba\u015fka bir CI\/CD arac\u0131yla Kubernetes'e da\u011f\u0131tm\u0131\u015f olabiliriz, ancak Terraform ile yeni bir Kubernetes da\u011f\u0131t\u0131m\u0131 olu\u015ftururken bu Secret'\u0131n i\u00e7eri\u011fine eri\u015fmek isteriz.<\/p>\n Bu, veri kaynaklar\u0131n\u0131n sadece bulut sa\u011flay\u0131c\u0131lar\u0131 i\u00e7in de\u011fil, ayn\u0131 zamanda Kubernetes gibi platformlar i\u00e7in de ne kadar \u00e7ok y\u00f6nl\u00fc oldu\u011funu g\u00f6steren harika bir \u00f6rnektir. Diyelim ki, <\/code><\/p>\n Yukar\u0131daki Terraform kodunda \u015funlar\u0131 yap\u0131yoruz:<\/p>\n Bu, veri kaynaklar\u0131n\u0131n sadece mevcut altyap\u0131 hakk\u0131nda bilgi edinmekle kalmay\u0131p, ayn\u0131 zamanda bu bilgiyi hassas verilerin g\u00fcvenli bir \u015fekilde aktar\u0131lmas\u0131 ve altyap\u0131 kodunda dinamik olarak kullan\u0131lmas\u0131 i\u00e7in nas\u0131l bir k\u00f6pr\u00fc g\u00f6revi g\u00f6rd\u00fc\u011f\u00fcn\u00fc g\u00f6sterir. Uygulamalar\u0131n\u0131z\u0131n farkl\u0131 ortamlar i\u00e7in farkl\u0131 Secret'lara ihtiyac\u0131 oldu\u011funda, bu veri kaynaklar\u0131 yakla\u015f\u0131m\u0131, ayn\u0131 Terraform kodunu farkl\u0131 Secret'lar\u0131 i\u015faret edecek \u015fekilde yeniden kullanarak esneklik sa\u011flar. Bu y\u00f6ntemle, Secret'lar\u0131 Terraform state dosyas\u0131na kaydetmekten ka\u00e7\u0131n\u0131rken (ki bu g\u00fcvenlik a\u00e7\u0131s\u0131ndan iyi bir uygulamad\u0131r), yine de da\u011f\u0131t\u0131mlar\u0131n\u0131z i\u00e7in gerekli olan hassas verilere programl\u0131 bir \u015fekilde eri\u015febilirsiniz. Bu, s\u00fcrekli yeni Secret'lar yaratma veya manuel olarak kopyalama-yap\u0131\u015ft\u0131rma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r, b\u00f6ylece daha g\u00fcvenli ve otomatik bir i\u015f ak\u0131\u015f\u0131 sa\u011flar.<\/p>\n Terraform veri kaynaklar\u0131, sadece temel bilgileri \u00e7ekmekten \u00e7ok daha fazlas\u0131n\u0131 yapabilir. Onlar\u0131 stratejik olarak kullanarak altyap\u0131n\u0131z\u0131n esnekli\u011fini, g\u00fcvenli\u011fini ve y\u00f6netilebilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilirsiniz. \u0130\u015fte deneyimli kullan\u0131c\u0131lar i\u00e7in baz\u0131 ipu\u00e7lar\u0131 ve en iyi uygulamalar:<\/p>\n \u00c7o\u011fu veri kayna\u011f\u0131, <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, Veri kaynaklar\u0131, farkl\u0131 Terraform yap\u0131land\u0131rmalar\u0131, \u00e7al\u0131\u015fma alanlar\u0131 veya hatta farkl\u0131 bulut hesaplar\u0131 aras\u0131ndaki kaynaklara \u00e7apraz referans vermek i\u00e7in m\u00fckemmeldir. \u00d6rne\u011fin, bir DevOps ekibi ortak a\u011f altyap\u0131s\u0131n\u0131 y\u00f6netirken (VPC'ler, alt a\u011flar, y\u00f6nlendirme tablolar\u0131), uygulama ekipleri bu mevcut a\u011f kaynaklar\u0131na veri kaynaklar\u0131 arac\u0131l\u0131\u011f\u0131yla referans verebilir. Bu, monolitik Terraform durum dosyalar\u0131ndan ka\u00e7\u0131narak daha mod\u00fcler ve y\u00f6netilebilir bir mimari sa\u011flar.<\/p>\n Mod\u00fcler yap\u0131da, bir mod\u00fcl \u00e7\u0131kt\u0131s\u0131n\u0131 ba\u015fka bir mod\u00fclde girdi olarak kullanmak yerine, do\u011frudan kaynaklar\u0131 veri kaynaklar\u0131 ile sorgulamak daha g\u00fcvenli ve dinamik olabilir. Bu sayede mod\u00fcller aras\u0131ndaki kat\u0131 ba\u011f\u0131ml\u0131l\u0131klar azal\u0131r.<\/p>\n Daha \u00f6nce Kubernetes Secret \u00f6rne\u011finde g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, veri kaynaklar\u0131 hassas verileri do\u011frudan Terraform state'inde saklamadan kullanman\u0131za olanak tan\u0131r. \u00d6rne\u011fin, bir veritaban\u0131 \u015fifresini bir AWS Secrets Manager'dan veya HashiCorp Vault'tan \u00e7ekebilirsiniz. Bu, g\u00fcvenlik en iyi uygulamalar\u0131na uygun bir yakla\u015f\u0131md\u0131r:<\/p>\n <\/code><\/p>\n Terraform Bu ipu\u00e7lar\u0131 ve en iyi uygulamalar, Terraform veri kaynaklar\u0131n\u0131n potansiyelini tam olarak kullanman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Mevcut altyap\u0131n\u0131z\u0131 daha ak\u0131ll\u0131ca entegre ederek, Terraform kodunuzu daha sa\u011flam, daha okunabilir ve daha s\u00fcrd\u00fcr\u00fclebilir hale getirebilirsiniz. \"Her \u015feyi olu\u015fturma\" d\u00fcrt\u00fcs\u00fcnden vazge\u00e7erek, \"var olan\u0131 ak\u0131ll\u0131ca kullanma\" sanat\u0131nda ustala\u015f\u0131n.<\/p>\n Bu makale boyunca, Terraform veri kaynaklar\u0131n\u0131n (Data Sources) ne oldu\u011funu, neden bu kadar \u00f6nemli oldu\u011funu ve altyap\u0131 y\u00f6netim s\u00fcre\u00e7lerimizde bize nas\u0131l b\u00fcy\u00fck kolayl\u0131klar sa\u011flad\u0131\u011f\u0131n\u0131 detayl\u0131 bir \u015fekilde inceledik. \"Her \u015eeyi Olu\u015fturmay\u0131 Durdur\" felsefesiyle yola \u00e7\u0131karak, veri kaynaklar\u0131n\u0131n sadece bir \u00f6zellik olmaktan \u00f6te, modern altyap\u0131 otomasyonu i\u00e7in temel bir paradigma de\u011fi\u015fikli\u011fi sundu\u011funu g\u00f6rd\u00fck.<\/p>\n \u00d6zetle, veri kaynaklar\u0131 sayesinde:<\/p>\n Terraform veri kaynaklar\u0131, altyap\u0131 kodunuzu yaln\u0131zca \"olu\u015fturma\" ve \"yok etme\" yeteneklerinin \u00f6tesine ta\u015f\u0131yarak, \"ke\u015ffetme\" ve \"entegre etme\" yetenekleri kazand\u0131r\u0131r. Bu, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve dinamik bulut ortamlar\u0131nda, altyap\u0131n\u0131z\u0131n daha verimli, daha hatas\u0131z ve daha esnek bir \u015fekilde y\u00f6netilmesini sa\u011flar. Art\u0131k her yeni proje i\u00e7in bir VPC, bir g\u00fcvenlik grubu veya bir veritaban\u0131 yede\u011fi tan\u0131mlaman\u0131za gerek yok. Bunun yerine, mevcut kaynaklar\u0131 ak\u0131ll\u0131ca sorgulayarak, zaman\u0131n\u0131z\u0131 ve enerjinizi ger\u00e7ekten de\u011fer katan yeniliklere odaklayabilirsiniz.<\/p>\n Sonu\u00e7 olarak, Terraform veri kaynaklar\u0131, Altyap\u0131 Kod Olarak prensiplerini bir sonraki seviyeye ta\u015f\u0131yan kritik bir ara\u00e7t\u0131r. Onlar\u0131 altyap\u0131 stratejinizin ayr\u0131lmaz bir par\u00e7as\u0131 haline getirerek, daha ak\u0131ll\u0131, daha g\u00fcvenli ve daha verimli bulut ortamlar\u0131 in\u015fa edebilirsiniz. \"Yaratmaktan \u00e7ok kullanma\" sanat\u0131nda ustala\u015farak, DevOps yolculu\u011funuzda \u00f6nemli bir ad\u0131m atm\u0131\u015f olursunuz.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Bulut altyap\u0131n\u0131z\u0131 y\u00f6netirken, s\u00fcrekli yeni kaynaklar olu\u015fturman\u0131n getirdi\u011fi yorgunlu\u011fu ve karma\u015f\u0131kl\u0131\u011f\u0131 hi\u00e7 hissettiniz mi? Mevcut kaynaklar\u0131 tekrar tekrar…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36092","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nresource<\/code> bloklar\u0131 yetersiz kal\u0131r. Her \u015feyi yeniden tan\u0131mlamaya \u00e7al\u0131\u015fmak, \u00e7ak\u0131\u015fmalara, tutars\u0131zl\u0131klara ve gereksiz karma\u015f\u0131kl\u0131\u011fa yol a\u00e7abilir. \u00dcstelik, s\u00fcrekli mevcut kaynaklar\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 manuel olarak kopyalay\u0131p yap\u0131\u015ft\u0131rmak, IaC’nin temel prensiplerine ayk\u0131r\u0131 bir yakla\u015f\u0131md\u0131r. Bu durum, zamanla y\u00f6netilmesi zorla\u015fan “spagetti altyap\u0131s\u0131”na d\u00f6n\u00fc\u015febilir.<\/p>\nTerraform Veri Kaynaklar\u0131 Tam Olarak Nedir ve Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
resource<\/code> bloklar\u0131 ve data<\/code> bloklar\u0131. Bir resource<\/code> blo\u011fu, Terraform’un bir bulut sa\u011flay\u0131c\u0131s\u0131nda (\u00f6rne\u011fin AWS, Azure, GCP) yeni bir altyap\u0131 bile\u015feni olu\u015fturmas\u0131n\u0131, mevcut bir bile\u015feni de\u011fi\u015ftirmesini veya silmesini belirtirken, bir data<\/code> blo\u011fu tamamen farkl\u0131 bir amaca hizmet eder. Ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, data<\/code> bloklar\u0131, Terraform’un halihaz\u0131rda var olan kaynaklar hakk\u0131nda bilgi “toplamas\u0131na” veya “sorgulamas\u0131na” olanak tan\u0131r. Ba\u015fka bir deyi\u015fle, bir data<\/code> kayna\u011f\u0131 yeni bir \u015fey yaratmaz veya mevcut bir \u015feyi de\u011fi\u015ftirmez; sadece mevcut bir kayna\u011f\u0131n \u00f6zelliklerini okur ve bu bilgiyi Terraform kodunuzun geri kalan\u0131nda kullan\u0131labilir hale getirir.<\/p>\ndata<\/code> blo\u011funu kulland\u0131\u011f\u0131n\u0131zda, Terraform, ilgili sa\u011flay\u0131c\u0131ya (provider) bir API \u00e7a\u011fr\u0131s\u0131 yapar. Bu \u00e7a\u011fr\u0131, belirli kriterlere uyan mevcut bir kayna\u011f\u0131 (\u00f6rne\u011fin, belirli bir etiketle i\u015faretlenmi\u015f bir VPC veya belirli bir ada sahip bir g\u00fcvenlik grubu) bulmak i\u00e7in kullan\u0131l\u0131r. Sa\u011flay\u0131c\u0131, bu kriterlere uyan kayna\u011f\u0131 buldu\u011funda, onun t\u00fcm \u00f6zniteliklerini (ID, ad, durum, ayarlar vb.) Terraform’a geri d\u00f6nd\u00fcr\u00fcr. Terraform bu bilgiyi al\u0131r ve bunu, t\u0131pk\u0131 yeni olu\u015fturulmu\u015f bir resource<\/code> blo\u011funun \u00e7\u0131kt\u0131lar\u0131 gibi, di\u011fer Terraform bloklar\u0131n\u0131zda referans verebilece\u011finiz bir nesne olarak kullan\u0131ma sunar. Bu, \u00f6zellikle farkl\u0131 Terraform yap\u0131land\u0131rmalar\u0131 taraf\u0131ndan veya hatta Terraform d\u0131\u015f\u0131nda manuel olarak olu\u015fturulmu\u015f altyap\u0131 bile\u015fenlerine ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek i\u00e7in son derece g\u00fc\u00e7l\u00fc bir mekanizmad\u0131r.<\/p>\nresource \"aws_vpc\" \"my_vpc\"<\/code> \u015feklinde yeniden tan\u0131mlamaya \u00e7al\u0131\u015f\u0131rsan\u0131z, Terraform mevcut VPC’yi tespit edemez ve size \u00e7ak\u0131\u015fma hatas\u0131 verir ya da yanl\u0131\u015fl\u0131kla yeni bir VPC olu\u015fturmaya \u00e7al\u0131\u015f\u0131r. Oysa, data \"aws_vpc\" \"existing_vpc\"<\/code> blo\u011funu kullanarak, mevcut VPC’yi belirli etiketler veya ID’si ile sorgulayabilir ve onun ID’sini elde edebilirsiniz. B\u00f6ylece EC2 \u00f6rne\u011finizi olu\u015ftururken bu VPC’nin ID’sini kullan\u0131rs\u0131n\u0131z, yeni bir tane yaratmak zorunda kalmazs\u0131n\u0131z.<\/p>\nterraform plan<\/code>) ilgili sa\u011flay\u0131c\u0131ya sorgu g\u00f6nderilir ve mevcut kaynak bilgisi al\u0131n\u0131r. Bu sayede, plan \u00e7\u0131kt\u0131s\u0131, mevcut durumu yans\u0131tan ve planlanan de\u011fi\u015fiklikleri do\u011fru bir \u015fekilde g\u00f6steren g\u00fcncel bilgilere sahip olur. \u00d6zetle, data<\/code> kaynaklar\u0131, altyap\u0131n\u0131z\u0131n mevcut durumunu okuman\u0131n, anlaman\u0131n ve onu yeni altyap\u0131 da\u011f\u0131t\u0131mlar\u0131n\u0131zla sorunsuz bir \u015fekilde entegre etmenin zarif yoludur.<\/p>\nMevcut Kaynaklar\u0131 Ke\u015ffetmek: Bir Veri Kayna\u011f\u0131 Nas\u0131l Kullan\u0131l\u0131r?<\/h2>\n
\nprovider \"aws\" {\n region = \"us-east-1\"\n}\n\ndata \"aws_vpc\" \"uretim_vpc\" {\n filter {\n name = \"tag:Name\"\n values = [\"UretimVPC\"]\n }\n # \u0130ste\u011fe ba\u011fl\u0131 olarak, VPC'nin belirli bir durumda olmas\u0131n\u0131 da filtreleyebilirsiniz.\n # \u00d6rne\u011fin, \"available\" durumu:\n # filter {\n # name = \"state\"\n # values = [\"available\"]\n # }\n}\n\noutput \"uretim_vpc_id\" {\n description = \"\u00dcretim VPC'sinin ID'si\"\n value = data.aws_vpc.uretim_vpc.id\n}\n\noutput \"uretim_vpc_cidr_block\" {\n description = \"\u00dcretim VPC'sinin CIDR blo\u011fu\"\n value = data.aws_vpc.uretim_vpc.cidr_block\n}\n <\/pre>\n\n
provider \"aws\"<\/code>: Terraform'a AWS ile \u00e7al\u0131\u015faca\u011f\u0131m\u0131z\u0131 ve us-east-1<\/code> b\u00f6lgesini kullanaca\u011f\u0131m\u0131z\u0131 bildirir.<\/li>\ndata \"aws_vpc\" \"uretim_vpc\"<\/code>: Bu, bir veri kayna\u011f\u0131 blo\u011fudur. aws_vpc<\/code>, AWS sa\u011flay\u0131c\u0131s\u0131n\u0131n sundu\u011fu bir veri kayna\u011f\u0131 t\u00fcr\u00fcd\u00fcr ve mevcut bir VPC hakk\u0131nda bilgi \u00e7ekmek i\u00e7in kullan\u0131l\u0131r. uretim_vpc<\/code> ise bu veri kayna\u011f\u0131 i\u00e7in verdi\u011fimiz yerel add\u0131r.<\/li>\nfilter<\/code> blo\u011fu: Bu, Terraform'a hangi VPC'yi arayaca\u011f\u0131n\u0131 s\u00f6yler. Burada tag:Name<\/code> filtresini kullanarak, Name<\/code> etiketi UretimVPC<\/code> olan bir VPC'yi arad\u0131\u011f\u0131m\u0131z\u0131 belirtiyoruz. Sa\u011flay\u0131c\u0131lar, kaynaklar\u0131 filtrelemek i\u00e7in farkl\u0131 kriterler sunabilir (ID, durum, di\u011fer etiketler vb.).<\/li>\noutput \"uretim_vpc_id\"<\/code> ve output \"uretim_vpc_cidr_block\"<\/code>: Bu \u00e7\u0131kt\u0131 bloklar\u0131, buldu\u011fumuz VPC'nin ID'sini ve CIDR blo\u011funu Terraform'un \u00e7al\u0131\u015fmas\u0131 bittikten sonra konsola yazd\u0131rmak i\u00e7in kullan\u0131l\u0131r. Dikkat ederseniz, veri kayna\u011f\u0131n\u0131n \u00f6zniteliklerine data.aws_vpc.uretim_vpc.id<\/code> \u015feklinde eri\u015fiyoruz. Bu syntax, bir veri kayna\u011f\u0131n\u0131n ad\u0131n\u0131n ard\u0131ndan nokta operat\u00f6r\u00fcyle istenilen \u00f6zniteli\u011fe ula\u015fmay\u0131 sa\u011flar.<\/li>\n<\/ol>\nterraform init<\/code> ve terraform apply<\/code> komutlar\u0131yla), Terraform mevcut \"UretimVPC\"yi bulacak ve onun ID'sini ve CIDR blo\u011funu size g\u00f6sterecektir. Art\u0131k bu ID'yi, yeni bir EC2 \u00f6rne\u011fi veya RDS veritaban\u0131 gibi ba\u015fka bir kaynak olu\u015ftururken kullanabilirsiniz. \u00d6rne\u011fin, bu VPC i\u00e7inde bir alt a\u011f bulmak i\u00e7in ba\u015fka bir veri kayna\u011f\u0131 kullanabiliriz:<\/p>\n\ndata \"aws_subnet\" \"uretim_subnet\" {\n vpc_id = data.aws_vpc.uretim_vpc.id\n availability_zone = \"us-east-1a\" # Belirli bir AZ'deki alt a\u011f\u0131 bulmak i\u00e7in\n filter {\n name = \"tag:Purpose\"\n values = [\"Web Tier\"]\n }\n}\n\noutput \"uretim_subnet_id\" {\n description = \"\u00dcretim alt a\u011f\u0131n\u0131n ID'si\"\n value = data.aws_subnet.uretim_subnet.id\n}\n <\/pre>\nid<\/code> veya \u00e7ok spesifik etiketler kullanarak \u00f6nlenebilir.\n <\/div>\nKarma\u015f\u0131k Ortamlarda Basit \u00c7\u00f6z\u00fcmler: Bir AWS S3 Kovas\u0131n\u0131 Veri Kayna\u011f\u0131 Olarak Kullanma<\/h3>\n
\n# Mevcut bir S3 kovas\u0131n\u0131 veri kayna\u011f\u0131 olarak al\ndata \"aws_s3_bucket\" \"existing_app_data_bucket\" {\n bucket = \"my-application-data-bucket-12345\" # Mevcut S3 kovan\u0131z\u0131n ad\u0131\n}\n\n# Bu kova i\u00e7in bir IAM politikas\u0131 olu\u015ftural\u0131m\nresource \"aws_iam_policy\" \"app_s3_access_policy\" {\n name = \"app-s3-access-policy\"\n description = \"Uygulaman\u0131n S3 kovas\u0131na eri\u015fim politikas\u0131\"\n\n policy = jsonencode({\n Version = \"2012-10-17\"\n Statement = [\n {\n Action = [\n \"s3:GetObject\",\n \"s3:PutObject\",\n \"s3:DeleteObject\"\n ]\n Effect = \"Allow\"\n Resource = [\n data.aws_s3_bucket.existing_app_data_bucket.arn,\n \"${data.aws_s3_bucket.existing_app_data_bucket.arn}\/*\"\n ]\n Principal = {\n AWS = \"arn:aws:iam::123456789012:user\/my-app-user\" # Buraya uygulaman\u0131z\u0131n kullan\u0131c\u0131s\u0131n\u0131\/rol\u00fcn\u00fc girin\n }\n },\n ]\n })\n}\n\noutput \"s3_bucket_arn\" {\n description = \"Mevcut S3 kova ARN'si\"\n value = data.aws_s3_bucket.existing_app_data_bucket.arn\n}\n\noutput \"s3_bucket_domain_name\" {\n description = \"Mevcut S3 kova etki alan\u0131 ad\u0131\"\n value = data.aws_s3_bucket.existing_app_data_bucket.bucket_domain_name\n}\n <\/pre>\n\n
data \"aws_s3_bucket\" \"existing_app_data_bucket\"<\/code>: my-application-data-bucket-12345<\/code> adl\u0131 mevcut S3 kovas\u0131n\u0131 sorgular\u0131z. Bu veri kayna\u011f\u0131, S3 kovan\u0131n\u0131n ARN'si, etki alan\u0131 ad\u0131 ve di\u011fer \u00f6zellikleri gibi bilgileri Terraform'a getirir.<\/li>\nresource \"aws_iam_policy\" \"app_s3_access_policy\"<\/code>: Bu politika, uygulamam\u0131z\u0131n belirli S3 kovas\u0131na GetObject<\/code>, PutObject<\/code> ve DeleteObject<\/code> izinleriyle eri\u015fmesini sa\u011flar. En \u00f6nemlisi, Resource<\/code> alan\u0131nda, S3 kovan\u0131n\u0131n ARN'sini do\u011frudan data.aws_s3_bucket.existing_app_data_bucket.arn<\/code> \u00fczerinden dinamik olarak al\u0131r\u0131z. Bu, kovan\u0131n ad\u0131 veya ba\u015fka bir \u00f6zelli\u011fi de\u011fi\u015fse bile, IAM politikam\u0131z\u0131n her zaman do\u011fru ARN'ye referans verece\u011fi anlam\u0131na gelir.<\/li>\n<\/ul>\nDaha Ak\u0131ll\u0131 Referanslar Olu\u015fturmak: Kubernetes'te Bir Secret'\u0131 Veri Kayna\u011f\u0131 Olarak \u00c7ekme<\/h3>\n
my-db-credentials<\/code> ad\u0131nda bir Kubernetes Secret'\u0131n\u0131z var ve bu Secret, bir PostgreSQL veritaban\u0131na ba\u011flanmak i\u00e7in kullan\u0131c\u0131 ad\u0131 ve \u015fifre i\u00e7eriyor. Biz, Terraform ile yeni bir Kubernetes Deployment'\u0131 olu\u015ftururken bu Secret'taki veriyi, ortam de\u011fi\u015fkenleri olarak kapsay\u0131c\u0131m\u0131za enjekte etmek istiyoruz.<\/p>\n\nprovider \"kubernetes\" {\n # Kubernetes k\u00fcme ba\u011flant\u0131 bilgileri buraya gelir (kubeconfig, in-cluster config vb.)\n # \u00d6rne\u011fin, varsay\u0131lan kubeconfig dosyas\u0131n\u0131 kullanmak i\u00e7in:\n # config_path = \"~\/.kube\/config\"\n}\n\n# Mevcut Kubernetes Secret'\u0131n\u0131 veri kayna\u011f\u0131 olarak al\ndata \"kubernetes_secret\" \"db_credentials\" {\n metadata {\n name = \"my-db-credentials\"\n namespace = \"default\" # Secret'\u0131n bulundu\u011fu namespace\n }\n}\n\n# Bu Secret'taki veriyi kullanan bir Kubernetes Deployment olu\u015ftural\u0131m\nresource \"kubernetes_deployment\" \"my_app_deployment\" {\n metadata {\n name = \"my-app\"\n labels = {\n App = \"my-app\"\n }\n }\n\n spec {\n replicas = 2\n selector {\n match_labels = {\n App = \"my-app\"\n }\n }\n template {\n metadata {\n labels = {\n App = \"my-app\"\n }\n }\n spec {\n container {\n name = \"my-app-container\"\n image = \"my-registry\/my-app:1.0.0\"\n env {\n name = \"DB_USERNAME\"\n value = base64decode(data.kubernetes_secret.db_credentials.data[\"username\"])\n }\n env {\n name = \"DB_PASSWORD\"\n value = base64decode(data.kubernetes_secret.db_credentials.data[\"password\"])\n }\n }\n }\n }\n }\n}\n\noutput \"secret_data_keys\" {\n description = \"\u00c7ekilen Secret'\u0131n anahtarlar\u0131\"\n value = keys(data.kubernetes_secret.db_credentials.data)\n}\n <\/pre>\n\n
provider \"kubernetes\"<\/code>: Terraform'a Kubernetes ile \u00e7al\u0131\u015faca\u011f\u0131m\u0131z\u0131 bildirir. Ba\u011flant\u0131 bilgileri, kubeconfig<\/code> dosyas\u0131 veya di\u011fer y\u00f6ntemlerle yap\u0131land\u0131r\u0131labilir.<\/li>\ndata \"kubernetes_secret\" \"db_credentials\"<\/code>: Bu blok, default<\/code> namespace'indeki my-db-credentials<\/code> adl\u0131 Secret'\u0131 veri kayna\u011f\u0131 olarak sorgular. Bu Secret'\u0131n i\u00e7eri\u011fini (anahtar-de\u011fer \u00e7iftleri) Terraform'a \u00e7eker. Kubernetes Secret'lar\u0131 genellikle base64 ile kodland\u0131\u011f\u0131 i\u00e7in, verileri base64decode()<\/code> fonksiyonu ile \u00e7\u00f6zmemiz gerekir.<\/li>\nresource \"kubernetes_deployment\" \"my_app_deployment\"<\/code>: Bu da\u011f\u0131t\u0131m, my-app<\/code> etiketli kapsay\u0131c\u0131lar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131r. En kritik k\u0131s\u0131m, env<\/code> bloklar\u0131d\u0131r. Burada, DB_USERNAME<\/code> ve DB_PASSWORD<\/code> ortam de\u011fi\u015fkenlerini, veri kayna\u011f\u0131m\u0131zdan \u00e7ekti\u011fimiz Secret verileriyle dinamik olarak doldururuz. \u00d6rne\u011fin, data.kubernetes_secret.db_credentials.data[\"username\"]<\/code>, Secret'\u0131n username<\/code> anahtar\u0131n\u0131n de\u011ferini d\u00f6nd\u00fcr\u00fcr.<\/li>\n<\/ul>\nTerraform Veri Kaynaklar\u0131yla G\u00fcc\u00fc Art\u0131rmak: \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
1. Geli\u015fmi\u015f Filtreleme ve Ko\u015fullu Mant\u0131k<\/h3>\n
filter<\/code> bloklar\u0131 veya do\u011frudan \u00f6znitelikler arac\u0131l\u0131\u011f\u0131yla geli\u015fmi\u015f filtreleme yetenekleri sunar. Bu, y\u00fczlerce kaynak aras\u0131ndan do\u011fru olan\u0131 bulman\u0131za yard\u0131mc\u0131 olur. Ancak, bazen filtreleriniz tekil bir e\u015fle\u015fme d\u00f6nd\u00fcrmeyebilir veya istedi\u011finiz kayna\u011f\u0131 bulamayabilir. Bu t\u00fcr durumlar i\u00e7in ko\u015fullu mant\u0131k kullanmak \u00f6nemlidir.<\/p>\n\n# Belirli bir isme sahip bir AMI'yi bulmaya \u00e7al\u0131\u015fal\u0131m\ndata \"aws_ami\" \"latest_ubuntu\" {\n most_recent = true\n owners = [\"099720109477\"] # Canonical\n name_regex = \"^ubuntu\/images\/hvm-ssd\/ubuntu-focal-20.04-amd64-server-\\\\d{8}$\"\n filter {\n name = \"virtualization-type\"\n values = [\"hvm\"]\n }\n}\n\noutput \"ami_id\" {\n value = data.aws_ami.latest_ubuntu.id\n}\n <\/pre>\nmost_recent = true<\/code> kullanarak en yeni Ubuntu AMI'sini buluyoruz. name_regex<\/code> ile de daha spesifik bir arama yap\u0131yoruz. E\u011fer arad\u0131\u011f\u0131n\u0131z kaynak bazen mevcut olmayabilir veya ko\u015fullara ba\u011fl\u0131 olarak farkl\u0131 bir kaynak kullanmak isteyebilirsiniz. count<\/code> meta-arg\u00fcman\u0131n\u0131 veri kaynaklar\u0131yla birlikte kullanarak, bir kayna\u011f\u0131n varl\u0131\u011f\u0131na veya yoklu\u011funa g\u00f6re i\u015flem yapabilirsiniz.<\/p>\n2. \u00c7apraz Referanslama ve Mod\u00fcl Ba\u011f\u0131ml\u0131l\u0131klar\u0131<\/h3>\n
3. Hassas Veri Y\u00f6netimi<\/h3>\n
\n# AWS Secrets Manager'dan bir secret'\u0131 \u00e7ek\ndata \"aws_secretsmanager_secret\" \"db_password_secret\" {\n name = \"my-app\/db\/password\"\n}\n\ndata \"aws_secretsmanager_secret_version\" \"db_password_version\" {\n secret_id = data.aws_secretsmanager_secret.db_password_secret.id\n}\n\noutput \"db_password_value\" {\n value = data.aws_secretsmanager_secret_version.db_password_version.secret_string\n sensitive = true # \u00c7\u0131kt\u0131n\u0131n hassas oldu\u011funu i\u015faretle\n}\n <\/pre>\nsensitive = true<\/code> etiketi, hassas verilerin Terraform \u00e7\u0131kt\u0131 loglar\u0131nda g\u00f6r\u00fcnmesini engeller ve state dosyas\u0131nda da maskelenmesine yard\u0131mc\u0131 olur. Ancak unutmay\u0131n, Terraform state dosyas\u0131 yine de hassas verileri i\u00e7erebilir, bu y\u00fczden state dosyas\u0131n\u0131n g\u00fcvenli\u011fi her zaman \u00f6nceliklidir.<\/p>\n4. Performans ve Tekil E\u015fle\u015fmeler<\/h3>\n
plan<\/code> ve apply<\/code> a\u015famalar\u0131nda, veri kaynaklar\u0131 bulut sa\u011flay\u0131c\u0131lar\u0131na API \u00e7a\u011fr\u0131lar\u0131 yapar. \u00c7ok say\u0131da veri kayna\u011f\u0131 kullanmak veya \u00e7ok geni\u015f filtreleme kriterleri uygulamak, planlama s\u00fcresini uzatabilir. Bu nedenle:<\/p>\n\n
id<\/code> gibi benzersiz tan\u0131mlay\u0131c\u0131lar yerine etiketlerle arama yaparken ortaya \u00e7\u0131kabilir.<\/li>\n<\/ul>\n5. En \u0130yi Uygulamalar \u00d6zeti<\/h3>\n
\n
count<\/code> meta-arg\u00fcman\u0131n\u0131 kullanarak ko\u015fullu mant\u0131k uygulayabilirsiniz. \u00d6rne\u011fin, count = var.use_existing_vpc ? 1 : 0<\/code> ile yaln\u0131zca belirli bir de\u011fi\u015fken true ise veri kayna\u011f\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmay\u0131 tercih edebilirsiniz. Bu teknikle, esnekli\u011fi %30 art\u0131rabilirsiniz.\n <\/div>\nYaratmaktan \u00c7ok Kullanmak: Daha Verimli Bir Altyap\u0131 Y\u00f6netimi<\/h2>\n
\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
data<\/code> kaynaklar\u0131 ile resource<\/code> kaynaklar\u0131 aras\u0131ndaki temel fark nedir?<\/dt>\nresource<\/code> bloklar\u0131, Terraform'un yeni altyap\u0131 kaynaklar\u0131 olu\u015fturmas\u0131n\u0131, de\u011fi\u015ftirmesini veya silmesini<\/strong> sa\u011flar. \u00d6rne\u011fin, yeni bir EC2 \u00f6rne\u011fi veya S3 kovas\u0131 yaratmak i\u00e7in kullan\u0131l\u0131rlar. Buna kar\u015f\u0131l\u0131k, data<\/code> bloklar\u0131 sadece mevcut altyap\u0131 kaynaklar\u0131 hakk\u0131nda bilgi sorgulamak ve okumak<\/strong> i\u00e7in kullan\u0131l\u0131r. Yeni bir kaynak olu\u015fturmaz veya mevcut bir kayna\u011f\u0131 de\u011fi\u015ftirmezler; yaln\u0131zca mevcut bir kayna\u011f\u0131n \u00f6zniteliklerini Terraform'un kullanmas\u0131 i\u00e7in eri\u015filebilir hale getirirler.<\/dd>\ndata<\/code> kayna\u011f\u0131 mevcut bir kayna\u011f\u0131 silebilir mi veya de\u011fi\u015ftirebilir mi?<\/dt>\ndata<\/code> kaynaklar\u0131n\u0131n do\u011fas\u0131 gere\u011fi, yaln\u0131zca okuma (read-only) eri\u015fimine sahiptirler. Ama\u00e7lar\u0131, mevcut altyap\u0131 hakk\u0131nda bilgi edinmektir, onu manip\u00fcle etmek de\u011fil. Bir kayna\u011f\u0131 de\u011fi\u015ftirmek veya silmek i\u00e7in mutlaka bir resource<\/code> blo\u011fu kullanman\u0131z gerekir.<\/dd>\ndata<\/code> kaynaklar\u0131 ne zaman kullan\u0131lmamal\u0131d\u0131r?<\/dt>\ndata<\/code> kayna\u011f\u0131 yerine resource<\/code> blo\u011fu kullanmal\u0131s\u0131n\u0131z. Ayr\u0131ca, e\u011fer bir kayna\u011f\u0131n \u00e7\u0131kt\u0131s\u0131 (\u00f6rne\u011fin bir mod\u00fcl\u00fcn \u00e7\u0131kt\u0131s\u0131) do\u011frudan kullan\u0131labilirse ve karma\u015f\u0131k bir filtreleme gerektirmiyorsa, basit bir \u00e7\u0131kt\u0131 referans\u0131 genellikle data<\/code> kayna\u011f\u0131 kullanmaktan daha do\u011frudan bir \u00e7\u00f6z\u00fcm olabilir. Bir di\u011fer durum, sorgulamak istedi\u011finiz kayna\u011f\u0131n kriterlere uygun tek bir e\u015fle\u015fme d\u00f6nd\u00fcremeyece\u011fi belirsiz durumlar olabilir; bu durumda hata almamak i\u00e7in dikkatli olmak veya farkl\u0131 bir strateji izlemek gerekir.<\/dd>\ndata<\/code> kaynaklar\u0131 performans\u0131 nas\u0131l etkiler?<\/dt>\ndata<\/code> kaynaklar\u0131, terraform plan<\/code> veya terraform apply<\/code> komutlar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, ilgili bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n API'sine \u00e7a\u011fr\u0131lar yapar. \u00c7ok say\u0131da data<\/code> kayna\u011f\u0131 kullanmak veya \u00e7ok geni\u015f filtrelerle arama yapmak, bu API \u00e7a\u011fr\u0131lar\u0131n\u0131n say\u0131s\u0131n\u0131 art\u0131rarak Terraform'un planlama ve uygulama s\u00fcrelerini uzatabilir. Performans\u0131 optimize etmek i\u00e7in, sadece ihtiya\u00e7 duydu\u011funuz data<\/code> kaynaklar\u0131n\u0131 kullanmaya ve filtrelerinizi m\u00fcmk\u00fcn oldu\u011funca spesifik tutmaya \u00f6zen g\u00f6sterin.<\/dd>\ndata<\/code> kaynaklar\u0131 ile y\u00f6netebilir miyiz?<\/dt>\ndata<\/code> kaynaklar\u0131n\u0131n en b\u00fcy\u00fck avantajlar\u0131ndan biri de budur. Bir kaynak manuel olarak, farkl\u0131 bir CI\/CD boru hatt\u0131 ile veya ba\u015fka bir IaC arac\u0131yla olu\u015fturulmu\u015f olsa bile, e\u011fer ilgili bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n API'si arac\u0131l\u0131\u011f\u0131yla sorgulanabiliyorsa, Terraform data<\/code> kaynaklar\u0131 ile bu kayna\u011fa ait bilgilere eri\u015febilir ve kendi kodunuzda kullanabilirsiniz. Bu, farkl\u0131 y\u00f6netim metodlar\u0131 aras\u0131nda k\u00f6pr\u00fc kurarak altyap\u0131n\u0131z\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 ve entegrasyonunu sa\u011flar.<\/dd>\n<\/dl>\n