Navigator Kılavuzu: Modüler Altyapı Yapılandırması

Not : Bu, Navigator Guide Guide kitabının içeriğinin DigitalOcean Solutions Engineers tarafından sunulan bir sunumudur. Kitabın amacı, iş müşterilerinin altyapı ihtiyaçlarını planlamalarına yardımcı olmak, yol boyunca çalışma örneklerini sunmak ve teknik nüansı ve bazı kararları diğerlerinden daha iyi kılan “neden” i içermektedir.

Kitap ve beraberindeki kod, GitHub deposunda herkese açık olarak bulunacaktır. Bu erken bir sürüm olduğu için, kitap henüz tamamlanmadı ve depo henüz kamuya açık değil, ama bizi izlemeye devam edin!

Önceki bölüm, kaynakları (Damlacıklar, Yük Dengeleyicileri ve Kayan IP'ler) sağlamak ve WordPress uygulamanızı dağıtmak için Terraform ve Ansible'ı kullanmıştır.

Terraform bu kaynakları main.tf dosyasını kullanarak oluşturdu. Şu anda, bu dosyadaki tüm kaynaklar ayrı ayrı listelenmiştir. Ortamınız ne kadar karmaşık olursa, ihtiyaç duyacağınız daha fazla kaynak ve daha uzun ve daha karmaşık olan bu dosya alır. Bu, uzun vadede yapılandırmanızı daha zor hale getirecektir.

Bu ek bölümde, Terraform modüllerini ve ayrı altyapı ortamlarını kullanarak bu yapılandırmayı basitleştirmenin bazı yollarını tartışıyoruz. Yürütülecek kod yoktur ve bu bölümde yapılacak herhangi bir değişiklik yoktur, ancak gerçek dünya kurulumunda kavramlar önemlidir.

Terraform Modüllerini Anlamak

Terraform'un kendi modül tanımını kullanmak için:

Terraform'daki modüller, grup olarak yönetilen, kendi kendine yeterli Terraform konfigürasyon paketleridir. Modüller, Terraform'da ve ayrıca temel kod organizasyonu için yeniden kullanılabilir bileşenler oluşturmak için kullanılır.

Modüller, üst düzey bir programlama dilinde bir işlev gibi girişleri alıp çıktılar sağlayan yeniden kullanılabilir altyapı blokları oluşturur. Altyapımızın benzer parçaları için isteğe bağlı giriş argümanlarını kabul eden modüller oluşturabilir ve bu giriş parametreleri için varsayılan değerler belirleyebiliriz. Bu, yapılandırmanızı düzenlemenize ve basitleştirmenize yardımcı olur. Terraform'un modül belgelerinde modüller hakkında daha fazla bilgi edinebilirsiniz.

Tamamlanmış bir örnek için main.tf dosyasına bir göz atın. Son bölüm aslında bir Terraform modülü kullanıyor:

module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
...
}

Bu bölümü, çok daha fazla kod satırına sahip olan ve izlenmesi daha zor olan dosyanın wp_node doğru wp_node için kaynak bloğuyla karşılaştırabilirsiniz. Modülün bir uzak git deposu kullanılarak çağrıldığını unutmayın. Bazı hızlı geliştirme ve sınama için çalışabilecek yerel dosya yollarını kullanabilirsiniz, ancak uzak git repo kullanmak ortam yalıtımınızı bir adım ileriye taşır. Bu özellikle, evreleme ve üretim gibi çoklu altyapı ortamlarını çalıştırırken yararlıdır. Birden çok altyapı ortamına sahip yerel dosya yollarını kullanırken, yalnızca sahneyi etkilemeye yönelik bir değişiklik yapmayı sonlandırabilirsiniz, ancak prod uygulamasında bir uygulama çalıştırırsanız ve modül dosya yolu paylaşılıyorsa, bir şeyleri parçalayabilirsiniz. Her bir ortam için özel dizinler varsa, bu durumda, komut dosyalarınızın iki veya daha fazla kopyasına sahip olmak zorunda kalırsınız ve bir önceki duruma geri dönmek o kadar kolay olmaz.

