Cloud-init: Otomasi Provisioning

Bab 36 ditutup dengan catatan penting bahwa Ansible unggul untuk mengonfigurasi server yang sudah menyala dan dapat dijangkau lewat SSH, tetapi ada satu celah yang belum tersentuh sama sekali, yaitu bagaimana server itu pertama kali disiapkan sebelum Ansible sempat login. Setiap kali kita membuat VM baru lewat virt-install di Bab 28, langkah setelah instalasi selalu berulang, yaitu membuat user, menyalin SSH key, lalu memasang beberapa paket dasar secara manual sebelum server benar-benar siap dipakai. Proses ini masih terasa wajar untuk satu atau dua VM percobaan, tetapi berubah menjadi beban nyata begitu kita perlu menyiapkan puluhan instance sekaligus, apalagi di lingkungan cloud yang VM-nya dapat dibuat dan dihapus dalam hitungan menit. Cloud-init menjawab celah ini dengan mengotomasi seluruh proses provisioning awal tersebut, langsung sejak detik pertama VM menyala, tanpa perlu satu pun sentuhan manual maupun koneksi SSH dari luar.

Skenario ini paling terasa bagi Sysadmin yang bekerja di lingkungan cloud atau yang rutin membuat VM baru untuk kebutuhan testing dan staging. Developer meminta lima VM identik untuk menguji aplikasi versi baru sebelum rilis, lengkap dengan user akses masing-masing dan beberapa paket pendukung sudah terpasang sejak awal. Tanpa cloud-init, permintaan ini berarti lima kali proses instalasi manual yang sama persis. Cloud-init membuat kelima VM tersebut lahir dari satu cloud image yang sama, hanya dibedakan oleh satu file konfigurasi kecil yang disuntikkan saat boot pertama, sehingga image dasarnya sendiri tidak pernah perlu diubah maupun dipasangi paket satu per satu secara manual.

Bab ini dimulai dari konsep cloud-init dan datasource, dilanjutkan dengan struktur file user-data yang menjadi inti konfigurasinya, lalu mempraktikkan provisioning penuh, membuat user, menanam SSH key, dan memasang paket awal, pada VM KVM yang sudah kita kuasai sejak Bab 28. Bab ditutup dengan gambaran penggunaan cloud-init di luar lingkungan lokal, termasuk kaitannya dengan cloud provider sungguhan yang akan dipraktikkan lebih detail di Bab 41.

37.1 Konsep Cloud-init dan Use Case-nya

37.1.1 Apa Itu Cloud-init dan Datasource

Cloud-init adalah tool open source yang menjadi standar de facto untuk inisialisasi instance lintas platform, dijalankan dari dalam sistem operasi guest itu sendiri pada saat boot pertama kali. Berbeda dari Ansible pada Bab 36 yang bekerja dari luar lewat SSH terhadap server yang sudah hidup dan dapat dijangkau, cloud-init justru bekerja dari dalam, sebagai bagian dari proses boot VM, jauh sebelum service SSH sempat menerima koneksi dari luar. Hampir seluruh cloud image resmi Ubuntu, termasuk yang dipakai AWS, Azure, GCP, dan OpenStack, sudah menyertakan cloud-init terpasang dan siap jalan sejak awal, menjadikannya jembatan universal antara image generik dan konfigurasi spesifik yang dibutuhkan setiap instance.

Supaya bisa bekerja di berbagai platform yang berbeda-beda, cloud-init memakai konsep datasource, yaitu mekanisme yang dipakai cloud-init untuk mengenali lingkungan tempatnya berjalan sekaligus menemukan sumber data konfigurasinya. Proses deteksi ini dijalankan secara otomatis oleh komponen internal bernama ds-identify pada tahap paling awal boot. Setelah datasource ditemukan, cloud-init biasanya menerima data dalam bentuk dua berkas: user-data yang berisi definisi konfigurasi instance secara lengkap, dan meta-data yang berisi informasi spesifik instance seperti instance-id dan hostname, umumnya disediakan otomatis oleh platform yang bersangkutan. Bab ini memakai datasource bernama NoCloud, yang memungkinkan kita menyuntikkan user-data dan meta-data secara manual lewat media lokal berlabel cidata, sesuai untuk lingkungan KVM lokal yang memang tidak memiliki metadata service seperti layaknya cloud sungguhan.

37.1.2 Use Case: Kapan Cloud-init Layak Digunakan

Cloud-init paling terasa manfaatnya pada beberapa skenario berikut, yang umum ditemui Sysadmin di lapangan.

• Peluncuran instance massal yang identik di cloud provider, misalnya menyalakan sepuluh VM sekaligus untuk autoscaling group di belakang load balancer yang sudah dibahas konsepnya di Bab 16, tanpa perlu login satu per satu ke tiap instance untuk konfigurasi awal.
• Konsep golden image, yaitu satu cloud image dasar yang sudah diuji dan divalidasi, lalu dipakai berulang untuk berbagai kebutuhan berbeda hanya dengan mengganti isi user-data, tanpa perlu membuat image terpisah untuk setiap variasi konfigurasi.
• Menyiapkan lingkungan testing dan staging yang perlu dibuat ulang dari nol secara cepat dan konsisten, sesuatu yang jauh lebih repetitif dan rawan kesalahan jika dikerjakan manual lewat console seperti Bagian 28.3.3.
• Menjadi jembatan menuju Ansible pada Bab 36. Cloud-init menyiapkan fondasi paling dasar seperti user dan akses SSH, lalu begitu instance sudah dapat dijangkau, Ansible mengambil alih untuk konfigurasi lanjutan dan perubahan berkelanjutan yang bukan lagi ranah cloud-init.

Poin terakhir ini penting untuk digarisbawahi. Cloud-init dirancang untuk provisioning saat boot pertama, bukan sebagai pengganti tool configuration management untuk perubahan rutin sehari-hari. Menjalankan ulang seluruh siklus cloud-init pada instance yang sudah lama berjalan bukan pola pakai yang wajar, berbeda dari playbook Ansible yang justru didesain untuk dijalankan berulang kali sepanjang umur server.

37.1.3 Tahapan Boot Cloud-init dan Statusnya di Server yang Sudah Terpasang

Cloud-init tidak berjalan sebagai satu proses tunggal, melainkan terbagi ke dalam beberapa tahap boot yang berurutan, masing-masing dipetakan ke unit systemd tersendiri.

Langkah Praktik

1. Periksa status cloud-init di server yang sudah kita install manual sejak Bab 2.

   cloud-init status --long

Verifikasi dan Troubleshooting

• Server yang diinstal interaktif lewat Subiquity sejak Bab 2 kemungkinan besar menampilkan status disabled, bukan done. Ini bukan tanda kerusakan. ds-identify tidak menemukan datasource yang valid pada instalasi manual semacam ini, lalu menuliskan penanda /etc/cloud/cloud-init.disabled yang membuat seluruh unit di atas tidak dijalankan pada boot berikutnya. Perilaku ini justru menegaskan bahwa cloud-init memang ditujukan untuk lingkungan yang menyediakan datasource sungguhan, seperti yang akan kita bangun sendiri pada Bagian 37.3.
• Pada instance yang datasource-nya terdeteksi dengan benar, status sehat menampilkan status: done disertai rincian waktu tempuh tiap tahap. Perintah cloud-init analyze blame berguna untuk melihat modul mana yang paling lama dieksekusi jika proses boot terasa lambat.

37.2 Struktur File user-data

37.2.1 Format #cloud-config dan Peran Setiap Bagian

File user-data mendukung beberapa format konten, tetapi format yang paling umum dan direkomendasikan untuk kebutuhan sehari-hari adalah cloud-config, ditulis dalam sintaks YAML dan wajib diawali baris literal #cloud-config di baris pertama. Baris ini bukan sekadar komentar YAML biasa, melainkan penanda wajib yang dibaca cloud-init untuk mengenali jenis konten file sebelum memprosesnya; tanpa baris ini, cloud-init akan mengabaikan seluruh isi file meskipun sintaks YAML di dalamnya valid.

Beberapa key level atas yang paling sering dipakai dan akan langsung dipraktikkan pada Bagian 37.3 adalah users untuk mendefinisikan akun beserta ssh_authorized_keys-nya, package_update dan package_upgrade untuk memperbarui daftar paket dan sistem sebelum instalasi, packages untuk daftar paket yang dipasang, serta runcmd untuk menjalankan perintah shell kustom pada tahap Final. Satu detail yang mudah terlewat namun penting adalah nilai instance-id di meta-data. Cloud-init menyimpan riwayat instance-id yang pernah diproses, dan modul-modul yang sifatnya sekali jalan tidak akan dijalankan ulang jika instance-id-nya sama dengan yang sudah pernah tercatat sebelumnya, sebuah jebakan umum saat mengkloning disk VM tanpa mengganti instance-id-nya.

37.2.2 Menulis dan Memvalidasi user-data Minimal

Langkah Praktik

1. Buat direktori kerja percobaan di host KVM yang sama dengan Bab 28, untuk memahami strukturnya lebih dulu sebelum menulis konfigurasi lengkap.

   mkdir -p ~/cloud-init-lab
   cd ~/cloud-init-lab

2. Buat file user-data percobaan dengan konfigurasi paling minimal.

   nano user-data

3. Isi dengan dua baris berikut.

   #cloud-config
   hostname: cloud-init-test

4. Validasi sintaks dan skema file tersebut tanpa perlu membuat VM sama sekali.

   cloud-init schema --config-file user-data --annotate

Verifikasi dan Troubleshooting

• Output sehat menampilkan Valid schema user-data:user-data. Jika baris #cloud-config sengaja dihapus untuk percobaan, perintah yang sama akan menolak file tersebut karena tidak mengenali jenis kontennya.
• cloud-init schema hanya memvalidasi struktur dan nama key terhadap skema resmi setiap modul, bukan menjamin isinya benar secara logis. Salah ketik nama paket pada key packages, misalnya, tetap lolos validasi skema karena secara struktur sudah valid, dan baru akan ketahuan gagal saat benar-benar dieksekusi apt di dalam VM.
• Error umum seperti mapping values are not allowed in this context mengindikasikan masalah indentasi YAML, persis seperti yang sudah dibahas saat menulis playbook Ansible di Bagian 36.3.3.

37.3 Provisioning Otomatis: User, SSH Key, dan Paket Awal

Bagian ini mempraktikkan skenario penuh, dari cloud image polos hingga VM yang sudah punya user sysadmin, akses SSH key-based, dan paket nginx terpasang, seluruhnya tanpa satu kali pun menyentuh console VM secara manual. Kita tetap memakai stack KVM/QEMU/libvirt yang sudah dipasang di Bagian 28.2, tetapi kali ini boot langsung dari cloud image, bukan dari ISO installer Subiquity seperti vm-app01 pada Bagian 28.3.

37.3.1 Menyiapkan Cloud Image dan Disk VM

Ubuntu menyediakan cloud image resmi, yaitu image dasar yang sudah terpasang sistem operasi lengkap dengan cloud-init aktif di dalamnya, siap dipakai langsung tanpa proses instalasi Subiquity sama sekali.

Langkah Praktik

1. Unduh cloud image Ubuntu Server 26.04 LTS ke storage pool yang sama dengan Bagian 28.3.1.

   cd /var/lib/libvirt/images
   sudo wget https://cloud-images.ubuntu.com/releases/26.04/release/ubuntu-26.04-server-cloudimg-amd64.img

2. Buat direktori terpisah untuk menyimpan file user-data dan meta-data, terpisah dari file disk VM.

   sudo mkdir -p /var/lib/libvirt/images/cloud-init

3. Buat disk VM baru dalam format copy-on-write, memakai cloud image yang baru diunduh sebagai backing file, lalu perbesar kapasitasnya menjadi 10 GB.

   sudo qemu-img create -f qcow2 -F qcow2 \
     -b /var/lib/libvirt/images/ubuntu-26.04-server-cloudimg-amd64.img \
     /var/lib/libvirt/images/vm-cloudinit01.qcow2 10G

Verifikasi dan Troubleshooting

• Konfirmasikan disk baru benar-benar tertaut ke backing file dan sudah membesar sesuai perintah.

  qemu-img info /var/lib/libvirt/images/vm-cloudinit01.qcow2

  Baris backing file semestinya menunjuk ke cloud image asli, sementara virtual size menampilkan 10 GiB meski ukuran file sesungguhnya di disk host (disk size) masih jauh lebih kecil, karena format qcow2 hanya mengalokasikan blok yang benar-benar dipakai.
• Pendekatan backing file ini menghindari duplikasi penuh cloud image setiap kali membuat VM baru. Cloud image asli tetap utuh sebagai referensi bersama, sementara setiap VM hanya menyimpan perubahan (delta) miliknya sendiri di file qcow2 masing-masing, jauh lebih hemat storage dibanding menyalin penuh setiap kali seperti pola cp biasa.
• Cloud image bawaan sengaja dibuat berukuran kecil (umumnya di bawah 3 GB), dan mengandalkan modul growpart serta resizefs di dalam cloud-init untuk memperbesar partisi dan filesystem root secara otomatis pada boot pertama, mengikuti kapasitas 10 GB yang baru saja kita tentukan lewat qemu-img create. Kedua modul ini sudah aktif secara default di cloud image resmi Ubuntu, jadi tidak perlu dikonfigurasi manual di user-data.

37.3.2 Menulis user-data Lengkap untuk Provisioning

Langkah Praktik

1. Buat file meta-data berisi identitas instance.

   sudo nano /var/lib/libvirt/images/cloud-init/meta-data

2. Isi dengan instance-id dan hostname.

   instance-id: vm-cloudinit01
   local-hostname: vm-cloudinit01

3. Buat file user-data utama.

   sudo nano /var/lib/libvirt/images/cloud-init/user-data

4. Isi dengan definisi user, SSH key, dan paket awal. Ganti isi ssh_authorized_keys dengan isi sesungguhnya dari ~/.ssh/id_ed25519.pub milik kita sendiri yang sudah dibuat sejak Bagian 3.2.1, bukan contoh di bawah ini.

   #cloud-config
   users:
     - name: sysadmin
       groups: sudo
       shell: /bin/bash
       sudo: ALL=(ALL) NOPASSWD:ALL
       lock_passwd: true
       ssh_authorized_keys:
         - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGXampleKeyMaterialGantiDenganPublicKeyAsli
   
   package_update: true
   package_upgrade: true
   packages:
     - nginx
     - curl
   
   runcmd:
     - [ sh, -c, "echo Provisioned via cloud-init on $(date) > /var/www/html/provisioned.txt" ]

   Bagian users membuat satu akun bernama sysadmin, masuk ke group sudo, dengan baris sudo yang setara entri di /etc/sudoers.d/ pada Bagian 4.2.1, memberi akses sudo tanpa password. Key lock_passwd: true sebenarnya sudah jadi default cloud-init untuk user baru, ditulis eksplisit di sini semata agar terlihat jelas bahwa login lewat password memang sengaja dimatikan total dan satu-satunya jalur masuk adalah SSH key, sejalan dengan prinsip hardening pada Bab 30. Key package_update dan package_upgrade setara apt update dan apt upgrade, dijalankan sebelum packages memasang nginx dan curl. Terakhir, runcmd dieksekusi pada tahap Final dan di sini dipakai untuk menulis file penanda yang nanti dicek lewat curl, bukti nyata bahwa seluruh rangkaian provisioning benar-benar berjalan sampai akhir.

Verifikasi dan Troubleshooting

• Validasi ulang sebelum benar-benar dipakai untuk boot VM.

  cloud-init schema --config-file /var/lib/libvirt/images/cloud-init/user-data --annotate

• Karena key users di atas dituliskan sendiri tanpa menyertakan kata default di dalam daftarnya, cloud-init tidak lagi membuat user bawaan cloud image (biasanya bernama ubuntu) sama sekali. Hanya user sysadmin yang akan ada di VM hasil provisioning, sebuah perilaku yang disengaja di sini, tetapi kerap jadi kejutan bagi yang baru pertama kali menulis user-data sendiri dan mengira user ubuntu bawaan tetap akan ada.
• Pastikan baris ssh-ed25519 ... pada ssh_authorized_keys ditulis utuh dalam satu baris tanpa terpotong. Kesalahan copy-paste yang memecah public key jadi dua baris adalah penyebab paling umum kegagalan login SSH pada Bagian 37.3.4 nanti.

37.3.3 Boot VM dengan virt-install dan Seed Cloud-init

Flag --cloud-init pada virt-install otomatis membungkus user-data dan meta-data menjadi media seed berlabel cidata sesuai spesifikasi datasource NoCloud, lalu melekatkannya ke VM sebagai CD-ROM virtual, persis seperti yang dilakukan tool cloud-localds dari paket cloud-image-utils secara manual. Kita memakai jalur otomatis ini karena sudah memakai virt-install, tetapi tool cloud-localds tetap relevan dipelajari untuk kombinasi QEMU polos atau hypervisor lain yang tidak menyediakan flag setara.

Langkah Praktik

1. Jalankan virt-install dengan disk yang sudah disiapkan di Bagian 37.3.1, memakai --import agar langsung boot dari disk berisi OS tanpa melalui installer sama sekali.

   virt-install \
     --name vm-cloudinit01 \
     --memory 2048 \
     --vcpus 2 \
     --disk path=/var/lib/libvirt/images/vm-cloudinit01.qcow2,bus=virtio \
     --os-variant detect=on,require=off \
     --network network=default,model=virtio \
     --graphics none \
     --import \
     --cloud-init user-data=/var/lib/libvirt/images/cloud-init/user-data,meta-data=/var/lib/libvirt/images/cloud-init/meta-data

2. Tunggu beberapa saat hingga proses boot dan provisioning berjalan, lalu periksa alamat IP yang didapat VM dari DHCP network default.

   virsh domifaddr vm-cloudinit01

Verifikasi dan Troubleshooting

• Flag --import berbeda dari --location yang dipakai pada Bagian 28.3.2. --location mem-boot installer Subiquity dari ISO, sedangkan --import memberi tahu virt-install bahwa disk yang ditunjuk sudah berisi sistem operasi utuh dan siap langsung dijalankan, cocok untuk cloud image yang memang sudah terinstal penuh.
• Alamat IP yang tampil dari virsh domifaddr berada di rentang 192.168.122.0/24, subnet bawaan network NAT default milik libvirt yang sudah diaktifkan di Bagian 28.2.4, berbeda dari skema 192.168.1.0/24 yang dipakai server fisik/produksi sejak Bab 9.
• Jika virsh domifaddr belum menampilkan alamat apa pun, VM kemungkinan masih dalam proses boot atau tahap Network cloud-init belum selesai meminta lease DHCP. Tunggu beberapa detik lalu ulangi, atau pantau langsung lewat virsh console vm-cloudinit01 untuk melihat proses boot secara real time.

37.3.4 Verifikasi Hasil Provisioning

Langkah Praktik

1. Login SSH ke VM memakai alamat IP hasil domifaddr dan key yang sudah didaftarkan di user-data.

   ssh [email protected]

2. Setelah berhasil login, pastikan seluruh proses cloud-init benar-benar sudah selesai sebelum menyimpulkan provisioning berhasil.

   cloud-init status --wait

3. Konfirmasikan paket nginx sudah terpasang dan aktif, sekaligus file penanda dari runcmd sudah dibuat.

   systemctl is-active nginx
   curl http://localhost/provisioned.txt

Verifikasi dan Troubleshooting

• Berhasil login SSH pada langkah pertama tidak otomatis berarti seluruh provisioning sudah selesai. Modul yang mengaktifkan ssh_authorized_keys berjalan relatif lebih awal, sementara instalasi paket lewat packages dan eksekusi runcmd baru selesai di tahap Config dan Final. Inilah sebabnya cloud-init status --wait pada langkah kedua penting dijalankan lebih dulu, sebuah kebiasaan yang layak dijadikan standar sebelum menganggap sebuah instance baru sudah sepenuhnya siap dipakai di lingkungan produksi.
• Output systemctl is-active nginx semestinya mencetak active, dan isi provisioned.txt menampilkan baris Provisioned via cloud-init on diikuti timestamp saat VM pertama kali boot, bukti konkret bahwa modul runcmd pada Bagian 37.3.2 benar-benar dieksekusi.
• Jika ada kejanggalan pada modul mana pun, log paling berguna untuk ditelusuri lebih dulu adalah /var/log/cloud-init-output.log di dalam VM, berisi seluruh output stdout dan stderr dari setiap modul persis seperti tampil di terminal. Log /var/log/cloud-init.log di sebelahnya menyimpan detail debug yang jauh lebih teknis, berguna untuk kasus yang tidak cukup jelas hanya dari log output biasa.
• Error Permission denied (publickey) pada langkah SSH mengarah kembali ke potensi salah tempel public key yang sudah disinggung di Bagian 37.3.2, atau bisa juga karena baris ssh_authorized_keys memakai indentasi YAML yang keliru sehingga cloud-init gagal membacanya sebagai list yang valid.

37.4 Penggunaan Cloud-init di VM Lokal maupun Cloud

37.4.1 Datasource Lain di Luar NoCloud: Ringkasan Perbandingan

NoCloud yang baru saja kita praktikkan hanyalah satu dari puluhan datasource yang didukung cloud-init. Setiap platform besar memiliki datasource sendiri, dengan mekanisme pengambilan data yang berbeda-beda, tetapi format user-data yang kita tulis tetap portabel di semuanya karena mesin dan modul cloud-init yang memprosesnya sama persis.

Perbedaan di antara datasource ini murni soal bagaimana cloud-init menemukan dan mengambil data, bukan soal apa yang bisa ditulis di dalam user-data itu sendiri. Seluruh key seperti users, packages, dan runcmd yang sudah dipraktikkan pada Bagian 37.3.2 berlaku sama persis di kelima datasource pada tabel di atas.

37.4.2 Memeriksa Datasource yang Terdeteksi di VM

Langkah Praktik

1. Dari dalam VM vm-cloudinit01 yang masih terhubung lewat SSH, periksa datasource yang berhasil terdeteksi ds-identify saat boot pertama.

   cloud-id --long

Verifikasi dan Troubleshooting

• Output semestinya mencetak nocloud, mengonfirmasi bahwa seed yang dilekatkan lewat flag --cloud-init pada Bagian 37.3.3 memang terbaca sebagai datasource NoCloud, bukan salah satu datasource cloud lain yang sebenarnya tidak relevan di lingkungan KVM lokal.
• Perintah cloud-id adalah binary terpisah yang ikut terpasang bersama paket cloud-init, murni untuk mengecek identitas datasource tanpa perlu membongkar file JSON instance data secara manual.

37.4.3 Portabilitas user-data ke Cloud Provider Sungguhan

File user-data yang sudah kita tulis di Bagian 37.3.2 nyaris dapat digunakan apa adanya saat meluncurkan instance sungguhan di AWS, Azure, atau GCP, tinggal ditempelkan ke kolom user data pada wizard peluncuran instance masing-masing provider, tanpa perlu membuat seed ISO manual karena datasource cloud tersebut sudah menyediakan mekanismenya sendiri lewat metadata service masing-masing. Praktik langsung di salah satu provider ini akan dibahas lebih detail pada Bab 41, termasuk perbedaan security group cloud yang menggantikan peran firewall lokal seperti UFW pada Bab 31.

Perbedaan paling terasa umumnya hanya pada meta-data, karena cloud provider mengisi instance-id dan hostname secara otomatis lewat metadata service-nya sendiri, sehingga kita nyaris tidak pernah perlu menulis meta-data manual seperti Bagian 37.3.2 di lingkungan cloud sungguhan. Ini berbeda dari lingkungan NoCloud lokal yang mengharuskan kita menuliskannya sendiri karena memang tidak ada metadata service yang bisa diandalkan.

Sampai di sini, kita sudah memahami konsep datasource, menulis dan memvalidasi user-data, hingga mempraktikkan provisioning penuh sebuah VM dari cloud image polos menjadi server yang siap pakai lengkap dengan user, SSH key, dan paket awal, seluruhnya otomatis sejak boot pertama. Cloud-init menutup rangkaian otomasi yang dimulai Bagian IX ini dengan cara yang saling melengkapi, bukan bersaing: shell script pada Bab 35 menangani task administrasi rutin di satu server, Ansible pada Bab 36 mengambil alih konfigurasi berkelanjutan lintas banyak server yang sudah hidup, dan cloud-init mengisi celah paling awal, yaitu mengubah instance kosong menjadi server siap SSH tanpa sentuhan manual sama sekali. Begitu kemampuan provisioning secepat ini tersedia, jumlah server yang dikelola cenderung bertambah cepat pula, dan menjaga visibilitas atas seluruh armada server tersebut menjadi tantangan baru yang dibuka Bagian X lewat monitoring sistem pada Bab 38.