يُعرّف سجل دوكر Docker Registry بأنه تطبيق يُدّير عمليات تخزين صور حاويات Docker وتسليمها للمطورين، حيث تكون صور الحاويات متاحة أمامهم في سجلٍ مركزي واحد ومُضمّن فيها جميع المكونات الضرورية لعملها، وفي هذا استثمارٌ كبير لوقت المطوّر، إذ تكفل صور دوكر بيئة تشغيل مماثلة لمتطلباته عبر المحاكاة الافتراضية، وبهذا يمكن للمطور سحب الصورة التي يحتاجها من السجل مع كل ما يلزم وتنزيلها بهيئة مضغوطة، بدلًا من تنزيل الاعتماديات والحزم واحدة واحدة وتثبيتها داخل الحاوية في كل مرة، وبالمثل أيضًا يستطيع المطوّر أتمتة عمليات نشر الصور على السجل باستخدام أدوات التكامل المستمر (CI) مثل TravisCI أو غيرها لتحديث صوره باستمرار في مراحل التطوير والإنتاج.
قد تكون سجلات Docker عامة أو خاصة ولعل Docker Hub هو أبرز مثال على سجلات دوكر العامة، فهو مجاني ومتاح للجميع ويمكنك تخصيص صورك حسب احتياجات عملك واستضافتها عليه، وإذا رغبت بمستوى أعلى من السرية والخصوصية فيمكنك استخدام سجل خاص بك فهو الخيار الأفضل للتطبيقات مغلقة المصدر، إذ تتضمن الصور عادةً جميع التعليمات البرمجية اللازمة لعمل التطبيق، ويبقيها السجل الخاص في متناول مجموعة محددة من الأشخاص فقط.
سنشرح لك في هذا المقال كيفية إعداد سجلك الخاص لصور حاويات Docker، وطريقة تأمينه، واستخدام كل من Docker Compose لضبط إعدادات التحكم بتشغيل الحاويات، وخادم Nginx لتوجيه حركة مرور البيانات القادمة من الإنترنت إلى حاوية Docker قيد التشغيل. وستمتلك في النهاية المعرفة الكافية لرفع صورة Docker إلى سجلك الخاص، وسحب الصور بأمان من خادمٍ بعيد.
متطلبات العمل
ستحتاج لتوفير المتطلبات التالية لتتابع معنا سير العمل خطوة بخطوة:
-
خادمين مثبت عليهما نظام تشغيل أوبنتو (الإصدار 22.04 )، ويمكنك اتباع هذا الدليل لتجهيزهما، حيث يتضمن هذا الدليل طريقة إنشاء مستخدم جديد غير مستخدم الجذر لكنه يتمتع بصلاحيات
sudo
بالإضافة إلى آلية إعداد جدار الحماية للخادم، احرص على تنفيذ هذه الخطوات إذ سيستضيف أحد الخادمين سجل Docker الخاص بك وسنسميه الخادم المضيف host، وسيكون الخادم الآخر عميلًا client يستخدم السجل. -
تثبيت Docker على الخادمين، تساعدك الخطوتان 1 و 2 من مقال كيفية تثبيت دوكر واستخدامه على دبيان في تنفيذ المطلوب فتثبيت Docker على دبيان يشبه تثبيته على أوبنتو.
اضبط بعد ذلك الإعدادات التالية على الخادم المضيف:
-
ثبّت عليه دوكر كومبوزر Docker Compose مستعينًا بالخطوات الواردة في مقال تثبيت الأداة دوكر كومبوز Docker Compose واستخدامها ضمن نظام لينكس أوبونتو.
-
ثبّت عليه إنجن إكس Nginx بإتباع الإرشادات الواردة في مقال كيفية تثبيت Nginx على أوبونتو 18.04.
-
أمّن حماية الخادم Nginx الموجود على المضيف بشهادات مصدقة من Let’s Encrypt مثلًا لحماية سجل Docker الخاص الذي تنشؤه، اطلّع على مقال كيف تؤمّن خادم ويب NGINX على أوبنتو 16.04 على أكاديمية حسوب أو مقال تأمين خادم NGINX باستخدام Let’s Encrypt على DigitalOcean لإنجاز هذه الخطوة. وتأكد من توجيه حركة مرور البيانات الواردة إلى تطبيقك من HTTP إلى HTTPS.
-
احجز اسم نطاق لخادمك المضيف لسجل Docker، واسم النطاق المعتمد في المقال هو
your_domain
، وتوفير اسم النطاق ضروري قبل البدء بإعدادات خدمة Let’s Encrypt.
الخطوة 1: تثبيت سجل Docker وإعداده
يفيدك تشغيل Docker من سطر الأوامر في بداية التشغيل وعند اختبار الحاويات، لكن استمرارك باستخدامه من سطر الأوامر لن يكون عمليًّا مع تقدم سير العمل، وبالأخص في عمليات النشر واسعة النطاق أو تلك التي تتطلب التحكم بعدة حاويات تعمل معًا على التوازي.
لذا يستخدم المطورون أداة Docker Compose، حيث تكتب ملف yml.
واحد لكل حاوية يتضمن إعداداتها والمعلومات التي تحتاجها للتواصل مع بقية الحاويات. ويمكنك استخدام تعليمة docker compose
لتطبيق الأوامر دفعةً واحدة على جميع الأجزاء المكوّنة لتطبيقك والتحكم بها على أنها مجموعة.
تُستخدم أداة Docker Compose أيضًا لإدارة سجل دوكر ومكوناته فهو تطبيق في نهاية الأمر ويتكون من عدة أجزاء.
لتشغيل مثيل instance لسجل Docker على Docker Compose عليك إعداد الملف docker-compose.yml
لتعريف السجل، وتوفير مساحة تخزينية له على القرص الصلب ليُخزّن البيانات.
أنشئ في البداية مجلدًا اسمه docker-registry
على الخادم المضيف وفق التالي، إذ سنُخزّن فيه إعدادات السجل:
$ mkdir ~/docker-registry
انتقل إلى المجلد الجديد بكتابة التالي:
$ cd ~/docker-registry
وأنشئ بداخله مجلدًا فرعيًّا باسم data
، وفق الأمر التالي حيث سيُخزّن السجل صور الحاويات بداخله:
$ mkdir data
أنشئ أيضًا ملفًا نصيًّا باسم docker-compose.yml
باستعمال محرر نصوص مثل نانو كما يلي:
$ nano docker-compose.yml
واكتب ضمنه المعلومات التالية، التي تُعرّف المثيل الأساسي لسجل Docker:
version: '3' services: registry: image: registry:latest ports: - "5000:5000" environment: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data volumes: - ./data:/data
لنشرح المعلومات السابقة، عرّفنا في البداية خدمةً جديدة باسم registry
، وحددنا الصورة التي ستُبنى انطلاقًا منها وهي registry
، أما الكلمة latest فتعني أنك تطلب استخدام أحدث إصدار متوفر من الصورة، وفي القسم التالي وجهّنا المنفذ port رقم 5000
على الخادم المضيف إلى المنفذ 5000
على الحاوية، وذلك يعني أن الطلبات الواردة إلى المنفذ 5000
على الخادم سترسل مباشرةً إلى السجل.
أما في قسم بيئة العمل environment
فقد أسندنا القيمة data/
للمتغير REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
وهو المسؤول عن تحديد المجلد المخصص لتخزين بيانات السجل. وفي القسم volumes
وصلنا المجلد data/
على نظام ملفات الخادم المضيف بالمجلد data/
داخل الحاوية، الذي يُعدّ بمثابة معبر فقط إذ ستُخزّن البيانات فعليًّا على الخادم المضيف.
احفظ التغييرات على الملف، وأغلقه وشغّل الآن الإعدادات بتنفيذ الأمر التالي:
$ docker compose up
سيبدأ تحميل حاوية السجل مع اعتمادياتها، وستصبح في وضع التشغيل، ثم ستحصل على خرج يشبه التالي:
[+] Running 2/2 ⠿ Network docker-registry_default Created 0.1s ⠿ Container docker-registry-registry-1 Created 0.1s Attaching to docker-registry-registry-1 docker-registry-registry-1 | time="2024-01-19T14:31:20.40444638Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.404960549Z" level=info msg="redis not configured" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.412312462Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.412803878Z" level=info msg="Starting upload purge in 52m0s" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.41296431Z" level=info msg="listening on [::]:5000" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" ...
يتضمن الخرج السابق رسالة تحذير مفادها عدم توفر اتصال HTTP آمن No HTTP secret provided
، لا تقلق سنعالجها في الفقرات القادمة.
إذا دققت في السطر الأخير، ستجده يعلمك بإتمام عملية التشغيل بنجاح، وبأن السجل جاهز لاستقبال الطلبات على المنفذ 5000
.
يمكنك الآن الضغط على CTRL+C
لإيقاف التنفيذ.
إذًا فقد أنشأنا في هذه الخطوة إعدادات Docker Compose التي شغّلت سجل Docker على المنفذ 5000
، وسنعمل في الخطوات التالية على استعراضه باسم النطاق المخصص له، وعلى ضبط إعدادات المصادقة Authentication للتحكم بصلاحية الوصول إليه.
الخطوة 2: ضبط إعدادات التوجيه لمنفذ Nginx
ذكرنا في بداية المقال أن تفعيل بروتوكول HTTPS على اسم نطاقك هو أحد متطلبات العمل الأولية، وسنعمل الآن على توجيه حركة مرور البيانات من اسم النطاق إلى حاوية السجل لنضمن أن الوصول لسجل Docker سيجري عبر اتصالٍ آمن.
لابد أنك جهزت الملف etc/nginx/sites-available/your_domain/
أثناء إعدادك لخادم Nginx، إذ يحتوى هذا الملف على قسمٍ خاص بإعدادات الخادم، افتحه بواسطة أي محرر نصوص وفق التالي، لنجري عليه بعض التعديلات:
$ sudo nano /etc/nginx/sites-available/your_domain
ابحث ضمنه عن القسم المسمى location
:
... location / { ... } ...
المطلوب في حالتنا أمران: توجيه حركة مرور البيانات إلى المنفذ 5000
الذي يتلقى السجل عبره الطلبات، وإضافة ترويسات headers للطلبات الموجهة إلى السجل تحتوي معلوماتٍ إضافية عنها يضيفها الخادم. استبدل محتوى القسم location
بالتالي لتنفيذهما:
... location / { # Do not allow connections from docker 1.5 and earlier # docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) { return 404; } proxy_pass http://localhost:5000; proxy_set_header Host $http_host; # required for docker client's sake proxy_set_header X-Real-IP $remote_addr; # pass on real client's IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 900; } ...
تتأكد الجملة if
من توفر عدة شروط قبل أن تسمح للطلب بالمرور إلى السجل، فتتحقق من وكيل المستخدم صاحب الطلب User Agent، ومن كون إصدار Docker الذي يستعمله أعلى من 1.5، ومن أنه ليس تطبيق مبرمج بلغة Go
ويسعى للوصول إلى السجل. يمكنك معرفة المزيد عن ترويسة nginx
بمراجعة دليل إعداد Ngin لسجل Docker من توثيقات Docker الرسمية.
احفظ التغييرات على الملف، وأعِد تشغيل Nginx بكتابة التعليمة التالية، حتى تأخذ التغييرات مفعولها:
$ sudo systemctl restart nginx
إذا حصلت على أي رسالة خطأ تفيد بعدم نجاح عملية إعادة التشغيل، فتحقق مجددًا من صحة التعديلات التي أجريتها على الملف.
سنشغل السجل الآن لنتأكد من توجيه Nginx الطلبات الواردة إلى حاوية السجل، اكتب الأمر التالي:
$ docker compose up
استعرض العنوان التالي في متصفحك، والذي يتضمن اسم النطاق يليه v2
نقطة الوصول endpoint:
https://your_domain/v2
سيعرض لك المتصفح كائن JSON فارغ على الشكل:
وستحصل في الطرفية على الخرج التالي:
docker-registry-registry-1 | time="2024-01-19T14:32:50.082396361Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=779fe265-1a7c-4a15-8ae4-eeb5fc35de98 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="text/html; charset=utf-8" http.response.duration="162.546µs" http.response.status=301 http.response.written=39 docker-registry-registry-1 | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2 HTTP/1.0" 301 39 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" docker-registry-registry-1 | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2/ HTTP/1.0" 200 2 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" docker-registry-registry-1 | time="2024-01-19T14:32:50.132472674Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=0ffb17f0-c2a0-49d6-94f3-af046cfb96e5 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.429608ms http.response.status=200 http.response.written=2
يخبرك السطر الأخير أن الطلب GET
قد وصل إلى نقطة الوصول /v2/
المذكورة في العنوان الذي طلبته من المتصفح، واستقبلته حاوية السجل (بفضل إعدادات التوجيه التي عملنا عليها) وأرسلت استجابة بكائن JSON {}
مع رمز الاستجابة 200
الذي يشير لنجاح العملية.
اضغط الآن CTRL+C
لإيقاف التنفيذ.
أنهينا بذلك إعدادات التوجيه وننتقل لإعدادات تأمين السجل.
الخطوة 3: ضبط إعدادات المصادقة Authentication
يتيح Nginx لمستخدمه إعداد آلية مصادقة Authentication باسم مستخدم وكلمة مرور لتقييد الوصول إلى مواقعهم المستضافة عليه وذلك بإنشاء ملف مصادقة htpasswd
وكتابة أسماء المستخدمين المسموح له بالوصول إليه مع كلمات مرورهم. سنستخدم هذه الآلية هنا لحماية سجل Docker.
يمكنك الحصول على الأداة htpasswd
بتثبيت الحزمة apache2-utils
وفق الأمر التالي:
$ sudo apt install apache2-utils -y
سننشئ الآن المجلد docker-registry/auth/~
لتخزين ملف المصادقة الذي يتضمن بيانات الاعتماد، وفق ما يلي:
$ mkdir ~/docker-registry/auth
انتقل للمجلد الجديد بكتابة التالي:
$ cd ~/docker-registry/auth
نفذّ الأمر المبين أدناه لإنشاء المستخدم الأول، واستبدل العبارة username
باسم المستخدم الفعلي، واحرص على كتابة الراية B-
فهي مسؤولة عن تفعيل خاصية التشفير bcrypt
التي تشترطها Docker:
$ htpasswd -Bc registry.password username
سيُطلب منك إدخال كلمة المرور الخاصة بهذا المستخدم، أدخلها بدقة. وستخزن بيانات الاعتماد هذه التي أدخلتها في registry.password
.
ملاحظة: أعِدّ تنفيذ الأمر السابق بدون الراية c-
لإضافة مستخدمين آخرين إلى الملف وفق التالي:
$ htpasswd -B registry.password username
إذ تشير الراية c-
إلى إنشاء ملف جديد، وتعني إزالتها التعديل على الملف الحالي (أي إضافة مستخدمين جدد).
عدّل الآن الملف docker-compose.yml
ليستخدم Docker ملف بيانات الاعتماد -الذي أنشأناه- لإجراء المصادقة مع المستخدمين للتحقق من هوياتهم. افتح أولًا الملف بكتابة التالي:
$ nano ~/docker-registry/docker-compose.yml
أضف الأجزاء المتعلقة بالمصادقة إلى محتواه، ليصبح كما يلي:
version: '3' services: registry: image: registry:latest ports: - "5000:5000" environment: REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry REGISTRY_AUTH_HTPASSWD_PATH: /auth/registry.password REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data volumes: - ./auth:/auth - ./data:/data
أضفت بهذه التعديلات بعض المتغيرات إلى متغيرات البيئة لفرض استخدام المصادقة مع بروتوكول HTTP، ولتوفير مسار الملف htpasswd
. فقد حدد المتغير REGISTRY_AUTH
الذي يحمل القيمة htpasswd
مخطط المصادقة المستخدم أو authentication scheme، وأُسندت القيمة التي تدل على مسار ملف المصادقة إلى المتغير REGISTRY_AUTH_HTPASSWD_PATH
، أما المتغير REGISTRY_AUTH_HTPASSWD_REALM
فيوضح نطاق تنفيذ المصادقة htpasswd
.
وفي السطر ما قبل الأخير وصلت المجلد auth/.
إلى داخل حاوية السجل ليكون متاحًا ضمنها. احفظ التغييرات على الملف وأغلقه.
ودعنا نتأكد من استخدام السجل لإجراء المصادقة. توجه في البداية إلى مجلد السجل الأساسي بكتابة الأمر:
$ cd ~/docker-registry
شغّل السجل بتنفيذ ما يلي:
$ docker compose up
حدّث الصفحة في متصفح الويب إذا كان ما يزال مفتوحًا لديك، أو اطلب مجددًا اسم النطاق الذي حددته للسجل، ولاحظ الفرق. سيطلب منك في هذه المرة اسم مستخدم وكلمة مرور.
أدخل البيانات الصحيحة وستحصل على الخرج السابق نفسه، كائن JSON فارغ كما يلي، وهو ما يشير لصحة التنفيذ:
نجحت إذا عملية المصادقة وسُمح لك بالوصول للسجل بعد إدخال بيانات الاعتماد الصحيحة. يمكنك الخروج بالضغط على CTRL+C
في نافذة الطرفية.
خطوتنا التالية هي تحويل السجل إلى خدمة تعمل في الخلفية، وتقلع تلقائيًا، مع الإبقاء على المرونة التي تسمح لنا بإعادة تشغيلها.
الخطوة 4: بدء تشغيل سجل Docker بصفته خدمة
يعني تحويل سجل Docker إلى خدمة ضبط بعض الإعدادات في Docker Compose لإبقاء حاوية السجل في وضع التشغيل دائمًا، فتُقلع تلقائيًا مع إقلاع نظام التشغيل، ويُعاد تشغيلها بعد أي عطل.
اكتب الأمر التالي، وافتح الملف docker-compose.yml
لنجري عليه بعض التعديلات:
$ nano docker-compose.yml
ابحث ضمن الملف عن قسم السجل المسمى registry
، واكتب تحته السطر التالي:
... registry: restart: always ...
يعني ضبط المحدد restart
على القيمة always
أن حاوية السجل سيُعاد تشغيلها دائمًا بعد أي طارئ يسبب إيقافها. احفظ الآن التغييرات على الملف، وأغلقه لننتقل إلى الإجراء التالي.
اكتب الأمر المبين أدناه لبدء تشغيل حاوية السجل بصفتها عملية تعمل في الخلفية background process، وذلك بتمرير الراية d-
:
$ docker compose up -d
يمكنك إغلاق جلسة SSH والاطمئنان بأن حاوية السجل لن تتوقف فهي الآن تعمل في الخلفية.
ستتناول الخطوة التالية زيادة حجم الملفات التي يُسمح برفعها على خادم Nginx ليناسب حجوم صور الحاويات التي ستحفظ على السجل.
الخطوة 5: زيادة حجم الملفات المسموح رفعها على Nginx
الحجم الأعظمي المسموح رفعه على خادم Nginx افتراضيًا هو 1m
أي 1 ميجا بايت للملف الواحد، ويُعدّ صغيرًا نسبيًا موازنةً بحجوم صور الحاويات، لذا يتحتم علينا تغيره قبل البدء برفع الصور إلى السجل. يمكنك تغييره بتعديل قيمته في ملف إعدادات Nginx الموجود في المسار etc/nginx/nginx.conf/
.
افتح ملف إعدادات Nginx بكتابة الأمر التالي:
$ sudo nano /etc/nginx/nginx.conf
أضف السطر التالي إلى القسم http
ضمنه:
... http { client_max_body_size 16384m; ... } ...
زدنا بهذا التعديل الحجم الأعظمي للملف المسموح برفعه إلى 16 جيجا بايت، وذلك بضبط قيمة المحدد client_max_body_size
على 16384m
.
احفظ التغييرات على الملف وأغلقه.
أعِدّ تشغيل الخادم Nginx لتأخذ التغييرات مفعولها، وفق التالي:
$ sudo systemctl restart nginx
يمكنك الآن رفع الصور إلى السجلات بدون أي أخطاء تتعلق بالحجم من Nginx.
الخطوة 6: نشر صور الحاويات على سجل Docker الخاص
أصبح خادم السجل قادرًا على استيعاب الملفات كبيرة الحجم، لذا سنجرب نشر صورة تجريبية عليه، فإذا لم يتوفر لديك أي صورة لرفعها، يمكنك تحميل صورة أوبنتو من Docker Hub (سجل Docker العام) لتجرب نشرها على هذا السجل.
افتح جلسة طرفية جديدة على الخادم العميل، ونفذّ الأمر المبين أدناه لتحميل صورة الحاوية ubuntu
وتشغيلها (تذكر أننا طلبنا وجود خادمين ضمن المتطلبات الأولية خادم مضيف وخادم عميل):
$ docker run -t -i ubuntu /bin/bash
تمنحك الرايتان t-
و i-
واجهة صدفة shell تفاعلية لتُنفذ بواسطتها الأوامر داخل حاوية أوبنتو.
أنشئ الآن ملفًا يدعى SUCCESS
داخل حاوية أوبنتو وفق التالي:
root@f7e13d5464d1:/# touch /SUCCESS
أنشأنا هذا الملف داخل الحاوية كنوع من التخصيص لتمييزها عن غيرها، فيمكننا لاحقًا استعراضه للتأكد من استخدامنا الحاوية الصحيحة.
اخرج من صدفة الحاوية بكتابة التالي:
root@f7e13d5464d1:/# exit
أنشئ الآن صورة عن هذه الحاوية بعد تخصيصها، بكتابة الأمر التالي:
$ docker commit $(docker ps -lq) test-image
أصبح لديك صورة عن حاوية أوبنتو المخصصة محفوظة محليًا على خادمك، سجِّل دخول إلى سجل Docker وفق التالي لنحاول نشرها عليه:
$ docker login https://your_domain
سيُطلب منك إدخال اسم مستخدم وكلمة مرور، أدخل بيانات أحد المستخدمين الذين أنشأتهم في الخطوة 3 قبل قليل، وستحصل على الخرج التالي:
Login Succeeded
بعد تسجيل الدخول بنجاح عدّل تسمية صورة الحاوية كما يلي:
$ docker tag test-image your_domain/test-image
انشرها الآن على سجلك بكتابة الأمر التالي:
$ docker push your_domain/test-image
وستحصل على خرج يشبه ما يلي يؤكد لك نجاح العملية:
Using default tag: latest The push refers to a repository [your_domain/test-image] 1cf9c9034825: Pushed f4a670ac65b6: Pushed latest: digest: sha256:95112d0af51e5470d74ead77932954baca3053e04d201ac4639bdf46d5cd515b size: 736
إذًا فقد نشرنا صورة حاوية Docker على السجل الخاص، وتأكدنا من فعالية عملية المصادقة، إذ لم نتمكن من الوصول للسجل والنشر عليه بدون إدخال اسم مستخدم وكلمة مرور صحيحين، لنختبر الآن سحب الصور من السجل.
سحب الصور من سجل Docker الخاص
سنحاول سحب الصورة نفسها التي نشرتها على السجل في الخطوة السابقة.
اكتب الأمر التالي، وسجل دخول إلى سجل Docker من الخادم الرئيسي باستخدام بيانات المستخدمين الذين أنشأتهم سابقًا:
$ docker login https://your_domain
جرّب سحب الصورة test-image
من السجل كما يلي:
$ docker pull your_domain/test-image
حمَّل Docker الآن هذه الصورة إلى خادمك المحلي، شغّل حاوية جديدة باستخدامها عبر كتابة ما يلي:
$ docker run -it your_domain/test-image /bin/bash
يوفر لنا هذا الأمر صدفة shell تفاعلية مع الحاوية المُشغّلة.
اكتب ضمنها الأمر التالي لنستعرض نظام ملفاتها:
root@f7e13d5464d1:/# ls
لاحظ الخرج التالي، إنه يتضمن الملف SUCCESS
الذي أنشأناه قبلًا لتمييز صورة الحاوية قبل نشرها على السجل، وهذا يؤكد أن الحاوية المُشغّلة حاليًّا مبنية على الصورة نفسها المسحوبة من السجل:
root@f7e13d5464d1:/# SUCCESS bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
اخرج الآن من صدفة الحاوية بكتابة الأمر التالي:
$ exit
أنهينا بذلك إنشاء سجل Docker خاص وآمن لتخزين صور الحاويات التي تخصصها حسب احتياجاتك، وجربنا معًا نشر صورة تجريبية عليه وسحبها منه إلى الخادم المحلي.
الخلاصة
يساعدك هذا المقال التعليمي على إنشاء سجلك الخاص لحفظ صور حاويات Docker ونشر الصور عليه بمرونة وأمان، ويمكنك أيضًا الاستفادة من بعض الأدوات الخاصة بالتكامل المستمر لأتمتة عمليات النشر عليه.
وتذكر دائمًا أن اعتمادك على حاويات Docker في سير عملك يعني أن الصور التي تتضمن الشيفرات البرمجية لتطبيقاتك ستعمل دائمًا بالصورة المطلوبة نفسها على أي جهاز وفي أي بيئة العمل سواءً في مرحلة التطوير أو الإنتاج. لمزيد من المعلومات عن حاويات Docker وتفاصيل التعامل معها، وطرق كتابة ملفات Docker، ننصحك بالاطلاع على مقالات قسم Docker باللغة العربية على أكاديمية حسوب أو على توثيقات Docker الرسمية.
ترجمة -وبتصرف- للمقال How To Set Up a Private Docker Registry on Ubuntu 22.04 لصاحبيه Young Kim و Savic.
اقرأ أيضًا
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.