Kenapa Docker Buildx Mengubah CI/CD Gue Selamanya

Kenapa Gue Akhirnya Ninggalin Server Side Docker Build

Ngeliat pipeline GitLab ngantri 15 menit udah jadi rutinitas harian gue. Server CPU nya mentok tiap kali Docker build, ngeblock deployment lain dan ngabisin resource habis habisan. Setelah bertahun tahun nerima ini sebagai hal normal, gue akhirnya mikir udah cukup deh.

Solusinya dateng lewat Docker Buildx pake cloud builder. Subscribe Docker Pro setahun dan migrasi seluruh pipeline CI/CD ngubah semuanya total. Waktu build turun 67 persen, load server terjun bebas, dan tim gue berhenti ngeluh soal deployment yang lambat.

Kalo lo lagi pake Docker build di dalam server dan ngalamin bottleneck resource, build yang lambat, atau performa yang ga konsisten, panduan ini cocok banget buat lo.

Masalah dengan Docker Build Tradisional

Waktu lo jalanin docker build langsung di GitLab runner atau server, ada beberapa masalah yang muncul nih. Pertama, lo berebut resource sama job lain. Kedua, build caching jadi ga predictable. Ketiga, hardware server lo jadi batas performa build lo.

Di project production frontend gue, setiap build butuh sekitar 8 sampe 12 menit di server OVH kita. Server struggle banget kalo ada beberapa build concurrent, dan kita punya tiga deployment job terpisah yang rebutan resource yang sama.

Ini nih contoh traditional build yang biasa di konfigurasi GitLab CI kita sebelum migrasi.

build_job:
    stage: build
    script:
        - docker build -t myapp:latest .
        - docker push myapp:latest

Simpel kan? Tapi di balik layar, ini ngehabisin siklus CPU yang gede banget, server jadi panas, dan ngeblock pipeline lain.

Apa yang Bikin Docker Buildx Beda

Docker Buildx ngextend perintah docker build dengan capability baru. Dia support multi platform build, strategi caching yang advanced, dan yang paling penting, remote builder.

Game changer nya adalah Docker Build Cloud. Waktu lo subscribe Docker Pro, lo dapet akses ke cloud builder yang handle build lo secara remote. Server lo jadi coordinator, bukan workhorse.

Analoginya gini deh. Daripada lo masak pesta di dapur kecil lo, lo pesen dari restoran yang punya equipment industrial grade. Makanannya dateng lebih cepet, dapur lo tetep bersih, dan lo bisa handle banyak pesanan sekaligus.

Baca Juga: Menguasai Automated Docker Tagging di GitLab CI/CD: Panduan Praktis

Journey Migrasi Gue Step by Step

Migrasi butuh tiga perubahan utama di pipeline GitLab CI/CD kita nih. Pertama, install buildx di runner environment. Kedua, konfigurasi cloud builder. Ketiga, update perintah build.

Ini nih exact before script yang kita implementasikan.

