يعرف الكثير من الأشخاص Terraform ويستخدمونه في عملهم اليومي ، ولكن لا توجد حتى الآن أفضل الممارسات لذلك. يجب على كل فريق أن يبتكر مناهجه وطرقه الخاصة.
من شبه المؤكد أن بنيتك التحتية تبدأ بالبساطة: بعض الموارد + عدد قليل من المطورين. بمرور الوقت ، ينمو في كل الاتجاهات. هل تجد طرقًا لتجميع الموارد في وحدات Terraform النمطية ، وتنظيم التعليمات البرمجية في مجلدات ، وما الذي يمكن أن يحدث بشكل خاطئ أيضًا؟ (اشهر اخر كلمات)
يمر الوقت وتشعر أن بنيتك التحتية هي حيوانك الأليف الجديد ، لكن لماذا؟ أنت قلق بشأن التغييرات التي لا يمكن تفسيرها في البنية التحتية ، وتخشى أن تلمس البنية التحتية والرمز - ونتيجة لذلك ، فإنك تؤخر وظائف جديدة أو تقلل الجودة ...
بعد ثلاث سنوات من إدارة مجموعة من وحدات مجتمع Terraform لـ AWS على Github وصيانة طويلة الأجل لـ Terraform في الإنتاج ، أصبح Anton Babenko جاهزًا لمشاركة خبرته: كيفية كتابة وحدات TF بحيث لا تتأذى في المستقبل.
بحلول نهاية الحديث ، سيكون الحاضرون أكثر دراية بمبادئ إدارة موارد Terraform وأفضل الممارسات المتعلقة بوحدة Terraform وبعض مبادئ التكامل المستمر المتعلقة بإدارة البنية التحتية.
تنصل: ألاحظ أن هذا التقرير مؤرخ في نوفمبر 2018 - مرت سنتان. لم يعد إصدار Terraform 2 الوارد في التقرير مدعومًا. على مدار العامين الماضيين ، تم إصدار إصدارين جديدين ، ظهر فيهما الكثير من الابتكارات والتحسينات والتغييرات. يرجى الانتباه إلى هذا والتحقق من الوثائق.
المراجع:
- +
- - التنسيق التلقائي للرمز والوثائق
- - مولد وحدات Terraform (WIP)
- - مولد كود Terraform من الرسوم البيانية المرئية (WIP)
- www.terraform-best-practices.com
- (المنشورات الجديدة موجودة على الموقع الشخصي www.antonbabenko.com/)
- antonbabenko - تويتر ، ومجموعة من Slacks المختلفة
اسمي انطون بابينكو. لابد أن بعضكم قد استخدم الكود الذي كتبته. سأتحدث الآن عن هذا بثقة أكبر من أي وقت مضى ، لأن لدي إمكانية الوصول إلى الإحصائيات.
أنا منخرط في Terraform وكنت مساهمًا نشطًا ومساهمًا في عدد كبير من المشاريع مفتوحة المصدر المتعلقة بـ Terraform و Amazon منذ عام 2015.
منذ ذلك الحين ، قمت بكتابة ما يكفي من التعليمات البرمجية لجعل هذا الأمر ممتعًا. وسأحاول الحديث عن هذا الآن.
سأتحدث عن تعقيدات وتفاصيل العمل مع Terraform. لكن في الحقيقة ليس موضوع HighLoad. والآن ستفهم لماذا.
بمرور الوقت ، بدأت في كتابة وحدات Terraform. كتب المستخدمون أسئلة ، أعدت كتابتها. ثم قمت بكتابة العديد من أدوات تنسيق التعليمات البرمجية باستخدام خطافات الالتزام المسبق ، وما إلى ذلك.
كان هناك العديد من المشاريع المثيرة للاهتمام. أحب إنشاء الكود لأنني أحب أن يقوم الكمبيوتر بالمزيد والمزيد من العمل من أجلي وللمبرمج ، لذلك أنا أعمل حاليًا على منشئ كود Terraform من الرسوم البيانية المرئية. ربما رآهم البعض منكم. هذه صناديق جميلة بها سهام. وأعتقد أنه من الرائع أن تتمكن من النقر فوق الزر "تصدير" والحصول على كل ذلك كرمز.
أنا من أوكرانيا. لقد عشت في النرويج لسنوات عديدة.
أيضًا ، تم جمع المعلومات الخاصة بهذا التقرير من أشخاص يعرفون اسمي ويجدونني على الشبكات الاجتماعية. أنا دائما تقريبا نفس الاسم المستعار.
كما ذكرت ، أنا المشرف الرئيسي على وحدات Terraform AWS ، والتي تعد واحدة من أكبر مستودعات GitHub حيث نستضيف وحدات للمهام الأكثر شيوعًا: VPC ، Autoscaling ، RDS.
وما سمعته الآن هو أبسط. إذا كنت تشك في أنك تفهم ما هو Terraform ، فمن الأفضل أن تقضي وقتك في مكان آخر. سيكون هناك الكثير من المصطلحات الفنية هنا. ولم أتردد في إعلان مستوى التقرير على أنه الأعلى. هذا يعني أنه يمكنني التحدث باستخدام جميع المصطلحات الممكنة دون الكثير من الشرح.
ظهر Terraform في عام 2014 كأداة تتيح لك كتابة وتخطيط وإدارة البنية التحتية كرمز. المفهوم الرئيسي هنا هو "البنية التحتية كرمز".
جميع الوثائق ، كما قلت ، مكتوبة بها . آمل أن يعرف معظم الناس عن هذا الموقع وقد قرأوا الوثائق. إذا كان الأمر كذلك ، فأنت في المكان الصحيح.
هكذا يبدو ملف تكوين Terraform العادي ، حيث نحدد أولاً بعض المتغيرات.
في هذه الحالة ، نحدد "aws_region".
ثم نصف الموارد التي نريد إنشاءها.
نقوم بتشغيل بعض الأوامر ، ولا سيما "terraform init" لتحميل التبعيات ، ومقدمي الخدمات.
ونقوم بتشغيل الأمر "terraform apply" للتحقق مما إذا كان التكوين المحدد يطابق الموارد التي أنشأناها. نظرًا لأننا لم ننشئ أي شيء من قبل ، يقترح Terraform أن ننشئ هذه الموارد.
نحن نؤكد هذا. هذه هي الطريقة التي نصنع بها دلو يسمى شراع البحر.
هناك أيضا العديد من المرافق المماثلة. يعرف الكثير منكم ممن يستخدمون Amazon AWS CloudFormation أو Google Cloud Deployment Manager أو Azure Resource Manager. كل واحد منهم لديه نوع من التنفيذ لإدارة الموارد داخل كل من موفري السحابة العامة هؤلاء. Terraform مفيد بشكل خاص لأنه يسمح لك بإدارة أكثر من 100 مزود. (أكثر )
الأهداف التي سعت Terraform لتحقيقها منذ البداية:
- يمنحك Terraform عرضًا واحدًا للموارد.
- يسمح لك بدعم جميع المنصات الحديثة.
- وقد تم تصميم Terraform منذ البداية كأداة تتيح لك تغيير البنية التحتية بأمان وبشكل متوقع.
في عام 2014 ، بدت كلمة "متوقع" غير عادية للغاية في هذا السياق.
Terraform هو أداة عالمية. إذا كانت لديك واجهة برمجة تطبيقات ، فيمكنك التحكم في كل شيء تمامًا:
- يمكنك استخدام أكثر من 120 مزودًا لإدارة كل ما تشتهيه نفسك.
- على سبيل المثال ، يمكنك استخدام Terraform لوصف الوصول إلى مستودعات GitHub.
- يمكنك حتى إنشاء وإغلاق الأخطاء في Jira.
- يمكنك إدارة مقاييس New Relic.
- يمكنك أيضًا إنشاء ملفات في صندوق الإسقاط إذا كنت تريد ذلك حقًا.
يتم تحقيق كل ذلك بمساعدة موفري Terraform ، الذين لديهم واجهة برمجة تطبيقات مفتوحة يمكن وصفها في Go.
لنفترض أننا بدأنا في استخدام Terraform ، اقرأ بعض الوثائق على الموقع ، وشاهدنا بعض مقاطع الفيديو ، وبدأنا في كتابة main.tf ، كما أوضحت في الشرائح السابقة.
وكل شيء رائع معك ، لديك ملف يقوم بإنشاء VPC.
إذا كنت ترغب في إنشاء VPC ، فأنت تحدد هذه السطور الـ 12 تقريبًا. صف المنطقة التي تريد إنشاءها ، وأي cidr_block لعناوين IP يجب استخدامها. وهذا كل شيء.
بطبيعة الحال ، سينمو المشروع تدريجياً.
وستقوم بإضافة مجموعة من الأشياء الجديدة هناك: الموارد ، ومصادر البيانات ، وستتكامل مع مقدمي الخدمات الجدد ، وفجأة سترغب في استخدام Terraform لإدارة المستخدمين على حساب GitHub الخاص بك ، وما إلى ذلك. تريد استخدام مزودي DNS مختلفين ، عبور كل شيء. Terraform يجعل هذا الأمر سهلاً.
تأمل المثال التالي.
أنت تقوم بإضافة internet_gateway تدريجياً لأنك تريد موارد من VPC لديك للوصول إلى الإنترنت. هذه فكرة جيدة.
والنتيجة هي هذا main.tf:
هذا هو الجزء العلوي من main.tf.
هذا هو الجزء السفلي من main.tf.
ثم تقوم بإضافة الشبكة الفرعية. بحلول الوقت الذي تريد فيه إضافة بوابات NAT ومسارات وجداول توجيه ومجموعة من الشبكات الفرعية الأخرى ، لن يكون لديك 38 سطرًا ، بل حوالي 200-300 سطر.
وهذا يعني أن ملف main.tf الخاص بك ينمو تدريجيًا. وغالبًا ما يضع الأشخاص كل شيء في ملف واحد. يظهر 10-20 كيلو بايت في main.tf. تخيل أن 10-20 كيلو بايت عبارة عن محتوى نصي. وكل شيء مرتبط بكل شيء. هذا يزداد صعوبة العمل معه. 10-20 كيلو بايت هي حالة مستخدم جيدة ، وأحيانًا أكثر. ولا يعتقد الناس دائمًا أنه سيء.
كما هو الحال في البرمجة التقليدية ، أي ليس البنية التحتية كرمز ، نحن معتادون على استخدام مجموعة من الفئات والحزم والوحدات والتجمعات المختلفة. يسمح لك Terraform بفعل الشيء نفسه.
- القانون ينمو.
- الاعتماد على الموارد آخذ في الازدياد أيضًا.
ولدينا حاجة كبيرة وكبيرة. نحن نتفهم أننا لم نعد نستطيع أن نعيش هكذا. يصبح الرمز لدينا هائلا. 10-20 كيلو بايت ، بالطبع ، ليست واسعة جدًا ، لكننا نتحدث فقط عن مكدس الشبكة ، أي أنك أضفت موارد الشبكة فقط. نحن لا نتحدث عن Application Load Balancer ، أو مجموعة النشر ES ، أو Kubernetes ، وما إلى ذلك ، حيث لا يزال من السهل نسج 100 كيلوبايت. إذا كتبت كل هذا ، فستكتشف قريبًا أن Terraform يوفر وحدات Terraform.
وحدات Terraform النمطية هي تكوينات Terraform المستقلة التي يتم إدارتها كمجموعة. هذا كل ما تحتاج لمعرفته حول وحدات Terraform. إنهم ليسوا أذكياء على الإطلاق ، ولا يسمحون لك بإجراء أي اتصالات معقدة اعتمادًا على شيء ما. كل ذلك يقع على عاتق المطورين. وهذا يعني أنه مجرد نوع من تكوين Terraform الذي كتبته بالفعل. ويمكنك فقط تسميتها كمجموعة.
لذلك نحن نحاول معرفة كيف سنقوم بتحسين 10-20-30 كيلوبايت من التعليمات البرمجية. نحن نفهم تدريجيًا أننا بحاجة إلى استخدام بعض الوحدات.
النوع الأول من الوحدات النمطية التي تمت مواجهتها هو وحدات الموارد. إنهم لا يفهمون ما هي البنية التحتية الخاصة بك ، وما هو عملك ، وأين وما هي الظروف. هذه هي بالضبط الوحدات التي أديرها أنا ومجتمع المصادر المفتوحة ، والتي طرحناها على أنها اللبنات الأساسية للبنية التحتية الخاصة بك.
مثال على وحدة الموارد.
عندما نستدعي وحدة موارد ، نحدد المسار الذي يجب أن نحمل محتوياته من خلاله.
نحدد الإصدار الذي نريد تنزيله.
نمرر مجموعة من الحجج هناك. وهذا كل شيء. هذا كل ما نحتاج إلى معرفته عند استخدام هذه الوحدة.
يعتقد الكثير من الناس أنه إذا كنت تستخدم أحدث إصدار ، فسيكون كل شيء مستقرًا. لكن لا. يجب إصدار البنية التحتية ، ويجب أن نجيب بوضوح على الإصدار الذي تم نشر هذا المكون أو ذاك.
هذا هو الكود الموجود داخل هذه الوحدة. وحدة مجموعة الأمان. هنا يرتفع التمرير إلى السطر 640. يعد إنشاء مجموعة أمان الموارد في Amazon في جميع أنواع التكوينات مهمة غير تافهة للغاية. لا يكفي مجرد إنشاء مجموعة أمان وإخبارها بالقواعد التي يجب تمريرها إليها. سيكون من السهل جدا. داخل أمازون ، هناك مليون قيود مختلفة. على سبيل المثال ، إذا كنت تستخدم نقطة نهاية VPC ، قائمة البادئة ، واجهات برمجة التطبيقات المختلفة ويحاول عبور كل شيء مع كل شيء ، فإن Terraform لا يسمح لك بالقيام بذلك. ولا تسمح واجهة برمجة تطبيقات أمازون بذلك أيضًا. لذلك ، نحتاج إلى إخفاء كل هذا المنطق الرهيب في وحدة نمطية وإعطاء المستخدم رمزًا يشبه هذا تمامًا.
لا يحتاج المستخدم إلى معرفة كيف يتم ذلك من الداخل.
النوع الثاني من الوحدات ، والذي يتكون من وحدات الموارد ، يحل بالفعل المهام الأكثر قابلية للتطبيق في عملك. غالبًا ما يكون هذا المكان امتدادًا لـ Terraform ويضع بعض القيم الثابتة للعلامات ، لمعايير الشركة. يمكنك أيضًا إضافة وظائف هناك لا يسمح لك Terraform باستخدامها حاليًا. إنه الآن. الآن الإصدار 0.11 ، والذي على وشك أن يصبح شيئًا من الماضي. ولكن مع ذلك ، فإن المعالجات المسبقة و jsonnet و cookiecutter ومجموعة من الأشياء الأخرى هي الآلية المساعدة التي يجب استخدامها للعمل الكامل.
بعد ذلك ، سأعرض بعض الأمثلة على ذلك.
يتم استدعاء وحدة البنية التحتية بنفس الطريقة تمامًا.
يحدد المصدر من مكان تنزيل المحتوى.
يتم تمرير مجموعة من القيم ، والتي يتم تمريرها إلى هذه الوحدة.
علاوة على ذلك ، داخل هذه الوحدة ، يتم استدعاء مجموعة من وحدات الموارد لإنشاء VPC أو Application Load Balancer ، أو لإنشاء مجموعة أمان أو مجموعة خدمة حاوية مرنة.
هناك نوعان من الوحدات. من المهم فهم ذلك ، لأن معظم المعلومات التي جمعتها في هذا التقرير غير مكتوبة في الوثائق.
والتوثيق في Terraform الآن يمثل مشكلة كبيرة ، لأنه يقول فقط أن هناك مثل هذه الميزات ، يمكنك استخدامها. لكنها لا تذكر كيفية استخدام هذه الميزات ، ولماذا من الأفضل استخدامها. لذلك ، يكتب عدد كبير جدًا من الأشخاص شيئًا لا يمكنك التعايش معه لاحقًا.
دعونا نرى كيفية كتابة هذه الوحدات بعد ذلك. ثم سنرى كيفية الاتصال بهم وكيفية العمل مع الكود.
سجل Terraform -
النصيحة رقم 0 هي عدم كتابة وحدات الموارد. تمت كتابة معظم هذه الوحدات بالفعل من أجلك. كما قلت ، فهي مفتوحة المصدر ، ولا تحتوي على أي منطق عملك ، ولا تحتوي على قيم مشفرة لعناوين IP ، وكلمات المرور ، وما إلى ذلك. الوحدة مرنة للغاية. وربما تكون مكتوبة بالفعل. هناك الكثير من الوحدات النمطية للموارد من Amazon. حوالي 650. ومعظمهم من نوعية جيدة.
في هذا المثال ، يأتي إليك شخص ما ويقول ، "أريد أن أكون قادرًا على إدارة قاعدة البيانات. أنشئ وحدة نمطية حتى أتمكن من إنشاء قاعدة بيانات ". لا يعرف الشخص تفاصيل تنفيذ أمازون أو Terraform. تقول فقط "أريد إدارة MSSQL". وهذا يعني أنه سيتصل بالوحدة الخاصة بنا ، ويمرر نوع المحرك هناك ، ويشير إلى المنطقة الزمنية.
ويجب ألا يعرف الشخص أننا سننشئ مصدرين مختلفين داخل هذه الوحدة: أحدهما لـ MSSQL ، والثاني لكل شيء آخر ، فقط لأنه في Terraform 0.11 لا يمكنك تحديد قيم المنطقة الزمنية على أنها اختيارية.
وعند إخراج هذه الوحدة ، سيتمكن الشخص ببساطة من تلقي العنوان. لن يعرف من أي قاعدة بيانات ، ومن أي مورد ننشئ كل هذا في الداخل. هذا عنصر مهم جدًا للاختباء. وهذا لا ينطبق فقط على تلك الوحدات العامة في المصادر المفتوحة ، ولكن أيضًا لتلك الوحدات التي ستكتبها داخل مشاريعك وفرقك.
هذه هي الحجة الثانية ، وهي مهمة جدًا إذا كنت تستخدم Terraform لفترة من الوقت. لديك مستودع حيث تخزن فيه جميع وحدات Terraform النمطية لشركتك. ومن الطبيعي أنه بمرور الوقت سينمو هذا المشروع إلى حجم واحد أو اثنين ميغا بايت. هذا جيد.
لكن المشكلة تكمن في الطريقة التي يسميها Terraform هذه الوحدات. على سبيل المثال ، إذا اتصلت بوحدة نمطية لإنشاء كل مستخدم فردي ، فسيقوم Terraform أولاً بتنزيل المستودع بالكامل ، ثم الانتقال إلى المجلد حيث توجد هذه الوحدة المحددة. بهذه الطريقة سوف تقوم بتنزيل واحد ميغا بايت في كل مرة. إذا كنت تدير 100 أو 200 مستخدم ، فستقوم بتنزيل 100 أو 200 ميجابايت ، ثم الانتقال إلى هذا المجلد. لذلك ، بطبيعة الحال ، لا تريد تحميل مجموعة من الأشياء في كل مرة تضغط فيها على "Terraform init".
هناك نوعان من الحلول لهذه المشكلة. الأول هو استخدام المسارات النسبية. هذه هي الطريقة التي تحدد في التعليمات البرمجية أن المجلد محلي (./). وقبل أن تقوم بتشغيل أي شيء ، تقوم بعمل نسخة Git من هذا المستودع محليًا. لذلك قمت بذلك مرة واحدة.
هناك بالطبع مجموعة من الجوانب السلبية. على سبيل المثال ، لا يمكنك استخدام الإصدار. وأحيانًا يصعب التعايش معها.
الحل الثاني. إذا كان لديك الكثير من الوحدات الفرعية ولديك بالفعل نوع من خطوط الأنابيب المثبتة ، فهناك مشروع MBT يسمح لك بجمع العديد من الحزم المختلفة من مستودع واحد وتحميلها إلى S3. هذه طريقة جيدة جدا. وبالتالي ، سيكون حجم ملف iam-user-1.0.0.zip 1 كيلوبايت فقط ، لأن كود إنشاء هذا المورد صغير جدًا. وسوف تعمل بشكل أسرع.
دعنا نتحدث عما لا يمكن استخدامه في الوحدات.
لماذا هو شر في وحدات؟ الشيء الأكثر رعبا هو افتراض المستخدم. افترض أن المستخدم هو خيار مصادقة لموفر يمكن استخدامه من قبل أشخاص مختلفين. على سبيل المثال ، سنفترض جميعًا دورًا. هذا يعني أن Terraform سيتولى هذا الدور. وبعد ذلك مع هذا الدور سيتم تنفيذ إجراءات أخرى.
والشر هو أنه إذا كان Vasya يحب الاتصال بـ Amazon بطريقة واحدة ، على سبيل المثال ، باستخدام بيئة متغيرة افتراضيًا ، ويحب Petya استخدام مفتاحه المشترك ، الذي لديه في مكان سري ، فلا يمكن تحديد كليهما في Terraform . ولكي لا يتعرضوا للمعاناة ، لا ينبغي تحديد هذه الكتلة في الوحدة. يجب الإشارة إلى هذا في المستوى الأعلى. وهذا يعني أن لدينا وحدة موارد ووحدة بنية تحتية وتكوينًا في الأعلى. وفي مكان أعلى يجب الإشارة إليه.
الشر الثاني هو الموفر. الشر هنا ليس تافهًا جدًا ، لأنك إذا كتبت رمزًا وكان يعمل من أجلك ، فقد تعتقد أنه إذا نجح ، فلماذا نغيره.
يكمن الشر في حقيقة أنك لا تتحكم دائمًا في هذا المزود عندما يتم إطلاقه على وجه التحديد ، أولاً. وثانيًا ، لا يمكنك التحكم في معنى aws ec2 ، أي أننا نتحدث الآن عن Linux أو عن Windows. وبالتالي ، لا يمكنك كتابة شيء يعمل بنفس الطريقة على أنظمة تشغيل مختلفة أو لحالات مستخدم مختلفة.
المثال الأكثر شيوعًا ، والمشار إليه أيضًا في الوثائق الرسمية ، هو أنك إذا كتبت aws_instance ، وحددت مجموعة من الحجج ، فلا حرج في ذلك إذا حددت أيضًا المزود "local-exec" هناك وقمت بتشغيله. -Playbook.
في الواقع ، نعم ، لا حرج في ذلك. ولكن سرعان ما ستدرك حرفيًا أن هذا الشيء exec المحلي غير موجود ، على سبيل المثال ، في launch_configuration.
وعندما تستخدم launch_configuration ، وتريد إنشاء مجموعة قياس تلقائي من مثيل واحد ، فلا يوجد مفهوم "المزود" في launch_configuration. هناك مفهوم "بيانات المستخدم".
لذلك ، فإن الحل الأكثر شمولية هو استخدام بيانات المستخدم. وسيتم تشغيله إما على المثيل نفسه ، عند تمكين المثيل ، أو في نفس بيانات المستخدم ، عندما تستخدم مجموعة القياس التلقائي هذا launch_configuration.
ومع ذلك ، إذا كانت هناك رغبة في تشغيل الموفر ، لأنه مكون لصق ، فعند إنشاء مورد واحد وفي هذه اللحظة تحتاج إلى تشغيل المزود ، فريقك. هناك العديد من هذه الحالات.
والمورد الأكثر صحة لهذا يسمى null_resource. Null_resource هو مورد وهمي لم يتم إنشاؤه بالفعل. لا تلمس أي شيء ، لا API ، لا autoscaling. لكنه يسمح لك بالتحكم في وقت تشغيل الأمر. في هذه الحالة ، يتم تشغيل الأمر في وقت الإنشاء.
رابط
هناك عدة علامات. لن أخوض في جميع الميزات بتفصيل كبير. هناك مقال حول هذا الموضوع. ولكن إذا كنت قد عملت مع Terraform أو استخدمت وحدات أشخاص آخرين ، فغالبًا ما لاحظت أن العديد من الوحدات ، مثل معظم التعليمات البرمجية في المصدر المفتوح ، كتبها أشخاص لاحتياجاتهم الخاصة. كتبه الرجل وحل مشكلته. لقد صنعته على GitHub ، دعه يعيش. ستعيش ، لكن إذا لم يكن هناك توثيق وأمثلة ، فلن يستخدمها أحد. وإذا لم تكن هناك وظيفة تسمح لك بحل ما هو أكثر بقليل من مهمتها المحددة ، فلن يستخدمها أحد أيضًا. هناك العديد من الطرق لفقدان المستخدمين.
إذا كنت ترغب في كتابة شيء ما ليستخدمه الأشخاص ، فأوصيك باتباع هذه العلامات.
وهذه هي:
- التوثيق والأمثلة.
- وظائف كاملة.
- افتراضات معقولة.
- كود نظيف.
- الاختبارات.
تعتبر الاختبارات حالة منفصلة لأن من الصعب جدًا كتابتها. أنا أؤمن أكثر في التوثيق وفي الأمثلة.
لذلك رأينا كيف نكتب الوحدات. هناك نوعان من الحجج. أولاً ، والأهم من ذلك ، لا تكتب إذا استطعت ، لأن مجموعة من الأشخاص قد قاموا بالفعل بهذه المهام قبلك. والثاني ، إذا كنت لا تزال تقرر ، فحاول عدم استخدام الموفرين في الوحدات النمطية ومقدم الخدمة.
هذا هو الجزء الرمادي من الوثائق. الآن قد تفكر ، "شيء ما غير واضح. غير مقتنع." لكننا سنرى بعد ستة أشهر.
الآن دعنا نتحدث عن كيفية استدعاء هذه الوحدات.
نحن نتفهم أن الكود الخاص بنا ينمو بمرور الوقت. لم يعد لدينا ملف واحد ، لدينا بالفعل 20 ملفًا. كلهم في مجلد واحد. أو ربما خمسة مجلدات. ربما بدأنا في تقسيمها بطريقة أو بأخرى حسب المنطقة ، من خلال بعض المكونات. ثم نفهم أنه لدينا الآن بعض أساسيات التزامن ، يجب أن تنشأ التزامن. بمعنى ، يجب أن نفهم ما يجب فعله إذا قمنا بتغيير موارد الشبكة ، وماذا نفعل ببقية مواردنا ، وكيفية استدعاء هذه التبعيات ، وما إلى ذلك.
هناك نوعان من التطرف. المتطرف الأول هو الكل في واحد. لدينا ملف رئيسي واحد. في الوقت الحالي ، كانت هذه هي أفضل الممارسات الرسمية على موقع Terraform.
ولكن الآن تمت كتابته على أنه مهمل ومُزال. بمرور الوقت ، أدرك مجتمع Terraform أن هذا بعيد كل البعد عن كونه أفضل ممارسة ، لأن الناس يبدأون في استخدام المشروع بطرق مختلفة. وهناك مشاكل. على سبيل المثال ، عندما نحدد جميع التبعيات في مكان واحد. هناك مواقف عندما نضغط على "خطة Terraform" وقد يستغرق الأمر وقتًا طويلاً لـ Terraform لتحديث حالات جميع الموارد.
الكثير من الوقت ، على سبيل المثال ، 5 دقائق. بالنسبة للبعض ، هذا كثير من الوقت. لقد رأيت حالات استغرق فيها الأمر 15 دقيقة. تم تغيير AWS API لمدة 15 دقيقة لفهم ما كان يحدث مع حالة كل مورد. هذه منطقة كبيرة جدًا.
وبالطبع ، ستظهر مشكلة ذات صلة عندما تريد تغيير شيء ما في مكان واحد ، ثم تنتظر 15 دقيقة ، وتعطيك لوحة ببعض التغييرات. لقد بصقت ، وكتبت "نعم" ، وحدث خطأ ما. هذا مثال حقيقي جدا. لا يحاول Terraform عزلك عن المشاكل. هذا هو ، اكتب ما تريد. ستكون هناك مشاكل - مشاكلك. بينما لا يحاول Terraform 0.11 مساعدتك بأي شكل من الأشكال. هناك أماكن معينة مثيرة للاهتمام في 0.12 تتيح لك أن تقول: "فاسيا ، هل تريد هذا حقًا ، هل يمكنك تغيير رأيك؟".
الطريقة الثانية هي تقليل هذه المنطقة ، أي أن المكالمات من مكان واحد من مكان آخر يمكن أن تكون أقل اتصالاً.
المشكلة الوحيدة هي أنك تحتاج إلى كتابة المزيد من التعليمات البرمجية ، أي أنك تحتاج إلى وصف المتغيرات في عدد كبير من الملفات ، قم بتحديث هذا. شخص ما لا يحب ذلك. بالنسبة لي ، هذا طبيعي. ويعتقد بعض الناس: "لماذا أكتب هذا في أماكن مختلفة ، سأضع كل شيء في مكان واحد." إنه ممكن وهكذا ، لكن هذا هو التطرف الثاني.
من لديه كل ذلك في مكان واحد؟ واحد ، اثنان ، ثلاثة أشخاص ، أي شخص يستخدمه.
ومن الذي يستدعي مكونًا معينًا ، أو كتلة واحدة أو وحدة بنية تحتية واحدة؟ خمسة إلى سبعة أشخاص. ان هذا رائع.
الإجابة الأكثر شيوعًا هي في مكان ما في المنتصف. إذا كان المشروع كبيرًا ، فغالبًا ما يكون لديك موقف لا يكون فيه أي من الحلول مناسبًا ولا يعمل كل شيء هناك ، لذلك ينتهي بك الأمر بمزيج. لا حرج في هذا ، طالما أنك تدرك أن هناك ميزة لكليهما.
إذا تغير شيء ما في المكدس VPC وتريد تطبيق تغييرات EC2 هذه ، أي أنك تريد تحديث مجموعة القياس التلقائي لأن لديك شبكة فرعية جديدة ، فأنا أطلق على هذا النوع من تزامن التبعية. هناك بعض الحلول: من يستخدم ماذا؟
أستطيع أن أقترح ما هي الحلول. يمكنك استخدام Terraform للقيام بالسحر ، أو يمكنك استخدام makefiles لاستخدام Terraform. وانظر ، إذا تغير شيء هناك ، يمكنك تشغيله هنا.
كيف تحب هذا القرار؟ هل يعتقد أي شخص أن هذا حل رائع؟ أرى ابتسامة ، أرى الشكوك تتسلل.
بالطبع ، لا تكرر هذا في المنزل. لم يتم تصميم Terraform مطلقًا للتشغيل من داخل Terraform.
قيل لي في أحد التقارير: "لا ، هذا لن ينجح". الشيء هو أنه لا ينبغي أن يعمل. على الرغم من أنه يبدو مثيرًا للإعجاب عندما يمكنك إطلاق Terraform من Terraform ، وهناك أيضًا Terraform ، لكن ليس عليك القيام بذلك. يجب أن يبدأ Terraform دائمًا بكل بساطة.
إذا كنت بحاجة إلى تنظيم المكالمات عندما يتغير شيء ما في مكان واحد ، فهناك Terragrunt.
Terragrunt هو أداة مساعدة ، وهو إضافة إلى Terraform ، والذي يسمح لك بتنسيق وتنسيق المكالمات إلى وحدات البنية التحتية.
يبدو ملف تكوين Terraform النموذجي هكذا.
أنت تحدد الوحدة التي تريد الاتصال بها.
أي وحدة لها تبعيات.
وما الحجج التي تقبلها هذه الوحدة. هذا كل ما يمكن معرفته عن Terragrunt.
التوثيق موجود ، هناك أيضًا 1 نجمة على GitHub. لكن في معظم الحالات ، هذا ما تحتاج إلى معرفته. وهذا سهل التنفيذ في الشركات التي بدأت للتو العمل مع Terraform.
لذا فإن التنسيق هو Terragrunt. هناك خيارات أخرى.
الآن دعنا نتحدث عن كيفية العمل مع الكود.
إذا كنت بحاجة إلى إضافة ميزات جديدة إلى الشفرة في معظم الحالات ، فمن السهل ذلك. أنت تكتب موردًا جديدًا ، كل شيء بسيط هنا.
إذا كان لديك نوع من الموارد التي قمت بإنشائها مسبقًا ، على سبيل المثال ، فقد تعرفت على Terraform بعد أن فتحت حساب AWS وترغب في استخدام الموارد التي لديك بالفعل ، فسيكون من المناسب توسيع الوحدة الخاصة بك بهذه الطريقة ، بحيث يدعم استخدام الموارد الموجودة.
ودعم إنشاء موارد جديدة باستخدام مورد الكتلة.
عند الإخراج ، نعيد دائمًا معرف الإخراج اعتمادًا على ما تم استخدامه.
المشكلة الثانية البالغة الأهمية في Terraform 0.11 هي التعامل مع القوائم.
تكمن الصعوبة في حقيقة أنه إذا كان لدينا مثل هذه القائمة من المستخدمين.
وعندما ننشئ هؤلاء المستخدمين باستخدام مورد الكتلة ، كل شيء يسير على ما يرام. نتصفح القائمة بأكملها ، وننشئ ملفًا لكل منها. كل شيء على ما يرام. وبعد ذلك ، على سبيل المثال ، يجب إزالة user3 ، الموجود في المنتصف ، من هنا ، ثم سيتم إعادة إنشاء جميع الموارد التي تم إنشاؤها بعده ، لأن الفهرس سيتغير.
العمل مع القوائم في بيئة ذات حالة. ما هي بيئة الدولة؟ هذا هو الموقف الذي تحدث فيه قيمة جديدة عند إنشاء المورد. على سبيل المثال ، مفتاح AWS Access أو مفتاح AWS السري ، أي عندما ننشئ مستخدمًا ، نتلقى وصولًا جديدًا أو مفتاحًا سريًا. وفي كل مرة نقوم فيها بحذف مستخدم ، سيكون لهذا المستخدم مفتاح جديد. لكن هذا ليس فنغ شوي ، لأن المستخدم لن يرغب في أن يكون صديقًا لنا إذا أنشأنا مستخدمًا جديدًا له في كل مرة يغادر فيها شخص ما الفريق.
الحل هو هذا. هذا رمز مكتوب في Jsonnet. Jsonnet هي لغة نموذجية من Google.
يسمح لك هذا الأمر بقبول هذا القالب وعند الإخراج يقوم بإرجاع ملف json الذي تم إنشاؤه وفقًا للقالب الخاص بك.
القالب يبدو مثل هذا.
يسمح لك Terraform بالعمل مع كل من HCL و Json بنفس الطريقة ، لذلك إذا كان لديك القدرة على إنشاء Json ، فيمكنك حينئذٍ أن تنزلق إلى Terraform. سيتم تحميل ملف .tf.json بنجاح.
ثم نعمل معها كالمعتاد: terraform init، terramorm application. وقمنا بإنشاء مستخدمين.
الآن نحن لسنا خائفين إذا ترك شخص ما الفريق. سنقوم فقط بتحرير ملف json. غادر فاسيا بوبكين ، بقيت بيتيا بياتوشكين. لن تتلقى Petya Pyatochkin مفتاحًا جديدًا.
إن تكامل Terraform مع الأدوات الأخرى ليس في الواقع وظيفة Terraform. تم إنشاء Terraform كمنصة لخلق الموارد وهذا كل شيء. وكل ما يأتي بعد ذلك ليس من اهتمامات Terraform. وليس عليك وضعها هناك. هناك Ansible ، الذي يفعل كل ما هو مطلوب.
ولكن هناك مواقف نريد فيها تكملة Terraform واستدعاء بعض الأوامر بعد اكتمال شيء ما.
اول طريق. نقوم بإنشاء الإخراج حيث نكتب هذا الأمر.
ثم نسمي هذا الأمر من إخراج shell terraform ونحدد هذه القيمة التي نريدها. وبالتالي ، يتم تنفيذ الأمر بكل القيم المستبدلة. إنه مريح للغاية.
الطريقة الثانية. هذا هو استخدام null_resource اعتمادًا على التغييرات في بنيتنا التحتية. يمكننا استدعاء نفس exec المحلي بمجرد تغيير معرف بعض الموارد.
وبطبيعة الحال ، كل هذا سلس على الورق ، لأن أمازون ، مثل جميع مقدمي الخدمات العامة الآخرين ، لديها مجموعة من حالات الحافة الخاصة بها.
أكثر حالات الحواف شيوعًا هي أنه عندما تفتح حساب AWS ، فمن المهم تحديد المناطق التي تستخدمها ؛ ما إذا كانت هذه الميزة مدرجة هناك ؛ ربما فتحته بعد ديسمبر 2013 ؛ ربما كنت تستخدم الافتراضي في VPC وما إلى ذلك. هناك العديد من القيود. وزعتهم أمازون في جميع أنحاء الوثائق.
هناك بعض الأشياء التي أوصي بتجنبها.
بادئ ذي بدء ، تجنب جميع الحجج غير السرية داخل خطة Terraform أو Terraform CLI. كل هذا يمكن أن يضاف إما إلى ملف tfvars أو إلى متغير بيئة.
لكن ليس عليك حفظ هذا الأمر السحري بالكامل. خطة Terraform - فار ونذهب بعيدًا. المتغير الأول هو var ، والمتغير الثاني هو var ، والمتغير الثالث ، والرابع. أهم مبدأ للبنية التحتية كرمز الذي أستخدمه أكثر من غيره هو أنه بمجرد النظر إلى الكود ، يجب أن أكون قادرًا على فهم ما يتم نشره هناك تمامًا ، وفي أي حالة وبأي قيم. ولذا لا أحتاج إلى قراءة الوثائق أو سؤال Vasya عن المعلمات التي استخدمها لإنشاء مجموعتنا. يكفي أن أفتح ملفًا بامتداد tfvars ، والذي غالبًا ما يطابق البيئة ، وأرى كل شيء هناك.
أيضًا لا تستخدم الوسيطات الهدف لتقليل النطاق. من الأسهل بكثير استخدام وحدات البنية التحتية الصغيرة لهذا الغرض.
أيضا ، لا تحد وتزيد من التوازي. إذا كان لدي 150 موردًا وأردت زيادة التوازي في Amazon من 10 ، وهو الافتراضي ، إلى 100 ، فمن المحتمل أن يحدث خطأ ما. أو قد تسير الأمور على ما يرام الآن ، ولكن عندما تقول أمازون إنك تجري مكالمات كثيرة جدًا ، فأنت في ورطة.
سيحاول Terraform إعادة تشغيل معظم هذه المشكلات ، لكنك لن تحقق شيئًا تقريبًا. يعد Parallelism = 1 أمرًا مهمًا لاستخدامه إذا تعثرت في بعض الأخطاء داخل AWS API أو داخل موفر Terraform. ثم تحتاج إلى تحديد: التوازي = 1 وانتظر حتى ينهي Terraform مكالمة واحدة ، ثم الثانية ، ثم الثالثة. سيطلقهم واحدًا تلو الآخر.
كثيرًا ما يسألني الناس: "لماذا أعتقد أن مساحات العمل في Terraform شريرة؟". أعتقد أن مبدأ البنية التحتية كرمز هو معرفة البنية التحتية التي تم إنشاؤها وبأي قيم.
لم يتم إنشاء مساحات العمل من قبل المستخدمين. هذا لا يعني أن المستخدمين كتبوا في GitHub مشكلات لا يمكنهم العيش بدون مساحات عمل Terraform. لا ليس مثل هذا. Terraform Enterprise هو حل تجاري. قرر Terraform من HashiCorp أننا بحاجة إلى مساحات عمل ، لذلك سنقوم بحفظها. أجد أنه من الأسهل بكثير وضعه في مجلد منفصل. بعد ذلك سيكون هناك المزيد من الملفات ، لكنها ستكون أكثر وضوحًا.
كيف تعمل مع الكود؟ في الواقع ، العمل مع القوائم هو الألم الوحيد. وخذ Terraform أسهل. إنه ليس نوع الشيء الذي سيجعلك تشعر بالراحة. لا حاجة لدفع كل ما هو مكتوب في الوثائق هناك.
تمت كتابة موضوع التقرير "للمستقبل". سأقول هذا باختصار شديد. بالنسبة للمستقبل ، هذا يعني أنه سيتم إصدار 0.12 قريبًا.
0.12 عبارة عن مجموعة من الأشياء الجديدة. إذا كنت من البرمجة العادية ، فإنك تفوت جميع أنواع الكتل الديناميكية ، والحلقات ، وعمليات المقارنة العادية والشرطية ، حيث لا يتم حساب الجزأين الأيمن والأيسر في وقت واحد ، ولكن اعتمادًا على الموقف. أنت تفتقدها كثيرًا ، لذا فإن 0.12 ستحلها لك.
لكن! إذا كنت تكتب أقل وأسهل ، باستخدام وحدات جاهزة ، وحلول من جهات خارجية ، فلن تضطر إلى الانتظار وتأمل أن يأتي 0.12 ويصلح كل شيء من أجلك.
شكرا على التقرير! لقد تحدثت عن البنية التحتية كرمز وقلت حرفياً كلمة واحدة عن الاختبارات. هل اختبارات الوحدة ضرورية؟ من هذه المسؤولية؟ هل يجب علي كتابتها بنفسي أم أنها مسؤولية الوحدات؟
العام المقبل سيواجه قصفًا بالتقارير التي تفيد بأننا قررنا اختبار كل شيء. ما الذي يجب اختباره هو السؤال الأكبر. هناك الكثير من التبعيات ، والكثير من القيود من مختلف مقدمي الخدمة. عندما نتحدث أنت وأنا وتقول: "أنا بحاجة إلى اختبارات" ، فأنا أسأل: "ماذا ستختبر؟". أنت تقول أنك ستختبر في منطقتك. ثم أقول إنه لا يعمل في منطقتي. وهذا يعني أننا لا نستطيع حتى الاتفاق على هذا معك. ناهيك عن وجود الكثير من المشاكل الفنية. أي كيف تكتب هذه الاختبارات بحيث تكون كافية.
أنا أبحث بنشاط في هذا الموضوع ، أي كيفية إنشاء الاختبارات تلقائيًا بناءً على البنية التحتية التي كتبتها. بمعنى ، إذا كتبت هذا الرمز ، فأنا بحاجة إلى تشغيله ، بناءً على ذلك يمكنني إنشاء اختبارات.
- هذه إحدى المكتبات الأكثر ذكرًا والتي تتيح لك كتابة اختبارات تكامل لـ Terraform. هذه واحدة من المرافق. أنا أفضل نوع DSL مثل rspec.
انطون ، شكرا على التقرير! اسمي فاليري. دعني أطرح عليك سؤالا فلسفيا صغيرا. هناك ، بشكل مشروط ، توفير ، هناك نشر. يؤدي التزويد إلى إنشاء البنية التحتية الخاصة بي ، وعند النشر نقوم بملئها بشيء مفيد ، على سبيل المثال ، الخوادم والتطبيقات وما إلى ذلك ، ويترسخ في رأسي أن Terraform هو أكثر للتزويد ، و Ansible أكثر للنشر ، لأن Ansible موجود أيضًا على الجانب المادي تسمح لك البنية التحتية بتثبيت nginx و Postgres. ولكن في الوقت نفسه ، يبدو أن Ansible يسمح لك بتوفير موارد Amazon أو Google على سبيل المثال. لكن Terraform يسمح لك أيضًا بنشر بعض البرامج بمساعدة وحداتها النمطية. من وجهة نظرك ، هل هناك حدود بين Terraform و Ansible ، أين وما هو الأفضل للاستخدام؟ أو ، على سبيل المثال ، هل تعتقد أن Ansible عبارة عن قمامة بالفعل ، هل يجب أن تحاول استخدام Terraform في كل شيء؟
سؤال جيد ، فاليري. أعتقد أن Terraform لم يتغير من حيث الغرض منذ عام 2014. تم بناؤه للبنية التحتية وتوفي بسبب البنية التحتية. ما زلنا نمتلك وسنحتاج إلى إدارة تكوين Ansible. التحدي هو أن هناك بيانات مستخدم داخل launch_configuration. وهناك تقوم بسحب Ansible ، وما إلى ذلك. هذا هو التحديد القياسي الذي يعجبني أكثر.
إذا كنا نتحدث عن بنية تحتية جميلة ، فهناك أدوات مساعدة مثل Packer تقوم ببناء هذه الصورة. ثم يستخدم Terraform مصدر البيانات للعثور على هذه الصورة وتحديث launch_configuration. وبهذه الطريقة ، يتكون خط الأنابيب من حقيقة أننا نسحب أولاً Tracker ، ثم نسحب Terraform. وإذا كان هناك بناء ، فسيحدث تغيير جديد.
مرحبًا! شكرا على التقرير! اسمي ميشا ، شركة RBS. يمكنك الاتصال بـ Ansible من خلال الموفر عند إنشاء مورد. وأيضًا يوجد في Ansible موضوع مثل المخزون الديناميكي. ويمكنك أولاً الاتصال بـ Terraform ، ثم الاتصال بـ Ansible ، والتي ستأخذ موارد من الدولة وتنفذها. ما الأفضل؟
وهذا وذاك يستخدمه الناس بنجاح مماثل. يبدو لي أن المخزون الديناميكي في Ansible هو أمر مناسب ، إذا لم نتحدث عن مجموعة قياس ذاتي. لأنه في مجموعة القياس التلقائي لدينا بالفعل مجموعة أدوات خاصة بنا تسمى launch_configuration. نكتب في launch_configuration كل ما يحتاج إلى إطلاقه عندما ننشئ موردًا جديدًا. لذلك ، مع Amazon ، فإن استخدام الجرد الديناميكي وقراءة ملف Terraform ts أمر مبالغ فيه في رأيي. وإذا كنت تستخدم أدوات أخرى لا يوجد فيها مفهوم "مجموعة القياس التلقائي" ، على سبيل المثال ، إذا كنت تستخدم DigitalOcean أو مزودًا آخر حيث لا توجد مجموعة قياس تلقائي ، فستحتاج إلى سحب مقابض واجهة برمجة التطبيقات ، والعثور على عناوين IP ، وإنشاء ملف جرد ديناميكي ، وسيقوم Ansible بالتجول فيه بالفعل. وهذا يعني ، بالنسبة إلى Amazon ، يوجد launch_configuration ، ولكل شيء آخر يوجد مخزون ديناميكي.
المصدر: www.habr.com