Terraform Import: Mevcut Altyapıyı Koda Taşıyın

Ekibiniz yıllardır konsol tıklamaları ve kabuk betikleriyle bulut kaynakları dağıtıyor. Artık Infrastructure as Code benimsemek istiyorsunuz, ancak her şeyi sıfırdan yeniden oluşturmak göz korkutucu görünüyor. Ben de bu durumla karşılaştım ve Terraform'un import işlevi bu zorluğa çözümünüz.

"ClickOps" ve manuel altyapı yönetiminin riskleri zamanla katlanır. Kaynaklar belgesiz hâle gelir, yapılandırmalar standartlardan sapar ve doğru dokümantasyonun yerini kurumsal hafıza alır. Ekip üyeleri ayrıldığında, onların altyapı kararları da onlarla birlikte gider. 

Kuruluşların Infrastructure as Code (IaC) benimsemesinin nedeni budur. Bu eğitimde, mevcut altyapıyı Terraform'a nasıl aktaracağınızı adım adım göstereceğim. 

CLI tabanlı import komutunu Terraform 1.5 ile gelen deklaratif import bloklarıyla karşılaştıracağız, her iki yaklaşım için pratik iş akışlarını inceleyeceğiz ve basit bir importu üretim kesintisine dönüştürebilecek yaygın tuzakların üstesinden geleceğiz. Sonunda, mevcut altyapınızı kod yönetimi altına almada kendinize güveneceksiniz. 

IaC ve bulut sağlayıcılarında yeniyseniz, AWS Concepts, Understanding Cloud Computing veya Understanding Microsoft Azure gibi kurslarımızdan birini almayı düşünebilirsiniz. 

Terraform Import Nedir?

Terraform ile altyapıyı en baştan oluşturduğunuzda her şey sorunsuz ilerler. Yapılandırmayı yazarsınız, terraform plan çalıştırır, değişiklikleri gözden geçirir ve uygularsınız. Terraform her şeyi durum (state) dosyasında takip eder, kodunuz ile bulut kaynaklarınız arasında kusursuz bir harita oluşturur. 

Peki ya kaynaklar Terraform'un bilgisi dışında zaten mevcutsa? Önce import'un tam olarak ne yaptığını ve neden var olduğunu anlayarak başlayalım.

Temel tanım ve amaç

Terraform import, mevcut gerçek dünya altyapısını yeni kaynaklar oluşturmadan Terraform'un durum dosyasındaki girdilere eşler. Bunu evlat edinme gibi düşünün: Terraform'a hâlihazırda çalışan bir kaynağı yönetmeye başlamasını söylüyorsunuz.

Bu, "gölge BT" sorununu çözer. Kuruluşlar farklı yollarla altyapı biriktirir: kesintiler sırasında konsoldan yapılan dağıtımlar, kalıcı hâle gelen test kaynakları veya IaC benimsenmesinden önceki eski sistemler. Import, bu gerçekliği Infrastructure as Code ilkeleriyle uzlaştırır.

Kritik nokta şu: import esas olarak bir state işlemidir. Terraform 1.5+ içindeki üretim (generation) özelliklerini kullanmadığınız sürece otomatik olarak yapılandırma kodu yazmaz. HCL yapılandırmanızın import edilen kaynağı doğru şekilde yansıttığından siz sorumlusunuz.

Artık import'un ne yaptığını bildiğimize göre, ne zaman kullanmanız ve ne zaman kullanmamanız gerektiğini inceleyelim.

Terraform import ve alternatifler

Üç ana senaryo için import öneririm:

• Kayda değer kesinti veya veri kaybı olmadan yeniden oluşturulamayacak eski altyapının taşınması. Yılların verisine sahip üretim veritabanları veya canlı trafiği karşılayan yük dengeleyiciler gibi.
• Yedekler düzgün yapılandırılmadıysa uzak arka uçlarda bile yaşanabilen kayıp state dosyalarından kurtarma.
• Kesinti sırasında yapılan acil düzeltmeler gibi, değişiklik yönetimi sürecinizi bir şekilde atlayan manuel değişikliklerin devreye alınması.

