تطبيقات ASP.NET Core هي بالفعل منصات مشتركة ويمكن تشغيلها في وظائف لا تشوبها شائبة ، وبالتالي في Docker. دعونا نرى كيف يمكن تعبئتها ليتم نشرها على لينكس واستخدامها جنبا إلى جنب مع Nginx. التفاصيل تحت خفض!

ملاحظة: نواصل سلسلة منشورات الإصدارات الكاملة من المقالات من مجلة هاكر. هجاء وعلامات الترقيم للمؤلف المحفوظة.

حول عامل الميناء

لقد سمع الجميع تقريبًا عن هندسة الخدمات الميكروية. لا يعني مفهوم تقسيم التطبيق إلى أجزاء أنه جديد. ولكن الجديد هو النسيان والمعاد تدويره.

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

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

تستخدم الحاويات جوهر نظام التشغيل الحالي وتقسيمه فيما بينها. بينما تستخدم الأجهزة الظاهرية برنامج hypervisor موارد الأجهزة.
Docker Image هو كائن للقراءة فقط يقوم بشكل أساسي بتخزين قالب لإنشاء حاوية. الحاوية هي بيئة يتم فيها تنفيذ التعليمات البرمجية. يتم تخزين الصور في المستودعات. على سبيل المثال ، يسمح لك مستودع Docker Hub الرسمي بتخزين صورة واحدة فقط بشكل خاص. ومع ذلك ، فهو مجاني ، لذا حتى في هذا ، يجب أن تشكرهم.

معلومات

عامل الميناء ليس الممثل الوحيد للحاويات. بالإضافة إلى ذلك ، هناك تقنيات أخرى. على سبيل المثال:

rkt (وضوحا 'صاروخ') من قبل CoreOS

LXD (وضوحا "lexdi") من قبل أوبونتو

حاويات ويندوز - لن تخمن أبدا من أي شخص.

الآن وقد تعرفنا على النظرية ، دعنا ننتقل إلى الممارسة.

لا يوجد أي معنى لتفكيك تثبيت عامل الميناء ، لأنه يمكن تثبيته على العديد من أنظمة التشغيل. سأشير فقط إلى أنه يمكنك تنزيله لنظامك الأساسي من Docker Store . إذا كنت تقوم بتثبيت Docker تحت Windows ، فيجب تمكين الوضع الافتراضي في BIOS ونظام التشغيل. يمكنك أن تقرأ عن كيفية تمكينه في 10 كه في المقالة التالية: تثبيت Hyper-V في Windows10

إنشاء مشروع تمكين عامل ميناء

Docker هو ، بالطبع ، منتج Linux ، ولكن إذا لزم الأمر ، يمكنك استخدامه عند التطوير لنظام التشغيل Mac أو Windows. عند إنشاء مشروع في Visual Studio ، لإضافة دعم عامل ميناء ، ما عليك سوى تحديد خانة الاختيار تمكين دعم Docker.

يمكن إضافة دعم عامل الميناء إلى مشروع موجود. يتم إضافته إلى المشروع بنفس طريقة إضافة مكونات جديدة متنوعة. قائمة السياق إضافة - دعم عامل الميناء.

إذا تم تثبيت عامل التشغيل وتشغيله على جهازك ، فسيتم فتح وحدة التحكم تلقائيًا وسيتم تنفيذ الأمر

docker pull microsoft/aspnetcore:2.0 

الذي يبدأ عملية تنزيل الصورة. هذه الصورة في الواقع فارغة على أساسها سيتم إنشاء صورتك. يستخدم ASP.NET Core 2.1 صورة مختلفة - microsoft / dotnet: sdk

سيتم إنشاء الملفات التالية تلقائيًا في الدليل مع توفير الحل لك:
.dockerignore (باستثناء الملفات والدلائل من صورة docker) ، docker-compose.yml (باستخدام هذا الملف يمكنك تكوين تنفيذ العديد من الخدمات) ، docker-compose.override.yml (التكوين الإضافي docker-compose) ، docker-compose.dcproj ( ملف مشروع لبرنامج Visual Studio).

