في عصر DevOps الفائز ، يكون المطورون ملزمين ببساطة بمعرفة حاويات Docker ولماذا يحتاجون إليها وكيفية العمل معهم. هذا يسهل كثيرا من العمل. علاوة على ذلك ، حتى أولئك الذين يعملون مع .Net Core في بيئة تطوير Visual Studio 2017 يمكن أن يشعروا بالقدرة الكاملة على النقل بالحاويات ، وتحدث بافيل سكيبا ، رئيس قسم تطوير تطبيقات الخادم ، في اجتماع
Panda-Meetup C # .Net ، عن الأدوات المتاحة وتكوين Docker لـ VS.
ماذا يجب أن يكون المطور قادرًا على القيام به؟ "البرنامج" ، أجبت و ... تخمين. ولكن إذا كانت قائمة المعارف اللازمة قد انتهت في وقت سابق ، في عصر DevOps ، فهي الآن مجرد بداية. عندما نكتب الشفرة ، نحتاج بالتأكيد إلى معرفة بنية الشبكة: ما الذي يتفاعل مع ما. مطلوب دعم لعدة لغات البرمجة في وقت واحد ، ويمكن كتابة أجزاء مختلفة من التعليمات البرمجية في مشروع على أي شيء.
نحتاج إلى معرفة كيفية استرجاع البرنامج في حالة اكتشاف خطأ. نحتاج إلى إدارة التكوينات الخاصة بالبيئات المختلفة المستخدمة في الشركة - فهذه هي على الأقل بيئات تطوير متعددة ، وبيئات اختبار ومكافحة. نعم ، ما زلت بحاجة إلى فهم البرامج النصية على خوادم / أنظمة تشغيل مختلفة ، لأنه لا يمكن القيام بكل شيء باستخدام الكود ، في بعض الأحيان يتعين عليك كتابة البرامج النصية.
نحتاج إلى معرفة متطلبات الأمان ، وقد أصبحت أكثر صرامة وتناول الكثير من الوقت من المطور. لا تنس دعم وتطوير البرامج ذات الصلة: Git ، Jenkins وما إلى ذلك. نتيجة لذلك ، قد لا يكون لدى المطور ببساطة وقت كافي لتطوير خالص.
ماذا تفعل؟ يوجد مخرج ، وهو موجود في حاويات Docker ونظام إدارتها. بمجرد نشر كل هذا العملاق المعقد ، وأنت ، كما في الأيام الخوالي ، ستكتب الرمز مرة أخرى. سيتم التحكم في كل شيء آخر بواسطة أشخاص آخرين أو النظام نفسه.
نحن نفهم الحاويات
ما هو حاوية عامل ميناء؟ هذا هيكل يتكون من عدة طبقات. الطبقة العليا هي الطبقة الثنائية للتطبيق الخاص بك. يتم دمج الطبقتين الثانية والثالثة في .Net Core ، الحاوية بالفعل SDK-shny. تعتمد الطبقة التالية على نظام التشغيل الذي تم نشر الحاوية عليه. والطبقة السفلية هي نظام التشغيل نفسه.
في المستوى الأدنى ، يتم نشر Windows Nanoserver. هذا ضغط كبير من Windows Server ، لا يمكنه فعل أي شيء سوى الحفاظ على برنامج أداة مساعدة تم نشره. لكن حجمها أقل 12 مرة.
إذا قارنا الخوادم والحاويات الفعلية والظاهرية ، فستكون فوائد هذه الأخيرة واضحة.
عندما كان كل شيء يعمل على الخوادم الفعلية ، واجهنا مجموعة من المشاكل. لم يكن هناك عزل في رموز المكتبة ؛ فقد تتداخل بعض التطبيقات مع بعضها البعض. على سبيل المثال: تطبيق واحد يعمل على .Net 1.1 ، والآخر يعمل على .Net 2.0. في معظم الأحيان ، وهذا أدى إلى مأساة. بعد مرور بعض الوقت ، ظهرت خوادم افتراضية ، تم حل مشكلة العزلة ، ولم تكن هناك مكتبات مشتركة. صحيح ، في الوقت نفسه ، أصبح مكلفًا للغاية من حيث الموارد والعمل: كان من الضروري تتبع عدد الأجهزة الظاهرية التي كانت تدور على جهاز افتراضي واحد ، وعلى Hyper-V وعلى قطعة من الحديد.
تم تصميم الحاويات لتكون حلاً غير مناسب ومريح ، يعتمد على الحد الأدنى من نظام التشغيل. دعونا نرى كيف تختلف. توجد الخوادم الافتراضية داخل النظام تقريبًا مثل هذا.
الطبقة السفلية هي الخادم المضيف. يمكن أن يكون إما المادية أو الافتراضية. الطبقة التالية هي أي نظام تشغيل ذي محاكاة افتراضية ، أعلاه عبارة عن برنامج مراقبة. في الجزء العلوي ، توجد خوادم افتراضية يمكن تقسيمها إلى نظام تشغيل وتطبيقات ضيف. وهذا هو ، تحت كل خادم افتراضي ، يتم نشر نظام التشغيل الضيف على رأس نظام التشغيل ، وهذا هو مضيعة إضافية للموارد.
لنرى كيف توجد حاويات Linux على النظام.
كما ترون ، توجد الثنائيات مع التطبيقات مباشرة فوق الخادم المضيف ونظام التشغيل. ليست هناك حاجة إلى نظام التشغيل الضيف ، يتم تحرير الموارد ، ليست هناك حاجة لتراخيص نظام التشغيل الضيف.
حاويات ويندوز تختلف قليلا عن لينكس.
الطبقات الأساسية هي نفسها: البنية التحتية ، نظام التشغيل المضيف (ولكن الآن ويندوز). ولكن بعد ذلك ، يمكن أن تعمل الحاويات مباشرة مع نظام التشغيل أو يمكن نشرها أعلى برنامج Hypervisor. في الحالة الأولى ، هناك عزلة للعمليات والمسافات ، لكنها تستخدم نفس النواة مع الحاويات الأخرى ، والتي من وجهة نظر الأمن ليست الجليد. إذا كنت تستخدم الحاويات عبر Hyper-V ، فسيتم عزل كل شيء.
تعلم عامل الميناء ل VS
دعنا ننتقل إلى عامل الميناء نفسه. افترض أن لديك Visual Studio ، وأنك تقوم بتثبيت عميل Docker لنظام التشغيل Windows لأول مرة. في هذه الحالة ، سينشر Docker خادم Docker demon ، والواجهة على Rest للوصول إليه ، والعميل نفسه - سطر أوامر Docker. سوف يسمح لنا بإدارة كل ما يتعلق بالحاويات: الشبكة ، الصور ، الحاويات ، الطبقات.
تعرض الشريحة أبسط الأوامر: اسحب حاوية Docker ، ثم قم بتشغيلها ، وجمعها ، وارتكبها ، وأرسلها مرة أخرى.
يتم إرفاق عامل الأرصاد بشكل كبير مع Visual Studio. تعرض لقطة الشاشة قائمة لوحة من Visual Studio 2017. يتم دمج دعم Docker مباشرة في Intellisense ، يتم دعم Dockerfile ، وجميع الأعمال الفنية تعمل على سطر الأوامر.
ومن المثير للاهتمام ، أننا يمكن أن Docker تصحيح الحاويات مباشرة في الوقت الحقيقي. وإذا كانت حاوياتك متصلة ببعضها البعض ، فستتم إزالة حزمها على الفور في الحال ، ولن تحتاج إلى تشغيل عدة بيئات.
كيف يتم تجميع الحاويات؟ العنصر الرئيسي هنا هو dockerfile ، الذي يحتوي على تعليمات لبناء الصورة. يتم إنشاء كل dockerfile لكل مشروع. إنه يشير إلى: من أين نحصل على الصورة الأساسية ، وما هي الحجج التي نمررها ، وما هو اسم دليل العمل مع الملفات والمنافذ.
تحتوي هذه الوسيطة المصدر على معلمتين. المعلمة الثانية هي المسار الذي سيتم من خلاله وضع نتيجة التجميع في المشروع ، ويتم تعيين القيمة افتراضيًا. في رأيي ، هذا ليس خيارًا جيدًا للغاية. غالبًا ما يكون هناك الكثير من النفايات في هذا المجلد ، ويجب تنظيفها بشكل دوري ، وعندما نقوم بتنظيف هذا المجلد ، يمكننا فرك التجميع. لذلك ، إذا كنت ترغب في ذلك ، يمكنك تغييره ، حيث يتم تعيينه بواسطة معلمة نظام Docker_build_source ، والتي يمكن أيضًا التوصل إليها.
يتيح لك تعليمة Entrypoint تكوين الحاوية كملف قابل للتنفيذ. هذا الخط مطلوب من أجل .Net Core ، بحيث بعد بدء تشغيل الحاوية بنجاح ، يرسل رسالة "يتم تشغيل التطبيق الخاص بك" إلى سطر الأوامر.
الآن حول تصحيح الأخطاء الحاويات. كل شيء هنا يشبه العادية. صافي ، سوف تلاحظ بالكاد الفرق. في أغلب الأحيان ، أركض .Net Core كمستضافة ذاتية ضمن dotnet.exe. ويستخدم مصحح أخطاء CLRDBG وذاكرة التخزين المؤقت لحزمة NuGet وشفرة المصدر.
تتم استضافة ASP.Net 4.5+ بواسطة IIS أو IIS Express ، ويستخدم Microsoft Visual Studio Debugger ومصدر جذر الموقع في IIS.
هناك نوعان من البيئات لتصحيح الأخطاء: Debug and Release. يتم تمييز علامة صورة تصحيح الأخطاء على أنها dev ، والإصدار الأخير. عند تصحيح الأخطاء ، يتم ضبط وسيطة المصدر بشكل أفضل على obj / Docker / فارغة ، حتى لا يتم الخلط ، ولكن عند إطلاق obj / Docker / publish. هنا يمكنك استخدام جميع الثنائيات نفسها ، وجهات النظر ، مجلد wwwroot وجميع التبعيات الموجودة.
اتقان عامل الميناء يؤلف
دعنا ننتقل إلى الجزء الممتع: أداة تزامن Docker-compose. دعونا نلقي نظرة على مثال: لديك نوعًا من خدمات الأعمال يؤثر على 5-6 حاويات. وتحتاج إلى إصلاح بطريقة ما كيف ينبغي تجميعها ، في أي ترتيب. هذا هو المكان الذي يأتي فيه Docker-compose في متناول يدي ، مما سيوفر جميع عمليات تجميع الحاويات وإطلاقها وتوسيع نطاقها. يتم إدارتها ببساطة ، يتم جمع كل شيء من قبل فريق واحد.
يستخدم Docker-compose ملفات YAML التي تخزن تكوين كيفية تجميع الحاويات. يصفون الإعدادات التي تحتاج إلى استخدامها للصور نفسها ، والتجمعات ، والخدمات ، وحدات التخزين ، الشبكات ، البيئات. بناء الجملة مطابق للنشر في الكتل. أي بمجرد أن يكتبوا مثل هذا الملف ، وإذا كان من الضروري في المستقبل نشر خدمة أعمال في كتلة ، فلن تضطر إلى إضافة أي شيء آخر.
النظر في هيكل ملف YAML. الصورة هي صورة عامل الميناء. الصورة عبارة عن حاوية بدون طبقة تطبيق ؛ فهي غير قابلة للتغيير.
يشير Build إلى كيفية الإنشاء ، وإلى مكان الإنشاء وإلى مكان نشره.
Depends_on - الاعتماد على الخدمات التي تعتمد عليها.
البيئة - هنا وضعنا البيئة.
المنافذ - تعيين المنافذ التي سيتوفر بها الحاوية الخاصة بك.
النظر في مثال. لدينا فقط واجهة برمجة تطبيقات (API) بدون خدمة ، ولا سيما 3 حاويات: يوجد SQL.data على نظام Linux ، وهناك تطبيق في حد ذاته ، ويعتمد على webapi ، ويعتمد webapi على SQL.data.
لا يهم بترتيب المكونات المكتوبة في الملف. إذا تم وصف كل شيء بشكل صحيح ، فسيقوم "إنشاء" تلقائيًا بإنشاء هذه المعلومات بشكل صحيح استنادًا إلى التبعيات في المشروع. هذا الملف يكفي لجمع جميع الحاويات في وقت واحد ، والإخراج سيكون الإصدار النهائي.
يوجد نوع من "حاوية الحاوية" ، عامل رصيف حاويات خاص. cci.build.yml ، يتم فيه تجميع التركيب بالكامل. يمكنك تشغيل هذه الحاوية الخاصة من سطر أوامر Visual Studio ، وستكون قادرة على إكمال التجميع على خادم بناء ، على سبيل المثال ، في جنكينز.
ألق نظرة داخل الملف. المثال يحتوي على دليل العمل ومن أين يأتي. يقوم باستعادة المشروع من GIT ، وينشر هذا الحل بنفسه ، ويقوم بتكوين الإصدار وتحميل النتيجة. هذا هو الفريق بأكمله الذي سيتم بناؤه ، ولا يجب كتابة أي شيء آخر. يكفي تسجيله مرة واحدة ، ثم بدء المنشور بضغطة واحدة.
ماذا يستحق الاهتمام. عامل إنشاء يؤلف لكل بيئة بجمع الصور ، لكل تكوين ملف منفصل. لكل تكوين في Visual Studio يوجد ملف بالإعدادات التي تحتاجها للبيئة.
مباشرة من VS ، يمكنك البدء في تصحيح التكوين بأكمله عن بُعد.
أوركسترا الكتل
أخيرًا ، نتطرق إلى مواضيع مثل أوركسترا الكتل. يجب ألا نفكر في كيفية استمرار وجود الحاويات ، أي الأشخاص أو الأنظمة التي تتم إدارتها. لهذا ، هناك 4 من أكثر أنظمة إدارة الحاويات شيوعًا: Google Kubernetes و Mesos DC / OS و Docker Swarm و Azure Service Fabric. أنها تسمح لك لإدارة تجميع وتكوين الحاويات.
هذه الأنظمة قادرة على التعامل مع طبقة ضخمة من الخدمات المصغرة ، مما يوفر لها كل ما هو ضروري. سيحتاج المطور فقط لتهيئة هذه الطبقة مرة واحدة.
النسخة الكاملة للأداء في Panda Meetup متاحة أدناه.
بالنسبة لأولئك الذين يرغبون في الخوض في الموضوع بشكل أعمق ، أنصحك بدراسة المواد التالية:
المتشعب: / / dot.net
المتشعب: / / docs.docker.com
المتشعب: / / www.hub.docker.com/microsoft
المتشعب: / / docs.microsoft.com
المتشعب: / /visualstudio.com
وأخيرا ، نصيحة مهمة من الممارسة: أصعب شيء هو أن نتذكر أين يكمن.
الوثائق عند العمل مع حاويات السفن سوف تقع على كتفيك. بدون وثائق ، سوف تنسى أين يوجد في الحاوية ما هو متصل بماذا وماذا يعمل. لمزيد من الخدمات ، زاد إجمالي شبكة الاتصالات.