يعد تمثيل البنية التحتية كرمز في تنسيق نصي قابل للتكرار من أفضل الممارسات البسيطة للأنظمة التي لا تتطلب التلاعب بالماوس. هذه الممارسة لها اسم - ، وحتى الآن هناك أداتان شائعتان لتنفيذه، خاصة في AWS: и .
مقارنة الخبرة مع Terraform وCloudFormation
قبل المجيء إلى (الملقب ) أنا عملت واستخدمت Terraform لمدة ثلاث سنوات. في المكان الجديد، استخدمت أيضًا Terraform بكل قوتي، ثم دفعت الشركة بالانتقال إلى كل شيء على غرار Amazon، بما في ذلك CloudFormation. لقد عملت بجد على تطوير أفضل الممارسات لكليهما، واستخدمت كلتا الأداتين في عمليات سير عمل معقدة للغاية على مستوى المؤسسة. لاحقًا، بعد دراسة مضامين الانتقال من Terraform إلى CloudFormation بشكل مدروس، أصبحت مقتنعًا بأن Terraform ربما كان الخيار الأفضل للمؤسسة.
Terraform الرهيبة
برنامج بيتا
لم تصدر Terraform الإصدار 1.0 حتى الآن، وهذا سبب وجيه لعدم استخدامه. لقد تغير كثيرًا منذ أن جربته بنفسي لأول مرة، ولكن في ذلك الوقت terraform apply غالبًا ما يتعطل بعد عدة تحديثات أو ببساطة بعد عامين من الاستخدام. أود أن أقول إن "كل شيء مختلف الآن"، ولكن... هذا ما يقوله الجميع، أليس كذلك؟ هناك تغييرات غير متوافقة مع الإصدارات السابقة، على الرغم من أنها مناسبة، ويبدو أن بناء الجملة وتجريدات مخازن الموارد هي ما نحتاجه الآن. يبدو أن الأداة قد تحسنت بالفعل، ولكن... :-0
من ناحية أخرى، قامت AWS بعمل جيد في الحفاظ على التوافق مع الإصدارات السابقة. ربما يكون السبب في ذلك هو أن خدماتهم غالبًا ما يتم اختبارها بدقة داخل المؤسسة، وبعد ذلك فقط يتم نشرها وإعادة تسميتها. لذا فإن عبارة "لقد حاولوا جاهدين" هي عبارة بخس. يعد الحفاظ على التوافق مع الإصدارات السابقة مع واجهات برمجة التطبيقات لنظام متنوع ومعقد مثل AWS أمرًا صعبًا للغاية. يجب على أي شخص اضطر إلى الاحتفاظ بواجهات برمجة التطبيقات العامة التي يتم استخدامها على نطاق واسع أن يفهم مدى صعوبة القيام بذلك لسنوات عديدة. لكن سلوك CloudFormation، في ذاكرتي، لم يتغير أبدًا على مر السنين.
تعرف على الساق...إنها رصاصة
بقدر ما أعرف، حذف المورد دخيل مكدس CloudFormation من مكدس CF الخاص بك غير ممكن. وينطبق الشيء نفسه على Terraform. يسمح لك باستيراد الموارد الموجودة إلى مجموعتك. يمكن القول أن الوظيفة مذهلة، ولكن مع القوة الكبيرة تأتي مسؤولية كبيرة. تحتاج فقط إلى إضافة مورد إلى المكدس، وأثناء العمل مع المكدس الخاص بك، لا يمكنك حذف هذا المورد أو تغييره. ذات يوم جاءت بنتائج عكسية. في أحد الأيام على Twitch، قام شخص ما عن طريق الخطأ باستيراد مجموعة أمان AWS الخاصة بشخص آخر إلى مكدس Terraform الخاص به دون أن يتسبب في أي ضرر. لقد أدخلت عدة أوامر و... اختفت مجموعة الأمان (مع حركة المرور الواردة).
Terraform عظيم
التعافي من الحالات غير المكتملة
في بعض الأحيان يفشل CloudFormation في الانتقال بشكل كامل من حالة إلى أخرى. وفي الوقت نفسه، سيحاول العودة إلى السابق. ومن المؤسف أن هذا ليس ممكنا دائما. قد يكون تصحيح ما حدث لاحقًا أمرًا مخيفًا للغاية - فأنت لا تعرف أبدًا ما إذا كانت CloudFormation ستكون سعيدة بتعرضها للاختراق - حتى لإصلاحها فقط. سواء كان من الممكن العودة إلى الحالة السابقة أم لا، فهو لا يعرف حقًا كيفية تحديد ذلك، وبشكل افتراضي، يتوقف لساعات في انتظار حدوث معجزة.
من ناحية أخرى، يميل Terraform إلى التعافي من التحولات الفاشلة بشكل أكثر رشاقة ويوفر أدوات تصحيح أخطاء متقدمة.
تغييرات أكثر وضوحًا في حالة المستند
"حسنًا، يا موازن الأحمال، أنت تتغير. ولكن كيف؟"
- مهندس قلق، جاهز للضغط على زر "القبول".
في بعض الأحيان أحتاج إلى إجراء بعض المعالجات باستخدام موازن التحميل في مكدس CloudFormation، مثل إضافة رقم منفذ أو تغيير مجموعة أمان. يعرض ClouFormation التغييرات بشكل سيئ. أقوم، على أحر من الجمر، بفحص ملف yaml مرة أخرى عشر مرات للتأكد من أنني لم أمسح أي شيء ضروري ولم أضف أي شيء غير ضروري.
Terraform أكثر شفافية في هذا الصدد. في بعض الأحيان يكون شفافًا جدًا (اقرأ: ممل). ولحسن الحظ، يتضمن الإصدار الأخير عرضًا محسّنًا للتغييرات بحيث يمكنك الآن رؤية ما يتغير بالضبط.
مرونة
كتابة البرامج إلى الوراء.
وبعبارة صريحة، فإن أهم ما يميز البرمجيات طويلة العمر هو القدرة على التكيف مع التغيير. كتابة أي برنامج إلى الوراء. في أغلب الأحيان، ارتكبت أخطاء عندما أخذت خدمة "بسيطة"، ثم بدأت في حشر كل شيء في حزمة CloudFormation أو Terraform واحدة. وبالطبع، بعد أشهر تبين أنني فهمت كل شيء بشكل خاطئ، والخدمة في الواقع لم تكن بسيطة! والآن أحتاج إلى تقسيم المكدس الكبير بطريقة أو بأخرى إلى مكونات صغيرة. عند العمل مع CloudFormation، لا يمكن القيام بذلك إلا عن طريق إعادة إنشاء المكدس الموجود أولاً، ولا أفعل ذلك مع قواعد البيانات الخاصة بي. من ناحية أخرى، أتاح Terraform إمكانية تشريح المكدس وتقسيمه إلى أجزاء أصغر يمكن فهمها بشكل أكبر.
الوحدات في بوابة
تعد مشاركة كود Terraform عبر مجموعات متعددة أسهل بكثير من مشاركة كود CloudFormation. باستخدام Terraform، يمكنك وضع التعليمات البرمجية الخاصة بك في مستودع git والوصول إليها باستخدام التحكم في الإصدار الدلالي. يمكن لأي شخص لديه حق الوصول إلى هذا المستودع إعادة استخدام الكود المشترك. ما يعادل CloudFormation هو S3، لكنه لا يتمتع بنفس الفوائد، وليس هناك سبب يجعلنا نتخلى عن git لصالح S3 على الإطلاق.
نمت المنظمة ووصلت القدرة على مشاركة الأكوام المشتركة إلى مستوى حرج. يجعل Terraform كل هذا أمرًا سهلاً وطبيعيًا، في حين أن CloudFormation سوف يجعلك تقفز عبر الأطواق قبل أن تتمكن من تنفيذ شيء مثل هذا.
العمليات كرمز
"دعونا نكتبها وحسنًا."
- مهندس قبل 3 سنوات من اختراع دراجة Terraform.
عندما يتعلق الأمر بتطوير البرامج، فإن برنامج Go أو Java ليس مجرد كود.
الكود كرمز
هناك أيضًا البنية التحتية التي تعمل عليها.
البنية التحتية كرمز
ولكن من أين هي؟ كيفية مراقبته؟ أين يعيش الكود الخاص بك؟ هل يحتاج المطورون إلى إذن الوصول؟
العمليات كرمز
كونك مطور برامج لا يعني فقط كتابة التعليمات البرمجية.
AWS ليست الوحيدة: ربما تستخدم موفري خدمات آخرين. SignalFx أو PagerDuty أو Github. ربما لديك خادم Jenkins داخلي لـ CI/CD أو لوحة معلومات Grafana داخلية للمراقبة. يتم اختيار Infra as Code لأسباب مختلفة، ولكل منها نفس القدر من الأهمية لكل ما يتعلق بالبرمجيات.
عندما عملت في Twitch، قمنا بتسريع الخدمات داخل أنظمة Amazon المدمجة وأنظمة AWS. لقد أنتجنا ودعمنا العديد من الخدمات الصغيرة، مما أدى إلى زيادة تكاليف التشغيل. وكانت المناقشات تسير على النحو التالي:
- Я: اللعنة، هذه الكثير من الإيماءات لرفع تردد التشغيل لخدمة صغيرة واحدة. سيتعين علي استخدام هذه البيانات المهملة لإنشاء حساب AWS (ذهبنا إلى حسابين في خدمة مصغرة)، ثم هذا لإعداد التنبيهات، وهذا لمستودع التعليمات البرمجية، وهذا لقائمة البريد الإلكتروني، ثم هذا...
- قيادة: دعونا نصه وحسنا.
- Я: حسنا، ولكن البرنامج النصي نفسه سوف يتغير. سنحتاج إلى طريقة للتحقق من أن جميع أدوات Amazon المضمنة هذه محدثة.
- قيادة: ًيبدو جيدا. وسنكتب سيناريو لهذا.
- Я: عظيم! وربما سيظل البرنامج النصي بحاجة إلى تعيين المعلمات. هل سيقبلهم؟
- قيادة:دعه يأخذ حيث يذهب!
- Я: قد تتغير العملية وسيتم فقدان التوافق مع الإصدارات السابقة. ستكون هناك حاجة إلى نوع من التحكم في الإصدار الدلالي.
- قيادة: فكرة عظيمة!
- Я: يمكن تغيير الأدوات يدويا، داخل واجهة المستخدم. سنحتاج إلى طريقة للتحقق من ذلك وإصلاحه.
…بعد 3 سنوات:
- قيادة: وحصلنا على Terraform.
المغزى من القصة هو : حتى لو كنت رأسا على عقب في كل شيء الأمازون، فأنت لا تزال تستخدم شيئًا ليس من AWS، وهذه الخدمات لها حالة تستخدم لغة تكوين للحفاظ على مزامنة هذه الحالة.
CloudFormation lambda مقابل git Modules Terraform
lambda هو حل CloudFormation لمشكلة المنطق المخصص. مع لامدا يمكنك أو . يقدم هذا الأسلوب تعقيدات إضافية غير موجودة في الإصدار الدلالي لوحدات git الخاصة بـ Terraform. بالنسبة لي، كانت المشكلة الأكثر إلحاحًا هي إدارة الأذونات لجميع مستخدمين lambdas (وهذه العشرات من حسابات AWS). مشكلة أخرى مهمة كانت مشكلة "ما الذي جاء أولاً، الدجاجة أم البيضة؟": كانت مرتبطة برمز لامدا. هذه الوظيفة بحد ذاتها عبارة عن بنية تحتية وتعليمات برمجية، وتحتاج في حد ذاتها إلى المراقبة والتحديث. كان المسمار الأخير في النعش هو صعوبة التحديث الدلالي لتغييرات كود لامدا؛ كان علينا أيضًا التأكد من أن إجراءات المكدس بدون أمر مباشر لم تتغير بين عمليات التشغيل.
أتذكر ذات مرة أنني أردت إنشاء نشر كناري لبيئة Elastic Beanstalk باستخدام موازن التحميل الكلاسيكي. أسهل ما يمكنك فعله هو إجراء عملية نشر ثانية لـ EB بجانب بيئة الإنتاج، مما يؤدي إلى خطوة أخرى إلى الأمام: دمج مجموعة نشر Canary ذات القياس التلقائي مع LB النشر في بيئة الإنتاج. ومنذ أن يستخدم Terraform ، سيتطلب هذا 4 أسطر إضافية من التعليمات البرمجية في Terraform. عندما سألت عما إذا كان هناك حل مشابه في CloudFormation، وجهوني إلى مستودع git كامل مع مسار نشر وكل شيء، كل ذلك من أجل شيء يمكن أن تفعله 4 أسطر فقيرة من كود Terraform.
يكتشف الانجراف بشكل أفضل
تأكد من أن الواقع يطابق التوقعات.
هي عمليات قوية جدًا كميزة تعليمات برمجية لأنها تساعد على ضمان مطابقة الواقع للتوقعات. وهي متوفرة مع كل من CloudFormation وTerraform. ولكن مع نمو مجموعة الإنتاج، أدى البحث عن الانجراف في CloudFormation إلى إنتاج المزيد والمزيد من الاكتشافات الخاطئة.
مع Terraform، لديك خطافات دورة حياة أكثر تقدمًا لاكتشاف الانجراف. على سبيل المثال، قمت بإدخال الأمر مباشرة في تعريف مهمة ECS إذا كنت تريد تجاهل التغييرات التي تم إجراؤها على تعريف مهمة معينة دون تجاهل التغييرات التي تم إجراؤها على نشر ECS بالكامل.
CDK ومستقبل CloudFormation
من الصعب إدارة CloudFormation على نطاقات واسعة عبر البنية التحتية. تم التعرف على العديد من هذه الصعوبات وتحتاج الأداة إلى أشياء مثل ، إطار عمل لتحديد البنية التحتية السحابية في التعليمات البرمجية وتشغيلها من خلال AWS CloudFormation. سيكون من المثير للاهتمام رؤية ما يخبئه المستقبل لـ aws-cdk، لكنه سيواجه صعوبة في التنافس مع نقاط القوة الأخرى في Terraform؛ لتحديث CloudFormation، ستكون هناك حاجة إلى تغييرات عالمية.
حتى لا يخيب Terraform
هذه هي "البنية التحتية كرمز"، وليس "كنص".
كان انطباعي الأول عن Terraform سيئًا إلى حد ما. أعتقد أنني لم أفهم هذا النهج. ينظر إليه جميع المهندسين تقريبًا بشكل لا إرادي على أنه تنسيق نص يجب تحويله إلى البنية التحتية المطلوبة. لا تفعل ذلك بهذه الطريقة.
تنطبق بديهيات تطوير البرمجيات الجيدة أيضًا على Terraform.
لقد رأيت العديد من الممارسات المعتمدة لإنشاء تعليمات برمجية جيدة يتم تجاهلها في Terraform. لقد درست لسنوات لتصبح مبرمجًا جيدًا. لا تتخلى عن هذه التجربة لمجرد أنك تعمل مع Terraform. تنطبق بديهيات تطوير البرمجيات الجيدة على Terraform.
كيف لا يمكن توثيق الكود؟
لقد رأيت مجموعات Terraform ضخمة بدون أي وثائق على الإطلاق. كيف يمكنك كتابة التعليمات البرمجية في الصفحات - بدون أي وثائق على الإطلاق؟ أضف الوثائق التي تشرح رمز Terraform (التركيز على كلمة "code")، وسبب أهمية هذا القسم، وماذا تفعل.
كيف يمكننا نشر الخدمات التي كانت ذات يوم وظيفة رئيسية واحدة كبيرة؟
لقد رأيت مجموعات Terraform معقدة للغاية مقدمة كوحدة واحدة. لماذا لا ننشر البرمجيات بهذه الطريقة؟ لماذا نقسم الوظائف الكبيرة إلى وظائف أصغر؟ تنطبق نفس الإجابات على Terraform. إذا كانت وحدتك كبيرة جدًا، فستحتاج إلى تقسيمها إلى وحدات أصغر.
ألا تستخدم شركتك المكتبات؟
لقد رأيت كيف أن المهندسين، الذين بدأوا مشروعًا جديدًا باستخدام Terraform، قاموا بغباء بنسخ أجزاء ضخمة من مشاريع أخرى ولصقها في مشاريعهم الخاصة، ثم قاموا بالتلاعب بها حتى بدأ العمل. هل ستعمل بهذه الطريقة مع الكود "القتال" في شركتك؟ نحن لا نستخدم المكتبات فقط. نعم، ولكن أين نحن بدون المكتبات المشتركة من حيث المبدأ؟!
ألا تستخدم PEP8 أو gofmt؟
تحتوي معظم اللغات على نظام تنسيق قياسي ومقبول. في بايثون هذا هو PEP8. في الذهاب - الحكومة. Terraform له خاصيته: terraform fmt. استمتع بها من أجل صحتك!
هل ستستخدم React دون معرفة JavaScript؟
يمكن لوحدات Terraform تبسيط جزء من البنية التحتية المعقدة التي تقوم بإنشائها، ولكن هذا لا يعني أنه لا يمكنك العبث بها على الإطلاق. هل تريد استخدام Terraform بشكل صحيح دون فهم الموارد؟ لقد محكوم عليك بالفشل: سوف يمر الوقت، ولن تتقن Terraform أبدًا.
هل تقوم بالبرمجة باستخدام المفردات أو حقن التبعية؟
يعد حقن التبعية من أفضل الممارسات المعترف بها لتطوير البرمجيات ويفضل على المفردات. كيف يكون هذا مفيدًا في Terraform؟ لقد رأيت وحدات Terraform التي تعتمد على الحالة البعيدة. بدلاً من كتابة وحدات تسترد الحالة البعيدة، اكتب وحدة تأخذ المعلمات. ثم قم بتمرير هذه المعلمات إلى الوحدة النمطية.
هل مكتباتك تفعل عشرة أشياء بشكل جيد أم شيء واحد عظيم؟
المكتبات التي تعمل بشكل أفضل هي تلك التي تركز على مهمة واحدة تقوم بها بشكل جيد للغاية. بدلاً من كتابة وحدات Terraform الكبيرة التي تحاول القيام بكل شيء مرة واحدة، قم ببناء أجزاء منها تؤدي شيئًا واحدًا بشكل جيد. ومن ثم الجمع بينهما حسب الحاجة.
كيف يمكنك إجراء تغييرات على المكتبات دون التوافق مع الإصدارات السابقة؟
تحتاج وحدة Terraform الشائعة، مثل المكتبة العادية، إلى توصيل التغييرات بطريقة أو بأخرى إلى المستخدمين دون أن تكون متوافقة مع الإصدارات السابقة. إنه أمر مزعج عندما تحدث هذه التغييرات في المكتبات، كما أنه مزعج أيضًا عند إجراء تغييرات غير متوافقة مع الإصدارات السابقة في وحدات Terraform. يوصى باستخدام علامات git وsemver عند استخدام وحدات Terraform.
هل تعمل خدمة الإنتاج الخاصة بك على الكمبيوتر المحمول الخاص بك أو في مركز البيانات؟
لدى Hashicorp أدوات مثل لتشغيل Terraform الخاص بك. تسهل هذه الخدمات المركزية إدارة تغييرات التضاريس ومراجعتها والموافقة عليها.
لا تكتب الاختبارات؟
يدرك المهندسون أن التعليمات البرمجية تحتاج إلى اختبار، لكنهم غالبًا ما ينسون الاختبار عند العمل مع Terraform. بالنسبة للبنية التحتية، فإن هذا محفوف باللحظات الغادرة. نصيحتي هي "اختبار" أو "إنشاء أمثلة" للحزم باستخدام الوحدات النمطية التي يمكن نشرها بشكل صحيح للاختبار أثناء CI/CD.
Terraform والخدمات الصغيرة
تعتمد حياة وموت شركات الخدمات الصغيرة على سرعة مجموعات عمل الخدمات الصغيرة الجديدة وابتكارها وتعطيلها.
الجانب السلبي الأكثر شيوعًا المرتبط بهندسة الخدمات الصغيرة، والذي لا يمكن التخلص منه، يتعلق بالعمل وليس بالكود. إذا كنت تعتقد أن Terraform هو مجرد وسيلة لأتمتة جانب البنية التحتية فقط لبنية الخدمات الصغيرة، فأنت تفوت الفوائد الحقيقية للنظام. الآن أصبح الأمر كذلك بالفعل .
المصدر: www.habr.com