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 ve yürütmeniz gerektiği bir operasyonlar dizisidir. Bu, operasyonların tüm yönlerini, hatta donanımı temsil eden yönleri bile (örneğin, fiziksel sunucuları kurmak) yazılım olarak ele aldığınız önemli bir değişimi temsil eder. Aslında DevOps'un önemli bir öngörüsü, sunucular, veritabanları, ağlar, loglar, uygulama yapılandırması, belgeler, otomatik testler, dağıtım süreçleri vb. dahil olmak üzere koddaki hemen hemen her şeyi yönetebilmenizdir.

Beş adet IAC aracı kategorisi vardır:

• Ad hoc scriptleri
• Configuration management araçları
• Server templating araçları
• Orchestration araçları
• Provisioning araçları

Tüm bunlara şimdi tek tek bakalım:

1.1 Ad Hoc Scriptleri

Herhangi bir şeyi otomatikleştirmenin en basit yaklaşımı, geçici bir komut dosyası yazmaktır. Yaptığınız herhangi bir görevi manuel olarak yaparsınız ve onu ayrı adımlara bölersiniz. Bu adımların her birini kodda tanımlamak için favori komut dosyası dilinizi (örneğin, Bash, Ruby, Python) kullanırsınız ve bu komut dosyasını aşağıda gösterildiği gibi sunucunuzda yürütürsünüz. Şekil 1.

Örneğin, bağımlılıklar kurarak, Git deposundaki bazı kodları kontrol ederek ve bir Apache web sunucusunu çalıştırarak bir web sunucusunu yapılandıran setup-webserver.sh adlı bir Bash betiği şu şekildedir:

# Update the apt-get cache
sudo apt-get update

# Install PHP and Apache
sudo apt-get install -y php apache2

# Copy the code from the repository
sudo git clone https://github.com/brikis98/php-app.git /var/www/html/app

# Start Apache
sudo service apache2 start

Ad hoc betiklerin en güzel yanı, popüler, genel amaçlı programlama dillerini kullanabilmeniz ve kodu istediğiniz gibi yazabilmenizdir. Ad hoc betiklerle ilgili en kötü şey, popüler, genel amaçlı programlama dillerini kullanabilmeniz ve kodu istediğiniz gibi yazabilmenizdir 🤭

Amaca yönelik olarak IAC için oluşturulmuş araçlar karmaşık görevleri gerçekleştirmek için kısa API'ler sağlarken, genel amaçlı bir programlama dili kullanıyorsanız her görev için tamamen özel kod yazmanız gerekir. Ayrıca, IAC için tasarlanmış araçlar genellikle kodunuz için belirli bir yapıyı zorunlu kılarken, genel amaçlı bir programlama dili ile her geliştirici kendi stilini kullanacak ve farklı bir şey yapacaktır. Bu sorunların hiçbiri Apache'yi yükleyen sekiz satırlı bir komut dosyası için önemli değildir, ancak düzinelerce sunucuyu, veritabanını, yük dengeleyiciyi, ağ yapılandırmasını vb. yönetmek için ad hoc komut dosyaları kullanmaya çalışırsanız ortalık karışır.

Daha önce büyük bir Bash komut dosyası yazmak veya kullanmak zorunda kaldıysanız, bunun neredeyse her zaman sürdürülemez bir spagetti kodu karmaşasına dönüştüğünü bilirsiniz. Ad hoc komut dosyaları küçük, tek seferlik görevler için harikadır, ancak tüm altyapınızı kod olarak yönetecekseniz, bu iş için özel olarak oluşturulmuş bir IAC aracı kullanmalısınız.

1.2 Configuration Management Araçları

Chef, Puppet, Ansible ve SaltStack'in tümü configuration management (yapılandırma yönetimi) araçlarıdır, yani mevcut sunuculara yazılım yüklemek ve yönetmek için tasarlanmıştır. Örneğin, setup-webserver.sh komut dosyasıyla aynı Apache web sunucusunu yapılandıran web-server.yml adlı bir Ansible kodu şu şekildedir:

- name: Update the apt-get cache
  apt:
    update_cache: yes

- name: Install PHP
  apt:
    name: php

- name: Install Apache
  apt:
    name: apache2

- name: Copy the code from the repository
  git: repo=https://github.com/brikis98/php-app.git dest=/var/www/html/app

- name: Start Apache
  service: name=apache2 state=started enabled=yes

Kod Bash betiğine benziyor, ancak Ansible gibi bir araç kullanmak bir dizi avantaj sunar:

• Kodlama Kuralları:

Ansible; belgeler, dosya düzeni, açıkça adlandırılmış parametreler, secrets yönetimi vb. dahil olmak üzere tutarlı, öngörülebilir bir yapı sağlar. Her geliştirici ad hoc komut dosyalarını farklı bir şekilde düzenlerken, çoğu yapılandırma yönetimi aracı, kodda gezinmeyi kolaylaştıran bir dizi kuralla birlikte gelir.

• Idempotence:

Bir kez çalışan geçici bir komut dosyası yazmak çok zor değildir fakat tekrar tekrar çalıştırsanız bile düzgün çalışan geçici bir komut dosyası yazmak çok daha zordur. Komut dosyanızda bir klasör oluşturmaya her gittiğinizde, o klasörün zaten var olup olmadığını kontrol etmeyi hatırlamanız gerekir; bir dosyaya her yapılandırma satırı eklediğinizde, o satırın zaten var olmadığını kontrol etmeniz gerekir; bir uygulamayı her çalıştırmak istediğinizde, uygulamanın halihazırda çalışmadığını kontrol etmeniz gerekir.

Kaç defa çalıştırırsanız çalıştırın düzgün çalışan koda idempotent kod denir. Önceki bölümdeki Bash betiğini bağımsız kılmak için, çok sayıda if ifadesi de dahil olmak üzere birçok kod satırı eklemeniz gerekir. Öte yandan, çoğu Ansible işlevi varsayılan olarak idempotent'dir. Örneğin, web-server.yml Ansible kodu, Apache'yi yalnızca kurulu değilse kurar ve Apache web sunucusunu yalnızca çalışmıyorsa başlatmaya çalışır.

• Dağıtım:

Ad hoc komut dosyaları, tek bir yerel makinede çalışacak şekilde tasarlanmıştır. Ansible ve diğer konfigürasyon yönetimi araçları, Şekil 2'de gösterildiği gibi, çok sayıda uzak sunucuyu yönetmek için özel olarak tasarlanmıştır.

Örneğin, web-server.yml kodunu beş sunucuya da uygulamak için önce bu sunucuların IP adreslerini içeren hosts adlı bir dosya oluşturursunuz:

[webservers]
11.11.11.11
11.11.11.12
11.11.11.13
11.11.11.14
11.11.11.15

Ardından, aşağıdaki Ansible playbooku tanımlarsınız:

- hosts: webservers
  roles:
  - webserver

Son olarak, playbooku aşağıdaki gibi yürütürsünüz:

ansible-playbook playbook.yml

Bu, Ansible'a beş sunucunun tümünü paralel olarak yapılandırma talimatı verir. Alternatif olarak, playbookta serial adlı bir parametre ayarlayarak, sunucuları toplu olarak güncelleyen, sıralı bir dağıtım yapabilirsiniz. Örneğin, serial'ı 2'ye ayarlamak, Ansible'ı, aynı anda iki sunucuyu güncellemeye yönlendirir. Bu mantığın herhangi birini ad hoc bir komut dosyasında uygulamak, düzinelerce hatta yüzlerce kod satırı gerektirir.

1.3 Server Templating Araçları

