أسماء نطاقات SSL صالحة لحاويات المرسى المحلية

أصبح استخدام Docker أثناء عملية التطوير هو المعيار الفعلي. أصبح تشغيل تطبيق بكل تبعياته باستخدام أمر واحد فقط أكثر وأكثر شيوعًا. إذا كان التطبيق يوفر الوصول باستخدام واجهة الويب أو بعض واجهة برمجة تطبيقات HTTP - على الأرجح ، فإن حاوية الخط الأمامي تعيد توجيه منفذها الفريد (من بين التطبيقات الأخرى التي تقوم بتطويرها بالتوازي) إلى المضيف ، عن طريق النقر التي يمكننا التفاعل معها مع التطبيق في الحاوية .

وهذا يعمل بشكل جيد حتى يكون لديك مجموعة كاملة من التطبيقات ، حيث يبدأ التبديل بينها في التسبب في بعض الإزعاج ، حيث يتعين عليك تذكر المخطط والمنفذ ، وفي مكان ما لإصلاح أي المنافذ التي قمت بتخصيصها من قبل ، حتى لا نشأت اصطدامات مع مرور الوقت.

ثم تريد أيضًا التحقق من العمل على https - ويتعين عليك إما استخدام شهادة الجذر الخاصة بك ، أو استخدام curl --insecure ... دائمًا - غير curl --insecure ... ، وعندما تعمل الأوامر المختلفة على التطبيقات - يبدأ عدد الأزواج في النمو بشكل كبير.

في مواجهة مثل هذه المشكلة مرة أخرى - فكرت الفكرة في رأسي "أوقفها!" ، وكانت نتيجة العمل في عطلة نهاية أسبوع هي خدمة تحل هذه المشكلة في مهدها ، والتي سيتم وصفها أدناه. لفارغ الصبر ، تقليديا - مرجع .

العالم سنقوم بحفظ الوكيل العكسي

بطريقة جيدة ، نحتاج إلى نوع من منطقة المجال ، جميع النطاقات الفرعية التي سيحسم المضيف المحلي منها دائمًا (127.0.0.1). أشار البحث السريع إلى مجالات مثل *.localho.st و *.lvh.me و *.vcap.me وغيرها ، ولكن كيف يمكن إرفاق شهادة SSL صالحة بها؟ بعد العبث بشهادة الجذر الخاصة بي ، تمكنت من الحصول على curl بدون أخطاء ، لكن لم تقبلها جميع المتصفحات بشكل صحيح ، واستمرت في إلقاء خطأ. بالإضافة إلى ذلك - لم أرغب حقًا في "العبث" باستخدام طبقة المقابس الآمنة.

"حسنا ، دعنا نذهب على الجانب الآخر!" - ثم تم شراء مجال يحمل الاسم localhost.tools وتم تفويضه إلى CloudFlare ، وتم تكوين الدقة المطلوبة (تم حل جميع المجالات الفرعية 127.0.0.1 ):

 $ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1 

بعد ذلك ، تم إطلاق certbot في الحاوية ، والتي ، عند تلقي KEY API من CF باستخدام سجل DNS ، تؤكد ملكية المجال ، وتصدر شهادة SSL صالحة في الإخراج:

 $ docker run \ --entrypoint="" \ -v "$(pwd)/cf-config.conf:/cf-credentials:ro" \ -v "$(pwd)/cert:/out:rw" \ -v "/etc/passwd:/etc/passwd:ro" \ -v "/etc/group:/etc/group:ro" \ certbot/dns-cloudflare:latest sh -c \ "certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials '/cf-credentials' \ -d '*.localhost.tools' \ --non-interactive \ --agree-tos \ --email '$CF_EMAIL' \ --server 'https://acme-v02.api.letsencrypt.org/directory' \ && cp -f /etc/letsencrypt/live/localhost.tools/* /out \ && chown '$(id -u):$(id -g)' /out/*" 

يحتوي الملف ./cf-config.conf على بيانات التفويض على CF ، لمزيد من التفاصيل ، راجع الوثائق الموجودة على certbot ، $CF_EMAIL - متغير البيئة مع بريدك الإلكتروني

