🍱 🦒 🧑🏼‍🤝‍🧑🏼 البنية التحتية ككود ، فزنا على نطاق واسع (كيريل فيتشينكين ، TYME) 👠 🖐️ 🕥

يعد نموذج البنية التحتية كرمز (IaC) ، والذي يشار إليه أحيانًا باسم "البنية التحتية القابلة للبرمجة" ، هو النموذج الذي تشبه به عملية تكوين البنية الأساسية عملية برمجة البرنامج. بشكل أساسي ، كانت بداية إزالة الحدود بين كتابة التطبيقات وإنشاء بيئات لهذه التطبيقات. يمكن أن تحتوي التطبيقات على برامج نصية تنشئ وتدير أجهزتها الافتراضية الخاصة. هذا هو أساس الحوسبة السحابية وجزء لا يتجزأ من DevOps.

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

هذا هو بالضبط ما يدور حوله فك شفرة تقرير كيريل فيتشينكين في DevOpsDays Moscow 2018. التقرير: إعادة استخدام وحدات Ansible ، والتخزين في Git ، والمراجعة ، وإعادة البناء ، والفوائد المالية ، والتدرج الأفقي بنقرة واحدة.

من يهتم ، من فضلك ، تحت القط.

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

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

وفقًا لذلك ، فإن إدارة حديقة الحيوان بأكملها دون وجود DevOps الكامل أمر صعب للغاية. لذلك ، قامت شركتنا بتنفيذ ممارسات DevOps المختلفة. بطبيعة الحال ، نحن نعمل على kanban ، على SCRUM ، نقوم بتخزين كل شيء في بوابة. بعد الالتزام ، هناك تكامل مستمر ، يتم تشغيل الاختبارات. يكتب المختبرون اختبارات شاملة على PyTest تبدأ كل ليلة. يبدأ اختبار الوحدة بعد كل التزام. نستخدم عملية بناء ونشر منفصلة: يتم تجميعها ، ثم نشرها في بيئات مختلفة عدة مرات. كنا على النوافذ. على النوافذ التي نشرناها باستخدام Octopus الانتشار ، نقوم بتطوير هذا العام على DotNet Core. لذلك ، نحن الآن قادرون على تشغيل البرامج على أنظمة Linux. غادرنا الأخطبوط وجاءنا إلى Ansible. اليوم سوف نتحدث عن هذا الجزء ، وهو ممارسة جديدة قمنا بتطويرها هذا العام ، وهو شيء لم يكن لدينا من قبل. عندما يكون لديك اختبارات ، وعندما تعرف كيفية إنشاء التطبيق جيدًا ، يكون نشره في مكان ما جيدًا. ولكن إذا كان لديك بيئتان تم تكوينهما بشكل مختلف ، فستظل تسقط ، وستقع في الإنتاج. لذلك ، تعد إدارة التكوينات ممارسة مهمة جدًا. هذا ما سنتحدث عنه اليوم.

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

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

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

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

لأن النظام الذي يجري التغييرات ، نستخدم Ansible. نظرًا لعدم وجود عدد كبير من الخوادم ، فهو مناسب تمامًا لنا. إذا كان لديك 100 إلى 200 خادم هناك ، فستواجه مشكلات صغيرة ، لأنه (أي Ansible) لا يزال يتصل بكل منها ويقوم بتكوينها بدوره - هذه مشكلة. من الأفضل استخدام وسائل أخرى لا تدفع ، لكن تجر. ولكن بالنسبة لتاريخنا ، عندما يكون لدينا العديد من المشاريع ، ولكن لا يوجد أكثر من 20 خادمًا ، فهذا مناسب تمامًا لنا. يحتوي Ansible على علامة زائد كبيرة - إنها عتبة دخول منخفضة. وهذا يعني حرفيًا أن أي متخصص في تكنولوجيا المعلومات في غضون ثلاثة أسابيع يمكنه إتقانه بالكامل. لديه الكثير من الوحدات. وهذا يعني أنه يمكنك إدارة السحب والشبكات والملفات وتثبيت البرامج ونشرها - كل شيء تمامًا. إذا لم تكن هناك وحدات ، فيمكنك كتابة ما لديك ، ويمكنك أخيرًا كتابة شيء باستخدام Ansible shell أو وحدة القيادة.

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

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