سيتم إنشاء ملف Dockerfile في دليل المشروع. في الواقع ، بمساعدة هذا الملف ، نقوم بإنشاء صورتنا. بشكل افتراضي (في حالة ما يسمى المشروع DockerServiceDemo) ، فقد يبدو الأمر كما يلي:

 FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY DockerServiceDemo/DockerServiceDemo.csproj DockerServiceDemo/ RUN dotnet restore DockerServiceDemo/DockerServiceDemo.csproj COPY . . WORKDIR /src/DockerServiceDemo RUN dotnet build DockerServiceDemo.csproj -c Release -o /app FROM build AS publish RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"] 

لن يسمح لك التكوين الأولي لـ .NET Core 2.0 ببناء الصورة على الفور باستخدام أمر بناء الرصيف. تم تكوينه لتشغيل ملف إنشاء عامل ميناء من دليل مستوى واحد لأعلى. من أجل متابعة البناء بنجاح ، يمكن إحضار ملف Dockerfile إلى شكل مماثل:

 FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY DockerServiceDemo.csproj DockerServiceDemo.csproj RUN dotnet restore DockerServiceDemo.csproj COPY . . WORKDIR /src RUN dotnet build DockerServiceDemo.csproj -c Release -o /app FROM build AS publish RUN dotnet publish DockerServiceDemo.csproj -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "DockerServiceDemo.dll"] 

كل ما فعلته هو إزالة دليل DockerServiceDemo الإضافي.

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

ثلاثة الحبال عامل الميناء

للعمل اليومي مع عامل الميناء ، فقط عدد قليل من الأوامر كافية للتذكر.

الفريق الأكثر أهمية هو ، بالطبع ، بناء صورة. للقيام بذلك ، تحتاج إلى استخدام bash / CMD / PowerShell للانتقال إلى الدليل حيث يوجد Dockerfile وتنفيذ الأمر:

 docker build -t your_image_name . 

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

 docker build -t docker_account_name/image_name:your_tag . 

your_docker_account_name هنا هو اسم حساب لوحة الوصل.

إذا قمت بإنشاء الصورة فقط باسم محلي لا يتضمن المستودع ، فيمكنك وضع علامة على الصورة باسم مختلف بعد الإنشاء باستخدام الأمر التالي:

 docker tag image_name docker_account_name/image_name:your_tag 

لإرسال التغييرات إلى لوحة الوصل ، تحتاج الآن إلى تشغيل الأمر التالي:

 docker push docker_account_name/image_name:your_tag 

قبل ذلك ، تحتاج إلى تسجيل الدخول إلى حساب عامل ميناء الخاص بك. في نظام Windows ، يتم ذلك من واجهة المستخدم الخاصة بالتطبيق ، ولكن في * nix يتم ذلك بواسطة الأمر:

 docker login 

في الواقع ، ثلاثة فرق ليست كافية. يجب أن تكون أيضًا قادرًا على التحقق من تشغيل الحاوية. يبدو الأمر الذي يمكنك من خلاله بدء تشغيل الحاوية كما يلي:

 docker run -it -p 5000:80 image_name 

سيؤدي الخيار -it إلى إنشاء رمز زائف وسيستجيب الحاوية الخاصة بك للطلبات. بعد تشغيل الأمر ، ستكون الخدمة متاحة على http: // localhost: 5000 /

-p 5000: 80 يقترن المنفذ 5000 من الحاوية مع المنفذ 80 من المضيف.

بالإضافة إلى ذلك ، هناك مثل هذه الأوامر:

 docker ps –a 

تظهر لك قائمة الحاويات. منذ أن تم إضافة رمز التبديل - a ، سيتم عرض جميع الحاويات ، وليس فقط تلك التي تعمل حاليًا.

 docker rm container_name 

سيؤدي هذا الأمر إلى إزالة الحاوية المسماة container_name. rm - اختصار للإزالة

 docker logs container_name 

