Laptop di samping rak server menampilkan log deployment aplikasi Java ke Tomcat
Server & Tomcat

Cara Deploy Aplikasi Java ke Tomcat Langkah demi Langkah

adm_d7zkagp6

Cara deploy aplikasi Java ke Tomcat yang paling aman bergantung pada siapa yang menjalankan server dan seberapa sering rilis terjadi. Untuk intranet dengan rilis jarang, menyalin WAR ke folder webapps sudah cukup. Untuk tim yang merilis beberapa kali sehari, deploy lewat konteks terpisah atau manager lebih terkontrol.

Ada tiga metode deploy yang dibandingkan di sini, ditambah langkah persiapan WAR dan cara memverifikasi hasilnya sebelum pengguna menyadari kesalahan.

Menyiapkan WAR yang Layak Dideploy

Sebelum menyentuh server, pastikan artefak yang dibangun memang bisa berjalan sendiri. Periksa isi WAR dengan jar tf target/aplikasi.war dan pastikan folder WEB-INF/classes serta WEB-INF/lib terisi sesuai harapan.

Konfigurasi yang berbeda antar lingkungan sebaiknya tidak ditanam di dalam WAR. Simpan application.properties atau context.xml di luar artefak, lalu arahkan Tomcat ke lokasi tersebut. Pola ini membuat WAR yang sama bisa dipakai di staging dan produksi tanpa dibongkar ulang.

Untuk aplikasi yang memakai koneksi database, definisikan datasource di META-INF/context.xml atau di level server. Rincian parameternya dibahas di panduan konfigurasi connection pool di Java, termasuk cara menghindari pool yang habis saat beban naik.

Tiga Metode Deploy dan Kapan Memakainya

1. Salin WAR ke folder webapps

Tomcat memantau folder $CATALINA_HOME/webapps dan mengekstrak WAR secara otomatis. Metode ini paling sederhana, tapi punya satu jebakan: jika deployment gagal di tengah ekstraksi, folder hasil ekstraksi bisa tertinggal dan menutupi WAR baru pada rilis berikutnya.

Hentikan Tomcat, hapus folder hasil ekstraksi lama, salin WAR baru, lalu jalankan ulang. Langkah manual ini menghindari aplikasi berjalan dengan campuran kelas lama dan baru.

2. Deploy lewat Tomcat Manager

Manager memberi antarmuka HTTP untuk mengunggah WAR dan memantau status aplikasi. Cocok untuk server yang diakses beberapa orang, asalkan akun manager dibatasi peran dan tidak diekspos ke jaringan luas.

Kelemahannya, unggahan WAR berukuran besar bisa terputus di tengah jalan pada koneksi intranet yang tidak stabil. Untuk artefak di atas ratusan megababyte, metode ini sering merepotkan.

3. Konteks terpisah di luar webapps

Tomcat membaca file conf/Catalina/localhost/aplikasi.xml yang menunjuk ke lokasi WAR atau direktori di luar instalasi Tomcat. Metode ini memisahkan artefak dari server, sehingga upgrade Tomcat tidak menyentuh aplikasi dan rollback cukup mengganti satu file XML.

<Context docBase="/opt/aplikasi/rilis-2026-10-22" reloadable="false">
  <Resource name="jdbc/app" auth="Container"
            type="javax.sql.DataSource"
            maxTotal="20" maxIdle="5" />
</Context>

Tabel berikut merangkum perbandingannya.

Metode Cocok untuk Risiko utama
Salin ke webapps Rilis jarang, satu admin Sisa folder ekstraksi lama
Tomcat Manager Tim kecil, artefak ringan Unggahan terputus, akses terbuka
Konteks terpisah Rilis sering, banyak lingkungan Salah tulis path docBase

