Saat pertama membangun server produksi, saya sempat mengira setiap service Docker harus membuka port agar bisa diakses. Setelah beberapa kali setup ulang dan audit keamanan, pola tersebut justru membuka banyak celah. Karena itu, saya memilih pendekatan yang lebih aman: semua service berjalan di network bridge tanpa expose port, lalu akses publik saya kontrol penuh melalui reverse proxy.
Pendekatan ini saya terapkan langsung di server produksi dengan banyak layanan aktif. Hasilnya terasa lebih rapi, lebih aman, dan jauh lebih mudah dikelola.
Kenapa Service Docker Tidak Perlu Expose Port?
Saat admin membuka port, service bisa langsung menerima akses dari luar server. Jika jumlah container terus bertambah, permukaan serangan ikut melebar. Selain itu, konflik port sering muncul ketika admin menambahkan layanan baru.
Dengan network bridge internal, container tetap bisa saling terhubung. Namun, service tidak bisa diakses langsung dari luar tanpa perantara. Pada tahap inilah reverse proxy mengambil peran utama.
Konsep Dasar Arsitektur yang Saya Gunakan
Saya menerapkan konsep yang sederhana namun efektif:
- Saya menempatkan semua container di satu network bridge
- Saya tidak membuka port service ke host
- Saya menjadikan reverse proxy sebagai satu-satunya pintu akses publik
Dengan pola ini, server hanya benar-benar membuka port 80 dan 443.
Mengenal Bridge Network di Docker
Bridge network memungkinkan container berkomunikasi menggunakan nama service. Docker secara otomatis mengatur routing internal tanpa IP manual. Karena itu, reverse proxy tetap bisa mengakses service meskipun admin tidak membuka port ke host.
Pola ini sangat cocok untuk WordPress, monitoring server, maupun aplikasi internal.
Contoh Docker Compose Tanpa Expose Port
version: '3.8'
networks:
internal_net:
driver: bridge
services:
wordpress:
image: wordpress:latest
container_name: wp_internal
networks:
- internal_net
volumes:
- ./wp:/var/www/html
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wpuser
WORDPRESS_DB_PASSWORD: wppass
WORDPRESS_DB_NAME: wpdb
db:
image: mariadb:10.6
container_name: db_internal
networks:
- internal_net
environment:
MYSQL_DATABASE: wpdb
MYSQL_USER: wpuser
MYSQL_PASSWORD: wppass
MYSQL_ROOT_PASSWORD: rootpass
Pada konfigurasi ini, saya tidak membuka satu pun port ke host.
Peran Reverse Proxy Sebagai Gerbang Publik
Untuk akses dari internet, saya menjalankan reverse proxy di Docker dan menghubungkannya ke network yang sama. Dengan cara ini, reverse proxy langsung mengarah ke nama container.
Request dari domain masuk ke reverse proxy, lalu proxy meneruskannya ke service internal tanpa membuka port tambahan.
Alur Akses yang Terjadi
- User membuka domain dari browser
- Request masuk ke reverse proxy
- Reverse proxy meneruskan request ke container tujuan
- Service merespons tanpa expose port ke publik
Baca Juga :
- Install Nginx Proxy Manager di Docker
- Docker Tidak Bisa Akses Internet
- Monitoring Docker dengan Scrutiny
Keuntungan Model Ini di Server Produksi
Setelah menerapkan konsep ini, saya bisa menambah service baru tanpa memikirkan konflik port. Firewall juga menjadi lebih sederhana karena saya hanya fokus mengamankan port 80 dan 443.
Jika satu service bermasalah, akses publik tetap aman karena reverse proxy memegang kendali penuh.
Kesimpulan
Menjalankan service Docker tanpa expose port bukan hanya soal keamanan, tetapi juga soal kerapian arsitektur. Dengan bridge network dan reverse proxy, admin bisa menjaga server produksi tetap stabil dan mudah dikembangkan.
Pola ini sangat cocok untuk server dengan banyak layanan aktif.