Mevcut bulut altyapısını Terraform'a import ile alma: adım adım

Import ne zaman gerekir?

Terraform ile kod olarak yönetilmeyen kaynaklar çoğu kurumda bulunur: konsoldan elle açılmış bir veritabanı, başka bir ekibin kurduğu ağ, kodlanmadan önce var olan üretim sistemi. Bu kaynakları silip yeniden oluşturmak çoğu zaman mümkün değildir. Import, var olan kaynağı Terraform state'ine bağlar; böylece kaynak yeniden yaratılmadan Terraform tarafından yönetilmeye başlanır.

HashiCorp belgelerinin tarifiyle import, dışarıda oluşturulmuş bir nesneyle yapılandırmanızdaki kaynak bloğu arasında bağ kurar. Import yalnızca state'i günceller; kaynak bloğunu sizin yazmanız ya da ürettirmeniz gerekir. Terraform kaynağı kendisi oluşturmadığı için import sonrası ilk plan çıktısı, yazdığınız yapılandırma ile gerçek durum arasındaki farkları gösterir.

Yöntem: import bloğu ile adım adım aktarım

Güncel Terraform iş akışı, yapılandırma içinde bir import bloğu tanımlamaya dayanır. Belgelerdeki örnek şöyledir:

import { to = azurerm_resource_group.this id = "mevcut-bucket-adi" }

resource "azurerm_resource_group" "this" { }

to argümanı, kaynağın state'te hangi adresle durmasını istediğinizi söyler ve mevcut bir resource bloğunun adresiyle eşleşmelidir. id ise sağlayıcının kaynağa verdiği kimliktir. Belgelere göre id plan aşamasında bilinebilir olmalıdır. Bazı kaynaklarda id yerine identity (anahtar-değer çiftleri) kullanılabilir, ancak ikisi birlikte verilmez. Doğru kimlik biçimi sağlayıcıya göre değişir; her kaynak türü için sağlayıcı belgesine bakılmalıdır.

Adımlar: önce kaynağın sağlayıcıdaki kimliğini öğrenin, import bloğunu yazın, resource bloğunu ekleyin, terraform plan ile ne olacağını görün, sonra terraform apply ile import'u uygulayın.

Kaynak bloğunu otomatik ürettirmek

Her kaynağın tüm özniteliklerini elle yazmak zahmetlidir. Terraform bunun için yapılandırma üretme seçeneği sunar: yalnız import bloğunu yazıp terraform plan -generate-config-out=<yeni dosya yolu> komutunu çalıştırırsanız Terraform, import edilecek kaynaklar için tahmini bir yapılandırma şablonunu o dosyaya yazar.

HashiCorp belgeleri bu özellik için şu uyarıları verir:

• Çıktı dosyası yeni olmalı; var olan bir dosya yolu verirseniz Terraform hata verir.
• Özellik deneyseldir; sonraki sürümlerde üretilen biçim değişebilir.
• Üretilen kod bir başlangıç taslağıdır. Gereksiz argümanları temizlemeli, değişkenlere ve diğer kaynaklara referans vermeli, uygun dosya ya da modüle taşımalısınız.
• Sağlayıcı için başka kaynak yoksa bir provider bloğu eklemek ve terraform init'i yeniden çalıştırmak gerekir.
• Bazı kaynaklarda birbiriyle çakışan argümanlar için "Conflicting configuration arguments" hatası görülebilir. Terraform dosyayı yine de yazar; çakışan argümanlardan birini silip planı yeniden çalıştırırsınız.

Üretilen kodu incelemeden depoya almak kötü bir alışkanlıktır.

Plan çıktısını doğrulamak: sıfır fark hedefi

Import tamamlandığında amaç, planın "değişiklik yok" demesidir. Plan çıktısında fark görünüyorsa iki ihtimal vardır: yazdığınız yapılandırma gerçek durumla uyuşmuyordur ya da kaynakta Terraform'un yönetmediği varsayılan bir özellik vardır. Fark listesini satır satır okuyun.

