Terraform Nedir? Nasıl Kurulur?
9 min read

Terraform Nedir? Nasıl Kurulur?

Terraform, basit ve declarative bir dil kullanarak altyapınızı kod olarak tanımlamanızı sağlayan açık kaynak kodlu bir araçtır.
Terraform Nedir ve Nasıl Kurulur

Terraform, basit ve declarative bir dil kullanarak altyapınızı kod olarak tanımlamanızı sağlayan açık kaynak kodlu bir araçtır. Terraform ile çeşitli genel bulut sağlayıcılarını (ör. Amazon Web Services, Microsoft Azure, Google Cloud Platform, DigitalOcean, DigitalOcean) ve özel sanallaştırma platformlarını (örn. OpenStack, VMWare) birkaç komut kullanarak yönetebilirsiniz. Örneğin, bir web sayfasını manuel olarak tıklamak veya düzinelerce komut çalıştırmak yerine, AWS'de bir sunucuyu yapılandırmak için gereken tüm kod sadece şudur:

provider "aws" {
  region = "us-east-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0fb653ca2d3203ac1"
  instance_type = "t2.micro"
}

Ve deploy etmek için aşağıdaki kodları çalıştırmanız yeterlidir:

$ terraform init
$ terraform apply

Bu basit ve bir o kadar da güçlü aracı nasıl kuracağımıza ve kullanacağımıza geçmden önce temelini öğrenerek başlayacağız.


💡
Kod bilgisayarınızda çalışırken tamamlanmış sayılmaz. Testleri geçtiğinde tamamlanmış sayılmaz. Ve biri size olumlu bir kod review verdiğinde tamamlanmış sayılmaz. Siz kullanıcıya teslim edene kadar yazılım tamamlanmış sayılmaz.

Yazılım teslimatı (Software Delivery), kodun production sunucularında çalıştırılması, kesintilere ve trafik artışlarına karşı dayanıklı hale getirilmesi ve saldırganlardan korunması gibi kodu bir müşteriye sunmak için yapmanız gereken tüm çalışmalardan oluşur. Terraform'un ayrıntılarına dalmadan önce, Terraform'un yazılım teslimatında daha büyük resimde nerede uyduğunu görmek için bir adım geri atalım.

1. DevOps'un Yükselişi

Çok da uzak olmayan geçmişte, bir yazılım şirketi kurmak istiyorsanız, aynı zamanda çok sayıda donanımı da yönetmeniz gerekiyordu. Bunlardan birkaçı şu şekildedir; kabinleri ve rafları kurmak, onları sunucularla yüklemek, kabloları bağlamak, soğutma ve yedekli güç sistemlerini ayarlamak vb. Tabi bu sorumluluklarla beraber yazılımı yazmaya adanmış, genellikle Geliştiriciler ("Devs") olarak adlandırılan bir ekibin ve bu donanımı yönetmeye ayrılmış, genellikle Operasyonlar ("Ops") adlı ayrı bir ekibin olması daha mantıklıydı.

Geleneksel geliştirme ekibi bir uygulama oluşturur ve bombayı operasyon ekibinin "kucağına bırakır". Daha sonra, bu uygulamanın nasıl dağıtılacağını ve çalıştırılacağını bulmak Ops'a kalır. Belirtmeden geçmeyelim ki bunların çoğu manuel olarak yapılır. Kısmen bu kaçınılmazdır, çünkü Ops tarafında işin çoğu zateb donanımsal olarak fiziksel işlerle geçer (örneğin, sunucuları rafa kaldırmak, ağ kablolarını takmak). Ancak, uygulamayı ve bağımlılıklarını yüklemek gibi Ops'un yazılımda yaptığı işler bile, genellikle bir sunucuda manuel olarak komutlar yürütülerek yapılır.

Bu bir süre için iyi çalışır, ancak şirket büyüdükçe sonunda sorunlarla karşılaşırsınız. Genelde de şu şekilde gelişir: sürümler manuel olarak yapıldığından, sunucu sayısı arttıkça sürümler yavaş, zahmetli ve öngörülemez hale gelir. Operasyon ekibi ara sıra hatalar yapar, bu nedenle, her birinin diğerlerinden tamamen farklı bir konfigürasyona sahip olduğu (yapılandırma kayması olarak bilinen bir sorun) kar tanesi sunucuları ile sonuçlanırsınız. Sonuç olarak, hata sayısı artar. Geliştiriciler ise omuz silkip "Makinemde çalışıyor!" demeye devam ederler. Kesintiler ve aksama süreleri daha sık hale gelir.

Her deploy'dan sonra telefonlarının çalmasından yorulan Operasyon ekibi, deploy ritmini haftada bire indirir. Sonra ayda bir. Sonra altı ayda bir. İki yılda bir yayınlanan sürümden haftalar önce, ekipler tüm projelerini mergelemeye çalışarak büyük bir merge conflict'e yol açarlar. Release branch'ini kimse sabitleyemez. Takımlar birbirini suçlamaya başlar. Şirket durma noktasına gelir.