Configuration management araçlarına bir alternatif, son zamanlarda popülaritesi artan Docker, Packer ve Vagrant gibi server templating araçlarıdır. Bir grup sunucuyu başlatmak ve her birinde aynı kodu çalıştırarak yapılandırmak yerine, server templating araçlarının arkasındaki fikir; işletim sisteminin (OS) yazılım, dosyalar ve diğer tüm ilgili ayrıntılarla birlikte tamamen bağımsız bir "anlık görüntüsünü (snapshot)" içeren image'ini oluşturmaktır. Daha sonra, Şekil 3'te gösterildiği gibi, bu image'i tüm sunucularınıza yüklemek için başka bir IaC aracını kullanabilirsiniz.

Şekil 4'te gösterildiği gibi, image'lerle çalışmak için iki geniş araç kategorisi vardır:

• Virtual Machines:

Bir sanal makine (VM), donanım dahil olmak üzere tüm bilgisayar sistemini taklit eder. Temel CPU'yu, belleği, sabit sürücüyü ve ağı sanallaştırmak (yani simüle etmek) için VMWare, VirtualBox veya Parallels gibi bir hypervisor çalıştırırsınız. Bunun yararı, hypervisor üzerinde çalıştırdığınız herhangi bir VM image'inin yalnızca sanallaştırılmış donanımı görebilmesidir. Bu nedenle ana makineden ve diğer tüm VM görüntülerinden tamamen yalıtılmıştır ve tüm ortamlarda tam olarak aynı şekilde çalışacaktır (örneğin, bilgisayarınızda, bir QA sunucusunda veya bir production sunucusunda). Dezavantajı, tüm bu donanımı sanallaştırmanın ve her VM için tamamen ayrı bir işletim sistemi çalıştırmanın CPU kullanımı, bellek kullanımı ve başlatma süresi açısından çok fazla ek yüke yol açmasıdır. Packer ve Vagrant gibi araçları kullanarak VM imajlarını kod olarak tanımlayabilirsiniz.

• Containers

Bir container, bir OS'un kullanıcı alanını taklit eder. Yalıtılmış işlemler, bellek, mount point ve ağ oluşturmak için Docker, CoreOS rkt veya cri-o gibi bir container engine çalıştırırsınız. Bunun yararı, container engine'in üzerinde çalıştırdığınız herhangi bir container'in yalnızca kendi kullanıcı alanını görebilmesidir. Bu nedenle ana makineden ve diğer containerlerden yalıtılmıştır ve tüm ortamlarda (bilgisayarınız, bir QA veya production sunucu gibi) tam olarak aynı şekilde çalışır. Dezavantajı, tek bir sunucu üzerinde çalışan tüm containerlerin o sunucunun işletim sistemi çekirdeğini ve donanımını paylaşmasıdır, bu nedenle bir VM ile elde ettiğiniz yalıtım ve güvenlik düzeyine ulaşmak çok daha zordur. Ancak, çekirdek ve donanım paylaşıldığı için , containerler milisaniyeler içinde başlatılabilir ve neredeyse hiç CPU veya bellek yüküne sahip değildir. Docker ve CoreOS rkt gibi araçları kullanarak container imagelerini kod olarak tanımlayabilirsiniz;

Örneğin, AWS'de çalıştırabileceğiniz bir VM image'i olan Amazon Machine Image (AMI) oluşturan web-server.json adlı bir Packer şablonu şu şekildedir:

{
  "builders": [{
    "ami_name": "packer-example-",
    "instance_type": "t2.micro",
    "region": "us-east-2",
    "type": "amazon-ebs",
    "source_ami": "ami-0fb653ca2d3203ac1",
    "ssh_username": "ubuntu"
  }],
  "provisioners": [{
    "type": "shell",
    "inline": [
      "sudo apt-get update",
      "sudo apt-get install -y php apache2",
      "sudo git clone https://github.com/brikis98/php-app.git /var/www/html/app"
    ],
    "environment_vars": [
      "DEBIAN_FRONTEND=noninteractive"
    ],
    "pause_before": "60s"
  }]
}