Bununla birlikte, import her zaman doğru tercih değildir. Geçici test kaynakları veya standardizasyonu zayıf altyapı için çoğu zaman temiz bir yeniden oluşturmayı öneririm. 

Sıfırdan başlamak, güncel en iyi uygulamaları uygulamanıza, doğru adlandırma kurallarını hayata geçirmenize ve eski kaynaklarda eksik olabilecek güvenlik yapılandırmalarını eklemenize olanak tanır. Yeniden oluşturmanın başlangıçtaki zahmeti, uzun vadeli sürdürülebilirlikte çoğu kez karşılığını verir.

Import'u Terraform veri kaynaklarından ayırmak önemlidir. Veri kaynakları, var olan altyapıdan salt-okunur bilgiyi yönetmeden referans almanızı sağlar. Örneğin, başka bir ekip tarafından oluşturulmuş mevcut bir VPC'yi bulmak ve ardından kaynaklarınızı onun içine dağıtmak için bir veri kaynağı kullanabilirsiniz. 

Buna karşılık import, kaynakları Terraform'un tam yönetimi altına alır; bu, onları değiştirme veya yok etme yeteneğini de içerir. Yalnızca referanslamak değil, bir kaynağın tüm yaşam döngüsünü yönetmeniz gerektiğinde import'u seçin.

Import'a başlamadan önce anlamanız gereken bazı temel kısıtlar vardır.

Temel kısıtlar ve esaslar

Her import edilen kaynak, sağlayıcıya özgü benzersiz bir tanımlayıcı gerektirir. AWS için bu i-0123456789abcdef0 olabilir. Azure için tam kaynak yolu gerekir; örneğin /subscriptions/{id}/resourceGroups/{rg}/providers/{provider}/{resource}. Bunu yanlış almak, import hatalarının bir numaralı nedenidir.

Import işlemleri doğrudan state dosyanızı değiştirir, bu nedenle yedekler hayati önem taşır. S3 gibi sürümlendirilen arka uçlar kullanıyorsanız, sürümlendirmenin etkin olduğunu doğrulayın. Yerel state ile terraform.tfstate.backup olarak elle kopyalayın.

Import sonrası "drift" ile karşılaşacaksınız: import edilen state ile yerel yapılandırma arasındaki uyumsuzluk. terraform plan sıfır bekleyen değişiklik gösterene kadar HCL kodunuzu yinelemeli olarak güncelleyeceksiniz.

Terraform Import İçin Önkoşullar ve Hazırlık 

Her şeyi import etmeden önce başarı için hazır olduğunuzdan emin olun. Ekiplerin hazırlık adımlarını atladığı için hatalı import'lar gördüm.

İlk adımınız Terraform ortamınızın doğru yapılandırıldığından emin olmaktır.

Ortamın doğrulanması

terraform version ile Terraform kurulumunuzu doğrulayarak başlayın. Deklaratif import bloklarına ve otomatik kod üretimine erişmek istiyorsanız Terraform 1.5 veya sonrasında olduğunuzdan emin olun. Bu özellikler, karmaşık kaynaklar için import sürecini büyük ölçüde basitleştirir.

Import etmeden önce şu önkoşulları doğrulayın:

• Sağlayıcı kimlik bilgileri aktif: AWS için AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY ayarlı mı veya AWS CLI profiliniz yapılandırıldı mı kontrol edin. aws sts get-caller-identity ile test edin.

• Doğru çalışma alanı seçildi: Yanlış ortama yanlışlıkla import etmediğinizi doğrulamak için terraform workspace show çalıştırın.

• State dosyası kilitli değil: Ekip üyeleriyle koordine olun ve eşzamanlı işlemler olmadığından emin olmak için CI/CD hatlarını kontrol edin.

• Arka uç erişilebilir: Uzak state kullanıyorsanız S3, Azure Storage veya Terraform Cloud'a bağlantıyı doğrulayın.

Kilitli bir state dosyası, import'unuzun kilit alma hatasıyla anında başarısız olmasına neden olur; bu nedenle ekip ortamlarında bu koordinasyon adımı kritiktir.

Ortamınızı doğruladıktan sonra, import etmek istediğiniz kaynak için tam tanımlayıcıyı bulmak kritik adımdır.

