Bayangkan Anda harus membuat 50 virtual machine (VM) sekaligus di cloud, dan masing-masing butuh user baru, SSH key berbeda, hostname unik, serta paket software tertentu yang sudah terpasang sejak detik pertama VM itu menyala. Jika dikerjakan manual satu per satu, ini bisa memakan waktu berjam-jam dan rawan human error. Di sinilah cloud-init berperan sebagai jembatan antara image generik dan VM yang siap pakai.

Cloud-init adalah standar industri untuk inisialisasi instance cloud. Alih-alih membuat image khusus untuk setiap kebutuhan, satu image Ubuntu atau Debian cloud yang sama bisa “disulap” menjadi web server, database node, atau bastion host—cukup dengan data konfigurasi yang berbeda saat boot pertama. Bagi sysadmin, DevOps engineer, maupun pengguna homelab yang sering bermain dengan KVM/QEMU, Proxmox, atau LXD, memahami cloud-init adalah keterampilan wajib.

Artikel ini akan membahas tuntas bagaimana cloud-init bekerja di balik layar, bagaimana ia menyuntikkan user dan SSH key, tahapan boot yang dilaluinya, hingga contoh konfigurasi praktis yang bisa langsung Anda coba.

Apa Itu Cloud-Init?

Cloud-init adalah service yang berjalan otomatis saat instance cloud pertama kali di-boot. Tugas utamanya adalah membaca metadata dan user data yang disediakan oleh platform cloud atau hypervisor, lalu menerjemahkannya menjadi konfigurasi nyata di dalam sistem—membuat user, menambahkan SSH key, mengatur hostname, menjalankan skrip, hingga menginstal paket.

Hampir semua image cloud resmi dari Ubuntu, Debian, CentOS, hingga distribusi lain sudah menyertakan cloud-init secara default. Artinya, saat Anda men-deploy VM di AWS, GCP, Azure, OpenStack, atau bahkan lokal via NoCloud/QEMU, cloud-init sudah siap bekerja tanpa instalasi tambahan.

Analogi Sederhana

Anggap saja image VM Anda seperti sebuah rumah kosong yang sudah jadi (dinding, atap, listrik sudah terpasang). Cloud-init berperan seperti tim dekorasi yang datang begitu kunci rumah diserahkan: mereka membaca “daftar belanja” (user-data) berisi perabot apa yang harus dipasang, kunci pintu siapa saja yang boleh masuk (SSH key), dan nama rumah tersebut (hostname). Semua dilakukan otomatis, sekali saat serah terima pertama—bukan setiap kali penghuni pulang ke rumah.

Bagaimana Cloud-Init Bekerja: Tahapan Boot

Cloud-init tidak berjalan sebagai satu proses tunggal, melainkan melalui beberapa tahap (stage) yang berurutan selama proses boot:

• Generator — Mendeteksi apakah sistem sedang berjalan di lingkungan cloud/virtual sebelum service cloud-init benar-benar diaktifkan.
• Local Stage — Mencari datasource lokal dan mengambil konfigurasi jaringan awal.
• Network Stage — Mengaktifkan konfigurasi jaringan sesuai data yang ditemukan, sehingga koneksi ke datasource remote (jika ada) bisa dilakukan.
• Config Stage — Menjalankan modul-modul konfigurasi seperti pembuatan user, penulisan file, hingga pengaturan sistem lain.
• Final Stage — Menjalankan modul yang bergantung pada sistem yang sudah sepenuhnya siap, seperti instalasi paket dan eksekusi skrip kustom (runcmd).

Setiap tahap ini dijalankan oleh service systemd terpisah, sehingga cloud-init bisa terintegrasi rapi dengan urutan boot Linux modern.

Sumber Data: Datasource pada Cloud-Init

Cloud-init perlu tahu dari mana ia mengambil konfigurasi. Sumber ini disebut datasource, dan cloud-init mendukung banyak platform sekaligus, di antaranya:

• NoCloud — untuk deployment lokal tanpa cloud provider (KVM, QEMU, VirtualBox).
• Amazon EC2
• OpenStack
• Google Compute Engine (GCE)
• Microsoft Azure
• Dan puluhan datasource lain sesuai platform cloud yang digunakan.

Pada skenario lokal (misalnya lab dengan QEMU/KVM), datasource yang paling umum dipakai adalah NoCloud. Datasource ini membaca dua file utama: user-data dan meta-data, yang disisipkan melalui disk virtual (ISO atau image vfat) dengan volume label cidata atau CIDATA.

File Konfigurasi Utama Cloud-Init

Ada empat jenis “berkas data” yang perlu dipahami:

1. meta-data — Berisi informasi identitas instance seperti instance-id dan local-hostname. File ini yang menjadi penanda “first boot”: jika instance-id sama dengan sebelumnya, cloud-init menganggap konfigurasi sudah pernah dijalankan dan tidak mengulanginya lagi.
2. user-data — Berkas utama tempat Anda mendefinisikan konfigurasi kustom: user baru, SSH key, paket yang diinstal, perintah yang dijalankan, dan sebagainya. Biasanya ditulis dalam format #cloud-config (YAML).
3. network-config — Opsional, untuk mengatur konfigurasi jaringan statis atau custom di luar default DHCP.
4. vendor-data — Opsional, biasanya disediakan oleh penyedia cloud/hypervisor untuk konfigurasi tambahan dari sisi vendor.

Materi Praktis: Menyuntikkan User dan SSH Key

Berikut contoh konfigurasi user-data yang umum dipakai untuk membuat user baru dengan akses sudo tanpa password dan SSH key sudah terpasang sejak boot pertama:

#cloud-config
hostname: server-app-01
manage_etc_hosts: true
locale: en_US.UTF-8

users:
  - name: deploy
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: true
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... user@laptop

package_update: true
package_upgrade: true

packages:
  - curl
  - git
  - htop

runcmd:
  - echo "Provisioning selesai" >> /var/log/provision.log

Dari contoh di atas, cloud-init akan otomatis:

• Mengatur hostname menjadi server-app-01
• Membuat user deploy dengan akses sudo penuh tanpa password
• Menambahkan SSH public key sehingga login langsung bisa via SSH tanpa password
• Melakukan update paket sistem
• Menginstal curl, git, dan htop
• Menjalankan perintah kustom lewat runcmd

Tutorial Step-by-Step: Uji Coba Cloud-Init dengan QEMU/KVM Lokal

Berikut langkah praktis menguji cloud-init di lingkungan lokal menggunakan datasource NoCloud.

Langkah 1 — Unduh Image Cloud Ubuntu atau Debian

Ambil image cloud resmi (bukan image installer biasa), misalnya Ubuntu Cloud Image atau Debian Generic Cloud Image, karena image inilah yang sudah menyertakan paket cloud-init.

Langkah 2 — Siapkan File user-data dan meta-data

Buat dua file teks sederhana:

cat > meta-data <<EOF
instance-id: iid-local01
local-hostname: cloudtest
EOF

cat > user-data <<EOF
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
EOF

Langkah 3 — Buat Seed Image (ISO Konfigurasi)

Gunakan cloud-localds (dari paket cloud-image-utils) untuk mengemas kedua file tersebut menjadi ISO:

sudo apt install cloud-image-utils
cloud-localds seed.iso user-data meta-data

Langkah 4 — Salin Image agar Tidak Merusak File Asli

qemu-img create -f qcow2 -b disk.img -F qcow2 boot-disk.img

Langkah 5 — Boot VM dengan Kedua Disk

Jalankan QEMU/KVM dengan menyertakan boot-disk.img sebagai disk utama dan seed.iso sebagai disk kedua (CD-ROM). Saat boot pertama berjalan, cloud-init otomatis mendeteksi datasource NoCloud dari label cidata pada ISO tersebut dan menerapkan seluruh konfigurasi di dalamnya.

Langkah 6 — Verifikasi Hasil Konfigurasi

Login ke VM (via console atau SSH), lalu cek status cloud-init:

cloud-init status --long

Cek juga log detail untuk memastikan tidak ada modul yang gagal:

cat /var/log/cloud-init-output.log
cat /var/log/cloud-init.log

Kesalahan yang Sering Terjadi

1. Konfigurasi tidak berjalan ulang setelah diubah

• Penyebab: instance-id pada meta-data tidak diubah, sehingga cloud-init menganggap ini bukan boot pertama.
• Dampak: Perubahan pada user-data diabaikan sepenuhnya.
• Solusi: Ubah instance-id, atau jalankan cloud-init clean sebelum reboot untuk mereset status cloud-init.

2. File YAML tidak valid

• Penyebab: Indentasi YAML salah, atau lupa menambahkan header #cloud-config di baris pertama.
• Dampak: Modul cloud-init gagal parsing dan konfigurasi tidak diterapkan sama sekali.
• Solusi: Validasi YAML dengan cloud-init devel schema --config-file user-data sebelum digunakan.

3. Volume label ISO salah

• Penyebab: Seed image tidak diberi label cidata/CIDATA sesuai ketentuan datasource NoCloud.
• Dampak: Cloud-init tidak menemukan datasource sama sekali, sehingga tidak ada konfigurasi yang jalan.
• Solusi: Pastikan menggunakan tool seperti cloud-localds yang otomatis mengatur label dengan benar.

