البنية التحتية كرمز: التعارف الأول

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

استمرار لسلسلة من المقالات المكتوبة بناءً على الخطب التي ألقيت في حدثنا الداخلي منتدى التطوير:

1. قطة شرودنجر بدون صندوق: مشكلة الإجماع في الأنظمة الموزعة.
2. البنية التحتية كرمز. (أنت هنا)
3. إنشاء عقود Typescript باستخدام نماذج C#. (في تَقَدم...)
4. مقدمة إلى خوارزمية إجماع رافت. (في تَقَدم...)
...

قررنا إنشاء فريق SRE لتنفيذ الأفكار جوجل سر. قاموا بتجنيد مبرمجين من بين مطوريهم وأرسلوهم للتدريب لعدة أشهر.

وقام الفريق بالمهام التدريبية التالية:

• وصف البنية التحتية لدينا، والتي تكون في الغالب في Microsoft Azure في شكل تعليمات برمجية (Terraform وكل شيء حولها).
• تعليم المطورين كيفية العمل مع البنية التحتية.
• إعداد المطورين للواجب.

نقدم مفهوم البنية التحتية كرمز

في النموذج المعتاد للعالم (الإدارة الكلاسيكية)، تقع المعرفة بالبنية التحتية في مكانين:

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

وفي كلتا الحالتين، نجد أنفسنا محاصرين في أن نصبح تابعين:

• أو من شخص مميت، يخضع للمرض، والوقوع في الحب، وتقلب المزاج، وببساطة تسريح العمال؛
• أو من آلة تعمل جسديًا، فتسقط أيضًا وتتعرض للسرقة وتسبب المفاجآت والإزعاجات.

وغني عن القول أنه من الناحية المثالية يجب ترجمة كل شيء إلى كود مكتوب بشكل جيد ويمكن قراءته وقابل للصيانة.

وبالتالي، فإن البنية التحتية كرمز (Incfastructure as Code - IaC) هي وصف للبنية التحتية الحالية بالكامل في شكل كود، بالإضافة إلى الأدوات ذات الصلة للعمل معها وتنفيذ البنية التحتية الحقيقية منها.

لماذا تترجم كل شيء إلى كود؟الناس ليسوا آلات. لا يمكنهم تذكر كل شيء. رد فعل الشخص والآلة مختلف. من المحتمل أن يكون أي شيء آلي أسرع من أي شيء يفعله الإنسان. الشيء الأكثر أهمية هو مصدر واحد للحقيقة.

من أين يأتي مهندسو SRE الجدد؟لذلك، قررنا توظيف مهندسين جدد في SRE، ولكن من أين نحصل عليهم؟ الكتاب بالإجابات الصحيحة (كتاب جوجل SRE) يخبرنا: من المطورين. بعد كل شيء، إنهم يعملون مع الكود، ويمكنك تحقيق الحالة المثالية.

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

مشاكل البنية التحتية كرمز

الآن دعونا نلقي نظرة على أمثلة لكيفية تحويل البنية التحتية إلى كود برمجي. الكود مكتوب بشكل جيد، عالي الجودة، مع التعليقات والمسافات البادئة.

رمز المثال من Terraforma.

رمز المثال من Ansible.

أيها السادة، لو كان الأمر بهذه البساطة! نحن في العالم الحقيقي، وهو مستعد دائمًا لمفاجأتك وتقديم المفاجآت والمشاكل لك. لا أستطيع الاستغناء عنهم هنا أيضًا.

1. المشكلة الأولى هي أن IaC في معظم الحالات هو نوع من DSL.

وDSL، بدوره، هو وصف للهيكل. بتعبير أدق، ما يجب أن يكون لديك: Json، Yaml، تعديلات من بعض الشركات الكبيرة التي توصلت إلى DSL الخاصة بها (يتم استخدام HCL في Terraform).

المشكلة هي أنه قد لا يحتوي بسهولة على أشياء مألوفة مثل:

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

2. المشكلة الثانية في مثل هذا الكود هي أنه غالبًا ما يكون بيئة غير متجانسة. عادةً ما تجلس وتعمل باستخدام لغة C#، أي لغة C#. مع لغة واحدة، ومكدس واحد، ونظام بيئي واحد. وهنا لديك مجموعة كبيرة ومتنوعة من التقنيات.

إنه موقف حقيقي جدًا عندما يطلق bash with python بعض العمليات التي يتم إدراج Json فيها. تقوم بتحليله، ثم يقوم أحد المولدات الأخرى بإنتاج 30 ملفًا آخر. لكل هذا، يتم تلقي متغيرات الإدخال من Azure Key Vault، والتي يتم تجميعها معًا بواسطة مكون إضافي لـ Drone.io مكتوب بلغة Go، وتمر هذه المتغيرات عبر yaml، والتي تم إنشاؤها نتيجة للتوليد من محرك قالب jsonnet. من الصعب جدًا أن يكون لديك تعليمات برمجية موصوفة جيدًا عندما يكون لديك مثل هذه البيئة المتنوعة.