Kaynak kimliğini bulma

Kaynak kimlikleri, sağlayıcıya ve kaynak türüne göre önemli ölçüde değişir; bu da bu adımı ilk göründüğünden daha zor hâle getirir. İşte yaygın sağlayıcılardan örnekler:

AWS kaynakları için kimlikleri doğrudan konsolda bulabilirsiniz. Hizmete (EC2, S3 vb.) gidin, kaynağınızı seçin ve detaylar bölümünden tanımlayıcıyı kopyalayın.

Azure için, tam kaynak yolunu almak üzere Azure CLI kullanın:

az resource show --name myresource --resource-group mygroup

Çıktı, import için gerekli olan eksiksiz kaynak kimliğini içerir.

Benim de düştüğüm yaygın bir tuzak: yanlış bölge veya abonelikten bir kaynağı import etmeye çalışmak. Terraform sağlayıcı yapılandırmanız us-east-1'i işaret ediyorsa ama EC2 instance'ınız us-west-2'deyse, instance ID'niz doğru olsa bile import "resource not found" hatasıyla başarısız olur. 

İlerlemeden önce kapsamın sağlayıcı yapılandırmanızla eşleştiğini her zaman doğrulayın. Doğru kimliği aldıktan sonra, hangi import yöntemini kullanacağınıza karar vermeniz gerekir.

Import stratejisini seçme

İki yolunuz var: terraform import CLI komutu veya import blokları. İşte karşılaştırmaları:

Kod incelemeleri ve yeniden üretilebilir planlar gerektiren ekipler için import bloklarını, eski sürümlerde hızlı düzeltmeler için ise CLI'ı öneririm.

Bu neden önemli? Import blokları, altyapı benimsemeyi kod olarak ele alır; yani import'larınız sürüm kontrollü iş akışınızın bir parçası olur ve diğer altyapı değişiklikleriyle aynı titizlikle yönetilir. Bu, hata riskini azaltır ve uyumluluk ile ekip koordinasyonu için gerekli olan bir denetim izi oluşturur. 

Import blokları mevcut Git iş akışınızla sorunsuz bütünleşir; ekip arkadaşlarınız import'ları tıpkı diğer altyapı değişiklikleri gibi gözden geçirip onaylayabilir. CLI ise bireysel işler için daha hızlı olsa da denetim izi bırakmaz ve ortamlar arasında kolayca yeniden üretilemez.

Stratejinizi seçtiğinize göre, geleneksel CLI yaklaşımıyla başlayarak her bir iş akışını ayrıntılı olarak inceleyelim.

Çekirdek İş Akışı A: Terraform Import CLI Komutu

Sizi geleneksel CLI tabanlı import sürecinde gezdireyim. Deklaratif import blokları tercih edilmeye başlansa da CLI yöntemini anlamak, eski Terraform sürümleri ve hızlı, tek seferlik import'lar için değerlidir.

CLI iş akışındaki ilk adım, yapılandırma dosyanızı hazırlamaktır.

Hedef bloğun hazırlanması

terraform import çalıştırmadan önce, yapılandırmanızda bir resource bloğu tanımlamalısınız. Bu katı bir gerekliliktir: Terraform, import edilen state'in nereye eşleneceğini bilmelidir. Blok boş veya kısmen doldurulmuş olabilir.

İşte bir AWS S3 bucket'ını import etmek için bir örnek:

resource "aws_s3_bucket" "legacy_data" {
  # Configuration to be filled after import
}

Kaynak türü (aws_s3_bucket) import ettiğiniz altyapı türüyle tam olarak eşleşmelidir. Kaynak adı (legacy_data) proje adlandırma kurallarınıza uymalıdır. bucket1 gibi jenerik yerine production_data_bucket gibi açıklayıcı adlar kullanın.

Resource bloğunuz hazır olduğunda, import komutunu çalıştırmaya hazırsınız.

Import'u yürütme

terraform import <resource_address> <resource_id> komutunu çalıştırın. S3 bucket'ımız için:

terraform import aws_s3_bucket.legacy_data my-existing-bucket-name

Terraform, sağlayıcı API'sinden bucket'ın mevcut özniteliklerini alır ve state'e kaydeder. Şunu görürsünüz:

aws_s3_bucket.legacy_data: Import complete! 
Imported aws_s3_bucket

Artık state kaynağı içeriyor, ancak yapılandırmanız boş veya eksik kalıyor.

Asıl iş, kodunuzu import edilen state ile hizalamakla burada başlar.

Yapılandırmayı uzlaştırma

terraform plan çalıştırarak state ile yapılandırma arasındaki farkları görün. Hesaplanan öznitelikler (zaman damgaları gibi salt-okunur değerler) ve bildirmeniz gereken açık yapılandırma gerekliliklerini göreceksiniz.

Plan "kaynağı değiştirmeyi" öneriyorsa, durun. Bu, bölge veya erişilebilirlik alanı gibi değiştirilemeyen argüman uyumsuzluklarını gösterir. Yapılandırmanızı, mevcut kaynağın değiştirilemeyen öznitelikleriyle eşleşecek şekilde ayarlayın.

Çekirdek İş Akışı B: Terraform Import Bloğu

Şimdi Terraform 1.5'te tanıtılan modern yaklaşımı inceleyelim. Import blokları, import'u altyapı kodunuzun yanında yaşayan deklaratif bir yapılandırmaya dönüştürür.

Temel avantaj, yeniden üretilebilirlik ve ekip görünürlüğüdür. CLI import'larında neyin import edildiğine dair kod kaydı yoktur. Import blokları ile her import belgelenir, sürümlenir ve çekme istekleri üzerinden incelenebilir.

Önce import bloğunun kendisini oluşturarak başlayalım.

Import bloğunu tanımlama

Bir import bloğu iki bileşene sahiptir: to (hedef adres) ve id (kaynak tanımlayıcı):

import {
  to = aws_instance.web_server
  id = "i-0123456789abcdef0"
}

Bu, sürüm kontrol görünürlüğü sağlar. Ekipler, yürütmeden önce import bloklarını çekme isteklerinde inceleyebilir. Import bloklarını başarılı import'lardan sonra kolay temizleme için imports.tf içine yerleştirin.

Import bloklarının gerçekten parladığı yer burası: Terraform, baştan HCL yazmanın yorucu tahmin işini ortadan kaldırarak yapılandırma kodunu sizin için otomatik olarak üretebilir.

Yapılandırma üretimi (Terraform 1.5+)

Import blokları otomatik yapılandırma üretimini etkinleştirir. Import'u planlamak ve eşzamanlı olarak eksiksiz HCL kodu yazmak için terraform plan -generate-config-out=generated.tf komutunu çalıştırın.

Oluşturulan dosya, mevcut değerleriyle birlikte tüm öznitelikleri içerir. Gözden geçirin, gereksiz varsayılanları kaldırın ve anlamlı yapılandırmayı kod tabanınıza birleştirin. Bu, yaygın hataları önler: yanlış adlandırılmış öznitelikler, hatalı türler ve eksik zorunlu alanlar. Özellikle karmaşık kaynaklar için değerlidir.

Yapılandırmanız hazır olduğunda, import'u yürütme zamanı.

Uygulama ve sonlandırma

Son olarak, import'u yürütmek ve state'i yapılandırma ile hizalamak için terraform apply çalıştırın. Terraform, state dosyanızda herhangi bir değişiklik yapmadan önce tam olarak neyin import edildiğini gösterir.

Başarılı bir uygulamadan sonra, import bloklarını yapılandırmanızdan kaldırın. Görevlerini tamamladılar ve bırakılmaları gelecekteki çalıştırmaları yanıltır. Son olarak, terraform plan'ı bir kez daha çalıştırarak bekleyen değişikliklerin sıfır olduğunu doğrulayın; bu, yapılandırmanız ile state'in mükemmel şekilde senkronize olduğunu teyit eder.

Şimdiye kadar ele aldığımız iş akışları, basit ve bağımsız kaynaklar için kusursuz çalışır. Ancak üretim altyapısı nadiren bu kadar basittir. Modüller, yineleme ve bağımlılıkların gerçek dünya karmaşıklığının üstesinden gelelim.

Karmaşık Kaynaklar ve Modüller İçin Terraform Import