Bu Packer şablonu, aynı Bash kodunu kullanarak setup-webserver.sh içinde gördüğünüz Apache web sunucusunu yapılandırır. Packer şablonundaki kod ile önceki örnekler arasındaki tek fark, bu Packer şablonunun Apache web'i başlatmamasıdır (örneğin, sudo service apache2 start'ı çalıştırarak). Bunun nedeni, sunucu şablonlarının genellikle image'lerdeki yazılımları yüklemek için kullanılmasıdır, ancak yalnızca image'i çalıştırdığınızda (örneğin, bir sunucuya deploy ederek) bu yazılımı gerçekten çalıştırmanız gerekir.

packer build webserver.json komutunu çalıştırarak bu şablondan bir AMI oluşturabilirsiniz ve derleme tamamlandıktan sonra, bu AMI'yi tüm AWS sunucularınıza yükleyebilir, her sunucuyu, sunucu önyüklenirken Apache'yi çalıştıracak şekilde yapılandırabilirsiniz. Ve tüm sunucular tam olarak aynı şekilde çalışacaktır.

Farklı server templating araçlarının biraz farklı amaçları olduğunu unutmayın. Packer, genellikle production AWS hesabınızda çalıştırdığınız bir AMI gibi doğrudan production sunucularının üzerinde çalıştırdığınız imageler oluşturmak için kullanılır. Vagrant, genellikle Mac veya Windows dizüstü bilgisayarınızda çalıştırdığınız bir VirtualBox image'i gibi geliştirme bilgisayarlarınızda çalıştırdığınız imageler oluşturmak için kullanılır. Docker genellikle bireysel uygulamaların imagelerini oluşturmak için kullanılır. Docker imagelerini, Docker Engine olan başka üretim veya geliştirme bilgisayarlarında çalıştırabilirsiniz. Örneğin, yaygın bir kullanım şekli, Docker Engine'in yüklü olduğu bir AMI oluşturmak için Packer'ı kullanmak, bu AMI'yi AWS hesabınızdaki bir sunucu kümesine deploy etmek ve ardından uygulamalarınızı çalıştırmak için bu kümede ayrı Docker containerler deploy etmektir.

Server templating, immutable (değişmez) altyapıya geçişin önemli bir bileşenidir. Bu fikir, değişkenlerin immutable olduğu işlevsel programlamadan esinlenmiştir. Bu nedenle bir değişkene bir değeri atadıktan sonra, o değişkeni bir daha asla değiştiremezsiniz. Bir şeyi güncellemeniz gerekiyorsa, yeni bir değişken yaratırsınız. Değişkenler asla değişmediğinden, kodunuz hakkında akıl yürütmek çok daha kolaydır.

Immutable altyapının ardındaki fikir şuna benzer: Bir sunucuyu bir kez kurduktan sonra, bir daha asla değişiklik yapmazsınız. Kodunuzun yeni bir sürümünü deploy etmek gibi bir şeyi güncellemeniz gerekirse, server templating ile yeni bir image oluşturur ve onu yeni bir sunucuya dağıtırsınız. Sunucular asla değişmediğinden, neyin dağıtıldığı hakkında akıl yürütmek çok daha kolaydır.

1.4 Orchestration Araçları

Server templating araçları, sanal makineler ve containerler oluşturmak için harikadır, ancak bunları gerçekte nasıl yönetirsiniz? Gerçek dünyadaki kullanım örneklerinin çoğu için aşağıdakileri yapmanın bir yoluna ihtiyacınız olacak:

• Donanımınızı verimli bir şekilde kullanarak VM'leri ve containerleri deploy edin.
• Rolling deployment, blue-green deployment ve canary deployment gibi stratejiler kullanarak mevcut bir sanal makine ve container kümesinde güncellemeler yapın.
• Sanal makinelerinizin ve conteiner'inizin durumunu izleyin ve sağlıksız olanları otomatik olarak değiştirin (auto healing).
• Trafiğe yanıt olarak VM'lerin ve containerlerin sayısını artırın veya azaltın (auto scaling).
• Trafiği sanal makineleriniz ve containerleriniz arasında dağıtın (load balancing).
• VM'lerinizin ve conteinerlerinizin ağ üzerinden birbirini bulmasına ve konuşmasına izin verin (service discovery).

Bu görevleri yerine getirmek, Kubernetes, Marathon/Mesos, Amazon Elastic Container Service (Amazon ECS), Docker Swarm ve Nomad gibi orchestration araçlarının alanıdır. Örneğin Kubernetes, Docker containerlerinizi kod olarak nasıl yöneteceğinizi tanımlamanıza olanak tanır. Önce, Kubernetes'in Docker containerlerinizi çalıştırmak için yöneteceği ve kullanacağı bir sunucu grubu olan bir Kubernetes kümesini deploy edersiniz. Çoğu büyük bulut sağlayıcısı, Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) ve Azure Kubernetes Service (AKS) gibi yönetilen Kubernetes cluster'ları deploy etmek için yerel desteğe sahiptir.

Çalışan bir cluster'ınız olduğunda, Docker containerinizi bir YAML dosyasında kod olarak nasıl çalıştıracağınızı tanımlayabilirsiniz:

apiVersion: apps/v1

# Use a Deployment to deploy multiple replicas of your Docker
# container(s) and to declaratively roll out updates to them
kind: Deployment

# Metadata about this Deployment, including its name
metadata:
  name: example-app

# The specification that configures this Deployment
spec:
  # This tells the Deployment how to find your container(s)
  selector:
    matchLabels:
      app: example-app

  # This tells the Deployment to run three replicas of your
  # Docker container(s)
  replicas: 3

  # Specifies how to update the Deployment. Here, we
  # configure a rolling update.
  strategy:
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 0
    type: RollingUpdate

  # This is the template for what container(s) to deploy
  template:

    # The metadata for these container(s), including labels
    metadata:
      labels:
        app: example-app

    # The specification for your container(s)
    spec:
      containers:

        # Run Apache listening on port 80
        - name: example-app
          image: httpd:2.4.39
          ports:
            - containerPort: 80           

Bu dosya, Kubernetes'e aşağıdakileri tanımlamanın bildirimsel bir yolu olan bir Deployment oluşturma talimatı verir:

• Birlikte çalışacak bir veya daha fazla Docker container: Bu container grubuna Pod denir. Önceki kodda tanımlanan Pod, Apache'yi çalıştıran tek bir Docker container içerir.
• Pod'daki her Docker containerin ayarları: Önceki koddaki Pod, Apache'yi 80 numaralı bağlantı noktasını dinleyecek şekilde yapılandırır.
• Cluster'da çalıştırılacak Pod'un kaç kopyası (diğer adıyla replika) gerekli: Yukarıdaki kod, üç replica'yı yapılandırır. Kubernetes, high availability açısından, kaynaklar (ör. container'ın ihtiyaç duyduğu bağlantı noktaları, CPU, bellek ve diğer kaynaklar), performans (ör. en az yüke ve en az containere sahip sunucuları seçmeye çalışır) vb. açısından en uygun sunucuları seçmek için bir zamanlama algoritması kullanarak her Pod'un kümenizde nereye dağıtılacağını otomatik olarak bulur (ör. app). Kubernetes ayrıca her zaman çalışan üç replika olduğundan emin olmak için kümeyi sürekli olarak izler ve kilitlenen veya yanıt vermeyi durduran Pod'ları otomatik olarak değiştirir.
• Güncelleştirmeler nasıl dağıtılır: Docker conainerin yeni bir sürümünü dağıtırken, önceki kod üç yeni replicayı kullanıma sunar, sağlıklı olmalarını bekler ve ardından üç eski replicayı kaldırır.

