- Di lingkungan dengan target konfigurasi yang makin banyak seperti Kubernetes, cara menambah file YAML secara manual akan segera mencapai batasnya, dan pendekatan menghasilkan data konfigurasi menjadi lebih cocok daripada template YAML
- Helm chart menyuntikkan nilai dengan
values.yaml dan template Go, tetapi begitu ada field opsional, array, atau map, beban conditional dan indentasi menjadi besar
- YAML memiliki aturan whitespace yang ketat, sementara parser template Helm tidak memahami struktur YAML, sehingga kombinasi
toYaml dan indent mudah berujung pada pembuatan konfigurasi yang rapuh
- YAML adalah superset JSON sehingga konversi dua arah sederhana, dan Jsonnet memperlakukan pembuatan objek konfigurasi seperti kode melalui variabel eksternal, field kondisional, penggabungan map, dan merging objek
- kr8 menggunakan alur berbasis Jsonnet untuk membuat dan memanipulasi konfigurasi beberapa cluster Kubernetes, memilih membuat dan mengubah objek secara langsung alih-alih merangkai string YAML yang kompleks
Kompleksitas konfigurasi dimulai saat jumlah file YAML bertambah
- Setelah aplikasi dan infrastruktur melewati skala tertentu, kompleksitas konfigurasi meningkat dengan cepat
- Jika target deployment hanya 1–2, menulis file konfigurasi YAML secara langsung sudah cukup, tetapi jika lebih dari itu, konfigurasi perlu dikelola secara sistematis
- Alasan dibutuhkannya banyak file konfigurasi biasanya karena sebagian nilai berbeda meskipun targetnya sama
- Deployment per lingkungan seperti
dev, stg, prod
- Deployment per wilayah seperti Europe, North America
- Tidak semua konfigurasi berbeda, tetapi jika perbedaannya cukup besar, bagian umum dan bagian yang berbeda perlu dipisahkan dan dikelola
- Bidang manajemen konfigurasi sudah lama menangani masalah seperti ini, dan berbagai alat telah memanfaatkan YAML dengan caranya masing-masing
- hiera yang disertakan dalam Puppet kuat dan fleksibel karena dapat mencari variabel secara hierarkis, sehingga sangat mengurangi kebutuhan untuk membuat template atas YAML itu sendiri
Masalah template YAML yang terlihat pada Helm chart
- Dengan cloud computing dan Kubernetes, target konfigurasi meluas hingga lapisan di atas sistem operasi, sehingga muncul alat seperti CloudFormation dan Helm
- Helm chart dapat dirender dengan menerima parameter eksternal yang didefinisikan di
values.yaml
- Nilai string sederhana relatif mudah
image: "{{ .Values.image }}"
- Jika nilai
image ditentukan di values.yaml, nilai tersebut masuk ke template
- Masalah membesar saat mulai menangani konfigurasi yang lebih kompleks, seperti field opsional
{{- with .resourceGroup }}
resourceGroup: {{ . }}
{{- end }}
- Karena nilai opsional tidak bisa dibiarkan kosong, dibutuhkan conditional dan loop, dan template mudah menjadi berantakan
- Saat memasukkan array atau map,
toYaml dan indent harus dikombinasikan
{{- with .Values.podAnnotations }}
annotations:
{{ toYaml . | indent 8 }}
{{- end }}
- Pemanggilan fungsi yang mengubah YAML kembali menjadi YAML dengan
toYaml saja terasa janggal, tetapi masalah yang lebih besar adalah penanganan whitespace
Benturan aturan whitespace YAML dan template engine
- YAML memiliki aturan indentasi dan whitespace yang ketat
- Contoh berikut bukan YAML yang valid atau lengkap
something: nothing
hello: goodbye
- Jika ditulis langsung oleh manusia, ini bisa diperbaiki dengan menekan backspace beberapa kali, tetapi saat menghasilkan YAML dengan sistem template, masalahnya tidak sesederhana itu
- Jika file konfigurasi sudah melewati sekitar 5–10 file, yang dibutuhkan bukan lagi penulisan manual, melainkan pembuatan konfigurasi
- Untuk memasukkan nilai
.Values.podAnnotations di bawah annotations yang sudah terindentasi, nilai itu sendiri juga harus diindentasi pada level yang tepat
- Karena parser template Go tidak memahami YAML, upaya membuat sintaks template tampak rapi dengan indentasi pun bisa menimbulkan masalah
{{- with .Values.podAnnotations }}
annotations:
{{ toYaml . | indent 6 }}
{{- end }}
- Jika sistem template menangani whitespace dan conditional tanpa mengetahui struktur YAML, pembuatan konfigurasi yang kompleks menjadi makin sulit
- Menulis JSON secara langsung juga tidak cocok karena tidak ada komentar dan rawan koma yang terlewat; ketidaknyamanan seperti inilah yang membuat YAML digunakan
Jsonnet adalah bahasa template data untuk menghasilkan konfigurasi JSON
- Karena YAML adalah superset JSON, konversi antara JSON dan YAML sederhana
- Banyak aplikasi dan bahasa pemrograman dapat mem-parse atau mengonversi JSON dan YAML secara bawaan
- Di Python pun YAML dapat dibaca dan dikeluarkan sebagai JSON
python -c 'import json, sys, yaml ; y=yaml.safe_load(sys.stdin.read()) ; print(json.dumps(y))'
- Jsonnet menyebut dirinya bahasa template data, dan tujuan utamanya adalah menghasilkan konfigurasi JSON
- Latar belakang desain Jsonnet dapat dilihat di design rationale
Penanganan variabel eksternal dan field opsional
- Jsonnet dapat menyuntikkan nilai konfigurasi menggunakan variabel eksternal
{
image: std.extVar('image'),
}
- Jika variabel eksternal diberikan dari CLI, hasil JSON akan dibuat
jsonnet image.jsonnet -V image="my-image"
{
"image": "my-image"
}
- Field opsional dapat diekspresikan sebagai ekspresi conditional dalam kode, bukan menyisipkan conditional template ke dalam string
// define a variable - yes, jsonnet also has comments
local rg = null;
{
image: std.extVar('image'),
// if the variable is null, this will be blank
[if rg != null then 'resourceGroup']: rg,
}
- Jika
rg adalah null, field resourceGroup tidak disertakan dalam hasil
- Jika nilainya ditentukan, field tersebut akan dikeluarkan
Manipulasi map dan objek lebih sederhana daripada indentasi YAML
- Saat memasukkan map ke konfigurasi seperti annotation pod Kubernetes, di Jsonnet nilainya dapat didefinisikan sebagai variabel lalu ditempatkan dalam objek
local annotations = {
'nginx.ingress.kubernetes.io/app-root': '/',
'nginx.ingress.kubernetes.io/enable-cors': true,
};
{
metadata: { // annotations are nested under the metadata of a pod
annotations: annotations,
},
}
- Cara ini jauh lebih sederhana daripada menyesuaikan indentasi di template YAML
- Hasil yang dibuat adalah objek JSON dengan map annotation di bawah
metadata.annotations
{
"metadata": {
"annotations": {
"nginx.ingress.kubernetes.io/app-root": "/",
"nginx.ingress.kubernetes.io/enable-cors": true
}
}
}
- Menambahkan annotation ke objek yang sudah ada juga dapat ditangani di Jsonnet dengan operator
+
local annotations = {
'nginx.ingress.kubernetes.io/app-root': '/',
'nginx.ingress.kubernetes.io/enable-cors': true,
};
{
metadata: {
annotations: annotations,
},
} + { // this adds another JSON object
metadata+: { // I'm using the + operator, so we'll append to the existing metadata
annotations+: { // same as above
something: 'nothing',
},
},
}
- Pada objek hasil,
something: "nothing" ditambahkan ke annotation yang sudah ada
{
"metadata": {
"annotations": {
"nginx.ingress.kubernetes.io/app-root": "/",
"nginx.ingress.kubernetes.io/enable-cors": true,
"something": "nothing"
}
}
}
- Dalam contoh sederhana, kodenya mungkin terlihat lebih panjang, tetapi semakin kompleks konfigurasinya, semakin berguna kemampuan memanipulasi objek dengan cara ini
kr8 menangani konfigurasi Kubernetes dengan pendekatan Jsonnet
- kr8 menggunakan metode-metode ini untuk membuat dan memanipulasi konfigurasi beberapa cluster Kubernetes dengan mudah dan sederhana
- Alur intinya adalah membuat objek konfigurasi JSON dan mengubahnya sesuai kebutuhan, alih-alih merangkai template YAML dengan whitespace dan conditional
1 komentar
Komentar Hacker News
Saya sudah benar-benar muak dengan konfigurasi yang ditulis dalam YAML. Itu bagian yang paling saya benci dari GitHub Actions, bahkan lebih buruk daripada stabilitasnya
Saya langsung merasa cemas ketika melihat alat keren yang mengharuskan file YAML untuk konfigurasi. Bahasa konfigurasi khusus seperti HCL milik Terraform dan ASL milik AWS Step Functions juga sama
Tidak masalah menginginkan API deklaratif, tetapi saya berharap deklarasi itu bisa dibuat secara programatis. Pengalaman mendeklarasikan dan menghasilkan konfigurasi lewat kode jauh lebih baik, dan AWS CDK melakukannya dengan sangat baik
Kita bisa menulis definisi infrastruktur cloud dengan bahasa yang type-safe dan dukungan IDE yang bagus, tanpa harus bergantung pada plugin yang bahkan tidak diperbarui sejak 2 tahun lalu
deno fmtpunya formatter JSON, tetapi tidak punya formatter YAMLFormatter JSON adalah satu binary yang berjalan dalam hitungan milidetik, sedangkan auto-formatting YAML pada praktiknya harus memakai Prettier; Prettier bergantung pada separuh NPM dan butuh sekitar 2 detik untuk start dan berjalan
Jadi di repositori perusahaan, semua file YAML yang bisa diubah ke JSON saya pindahkan ke JSON, dan setidaknya saya jauh lebih puas. Tidak ada yang mengeluh
Banyak editor juga mendukung tag
$schemadi JSON. Kami menambahkan fitur ini ke produk, dan rasanya sangat bagus karena bisa membuat file konfigurasi hanya dengan menekan Tab tanpa membaca dokumentasiYAML juga bisa melakukannya dengan YAML language server, tetapi tombol Tab juga diperlukan untuk indentasi, jadi usability-nya kurang bagus. JSON juga tidak sempurna, tetapi setidaknya teks
"no"bukan bernilai trueBukankah cukup memasukkan satu filter yang menghapus komentar sebelum membaca konfigurasi? Tidak mungkin lebih sulit daripada menggantinya dengan YAML
Saya juga tidak begitu paham klaim bahwa YAML mudah dibaca. Rasa sakit mengelola konfigurasi bukan karena beberapa detik lebih sedikit untuk mem-parse kurung kurawal dan kurung siku, melainkan karena sulit mengetahui apa yang salah akibat spasi atau tab yang hilang di konfigurasi ratusan baris
Ansible juga melakukan kesalahan yang sama, begitu pula banyak sekali tool lainnya
Saya tidak begitu tahu apakah CDK bekerja dengan cara seperti itu. Saat saya mencobanya sedikit, pengalaman itu cukup berbeda dari pengalaman “menghasilkan CloudFormation” yang saya buat, dan saya belum benar-benar memahami keunggulan CDK
Rasanya seperti mengganti masalah YAML/template dengan masalah pewarisan/magic. Saya ingin mendengar lebih banyak pengalaman dari orang-orang yang pernah memakai AWS CDK, Terraform CDK, dan Pulumi
https://github.com/actions/runner/issues/1182
Saya setuju bahwa template YAML itu cukup gila, tetapi saya selalu tidak paham kenapa kita tidak berhenti memakai bahasa palsu dan memakai bahasa pemrograman sungguhan
Kalau butuh logika kompleks, cukup gunakan bahasa pemrograman untuk menghasilkan YAML/JSON/apa pun. Ruby, Python, atau bahasa lain mana pun menyediakan apa yang dibutuhkan tanpa bahasa semu aneh seperti Jsonnet atau Go template
Kalau langsung menulis kode, kita jauh lebih jarang tersandung masalah aneh yang buram dari template engine. Bahasa sungguhan apa pun akan jauh lebih baik
Saya pernah memakai Chef untuk pekerjaan serupa, dan karena berbasis Ruby, mudah mendefinisikan logika yang diinginkan serta memakai loop dan variabel yang benar; itu menyenangkan
Saya paham Ansible dirancang untuk non-programmer, tetapi bagi orang yang terbiasa dengan pemrograman dasar, tidak ada neraka yang lebih buruk daripada mengurung playbook Ansible yang penuh tugas kondisional dan perulangan di dalam sintaks template Jinja yang bertele-tele
Namun sekarang biasanya orang mengambil parser JSON/TOML/YAML dan membuat fungsi
readConfig, bahkan untuk tempat-tempat yang sebenarnya lebih cocok memakai interpreter tertanamDari sudut pandang developer, menambahkan kompleksitas ke format konfigurasi lebih mudah daripada menyediakan embedding bahasa penuh beserta binding aplikasi. Karena itu, sepertinya mereka sudah melupakan caranya, atau bahkan tidak terpikir bahwa hal itu mungkin dilakukan
Pada era Chef/Puppet, banyak tempat mulai memasukkan logika ke IaC lalu berakhir menjadi kekacauan raksasa yang mustahil di-upgrade maupun dipelihara. Pendekatan Chef/Pulumi memang bisa dilakukan, tetapi membutuhkan orang yang sangat ketat soal gaya dan pemeliharaan
Untuk tim besar dan pemeliharaan jangka panjang, menurut saya model Terraform/Puppet lebih baik. Walaupun HCL menyebalkan dan memakai Python/TypeScript dkk terasa membebaskan, kode deklaratif murni mencegah banyak spaghetti
Mereka ingin memasukkan elemen desain bahasa yang sedang tren, ingin self-hosting, dan ingin bahasa itu juga bisa dipakai menulis web server multithread cepat, sehingga secara konseptual menjadi rumit
Yang dibutuhkan adalah bahasa mainan sederhana seperti Logo untuk engineer sistem/DevOps. Idealnya bisa dijelaskan dalam satu buku seukuran buku K&R C
Dibutuhkan tipe dinamis, struktur kontrol yang bisa dipelajari dalam akhir pekan, tanpa threading atau konkurensi, tanpa OOP atau pewarisan, desain fungsional/modular, serta model FFI yang mudah dipanggil dan memanggil dari bahasa maupun framework lain
Masalahnya, para penggila bahasa tidak bisa mengendalikan diri dan terus menambahkan fitur, lalu fitur itu masuk ke library inti dan panduan gaya sehingga pemula pun harus mempelajari semuanya
Saya sendiri pun mungkin akan tergoda menambahkan fungsi sejenis
each/mapke array/hashmap serta memasukkan first-class function dan closure, tetapi itu bisa jadi kesalahan. Sudah ada bahasa fungsional immutable untuk konfigurasi, tetapi lebih dari 95% orang yang memakai template YAML tidak ingin belajar pemrograman dengan cara seperti itu, sehingga sulit menyebar luasKonfigurasi menjadi lebih sederhana, lebih mudah dikonsumsi, dan lebih baik untuk didokumentasikan. Namun saat menulis file konfigurasi, kita sebaiknya memakai bahasa pemrograman, dan kalau bisa bahasa bertipe statis yang menyediakan pemeriksaan kesalahan, autocomplete, dan dokumentasi inline
AWS CDK adalah contoh yang bagus. Menulis CloudFormation murni itu menyakitkan, tetapi CDK bukan menambahkan kemampuan pemrograman ke CloudFormation; CDK menghasilkan CloudFormation. Input yang dikonsumsi AWS tetap CloudFormation yang relatif sederhana dan stabil
Begitu melihat judulnya, saya langsung mengira ini akan membahas Kubernetes
Kubernetes API punya skema JSON yang cukup intuitif dan terdefinisi dengan baik. Sebagian besar waktu belajar k8s seharusnya dipakai untuk memahami cara menggunakan API, tetapi kenyataannya malah dipakai untuk mencari tahu cara memakai Helm chart
Saya tidak melihat Jsonnet, Ksonnet, Nu, atau CUE menjadi sangat populer. Sepertinya kebanyakan orang memakai Kustomize, karena relatif intuitif dan sudah tertanam di
kubectlAlat yang saya inginkan harus menyediakan pemeriksaan tipe, validasi, dan peringatan penghentian versi untuk skema k8s kepada penulis definisi; memberi pengguna satu artefak keluaran yang mudah diperiksa; gagal secara atomik jika kluster tidak mendukung objek/versi apa pun; dan tertanam dalam toolchain dasar
Jika skrip TypeScript Bun atau Deno mengekspor fungsi yang menerima argumen dan mengembalikan daftar definisi, rasanya akan cocok dengan
deno compiledan sejenisnya, tetapi itu melanggar syarat tertanam dalam toolchain dasarKita terlindung dari detail tingkat rendah, tetapi saat ada masalah, kita harus berhadapan dengan tumpukan abstraksi besar yang membuat diagnosis dan debugging menjadi sulit
Mengetahui apa yang sebenarnya terjadi menjadi jauh lebih sulit, dan karena bergantung pada lapisan abstraksi, kita ikut menanggung pembaruan dari penyedia serta masalah lain dalam grafik dependensi
Ia melakukan hampir semua yang kami butuhkan tanpa banyak masalah, lintas platform, dan bisa dipakai di banyak bahasa. Saya pernah menyematkannya ke executable C++, .NET, dan JVM
Konfigurasi JSON hasilnya bisa dipakai bersama ekosistem alat yang luas, yang sulit ditemukan pada alternatif seperti toml/yaml/hocon/ini. Saya pernah mencoba memakai HOCON di bahasa non-JVM, tetapi selalu tersandung pada suatu kasus tepi
Namun ketika benar-benar mengelola sistem besar, pada akhirnya manfaat template tidak bisa dihindari
Lucu melihat betapa sedikitnya developer memikirkan cara menangani konfigurasi dengan benar
Sekilas hanya tampak seperti kumpulan kunci dan nilai yang disimpan dalam file atau dihasilkan oleh kode, tetapi sebenarnya itulah semuanya. Itu adalah pemrograman itu sendiri
Semuanya adalah konfigurasi, dan semua argumen fungsi juga semacam konfigurasi. Semua konfigurasi dalam file eksternal pada akhirnya, dengan satu atau lain cara, menjadi argumen fungsi
Masalahnya adalah representasi teks biasa dari kode. File konfigurasi deklaratif terlihat bagus karena semuanya bisa dilihat di satu tempat, tetapi jika konfigurasi dibuat sebagai program, sulit menemukan bagian mana yang harus diubah
Jika kode berjalan secara langsung untuk menampilkan representasi konfigurasi akhir, dan setiap nilai konfigurasi akhir bisa dilacak bagaimana ia dihasilkan, itu bukan masalah. Namun meski fitur ini cukup sederhana, tidak ada sistem yang dirancang seperti itu. Konfigurasi selalu menjadi pemikiran belakangan
Jika konsep ini diperluas ke seluruh pemrograman, kita seharusnya bisa melihat semua kode yang bergantung pada satu nilai konfigurasi dan semua transformasinya
Selain itu, sebagian besar konfigurasi bersifat relasional/berbentuk graf, sehingga mungkin lebih baik disimpan di database pusat. Nilai konfigurasi yang berbeda saling terkait. Jadi konfigurasi seharusnya dilihat lewat database/editor graf
Begitu keluar dari teks biasa, semuanya mulai jauh lebih sederhana, tetapi fitur bahasa yang disebutkan tadi tetap masih diperlukan
Konfigurasinya mencoba memakai aturan penamaan untuk mengelompokkan variabel yang berkaitan
Mereka ingin memindahkannya ke struktur data bertingkat yang nyata, mungkin JSON, tetapi para engineer sama sekali tidak mau menulis kode, jadi konfigurasi sebagai kode tidak mungkin. Ada juga kekurangan yang disebutkan sebelumnya
Gagasan berikutnya adalah harus ada cara yang lebih baik untuk menampilkan dan mengubah konfigurasi. Saya membayangkan UI visual untuk menelusuri representasi produk akhir, memilih komponen, lalu mengubah parameter dengan cara itu
Saya penasaran apakah arah seperti ini benar. Jika tidak, saya ingin penjelasan sedikit lebih lanjut. Inti aplikasi ini adalah konfigurasi
Yang lebih buruk, di tempat seperti CI/CD, YAML nyaris menjadi bahasa pemrograman. Dan itu bahasa yang sangat bertele-tele, tidak intuitif, spesifikasinya buruk, serta berbeda-beda menurut vendor
Meski ada DTD dan validasi XML, ia punya sifat yang familier: gagal terlambat dan menghasilkan pesan kesalahan yang sulit ditafsirkan
Waktu itu banyak frustrasi diarahkan ke XML, tetapi melihat neraka YAML pada pertengahan 2020-an, masalahnya ternyata bukan bahasa markup itu sendiri
Saya benar-benar tidak suka logika dikubur di suatu tempat dalam template YAML
[0] https://tanzu.vmware.com/developer/guides/ytt-gs/
Sangat menyedihkan bahwa Helm yang menang. Di perusahaan, saya mengerjakan hal terkait k8s open source, dan 100% pengguna meminta kami membuat Helm chart, jadi akhirnya harus kami buat
Mengerjakannya terasa menyiksa. Nama filenya seperti
foo.yaml, tetapi sebenarnya bukan YAML, jadi editor tidak bisa membantu. Semua data harus dialirkan melaluiindent 4agar perataan YAML cocokHal yang paling membuat muram adalah harus mengekspos ulang semua fitur Kubernetes dengan caranya sendiri. Jika seseorang ingin menambahkan
deployment.spec.template.spec.fooBars, kita harus menambahkandeploymentFooBarskevalues.yamldan menghubungkannya. Ini berulang untuk setiap fiturIni benar-benar contoh “yang buruk itu baik” yang berjalan keliru. Saya sendiri pernah melakukan hal mengerikan seperti
sed -e s/$FOO/foo/guntuk mengimplementasikan template, dan mungkin Helm juga bermula seperti itu. Hasilnya berantakanSecara pribadi, saya sudah memakai Kustomize sejak sebelum masuk ke
kubectl, dan selalu cukup puas. Memang banyak keanehan, tetapi setidaknya ia memahami makna objek yang dihasilkan sehingga menghemat waktuJsonnet jauh lebih baik. Sebagai bagian dari aplikasi k8s kami, kami juga menyediakan deployment Envoy untuk routing trafik yang kompleks; konfigurasi Envoy memang panjang lebar, tetapi mudah ditangani dengan Jsonnet: https://github.com/pachyderm/pachyderm/blob/master/etc/gener...
Saya sedang serius mempertimbangkan untuk mentranspilasi jsonnet ke bahasa template Go lalu mengimplementasikan semuanya dengan Jsonnet. Setidaknya sedikit lebih bisa dipelihara, dan karena
helm installakan tetap berjalan begitu saja, tidak ada yang akan tahuNamun sepertinya Helm akan menjadi akhir bagi Kubernetes. Jika ada tool alokasi komputer/eksekusi container pesaing yang datang membawa bahasa yang layak untuk konfigurasi, orang-orang akan pindah dalam semalam
sed -e s/$FOO/foo/g, ada baiknya melihat envsubst sebagai solusi yang sedikit lebih standar dan lebih baikUntuk topik men-template-kan atau memodifikasi Helm chart dengan jsonnet, Tanka juga bisa membantu: https://tanka.dev/helm
Namun tempat-tempat tempat saya bekerja masih takut berubah, jadi tetap memakai tf/hcl dan helm apa adanya. Setidaknya di proyek pribadi, saya bisa sedikit bernapas lega
Saya melihat ada masalah di sini. Namun saya tidak begitu yakin apakah tipe orang yang memilih YAML sebagai bahasa konfigurasi akan melihat ini sebagai masalah
Ada konflik langsung antara representasi data yang berpusat pada manusia dan representasi data yang berpusat pada komputer. Komputer menyukai sesuatu yang mirip Lisp, sedangkan manusia menyukai sesuatu yang mirip Python
Bagi orang yang ingin memanipulasi konfigurasi Kubernetes dengan komputer, fakta bahwa Kubernetes memakai YAML akan terasa diam-diam menjengkelkan. Namun komunitas Kubernetes tampaknya terutama terdiri dari orang-orang kubu YAML, jadi mengapa mereka peduli bahwa memasukkan logika pemrograman membuat bekerja dengan file konfigurasi menjadi mengerikan?
Kelemahan YAML persis situasi ini, dan menurut saya orang-orang terkait k8s umumnya cukup pintar untuk memperkirakan hal semacam itu
Saya tidak berpikir ungkapan “YAML adalah superset dari JSON” benar dalam praktik, apa pun yang ditulis penyusun spesifikasi di dokumen. Jika semua konfigurasi YAML diubah menjadi JSON, tim DevOps akan marah
Kedua format data itu bisa memiliki representasi makna yang sama, tetapi begitu juga semua bahasa yang dikompilasi ke arsitektur CPU yang sama. JSON dan YAML dalam praktik adalah hal yang terpisah, dan mencampur keduanya bukan ide bagus
Tentu saja orang-orang akhirnya menulisnya dengan tangan, dan ketika menjadi sulit ditahan, mereka mulai menempelkan template. Sepertinya segala sesuatu selalu mengalir seperti itu
Teks yang ditulis tangan, alih-alih digantikan oleh teks serialisasi konfigurasi yang dibuat mesin, awalnya justru digantikan oleh bentuk yang masih berupa teks tulisan tangan dengan template yang ditempelkan
Prinsip pribadi saya adalah tidak boleh menggunakan interpolasi string untuk menghasilkan kode yang dibaca mesin. Bahasa template hanyalah interpolasi string yang lebih keren
Kita sudah melihat akibat dari SQL injection dan cross-site scripting. Selama kita terus memasukkan teks arbitrer ke interpreter, hal seperti ini akan terus terjadi
Karena itu, menurut saya bahkan saat membuat HTML pun sebaiknya tidak memakai file template
Sebagai alternatif bahasa template untuk HTML, ada Haml di Ruby dan Pug di JavaScript. Bahasa-bahasa ini menyediakan cara yang terdefinisi untuk menetapkan seluruh pohon tag, atribut, dan node teks
Jika tidak suka indentasi bermakna ala Python, di JavaScript ada JSX. Bagian JSX yang tampak seperti HTML dikompilasi menjadi ekspresi
createElementyang membuat pohon dokumen web, dan pohon itu bisa dikeluarkan sebagai HTML jika diperlukanHaml, Pug, dan JSX bukanlah bahasa template, meskipun bisa menghasilkan HTML. Demikian pula,
JSON.stringify(myObj)bukan bahasa template untuk JSONKode yang dibaca mesin, jika memungkinkan, harus dihasilkan dengan alat yang memahami dan memanfaatkan struktur yang diketahui dari bahasa target
Haml adalah sistem template untuk menghindari kode inline di dalam dokumen web dan membuat HTML lebih rapi, sedangkan Pug adalah engine template kaya fitur untuk Node.js
Saya bisa setuju bahwa JSX secara ketat bukan bahasa template
Pada akhirnya semuanya dikompilasi menjadi HTML. Hanya saja, bukan melalui interpolasi string, melainkan bahasa yang di-parse menjadi pohon sintaks dan di-render menjadi HTML berdasarkan pemahaman internal atas struktur yang valid
Template YAML adalah interpolasi string yang lebih keren, dan bukan bahasa template, atau setidaknya bahasa template yang diimplementasikan dengan buruk
Aturan pribadi saya: setiap kali sebuah nilai masuk ke dalam string, nilai itu harus dienkode dengan benar
Dulu saya pernah menulis tentang topik ini: https://kevincox.ca/2022/02/08/escape-everything/
Ringkasnya, semua string punya format yang harus dipatuhi, seperti HTML, SQL, atau output terminal yang dibaca manusia. Setiap kali memasukkan nilai ke dalam string, kita harus mengen-dahulukannya sesuai format itu, tetapi kita hampir tidak pernah melakukannya
Kami sedang beralih ke cuelang [1]. Secara pribadi menurut saya desainnya lebih baik daripada Jsonette
Kubernetes sudah memiliki rekonsiliasi status, jadi yang kurang dari konfigurasi ini hanyalah penghapusan, dan sekarang itu bisa ditangani dengan fitur prune [2]
[1] https://cuelang.org/docs/integrations/k8s/
[2] https://kubernetes.io/blog/2023/05/09/introducing-kubectl-ap...
Beberapa pesan error-nya agak sulit ditafsirkan, tetapi karena begitu banyak error tertangkap lebih awal, itu masih bisa diterima. Kini beberapa momen ketika harus menulis yaml langsung terasa sangat membosankan jika dibandingkan
Pada saat seperti ini, biasanya saya menyela dengan “sudahkah Anda mendengar tentang juru selamat kita, CUELang?”: https://cuelang.org/
Belum Turing-complete, tetapi cukup ekspresif untuk menghilangkan duplikasi, bisa mendefinisikan skema dan data dalam bahasa yang sama, baik di file yang sama maupun terpisah, dan juga punya tipe union
Bisa menghasilkan YAML atau JSON, dan bisa memvalidasi dirinya sendiri atau file YAML/JSON
Kelemahan terbesarnya adalah implementasi saat ini hanya Go, sehingga mungkin perlu subprocess atau FFI
Lalu pipeline itu membuat file JSON untuk tiap aplikasi, sebuah alat membuat definisi XML, definisi itu diterapkan ke XLS yang dimiliki para arsitek, dan dari sana keluar YAML untuk diterapkan ke chart Helm
Chart tersebut men-deploy klien k8s, lalu klien itu berinteraksi dengan cluster utama melalui API dalam bentuk JSON
Butuh waktu, tetapi kami memakai alat terbaik untuk masing-masing pekerjaan