Bash dan skrip shell masih menggerakkan job CI, server, dan perbaikan cepat. Pelajari keunggulannya, cara menulis skrip yang lebih aman, dan kapan menggunakan alat lain.
Ketika orang mengatakan “shell scripting,” mereka biasanya merujuk pada penulisan program kecil yang berjalan di dalam command-line shell. Shell membaca perintah Anda dan menjalankan program lain. Di sebagian besar server Linux, shell itu adalah POSIX sh (baseline yang distandarisasi) atau Bash (shell "sh-like" yang paling umum dengan fitur tambahan).
Dalam istilah DevOps, skrip shell adalah lapisan lem tipis yang mengikat alat OS, CLI cloud, alat build, dan file konfigurasi.
Mesin Linux sudah menyertakan utilitas inti (seperti grep, sed, awk, tar, curl, systemctl). Skrip shell bisa memanggil alat-alat ini langsung tanpa menambah runtime, paket, atau dependensi ekstra—berguna di image minimal, recovery shell, atau lingkungan yang dikunci.
Shell scripting bersinar karena sebagian besar alat mengikuti kontrak sederhana:
cmd1 | cmd2).0 berarti sukses; non-zero berarti gagal—kritis untuk otomatisasi.Kita akan fokus pada bagaimana Bash/shell cocok untuk otomasi DevOps, CI/CD, container, pemecahan masalah, portabilitas, dan praktik keselamatan. Kita tidak akan mencoba mengubah shell menjadi kerangka aplikasi penuh—ketika Anda butuh itu, kami akan menunjukkan opsi yang lebih baik (dan bagaimana shell tetap membantu di sekitarnya).
Skrip shell bukan hanya “legacy glue.” Ini adalah lapisan kecil dan andal yang mengubah rangkaian perintah manual menjadi tindakan yang dapat diulang—terutama ketika Anda bergerak cepat antar server, lingkungan, dan alat.
Bahkan jika tujuan jangka panjang Anda adalah infrastruktur yang sepenuhnya dikelola, sering ada saat Anda perlu menyiapkan host: memasang paket, menaruh file konfigurasi, mengatur izin, membuat user, atau mengambil rahasia dari sumber aman. Skrip shell pendek sempurna untuk tugas sekali jalan (atau jarang diulang) karena bisa berjalan di mana pun ada shell dan SSH.
Banyak tim menyimpan runbook sebagai dokumen, tapi runbook yang paling berdampak adalah skrip yang bisa dijalankan saat operasi rutin:
Mengubah runbook menjadi skrip mengurangi kesalahan manusia, membuat hasil lebih konsisten, dan memperbaiki serah terima.
Saat insiden terjadi, Anda jarang butuh aplikasi penuh atau dashboard—Anda butuh kejelasan. Pipeline shell dengan alat seperti grep, sed, awk, dan jq masih merupakan cara tercepat untuk memotong log, membandingkan output, dan menemukan pola di banyak node.
Pekerjaan sehari-hari sering berarti menjalankan langkah CLI yang sama di dev, staging, dan prod: memberi tag artefak, menyinkronkan file, memeriksa status, atau melakukan rollout aman. Skrip shell menangkap workflow ini sehingga konsisten antar lingkungan.
Tidak semua hal terintegrasi secara mulus. Skrip shell dapat menghubungkan “Tool A mengoutput JSON” ke “Tool B mengharapkan variabel lingkungan”, mengorkestrasi panggilan, dan menambahkan pengecekan serta retry yang hilang—tanpa menunggu integrasi atau plugin baru.
Skrip shell dan alat seperti Terraform, Ansible, Chef, dan Puppet menyelesaikan masalah yang terkait, tapi tidak saling menggantikan.
Anggap IaC/manajemen konfigurasi sebagai system of record: tempat di mana state yang diinginkan didefinisikan, direview, versioning, dan diterapkan secara konsisten. Terraform mendeklarasikan infrastruktur (network, load balancer, database). Ansible/Chef/Puppet menggambarkan konfigurasi mesin dan konvergensi berkelanjutan.
Skrip shell biasanya adalah glue code: lapisan tipis yang menghubungkan langkah, alat, dan lingkungan. Skrip mungkin tidak “menguasai” state akhir, tetapi membuat otomatisasi praktis dengan mengoordinasikan aksi.
Shell adalah pendamping yang bagus untuk IaC ketika Anda perlu:
Contoh: Terraform membuat resource, tetapi skrip Bash memvalidasi input, memastikan backend yang benar dikonfigurasi, dan menjalankan terraform plan + pemeriksaan kebijakan sebelum mengizinkan apply.
Shell cepat diimplementasikan dan minim dependensi—ideal untuk otomatisasi mendesak dan tugas koordinasi kecil. Kerugiannya adalah tata kelola jangka panjang: skrip dapat berubah menjadi “mini platform” dengan pola yang tidak konsisten, idempoten terbatas, dan audit terbatas.
Aturan praktis: gunakan IaC/alat konfigurasi untuk infrastruktur dan konfigurasi yang stateful dan dapat diulang; gunakan shell untuk workflow singkat dan komposabel di sekitarnya. Ketika skrip menjadi krusial bagi bisnis, migrasikan logika inti ke alat system-of-record dan pertahankan shell sebagai wrapper.
Sistem CI/CD mengorkestrasi langkah, tetapi tetap perlu sesuatu untuk benar-benar melakukan pekerjaan. Bash (atau POSIX sh) tetap glue default karena tersedia di sebagian besar runner, mudah dipanggil, dan dapat menggabungkan alat tanpa dependensi runtime tambahan.
Sebagian besar pipeline menggunakan langkah shell untuk tugas penting namun kurang glamor: memasang dependensi, menjalankan build, mengemas output, dan mengunggah artefak.
Contoh tipikal meliputi:
Pipeline meneruskan konfigurasi lewat variabel lingkungan, sehingga skrip shell secara alami menjadi router untuk nilai-nilai itu. Pola aman:
echo mereka, dan hindari menulis ke diskLebih disukai:
set +x di sekitar bagian sensitif (agar perintah tidak tercetak)CI butuh perilaku yang dapat diprediksi. Skrip pipeline yang baik:
Caching dan langkah paralel biasanya dikontrol oleh sistem CI, bukan skrip—Bash tidak dapat mengelola cache bersama antar job secara andal. Yang bisa dilakukan adalah membuat key cache dan direktori konsisten.
Untuk menjaga skrip terbaca antar tim, perlakukan mereka seperti kode produk: fungsi kecil, penamaan konsisten, dan header penggunaan singkat. Simpan skrip bersama repo (mis., di /ci/) sehingga perubahan direview bersamaan dengan kode yang dibangun.
Jika tim Anda terus menulis “satu skrip CI lagi,” workflow berbantuan AI dapat membantu—terutama untuk boilerplate seperti parsing argumen, retry, logging aman, dan guardrail. Di Koder.ai, Anda dapat mendeskripsikan job pipeline dalam bahasa biasa dan menghasilkan skrip Bash/sh starter, lalu iterasi dalam planning mode sebelum menjalankannya. Karena Koder.ai mendukung ekspor source code plus snapshot dan rollback, lebih mudah memperlakukan skrip sebagai artefak yang direview daripada snippet ad-hoc yang disalin ke YAML CI.
Shell scripting tetap lapisan lem praktis dalam workflow container dan cloud karena banyak alat mengekspos CLI terlebih dahulu. Bahkan ketika infrastruktur Anda didefinisikan di tempat lain, Anda masih membutuhkan otomasi kecil dan andal untuk meluncurkan, memvalidasi, mengumpulkan, dan memulihkan.
Tempat umum Anda masih melihat shell adalah entrypoint container. Skrip kecil dapat:
Kuncinya adalah menjaga skrip entrypoint pendek dan prediktif—lakukan setup, lalu exec proses utama agar sinyal dan kode keluar berperilaku benar.
Pekerjaan Kubernetes sehari-hari sering mendapat manfaat dari helper ringan: wrapper kubectl yang memastikan Anda berada di context/namespace yang benar, mengumpulkan log dari banyak pod, atau mengambil event terbaru selama insiden.
Misalnya, skrip dapat menolak dijalankan jika Anda sedang mengarah ke production, atau otomatis menggabungkan log ke satu artefak untuk tiket.
CLI AWS/Azure/GCP ideal untuk tugas batch: memberi tag resource, merotasi rahasia, mengekspor inventaris, atau mematikan environment non-prod di malam hari. Shell sering kali cara tercepat untuk merangkai aksi-aksi ini menjadi perintah yang dapat diulang.
Dua titik kegagalan umum adalah parsing yang rapuh dan API yang tidak andal. Lebih suka output terstruktur bila memungkinkan:
--output json) dan parse dengan jq daripada menggrep tabel berformat manusiawi.Pergeseran kecil—JSON + jq, plus logika retry dasar—mengubah skrip yang “jalan di laptop saya” menjadi otomatisasi andal yang bisa dijalankan berulang kali.
Ketika sesuatu rusak, biasanya Anda tidak perlu toolchain baru—Anda butuh jawaban dalam menit. Shell sempurna untuk respon insiden karena sudah ada di host, cepat dijalankan, dan bisa menggabungkan perintah kecil dan andal menjadi gambaran jelas tentang apa yang terjadi.
Saat outage, sering Anda memvalidasi beberapa hal dasar:
df -h, df -i)free -m, vmstat 1 5, uptime)ss -lntp, ps aux | grep ...)getent hosts name, dig +short name)curl -fsS -m 2 -w '%{http_code} %{time_total}\n' URL)Skrip shell bersinar di sini karena Anda dapat menstandarkan pengecekan ini, menjalankannya konsisten di banyak host, dan menempelkan hasilnya ke channel insiden tanpa format manual.
Skrip insiden yang baik mengumpulkan snapshot: cap waktu, hostname, versi kernel, log terbaru, koneksi saat ini, dan penggunaan sumber daya. Bundel "state" itu membantu analisis akar masalah setelah api padam.
#!/usr/bin/env bash
set -euo pipefail
out="incident_$(hostname)_$(date -u +%Y%m%dT%H%M%SZ).log"
{
date -u
hostname
uname -a
df -h
free -m
ss -lntp
journalctl -n 200 --no-pager 2>/dev/null || true
} | tee "$out"
Otomasi insiden sebaiknya bersifat read-only terlebih dahulu. Perlakukan aksi “memperbaiki” sebagai eksplisit, dengan konfirmasi (atau flag --yes) dan keluaran yang jelas tentang apa yang akan berubah. Dengan begitu, skrip membantu responder bekerja lebih cepat—tanpa membuat insiden kedua.
Portabilitas penting kapan pun otomasi Anda berjalan di “apa pun yang runner sediakan”: container minimal (Alpine/BusyBox), distro Linux berbeda, image CI, atau laptop developer (macOS). Sumber utama masalah adalah mengasumsikan setiap mesin memiliki shell yang sama.
POSIX sh adalah denominasi terendah: variabel dasar, case, for, if, pipeline, dan fungsi sederhana. Pilih ini ketika Anda ingin skrip berjalan hampir di mana saja.
Bash adalah shell kaya fitur dengan kenyamanan seperti array, [[ ... ]] tests, process substitution (<(...)), set -o pipefail, extended globbing, dan penanganan string yang lebih baik. Fitur-fitur itu mempercepat otomasi DevOps—tetapi bisa rusak di sistem di mana /bin/sh bukan Bash.
sh untuk portabilitas maksimum (Alpine’s ash, Debian dash, BusyBox).Di macOS, pengguna mungkin punya Bash 3.2 secara default, sementara image Linux CI mungkin Bash 5.x—jadi bahkan “skrip Bash” bisa terkena perbedaan versi.
Bashisms umum termasuk [[ ... ]], array, source (gunakan .), dan perilaku echo -e yang berbeda. Jika maksud Anda POSIX, tulis dan uji dengan shell POSIX nyata (mis., dash atau BusyBox sh).
Gunakan shebang yang sesuai niat Anda:
#!/bin/sh
atau:
#!/usr/bin/env bash
Lalu dokumentasikan persyaratan di repo (mis., "membutuhkan Bash ≥ 4.0") agar CI, container, dan rekan tim tetap selaras.
Jalankan shellcheck di CI untuk menandai bashisms, kesalahan quoting, dan pola tidak aman. Ini salah satu cara tercepat untuk mencegah kegagalan "jalan di mesin saya".
Dalam konteks DevOps, skrip shell biasanya adalah glue code: program kecil yang merangkai alat yang sudah ada (utilitas Linux, CLI cloud, langkah CI) menggunakan pipe, kode keluar, dan variabel lingkungan.
Ini paling cocok ketika Anda butuh otomatisasi cepat tanpa banyak dependensi pada server atau runner yang sudah memiliki shell.
Gunakan POSIX sh ketika skrip harus berjalan di berbagai lingkungan (BusyBox/Alpine, container minimal, runner CI yang tidak ditentukan).
Gunakan Bash ketika Anda mengendalikan runtime (image CI Anda, host operasi) atau membutuhkan fitur Bash seperti [[ ... ]], array, pipefail, atau proses substitution.
Tetapkan interpreter lewat shebang (mis., #!/bin/sh atau #!/usr/bin/env bash) dan dokumentasikan versi yang dibutuhkan.
Karena sudah tersedia: sebagian besar image Linux menyertakan shell dan utilitas inti (grep, sed, awk, tar, curl, systemctl).
Itu membuat shell ideal untuk:
Alat IaC/konfigurasi biasanya menjadi system of record (keadaan yang diinginkan, perubahan yang dapat direview, apply yang dapat diulang). Skrip shell paling baik sebagai wrapper yang menambahkan orkestrasi dan guardrail.
Contoh ketika shell melengkapi IaC:
plan/applyBuat mereka dapat diprediksi dan aman:
set +x di sekitar perintah sensitifjq daripada menggrep tabelJika suatu langkah tidak stabil (jaringan/API), tambahkan retry dengan backoff dan kegagalan keras bila habis.
Jaga entrypoint kecil dan deterministik:
exec proses utama agar sinyal dan kode keluar terlambatHindari proses background jangka panjang di entrypoint kecuali Anda memiliki strategi supervisi yang jelas; kalau tidak, shutdown dan restart bisa menjadi tidak dapat diandalkan.
Kesalahan umum:
/bin/sh bisa saja dash (Debian/Ubuntu) atau BusyBox sh (Alpine), bukan Bashecho -e, sed -i, dan sintaks test bervariasi antar platformGaris dasar yang kuat adalah:
set -euo pipefail
Kemudian tambahkan kebiasaan ini:
Untuk diagnostik cepat dan konsisten, standarkan seperangkat perintah kecil dan ambil output dengan cap waktu.
Pemeriksaan tipikal meliputi:
Dua alat menutupi kebutuhan sebagian besar tim:
Tambahkan pengujian ringan:
Jika portabilitas penting, uji dengan shell target (mis., dash/BusyBox) dan jalankan ShellCheck di CI untuk menangkap "bashisms" lebih awal.
"$var" (mencegah word-splitting/globbing)eval dan pembuatan perintah dari string-- untuk mengakhiri parsing opsi (mis., rm -- "$file")mktemp + trap untuk file sementara yang aman dan pembersihanBerhati-hatilah dengan set -e: tangani kegagalan yang diharapkan secara eksplisit (cmd || true atau pemeriksaan yang sesuai).
df -h, df -iuptime, free -m, vmstat 1 5ss -lntpjournalctl -n 200 --no-pagercurl -fsS -m 2 URLLebih baik gunakan skrip “read-only” terlebih dahulu, dan buat setiap aksi tulis/perbaikan menjadi eksplisit (prompt atau --yes).
--dry-run)bats jika Anda mau assertion pada kode keluar, output, dan perubahan fileSimpan skrip di lokasi yang dapat diprediksi (mis., scripts/ atau ops/) dan sertakan blok --help minimal.