نهج IAC (البنية التحتية كرمز) لا تتكون فقط من التعليمات البرمجية المخزنة في المستودع، ولكن أيضًا من الأشخاص والعمليات التي تحيط بهذا الرمز. هل من الممكن إعادة استخدام الأساليب بدءًا من تطوير البرمجيات وحتى إدارة البنية التحتية ووصفها؟ سيكون من الجيد أن تضع هذه الفكرة في الاعتبار أثناء قراءة المقال.
هذا هو نسخة من بلدي في .
الشرائح ومقاطع الفيديو
- التشغيل الجاف 2019-04-24
البنية التحتية كتاريخ باش
لنفترض أنك أتيت إلى مشروع جديد، وأخبروك: "لقد فعلنا ذلك البنية التحتية كرمز". في الواقع اتضح البنية التحتية كتاريخ باش أو على سبيل المثال التوثيق كتاريخ باش. هذا وضع حقيقي للغاية، على سبيل المثال، تم وصف حالة مماثلة من قبل دينيس ليسينكو في خطابه أخبر كيف حصلوا على بنية تحتية متماسكة للمشروع من تاريخ باش.
مع بعض الرغبة، يمكننا أن نقول ذلك البنية التحتية كتاريخ باش هذا مثل الكود:
- قابلية اعادة الأنتاج: يمكنك الحصول على سجل bash، وتشغيل الأوامر من هناك، وقد تحصل، بالمناسبة، على تكوين عملي كمخرج.
- الإصدارات: أنت تعرف من جاء وماذا فعلوا، مرة أخرى، ليس حقيقة أن هذا سيقودك إلى تكوين العمل عند الخروج.
- تاريخ: قصة من فعل ماذا. فقط لن تتمكن من استخدامه إذا فقدت الخادم.
ماذا تفعل؟
البنية التحتية كرمز
حتى هذه الحالة الغريبة مثل البنية التحتية كتاريخ باش يمكنك سحبه من الأذنين البنية التحتية كرمز، ولكن عندما نريد أن نفعل شيئًا أكثر تعقيدًا من خادم LAMP القديم الجيد، فسوف نتوصل إلى استنتاج مفاده أن هذا الرمز يحتاج إلى تعديل وتغيير وتحسين بطريقة أو بأخرى. بعد ذلك نود أن ننظر في أوجه التشابه بين البنية التحتية كرمز وتطوير البرمجيات.
جاف
في مشروع تطوير نظام التخزين، كانت هناك مهمة فرعية : نحن نصدر إصدارًا جديدًا - يجب طرحه لإجراء المزيد من الاختبارات. المهمة بسيطة للغاية:
- قم بتسجيل الدخول هنا عبر ssh وقم بتنفيذ الأمر.
- انسخ الملف هناك.
- تصحيح التكوين هنا.
- ابدأ الخدمة هناك
- ...
- ربح!
بالنسبة للمنطق الموصوف، فإن bash أكثر من كافٍ، خاصة في المراحل الأولى من المشروع، عندما يبدأ للتو. هذا ، ولكن مع مرور الوقت، تظهر طلبات لنشر شيء مشابه، ولكنه مختلف قليلاً. أول ما يتبادر إلى الذهن هو النسخ واللصق. والآن لدينا بالفعل نصان متشابهان للغاية يقومان بنفس الشيء تقريبًا. بمرور الوقت، زاد عدد البرامج النصية، وواجهنا حقيقة أن هناك منطق عمل معين لنشر التثبيت الذي يحتاج إلى المزامنة بين البرامج النصية المختلفة، وهو أمر معقد للغاية.
اتضح أن هناك ممارسة مثل DRY (لا تكرر نفسك). والفكرة هي إعادة استخدام التعليمات البرمجية الموجودة. يبدو الأمر بسيطا، لكننا لم نصل إلى هذا على الفور. في حالتنا، كانت فكرة مبتذلة: فصل التكوينات عن البرامج النصية. أولئك. منطق الأعمال لكيفية نشر التثبيت بشكل منفصل، والتكوينات بشكل منفصل.
الصلبة لCFM
مع مرور الوقت، نما المشروع و كان ظهور Ansible. السبب الرئيسي لظهوره هو وجود خبرة في الفريق وأن bash ليس مصممًا للمنطق المعقد. بدأ Ansible أيضًا في احتواء منطق معقد. ولمنع المنطق المعقد من التحول إلى فوضى، هناك مبادئ لتنظيم التعليمات البرمجية في تطوير البرمجيات صلب أيضًا، على سبيل المثال، أثار غريغوري بيتروف في تقريره "لماذا يحتاج متخصص في تكنولوجيا المعلومات إلى علامة تجارية شخصية" سؤالًا مفاده أن الشخص مصمم بطريقة يسهل عليه العمل مع بعض الكيانات الاجتماعية، في تطوير البرمجيات هذه هي كائنات. وإذا جمعنا بين هاتين الفكرتين واستمرينا في تطويرهما، سنلاحظ أنه يمكننا استخدامهما أيضًا صلب لتسهيل صيانة هذا المنطق وتعديله في المستقبل.
مبدأ المسؤولية الفردية
كل فئة تؤدي مهمة واحدة فقط.
لا حاجة لخلط التعليمات البرمجية وإنشاء وحوش سباغيتي إلهية متجانسة. يجب أن تتكون البنية التحتية من الطوب البسيط. اتضح أنه إذا قمت بتقسيم قواعد اللعب Ansible إلى أجزاء صغيرة، وقراءة الأدوار Ansible، فسيكون من الأسهل الحفاظ عليها.
المبدأ المفتوح المغلق
مبدأ مفتوح/مغلق.
- مفتوح للامتداد: يعني أنه يمكن توسيع سلوك الكيان عن طريق إنشاء أنواع كيانات جديدة.
- مغلق للتغيير: نتيجة لتوسيع سلوك الكيان، لا ينبغي إجراء أي تغييرات على التعليمات البرمجية التي تستخدم تلك الكيانات.
في البداية، قمنا بنشر البنية التحتية للاختبار على الأجهزة الافتراضية، ولكن نظرًا لحقيقة أن منطق النشر التجاري كان منفصلاً عن التنفيذ، أضفنا النشر إلى النظام المعدني دون أي مشاكل.
مبدأ استبدال ليسكوف
مبدأ الاستبدال لباربرا ليسكوف. يجب أن تكون الكائنات الموجودة في البرنامج قابلة للاستبدال بمثيلات من أنواعها الفرعية دون تغيير التنفيذ الصحيح للبرنامج
إذا نظرت إليها على نطاق أوسع، فهي ليست سمة من سمات أي مشروع معين يمكن تطبيقها هناك صلب، يتعلق الأمر بشكل عام بـ CFM، على سبيل المثال، في مشروع آخر، من الضروري نشر تطبيق Java المعبأ أعلى Java المختلفة وخوادم التطبيقات وقواعد البيانات ونظام التشغيل وما إلى ذلك. باستخدام هذا المثال، سأفكر في المزيد من المبادئ صلب
في حالتنا، هناك اتفاق داخل فريق البنية التحتية على أنه إذا قمنا بتثبيت دور imbjava أو oraclejava، فسيكون لدينا ملف Java ثنائي قابل للتنفيذ. وهذا ضروري لأن تعتمد أدوار المنبع على هذا السلوك؛ فهي تتوقع استخدام Java. في الوقت نفسه، يسمح لنا هذا باستبدال تطبيق/إصدار Java بآخر دون تغيير منطق نشر التطبيق.
تكمن المشكلة هنا في استحالة تنفيذ ذلك في Ansible، ونتيجة لذلك تظهر بعض الاتفاقيات داخل الفريق.
مبدأ فصل الواجهة
مبدأ فصل الواجهة: "العديد من الواجهات الخاصة بالعميل أفضل من واجهة واحدة للأغراض العامة.
في البداية، حاولنا وضع كل تنوع نشر التطبيق في دليل Ansible واحد، ولكن كان من الصعب دعمه، والنهج عندما يكون لدينا واجهة خارجية محددة (يتوقع العميل المنفذ 443)، فيمكن تجميع البنية التحتية من الأفراد الطوب لتنفيذ معين.
مبدأ انعكاس التبعية
مبدأ انعكاس التبعية. لا ينبغي أن تعتمد الوحدات في المستويات الأعلى على الوحدات في المستويات الأدنى. يجب أن يعتمد كلا النوعين من الوحدات على التجريدات. لا ينبغي أن تعتمد التجريدات على التفاصيل. التفاصيل يجب أن تعتمد على التجريدات.
هنا سوف يعتمد المثال على نمط مضاد.
- كان لدى أحد العملاء سحابة خاصة.
- لقد طلبنا أجهزة افتراضية داخل السحابة.
- ولكن نظرًا لطبيعة السحابة، كان نشر التطبيق مرتبطًا ببرنامج Hypervisor الذي يعمل عليه الجهاز الافتراضي.
أولئك. يتدفق منطق نشر التطبيق عالي المستوى مع التبعيات إلى مستويات أقل من برنامج Hypervisor، وهذا يعني حدوث مشكلات عند إعادة استخدام هذا المنطق. لا تفعل ذلك بهذه الطريقة.
تفاعل
البنية التحتية كرمز لا تتعلق فقط بالرمز، ولكن أيضًا بالعلاقة بين الكود والأشخاص، وبالتفاعلات بين مطوري البنية التحتية.
عامل الحافلة
لنفترض أن لديك Vasya في مشروعك. يعرف Vasya كل شيء عن البنية التحتية الخاصة بك، ماذا سيحدث إذا اختفى Vasya فجأة؟ هذا موقف حقيقي للغاية، لأنه من الممكن أن تصدمه حافلة. في بعض الأحيان يحدث ذلك. إذا حدث هذا ولم يتم توزيع المعرفة حول الكود وبنيته وكيفية عمله والمظاهر وكلمات المرور بين الفريق، فقد تواجه عددًا من المواقف غير السارة. لتقليل هذه المخاطر وتوزيع المعرفة داخل الفريق، يمكنك استخدام أساليب مختلفة
إقران Devopsing
ليست ك ، أن المسؤولين يشربون البيرة، ويغيرون كلمات المرور، وما شابه ذلك من البرمجة الزوجية. أولئك. يجلس مهندسان على جهاز كمبيوتر واحد، ولوحة مفاتيح واحدة، ويبدآن في إعداد البنية التحتية الخاصة بك معًا: إعداد الخادم، وكتابة دور Ansible، وما إلى ذلك. يبدو الأمر جميلاً، لكنه لم ينجح بالنسبة لنا. لكن حالات خاصة من هذه الممارسة نجحت. يأتي موظف جديد، يتولى معلمه معه مهمة حقيقية، ويعمل وينقل المعرفة.
حالة خاصة أخرى هي مكالمة حادثة. أثناء حدوث مشكلة، يجتمع مجموعة من المناوبين والمشاركين، ويتم تعيين قائد واحد يشارك شاشته ويصدر صوت قطار الأفكار. يتابع المشاركون الآخرون أفكار القائد، ويتجسسون على الحيل من وحدة التحكم، ويتأكدون من أنهم لم يفوتوا أي سطر في السجل، ويتعلمون أشياء جديدة حول النظام. وقد نجح هذا النهج في أغلب الأحيان.
مراجعة الكود
بشكل شخصي، كان نشر المعرفة حول البنية التحتية وكيفية عملها أكثر فعالية باستخدام مراجعة التعليمات البرمجية:
- يتم وصف البنية التحتية بواسطة الكود الموجود في المستودع.
- تحدث التغييرات في فرع منفصل.
- أثناء طلب الدمج، يمكنك رؤية دلتا التغييرات في البنية الأساسية.
وكان أبرز ما في الأمر هنا هو أنه تم اختيار المراجعين واحدًا تلو الآخر، وفقًا لجدول زمني، أي. مع درجة معينة من الاحتمال، سوف تصعد إلى قطعة جديدة من البنية التحتية.
نمط الرمز
مع مرور الوقت، بدأت المشاحنات تظهر أثناء المراجعات، لأن... كان للمراجعين أسلوبهم الخاص وقام تناوب المراجعين بتجميعهم بأنماط مختلفة: مسافتان أو 2، أو علبة الجمل أو علبة الثعبان. لم يكن من الممكن تنفيذ هذا على الفور.
- كانت الفكرة الأولى هي التوصية باستخدام اللينتر، ففي نهاية المطاف، الجميع مهندسون، والجميع أذكياء. لكن المحررين المختلفين لنظام التشغيل ليسوا مناسبين
- تطور هذا إلى روبوت يكتب إلى Slack لكل التزام به مشكلة ويرفق مخرجات linter. ولكن في معظم الحالات، كانت هناك أشياء أكثر أهمية يجب القيام بها وظل الرمز بدون إصلاح.
سيد البناء الأخضر
يمر الوقت، وقد توصلنا إلى نتيجة مفادها أنه لا يمكن السماح بالالتزامات التي لا تجتاز اختبارات معينة في السيد. هاهو! لقد اخترعنا برنامج Green Build Master، والذي تم ممارسته في مجال تطوير البرمجيات لفترة طويلة:
- التطوير جار في فرع منفصل.
- يتم تشغيل الاختبارات على هذا الموضوع.
- إذا فشلت الاختبارات، فلن يصل الكود إلى الملف الرئيسي.
كان اتخاذ هذا القرار مؤلمًا للغاية، لأنه... أثار الكثير من الجدل، لكنه كان يستحق ذلك، لأن... بدأت المراجعات في تلقي طلبات الدمج دون اختلافات في الأسلوب، وبمرور الوقت بدأ عدد مجالات المشكلات في الانخفاض.
اختبار إيك
بالإضافة إلى التحقق من النمط، يمكنك استخدام أشياء أخرى، على سبيل المثال، للتحقق من إمكانية نشر البنية الأساسية لديك بالفعل. أو تأكد من أن التغييرات في البنية التحتية لن تؤدي إلى خسارة المال. لماذا قد يكون هذا مطلوبا؟ السؤال معقد وفلسفي، ومن الأفضل الإجابة عليه بقصة مفادها أنه كان هناك بطريقة أو بأخرى أداة تحجيم تلقائية على Powershell لم تتحقق من الشروط الحدودية => تم إنشاء المزيد من الأجهزة الافتراضية أكثر من اللازم => أنفق العميل أموالًا أكثر مما كان مخططًا له. هذا ليس لطيفا للغاية، ولكن سيكون من الممكن تماما اكتشاف هذا الخطأ في المراحل المبكرة.
وقد يتساءل المرء، لماذا نجعل البنية التحتية المعقدة أكثر تعقيدا؟ لا تتعلق اختبارات البنية التحتية، تمامًا مثل التعليمات البرمجية، بالتبسيط، بل بمعرفة كيفية عمل البنية التحتية لديك.
هرم اختبار IAC
اختبار IAC: التحليل الثابت
إذا قمت بنشر البنية التحتية بأكملها مرة واحدة وتأكدت من أنها تعمل، فقد تجد أن الأمر يستغرق الكثير من الوقت ويتطلب الكثير من الوقت. لذلك، يجب أن يكون الأساس شيئًا يعمل بسرعة، ويوجد منه الكثير، ويغطي الكثير من الأماكن البدائية.
باش صعب
دعونا نلقي نظرة على مثال تافه. حدد جميع الملفات الموجودة في الدليل الحالي وانسخها إلى موقع آخر. أول ما يتبادر إلى الذهن:
for i in * ; do
cp $i /some/path/$i.bak
doneماذا لو كان هناك مسافة في اسم الملف؟ حسنًا، حسنًا، نحن أذكياء، ونعرف كيفية استخدام علامات الاقتباس:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneأحسنت؟ لا! ماذا لو لم يكن هناك شيء في الدليل، أي. لن ينجح الضرب.
find . -type f -exec mv -v {} dst/{}.bak ;أحسنت الآن؟ لا... نسيت ما يمكن أن يكون في اسم الملف n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirأدوات التحليل الثابت
يمكن اكتشاف المشكلة من الخطوة السابقة عندما ننسى الاقتباسات، ولهذا هناك العديد من العلاجات في الطبيعة ، بشكل عام، يوجد الكثير منهم، وعلى الأرجح يمكنك العثور على حشوة لمكدسك ضمن IDE الخاص بك.
اللغة
أداة
سحق
روبي
الثعبان
ansible
اختبار IAC: اختبارات الوحدة
كما رأينا من المثال السابق، فإن الوبر ليس كلي القدرة ولا يمكنه الإشارة إلى جميع مناطق المشكلة. علاوة على ذلك، وبالقياس على الاختبار في تطوير البرمجيات، يمكننا أن نتذكر اختبارات الوحدة. ما يتبادر إلى الذهن على الفور هو , , , . ولكن ماذا تفعل مع ansible و Chef و Saltstack وآخرين مثلهم؟
في البداية تحدثنا عنها صلب وأن البنية التحتية لدينا يجب أن تتكون من الطوب الصغير. لقد حان وقتهم.
- البنية التحتية مقسمة إلى طوب صغير مثلا أدوار أنسيبل.
- يتم نشر نوع ما من البيئة، سواء كانت عامل إرساء أو جهاز افتراضي.
- نحن نطبق دورنا المسؤول على بيئة الاختبار هذه.
- نتأكد من أن كل شيء يعمل كما توقعنا (نجري اختبارات).
- نحن نقرر موافق أو لا موافق.
اختبار IaC: أدوات اختبار الوحدة
سؤال ما هي اختبارات CFM؟ يمكنك ببساطة تشغيل البرنامج النصي، أو يمكنك استخدام الحلول الجاهزة لهذا:
CFM
أداة
Ansible
تشف
تشف
ملح
مثال على testinfra، التحقق من أن المستخدمين test1, test2 موجودة وتكون في مجموعة sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsماذا تختار؟ السؤال معقد وغامض، فيما يلي مثال على التغييرات في المشاريع على جيثب لعام 2018-2019:
أطر اختبار IaC
السؤال الذي يطرح نفسه: كيف يمكن تجميع كل ذلك معًا وإطلاقه؟ يستطيع إذا كان هناك عدد كاف من المهندسين. أو يمكنك اتخاذ الحلول الجاهزة، على الرغم من عدم وجود الكثير منها:
CFM
أداة
Ansible
تشف
Terraform
مثال على التغييرات في المشاريع على جيثب للفترة 2018-2019:
جزيء مقابل. مطبخ الاختبار
في البداية نحن :
- إنشاء VM بالتوازي.
- تطبيق أدوار Ansible.
- تشغيل التفتيش.
لمدة 25-35 دورًا، استغرق الأمر 40-70 دقيقة، وهي فترة طويلة.
كانت الخطوة التالية هي الانتقال إلى jenkins/docker/ansible/molecule. من الناحية الأيديولوجية، كل شيء هو نفسه
- كتب اللعب الوبر.
- صف الأدوار.
- إطلاق الحاوية
- تطبيق أدوار Ansible.
- قم بتشغيل testinfra.
- التحقق من العجز الجنسي.
بدأ فحص 40 دورًا واختبارًا لعشرات الأدوار يستغرق حوالي 15 دقيقة.
يعتمد الاختيار على العديد من العوامل، مثل المجموعة المستخدمة، والخبرة في الفريق، وما إلى ذلك. وهنا يقرر الجميع بأنفسهم كيفية إغلاق سؤال اختبار الوحدة
اختبار IaC: اختبارات التكامل
ستكون الخطوة التالية في هرم اختبار البنية التحتية هي اختبارات التكامل. وهي تشبه اختبارات الوحدة:
- البنية التحتية مقسمة إلى طوب صغير، على سبيل المثال الأدوار Ansible.
- يتم نشر نوع ما من البيئة، سواء كانت عامل إرساء أو جهاز افتراضي.
- تنطبق على بيئة الاختبار هذه مجموعة من أدوار غير قابلة للتنفيذ.
- نتأكد من أن كل شيء يعمل كما توقعنا (نجري اختبارات).
- نحن نقرر موافق أو لا موافق.
بشكل تقريبي، نحن لا نتحقق من أداء عنصر فردي في النظام كما هو الحال في اختبارات الوحدة، بل نتحقق من كيفية تكوين الخادم ككل.
اختبار IaC: الاختبارات الشاملة
في أعلى الهرم، يتم الترحيب بنا من خلال اختبارات شاملة. أولئك. نحن لا نتحقق من أداء خادم منفصل، أو برنامج نصي منفصل، أو لبنة منفصلة من بنيتنا التحتية. نحن نتحقق من أن العديد من الخوادم متصلة ببعضها البعض، وأن بنيتنا التحتية تعمل كما نتوقع. لسوء الحظ، لم أر قط حلولاً جاهزة جاهزة، ربما بسبب... غالبًا ما تكون البنية التحتية فريدة ويصعب تصميمها وإنشاء إطار عمل للاختبار. ونتيجة لذلك، الجميع يخلق حلولهم الخاصة. هناك طلب، ولكن ليس هناك إجابة. لذلك، سأخبرك بما هو موجود من أجل دفع الآخرين إلى الأفكار السليمة أو فرك أنفي بحقيقة أن كل شيء تم اختراعه قبلنا بوقت طويل.
مشروع ذو تاريخ غني. يتم استخدامه في المؤسسات الكبيرة وربما يكون كل واحد منكم قد عبر مساراته بشكل غير مباشر. يدعم التطبيق العديد من قواعد البيانات وعمليات التكامل وما إلى ذلك. إن معرفة الشكل الذي قد تبدو عليه البنية التحتية يتطلب الكثير من ملفات إنشاء عامل الإرساء، ومعرفة الاختبارات التي سيتم تشغيلها في أي بيئة هي Jenkins.
لقد عمل هذا المخطط لفترة طويلة، حتى داخل الإطار لم نحاول نقل هذا إلى Openshift. تظل الحاويات كما هي، لكن بيئة الإطلاق تغيرت (مرحبًا DRY مرة أخرى).
لقد ذهبت فكرة البحث إلى أبعد من ذلك، وفي نظام openshift وجدوا شيئًا مثل APB (Ansible Playbook Bundle)، والذي يسمح لك بتجميع المعرفة حول كيفية نشر البنية التحتية في حاوية. أولئك. هناك نقطة معرفة قابلة للتكرار وقابلة للاختبار حول كيفية نشر البنية التحتية.
بدا كل هذا جيدًا حتى واجهنا بنية تحتية غير متجانسة: كنا بحاجة إلى Windows لإجراء الاختبارات. ونتيجة لذلك، فإن معرفة ماذا وأين وكيفية النشر والاختبار موجودة في جينكينز.
وفي الختام
البنية التحتية كما هو الرمز
- الكود في المستودع.
- التفاعل الإنساني.
- اختبار البنية التحتية.
وصلات
- التشغيل الجاف 2019-04-24
- &
المصدر: www.habr.com