{"id":35845,"date":"2025-12-04T16:01:11","date_gmt":"2025-12-04T13:01:11","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/terraform-statei-s3te-guvenle-saklama-kapsamli-rehber\/"},"modified":"2025-12-04T16:01:11","modified_gmt":"2025-12-04T13:01:11","slug":"terraform-statei-s3te-guvenle-saklama-kapsamli-rehber","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/terraform-statei-s3te-guvenle-saklama-kapsamli-rehber\/","title":{"rendered":"Terraform State\u2019i S3\u2019te G\u00fcvenle Saklama: Kapsaml\u0131 Rehber"},"content":{"rendered":"

Altyap\u0131y\u0131 kod olarak (IaC) y\u00f6netmek, modern bulut operasyonlar\u0131n\u0131n temelidir. Ancak Terraform gibi g\u00fc\u00e7l\u00fc bir IaC arac\u0131 kullan\u0131rken, altyap\u0131n\u0131z\u0131n mevcut durumunu temsil eden “state” dosyas\u0131n\u0131 nas\u0131l g\u00fcvenli, tutarl\u0131 ve eri\u015filebilir tutaca\u011f\u0131n\u0131z kritik bir soru haline gelir. Bu rehberde, Terraform state y\u00f6netiminin neden bu kadar \u00f6nemli oldu\u011funu a\u00e7\u0131klayacak, AWS S3 ve DynamoDB kullanarak Terraform durumunuzu tak\u0131m uyumlu, g\u00fcvenli ve etkin bir \u015fekilde nas\u0131l saklayaca\u011f\u0131n\u0131z\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz. \u0130ster yeni ba\u015flayan ister deneyimli bir DevOps m\u00fchendisi olun, bu k\u0131lavuz size sa\u011flam bir temel sunacak ve ileri d\u00fczey ipu\u00e7lar\u0131yla bilginizi peki\u015ftirecektir.<\/p>\n

Bulut altyap\u0131s\u0131n\u0131 kodla y\u00f6netmek, g\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen teknoloji d\u00fcnyas\u0131nda vazge\u00e7ilmez bir pratik haline geldi. Terraform, bu alanda lider ara\u00e7lardan biri olarak, ekiplerin AWS, Azure, GCP gibi farkl\u0131 bulut sa\u011flay\u0131c\u0131lar\u0131nda kaynaklar\u0131 tan\u0131mlamas\u0131na ve y\u00f6netmesine olanak tan\u0131r. Ancak Terraform\u2019un g\u00fcc\u00fcn\u00fcn merkezinde, altyap\u0131n\u0131z\u0131n mevcut durumunu kaydeden ve bir sonraki uygulaman\u0131zda ne gibi de\u011fi\u015fiklikler yap\u0131lmas\u0131 gerekti\u011fini anlamas\u0131na yard\u0131mc\u0131 olan \u2018state\u2019 dosyas\u0131 bulunur. Bu dosya, Terraform\u2019un y\u00f6netti\u011fi t\u00fcm kaynaklar\u0131n bir haritas\u0131d\u0131r ve bulut \u00fczerindeki ger\u00e7ek kaynaklar ile sizin kodunuzdaki tan\u0131mlamalar aras\u0131ndaki k\u00f6pr\u00fcy\u00fc kurar. Peki, bu kadar kritik bir dosyan\u0131n y\u00f6netimi neden bu kadar \u00f6nemli ve \u00f6zellikle de neden g\u00fcvenli bir \u015fekilde saklanmal\u0131d\u0131r? D\u00fc\u015f\u00fcn\u00fcn ki, bir e-ticaret uygulamas\u0131n\u0131n t\u00fcm altyap\u0131s\u0131, veritabanlar\u0131ndan sunuculara, y\u00fck dengeleyicilerden g\u00fcvenlik gruplar\u0131na kadar, tek bir Terraform state dosyas\u0131yla takip ediliyor. E\u011fer bu dosya kaybolur, bozulur veya yanl\u0131\u015f ki\u015filer taraf\u0131ndan eri\u015filirse, t\u00fcm altyap\u0131n\u0131z\u0131n kontrol\u00fcn\u00fc kaybetme veya ciddi g\u00fcvenlik riskleriyle kar\u015f\u0131la\u015fma potansiyeliniz do\u011far. \u0130\u015fte bu y\u00fczden Terraform state y\u00f6netimi, sadece bir depolama karar\u0131 olmaktan \u00f6te, bir stratejik g\u00fcvenlik ve s\u00fcreklilik plan\u0131n\u0131n par\u00e7as\u0131d\u0131r.<\/p>\n

Ba\u015flang\u0131\u00e7ta bir\u00e7ok kullan\u0131c\u0131, Terraform state dosyas\u0131n\u0131 yerel makinelerinde saklama e\u011filimindedir. Bu yakla\u015f\u0131m, tek ki\u015filik projeler veya test ortamlar\u0131 i\u00e7in belki yeterli olabilirken, ger\u00e7ek d\u00fcnya senaryolar\u0131nda, \u00f6zellikle de bir ekip i\u00e7erisinde \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131nda h\u0131zla sorunlara yol a\u00e7ar. Birincisi, yerel state dosyas\u0131 kolayca kaybolabilir veya bozulabilir; bir disk \u00e7\u00f6kmesi ya da yanl\u0131\u015fl\u0131kla silme i\u015flemi, altyap\u0131n\u0131zla olan ba\u011flant\u0131n\u0131z\u0131 koparabilir. \u0130kincisi, ekip \u00fcyeleri aras\u0131nda tutars\u0131zl\u0131klar meydana gelebilir. Bir geli\u015ftirici kendi yerel state dosyas\u0131yla bir de\u011fi\u015fiklik yaparken, di\u011feri kendi kopyas\u0131yla \u00e7ak\u0131\u015fan ba\u015fka bir de\u011fi\u015fiklik yapabilir, bu da \u2018state drift\u2019 olarak bilinen duruma ve hatta altyap\u0131da istenmeyen sonu\u00e7lara yol a\u00e7abilir. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, g\u00fcvenlik zafiyetleri ortaya \u00e7\u0131kabilir. State dosyalar\u0131 hassas bilgiler i\u00e7erebilir, \u00f6rne\u011fin veritaban\u0131 ba\u011flant\u0131 dizeleri veya API anahtarlar\u0131 gibi, bu da onlar\u0131n g\u00fcvenli bir \u015fekilde depolanmas\u0131n\u0131 zorunlu k\u0131lar. Bu gibi nedenlerle, Terraform state\u2019inin uzaktan, merkezi ve g\u00fcvenli bir konumda saklanmas\u0131 modern DevOps uygulamalar\u0131 i\u00e7in bir zorunluluktur. Bu, hem ekip i\u015fbirli\u011fini geli\u015ftirir hem de altyap\u0131n\u0131z\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve g\u00fcvenli\u011fini sa\u011flar. Uzaktan saklama \u00e7\u00f6z\u00fcmleri aras\u0131nda AWS S3, sahip oldu\u011fu versiyonlama, \u015fifreleme ve eri\u015fim kontrol\u00fc gibi \u00f6zelliklerle \u00f6ne \u00e7\u0131karak ideal bir se\u00e7enek sunar.<\/p>\n

Terraform State Nedir ve Neden Uzaktan Saklamal\u0131y\u0131z?<\/h2>\n

Terraform’un kalbinde, y\u00f6netti\u011fi altyap\u0131n\u0131n mevcut durumunu temsil eden “state” dosyas\u0131 yer al\u0131r. Bu dosya, basit\u00e7e ifade etmek gerekirse, Terraform’un sizin ad\u0131n\u0131za bulut sa\u011flay\u0131c\u0131n\u0131zda (\u00f6rne\u011fin AWS) olu\u015fturdu\u011fu t\u00fcm kaynaklar\u0131n bir kayd\u0131d\u0131r. Hangi EC2 instance’lar\u0131n\u0131n, S3 bucket’lar\u0131n\u0131n, VPC’lerin veya veritabanlar\u0131n\u0131n var oldu\u011funu, bu kaynaklar\u0131n ID’lerini ve yap\u0131land\u0131rma detaylar\u0131n\u0131 i\u00e7erir. Terraform, bu state dosyas\u0131 arac\u0131l\u0131\u011f\u0131yla, yazd\u0131\u011f\u0131n\u0131z HCL (HashiCorp Configuration Language) kodundaki tan\u0131mlamalar\u0131n\u0131z ile ger\u00e7ek bulut altyap\u0131n\u0131z aras\u0131ndaki farklar\u0131 tespit eder. \u00d6rne\u011fin, bir EC2 instance’\u0131 tan\u0131mlad\u0131\u011f\u0131n\u0131zda, Terraform bunu state dosyas\u0131na kaydeder. Bir sonraki terraform apply<\/code> komutunuzda, Terraform \u00f6nce state dosyas\u0131na bakar, ard\u0131ndan bulut sa\u011flay\u0131c\u0131n\u0131zdaki mevcut durumu sorgular ve bu iki durum aras\u0131ndaki farklar\u0131 (eklenecek, g\u00fcncellenecek veya silinecek kaynaklar) size sunar. K\u0131sacas\u0131, state dosyas\u0131 olmadan Terraform, bulut kaynaklar\u0131n\u0131zla do\u011fru bir \u015fekilde etkile\u015fime giremez ve altyap\u0131n\u0131z\u0131 y\u00f6netemez.<\/p>\n

Peki, b\u00f6ylesine kritik bir dosyan\u0131n yerel bir makinede kalmas\u0131 neden sorunludur? \u0130lk olarak, tutars\u0131zl\u0131k ve \u00e7ak\u0131\u015fma riski<\/strong> devreye girer. Bir ekip ortam\u0131nda, birden fazla geli\u015ftirici ayn\u0131 altyap\u0131 \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, her birinin kendi yerel state dosyas\u0131na sahip olmas\u0131, e\u015f zamanl\u0131 de\u011fi\u015fikliklerde karma\u015faya yol a\u00e7ar. Bir geli\u015ftirici kendi yerel state’ini g\u00fcncelleyip bir kaynak olu\u015ftururken, di\u011feri ayn\u0131 kaynak \u00fczerinde farkl\u0131 bir de\u011fi\u015fiklik yapmaya \u00e7al\u0131\u015fabilir. Bu durum, “state drift” olarak bilinen, ger\u00e7ek altyap\u0131 ile Terraform state’i aras\u0131ndaki senkronizasyon bozuklu\u011funa ve hatta veri kayb\u0131na yol a\u00e7abilir. \u0130kinci olarak, g\u00fcvenlik zaafiyetleri<\/strong> g\u00f6z ard\u0131 edilemez. State dosyalar\u0131, hassas bilgiler (\u00f6rne\u011fin, kaynak kimlikleri, baz\u0131 durumlarda API anahtarlar\u0131 veya veritaban\u0131 parolalar\u0131 gibi do\u011frudan hassas veriler olmasa da, altyap\u0131n\u0131n i\u00e7 yap\u0131s\u0131n\u0131 g\u00f6steren kritik bilgiler) i\u00e7erebilir. Yerel bir makinede \u015fifrelenmemi\u015f bir \u015fekilde duran bu dosya, k\u00f6t\u00fc niyetli ki\u015filer taraf\u0131ndan ele ge\u00e7irildi\u011finde ciddi g\u00fcvenlik riskleri olu\u015fturur. \u00dc\u00e7\u00fcnc\u00fc olarak, kal\u0131c\u0131l\u0131k ve eri\u015filebilirlik sorunlar\u0131<\/strong> vard\u0131r. Yerel bir state dosyas\u0131, geli\u015ftiricinin bilgisayar\u0131n\u0131n bozulmas\u0131, kaybolmas\u0131 veya yanl\u0131\u015fl\u0131kla silinmesi durumunda t\u00fcm altyap\u0131 y\u00f6netimini sekteye u\u011fratabilir. Bu da felaket kurtarma senaryolar\u0131nda b\u00fcy\u00fck bir engel te\u015fkil eder. Merkezi bir state depolama sistemi olmadan, bir ekip \u00fcyesi tatildeyken veya \u015firketten ayr\u0131ld\u0131\u011f\u0131nda, onun makinelerindeki state dosyas\u0131n\u0131n kaybolmas\u0131, projeyi durma noktas\u0131na getirebilir.<\/p>\n

Bu nedenlerden dolay\u0131, Terraform state’ini uzaktan saklamak modern ve s\u00fcrd\u00fcr\u00fclebilir bir altyap\u0131 y\u00f6netimi prati\u011fidir. Uzaktan saklama, \u00f6zellikle AWS S3 gibi servisler arac\u0131l\u0131\u011f\u0131yla, bir dizi avantaj sunar: Tak\u0131m i\u015fbirli\u011fi<\/strong> kolayla\u015f\u0131r, zira t\u00fcm ekip \u00fcyeleri tek, g\u00fcvenilir bir state dosyas\u0131n\u0131 kullan\u0131r. G\u00fcvenlik art\u0131r\u0131l\u0131r<\/strong>, \u00e7\u00fcnk\u00fc S3’\u00fcn \u015fifreleme, versiyonlama ve eri\u015fim kontrol\u00fc \u00f6zellikleri (IAM politikalar\u0131) hassas verilerin korunmas\u0131na yard\u0131mc\u0131 olur. Kal\u0131c\u0131l\u0131k ve eri\u015filebilirlik<\/strong> sa\u011flan\u0131r, zira S3 y\u00fcksek dayan\u0131kl\u0131l\u0131k ve 7\/24 eri\u015fim sunar. Ayr\u0131ca, S3 ile birlikte kullan\u0131lan DynamoDB gibi servisler sayesinde, e\u015f zamanl\u0131 state de\u011fi\u015fikliklerinde kilitleme (state locking)<\/strong> mekanizmalar\u0131 devreye girer, b\u00f6ylece \u00e7ak\u0131\u015fmalar \u00f6nlenir. Bu entegre yakla\u015f\u0131m, Terraform state’inin g\u00fcvenli, eri\u015filebilir ve tutarl\u0131 bir \u015fekilde y\u00f6netilmesini sa\u011flayarak, altyap\u0131n\u0131z\u0131n gelece\u011fini g\u00fcvence alt\u0131na al\u0131r.<\/p>\n

AWS S3’\u00fc Terraform Backend Olarak Yap\u0131land\u0131rma: Temel Ad\u0131mlar<\/h2>\n

Terraform state’ini g\u00fcvenli ve merkezi bir \u015fekilde y\u00f6netmek i\u00e7in AWS S3’\u00fc backend olarak yap\u0131land\u0131rmak, asl\u0131nda olduk\u00e7a basit ve standart bir s\u00fcre\u00e7tir. Ancak bu s\u00fcreci do\u011fru ad\u0131mlarla ve en iyi uygulamalar\u0131 takip ederek yapmak, gelecekte kar\u015f\u0131la\u015fabilece\u011finiz bir\u00e7ok potansiyel sorunu \u00f6nleyecektir. Bu b\u00f6l\u00fcmde, S3 bucket olu\u015fturmadan, DynamoDB tablosunu ayarlamaya ve Terraform konfig\u00fcrasyonunu yazmaya kadar her ad\u0131m\u0131 detayl\u0131ca ele alaca\u011f\u0131z.<\/p>\n

Ad\u0131m 1: S3 Bucket Olu\u015fturma (Terraform State Depolama Alan\u0131)<\/strong><\/p>\n

\u0130lk olarak, Terraform state dosyalar\u0131n\u0131z\u0131 depolayaca\u011f\u0131n\u0131z bir S3 bucket’\u0131na ihtiyac\u0131m\u0131z var. Bu bucket’\u0131n ismi benzersiz olmal\u0131 ve belirli \u00f6zelliklere sahip olmal\u0131d\u0131r. En \u00f6nemlileri versiyonlama (versioning) ve \u015fifreleme (encryption) \u00f6zellikleridir. Versiyonlama, state dosyan\u0131z\u0131n her de\u011fi\u015fikli\u011finde yeni bir s\u00fcr\u00fcm\u00fcn\u00fc olu\u015fturarak, yanl\u0131\u015fl\u0131kla silme veya bozulma durumlar\u0131nda \u00f6nceki bir s\u00fcr\u00fcme geri d\u00f6nebilmenizi sa\u011flar. \u015eifreleme ise, hassas olabilecek verilerinizi S3’te depolan\u0131rken g\u00fcvende tutar. A\u015fa\u011f\u0131daki AWS CLI komutunu veya AWS Konsolu’nu kullanarak bir bucket olu\u015fturabilirsiniz:<\/p>\n

\n
\naws s3api create-bucket \\\n--bucket my-terraform-state-bucket-unique-name \\\n--region us-east-1 \\\n--create-bucket-configuration LocationConstraint=us-east-1\n<\/pre>\n
<\/code>\n<\/div>\n
Bucket olu\u015fturulduktan sonra, versiyonlamay\u0131 etkinle\u015ftirmemiz gerekiyor:<\/p>\n
\n
\naws s3api put-bucket-versioning \\\n--bucket my-terraform-state-bucket-unique-name \\\n--versioning-configuration Status=Enabled\n<\/pre>\n
<\/code>\n<\/div>\n
\u015eifreleme i\u00e7in ise genellikle sunucu taraf\u0131 \u015fifreleme (Server-Side Encryption, SSE) kullan\u0131l\u0131r. AWS KMS (Key Management Service) veya S3'\u00fcn kendi anahtarlar\u0131yla (SSE-S3) \u015fifreleme yapabilirsiniz. G\u00fcvenlik i\u00e7in KMS tercih edilir:<\/p>\n
\n
\naws s3api put-bucket-encryption \\\n--bucket my-terraform-state-bucket-unique-name \\\n--server-side-encryption-configuration '{\"Rules\": [{\"ApplyServerSideEncryptionByDefault\": {\"SSEAlgorithm\": \"AES256\"}}]}'\n<\/pre>\n
<\/code>\n<\/div>\n
Bu ad\u0131mlar, state dosyalar\u0131n\u0131z\u0131n g\u00fcvenli bir \u015fekilde depolanmas\u0131n\u0131 sa\u011flar. Ayr\u0131ca, bucket'\u0131 yanl\u0131\u015fl\u0131kla silinmelere kar\u015f\u0131 korumak i\u00e7in IAM politikalar\u0131 ile eri\u015fimi k\u0131s\u0131tlamak ve \"MFA Delete\" gibi \u00f6zellikleri etkinle\u015ftirmek de iyi bir uygulamad\u0131r.<\/p>\n
Ad\u0131m 2: DynamoDB Tablosu Olu\u015fturma (State Kilitleme i\u00e7in)<\/strong><\/p>\n
Terraform state kilitleme (state locking), ayn\u0131 anda birden fazla kullan\u0131c\u0131n\u0131n state dosyas\u0131nda de\u011fi\u015fiklik yapmaya \u00e7al\u0131\u015fmas\u0131n\u0131 \u00f6nleyen kritik bir \u00f6zelliktir. Bu sayede, state dosyas\u0131n\u0131n bozulmas\u0131 veya \u00e7ak\u0131\u015fmalar\u0131n \u00f6n\u00fcne ge\u00e7ilir. Terraform, bu kilitleme mekanizmas\u0131n\u0131 uygulamak i\u00e7in genellikle AWS DynamoDB tablosunu kullan\u0131r. DynamoDB tablosunun temel gereksinimi, Partition Key'i olarak LockID<\/code> ad\u0131nda bir dizge (string) niteli\u011fine sahip olmas\u0131d\u0131r. Olu\u015fturaca\u011f\u0131n\u0131z tablo \u00e7ok fazla trafik almayaca\u011f\u0131ndan, d\u00fc\u015f\u00fck kapasiteli bir tablo yeterli olacakt\u0131r:<\/p>\n
\n
\naws dynamodb create-table \\\n--table-name my-terraform-lock-table \\\n--attribute-definitions AttributeName=LockID,AttributeType=S \\\n--key-schema AttributeName=LockID,KeyType=HASH \\\n--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5\n<\/pre>\n
<\/code>\n<\/div>\n
Bu komut, my-terraform-lock-table<\/code> ad\u0131nda, LockID<\/code> anahtar niteli\u011fine sahip bir DynamoDB tablosu olu\u015fturur. Bu tablo, Terraform'un kilit bilgilerini depolamas\u0131 i\u00e7in kullan\u0131lacakt\u0131r. Kilitleme mekanizmas\u0131 sayesinde, birden fazla ekip \u00fcyesinin ayn\u0131 anda terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131rmas\u0131 durumunda bile state dosyas\u0131n\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fc korunur.<\/p>\n
Ad\u0131m 3: IAM Rolleri ve Politikalar\u0131 (Eri\u015fim Kontrol\u00fc)<\/strong><\/p>\n
Terraform'un S3 bucket'\u0131n\u0131za ve DynamoDB tablonuza eri\u015febilmesi i\u00e7in uygun IAM izinlerine sahip olmas\u0131 gerekir. G\u00fcvenlik en iyi uygulamas\u0131 olarak \"en az ayr\u0131cal\u0131k prensibi\" (least privilege principle) uygulanmal\u0131d\u0131r. Yani, Terraform'a sadece ihtiya\u00e7 duydu\u011fu kaynaklara, ihtiya\u00e7 duydu\u011fu i\u015flemleri yapmas\u0131 i\u00e7in izin verilmelidir. Bu izinler, genellikle bir IAM rol\u00fc veya kullan\u0131c\u0131ya atanacak bir politika \u015feklinde tan\u0131mlan\u0131r. \u0130\u015fte \u00f6rnek bir IAM politikas\u0131:<\/p>\n
\n
\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:PutObject\",\n        \"s3:DeleteObject\",\n        \"s3:ListBucket\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::my-terraform-state-bucket-unique-name\",\n        \"arn:aws:s3:::my-terraform-state-bucket-unique-name\/*\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"dynamodb:GetItem\",\n        \"dynamodb:PutItem\",\n        \"dynamodb:DeleteItem\"\n      ],\n      \"Resource\": \"arn:aws:dynamodb:us-east-1:123456789012:table\/my-terraform-lock-table\"\n    }\n  ]\n}\n<\/pre>\n
<\/code>\n<\/div>\n
Bu politika, belirtilen S3 bucket'\u0131 \u00fczerinde temel okuma\/yazma\/listeleme izinlerini ve DynamoDB tablosu \u00fczerinde gerekli kilitleme i\u015flemlerini yapma izinlerini verir. 123456789012<\/code> yerine kendi AWS hesap numaran\u0131z\u0131 ve us-east-1<\/code> yerine kendi b\u00f6lgenizi yazmay\u0131 unutmay\u0131n. Bu politika, Terraform'u \u00e7al\u0131\u015ft\u0131racak IAM kullan\u0131c\u0131s\u0131na, rol\u00fcne veya CI\/CD pipeline'\u0131n\u0131z\u0131n \u00fcstlendi\u011fi role atanmal\u0131d\u0131r.<\/p>\n
Ad\u0131m 4: Terraform Yap\u0131land\u0131rmas\u0131 (backend \"s3\"<\/code>)<\/strong><\/p>\n
Son olarak, Terraform projenizin ana yap\u0131land\u0131rma dosyas\u0131nda (genellikle main.tf<\/code> veya versions.tf<\/code>) S3 backend'ini tan\u0131mlaman\u0131z gerekir. Bu, Terraform'a state dosyas\u0131n\u0131 yerel olarak de\u011fil, uzaktan, belirtti\u011finiz S3 bucket'\u0131nda saklamas\u0131 gerekti\u011fini s\u00f6yler:<\/p>\n
\n
\nterraform {\n  backend \"s3\" {\n    bucket         = \"my-terraform-state-bucket-unique-name\"\n    key            = \"dev\/network\/terraform.tfstate\" # State dosyas\u0131n\u0131n S3 i\u00e7indeki yolu\n    region         = \"us-east-1\"\n    dynamodb_table = \"my-terraform-lock-table\"\n    encrypt        = true # S3 \u00fczerinde \u015fifrelemeyi etkinle\u015ftir\n  }\n}\n\nprovider \"aws\" {\n  region = \"us-east-1\"\n}\n<\/pre>\n
<\/code>\n<\/div>\n
Burada bucket<\/code>, olu\u015fturdu\u011funuz S3 bucket'\u0131n\u0131n ad\u0131n\u0131; key<\/code>, state dosyan\u0131z\u0131n S3'teki tam yolunu (farkl\u0131 ortamlar veya mod\u00fcller i\u00e7in farkl\u0131 key<\/code>'ler kullanabilirsiniz); region<\/code>, AWS b\u00f6lgenizi; dynamodb_table<\/code>, DynamoDB kilitleme tablonuzun ad\u0131n\u0131 belirtir. encrypt = true<\/code> parametresi, S3 \u00fczerinde sunucu taraf\u0131 \u015fifrelemeyi otomatik olarak etkinle\u015ftirir (\u00f6nceden bucket'ta ayarlad\u0131\u011f\u0131n\u0131z \u015fifreleme tipini kullan\u0131r). Bu yap\u0131land\u0131rmay\u0131 projenize ekledikten sonra, ilk terraform init<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, Terraform state dosyan\u0131z\u0131 otomatik olarak belirtti\u011finiz S3 bucket'\u0131na ta\u015f\u0131yacak ve gelecekteki t\u00fcm i\u015flemler bu uzaktan state \u00fczerinden y\u00fcr\u00fct\u00fclecektir.<\/p>\n
Uygulamal\u0131 Senaryo: Tak\u0131m \u00c7al\u0131\u015fmas\u0131nda Terraform State Y\u00f6netimi Nas\u0131l \u0130\u015fler?<\/h2>\n
Terraform state'inin uzaktan, merkezi bir konumda saklanmas\u0131n\u0131n en b\u00fcy\u00fck faydalar\u0131ndan biri, ekip i\u00e7i i\u015fbirli\u011fini sorunsuz hale getirmesidir. Yerel state dosyalar\u0131n\u0131n neden oldu\u011fu \u00e7ak\u0131\u015fma, kay\u0131p veya tutars\u0131zl\u0131k sorunlar\u0131, merkezi bir S3 backend ile etkin bir \u015fekilde \u00e7\u00f6z\u00fcl\u00fcr. Gelin, bu durumu bir \u00f6rnek senaryo \u00fczerinden inceleyelim: Bir SaaS (Hizmet Olarak Yaz\u0131l\u0131m) \u015firketi d\u00fc\u015f\u00fcnelim. Bu \u015firketin DevOps ekibi, \"Project Phoenix\" ad\u0131n\u0131 verdikleri yeni bir microservice tabanl\u0131 web uygulamas\u0131n\u0131 AWS \u00fczerinde da\u011f\u0131t\u0131yor. Bu ekipte \u00fc\u00e7 geli\u015ftirici var: Ay\u015fe (Veritaban\u0131), Can (Backend API) ve Deniz (Frontend). Hepsi ayn\u0131 Terraform kod taban\u0131n\u0131 kullanarak farkl\u0131 AWS kaynaklar\u0131n\u0131 y\u00f6netiyor.<\/p>\n
Senaryo Ba\u015flang\u0131c\u0131:<\/strong>
\nEkip, daha \u00f6nce a\u00e7\u0131klanan ad\u0131mlar\u0131 izleyerek bir S3 bucket'\u0131 (\u00f6rne\u011fin phoenix-project-terraform-states<\/code>) ve bir DynamoDB kilitleme tablosu (phoenix-project-locks<\/code>) olu\u015fturmu\u015f durumda. Terraform konfig\u00fcrasyonlar\u0131 da backend olarak bu S3 bucket'\u0131n\u0131 ve DynamoDB tablosunu i\u015faret ediyor. Her bir geli\u015ftirici kendi yerel makinesinde ayn\u0131 Terraform projesini klonlam\u0131\u015f durumda.<\/p>\n
\n
\n# versions.tf\nterraform {\n  backend \"s3\" {\n    bucket         = \"phoenix-project-terraform-states\"\n    key            = \"phoenix-app\/terraform.tfstate\"\n    region         = \"eu-central-1\" # \u00d6rnek b\u00f6lge\n    dynamodb_table = \"phoenix-project-locks\"\n    encrypt        = true\n  }\n}\nprovider \"aws\" {\n  region = \"eu-central-1\"\n}\n\n# main.tf (\u00f6rne\u011fin)\nresource \"aws_vpc\" \"main\" {\n  cidr_block = \"10.0.0.0\/16\"\n  tags = {\n    Name = \"Phoenix-VPC\"\n  }\n}\n<\/pre>\n
<\/code>\n<\/div>\n
Ay\u015fe'nin G\u00f6revi: Veritaban\u0131 Olu\u015fturma<\/strong>
\nAy\u015fe, uygulaman\u0131n PostgreSQL veritaban\u0131n\u0131 olu\u015fturmakla g\u00f6revli. main.tf<\/code> dosyas\u0131na bir aws_rds_instance<\/code> kayna\u011f\u0131 ekler.
\nKodunu yazd\u0131ktan sonra, terraform plan<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r ve de\u011fi\u015fiklikleri inceler. Her \u015fey yolunda g\u00f6r\u00fcnd\u00fc\u011f\u00fcnde, terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r.
\nBu komut \u00e7al\u0131\u015ft\u0131\u011f\u0131nda:
\n1.  Terraform, DynamoDB tablosunda phoenix-app\/terraform.tfstate<\/code> anahtar\u0131 i\u00e7in bir kilit olu\u015fturmaya \u00e7al\u0131\u015f\u0131r.
\n2.  Kilit ba\u015far\u0131l\u0131 olursa, S3'teki mevcut state dosyas\u0131n\u0131 indirir.
\n3.  Bulut sa\u011flay\u0131c\u0131s\u0131yla senkronize olur ve veritaban\u0131n\u0131 olu\u015fturur.
\n4.  Yeni veritaban\u0131 bilgilerini i\u00e7eren g\u00fcncel state dosyas\u0131n\u0131 S3'e geri y\u00fckler.
\n5.  Son olarak, DynamoDB'deki kilidi serbest b\u0131rak\u0131r.
\nAy\u015fe'nin apply<\/code> i\u015flemi ba\u015far\u0131yla tamamland\u0131ktan sonra, veritaban\u0131 AWS'te aktif hale gelir ve Terraform state'i S3'te bu yeni kayna\u011f\u0131 i\u00e7erecek \u015fekilde g\u00fcncellenir.<\/p>\n
Can'\u0131n G\u00f6revi: Backend API De\u011fi\u015fikli\u011fi ve Kilitleme Mekanizmas\u0131<\/strong>
\nAy\u015fe'nin veritaban\u0131n\u0131 olu\u015fturduktan k\u0131sa bir s\u00fcre sonra, Can backend API'leri i\u00e7in yeni bir Auto Scaling Group ve Load Balancer olu\u015fturmak ister. O da main.tf<\/code>'e ilgili kaynaklar\u0131 ekler ve terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131rmaya haz\u0131rlan\u0131r. Ancak o s\u0131rada Ay\u015fe, veritaban\u0131n\u0131n bir \u00f6zelli\u011fini g\u00fcncellemeyi unutmu\u015f oldu\u011funu fark eder ve h\u0131zl\u0131ca k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik yap\u0131p tekrar terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r.<\/p>\n
\u0130\u015fte tam bu noktada, DynamoDB kilitleme mekanizmas\u0131 devreye girer:
\n1.  Ay\u015fe'nin ikinci terraform apply<\/code> iste\u011fi \u00f6nce DynamoDB'de bir kilit olu\u015fturmaya \u00e7al\u0131\u015f\u0131r ve ba\u015far\u0131l\u0131 olur.
\n2.  Can'\u0131n terraform apply<\/code> iste\u011fi de ayn\u0131 anda bir kilit olu\u015fturmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, DynamoDB'de zaten bir kilit oldu\u011funu g\u00f6r\u00fcr.
\n3.  Terraform, Can'a a\u015fa\u011f\u0131daki gibi bir hata mesaj\u0131 g\u00f6sterir:<\/p>\n
\n
\nError: Error acquiring the state lock\n...\nLock Info:\n  ID: \n  Operation: OperationTypeApply\n  Info:\n  Who: ayse@example.com\n  Version: 0.14.7\n  Created: 2023-10-27T10:30:00Z\n  Path: phoenix-app\/terraform.tfstate\n\nTerraform has detected that the state lock file is already held.\n<\/pre>\n
<\/code>\n<\/div>\n
Can bu mesaj\u0131 g\u00f6rd\u00fc\u011f\u00fcnde, state'in o anda ba\u015fka birisi taraf\u0131ndan kullan\u0131ld\u0131\u011f\u0131n\u0131 anlar. Birka\u00e7 saniye veya dakika bekledikten sonra, Ay\u015fe'nin i\u015flemi bitti\u011finde kilit serbest kal\u0131r ve Can kendi terraform apply<\/code> komutunu tekrar \u00e7al\u0131\u015ft\u0131rarak sorunsuzca devam edebilir. Bu mekanizma, state dosyas\u0131n\u0131n e\u015f zamanl\u0131 yazma i\u015flemlerinden kaynaklanan bozulmalar\u0131 veya tutars\u0131zl\u0131klar\u0131 kesinlikle engeller, bu da ekip i\u00e7i i\u015fbirli\u011fini inan\u0131lmaz derecede g\u00fcvenli hale getirir.<\/p>\n
Deniz'in G\u00f6revi: Frontend \u0130\u00e7in S3 Bucket Olu\u015fturma<\/strong>
\nDeniz ise, uygulaman\u0131n statik dosyalar\u0131n\u0131 bar\u0131nd\u0131racak bir S3 bucket'\u0131 ve CloudFront da\u011f\u0131t\u0131m\u0131 olu\u015fturur. O da kendi de\u011fi\u015fikliklerini main.tf<\/code> dosyas\u0131na ekler, terraform plan<\/code> yapar ve ard\u0131ndan terraform apply<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r. DynamoDB kilitlemesi sayesinde, Ay\u015fe veya Can'\u0131n o an herhangi bir i\u015flem yapmad\u0131\u011f\u0131ndan emin olarak, kendi kaynaklar\u0131n\u0131 state'e ekler ve S3'teki state dosyas\u0131n\u0131 sorunsuz bir \u015fekilde g\u00fcnceller. Herkesin tek bir merkezi state \u00fczerinde \u00e7al\u0131\u015fmas\u0131, kaynaklar\u0131n s\u00fcrekli g\u00fcncel ve birbiriyle tutarl\u0131 olmas\u0131n\u0131 sa\u011flar. Bu senaryo, S3 backend ve DynamoDB kilitlemesinin, bir DevOps ekibinin Terraform ile g\u00fcvenli ve koordineli bir \u015fekilde altyap\u0131 y\u00f6netimi yapmas\u0131n\u0131 nas\u0131l sa\u011flad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Bu sayede, \"kimin en g\u00fcncel state'i var?\" veya \"benim yapt\u0131\u011f\u0131m de\u011fi\u015fiklikler ba\u015fkas\u0131n\u0131nkini bozar m\u0131?\" gibi endi\u015feler ortadan kalkar.<\/p>\n
\n  Uzman \u0130pucu: Farkl\u0131 ortamlar (dev, test, prod) veya b\u00fcy\u00fck projelerde farkl\u0131 mod\u00fcller i\u00e7in ayn\u0131 S3 bucket'\u0131 i\u00e7inde farkl\u0131 key<\/code> \u00f6nekleri kullanarak mant\u0131ksal olarak ayr\u0131 state dosyalar\u0131 olu\u015fturabilirsiniz. \u00d6rne\u011fin: prod\/web-app\/terraform.tfstate<\/code> veya dev\/database\/terraform.tfstate<\/code>. Bu, daha temiz bir yap\u0131 ve daha kontroll\u00fc bir y\u00f6netim sa\u011flar.\n<\/div>\n
Geli\u015fmi\u015f Konfig\u00fcrasyonlar ve G\u00fcvenlik Best Practice'leri<\/h2>\n
Terraform state'ini S3'te saklamak, temel bir g\u00fcvenlik ve i\u015fbirli\u011fi katman\u0131 sa\u011flasa da, daha sa\u011flam ve kurumsal d\u00fczeyde bir altyap\u0131 y\u00f6netimi i\u00e7in baz\u0131 geli\u015fmi\u015f konfig\u00fcrasyonlar\u0131 ve g\u00fcvenlik en iyi uygulamalar\u0131n\u0131 hayata ge\u00e7irmek b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Bu b\u00f6l\u00fcm, mevcut kurulumunuzu daha da g\u00fc\u00e7lendirecek ileri d\u00fczey tekniklere odaklanacakt\u0131r.<\/p>\n
State \u015eifrelemesi ve Anahtar Y\u00f6netimi<\/h3>\n
S3 bucket'\u0131nda depolanan Terraform state dosyalar\u0131, \u00f6zellikle hassas bilgiler i\u00e7erebildikleri i\u00e7in y\u00fcksek d\u00fczeyde \u015fifrelenmelidir. Daha \u00f6nce bahsetti\u011fimiz gibi, encrypt = true<\/code> parametresiyle varsay\u0131lan S3 \u015fifrelemesini (SSE-S3) kullanabilirsiniz. Ancak daha y\u00fcksek g\u00fcvenlik gerektiren durumlar i\u00e7in AWS Key Management Service (KMS) ile sunucu taraf\u0131 \u015fifreleme (SSE-KMS) tercih edilmelidir. KMS, \u015fifreleme anahtarlar\u0131n\u0131n y\u00f6netimini sizin ad\u0131n\u0131za \u00fcstlenir ve daha detayl\u0131 denetim ve yetkilendirme imkan\u0131 sunar.<\/p>\n
\n
\nterraform {\n  backend \"s3\" {\n    bucket         = \"my-terraform-state-bucket-unique-name\"\n    key            = \"dev\/network\/terraform.tfstate\"\n    region         = \"us-east-1\"\n    dynamodb_table = \"my-terraform-lock-table\"\n    encrypt        = true\n    kms_key_id     = \"arn:aws:kms:us-east-1:123456789012:key\/your-kms-key-id\" # KMS Anahtar\u0131n\u0131z\u0131n ARN'i\n  }\n}\n<\/pre>\n
<\/code>\n<\/div>\n
kms_key_id<\/code> parametresi ile \u00f6zel bir KMS anahtar\u0131 belirterek, state dosyan\u0131z\u0131n bu anahtar ile \u015fifrelenmesini sa\u011flayabilirsiniz. Bu, anahtar eri\u015fim politikalar\u0131 \u00fczerinden state dosyas\u0131n\u0131n kimler taraf\u0131ndan \u015fifresinin \u00e7\u00f6z\u00fclebilece\u011fi \u00fczerinde ek bir kontrol katman\u0131 sa\u011flar.<\/p>\n
Detayl\u0131 IAM Politikalar\u0131 ve Ko\u015fullu Eri\u015fim<\/h3>\n
En az ayr\u0131cal\u0131k prensibi (least privilege principle) IAM politikalar\u0131n\u0131n temelidir. S3 ve DynamoDB i\u00e7in verdi\u011fimiz temel izinler yeterli olsa da, eri\u015fimi daha da k\u0131s\u0131tlamak m\u00fcmk\u00fcnd\u00fcr. \u00d6rne\u011fin, sadece belirli IP adreslerinden veya belirli IAM rolleri taraf\u0131ndan eri\u015fime izin verebilirsiniz. IAM politikalar\u0131nda ko\u015ful anahtarlar\u0131 (condition keys) kullanarak \u00e7ok daha granular kontroller uygulayabilirsiniz:<\/p>\n
\n
\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:PutObject\"\n      ],\n      \"Resource\": \"arn:aws:s3:::my-terraform-state-bucket-unique-name\/*\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"aws:SourceVpc\": \"vpc-0abcdef1234567890\" # Sadece bu VPC'den gelen isteklere izin ver\n        }\n      }\n    },\n    {\n      \"Effect\": \"Deny\",\n      \"Action\": \"s3:DeleteObject\",\n      \"Resource\": \"arn:aws:s3:::my-terraform-state-bucket-unique-name\/*\",\n      \"Condition\": {\n        \"Null\": {\n          \"aws:MultiFactorAuthPresent\": \"true\" # MFA olmadan silme i\u015flemini engelle\n        }\n      }\n    }\n  ]\n}\n<\/pre>\n
<\/code>\n<\/div>\n
Bu \u00f6rnek politika, S3 bucket'\u0131na sadece belirli bir VPC'den eri\u015fime izin verir ve bir nesnenin silinmesini sadece Multi-Factor Authentication (MFA) kullan\u0131l\u0131yorsa onaylar. Bu t\u00fcr ko\u015fullar, yetkisiz eri\u015fimi ve yanl\u0131\u015fl\u0131kla silinmeleri \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n
Terraform Workspaces ile \u00c7oklu Ortam Y\u00f6netimi<\/h3>\n
Terraform Workspaces, ayn\u0131 konfig\u00fcrasyon dosyalar\u0131n\u0131 kullanarak farkl\u0131, izole state dosyalar\u0131 olu\u015fturman\u0131za olanak tan\u0131r. Bu, genellikle dev<\/code>, staging<\/code> ve prod<\/code> gibi farkl\u0131 ortamlar\u0131 y\u00f6netmek i\u00e7in kullan\u0131l\u0131r. Her bir workspace, kendi state dosyas\u0131na sahip olur ancak ayn\u0131 kod taban\u0131n\u0131 payla\u015f\u0131r. Bu sayede, ortamlar aras\u0131 ge\u00e7i\u015fi kolayla\u015ft\u0131r\u0131r ve her ortam\u0131n kendi benzersiz konfig\u00fcrasyonlar\u0131na sahip olmas\u0131na izin verirken kod tekrar\u0131n\u0131 azalt\u0131r.<\/p>\n
\n
\nterraform workspace new dev\nterraform workspace new staging\nterraform workspace new prod\nterraform workspace select dev\n<\/pre>\n
<\/code>\n<\/div>\n
Her bir workspace se\u00e7ildi\u011finde, Terraform o workspace'e ait state dosyas\u0131n\u0131 (\u00f6rne\u011fin S3'teki key<\/code> i\u00e7inde dev\/network\/terraform.tfstate<\/code> gibi bir alt dizinle) kullan\u0131r. Bu \u00f6zellik, daha d\u00fczenli ve hata olas\u0131l\u0131\u011f\u0131 d\u00fc\u015f\u00fck bir ortam y\u00f6netimi sa\u011flar.<\/p>\n
State Migration ve Refactoring<\/h3>\n
Zaman zaman, mevcut bir state dosyas\u0131n\u0131 farkl\u0131 bir backend'e ta\u015f\u0131mak (\u00f6rne\u011fin yerelden S3'e), S3 i\u00e7indeki key<\/code> yolunu de\u011fi\u015ftirmek veya state dosyas\u0131n\u0131 b\u00f6lmek (mod\u00fcler hale getirmek i\u00e7in) gerekebilir. Terraform, bu t\u00fcr durumlar i\u00e7in terraform state mv<\/code> ve terraform init -migrate-state<\/code> gibi komutlar sunar. \u00d6rne\u011fin, yerel bir state dosyas\u0131n\u0131 S3'e ta\u015f\u0131mak i\u00e7in, \u00f6nce S3 backend'ini yap\u0131land\u0131r\u0131r ve ard\u0131ndan terraform init -migrate-state<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131rs\u0131n\u0131z. Bu komut, Terraform'a mevcut state dosyas\u0131n\u0131 yeni backend'e ta\u015f\u0131mas\u0131n\u0131 s\u00f6yler. Bu s\u00fcre\u00e7ler dikkatle yap\u0131lmal\u0131 ve her zaman yedekleme al\u0131nmal\u0131d\u0131r.<\/p>\n
Bu geli\u015fmi\u015f konfig\u00fcrasyonlar ve en iyi uygulamalar, Terraform state y\u00f6netiminizin sadece i\u015flevsel olmakla kalmay\u0131p, ayn\u0131 zamanda son derece g\u00fcvenli, dayan\u0131kl\u0131 ve esnek olmas\u0131n\u0131 sa\u011flar. G\u00fcvenlikten \u00f6d\u00fcn vermeden, farkl\u0131 ortamlarda ve karma\u015f\u0131k altyap\u0131larda tutarl\u0131 bir y\u00f6netim deneyimi sunar.<\/p>\n
\n  Uzman \u0130pucu: S3 bucket'\u0131n\u0131z i\u00e7in \"Block Public Access\" ayarlar\u0131n\u0131 her zaman etkin tutun. Bu ayarlar, bucket'\u0131n\u0131z\u0131n veya i\u00e7indeki nesnelerin yanl\u0131\u015fl\u0131kla herkese a\u00e7\u0131k hale gelmesini \u00f6nleyerek \u00f6nemli bir g\u00fcvenlik katman\u0131 sa\u011flar.\n<\/div>\n
Mobil Uyumlu Y\u00f6netim ve Performans \u0130pu\u00e7lar\u0131<\/h2>\n
Terraform state y\u00f6netimini S3 \u00fczerinde ger\u00e7ekle\u015ftirirken, do\u011frudan bir mobil aray\u00fcz ile etkile\u015fim kurmak tipik bir senaryo olmasa da, altyap\u0131 durumunu izlemek, raporlamak veya hatta acil durum m\u00fcdahaleleri i\u00e7in mobil eri\u015filebilirli\u011fin \u00f6nemi yads\u0131namaz. Bu b\u00f6l\u00fcmde, Terraform \u00e7\u0131kt\u0131lar\u0131n\u0131 veya genel altyap\u0131 durumunu mobil cihazlarda daha iyi g\u00f6r\u00fcnt\u00fclemek i\u00e7in al\u0131nabilecek baz\u0131 yakla\u015f\u0131mlar\u0131 ve performans ipu\u00e7lar\u0131n\u0131 ele alaca\u011f\u0131z. Ayr\u0131ca, talep edildi\u011fi \u00fczere, HTML yap\u0131lar\u0131n\u0131n mobil uyumlu hale getirilmesine dair temel bir \u00f6rne\u011fi style<\/code> etiketi i\u00e7inde g\u00f6sterece\u011fiz, bunu Terraform ile olu\u015fturulan bir durum raporlama aray\u00fcz\u00fc ba\u011flam\u0131nda d\u00fc\u015f\u00fcnebilirsiniz.<\/p>\n
Mobil Uyumlu Raporlama ve Dashboard'lar<\/h3>\n
Terraform, altyap\u0131n\u0131z\u0131 y\u00f6netmek i\u00e7in CLI (Komut Sat\u0131r\u0131 Aray\u00fcz\u00fc) tabanl\u0131 bir ara\u00e7t\u0131r. Do\u011frudan mobil cihazdan terraform apply<\/code> \u00e7al\u0131\u015ft\u0131rmak pratik de\u011fildir. Ancak, Terraform ile da\u011f\u0131t\u0131lan altyap\u0131n\u0131z\u0131n sa\u011fl\u0131k durumunu, kaynak kullan\u0131m\u0131n\u0131 veya en son da\u011f\u0131t\u0131m\u0131n detaylar\u0131n\u0131 mobil cihazlardan takip etmek isteyebilirsiniz. Bunun i\u00e7in:<\/p>\n
    \n
  1. Durum Raporlama Ara\u00e7lar\u0131:<\/strong> Terraform state'ini okuyarak (IAM izinleriyle g\u00fcvenli bir \u015fekilde) ve bu verileri kullan\u0131c\u0131 dostu bir aray\u00fcze d\u00f6n\u00fc\u015ft\u00fcren \u00f6zel ara\u00e7lar geli\u015ftirebilirsiniz. Bu aray\u00fczler, mobil uyumlu HTML\/CSS ile tasarlanabilir.<\/li>\n
  2. Bulut Sa\u011flay\u0131c\u0131 Konsollar\u0131:<\/strong> AWS Console gibi mobil uygulamalar, altyap\u0131n\u0131z\u0131n genel durumunu ve Terraform taraf\u0131ndan olu\u015fturulan kaynaklar\u0131 izlemek i\u00e7in kullan\u0131labilir.<\/li>\n
  3. Grafana\/Prometheus Dashboard'lar\u0131:<\/strong> Terraform ile da\u011f\u0131tt\u0131\u011f\u0131n\u0131z izleme altyap\u0131lar\u0131 (Prometheus, Grafana) sayesinde olu\u015fturulan dashboard'lar, mobil cihazlarda da eri\u015filebilir ve okunabilir olacak \u015fekilde tasarlanabilir.<\/li>\n<\/ol>\n
    HTML ve CSS ile Mobil Uyumlu Tasar\u0131m \u00d6rne\u011fi<\/h3>\n
    Varsayal\u0131m ki, Terraform state'inden belirli verileri okuyup basit bir web aray\u00fcz\u00fc ile g\u00f6steren bir \"Altyap\u0131 Durum \u00d6zeti\" sayfas\u0131 olu\u015fturdunuz. Bu sayfan\u0131n mobil uyumlu olmas\u0131 i\u00e7in temel bir media query<\/code> kullan\u0131m\u0131 a\u015fa\u011f\u0131daki gibi olabilir:<\/p>\n
    \n
    \n