4. SSH key tidak terpasang

• Penyebab: Format ssh_authorized_keys salah, atau key ditulis sebagai satu baris tanpa list YAML yang benar.
• Dampak: Login SSH berbasis key gagal walau user berhasil dibuat.
• Solusi: Gunakan format list YAML yang benar dan cek ulang dengan cat ~/.ssh/authorized_keys pada user tujuan.

Tips dan Rekomendasi

• Selalu gunakan image cloud resmi, bukan image instalasi desktop biasa, karena cloud-init sudah terpasang dan dikonfigurasi sejak awal.
• Simpan template user-data dalam version control (Git) agar mudah diaudit dan digunakan ulang.
• Gunakan modul write_files untuk menyisipkan file konfigurasi tambahan (misalnya konfigurasi Nginx) langsung saat first boot.
• Manfaatkan runcmd untuk automasi lanjutan seperti clone repository atau menjalankan script provisioning eksternal.
• Untuk lingkungan produksi skala besar, kombinasikan cloud-init dengan tool orkestrasi seperti Terraform atau Ansible agar alur provisioning tetap konsisten dan terdokumentasi.

Kesimpulan

Cloud-init adalah fondasi otomatisasi provisioning VM modern. Dengan memahami konsep datasource, struktur user-data/meta-data, serta tahapan boot yang dilaluinya, Anda bisa membangun infrastruktur cloud maupun on-premise yang konsisten, cepat, dan minim kesalahan manual. Poin penting yang perlu diingat:

• Cloud-init berjalan lewat tahapan Generator, Local, Network, Config, dan Final.
• Konfigurasi utama ditulis di user-data, sedangkan identitas instance ada di meta-data.
• instance-id menentukan apakah cloud-init menganggap ini first boot atau bukan.
• Selalu verifikasi hasil lewat cloud-init status dan file log terkait.

Menguasai cloud-init membuka jalan menuju infrastruktur yang benar-benar immutable dan mudah direplikasi—satu langkah penting menuju praktik DevOps yang matang.

Sudah pernah mencoba cloud-init di server atau homelab Anda? Ceritakan pengalaman atau kendala yang Anda temui di kolom komentar!

Jangan lupa bagikan artikel ini ke rekan sysadmin/DevOps Anda, dan ikuti terus konten seputar Linux, Networking, dan Infrastruktur IT lainnya di blog ini.

---

Frequently Asked Questions (FAQ)

Pertanyaan: Apa itu cloud-init? Jawaban: Cloud-init adalah service yang membaca metadata dan user-data untuk mengonfigurasi VM secara otomatis saat pertama kali boot, seperti membuat user, memasang SSH key, dan menjalankan skrip provisioning.

Pertanyaan: Apakah cloud-init hanya bekerja di cloud provider seperti AWS atau GCP? Jawaban: Tidak. Cloud-init juga mendukung penggunaan lokal lewat datasource NoCloud, sehingga bisa dipakai di KVM/QEMU, VirtualBox, LXD, atau Proxmox tanpa terhubung ke cloud provider mana pun.

Pertanyaan: Bagaimana cloud-init tahu bahwa VM sedang boot pertama kali? Jawaban: Cloud-init menggunakan nilai instance-id pada file meta-data sebagai penanda unik. Jika nilai ini sama dengan sebelumnya, cloud-init tidak akan menjalankan ulang konfigurasi.

Pertanyaan: Apakah cloud-init bisa menginstal paket software secara otomatis? Jawaban: Bisa. Melalui direktif packages, package_update, dan package_upgrade pada user-data, cloud-init dapat menginstal serta memperbarui paket sistem saat first boot.

Pertanyaan: Di mana saya bisa melihat log jika konfigurasi cloud-init gagal? Jawaban: Cek file /var/log/cloud-init.log untuk log proses detail, dan /var/log/cloud-init-output.log untuk output dari setiap modul serta skrip yang dijalankan.

Pertanyaan: Apa bedanya user-data dan meta-data? Jawaban: meta-data berisi identitas instance seperti instance-id dan hostname, sedangkan user-data berisi konfigurasi kustom yang ingin Anda terapkan, seperti user, SSH key, paket, dan perintah.

---

Kalau artikel ini membantu Anda memahami cloud-init lebih dalam, yuk tinggalkan komentar dan diskusikan pengalaman provisioning VM Anda!

Bagikan artikel ini ke tim atau komunitas sysadmin/DevOps Anda, dan jangan lewatkan artikel-artikel lain seputar Linux, Networking, MikroTik, Cisco, dan Cloud Computing di blog ini. Ikuti terus update konten terbaru agar tidak ketinggalan tips dan tutorial praktis lainnya!