Belajar Wget - Ekosistem & Integrasi Tooling

#Pendahuluan

Di episode 19 kalian mengenal Wget2 dan fitur-fitur modern di kedua generasi wget. Sekarang kita keluar sejenak dari terminal dan melihat lebih luas: di mana saja wget hidup? Jawabannya: hampir di mana-mana. Di dalam image Docker yang kalian build setiap hari, di skrip provisioning server, di pipeline CI, dan di alur kerja verifikasi artefak yang ketat. wget sering "tak terlihat" justru karena ia adalah bagian yang paling bisa diandalkan — dan episode 20 ini akan membongkar posisi-posisi itu satu per satu.

#wget di Image Docker

Banyak image Linux minimal memakai wget — dan di sinilah perangkap pertama mengintai. Di Alpine Linux, perintah wget bawaan berasal dari BusyBox, bukan GNU Wget. Versi BusyBox itu jauh lebih kecil dan cepat, tapi juga jauh lebih terbatas — sering tanpa dukungan TLS yang lengkap, tanpa resume yang setara, dan tanpa banyak opsi yang sudah kalian kuasai di series ini.

Jika kalian butuh GNU Wget yang sesungguhnya, pasang secara eksplisit:

FROM alpine:3.20 AS download
RUN apk add --no-cache wget tar
RUN wget -q https://example.com/app/latest.tar.gz -O /app.tar.gz \
    && mkdir /out \
    && tar -xzf /app.tar.gz -C /out
 
FROM alpine:3.20 AS runtime
RUN apk add --no-cache ca-certificates
COPY --from=download /out/app /usr/local/bin/app
ENTRYPOINT ["app"]

Perhatikan pola multi-stage build di atas: stage pertama hanya bertugas mengunduh dan mengekstrak artefak, stage kedua adalah image runtime yang ramping. wget tidak pernah masuk ke image final — yang masuk hanya hasilnya. Ini membuat image produksi sekecil mungkin sekaligus memastikan artifact selalu segar saat build.

#wget di Pipeline CI/CD

Pipeline CI/CD adalah rumah kedua wget. Setiap kali kalian butuh artefak dari luar — binary tool, file migrasi, template, dataset — wget adalah perantara yang paling netral: tidak perlu library bahasa pemrograman, tidak perlu dependency, cukup satu perintah yang tersedia di semua runner.

jobs:
  fetch:
    runs-on: ubuntu-latest
    steps:
      - name: Unduh artefak
        run: |
          wget -q -P ./vendor https://example.com/tool-2.3.0.tar.gz
      - name: Verifikasi checksum
        run: |
          echo "${{ secrets.TOOL_SHA256 }}  ./vendor/tool-2.3.0.tar.gz" |
            sha256sum -c -

Perhatikan satu detail penting: nilai checksum tidak ditulis mentah di file workflow, melainkan diambil dari secrets. Ini menghindarkan dua masalah sekaligus — checksum yang berubah-ubah antar rilis tidak di-commit manual, dan nilai rahasia tidak tercetak di log pipeline. Wget mengangkut, CI yang menjaga integritasnya.

#wget di Skrip Provisioning

Sebelum Ansible, Terraform, dan teman-temannya, skrip shell adalah cara manusia menyiapkan server. Di dalam skrip itulah wget bekerja tanpa lelah: mengunduh binary, paket, dan konfigurasi dari sumber yang tepercaya.

apt-get update && apt-get install -y wget tar gnupg
wget -q -O /tmp/tool.deb https://example.com/tool_2.3.0.deb
dpkg -i /tmp/tool.deb

Pola ini adalah fondasi dari banyak package manager modern: unduh dari URL yang diketahui, verifikasi, lalu pasang. Wget unggul di sini karena non-interactive — ia tidak menunggu input manusia, sehingga aman dijalankan saat boot, di cron, dan di pipeline CI. Satu hal yang harus ditambahkan ke skrip semacam ini di produksi adalah verifikasi — kita akan membahasnya di episode 21.

#Perbandingan dengan Tool Lain

Wget hebat, tapi ia bukan jawaban untuk semua hal. Berikut peta cepat posisi wget di antara tool-tool tetangganya:

Mari bedah satu per satu. curl adalah "saudara" wget yang lebih banyak bicara — ia memberi kontrol penuh atas metode HTTP, header, dan body, sehingga paling cocok untuk ngobrol dengan API. httrack adalah wget dengan dashboard GUI untuk kebutuhan mirroring serius skala besar. aria2 memecah satu file menjadi beberapa koneksi paralel sekaligus — mengalahkan wget dalam hal kecepatan unduh file tunggal, terutama dari server yang membatasi kecepatan per koneksi. yt-dlp memecahkan masalah yang tidak bisa disentuh wget: mengekstrak video yang tersembunyi di balik halaman pemutar streaming.

Pola yang perlu kalian lihat: wget memenangkan kategori kesederhanaan dan otomasi. Ia bukan yang paling cepat, bukan yang paling kaya fitur — tapi ia adalah alat yang tepat untuk pekerjaan yang berulang, tanpa interaksi, dan bisa dipertanggungjawabkan.

#wget + Verifikasi Tanda Tangan GPG

Alur kerja development yang serius tidak pernah memakai file yang diunduh mentah-mentah. Jika proyek menandatangani rilisnya, verifikasi adalah gerbang wajib — terutama untuk file biner. Wget mengunduh artefak dan tanda tangannya, lalu gpg yang berbicara:

wget https://example.com/app-2.3.0.tar.gz
wget https://example.com/app-2.3.0.tar.gz.sig
gpg --keyserver keys.openpgp.org --recv-keys 0x1234ABCD
gpg --verify app-2.3.0.tar.gz.sig app-2.3.0.tar.gz

Tiga langkah itu adalah ritme yang sama di hampir semua rilis perangkat lunak terbuka. gpg --verify sukses berarti file benar-benar berasal dari pemegang kunci — bukan dari penyerang yang menyamar di tengah jaringan. Kombinasi ini, wget + gpg, adalah cara memindahkan kepercayaan: wget mengangkut, gpg mengautentikasi.

#wget + tar / unzip: Menyiapkan Artefak

Setelah unduh, artefak perlu dibongkar. Pasangan wget + tar atau unzip adalah ritual yang terjadi ribuan kali setiap hari di CI: unduh arsip, verifikasi checksum, lalu ekstrak.

wget https://example.com/tool-2.3.0.zip
echo "deadbeefcafe1234  tool-2.3.0.zip" | sha256sum -c -
unzip tool-2.3.0.zip -d tools/

Baris sha256sum -c - membaca checksum yang diharapkan dari stdin dan membandingkannya dengan file yang diunduh. Jika berbeda, perintah keluar non-zero dan proses dihentikan — inilah gerbang keamanan yang mencegah artefak rusak atau terintervensi masuk ke build. Ritual yang sama berlaku untuk .tar.gz dengan tar -xzf.

#wget untuk Distribusi Biner dan Update

Satu peran wget yang sering diabaikan: jalur distribusi biner itu sendiri. Banyak tool CLI mendistribusikan pembaruan dengan pola sederhana: unduh file latest atau file manifest versi, bandingkan dengan versi lokal, lalu ganti binary.

wget -q -N https://cdn.example.com/cli/latest/manifest.json

Flag -N (timestamping) yang kalian pelajari di episode 15 bekerja sempurna di sini: wget hanya mengunduh jika versi server lebih baru dari file lokal. Dengan pola ini, satu perintah wget menjadi mesin update yang sederhana dan dapat dijadwalkan — tanpa daemon, tanpa service, tanpa kompleksitas. Inilah keindahan wget: satu baris yang tenang, menjalankan seluruh proses distribusi software.

#Penutup

Episode 20 menempatkan wget dalam ekosistem yang lebih luas: perannya di image Docker dan skrip provisioning, peta posisi wget dibanding curl, httrack, aria2, dan yt-dlp, serta alur kerja development yang memanfaatkannya — verifikasi GPG, pembongkaran artefak dengan tar dan unzip, hingga distribusi biner dan update.

Inti yang harus dibawa pulang: wget adalah pemain tim yang hebat. Ia jarang menjadi pusat perhatian, tapi di balik setiap build container, setiap provisioning, dan setiap pipeline CI, ada wget yang mengangkut artefak dengan setia. Kehebatan itu baru terasa ketika koneksinya gagal di tengah malam — dan itulah topik kita selanjutnya.

Di episode 21 berikutnya kita akan menaikkan semuanya ke level produksi: production readiness & security hardening — verifikasi TLS, checksum, dan GPG yang benar, pembatasan crawl, pengelolaan .netrc yang aman, hingga checklist keamanan untuk download otomatis. Sampai jumpa!