All Products
Search

This Product

    Container Registry:Praktik terbaik untuk meng-container-kan proyek Java

    Document Center

    Container Registry:Praktik terbaik untuk meng-container-kan proyek Java

    Last Updated:Aug 29, 2026

    Gunakan Dockerfile untuk membangun kode sumber menjadi gambar kontainer, lalu distribusikan dan deploy gambar tersebut. Proyek Java lebih sulit di-container-kan dibandingkan proyek Golang atau Python, dan proses build-nya seringkali lebih lambat. Perusahaan biasanya mengandalkan repositori dependensi yang dikelola sendiri seperti Maven, dan pengembang sering tidak familiar dengan mekanisme cache Dockerfile. Topik ini dimulai dari skenario khas: repositori kode GitLab yang dikelola sendiri dan repositori Maven yang dikelola sendiri di cloud. Topik ini menjelaskan cara membangun proyek Java dengan Dockerfile, mempercepat setiap proses build, serta mengotomatiskan pembuatan gambar menggunakan layanan build Container Registry Enterprise Edition (ACR EE).

    Prasyarat

    • Anda telah membuat repositori kode GitLab.

    • Anda telah membuat repositori Maven.

    • Anda telah membuat instans Container Registry Enterprise Edition. Untuk informasi selengkapnya, lihat Buat instans Edisi Perusahaan.

    Ikhtisar proyek

    Topik ini mendemonstrasikan proses build menggunakan dua proyek Java yang saling bergantung. Proyek-proyek tersebut adalah sebagai berikut:

    • Provider: Menyediakan layanan yang dapat dipanggil.

      • Modul Core: Menyediakan antarmuka publik.

      • Modul Service: Modul implementasi layanan.

    • Consumer: Memanggil layanan Provider.

      • Modul Service: Bergantung pada modul Core dalam proyek Provider. Contoh struktur kode sebagai berikut:

        .
├── consumer
│ ├── Dockerfile
│ ├── consumer.iml
│ ├── pom.xml
│ └── service
│     ├── pom.xml
│     ├── src
│     └── target
└── provider
    ├── Dockerfile
    ├── core
    │ ├── pom.xml
    │ ├── src
    │ └── target
    ├── pom.xml
    ├── provider.iml
    └── service
        ├── pom.xml
        ├── src
        └── target

    Artefak build:

    • Gambar aplikasi produsen yang dibangun dari proyek Provider.

    • Gambar aplikasi konsumen yang dibangun dari proyek Consumer.

    Langkah 1: Pastikan dependensi publik telah diunggah

    Unggah paket dependensi publik yang direferensikan oleh proyek Anda ke repositori Maven yang dikelola sendiri sebelum membangun gambar apa pun. Untuk proyek Provider, jalankan perintah unggah berikut di direktori Provider:

    mvn clean install org.apache.maven.plugins:maven-deploy-plugin:2.8:deploy -DskipTests

    Langkah 2: Buat gambar dasar Maven kustom

    Untuk mengakses repositori Maven yang dikelola sendiri di lingkungan build yang dikontainerisasi, tambahkan konfigurasi repositori Maven ke gambar dasar. Buat gambar dasar Maven publik kustom untuk perusahaan Anda berdasarkan gambar Maven resmi. Proyek aplikasi kemudian dapat mereferensikan gambar dasar ini untuk mengakses repositori Maven.

    1. Simpan konten berikut sebagai Dockerfile dan letakkan di direktori yang sama dengan file settings.xml repositori Maven.

      FROM maven:3.8-openjdk-8 # Gunakan gambar Maven yang sesuai dengan proyek. Contoh ini menggunakan Maven 3.8.
ADD settings.xml /root/.m2/ # Tambahkan konfigurasi repositori Maven yang dikelola sendiri ke path yang ditentukan.

    2. Jalankan perintah berikut untuk membangun gambar dan mendorongnya ke repositori gambar remote.

      ls
Dockerfile   settings.xml
docker build -t demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 -f Dockerfile .
Sending build context to Docker daemon   7.68kB
Step 1/2 : FROM maven:3.8-openjdk-8
 ---> a3f42bfde036
Step 2/2 : ADD settings.xml /root/.m2/
 ---> db0d5a5192e3
Successfully built db0d5a5192e3
Successfully tagged demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8
docker push demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8

    Langkah 3: Bangun gambar aplikasi Consumer (lewati untuk proyek Provider)

    Jalankan perintah berikut. (Dorong semua gambar dasar yang diperlukan selama proses build ke repositori gambar Alibaba Cloud.)

    FROM demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 AS builder