before_script:
    - docker info
    - echo $DOCKER_HUB_PASSWORD | docker login -u $DOCKER_HUB_USERNAME --password-stdin
    - |
        apk add curl jq
        ARCH=${CI_RUNNER_EXECUTABLE_ARCH#*/}
        BUILDX_URL=$(curl -s https://raw.githubusercontent.com/docker/actions-toolkit/main/.github/buildx-lab-releases.json | jq -r ".latest.assets[] | select(endswith(\"linux-$ARCH\"))")
        mkdir -vp ~/.docker/cli-plugins/
        curl --silent -L --output ~/.docker/cli-plugins/docker-buildx $BUILDX_URL
        chmod a+x ~/.docker/cli-plugins/docker-buildx
    - docker buildx create --use --driver cloud myorg/builder-cloud

Script ini ngelakuin beberapa hal krusial nih. Dia download binary buildx terbaru sesuai arsitektur runner. Dia install buildx sebagai Docker CLI plugin. Terus dia create buildx builder pake cloud driver, ngarah ke tim organisasi Docker gue.

Yang keren di sini adalah ini jalan sekali per job, dan overhead setup nya minimal banget dibanding penghematan waktu build.

Transformasi Build Command

Perintah build yang actual berubah dari docker build simpel jadi docker buildx build dengan flag spesifik.

script:
    - |
        docker buildx build \
          --platform linux/amd64 \
          --tag $DOCKER_HUB_IMAGE:$CI_PIPELINE_IID \
          --push .

Perhatiin perbedaan key nya nih. Kita specify platform secara eksplisit. Kita push langsung waktu build, jadi ngilangin step push terpisah. Yang paling penting, build terjadi di cloud, bukan di server kita.

Setelah cloud build selesai, kita pull image nya balik buat deploy ke container kita.

- docker pull $DOCKER_HUB_IMAGE:$CI_PIPELINE_IID
- docker rm -f app-fe-prod-container-1 || true
- docker run -d -p 3202:3000 --name app-fe-prod-container-1 $DOCKER_HUB_IMAGE:$CI_PIPELINE_IID

Pendekatan hybrid ini kasih kita yang terbaik dari dua dunia. Cloud build yang cepet dan fleksibilitas deployment lokal.

Angka Performa Real

Biar gue share hasil actual dari production pipeline kita yuk. Sebelum buildx, rata rata waktu build kita adalah 10 menit 30 detik. Setelah migrasi, turun jadi 3 menit 15 detik.

Liat pipeline 5400 dari data GitLab API kita, build job selesai cuma dalam 194 detik. Itu pengurangan 67 persen waktu build loh. Deployment job yang ngikutin selesai dalam waktu kurang dari 2 menit masing masing.

Tapi kecepatan bukan satu satunya kemenangan. Penggunaan CPU server kita waktu build turun dari spike 90 persen jadi hampir 20 persen doang. Ini ngebebasin resource buat service krusial lain yang jalan di mesin yang sama.

Dari segi biaya, langganan Docker Pro sekitar 9 dolar per bulan per user itu ga seberapa dibanding penghematan waktu. Tim gue push 20 sampe 30 build setiap hari. Itu 3.5 jam yang kesimpen setiap hari loh.

Baca Juga: GitLab CI/CD: Variabel Dinamis Lintas Environment

Pelajaran yang Dipetik dan Best Practice

Migrasi ga selalu mulus kok. Awalnya gue lupa set flag platform, hasilnya image ARM yang ga bisa jalan di server x86 kita. Selalu specify target platform lo secara eksplisit ya.

Gotcha lain adalah autentikasi. Pastiin kredensial Docker Hub lo punya akses ke service Build Cloud. Error message nya ga selalu jelas kalo ini gagal.

Gue juga belajar buat misahin build dan deployment job. Ngejalanin lima instance container di tiga server beda lebih baik kalo stage build selesai dulu dan deployment terjadi parallel setelahnya.

Buat environment variable, inject mereka sebelum build pake perintah echo ke file .env. Ini bikin secret tetep di luar Dockerfile sambil tetep tersedia waktu proses build Next.js.

before_script:
    - echo NEXT_PUBLIC_BASE_URL_API=$NEXT_PUBLIC_BASE_URL_API >> .env
    - echo NEXT_PUBLIC_API_KEY=$NEXT_PUBLIC_API_KEY >> .env
    # Env var tambahan

Pattern ini works perfect sama output standalone Next.js dan bikin Docker image kita tetep portable.

Kapan Lo Harus Beralih

Ga semua project butuh Docker Buildx dengan cloud builder sih. Kalo lo build sekali sehari dan punya banyak resource server, pendekatan tradisional masih oke aja.

Tapi kalo lo ada di salah satu situasi ini, migrasi masuk akal banget. Beberapa build harian yang rebutan resource. Waktu build lambat yang impact produktivitas developer. Butuh support multi platform image. Pengen ngurangin load dan panas server.

Buat tim yang pake GitLab CI/CD dengan Docker, integrasi nya seamless banget. Investasi buat belajar buildx bayar sendiri dengan cepet, apalagi kalo lo udah nyaman sama konsep Docker.

Langganan Docker Pro worth it waktu dan biaya infrastructure lo melebihi biaya bulanan. Buat use case gue, ROI nya jelas dalam minggu pertama aja.

Langkah Selanjutnya Lo

Mulai dengan test buildx secara lokal pake perintah docker buildx build. Verifikasi Dockerfile lo works dengan buildx builder. Terus bikin test pipeline di GitLab yang pake cloud driver.

Monitor beberapa build pertama lo dengan hati hati. Cek log, verifikasi image push, dan konfirmasi deployment sukses. Begitu stabil, migrate pipeline sisanya deh.

Inget buat update dokumentasi lo dan kasih tau tim lo tentang proses build yang baru. Perintah nya keliatan beda, dan troubleshoot cloud build butuh pemahaman arsitektur buildx.

Kombinasi GitLab CI/CD, Docker Buildx, dan Docker Build Cloud ngetransform workflow deployment kita banget. Build lebih cepet, load server lebih rendah, dan developer lebih happy. Itulah yang harusnya modern DevOps rasakan.

Infrastructure lo deserve lebih baik dari cuma nunggu build yang lambat. Coba Docker Buildx deh, dan liat waktu pipeline lo turun drastis.