Günümüzde artık köklü bir değişim yaşanıyor. Birçok şirket kendi veri merkezlerini yönetmek yerine, Amazon Web Services (AWS), Microsoft Azure ve Google Cloud Platform (GCP) gibi hizmetlerden yararlanarak buluta geçiyor. Pek çok Operasyon ekibi, donanıma büyük yatırım yapmak yerine, Chef, Puppet, Terraform, Docker ve Kubernetes gibi araçları kullanarak tüm zamanlarını yazılım üzerinde çalışarak geçiriyor. Sunucuları rafa almak ve ağ kablolarını takmak yerine, birçok sistem yöneticisi kod yazıyor.

Sonuç olarak, hem Geliştiriciler hem de Operasyon birimi zamanlarının çoğunu yazılım üzerinde çalışarak geçirir ve iki ekip arasındaki ayrım saydamlaşır. Uygulama kodundan sorumlu ayrı bir Geliştirme ekibine ve operasyonel koddan sorumlu bir Operasyon ekibine sahip olmak yine de mantıklı olabilir, ancak Geliştirme ve Operasyonların birlikte daha yakın çalışması gerektiği oldukça açıktır. DevOps hareketinin geldiği yer burasıdır.

DevOps, bir ekibin adı, iş unvanı veya belirli bir teknoloji değildir. Bunun yerine, bir dizi süreç, fikir ve tekniktir. Herkesin biraz farklı bir DevOps tanımı vardır, ancak bu yazı için aşağıdaki tanımı yapacağım:

💡
DevOps'un amacı, yazılım teslimini çok daha verimli hale getirmektir.

Günlerce süren merge kabusları yerine, kodu sürekli olarak entegre eder ve her zaman deploy edilebilir bir durumda tutarsınız. Kodu ayda bir kez deploy etmek yerine, günde düzinelerce kez veya hatta her bir işlemden sonra deploy edebilirsiniz. Sürekli kesintiler ve downtime'lar yerine, esnek, kendi kendini onaran sistemler kurar ve otomatik olarak çözülemeyen sorunları yakalamak için monitoring araçlarını kullanırsınız.

DevOps hareketinde dört temel değer vardır: kültür (culture), otomasyon (automation), ölçüm (measurement) ve paylaşım (sharing) (bazen CAMS kısaltması olarak kısaltılır). Bu bölüm, DevOps'a kapsamlı bir genel bakış anlamına gelmemektedir, bu yüzden sadece şu değerlerden birine odaklanacağım: otomasyon.

Otomasyonda amaç, yazılım teslim sürecini mümkün olduğunca otomatik hale getirmektir. Bu, altyapınızı bir web sayfasını tıklatarak veya shell komutlarını manuel olarak yürüterek değil, kod aracılığıyla yönettiğiniz anlamına gelir. Bu, genellikle infrastructure as code (IAC) olarak adlandırılan bir kavramdır.

Terraform konusuna geçmeden önce son durak olarak infrastructure as code nedir sindirmelisiniz. Bunun için şu yazımızı okuyarak kaldığınız yerden devam edebilirsiniz:

Infrastructure as Code (IAC) Nedir? Faydaları Nelerdir?
Infrastructure as Code (IAC), altyapınızı tanımlamak, dağıtmak, güncellemek ve yok etmek için kod yazmanızı sağlayan bir fikirdir..

Okuduysanız devam edebilirsiniz..

2. TerraForm Nasıl Çalışır?

Terraform, HashiCorp tarafından oluşturulan ve Go programlama dilinde yazılmış açık kaynaklı bir araçtır. Go kodu, terraform adı verilen tek bir binary dosyada derlenir.

Bu binary programı, dizüstü bilgisayarınızdan, bir build sunucusundan veya hemen hemen başka herhangi bir bilgisayardan altyapıyı (infrastructure) deploy etmek için kullanabilirsiniz ve bunun gerçekleşmesi için herhangi bir ek altyapı çalıştırmanız gerekmez. Bunun nedeni, kaputun altında, terraform binary dosyasının sizin adınıza AWS, Azure, Google Cloud, DigitalOcean, OpenStack ve daha fazlası gibi bir veya daha fazla sağlayıcıya API çağrıları yapmasıdır. Bu, Terraform'un bu sağlayıcıların API sunucuları için halihazırda çalıştırmakta olduğu altyapının yanı sıra bu sağlayıcılarla halihazırda kullanmakta olduğunuz kimlik doğrulama mekanizmalarından (örneğin, AWS için zaten sahip olduğunuz API anahtarları) yararlanacağı anlamına gelir.

Terraform, hangi API çağrılarının yapılacağını nasıl biliyor? Cevap, hangi altyapıyı oluşturmak istediğinizi belirttiğiniz metin dosyaları olan Terraform konfigürasyonları oluşturmanızdır. Bu konfigürasyonlar, "infrastructure as code" daki "code" dur. İşte örnek bir Terraform konfigürasyonu:

resource "aws_instance" "example" {
  ami           = "ami-0fb653ca2d3203ac1"
  instance_type = "t2.micro"
}

resource "google_dns_record_set" "a" {
  name         = "demo.google-example.com"
  managed_zone = "example-zone"
  type         = "A"
  ttl          = 300
  rrdatas      = [aws_instance.example.public_ip]
}