YAML'nin yalnızca birkaç satırında çok fazla güç var! Kubernetes'e uygulamanızı dağıtması talimatını vermek için kubectl application -f example-app.yml komutunu çalıştırın. Ardından, YAML dosyasında değişiklikler yapabilir ve güncellemeleri kullanıma sunmak için kubectl apply'ı yeniden çalıştırabilirsiniz. Ayrıca Terraform'u kullanarak hem Kubernetes kümesini hem de içindeki uygulamaları yönetebilirsiniz.

1.5 Provisioning Araçları

Configuration management, server templating ve orchestration araçları her sunucuda çalışan kodu tanımlarken, Terraform, CloudFormation ve OpenStack Heat gibi provisioning araçları sunucuları oluşturmaktan sorumludur. Aslında, provisioning araçlarını yalnızca sunucular oluşturmak için değil, aynı zamanda veritabanları, önbellekler, yük dengeleyiciler, kuyruklar, monitoring, subnet yapılandırmaları, güvenlik duvarı ayarları, yönlendirme kuralları, SSL/TLS sertifikaları ve neredeyse diğer tüm aspect'ler için de kullanabilirsiniz.

Örneğin, aşağıdaki kod Terraform kullanarak bir web sunucusunu deploy eder:

resource "aws_instance" "app" {
  instance_type     = "t2.micro"
  availability_zone = "us-east-2a"
  ami               = "ami-0fb653ca2d3203ac1"

  user_data = <<-EOF
              #!/bin/bash
              sudo service apache2 start
              EOF
}

Bazı syntaxa henüz aşina değilseniz endişelenmeyin. Şimdilik, sadece iki parametreye odaklanın:

• ami: Bu parametre, sunucuya deploy edilecek bir AMI'nin kimliğini belirtir. Bu parametreyi, önceki bölümde PHP, Apache ve uygulama kaynak koduna sahip web-server.json Packer şablonundan oluşturulmuş bir AMI'nin kimliğine atayabilirsiniz.
• user_data: Bu, web sunucusu önyüklenirken yürütülen bir Bash betiğidir. Önceki kod, Apache'yi başlatmak için bu betiği kullanır.

Başka bir deyişle, bu kod immutable altyapıda yaygın bir kalıp olan provisioning ve server templatingin birlikte çalıştığını gösterir.

2. Infrastructure as Code (IAC)'nin Faydaları

Artık IaC'nin tüm farklı lezzetlerini gördüğünüze göre, sormanız gereken iyi bir soru şudur: Neden bir sürü yeni dil ve araç öğrenip kendinizi yönetmek için daha fazla kodla donatıyorsunuz?

Cevap, kodun güçlü olduğudur. Manuel uygulamalarınızı koda dönüştürmeye yönelik ön yatırım karşılığında, yazılım sağlama yeteneğinizde çarpıcı gelişmeler elde edersiniz. 2016 DevOps Durumu Raporuna göre, IaC gibi DevOps uygulamalarını kullanan kuruluşlar 200 kat daha sık devreye giriyor, arızalardan 24 kat daha hızlı kurtuluyor ve 2.555 kat daha kısa teslim sürelerine sahip.

Altyapınız kod olarak tanımlandığında, aşağıdakiler dahil olmak üzere yazılım teslim sürecinizi önemli ölçüde iyileştirmek için çok çeşitli yazılım mühendisliği uygulamalarını kullanabilirsiniz:

• Self Servis:

Kodu manuel olarak deploy eden ekiplerin çoğu, dağıtımın çalışması için tüm duaları bilen ve üretime erişimi olan tek kişi olan az sayıda sistem yöneticisine (genellikle yalnızca bir) sahiptir. Şirket büyüdükçe bu büyük bir darboğaz haline gelir. Altyapınız kodda tanımlanmışsa, tüm dağıtım süreci otomatikleştirilebilir ve geliştiriciler gerektiğinde kendi dağıtımlarını başlatabilir.