Gerçek dünya altyapısı nadiren basit, bağımsız kaynaklardan oluşur. Modülle yönetilen kaynaklar özel adresleme söz dizimi gerektirir; bu da ilk zorluğumuzdur.

Alt modüllere import etme

Modül kaynakları tam yol adreslemesi gerektirir: module.<module_name>.<resource_type>.<resource_name>; şu şekilde görünebilir:

terraform import module.network.aws_vpc.main vpc-0abcdef123456789

Doğru adresi bulmak için, normal bir apply'dan sonra terraform state list kullanın. Bu, Terraform'un modül kaynaklarına tam olarak nasıl atıf yaptığını gösterir. Adresi yanlış almak, sonraki apply'da Terraform'un oluşturmaya çalışacağı yinelenen state girdileri oluşturur.

Ayrıca, count veya for_each ile örneklenen modül örneklerine import ederken, örnek tanımlayıcısını tırnak içinde eklemeniz gerekir:

terraform import 'module.network[0].aws_vpc.main' vpc-0abcdef123456789

Modül adreslemenin ötesinde, count veya for_each meta-argümanlarını kullanan kaynaklar kendi zorluklarını sunar.

count ve for_each ile çalışmak

Terraform yapılandırmanız count kullanarak bir kaynağın birden fazla örneğini oluşturuyorsa, import için dizi söz dizimi gerekir. Örneğin, yapılandırmanız şöyleyse:

resource "aws_instance" "server" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

Her instance'ı, indeksini kullanarak ayrı ayrı import edersiniz:

terraform import 'aws_instance.server[0]' i-0123456789abcdef0
terraform import 'aws_instance.server[1]' i-1234567890abcdef1
terraform import 'aws_instance.server[2]' i-2345678901abcdef2

Öte yandan, yapılandırmasında for_each kullanan kaynaklar dize anahtarları gerektirir. Şu örneği düşünün:

resource "aws_instance" "server" {
  for_each      = toset(["web", "api", "worker"])
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

Burada, anahtar adlarını kullanarak import edersiniz:

terraform import 'aws_instance.server["web"]' i-0123456789abcdef0
terraform import 'aws_instance.server["api"]' i-1234567890abcdef1
terraform import 'aws_instance.server["worker"]' i-2345678901abcdef2

"index out of range" hatalarıyla karşılaşırsanız, count değerinizin import ettiğiniz kaynak sayısıyla eşleşmediği anlamına gelir. Çözüm basittir: import'u çalıştırmadan önce doğru count değerini ayarlayın veya yapılandırmanızda uygun for_each anahtarlarını tanımlayın.

Ayrıca, özellikle karmaşık mimarilerle uğraşırken kaynakların birbirleriyle nasıl ilişkili olduğunu düşünmeniz gerekir.

Bağımlılıkları ve yan etkileri yönetmek

Bazı bulut kaynakları tek bir varlık olarak import edilmez. Bunun yerine birden fazla Terraform kaynağı olarak import edilir: Yaygın örnekler şunlardır:

• Güvenlik grubu kuralları
• IAM ilke ekleri
• Ağ ACL kuralları

Bu durumlarda her zaman önce "ebeveyn" kaynakları import edin. Örneğin, alt ağlardan önce VPC'leri, ilke eklerinden önce IAM rolleri ve bireysel kurallardan önce güvenlik gruplarını import edin. Bu, state dosyanızda doğru bağımlılık zincirini kurar.

Import'tan sonra, sağlayıcı otomatik olarak tespit etmediği yerlerde depends_on kullanarak bağımlılıkları açıkça bildirin. Bu, gelecekteki apply işlemlerinin doğru sırada yürütülmesini sağlar ve Terraform'un bir VPC var olmadan önce alt ağ oluşturmayı denemesi gibi hataları önler.

Kaynaklarınızı başarıyla import edip düzgün şekilde yapılandırdıktan sonra, bir sonraki aşama uzun vadeli bakım ve düzenlemeye odaklanır.

State Yönetimi ve Yeniden Düzenleme

Kaynakları import etmek yalnızca başlangıçtır. Uzun vadeli başarı, doğru state yönetimi ve ara sıra yeniden düzenleme gerektirir.

Üretim kaynaklarını import ederken ilk endişeniz güvenlik olmalıdır.

Hassas bir state'i güvenceye alma

Pek çok ekibi hazırlıksız yakalayan bir durum: veritabanları veya şifreleme anahtarlarını import etmek, parolalar, özel anahtarlar ve bağlantı dizeleri gibi hassas değerleri state dosyanıza düz metin olarak çeker. Bu, derhal ele almanız gereken kritik bir güvenlik hususudur.

Çözüm, şifreli uzak arka uçlar kullanmaktır. AWS için bu, encrypt = true seçeneği ve isteğe bağlı KMS şifrelemesi etkin S3 anlamına gelir. Azure için, beklemede şifreleme etkin Azure Storage kullanın. HCP Terraform / Terraform Cloud kullanıyorsanız state varsayılan olarak beklemede ve aktarımda şifrelenir; yine de erişim kontrollerini doğrulamak isteyeceksiniz.

Ayrıca, hassas veriye sahip üretim kaynaklarını import ettikten sonra iki ek adım atın: state depolama erişim kontrollerinin doğru yapılandırıldığını doğrulayın ve state'e kimin ne zaman eriştiğini izlemek için denetim günlüğünü etkinleştirin. Bu önlemler, uyumluluk için paha biçilmez bir güvenlik denetim izi oluşturur.

Altyapınız geliştikçe, import edilen kaynakları yeniden düzenlemek ve yeniden adlandırmak isteyeceksiniz.

Import edilen kaynakları yeniden düzenleme

Kaynakları yeniden adlandırmak için iki seçeneğiniz var: terraform state mv (emredici) veya moved blokları (deklaratif). Sürüm kontrol geçmişinizde değişikliği belgeledikleri için moved bloklarını tercih ederim:

moved {
  from = aws_instance.old_name
  to   = aws_instance.new_name
}

Yeniden adlandırmanın ötesinde, sabitlenmiş ID'leri kaynak referanslarıyla değiştirmelisiniz. vpc_id = "vpc-123456" yerine vpc_id = aws_vpc.main.id kullanın. Bu yaklaşım, Terraform'un doğru işlem sırasını belirlemek için kullanabileceği düzgün bağımlılık grafiklerini oluşturur.

State yönetiminin son parçası, gelecekteki drift'i önlemektir.

Drift'e karşı sağlamlaştırma

Import sonrası kurulması gereken en önemli politika şudur: tüm değişiklikler bulut konsolu üzerinden değil, Terraform üzerinden yapılır. Kodunuz ile gerçeklik arasındaki drift'i önlemenin tek yolu budur.

Bununla birlikte, bazı öznitelikler sürekli sapar ancak yönetilmesi gerekmez. Bunlar için ignore_changes yaşam döngüsü argümanını kullanın:

lifecycle {
  ignore_changes = [tags["LastModified"]]
}

Son olarak, terraform plan'ın sadece kasıtlı değişiklikleri gösterdiği bir "temiz plan" standardı oluşturun. Dağıtım yapmıyor olsanız bile planları düzenli olarak çalıştırmayı alışkanlık hâline getirin; böylece büyük bir soruna dönüşmeden önce drift'i erken yakalayın.

Yaygın Terraform Import Hatalarını Giderme

Dikkatli hazırlığa rağmen import işlemleri başarısız olabilir. Karşılaşacağınız en yaygın sorunları teşhis edelim ve çözelim.

Adres ve ID uyumsuzlukları en sık görülen sorunlardır.

Adres ve ID hatalarını çözme

İşte en yaygın import hataları ve çözümleri:

Resource address does not exist

• Neden: Terraform, yapılandırmada resource bloğunuzu bulamıyor
• CLI import'ları için çözüm: Komutu çalıştırmadan önce boş bir resource bloğu oluşturun
• Import blokları için çözüm: to adresinde yazım hatalarını veya yanlış modül yollarını kontrol edin

Cannot import non-existent remote object

• Neden: Yanlış ID biçimi veya hatalı sağlayıcı bölgesi/aboneliği
• Çözüm: Sağlayıcı yapılandırmasının doğru AWS bölgesini, Azure aboneliğini veya GCP projesini işaret ettiğini doğrulayın
• Ayrıca kontrol edin: Sağlayıcı dokümantasyonundaki kaynak ID biçimi

Resource already managed

• Neden: Yinelenen state girdileri. Kaynak zaten farklı bir ad altında izleniyor

• Çözüm: Yinelenenleri bulmak için terraform state list çalıştırın, ardından yeniden import etmeden önce eski girdiyi kaldırmak için terraform state rm kullanın

İstemsiz değiştirmeleri önleme

Kaynakları başarıyla import ettikten sonra, onları değiştirmek isteyen planlara dikkat edin.

Import sonrası terraform plan "forces replacement" gösteriyorsa, yeniden oluşturmayı tetikleyen argümanı belirlemeniz gerekir. Yaygın nedenler EC2 AMI ID'leri veya erişilebilirlik alanları gibi değiştirilemeyen argümanlardır. Bunlar, kaynak oluşturulduktan sonra değiştirilemez.

Çözüm basittir: yapılandırmanızı gerçeklikle hizalayın. Gerçek değerleri plan çıktısından kopyalayıp yapılandırma dosyanıza ekleyin. 

Ve işte kritik bir güvenlik kuralı: kritik kaynakları yok etmeyi öneriyorsa asla onaylamayın veya uygulamayın. Bu, bir şeylerin yanlış olduğunun uyarı işaretidir.

Sağlayıcı sorunlarıyla başa çıkma

Bazen sorun yapılandırmanızla değil, sağlayıcılarınızın nasıl yapılandırıldığıyladır.

"Provider configuration depends on non-var" hataları, sağlayıcı bloğunuzun import sırasında hesaplanan değerlerin kullanımını engellediğinde ortaya çıkar. Terraform'un import için kaynağı bulması adına statik sağlayıcı yapılandırmasına ihtiyacı vardır.

Geçici çözümler sabitlemedir: dinamik sağlayıcı ayarlarını sabit değerlerle değiştirin, import'u çalıştırın, ardından dinamik yapılandırmanızı geri yükleyin. Alternatif olarak, Terraform'un import sürecinde çözebileceği sağlayıcı kimlik doğrulaması için ortam değişkenlerini kullanabilirsiniz.

Kaynak ID'niz doğru görünüyor ancak import yine de başarısız oluyorsa, tam ID biçimi gereksinimleri için sağlayıcı dokümantasyonunun "Import" bölümünü kontrol edin. Bazı kaynaklar, ayırıcı olarak eğik çizgi veya iki nokta üst üste içeren bileşik ID'ler kullanır; biçimi tam olarak doğru almak esastır.

Sonuç

Artık mevcut altyapıyı hem CLI komutları hem de import blokları kullanarak Terraform yönetimi altına almayı öğrendiniz. Her import'tan önce şu güvenlik kontrol listesini izleyin:

• Kaynak ID'lerinin sağlayıcınız için doğru olduğunu doğrulayın
• State dosyanızı yedekleyin (uzak arka uçlarda sürümlendirmeyi etkinleştirin)
• Beklenmeyen değişimlere karşı planları dikkatle inceleyin
• Doğru çalışma alanında/ortamda olduğunuzu onaylayın
• Önce kritik olmayan kaynaklarla test edin

Ancak import, terraform apply ile bitmez. Asıl iş import'tan sonra başlar: drift'i önleme politikaları oluşturmak, import edilen kaynakları standartlarınıza uyacak şekilde yeniden düzenlemek ve altyapının yalnızca kod üzerinden yönetimi konusunda ekibinizi eğitmek. Bu kültürel dönüşüm, teknik uygulama kadar önemlidir.

Bir sonraki adımınız olarak, terraform state mv ve terraform state rm ile Terraform state manipülasyonunu keşfetmenizi öneririm. Bu komutlar, altyapınız geliştikçe state dosyanızı yeniden düzenlemenize ve iyileştirmenize yardımcı olarak import'u tamamlar.

Ayrıca Terraform'u Docker ile kullanma rehberimizi incelemenizi ve bir sonraki mülakatınıza en iyi Terraform mülakat sorularımız ile hazırlık yapmanızı öneririm.