- Unregistry adalah registry image container ringan yang menyimpan dan menyajikan image langsung dari penyimpanan Docker daemon, serta mengirim image langsung ke server Docker jarak jauh melalui SSH dengan perintah
docker pussh
- Opsi yang ada selama ini adalah Docker Hub/GitHub Container Registry, registry yang di-host sendiri,
docker save | ssh... docker load, atau rebuild jarak jauh; masing-masing punya masalah seperti repository publik/berbayar, beban operasional, pengiriman seluruh image, dan pemborosan resource server
docker pussh myapp:latest user@server membuat tunnel SSH, menjalankan container unregistry sementara di server jarak jauh, lalu melakukan docker push ke port localhost yang di-forward sehingga hanya layer yang belum ada di remote yang dikirim- Server jarak jauh memerlukan runtime Docker, izin untuk menjalankan perintah
docker, dan akses ke ghcr.io/psviderski/unregistry:latest saat pertama kali dijalankan; container unregistry berjalan sebagai root karena perlu mengakses /run/containerd/containerd.sock
- Jika containerd image store Docker diaktifkan, image yang dikirim bisa langsung digunakan oleh Docker dan penyimpanan ganda dapat dihindari, tetapi image dan container yang dibuat dengan classic storage driver yang sudah ada mungkin sementara tidak terlihat
Masalah deployment yang diselesaikan Unregistry
- Unregistry adalah registry image container ringan untuk memindahkan image Docker ke server jarak jauh tanpa registry eksternal
- Perintah plugin Docker CLI yang disertakan adalah
docker pussh, dengan tambahan huruf s pada namanya yang berarti SSH
- Saat memindahkan image Docker yang dibuat secara lokal ke server, opsi umum memiliki keterbatasan berikut
- Docker Hub / GitHub Container Registry: kode menjadi publik atau harus menanggung biaya repository private
- Self-hosted registry: muncul layanan terpisah yang membutuhkan maintenance, keamanan, dan biaya penyimpanan
- Save/Load:
docker save | ssh <remote server> docker load mengirim seluruh image meski 90% sudah ada di server
- Remote rebuild: memakai waktu dan resource server, dan Anda mungkin harus men-debug penyebab kegagalan build di production
Cara kerja docker pussh
- Penggunaan dasarnya adalah satu baris berikut
docker pussh myapp:latest user@server
- Perintah ini mengirim langsung melalui SSH hanya layer yang hilang, tanpa konfigurasi registry, subscription, penyimpanan perantara, atau port publik
- Cara kerja internalnya berjalan dalam urutan berikut
- Membuat tunnel SSH ke server jarak jauh
- Memulai container unregistry sementara di server
- Mem-forward port localhost acak melalui tunnel ke port unregistry
- Melakukan
docker push ke port yang di-forward untuk mengirim hanya layer yang belum ada di remote
- Image yang dikirim langsung bisa digunakan di Docker daemon jarak jauh
- Menghentikan container unregistry dan menutup tunnel SSH
- Proyek ini bertujuan menyediakan pengiriman yang sederhana dan efisien, seperti
rsync untuk image Docker
- Unregistry dibuat untuk Uncloud, alat ringan untuk men-deploy container ke beberapa host Docker, karena dibutuhkan cara yang lebih sederhana daripada registry penuh dan lebih efisien daripada save/load
Persyaratan dan batasan runtime
- Mesin lokal memerlukan dukungan plugin Docker CLI, Docker 19.03 atau lebih baru, serta klien OpenSSH
- Server jarak jauh harus sudah memasang Docker dan Docker harus sedang berjalan
- Pengguna SSH harus memiliki izin untuk menjalankan perintah
docker
- Pengguna harus
root atau pengguna non-root harus berada di grup docker
- Untuk dokumentasi terkait, lihat Manage Docker as a non-root user dari Docker
- Jika
sudo diperlukan, pengguna harus bisa menjalankan sudo docker tanpa prompt password
- Saat pertama kali menjalankan
docker pussh, server jarak jauh harus bisa mengambil image ghcr.io/psviderski/unregistry:latest dari ghcr.io
- Server yang memerlukan proxy harus dikonfigurasi mengikuti panduan Daemon proxy configuration dari Docker
- Di lingkungan air-gapped atau lingkungan dengan akses terbatas ke
ghcr.io, Anda dapat memeriksa versi image unregistry yang diperlukan lalu melakukan preload secara manual
- Container unregistry harus mengakses
/run/containerd/containerd.sock, sehingga dijalankan sebagai root untuk mendapatkan izin yang diperlukan
Instalasi dan platform yang didukung
- Di macOS/Linux,
docker-pussh dapat diinstal dengan Homebrew
brew install psviderski/tap/docker-pussh
- Setelah instalasi Homebrew, agar bisa memakai
docker pussh sebagai plugin Docker CLI, Anda harus membuat symbolic link ~/.docker/cli-plugins/docker-pussh
- Di macOS/Linux, metode download langsung juga tersedia
- Contoh versi saat ini adalah mengunduh skrip
docker-pussh versi v0.4.3 ke direktori plugin Docker dan memberinya izin eksekusi
- Metode untuk mengunduh skrip terbaru dari branch main juga tersedia
- Debian dapat diinstal melalui repository paket tidak resmi unregistry-debian yang dibuat dan dikelola oleh @dariogriffo
- Windows saat ini belum didukung, tetapi Anda dapat mencoba WSL 2 dan prosedur instalasi Linux
- Verifikasi instalasi dilakukan dengan perintah berikut
docker pussh --help
Konfigurasi containerd image store
Contoh penggunaan
- Pengiriman dasar hanya menentukan nama image dan target SSH jarak jauh
docker pussh myapp:latest user@server.example.com
- Jika private key belum terdaftar di SSH agent, Anda dapat menentukan key dengan
-i
docker pussh myapp:latest ubuntu@192.168.1.100 -i ~/.ssh/id_rsa
- Port SSH kustom ditentukan dengan menambahkan port setelah target
docker pussh myapp:latest user@server:2222
- File konfigurasi SSH kustom ditentukan dengan
-F
docker pussh myapp:latest prod-server -F ~/.ssh/config.prod
- Untuk melakukan push hanya platform tertentu dari image multi-platform, gunakan
--platform
docker pussh myapp:latest user@server --platform linux/amd64
- Untuk memakai versi image unregistry tertentu di host jarak jauh, tentukan variabel lingkungan
UNREGISTRY_IMAGE
UNREGISTRY_IMAGE=ghcr.io/psviderski/unregistry:A.B.C docker pussh myapp:latest user@server.example.com
Contoh use case utama
- Dalam deployment server production, image yang dibuild secara lokal dapat langsung di-push ke server dan dijalankan tanpa registry perantara
docker build --platform linux/amd64 -t myapp:1.2.3 .
docker pussh myapp:1.2.3 deploy@prod-server
ssh deploy@prod-server docker run -d myapp:1.2.3
- Dalam pipeline CI/CD, Anda dapat melewati kompleksitas registry dan mengirim image langsung ke target deployment
- name: Build and deploy
run: |
docker build -t myapp:${{ github.sha }} .
docker pussh myapp:${{ github.sha }} deploy@staging-server
- Di lingkungan homelab dan air-gapped, image dapat di-deploy di jaringan terisolasi yang tidak bisa mengakses registry publik melalui internet
Penggunaan lanjutan dan proyek terkait
- Unregistry juga dapat digunakan sebagai registry lokal standalone
- Mount
/run/containerd/containerd.sock dan jalankan container ghcr.io/psviderski/unregistry
- Setelah itu,
localhost:5000 dapat digunakan seperti registry biasa dengan docker tag dan docker push
- Konfigurasi SSH dapat memakai file config SSH standar atau meneruskan file config terpisah dengan
-F
- Tersedia proyek pihak ketiga terkait
- Implementasinya menyebut Spegel dan Docker Distribution
- Spegel adalah registry image container P2P yang menginspirasi implementasi registry yang memakai containerd image store sebagai backend
- Docker Distribution adalah implementasi Docker registry yang menjadi dasar unregistry
1 komentar
Komentar Hacker News
Sebagai orang yang membuat Docker, saya suka ini. Menurut saya desain idealnya dulu adalah satu server tunggal tanpa pemisahan antara Docker Engine dan registry
Jika bisa menyimpan, mengirim, dan menjalankan container sesuai kebutuhan, itu akan menjadi komponen yang jauh lebih kokoh, dan alur yang disayangkan ketika Engine dan registry menyimpan image dengan cara yang berbeda juga bisa dihindari
Selain itu, menurut saya setiap cluster produksi seharusnya punya penyimpanan image terdistribusi, dan mendorong image ke penyimpanan itu seharusnya memicu deployment. Cara sekarang—push ke registry, mengatur cluster, lalu tiap node menarik dari registry—rapuh dan tidak efisien. Saya mendorong desain yang lebih baik, tetapi momentumnya sudah terlalu besar, dan komunitas Kubernetes awal bersikap memusuhi ide-ide yang berasal dari Docker
Deployment dengan push ke cluster terlihat cerdas. Saya sedang memikirkan penyimpanan image terdistribusi dengan memasang unregistry di semua node agar mereka saling mengambil dan berbagi image, tetapi cara push yang memicu deployment masih perlu saya pikirkan lebih lanjut
Bagus. Perintah
pusshbenar-benar pantas diakui sebagai permainan kata yang elegan. Mudah diingat, maknanya langsung terlihat, dan hanya berbeda satu huruf dari perintah standar saudaranyadocker push-over-sshDalam otomasi yang dikembangkan secara kolaboratif,
pusshbisa terlihat seperti salah ketik bagi orang yang tidak tahu fungsinya, sehingga menimbulkan kebingungan yang tidak perlu. Sebaliknya,push-over-sshjelas merupakan nama yang disengaja. Anggap saja seperti opsi pendek dan opsi panjangstambahan itu adalahsdarisssh“Apa itu extra
s?”“Salah ketik”
Pada 2015, saya dengan naif mengirim PR[1] untuk memasukkan fitur ini ke arus utama Docker, tetapi dengan cepat diarahkan untuk membantu area lain. Membuat orang tidak perlu memakai registry mungkin terlalu mengguncang model bisnis Docker
[1]: https://github.com/richardcrichardc/docker2docker
Pada akhirnya saya rasa rencananya adalah beralih ke penyimpanan image containerd sebagai default. Jika penyimpanan image containerd dipakai baik lokal maupun remote, sepertinya hal yang dulu Anda implementasikan bisa dilakukan tanpa wrapper registry
Ini ide keren yang tampaknya cocok dengan sistem yang sudah memakai alat deployment berbasis push seperti Ansible. Untuk perusahaan yang tidak punya dukungan 24/7 untuk Docker registry, ini juga terlihat bisa dipakai sebagai mekanisme deployment hotfix yang bagus
Saya penasaran apakah ini terintegrasi rapi dengan alat OCI seperti buildah, atau butuh instalasi Docker penuh di kedua ujung. Saya belum melihatnya secara mendalam, tetapi dalam konfigurasi seperti ini, agar skopeo bisa berjalan, men-bootstrap mini registry di server remote terlihat seperti potongan yang hilang
Unregistry menggunakan ulang kode registry resmi Docker pada lapisan API, jadi tampilan dan perilakunya mirip dengan https://hub.docker.com/_/registry
Di client, Anda bisa memakai alat yang berbicara OCI registry seperti skopeo, crane, regclient, BuildKit, dan sebagainya. Namun untuk memakai alat-alat itu, Anda harus menjalankan unregistry secara manual di host remote. Perintah
docker pusshhanya mengotomatiskan alur itu memakai Docker lokalAnggap saja ini skrip Bash: https://github.com/psviderski/unregistry/blob/main/docker-pu...
Anda bisa dengan mudah mengubahnya sesuai cara yang diinginkan
Seharusnya memang begini sejak awal. Luar biasa
Docker registry memang ada kegunaannya, tetapi secara keseluruhan desainnya berlebihan dan berseberangan dengan semangat hacker
Butuh sekitar 20 menit untuk menyiapkan workflow
.yamlyang membangun dan mendorong image ke registry ghcr.io privat, lalu sekitar 5 menit agar server diizinkan mengambil image dari sana. Konfigurasi yang cukup praktisSaya sedang melihat pipeline yang membangun image di GitLab dan mendorongnya ke Artifactory, lalu deployment dipicu sehingga image diambil dari Artifactory dan didorong lagi ke AWS ECR, kemudian template deployment EKS diperbarui sehingga node mengambilnya dari ECR dan menjalankan container Pod
Saya membutuhkan ini dalam hidup saya
Dari sini saya jadi tahu tentang uncloud. Saya sedang mencari sesuatu yang seperti dokku tapi lebih kuat untuk konfigurasi server proyek sampingan, dan ini terasa pas seperti itu
Fitur stack-nya juga sangat bagus; pada dasarnya Docker Compose. Di satu instans EC2, Portainer Agent menjalankan Caddy di dalam container, dan Caddy berperan sebagai load balancer serta reverse proxy
Cukup aneh bahwa Docker sejak awal tidak bekerja seperti ini. Kelihatannya keren
Menyimpan arsip dilakukan seperti
docker save -o may-app.tar my-app:latest, dan memuatnya sepertidocker load -i /path/to/my-app.tarDengan alat seperti Ansible, pekerjaan yang diotomatisasi oleh “Unregistry” bisa dicapai dengan mudah. Menurut repositori GitHub-nya, kelemahan metode save/load adalah seluruh image ditransfer melalui jaringan, dan itu memang bisa menjadi masalah. Mengelola image itu sendiri, alih-alih file arsip, juga tampaknya lebih praktis
Proyek dan pendekatan yang rapi. Karena muak dengan registry yang mahal, saya akhirnya meng-host Zot[1] sendiri, tetapi untuk sebagian penggunaan ini tampaknya jauh lebih mudah
Saya penasaran apakah ada juga orang lain yang merasa akan bagus jika ada layanan registry privat yang mudah disetel, murah, dan ditagih berdasarkan pemakaian
[1]: https://zotregistry.dev
Ide yang bagus. Namun, mungkin ada kekurangan karena deployment menjadi terikat ke service. Misalnya, saya tidak tahu bagaimana menangani scale-out atau deployment red/green, dan sepertinya pihak yang melakukan hal seperti itu perlu mengetahui push-nya
Edit: ternyata yang melakukan itu adalah uncloud. Baru saja tahu
Tetap saja, ini trade-off. Kalau skalanya kecil, memakai satu VM Hetzner, puas dengan kesederhanaan, dan tidak masalah membangun image secara lokal, ini bagus