Kritik nokta, fark içinde yıkıcı bir değişiklik (kaynağın silinip yeniden oluşturulması) çıkıp çıkmadığıdır. Veritabanı gibi durum taşıyan bir kaynakta bu istenmez. Böyle bir fark varsa uygulamadan önce yapılandırmayı gerçek duruma uyduracak şekilde düzeltin.

Örneğin bir depolama alanını import ettiniz ve plan, adın değiştirileceğini gösteriyor. Bu, yazdığınız yapılandırmadaki adın gerçekle uyuşmadığını gösterir ve bu hata düzeltilmeden apply çalıştırılmaz.

Fark çıkan her öznitelik için karar verilir: ya yapılandırma gerçek değere çekilir ya da farkın kasıtlı bir değişiklik olduğu kabul edilip apply ile gerçek kaynak koda uydurulur. Hangi yolun seçildiğini değişiklik isteğinin açıklamasına yazmak, ekibin sonradan nedenini bulabilmesini sağlar.

Birden fazla kaynağı toplu almak

Çok sayıda benzer kaynak varsa tek tek import bloğu yazmak yerine import bloğunda for_each meta-argümanı kullanılabilir; bu bir map ya da string kümesi kabul eder. Böylece bir blok birden fazla kaynağı kapsar. Belgeler ayrıca keşif sorguları tanımlayıp sonuçları yapılandırmaya ekleyen toplu bir iş akışından da söz eder.

Aktarımı küçük ve mantıksal gruplar halinde yapmak güvenlidir: önce ağ, sonra güvenlik grupları, sonra uygulama kaynakları gibi. Her grup sonrası plan temizse bir sonraki gruba geçin. Bağımlılıkların doğru sırada yönetildiğini görmek için kaynaklar arasındaki ilişkileri (bir alt ağın hangi ağa ait olduğunu) referanslarla bağlayın; kimlik sabit yazmak yerine kaynak referansı kullanmak kodu esnek tutar.

Eski yöntem olan terraform import komutu da vardır; bu komut yalnız state'i günceller, yapılandırma yazmaz. Yeni projelerde import bloğu daha izlenebilir olduğu için tercih edilir, çünkü import niyeti kod incelemesinden geçebilir.

Sık yapılan hatalar

• Resource bloğu olmadan import: to adresi var olan bir resource bloğuyla eşleşmelidir; blok yoksa üretin ya da yazın.
• Yanlış kimlik biçimi: Kaynak kimliği sağlayıcıya göre değişir. Bir kaynak adı beklerken tam bir kaynak yolu vermek ya da tersi hata verir.
• Planı okumadan apply: Yıkıcı değişiklik riskini yalnız plan gösterir.
• Üretilen yapılandırmayı olduğu gibi benimsemek: Gereksiz ve sağlayıcının varsayılanı olan argümanlar kodu kirletir.
• Aynı kaynağı iki farklı state'e almak: Bir kaynak yalnız tek bir state tarafından yönetilmelidir; iki yönetim noktası birbirini bozar.
• Hassas değerleri yapılandırmada bırakmak: Üretilen taslakta parola benzeri değerler yer alabilir, temizleyin.
• State'i yedeksiz bırakmak: Import state'i değiştirir. Uzak backend kullanıyorsanız işlemden önce state sürümlemesinin açık olduğunu doğrulayın ya da mevcut state'in bir kopyasını alın; hatalı bir import geri alınabilir kalır.

Mindset programlarında nerede çalışılır?

Mevcut altyapıyı koda taşımak, kurumların elle yönetimden altyapı otomasyonuna geçişinde en sık karşılaşılan işlerden biridir. Mindset'in Terraform ile Altyapı Otomasyonu programı durum yönetimi ve backend, Terraform temelleri ve HCL dili, modüler mimari, politika ve uyumluluk otomasyonu ile CI/CD iş akışları modüllerini içerir. Bulut, sistem ve DevOps mühendislerinden oluşan ekipler, mevcut ortamı koda alma stratejisini bu program üzerinden ortak bir çerçevede çalışabilir.