YAML
2 araç
Veri Serileştirme Formatları
Veri serileştirme, yapılandırılmış verinin depolanabilir veya iletilebilir bir biçime dönüştürülmesi ve daha sonra yeniden oluşturulabilmesi sürecidir. Farklı formatlar; insan tarafından okunabilirlik, makine tarafından ayrıştırılabilirlik, ifade gücü ve dosya boyutu arasında farklı dengeler kurar. Hangi formatın seçileceği, yalnızca teknik kısıtlamalara değil; ekibin alışkanlıklarına, araç zincirine ve verinin kim tarafından tüketileceğine de bağlıdır.
JSON, YAML, TOML ve XML; yazılım geliştirmede öne çıkan dört metin tabanlı serileştirme formatıdır. Her birinin belirli bağlamlarda onu en iyi seçenek yapan güçlü yanları vardır — bu dengeleri anlamak, her iş için doğru formatı seçmenizi sağlar. Örneğin API sınırlarında JSON egemenken, altyapı otomasyonunda YAML fiili standart hâline gelmiştir.
JSON ve YAML Yan Yana
JSON ve YAML aynı veri modelini temsil eder. YAML, JSON'ın tam bir üst kümesidir — geçerli her JSON belgesi aynı zamanda geçerli bir YAML belgesidir. Aşağıda aynı yapılandırma her iki formatta da gösterilmektedir:
{
"server": {
"host": "localhost",
"port": 8080,
"debug": true
},
"database": {
"url": "postgres://localhost/mydb",
"pool": 10
}
}server: host: localhost port: 8080 debug: true database: url: postgres://localhost/mydb pool: 10
YAML, süslü parantez ve köşeli parantez yerine girinti kullanır; çoğu metin değerinde tırnak işaretlerini atlar. Bu, insan tarafından düzenlenen dosyalar için daha kompakt ve okunabilir bir format sağlar, ancak girintiye duyarlılık getirir. İki format arasında geçiş yaparken bir dönüştürücü kullanmak, elle düzenlemeye kıyasla sözdizimi hatalarını büyük ölçüde azaltır.
Format Karşılaştırması
| Format | Okunabilirlik | Yorumlar | Diziler | En iyi kullanım |
|---|---|---|---|---|
| JSON | ★★★☆☆ | Yorum yok | Yerel | API'ler, veri alışverişi |
| YAML | ★★★★★ | Evet (#) | Yerel | Yapılandırma dosyaları, IaC |
| TOML | ★★★★☆ | Evet (#) | Yerel | Uygulama yapılandırması (Rust, Python) |
| XML | ★★☆☆☆ | Evet (<!-- -->) | Tekrarlanan elemanlar | Belgeler, SOAP, SVG |
YAML Tuzakları
YAML güçlü bir format olmakla birlikte, geliştiricileri sürpriz şekilde yakalayan bilinen uç durumları vardır. En sık karşılaşılanlar şunlardır. Bu tuzakların büyük bölümü, ayrıştırıcının sizin adınıza karar vermesinden kaynaklanır; belirsiz değerleri açıkça tırnak içine almak bu sorunların çoğunu önler:
YAML 1.1'de 'NO' değeri boolean false olarak yorumlanır. NO (Norveç), OFF, FALSE, N gibi ülke kodları false olarak ayrıştırılır. YAML 1.2'de bu sorun giderilmiştir, ancak pek çok ayrıştırıcı hâlâ 1.1 kurallarını kullanmaktadır. Belirsiz dizeleri her zaman tırnak içine alın. Aynı durum 'YES', 'ON', 'TRUE', 'Y' gibi değerler için de geçerlidir — bunlar da beklenmedik şekilde boolean true'ya dönüşebilir.
YAML, yapıyı tanımlamak için girinti kullanır. Tek bir fazladan boşluk veya bir sekme karakteri, belgenin anlamını tamamen değiştirebilir. YAML'da girinti için sekme kullanımı yasaktır — yalnızca boşluk kullanın. Editörünüzün YAML dosyaları için görünmez boşluk göstergelerini etkinleştirmesi, bu tür hataları erken tespit etmenin en pratik yoludur.
Sayı, boolean veya null gibi görünen ham değerler otomatik olarak dönüştürülür. '1.0' float'a, '2024-01-01' bazı ayrıştırıcılarda tarih nesnesine dönüşür. Dize olarak saklamak istediğiniz değerleri tırnak içine alın. Özellikle ortam değişkeni değerleri, sürüm numaraları ve IP adresleri beklenmedik tür dönüşümlerine maruz kalabilir.
YAML spesifikasyonu, girinti için sekme karakterlerini açıkça yasaklar. Boşlukları otomatik olarak sekmeye dönüştüren editörler YAML dosyanızı sessizce bozabilir. Editörünüzü YAML dosyalarında boşluk kullanacak şekilde yapılandırın. Birçok CI/CD sistemi, boru hattı dosyasındaki tek bir sekme karakteri yüzünden hata ayıklaması son derece güç olan çalışma zamanı hatalarıyla karşılaşır.
YAML'ın iki çok satırlı dize göstergesi vardır: | (gerçek blok, satır sonlarını korur) ve > (katlanmış blok, satır sonlarını boşluğa dönüştürür). Bunları karıştırmak sessizce yanlış çıktı üretir. Bloğun sonundaki satır sonu davranışını ince ayarlamak için | ve > sonrasına - (kırp) veya + (tümünü koru) eklenmesi de mümkündür.
YAML çapaları (&) ve takma adları (*), düğüm yeniden kullanımına izin verir; bu güçlü bir özellik olmakla birlikte, basit ayrıştırıcılarda sonsuz döngülere veya bellek tükenmesine yol açan döngüsel referanslar oluşturabilir. Güvenilmeyen kaynaklardan gelen çapalı YAML'ı doğrulayın.
YAML'a Özgü Özellikler
Yorumlar
YAML, # karakteriyle yorum desteği sunar. Bu, yapılandırma dosyaları için JSON'a göre en büyük pratik avantajlardan biridir — ayarlarınızı satır içinde belgeleyebilirsiniz. Yorumlar kendi satırlarında veya bir değerin ardından gelebilir. Öte yandan YAML'dan JSON'a dönüştürme sırasında yorumlar kaybolur; bu nedenle yorumları korumak önemliyse YAML'ı kaynak olarak tutup yalnızca çıktı için JSON'a dönüştürün.
Çapalar ve Takma Adlar
YAML, bir düğümü &çapa-adı ile bir kez tanımlamanıza ve *çapa-adı ile istediğiniz yerde yeniden kullanmanıza olanak tanır. Bu, karmaşık yapılandırmalardaki tekrarı ortadan kaldırır. Kubernetes ve Docker Compose, paylaşılan servis tanımları için çapaları yoğun biçimde kullanır. << (birleştirme anahtarı) sözdizimini çapalarla birlikte kullanarak bir nesnenin alanlarını diğerine miras bırakmak da mümkündür.
Çok Satırlı Dizeler
YAML, iki modda blok skalerleri destekler: gerçek blok (|) satır sonlarını tam olarak korur, betikler ve şablonlar için kullanışlıdır. Katlanmış blok (>) uzun dizeleri tek bir satıra sarar, uzun düz metin açıklamaları için kullanışlıdır. Betik adımları içeren GitHub Actions iş akışları, | bloğu sayesinde çok satırlı kabuk betiklerini tek bir dize değeri olarak temiz biçimde yerleştirebildiği için bu özelliği sıklıkla kullanır.
Dönüştürmeniz Gereken Durumlar
GitHub Actions, GitLab CI ve CircleCI yerel olarak YAML kullanır. Boru hattı yapılandırmalarını programatik olarak üretirken, genellikle bir JSON nesnesi oluşturup nihai çıktı için YAML'a dönüştürmek daha kolaydır. Bu yaklaşım, boru hattı şablonlarını kod olarak yönetmenize ve birden fazla ortam için tek bir kaynaktan farklı yapılandırmalar türetmenize olanak tanır.
Kubernetes kaynakları YAML olarak tanımlanır; ancak Helm şablon sistemi ve bazı araçlar JSON çıktısı üretir. Formatlar arasında dönüştürme yaparak API yanıtlarını inceleyebilir ve standart JSON araçlarını kullanabilirsiniz. kubectl get deployment my-app -o json komutu çıktısını YAML'a dönüştürerek GitOps deposuna doğrudan kaydedebilirsiniz.
REST API'leri JSON döndürür. Bu verileri YAML tabanlı yapılandırma sistemlerine (Ansible, Salt, Kubernetes) beslerken, bir dönüştürücü manuel yeniden biçimlendirmeye gerek kalmadan köprü görevi görür. Dönüştürme adımını boru hattına eklemek, farklı araçlar arasındaki veri akışını insan müdahalesi gerektirmeden otomatikleştirir.
Bir araçtan diğerine geçiş, çoğunlukla yapılandırma formatının dönüştürülmesi anlamına gelir. JSON ve YAML arasında dönüştürme yaparak ekosistemler arasında hızlıca geçiş yapabilirsiniz (Node.js → Python, Docker → Kubernetes).
JSON Schema araçları, YAML Schema araçlarına göre daha olgunlaşmıştır. Yaygın bir yaklaşım, okunabilirlik için yapılandırmayı YAML olarak yazmak, bir şemaya karşı doğrulama için JSON'a dönüştürmek ve ardından dağıtım için geri dönüştürmektir.
Dahili araçlar YAML yapılandırmalarını tüketirken dış API'ler JSON gerektirebilir. Derleme boru hattındaki bir dönüştürücü, yinelenen dosyalar tutmadan her iki gösterimi de senkronize tutar.
Sık Sorulan Sorular
Evet. YAML 1.2, JSON'ın tam bir üst kümesidir — geçerli her JSON belgesi aynı zamanda geçerli bir YAML belgesidir. Ancak YAML 1.1 (hâlâ pek çok ayrıştırıcı tarafından kullanılan), geçerli JSON'ın geçerli YAML 1.1 olmadığı birkaç uç duruma sahiptir. Kullandığınız kütüphanenin hangi YAML sürümünü desteklediğini doğrulamak, beklenmedik ayrıştırma davranışlarını önler.
YAML, JSON'ın desteklemediği yorum desteği sunar. Ayrıca derin iç içe yapılar için YAML daha kompakttır. Bu iki özellik, YAML'ı insan tarafından düzenlenen yapılandırma dosyaları (Docker, Kubernetes, GitHub Actions) için tercih edilen seçenek yapar. Bununla birlikte, program tarafından oluşturulan veya tüketilen yapılandırmalar için JSON'ın daha güçlü araç desteği ve kesin tür semantiği avantaj sağlayabilir.
TOML (Tom's Obvious Minimal Language), yapılandırma dosyaları için tasarlanmıştır. Açık türler ve belirsizlik içermeyen, INI benzeri net bir sözdizimine sahiptir. Rust (Cargo.toml) ve Python (pyproject.toml) projeleri için standarttır.
Nadiren, ama olası. JSON, çoğu ayrıştırıcıda anahtar sırasını korur (ancak spesifikasyon sırasızı belirtir). YAML, JSON'da karşılığı olmayan çapalar ve etiketleri destekler. Gidiş-dönüş uyumluluğu için ortak alt küme ile sınırlı kalın. Çapa ve etiket gibi YAML'a özgü özellikler kullanıyorsanız, JSON'a dönüştürmeden önce bunları ön işlemle çözümlemeniz gerekir.
JSON.stringify, undefined değerleri dizilerde null'a dönüştürür ve nesnelerden dışlar. JSON çıktısında beklenmedik null değerler veya eksik anahtarlar görüyorsanız, kaynak JavaScript nesnesi muhtemelen undefined özellikler içeriyordur.
Evet. YAML, JSON'ın üst kümesi olduğundan JSON sözdizimini doğrudan bir YAML belgesi içine gömebilirsiniz. Bu, YAML girintisinin kafa karıştırıcı olacağı karmaşık iç içe yapılar için bazen tercih edilir. Ancak aynı belgede iki sözdizimini karıştırmak okunabilirliği düşürebileceğinden, bunu bilinçli bir tercih olarak yapın.