Langkah Deploy dengan Konteks Terpisah

  1. Bangun WAR dan catat versinya di nama file, misalnya aplikasi-2026-10-22.war.
  2. Salin ke direktori rilis di server, pisahkan dari folder instalasi Tomcat.
  3. Buat file konteks di conf/Catalina/localhost/aplikasi.xml dengan atribut docBase menunjuk ke WAR tersebut.
  4. Setel reloadable="false" agar Tomcat tidak memantau perubahan kelas saat produksi.
  5. Jalankan ulang Tomcat, atau biarkan autoDeploy memuat konteks baru.
  6. Periksa logs/catalina.out dan logs/localhost.*.log untuk memastikan tidak ada ClassNotFoundException atau kegagalan datasource.

Untuk rollback, ubah docBase kembali ke WAR versi sebelumnya. Simpan minimal dua versi terakhir di server agar langkah ini tidak perlu menunggu unggahan.

Verifikasi Setelah Deploy

Buka satu endpoint kesehatan yang tidak menyentuh database, lalu satu endpoint yang menyentuh database. Dua pemeriksaan terpisah ini membantu membedakan masalah konfigurasi aplikasi dari masalah koneksi.

Akses juga halaman yang memuat aset statis. Kesalahan path konteks sering baru terlihat saat CSS dan JavaScript gagal dimuat, bukan saat respons API pertama.

Jika aplikasi mengandalkan nama host internal, pastikan resolusi nama berjalan dari server aplikasi. Perbandingan resolver publik di membandingkan DNS publik: Cloudflare, Google, dan Quad9 berguna saat memilih resolver untuk server yang juga butuh akses keluar.

Memilih antara Tomcat dan Alternatif Lain

Tomcat cocok bila aplikasi hanya butuh wadah servlet. Jika kebutuhan mulai mencakup deployment multi-aplikasi dengan manajemen terpusat atau clustering bawaan, pertimbangkan server lain. Perbandingan kemampuannya ada di membandingkan pilihan web server Java untuk aplikasi intranet.

Aplikasi yang berkomunikasi dengan layanan internal lain juga perlu memperhatikan pola API-nya. Beberapa pola yang umum dipakai untuk layanan internal dijelaskan di 5 pola arsitektur API Java untuk layanan internal. Pola yang dipilih memengaruhi cara konfigurasi keamanan dan timeout di Tomcat.

Untuk server yang menyimpan data pengguna intranet, pertimbangkan juga kanal komunikasi tim operasional saat menangani insiden. Perbandingan di perbandingan aplikasi pesan terenkripsi bisa menjadi bahan pertimbangan saat memilih kanal koordinasi.

Ringkasan

Deploy ke Tomcat yang terkendali berisi tiga kebiasaan: artefak diberi versi, konfigurasi lingkungan hidup di luar WAR, dan rollback disiapkan sebelum rilis. Metode konteks terpisah memberi kontrol paling besar untuk tim yang sering merilis, sementara salin ke webapps tetap masuk akal untuk server tunggal yang jarang berubah.

Pertanyaan yang Sering Diajukan

Apakah perlu menghapus folder hasil ekstraksi sebelum deploy ulang?

Ya, bila memakai metode salin ke webapps. Tomcat membandingkan timestamp WAR dan folder, tapi kegagalan ekstraksi sebelumnya bisa meninggalkan kelas lama. Menghapus folder memastikan hanya artefak baru yang dimuat.

Kenapa aplikasi berjalan di staging tapi gagal di produksi?

Penyebab umumnya konfigurasi yang ditanam di dalam WAR, perbedaan versi JDK, atau datasource yang tidak tersedia. Periksa log localhost untuk pesan awal kegagalan, biasanya muncul sebelum aplikasi selesai start.

Berapa lama waktu tunggu yang wajar untuk startup?

Tergantung jumlah library dan inisialisasi aplikasi. Jika startup melewati batas yang ditetapkan Tomcat, tambah nilai startupTimeout pada konteks atau periksa komponen yang memblokir thread utama saat inisialisasi.