فقط تعامل مع المشكلة نفسها: تعلمنا كيفية تكوين الخادم باستخدام Ansible وكان كل شيء على ما يرام. ولكن ، كما قلت ، لدينا العديد من المشاريع. هم تقريبا كل نفس. وتشارك بعض هذه الأنظمة في كل مشروع (k8s ، RabbitMQ ، Vault ، ELK ، PostgreSQL ، HAProxy). لكل منها ، كتبنا دور. يمكننا لفة من الزر.

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

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

ما فعلناه: لقد اتخذنا كل دور مشترك بين جميع المشاريع وجميع التكوينات التي تأتي من الخارج إلى مستودع منفصل ووضعها في بوابة في مجلد منفصل - أطلقنا عليه اسم TYME Infrastructure. يوجد لدينا دور لـ PostgreSQL و ELK لنشر مجموعات Kubernetes. إذا احتجنا إلى وضع بعض المشاريع ، فلنفترض نفس PostgreSQL ، ثم قم بتشغيله كجهاز ثانوي ، وأعد كتابة قوائم الجرد ، وهذا يعني ، تقريبًا ، التكوين الذي سيتم فيه نقل هذا الدور. نحن لا نعيد كتابة الدور نفسه: إنه موجود بالفعل. وبنقرة زر واحدة ، يظهر PostgreSQL في جميع المشاريع الجديدة. إذا كنت بحاجة إلى رفع كتلة Kubernetes - نفس الشيء.

وهكذا ، اتضح للحد من تكلفة أدوار الكتابة. أي أنهم كتبوا مرة واحدة - استخدموها 10 مرات. عندما يذهب المشروع بعد المشروع - فهو مناسب للغاية. ولكن بما أننا نعمل الآن مع البنية التحتية كرمز ، فإننا نحتاج إلى خطوط الأنابيب التي تحدثنا عنها بشكل طبيعي. يرتكب الأشخاص في بوابة ، ويمكنهم ارتكاب نوع من الخلل - نحتاج إلى تتبع هذا كله. لذلك ، قمنا ببناء خط أنابيب من هذا القبيل. وهذا هو ، المطور يرتكب نصوص Ansible في بوابة. يتعقبهم Teamity وينقلهم إلى Ansible. هناك حاجة إلى Teamcity هنا لسبب واحد فقط: أولاً ، لديه واجهة مرئية (هناك نسخة مجانية من Ansible Tower - AWX ، والتي تحل نفس المشكلة - تقريبًا.) على عكس Ansible free و ، من حيث المبدأ ، لدينا Teamcity كوحدة واحدة سي. لذلك ، من حيث المبدأ ، لدى Ansible وحدة يمكنها في حد ذاتها تتبع git. لكن في هذه الحالة فعلوا فقط في الصورة ومثالها. وبمجرد تتبعه ، يقوم بنقل جميع التعليمات البرمجية إلى Ansible و Ansible ، على التوالي ، ويقوم بتشغيلها على خادم التكامل وتغيير التكوين. إذا تم انتهاك هذه العملية ، فإننا نحلل ما هو الخطأ ، ولماذا كانت النصوص المكتوبة سيئة.

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

ولكن هنا نستخدم عامل ميناء بالاشتراك مع Ansible. أي أن البنية الأساسية المحددة لنا في عامل الإرساء وغير المحدد في Ansible. وهكذا ، فإننا نشارك هذه الدلتا الصغيرة في عامل الميناء ، وكل شيء آخر أساسي - في Ansible.

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

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

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

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

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

عندما قدمنا هذا النهج ، انخفض CI (Teamcity) ، الذي طرح التغييرات على خادم التكامل ، 8 مرات من أصل 10. لم يهتم أحد بذلك لأنه لم يكن هناك أي تعليقات. بالنسبة للمطورين ، تم تنفيذ هذه العمليات لفترة طويلة ، لكن الرسائل لم تصل إلى OPS (مسؤولو النظام). لذلك ، أضفنا لوحة معلومات مع تجميعات هذا المشروع إلى شاشة كبيرة في مكان بارز في المكتب. على ذلك ، يتم تسليط الضوء على مشاريع مختلفة باللون الأخضر - وهذا يعني أن كل شيء في محله. إذا تم تسليط الضوء باللون الأحمر يعني أن كل شيء سيء معه. نرى أن بعض الاختبارات فشلت. في العرض التقديمي ، على الجانب الأيسر من الثاني ، نرى من أعلى نتيجة مستودع نشر البنية التحتية. . , , , . : - . . Slack , - - - .

Ok, , , - , . trunk based . Master — . Master CI (Teamcity) integration . CI , integration . release candidate. . . , end-to-end , staging . production. , staging .