التنمية التقليدية في إطار مهمة واحدة تأتي مع لغة واحدة. نحن هنا نعمل مع عدد كبير من اللغات.

3. المشكلة الثالثة هي الضبط. لقد اعتدنا على تبريد المحررين (Ms Visual Studio وJetbrains Rider) الذين يقومون بكل شيء من أجلنا. وحتى لو كنا أغبياء، فسيقولون أننا مخطئون. يبدو طبيعيا وطبيعيا.

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

في وقت كتابة هذه السطور البرنامج المساعد vscode-terraform لم يتم إصداره بعد لدعم الإصدار 0.12، على الرغم من أنه تم إصداره منذ 3 أشهر.

حان الوقت لنسيان...

1. التصحيح.
2. أداة إعادة البناء.
3. الإكمال التلقائي.
4. اكتشاف الأخطاء أثناء التجميع.

إنه أمر مضحك، ولكن هذا يزيد أيضًا من وقت التطوير ويزيد من عدد الأخطاء التي تحدث حتمًا.

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

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

ماذا عن الاختبارات؟

تسأل: “وماذا عن الاختبارات أيها السادة المبرمجون؟” يختبر الرجال الجادون كل شيء في الإنتاج، وهو أمر صعب. فيما يلي مثال لاختبار الوحدة لوحدة terraform من موقع الويب مایکروسافت.

لديهم وثائق جيدة. لقد أحببت دائمًا Microsoft لنهجها في التوثيق والتدريب. لكن ليس من الضروري أن تكون العم بوب لكي تفهم أن هذا ليس رمزًا مثاليًا. لاحظ التحقق من الصحة على اليمين.

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

من الصعب تحليل Json في Go. وتحتاج إلى الكتابة بلغة Go، لأن terraform in Go يعد ممارسة جيدة للاختبار باللغة التي تكتب بها. تنظيم الكود نفسه ضعيف جدًا. وفي الوقت نفسه، هذه هي أفضل مكتبة للاختبار.

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

أفضل ممارسات البنية التحتية كرمز

هيا لنذهب. إذا لم تكن هناك اختبارات في IaC، وكان IDE والضبط سيئين، فيجب أن تكون هناك على الأقل أفضل الممارسات. لقد ذهبت للتو إلى Google Analytics وقمت بمقارنة استعلامي بحث: أفضل ممارسات Terraform وأفضل ممارسات C#.

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

أما بالنسبة لطلب IaC: فأنت تحاول هنا جمع المعلومات شيئًا فشيئًا من تقارير التحميل العالي أو تقارير HashiConf، ومن الوثائق الرسمية والعديد من المشكلات على Github. كيفية توزيع هذه الوحدات بشكل عام وماذا تفعل بها؟ يبدو أن هذه مشكلة حقيقية... هناك مجتمع، أيها السادة، حيث سيتم إعطاؤكم 10 تعليقات على جيثب لأي سؤال. ولكن الأمر ليس بالضبط.

ولسوء الحظ، في هذا الوقت، بدأ الخبراء في الظهور للتو. هناك عدد قليل جدا منهم حتى الآن. والمجتمع نفسه يتسكع على المستوى البدائي.

أين يذهب كل هذا وماذا تفعل

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

أنا شخصياً أراهن على عدة أشياء:

1. التطور في هذا المجال يحدث بسرعة كبيرة. فيما يلي جدول طلبات DevOps.

   
   
   ربما يكون الموضوع مثيراً للضجيج، لكن حقيقة أن المجال ينمو يعطي بعض الأمل.

   إذا كان هناك شيء ينمو بسرعة كبيرة، فسيظهر بالتأكيد الأشخاص الأذكياء الذين سيخبرونك بما يجب عليك فعله وما لا يجب فعله. تؤدي الزيادة في الشعبية إلى حقيقة أنه ربما يكون لدى شخص ما الوقت الكافي لإضافة مكون إضافي إلى jsonnet لـ vscode، مما سيسمح لك بالانتقال إلى تنفيذ الوظيفة، بدلاً من البحث عنها عبر ctrl+shift+f. مع تطور الأشياء، تظهر المزيد من المواد. يعد إصدار كتاب من Google حول SRE مثالًا ممتازًا على ذلك.

2. هناك تقنيات وممارسات متطورة في التطوير التقليدي يمكننا تطبيقها بنجاح هنا. نعم، هناك فروق دقيقة في الاختبار وبيئة غير متجانسة، وأدوات غير كافية، ولكن تم تراكم عدد كبير من الممارسات التي يمكن أن تكون مفيدة ومفيدة.

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

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

اختتام

على الرغم من أن تفكيري قد يبدو متشائمًا، إلا أنني أتطلع إلى المستقبل بأمل وآمل مخلصًا أن ينجح كل شيء معنا (وأنت).

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

المصدر: www.habr.com