Skip to content
VDS · Docker ও কনটেইনার

আপনার নিজের ইমেজ রেজিস্ট্রি

কখন নিজের রেজিস্ট্রি দরকার, পাসওয়ার্ড ও সার্টিফিকেট দিয়ে কীভাবে সেট আপ করবেন, এটি কত ডিস্ক নেয়, এবং পুরনো ইমেজের ডাম্পে পরিণত হওয়া থেকে কীভাবে বাঁচবেন।

আপডেট: ২৩ আগস্ট, ২০২৬

একটি রেজিস্ট্রি হলো ইমেজের ভান্ডার। তিনটি ক্ষেত্রে আপনার নিজের রেজিস্ট্রি প্রয়োজন: ইমেজগুলো প্রাইভেট এবং আপনার ইনফ্রাস্ট্রাকচার ছেড়ে বাইরে যাওয়া উচিত নয়, বিল্ড ঘন ঘন হয় এবং এক্সটার্নাল ডাউনলোড লিমিট বাধা হয়ে দাঁড়ায়, অথবা আপনি একই জিনিস একাধিক মেশিনে ডিপ্লয় করেন।

সহজ বিকল্প: registry:2

services:
  registry:
    image: registry:2
    restart: unless-stopped
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth:ro
    ports:
      - "127.0.0.1:5000:5000"

পাসওয়ার্ড এভাবে তৈরি করুন:

mkdir -p auth
docker run --rm --entrypoint htpasswd httpd:2 -Bbn deploy 'long-password' > auth/htpasswd
docker compose up -d

পোর্ট বাইরে এক্সপোজ করবেন না: রেজিস্ট্রির সামনে সার্টিফিকেটসহ একটি ওয়েব সার্ভার বসে। Docker HTTP-এর মাধ্যমে থার্ড-পার্টি রেজিস্ট্রির সাথে কাজ করতে অস্বীকার করে — এবং যথার্থই, কারণ এর মাধ্যমেই আপনার মেশিনগুলোতে এক্সিকিউটেবল কোড পৌঁছায়।

এটি নিয়ে কাজ করা

docker login registry.example.com
docker tag myapp:1.5.0 registry.example.com/myapp:1.5.0
docker push registry.example.com/myapp:1.5.0
docker pull registry.example.com/myapp:1.5.0

curl -u deploy https://registry.example.com/v2/_catalog
curl -u deploy https://registry.example.com/v2/myapp/tags/list

docker login করার পর ক্রেডেনশিয়ালগুলো ~/.docker/config.json-এ প্লেইন টেক্সটে থাকে (base64 কোনো এনক্রিপশন নয়)। বিল্ড মেশিনে read-only অধিকারসহ একটি আলাদা অ্যাকাউন্ট তৈরি করুন।

সাইজ লিমিট ও ক্লিনআপ ছাড়া একটি রেজিস্ট্রি ডিস্ক ভরে ফেলার দ্রুততম উপায়। প্রতিটি বিল্ড লেয়ার যোগ করে, আর একটি ট্যাগ ডিলিট করলে জায়গা খালি হয় না: আপনার প্রয়োজন গার্বেজ কালেকশন। ৪০ GB-এর VDS-1-এ একটি সক্রিয় প্রজেক্টের রেজিস্ট্রি কয়েক সপ্তাহেই ডিস্ক ভরে ফেলবে।

ক্লিনআপ

একটি ট্যাগ ডিলিট করা এবং তারপরের গার্বেজ কালেকশন:

docker compose exec registry registry garbage-collect \
  --delete-untagged /etc/docker/registry/config.yml

গার্বেজ কালেকশন চলার সময় আপনাকে অবশ্যই রেজিস্ট্রি বন্ধ করতে হবে — নাহলে একই সময়ে চলা একটি push লেয়ার হারাতে পারে:

docker compose stop registry
docker compose run --rm registry registry garbage-collect --delete-untagged /etc/docker/registry/config.yml
docker compose start registry

এটি সপ্তাহে একবার একটি শিডিউলড জব হিসেবে সেট করুন এবং ডিস্ক স্পেস নজরে রাখুন।

বিকল্প: Git সার্ভারের সাথে বান্ডল করা রেজিস্ট্রি

আপনি যদি ইতিমধ্যে Forgejo বা Gitea সেট আপ করে থাকেন, তাদের বিল্ট-ইন প্যাকেজ স্টোর আছে, যার মধ্যে Docker ইমেজও রয়েছে। আলাদা সার্ভিসের প্রয়োজন নেই: অ্যাক্সেস একই অ্যাকাউন্টের মাধ্যমে হয়, আর ইমেজগুলো কোডের পাশেই দেখা যায়। ছোট প্রজেক্টের জন্য এটি একটি স্ট্যান্ডঅ্যালোন registry:2-এর চেয়ে বেশি সুবিধাজনক।

সাধারণ ভুল

  • রেজিস্ট্রি অনুমোদন ছাড়াই খোলা। এর মাধ্যমে কেউ এমন একটি ইমেজ বসাতে পারে যা আপনার নিজের প্রোডাকশন মেশিনে ডিপ্লয় হবে।
  • ভার্সনের বদলে latest ট্যাগ। রেজিস্ট্রি আর পুনরুৎপাদনযোগ্যতার উৎস থাকে না: ঠিক কী ডিপ্লয় হয়েছে তা স্পষ্ট নয়। দেখুন কনটেইনার আপডেট।
  • ডেটাবেসের মতো একই ডিস্কে স্টোরেজ। push-এর হঠাৎ বৃদ্ধি ডিস্ক ব্যান্ডউইথ খেয়ে ফেলে এবং প্রোডাকশন সার্ভিস ধীর করে দেয় — দেখুন ডিস্ক স্পিড।
  • ./data ডিরেক্টরি আপনার ব্যাকআপে নেই। যে সব ইমেজের সোর্স হাতের কাছে নেই, সেগুলো আপনি হারাবেন। দেখুন কী ব্যাক আপ করবেন।