حسنًا ، لدينا الآن شهادة SSL صالحة (حتى لمدة 3 أشهر وفقط للنطاقات الفرعية من نفس المستوى). يبقى أن نتعلم بطريقة ما كيفية التوكيل على جميع الطلبات التي تأتي إلى المضيف المحلي في الحاوية الصحيحة .

وهنا يأتي Traefik لمساعدتنا (المفسد - إنه جميل). من خلال تشغيله محليًا وإعادة توجيه مأخذ التوصيل إلى الحاوية الخاصة به من خلال وحدة التخزين ، يمكنه إرسال طلبات بالوكالة إلى الحاوية التي تحمل docker label الضروري. وبالتالي ، لا نحتاج إلى أي تكوين إضافي ، إلا عند البدء في تحديد الملصق المطلوب للحاوية (وشبكة عامل الإرساء ، ولكن عند البدء دون إنشاء عامل الإرساء ، لا يعد هذا الأمر ضروريًا ، على الرغم من أنه مرغوب فيه للغاية) ، والذي نريد الحصول عليه الوصول عن طريق اسم المجال ومع SSL صالحة !

بعد القيام بكل هذه الطريقة ، رأى العالم حاوية ترسية مع شهادة SSL المهيأة مسبقًا لترافيك وشهادة البدل SSL (نعم ، هي عامة).

المفتاح الخاص من SSL في حاوية عامة؟

نعم ، لكنني أعتقد أن هذا ليس مخيفًا ، لأنه في منطقة المجال ، والذي يحل دائمًا المضيف المحلي. MitM في هذه الحالة لا معنى له من حيث المبدأ.

ماذا تفعل عندما تكون الشهادة سيئة؟

مجرد سحب قبالة صورة جديدة من خلال إعادة تشغيل الحاوية. تم تكوين CI للمشروع ، والذي يقوم تلقائيًا ، مرة واحدة في الشهر (في الوقت الحالي) بتحديث الشهادة ونشر صورة جديدة.

أريد أن أحاول ذلك!

لا يوجد شيء أسهل. أولاً وقبل كل شيء ، تأكد من أن المنافذ المحلية 80 و 443 مجانية ، وقم بما يلي:

 #  docker-   - $ docker network create localhost-tools-network #   - $ docker run -d --rm \ -v /var/run/docker.sock:/var/run/docker.sock \ --network localhost-tools-network \ --name localhost.tools \ -p 80:80 -p 443:443 \ tarampampam/localhost #  nginx,     "my-nginx.localhost.tools" $ docker run -d --rm \ --network localhost-tools-network \ --label "traefik.frontend.rule=Host:my-nginx.localhost.tools" \ --label "traefik.port=80" \ nginx:latest 

والآن يمكننا اختبار:

 $ curl -sS http://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1> $ curl -sS https://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1> 

كما ترون ، فهو يعمل :)

أين تعيش الوثائق ، الوصف؟

كل شيء ، ليس من الصعب تخمينه ، ويعيش في https://localhost.tools . علاوة على ذلك ، يكون الكمامة متجاوبًا ، ويمكنه معرفة ما إذا كان البرنامج الخفي للوكيل العكسي يعمل محليًا ويعرض قائمة بالحاويات قيد التشغيل والمتاحة للتفاعل (إن وجدت).

كم يكلف؟

لا على الإطلاق. بالتأكيد بعد القيام بهذا الشيء لنفسي وللفريقي ، أدركت أنه يمكن أن يكون مفيدًا للمطورين الآخرين. علاوة على ذلك - اسم النطاق فقط هو الذي يكلف المال ، كل شيء آخر يستخدم دون الحاجة إلى الدفع.

ملاحظة: لا تزال الخدمة في مرحلة تجريبية ، لذلك - في حالة وجود أي عيوب أو أخطاء مطبعية أو غير ذلك - فقط خربشة في PM . تتم الإشارة إلى "مراكز البرمجة" و "تطوير مواقع الويب" لأن هذا النهج قد يكون مفيدًا بشكل أساسي في هذه الصناعات.