Bir uzak git deposu kullanmak ve modül için bir sürüm numarası belirlemek bu sorunu ortadan kaldırır. Daha önce de belirtildiği gibi, bir şey yanlış giderse bilinen bir çalışma versiyonuna geri dönmeyi çok daha kolay hale getirir, bu da olayları ve kesintileri yönetme yeteneğinizi geliştirir (Bölüm 9'da daha ayrıntılı olarak ele alırız).

Bu modül sadece tek bir damlacık oluşturmaktan fazlasını yapar. Damlacık etiketleri, Galera küme düğümleri, yük dengeleyicileri ve Kayan IP oluşturur. Terraform modüllerini, / veya tüm bir servisin bileşenlerini paketlemenin güzel bir yolu olarak düşünebilirsiniz. Ayrıca, bir modüle daha fazla kaynak ekleyebileceğiniz veya geliştirebileceğiniz diğer modüller için girdi olarak kullanılabilecek modül çıktıları oluşturabileceğiniz anlamına da gelir. Yeni bir hizmet eklemek gibi yeni bir modül oluşturmanın ya da ayrıştırmak istediğiniz bazı destekleyici işlevlerin mantıklı olduğu durumlarda, modüllerinizde kesinlikle çıktılar oluşturabilir ve bunlar sizin durumunuzun bir parçası olarak depolanır. Uzak durumu kullanıyorsanız, altyapınızın farklı bileşenleri arasında salt okunur bilgileri paylaşmak istediğinizde veya gereksinim duyabileceği bilgileri almak için bir dış hizmet sağladığınızda modül çıktıları çok yararlı olabilir.

Basitçe söylemek gerekirse, bir Terraform planındaki kaynak bölümlerini Lego tuğlaları olarak düşünürseniz, modülleriniz ön montajlı bölümler olacaktır. Bu, her yerde Lego tuğlalarını takip etmekten ve muhtemelen bir adım atmaktan çok daha iyi. Bu ağrının engellenmesine yardımcı olmanın ötesinde, modüller, altyapı planınıza karmaşıklık ekledikçe diğer modüllerin konfigürasyonlarını bildirmek için de kullanılabilir.

Altyapı Ortamlarını Kurmak

Çoğu profesyonel projede, üç farklı ortamla çalışırsınız: geliştirme, aşamalandırma ve üretim.

Geliştirme ortamınız genellikle yereldir ve çalıştıkça bağımsız olarak test etme ve test etme konusunda size yer açar. Diğer yandan, evreleme ve üretim ortamlarınız ortak veya kamusal alanda olacak ve Terraform gibi otomatik bir süreçle sağlanacak.

Düşünceli ve planlı bir dağıtım iş akışından başlayarak baş ağrısını önlemede uzun bir yol kat edilecek ve bunun bir kısmı ortamları birbirinden ayırmayı da içeriyor. Terraform'un çalışma alanı özelliği, terraform.tfstate dosyalarını ortam başına ayrı tutar, ancak kaynaklarınızı açıklayan terraform dosyalarında yapılan değişiklikler yapılmaz. Bu özellik, küçük bir değişiklik, test ve dağıtım yapmanın hızlı bir yolu olarak işe yarayabilse de, ekiplerin yanı sıra birbirinden hizmetlerin ayrılmasını gerektirebilecek daha büyük bir dağıtımınız olduğunda güvenilmemelidir. onları yönetir.

Burada, dizinlerle ortam yalıtımı nasıl kurabileceğinizi açıklayan bir örnek dizin ağacı var:

.
├── ansible.cfg
├── bin/
├── environments/
│ ├── config/
│ │ └── cloud-config.yaml
│ │
│ ├── dev/
│ ├── prod/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ ├── staging/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ └── terraform-inventory

├── site.yml
├── wordpress.yml

└── roles/

Bu tür düzenlerin arkasındaki anahtar mantık, birbirinden ayrı ortamlarda benzer bileşenlerle ilgili dosyaları tutmaktır.

Örneğin, environments : dizininde, istediğimiz üç ortamların her biri için bir alt dizin var dev , staging ve prod . Bu yalıtım, yanlışlıkla bir Ansible veya Terraform komut dosyasını yanlışlıkla çalıştırmayı önlemeye yardımcı olur. Bir adım ileri gidebilir ve her ortamın altyapısının farklı bölümleri için dosyaları tutmak için başka bir alt dizin katmanı kullanabilirsiniz.

Bu konuyla ilgili birçok harika makale var, bunlardan biri Terzamorm: Yevgeniy Brikman'ın Up & Running kitabına dönüştü.

Ortamlar için Modül Sürümünü Kullanma

Terraform modülleri, diğer ortamları etkilemeden değişiklikler yapmanıza da yardımcı olabilir. Örneğin, bu iki modüle bir göz atın.

Evreleme ortamı için bir tane (örneğin, staging/main.tf ):

module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.8"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}

Ve bir üretim ortamı için (örneğin, prod/main.tf ):

module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}

Bunlar arasındaki tek fark, dağıtılacak sürümü belirten source satırın sonundaki ref anahtarının değeridir. Evreleme aşamasında, v1.0.8 ve üretimde, v1.0.6 . Sürüm denetimini kullanmak, üretime aktarmadan önce aşamalandırmada değişiklikler yapmanıza ve bunları test etmenize olanak tanır ve bunlar gibi ayarlar bunu destekleyen yapılandırmayı basitleştirir.

Şu anda, önceki bölümde uygulamalı kurulum uzak durumu kullanmıyor. Bölüm 6'da, bir ekipte çalışırken anahtar olan uzak bir eyalet arka planını (Konsolos gibi) ele alıyoruz. Uzak bir eyalet arka planı olmadan, hem siz hem de başka bir ekip üyesi aynı anda altyapıya değişiklikler yapabilir, çakışmalara, kesintilere veya durum dosyanızın bozulmasına neden olabilir.

Sıradaki ne?

Altyapı kodunuzu nasıl modüler hale getirdiğini ve daha güvenli geliştirme ve dağıtım için ortamları nasıl yalıtacağınızı anladığınızda, şablonlar oluşturarak dağıtım hızını nasıl artırabileceğimize bakabiliriz. Bir sonraki bölüm, yeni kodun güvenli ve hızlı bir şekilde dağıtılmasına yardımcı olacak sürekli geliştirme araçlarını kullanarak dağıtım iş akışını otomatik hale getirmeyi kapsar.

Bir önceki yazımız olan Ubuntu'da GitLab Nasıl Kurulur ve Yapılandırılır 18.04 başlıklı makalemizi de okumanızı öneririz.

About This Author

Comments are closed

%d blogcu bunu beğendi: