Jasa Ansible untuk Otomasi Konfigurasi Server

Playbook Ansible dan sifat idempoten

Yang membedakan playbook Ansible dari skrip shell adalah sifat idempotennya. Skrip yang menambahkan satu baris ke berkas konfigurasi akan menambahkannya lagi setiap kali dijalankan. Ansible menyatakan kondisi yang diinginkan — baris ini harus ada, sekali — dan tidak mengubah apa pun bila sudah sesuai.

Konsekuensinya praktis: playbook bisa dijalankan kapan saja tanpa khawatir merusak. Ia juga menjadi dokumentasi yang tidak bisa kedaluwarsa, karena kalau dokumennya salah, playbook-nya gagal.

Ansible juga tidak menuntut agen di server tujuan. Ia bekerja lewat SSH, jadi tidak ada yang perlu dipasang lebih dulu — pembeda yang penting untuk lingkungan yang campur atau yang sebagian servernya tidak boleh menerima perangkat lunak tambahan.

Ansible inventory dan pengelompokan server

Penyusunan ansible inventory menentukan seberapa berguna otomatisasinya. Inventory yang baik mengelompokkan server berdasarkan peran — web, basis data, cache — dan berdasarkan lingkungan, sehingga satu playbook bisa dijalankan ke kelompok tertentu saja.

Variabel per kelompok dan per host memisahkan konfigurasi dari nilainya. Playbook yang sama memasang Nginx dengan jumlah worker berbeda di server pengujian dan produksi, cukup dengan mengubah satu variabel.

Untuk lingkungan yang server-nya sering berubah, inventory dinamis membacanya langsung dari API penyedia cloud. Dengan begitu server baru otomatis masuk cakupan tanpa ada yang perlu menyunting berkas — dan tidak ada server yang terlewat karena lupa didaftarkan.

Konfigurasi server massal dan urutan penerapannya

Kemampuan konfigurasi server massal adalah alasan orang mulai memakai Ansible, dan juga sumber risiko terbesarnya: satu perintah bisa mengubah lima puluh server sekaligus, termasuk mengubahnya jadi salah semua.

Pengaman yang kami pakai berlapis. Mode `--check` menampilkan apa yang akan berubah tanpa mengubahnya. Opsi `--limit` membatasi ke satu server sebagai uji coba. Untuk penerapan ke banyak server, `serial` mengerjakannya bertahap — sepuluh persen dulu, diamati, baru lanjut.

Untuk server di belakang load balancer, playbook diatur agar mengeluarkan server dari rotasi sebelum diubah dan memasukkannya kembali setelah pemeriksaan lolos. Dengan begitu perubahan berjalan tanpa jeda layanan.

Ansible Vault untuk kredensial di dalam repositori

Otomatisasi selalu butuh kredensial — kata sandi basis data, kunci API, sertifikat. Menaruhnya sebagai teks biasa di repositori adalah kesalahan yang berulang kali menjadi berita.

Ansible Vault mengenkripsi berkas atau variabel tertentu, sehingga bisa disimpan di repositori bersama kode lainnya dan tetap aman. Kunci pembukanya disimpan terpisah — di pengelola kata sandi, atau sebagai secret di sistem CI.

Yang kami sarankan: enkripsi pada tingkat variabel, bukan seluruh berkas. Dengan begitu perubahan pada berkas masih bisa dibaca sebagai diff yang berguna, sementara nilai sensitifnya tetap tertutup.

Untuk organisasi yang sudah memakai pengelola secret terpusat seperti Vault dari HashiCorp, Ansible bisa mengambil nilainya saat berjalan — jadi tidak ada kredensial yang tersimpan di repositori sama sekali.

Otomasi konfigurasi server: dari mana mulai

Penerapan otomasi konfigurasi server yang mencoba mencakup semuanya sekaligus biasanya berhenti di tengah. Urutan yang kami pakai memberi hasil terlihat lebih cepat.

• Mulai dari pemasangan server baru — pekerjaan yang paling berulang dan paling seragam.
• Lanjut ke penguatan keamanan dasar: pengguna, kunci SSH, firewall, `fail2ban`.
• Kemudian pemasangan dan konfigurasi layanan: server web, runtime bahasa, agen pemantauan.
• Setelah itu pekerjaan berkala: rotasi kunci, pembaruan sertifikat, pemangkasan log.
• Terakhir, penerapan aplikasi — meski untuk ini sistem CI biasanya lebih tepat.

Ansible atau Terraform: keduanya, bukan salah satu

Pertanyaan ini sering muncul dan jawabannya cukup jelas: keduanya menangani lapisan yang berbeda. Terraform membuat sumber dayanya — server, jaringan, penyimpanan. Ansible mengonfigurasi isi server yang sudah ada.

Pola yang lazim kami pasang: Terraform membangun infrastrukturnya, lalu Ansible menyiapkan isinya. Keduanya bisa disambungkan sehingga server yang baru dibuat langsung masuk inventory dan dikonfigurasi tanpa langkah manual di antaranya.

Ansible memang punya modul untuk membuat sumber daya cloud juga, tetapi ia tidak menyimpan state — jadi tidak bisa menjawab "apa yang berubah" seperti `terraform plan`. Untuk pekerjaan itu, Terraform tetap lebih tepat.

Menguji playbook sebelum menyentuh produksi

Otomatisasi yang tidak diuji hanya memperbesar skala kesalahan. Karena itu ada beberapa lapis pemeriksaan sebelum playbook menyentuh server yang melayani.

• Pengujian sintaks dan aturan gaya lewat `ansible-lint` pada setiap perubahan.
• Uji jalan di kontainer atau mesin virtual sementara, memastikan hasilnya sesuai dari kondisi bersih.
• Uji idempoten: dijalankan dua kali, dan pada eksekusi kedua tidak boleh ada perubahan yang dilaporkan.
• Penerapan ke lingkungan pengujian yang bentuknya sama dengan produksi.
• Baru kemudian produksi, bertahap dengan `serial` dan pemeriksaan kesehatan di antaranya.