Process Manager dengan PM2

Konfigurasi produksi yang rapi tidak menolong bila tidak ada yang menjaga prosesnya tetap hidup. Server yang kita jalankan dengan node server.mjs dari sesi terminal memiliki tiga kelemahan: prosesnya berhenti begitu sesi SSH terputus, tidak ada yang menghidupkannya kembali saat aplikasi jatuh karena galat, dan seluruh log terkurung di satu terminal yang harus tetap terbuka. Process manager menjawab ketiganya — dan di ekosistem Node.js, PM2 adalah yang paling banyak dipakai. Pada chapter ini kita pelajari apa yang dikerjakannya, perintah-perintah intinya, dan berkas konfigurasi ecosystem yang membuat semuanya terdokumentasi di dalam repo.

Mengapa Menjalankan Server dari Terminal Tidak Cukup #

Ketika kita menjalankan node server.mjs lalu menutup jendela terminal atau memutus sesi SSH, proses tersebut menerima sinyal SIGHUP dari sistem operasi dan berhenti — mekanisme sinyal ini sudah kita bahas di chapter Signal dan Event Proses. Aplikasi yang jatuh karena uncaught exception juga tidak bangkit sendiri; aplikasi tetap mati sampai seseorang menyadarinya lalu menjalankannya ulang secara manual. Bahkan tugas sederhana seperti melihat log kemarin pun mustahil bila log hanya mengalir di terminal yang sudah lama tertutup.

Process manager memutus ketergantungan itu dengan pola daemon: aplikasi dijalankan sebagai proses latar belakang yang tidak lagi menjadi anak dari sesi terminal kita, dan sebuah proses pengawas terpisah terus memantau kondisinya. Ringkasan peran tersebut berbentuk tabel berikut:

Baris terakhir patut dijelaskan singkat: PM2 dapat menjalankan beberapa salinan aplikasi kita di belakang satu port yang sama, memakai mekanisme yang sama dengan module node:cluster dari chapter Clustering — tetapi tanpa satu baris kode cluster pun di aplikasi.

Perintah-Perintah Inti #

Pemasangan PM2 dilakukan sekali secara global di server, lalu aplikasi pertama dinyalakan dengan satu perintah:

npm install -g pm2
pm2 start server.mjs --name aplikasi-tugas

Opsi --name memberi identitas pada proses agar perintah-perintah berikutnya tidak perlu menyebut path berkas. Sekelompok perintah inti mengelola siklus hidupnya:

pm2 list                    # tabel seluruh aplikasi beserta statusnya
pm2 restart aplikasi-tugas  # nyalakan ulang
pm2 reload aplikasi-tugas   # ganti versi tanpa waktu henti
pm2 stop aplikasi-tugas     # hentikan, tapi tetap terdaftar
pm2 delete aplikasi-tugas   # hapus dari daftar proses

Dua perintah di tengah perlu dibedakan. pm2 restart menghentikan seluruh proses aplikasi lalu menyalakannya kembali sekaligus — selama jeda singkat itu tidak ada yang melayani permintaan. pm2 reload mengganti proses satu per satu sambil menjaga setidaknya satu proses tetap berjalan, sehingga pembaruan versi aplikasi terasa tanpa jeda bagi pengguna; pada aplikasi satu proses, keduanya praktis sama. Seluruh perintah pengelolaan proses ini dirinci di panduan process management PM2 .

Pemantauan berjalan lewat dua pintu. pm2 logs menampilkan aliran log aplikasi secara langsung — stdout maupun stderr — dan PM2 juga menyimpan salinannya ke berkas di folder ~/.pm2/logs sehingga log kemarin tetap bisa dibaca; perintah pm2 flush mengosongkannya kembali, dan urusan rotasi berkas log dibahas di panduan log management PM2 . Adapun pm2 monit membuka tampilan interaktif berisi pemakaian CPU, memori, dan laju request per menit untuk tiap proses — angka-angka yang menjadi bahasa pengantar Chapter Logging dan Monitoring nanti.

Berkas ecosystem untuk Konfigurasi Terdokumentasi #

Semua opsi di atas bisa diberikan lewat command line, tetapi daftar flag yang panjang rapuh: tidak terdokumentasi, mudah lupa, dan berbeda antar anggota tim. PM2 menyediakan berkas ecosystem.config.js sebagai satu tempat untuk seluruh konfigurasi — mengikuti pola “konfigurasi hidup di dalam repo” yang sama dengan eslint.config.mjs dan .prettierrc.json pada chapter Konsistensi Gaya Kode:

module.exports = {
  apps: [
    {
      name: 'aplikasi-tugas',
      script: './server.mjs',
      mode: 'cluster',
      instances: 'max',
      env: {
        NODE_ENV: 'development',
        PORT: 3000,
      },
      env_production: {
        NODE_ENV: 'production',
      },
      max_memory_restart: '200M',
    },
  ],
};

Mari kita bedah baris-per-baris konfigurasi di atas:

1. name dan script: identitas aplikasi di daftar PM2 beserta berkas titik masuknya — padanan flag --name dan argumen posisi pada pm2 start.
2. mode: 'cluster' dan instances: 'max': menyalakan cluster mode dengan jumlah salinan sebanyak core CPU yang tersedia; nilai instances juga menerima angka pasti seperti 2 bila kita ingin membatasinya. Perlu diingat bahwa aplikasi di cluster mode harus stateless — data sesi dan cache milik bersama tidak boleh disimpan di memori satu proses — karena permintaan pengguna yang sama bisa dilayani proses yang berbeda; panduan lengkapnya ada di halaman load balancing PM2 .
3. env: environment variable yang berlaku saat aplikasi dinyalakan dalam mode biasa — di sini mode pengembangan dengan port tetap.
4. env_production: menimpa nilai yang sama ketika PM2 menjalankan berkas dengan lingkungan produksi, sehingga satu berkas mendukung dua dunia.
5. max_memory_restart: '200M': batas pemakaian memori — bila proses melebihinya, PM2 memulai ulang proses tersebut; pengaman terhadap kebocoran memori yang dibahas di chapter Memory Management dan GC.

Aplikasi dinyalakan dari berkas tersebut dengan lingkungan produksi:

pm2 start ecosystem.config.js --env production

Menyala Bersama Server #

Satu masalah masih tersisa: PM2 sendiri berjalan sebagai proses biasa — bila server di-boot ulang, daemon PM2 ikut berhenti dan seluruh aplikasinya tidak otomasi. Dua perintah ini menutup celah itu:

pm2 startup
pm2 save

Perintah pm2 startup menghasilkan skrip integrasi dengan sistem init (systemd di banyak distribusi Linux) yang otomatis menjalankan daemon PM2 setiap kali server menyala. Adapun pm2 save merekam daftar aplikasi yang sedang berjalan saat itu; daemon yang bangkit saat boot kemudian memulihkan daftar tersebut. Kombinasinya menuntaskan rantai ketersediaan: server boot, PM2 menyala, aplikasi dipulihkan, dan setiap proses yang jatuh dimulai ulang.

Alternatif lain untuk masalah yang sama memang ada — unit file systemd yang ditulis manual, atau container Docker yang pengelolaannya kita bahas dua chapter ke depan. PM2 menempati titik manis: khusus Node.js, terpasang dengan satu perintah, dan dekat dengan aplikasi lewat cluster mode serta pengelolaan log. Sebelum melangkah ke container, mari kita rapikan dulu hal yang dijanjikan tabel di awal chapter: log dan metrik yang membuat kesehatan aplikasi bisa dipantau — topik Chapter Logging dan Monitoring.