Terraform kodunu daha önce hiç görmemiş olsanız bile, okumakta çok fazla zorluk çekmemelisiniz. Bu snippet, Terraform'a bir sunucuyu deploy etmek için AWS'ye API çağrıları yapması ve ardından AWS sunucusunun IP adresini gösteren bir DNS girişi oluşturmak için Google Cloud'a API çağrıları yapması talimatını verir. Sadece tek bir basit sözdiziminde, Terraform birbirine bağlı kaynakları birden çok bulut sağlayıcısı arasında dağıtmanıza olanak tanır.

Tüm altyapınızı (sunucular, veritabanları, yük dengeleyiciler, ağ topolojisi vb.) Terraform yapılandırma dosyalarında tanımlayabilir ve bu dosyaları sürüm kontrolüne tabi tutabilirsiniz. Ardından, bu altyapıyı dağıtmak için terraform apply gibi belirli Terraform komutlarını çalıştırırsınız. Terraform binary dosyası, kodunuzu ayrıştırır, kodda belirtilen bulut sağlayıcılarına bir dizi API çağrısına dönüştürür ve bu API çağrılarını Şekil 1'de gösterildiği gibi sizin adınıza mümkün olduğunca verimli hale getirir.

Şekil 1: Terraform, yapılandırmalarınızın içeriğini bulut sağlayıcılarına yapılan API çağrılarına çeviren bir binary dosyadır.

Ekibinizden birinin altyapıda değişiklik yapması gerektiğinde, altyapıyı manuel olarak ve doğrudan sunucularda güncellemek yerine, değişikliklerini Terraform yapılandırma dosyalarında yapar, bu değişiklikleri otomatik testler ve kod reviewler yoluyla doğrular, güncellenen kodu garanti eder. Sürüm kontrolü ve ardından Terraform'un değişiklikleri dağıtmak için gerekli API çağrılarını yapmasını sağlamak için terraform apply komutunu çalıştırır.


Bulut Sağlayıcaları Arasında Şeffaf Taşınabilirlik

Terraform birçok farklı bulut sağlayıcısını desteklediğinden, ortaya çıkan ortak bir soru, bunlar arasında şeffaf taşınabilirliği destekleyip desteklemediğidir. Örneğin, AWS'de bir grup sunucu, veri tabanı, yük dengeleyici ve diğer altyapıyı tanımlamak için Terraform'u kullandıysanız, Terraform'a tam olarak aynı altyapıyı Azure veya Google Cloud gibi başka bir bulut sağlayıcısına yalnızca bir birkaç tıklama ile taşıyabilir misiniz?

Cevap hayır. Terraform ile ilgili herhangi bir şey yüzünden değil, bulut sağlayıcılarının kendilerinin desteklemediği için bu sorunun cevabı hayırdır. Gerçek şu ki, bulut sağlayıcıları aynı altyapı türlerini sunmadığından "tam olarak aynı altyapıyı" farklı bir bulut sağlayıcısında dağıtamazsınız! İlerleyen yazılarda bu konuya daha fazla değineceğiz.


3. TerraForm Nasıl Kurulur?

Terraform'u kurmanın en kolay yolu, işletim sisteminizin paket yöneticisini kullanmaktır. Örneğin, bir Homebrew kullanıcısıysanız macOS'ta şunları çalıştırabilirsiniz:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Windows'ta Chocolatey kullanıcısıysanız şunları çalıştırabilirsiniz:

choco install terraform

Alternatif olarak, aşağıdaki bağlantı ile Terraform indirme sayfasına giderek ve işletim sisteminize uygun indirme bağlantısına tıklayarak paketi indirebilirsiniz. Ardından indirdiğiniz ZIP arşivini Terraform'un kurulmasını istediğiniz dizine çıkartarak Terraform'u manuel olarak kurabilirsiniz. İndirdiğiniz arşiv, PATH ortam değişkeninize eklemek isteyeceğiniz terraform adlı tek bir binary dosyayı içerir.

Downloads | Terraform by HashiCorp
Terraform is an open-source infrastructure as code software tool that enables you to safely and predictably create, change, and improve infrastructure.

Her seferinde terraform binary dosyasının kurulu olduğu dizinde cmd çalıştırmak yerine PATH ekleyerek her yerden erişebilmek için Bilgisayarım -> Gelişmiş Sistem Ayarları -> Gelişmiş -> Ortam Değişkenleri -> Sistem Değişkenleri  yolunu izleyerek "PATH" değişkenini düzenleyi seçiniz ve terraform dosyanızın olduğu dizini ekleyiniz.

Şekil 2: Terraform binary dosyasını PATH'e ekleme işlemi

Path'e ekledikten sonra cmd de terraform -version komutunu çalıştırdığınızda kurulu olan versiyon numarasını görüyor olmalısınız.

Şekil 3: Terraform kurulum kontrolü

Artık Terraform kullanmaya hazırsınız. Diğer yazılarımızda temelden başlayarak Terraform komutlarını nasıl kullanacağınızı göstereceğiz.