# tambahkan pom.xml dan kode sumber
ADD ./pom.xml pom.xml
ADD ./service service/
# buat paket jar
RUN mvn clean package
# Tahap kedua: lingkungan runtime minimal
From demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/openjdk:8-jre-alpine
# salin jar dari tahap pertama
COPY --from=builder service/target/service-1.0-SNAPSHOT.jar service-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "service-1.0-SNAPSHOT.jar"]

    Langkah 4: Optimalkan kecepatan build

    Dalam Langkah 3: Bangun gambar aplikasi Consumer (lewati untuk proyek Provider), Anda telah membangun sebuah gambar. Namun, jika Anda mengubah kode dan membangun ulang, Anda akan melihat bahwa proses build lambat karena paket JAR diunduh ulang alih-alih menggunakan cache. Docker membatalkan cache untuk suatu layer ketika isinya berubah. Setelah Anda mengubah kode sumber, hash file dalam instruksi ADD berubah. Perubahan ini memaksa instruksi RUN dieksekusi ulang, sehingga mengabaikan cache dari build sebelumnya. Untuk informasi selengkapnya, lihat praktik terbaik Dockerfile.

    Untuk mengoptimalkan kecepatan build, cache dan gunakan ulang dependensi Maven:

    1. Pertama, salin file pom.xml proyek ke dalam kontainer untuk mengunduh dependensi. Selama file pom.xml tidak berubah, build berikutnya dapat menggunakan cache.

    2. Salin kode sumber proyek dan kompilasi.

    Dockerfile berikut merupakan versi yang ditingkatkan. Build pertama memakan waktu 43 detik. Jika Anda hanya mengubah kode sumber, build berikutnya hanya memerlukan 7 detik.

    FROM demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 AS builder
# Untuk menyelesaikan dependensi dengan cara yang aman (tidak mengunduh ulang saat kode sumber berubah)
ADD ./pom.xml pom.xml
ADD ./service/pom.xml service/pom.xml
RUN  mvn install
ADD ./service service/
# buat paket jar
RUN mvn clean package
# Tahap kedua: lingkungan runtime minimal
From demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/openjdk:8-jre-alpine
# salin jar dari tahap pertama
COPY --from=builder service/target/service-1.0-SNAPSHOT.jar service-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "service-1.0-SNAPSHOT.jar"]

    Langkah 5: Proses build otomatis dengan Container Registry Enterprise Edition

    ACR EE menyediakan layanan build tingkat perusahaan dan direkomendasikan untuk pelanggan perusahaan. Untuk informasi selengkapnya, lihat Bangun gambar menggunakan instans Edisi PerusahaanBangun gambar menggunakan instans Edisi Perusahaan.

    Bagian berikut menguraikan beberapa praktik terbaik.

    • Use the VPC build mode

      Untuk instans GitLab yang dikelola sendiri di cloud, gunakan mode build VPC yang aman untuk membangun gambar. Hal ini mencegah layanan terekspos ke internet publik. Untuk informasi selengkapnya, lihat Bangun gambar kontainer dalam mode VPC yang amanBangun gambar kontainer dalam mode VPC yang aman.

    • Gunakan fitur versi gambar immutable

      Aktifkan fitur versi gambar immutable untuk repositori guna mencegah versi online ditimpa. Di halaman Create Image Repository, pada langkah Repository Information, atur Image Version ke Immutable dengan memilih kotak centang tersebut. Setelah Anda memilih kotak centang ini, tidak ada versi gambar dalam repositori—kecuali latest—yang dapat ditimpa. Hal ini menjaga konsistensi versi gambar kontainer.

    • Buat aturan build berdasarkan ID commit

      Setiap build menghasilkan dua versi gambar. Satu versi menggunakan ID commit kode, sehingga Anda dapat memetakan versi gambar ke versi kode. Versi lainnya menggunakan latest untuk menandai versi terbaru. Di dialog Modify Building Rule, pada langkah Image Version, versi gambar Commit ID dan latest telah dikonfigurasi.

      Komit kode untuk memicu build. Contoh berikut menunjukkan dua build yang secara otomatis dipicu oleh dua commit kode. Setiap build menghasilkan dua gambar, dan build kedua lebih cepat karena memanfaatkan cache. Di halaman pengaturan build, sakelar Automatically Build Images upon Code Change diaktifkan. Dalam pengaturan aturan build, Branch diatur ke branches:master, direktori konteks build adalah /, dan nama Dockerfile adalah Dockerfile. Versi gambar mencakup dua tag, Configuration 1 dan Configuration 2, yang masing-masing sesuai dengan versi ID commit dan versi latest. Log build menunjukkan bahwa kedua build berhasil diselesaikan, masing-masing memakan waktu 85 detik dan 106 detik.