عرض سجلات الحاوية

 docker rmi image_name 

حذف صورة باسم image_name

إطلاق حاوية عبر خادم وكيل عكسي

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

أولاً ، استعادة التكوين Dockerfile الأصلي. بعد ذلك ، سنتعامل مع ملف docker-compose.yml ونحاول تشغيل خدمتنا بمفردنا. تتم قراءة تنسيق ملف yml كـ "yaml" وهو اختصار إما من "لغة ترميز أخرى" أو من "YAML Ain't Markup Language". إما لغة ترميز أخرى ، أو ليست لغة ترميز على الإطلاق. بطريقة ما ، كل شيء غير مؤكد.

يبدو ملفي الافتراضي لرسو السفن على النحو التالي:

 version: '3.4' services: dockerservicedemo: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile 

يضيف ملف docker-compose.override.yml العديد من الإعدادات إلى التكوين:
الإصدار: "3.4"

 services: dockerservicedemo: environment: - ASPNETCORE_ENVIRONMENT=Development ports: - "80" 

يمكننا بناء الحل الذي تم إنشاؤه باستخدام build-compose build ، عن طريق استدعاء أمر docker-compose ، سنقوم بإطلاق حاوية لدينا هل كل شيء يعمل؟ ثم انتقل إلى الخطوة التالية. قم بإنشاء ملف nginx.info. سيكون التكوين تقريبًا كما يلي:

 worker_processes 4; events { worker_connections 1024; } http { sendfile on; upstream app_servers { server dockerservicedemo:80; } server { listen 80; location / { proxy_pass http://app_servers; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } } 

نوضح هنا أن nginx سيستمع على المنفذ 80 (استمع 80؛). وسيتم إعادة توجيه الطلبات المستلمة إلى المنفذ 80 للمضيف في حاوية dockerservicedemo. بالإضافة إلى ذلك ، نخبر nginx عن الرؤوس التي يجب نقلها.

يمكننا استخدام http في nginx ، والوصول إلى موقع الويب من خلال https. عندما يمر طلب https عبر وكيل http ، لا يتم تمرير الكثير من المعلومات من https إلى http. بالإضافة إلى ذلك ، عند استخدام وكيل ، يتم فقد عنوان IP الخارجي. لكي يتم نقل هذه المعلومات في الرؤوس ، تحتاج إلى تغيير رمز مشروع ASP.NET الخاص بنا وإضافة التعليمة البرمجية التالية إلى بداية طريقة تكوين ملف Startup.cs:

  app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto }); 

تستخدم معظم الخوادم الوكيلة رأس X-Forwarded-For و X-Forwarded-Proto. هذه هي الرؤوس المحددة الآن في تكوين nginx.

الآن قم بتضمين صورة nginx وملف nginx.conf في تكوين تكوين doker. الحذر في المساحات YAML يهم:

 version: '3.4' services: dockerservicedemo: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile ports: - 5000:80 proxy: image: nginx:latest volumes: - ./DockerServiceDemo/nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 

هنا نضيف الوكلاء إلى التكوين لدينا كصورة nginx. نعلق على هذه الصورة ملف الإعدادات الخارجية. نحن نوع من تركيبه في نظام الملفات الحاوية باستخدام آلية تسمى وحدة التخزين. إذا قمت بالإضافة في النهاية: ro ، فسيتم تثبيت الكائن للقراءة فقط.

يستمع الوكيل إلى المنفذ 80 الخارجي للجهاز الذي يتم تشغيل الحاوية عليه ويرسل طلبًا إلى المنفذ 80 الداخلي للحاوية.

عن طريق تشغيل الأمر doker-compose up ، سنقوم بتعبئة أي صورة nginx من المستودع وبدء تشغيل الحاوية الخاصة بنا مع حاوية البروكسي. الآن على http: // localhost: 80 / سيكون الوصول إليها عبر nginx. على المنفذ رقم 5000 ، "يدور" التطبيق أيضًا تحت Kestrel.

يمكننا التحقق من أن الطلب إلى تطبيق الويب يمر عبر الوكيل العكسي. افتح أدوات المطور في متصفح Chrome وانتقل إلى علامة التبويب الشبكة. انقر على المضيف المحلي هنا وحدد علامة التبويب الرؤوس.

نطلق الحاوية من خلال الوكلاء و HTTPS

أحضر ASP.NET Core 2.1 معه تحسينات في دعم HTTPS.
لنفترض أن البرامج الوسيطة التالية تسمح لك بإعادة التوجيه من اتصال غير آمن إلى اتصال آمن:

 app.UseHttpsRedirection(); 

ويتيح لك التالي استخدام بروتوكول أمان النقل HTTP Strict - HSTS.

 app.UseHsts(); 

HSTS هي ميزة من بروتوكول HTTP / 2 ، تم إصدار مواصفاتها في عام 2015. هذه الوظيفة مدعومة بواسطة المتصفحات الحديثة وتبلغ أن موقع الويب يستخدم https فقط. وبالتالي ، تحدث الحماية ضد أي هجوم تم تقليله خلاله يمكن للمهاجم الاستفادة من الموقف باستخدام الانتقال إلى بروتوكول http غير آمن. على سبيل المثال ، قم بخفض TLS أو حتى استبدال الشهادة.

عادةً ما يتم استخدام هذا النوع من الهجوم بالتزامن مع هجمات الرجل في الوسط. يجب أن تعلم وتذكر أن HSTS لا ينقذك من موقف عندما يزور المستخدم الموقع باستخدام بروتوكول http ثم يعيد التوجيه إلى https. هناك ما يسمى قائمة التحميل المسبق لمتصفح Chrome ، والتي تحتوي على روابط لمواقع تدعم https. تدعم المتصفحات الأخرى (Firefox و Opera و Safari و Edge) قوائم بمواقع https التي تم إنشاؤها بناءً على قائمة Chrome. لكن كل هذه القوائم بعيدة عن كل المواقع.

في المرة الأولى التي تقوم فيها بتشغيل أي تطبيق Core على Windows ، ستتلقى رسالة تفيد بأنه تم إنشاء شهادة مطور وتثبيتها. بالنقر فوق الزر وتثبيت الشهادة ، ستجعلها موثوقة. من سطر الأوامر على macOS ، يمكنك إضافة ثقة إلى الشهادة باستخدام الأمر:
dotnet dev-certs https –trust

إذا لم يتم تثبيت الأداة المساعدة dev-certs ، فيمكنك تثبيتها باستخدام الأمر:

 dotnet tool install --global dotnet-dev-certs 

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

يمكنك تصدير شهادة المطور إلى ملف باستخدام الأمر

 dotnet dev-certs https -ep ___.pfx 

يجب نسخ الملف إلى الدليل٪ APPDATA٪ / ASP.NET / Https / ضمن Windows أو إلى /root/.aspnet/https/ ضمن نظام التشغيل macOS / Linux.

لكي تلتقط الحاوية مسار الشهادة وكلمة المرور الخاصة بها ، قم بإنشاء أسرار المستخدم بالمحتويات التالية:

 { "Kestrel":{ "Certificates":{ "Default":{ "Path": "/root/.aspnet/https/__.pfx", "Password": "___" } } } } 

يخزن هذا الملف البيانات غير المشفرة ، وبالتالي يتم استخدامه فقط أثناء التطوير. يتم إنشاء ملف في Visual Studio عن طريق استدعاء قائمة السياق على أيقونة المشروع أو باستخدام أداة أسرار المستخدم على Linux.

في نظام Windows ، سيتم حفظ الملف في دليل٪ APPDATA٪ \ Microsoft \ UserSecrets \ <user_secrets_id> \ secrets.json ، وسيتم حفظه على نظامي MacOS و Linux في ~ / .microsoft / usersecrets / <user_secrets_id> /secrets.json

لحفظ إعدادات الإنتاج ، قد تستخدم بعض توزيعات Linux systemd ، ويتم حفظ الإعدادات تحت سمة الخدمة. على سبيل المثال ، مثل هذا:

 [Service] Environment="Kestrel _ Certificates _ Default _Path=/root/.aspnet/https/__.pfx" Environment="Kestrel _ Certificates _ Default _Password=___" 

بعد ذلك ، سأقدم ونحلل فورًا إصدار العمل من تكوين عامل ميناء الوكيل والحاوية عبر https.

ملف إنشاء عامل الميناء:

 version: '3.4' services: dockerservicedemo21: image: ${DOCKER_REGISTRY}dockerservicedemo build: context: . dockerfile: DockerServiceDemo/Dockerfile  override: version: '3.4' services: dockerservicedemo: environment: - ASPNETCORE_ENVIRONMENT=Development - ASPNETCORE_URLS=https://+:44392;http://+:80 - ASPNETCORE_HTTPS_PORT=44392 ports: - "59404:80" - "44392:44392" volumes: - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro proxy: image: nginx:latest volumes: - ./DockerServiceDemo/nginx.conf:/etc/nginx/nginx.conf - ./DockerServiceDemo/cert.crt:/etc/nginx/cert.crt - ./DockerServiceDemo/cert.rsa:/etc/nginx/cert.rsa ports: - "5001:44392" 

الآن سوف أصف لحظات غير مفهومة. يسمح لنا ASPNETCORE_URLS بعدم الإشارة في رمز التطبيق باستخدام التطبيق. استخدم المنفذ الذي يستمع إليه التطبيق.

يقوم ASPNETCORE_HTTPS_PORT بإعادة توجيه مشابهة لما تفعله التعليمة البرمجية التالية:
services.AddHttpsRedirection (options => options.HttpsPort = 44392)

أي أنه سيتم إعادة توجيه حركة المرور من طلبات http إلى منفذ معين لطلبات https.
باستخدام المنافذ ، تتم الإشارة إلى أنه سيتم إعادة توجيه الطلب من المنفذ 59404 الخارجي إلى الحاوية 80 ومن المنفذ الخارجي 44392 إلى 44392. نظريًا ، نظرًا لأننا قمنا بتكوين خادم وكيل عكسي ، يمكننا إزالة المنافذ باستخدام عمليات إعادة التوجيه هذه.
باستخدام وحدات التخزين ، يتم تثبيت دليل بشهادة pfx وتطبيق UserSecrets بكلمة مرور ورابط إلى الشهادة.

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

لكي يتمكنوا من إنشاء شهادة pfx واحدة (التي لدينا بالفعل) لإنشاء ملفات crt و rsa ، يمكنك استخدام OpenSSL. تحتاج أولاً إلى استخراج الشهادة:

 openssl pkcs12 -in ./_.pfx -clcerts -nokeys -out domain.crt 

ثم المفتاح الخاص:

 openssl pkcs12 -in ./_.pfx -nocerts -nodes -out domain.rsa 

تكوين nginx كالتالي:

 worker_processes 4; events { worker_connections 1024; } http { sendfile on; upstream app_servers { server dockerservicedemo:44392; } server { listen 44392 ssl; ssl_certificate /etc/nginx/cert.crt; ssl_certificate_key /etc/nginx/cert.rsa; location / { proxy_pass https://app_servers; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } } 

يستمع الخادم الوكيل إلى المنفذ 44392. يستقبل هذا المنفذ طلبات من منفذ المضيف 5001st. بعد ذلك ، يعيد الوكيل توجيه الطلبات إلى المنفذ 44392 الخاص بحاوية dockerdemoservice.

بعد فهمك لهذه الأمثلة ، ستحصل على خلفية جيدة للعمل مع عامل الإرساء وخدمات micros و nginx.

نذكرك أن هذه هي النسخة الكاملة لمقال من مجلة هاكر . مؤلفها هو أليكسي سومر .