• Hız ve Güvenlik:

Dağıtım süreci otomatikleştirilirse, bir bilgisayar deploy adımlarını bir kişiden çok daha hızlı gerçekleştirebileceğinden, önemli ölçüde daha hızlı olacaktır ve daha güvenli olacaktır. Çünkü otomatikleştirilmiş bir süreç daha tutarlı, daha tekrarlanabilir olacak ve manuel hataya meyilli olmayacak.

• Dökümantasyon:

Altyapınızın durumu tek bir sistem yöneticisinin kafasında kilitli kalırsa ve o sistem yöneticisi tatile giderse veya şirketten ayrılırsa veya bir otobüs çarparsa, birden artık kendi altyapınızı yönetemeyeceğinizi fark edebilirsiniz. Öte yandan, altyapınız kod olarak tanımlanmışsa, altyapınızın durumu herkesin okuyabileceği kaynak dosyalardadır. Diğer bir deyişle, IaC, sistem yöneticisi tatile çıksa bile kuruluştaki herkesin işlerin nasıl yürüdüğünü anlamasını sağlayan bir belge görevi görür.

• Versiyon Kontrol:

IaC kaynak dosyalarınızı sürüm kontrolüyle saklayabilirsinizç Bu, altyapınızın tüm geçmişinin artık commit logunda tutulduğu anlamına gelir. Bu, sorunları ayıklamak için güçlü bir araç haline gelir, çünkü ne zaman bir sorun ortaya çıkarsa, ilk adımınız commit logunu kontrol etmek ve altyapınızda nelerin değiştiğini bulmak olacaktır ve ikinci adımınız sorunu basitçe IaC kodunuzun önceki, bilinen iyi bir sürümüne geri dönerek çözmek olabilir.

• Doğrulama:

Altyapınızın durumu kodda tanımlanmışsa, her bir değişiklik için bir kod incelemesi gerçekleştirebilir, bir dizi otomatik test çalıştırabilir ve kodu statik analiz araçlarından geçirebilirsiniz.

• Yeniden Kullanılabilirlik:

Altyapınızı yeniden kullanılabilir modüller halinde paketleyebilirsiniz, böylece her ortamdaki her ürün için her dağıtımı sıfırdan yapmak yerine bilinen, belgelenmiş, test edilmiş parçaların üzerine inşa edebilirsiniz.

• Mutluluk:

IaC'yi neden kullanmanız gerektiğine dair çok önemli ve genellikle gözden kaçan bir neden daha var: mutluluk. Kodu dağıtmak ve altyapıyı manuel olarak yönetmek tekrarlayıcı ve sıkıcıdır. Geliştiriciler ve sistem yöneticileri, yaratıcılık, meydan okuma ve tanınma içermediğinden bu tür çalışmalara içerler. Kodu aylarca mükemmel bir şekilde dağıtabilirsiniz ve hiç kimse bunu fark etmeyecektir - ta ki siz her şeyi berbat ettiğiniz güne kadar. Bu stresli ve hoş olmayan bir ortam yaratır. IaC, bilgisayarların en iyi yaptıkları şeyi yapmalarına (otomasyon) ve geliştiricilerin en iyi yaptıkları şeyi yapmalarına (kodlama) izin veren daha iyi bir alternatif sunar.

Artık IaC'nin neden önemli olduğunu anladığınıza göre, sıradaki soru Terraform'un sizin için en iyi IaC aracı olup olmadığıdır. Buna cevap vermek için önce Terraform'un nasıl çalıştığına dair çok hızlı bir başlangıç ​​yapacağım ve ardından onu Chef, Puppet ve Ansible gibi diğer popüler IAC seçenekleriyle karşılaştıracağım.

Öyleyse sıradaki yazıyla devam edebilirsiniz: