اختبار البنية التحتية الخاصة بك كرمز مع Pulumi. الجزء 2

مرحبا بالجميع. نتبادل معك اليوم الجزء الأخير من مقال "اختبار البنية التحتية ككود يستخدم Pulumi" ، والذي تم إعداد ترجمة له خصيصًا لطلاب الدورة التدريبية "ممارسات وأدوات DevOps" .

اختبار النشر

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

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

(نحن نعمل لضمان أن تكون قدرات اختبار التكامل المماثلة باللغة SDK باللغة الأصلية. يمكنك استخدام إطار اختبار التكامل Go بغض النظر عن اللغة المكتوبة في برنامج Pulumi الخاص بك).

عن طريق تشغيل البرنامج باستخدام هذا الإطار ، يمكنك التحقق مما يلي:

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

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

اختبار التكامل بسيط

لنرى ذلك أثناء العمل ، نلقي نظرة على مستودع pulumi/examples ، حيث يستخدمه فريقنا ومجتمع Pulumi لاختبار مجموعة الطلبات والالتزامات والبنايات الليلية الخاصة بهم.

يوجد أدناه اختبار مبسط لمثالنا ، والذي يوفر مجموعة S3 وبعض الكائنات الأخرى :

example_test.go:

 package test import ( "os" "path" "testing" "github.com/pulumi/pulumi/pkg/testing/integration" ) func TestExamples(t *testing.T) { awsRegion := os.Getenv("AWS_REGION") if awsRegion == "" { awsRegion = "us-west-1" } cwd, _ := os.Getwd() integration.ProgramTest(t, &integration.ProgramTestOptions{ Quick: true, SkipRefresh: true, Dir: path.Join(cwd, "..", "..", "aws-js-s3-folder"), Config: map[string]string{ "aws:region": awsRegion, }, }) } 

يمتد هذا الاختبار إلى دورة الحياة الأساسية لإنشاء وتعديل وتدمير الحزمة aws-js-s3-folder . سوف يستغرق حوالي دقيقة للإبلاغ عن الاختبار الذي تم اجتيازه:

 $ go test . PASS ok ... 43.993s 

هناك العديد من الخيارات لتخصيص سلوك هذه الاختبارات. راجع بنية ProgramTestOptions للحصول على قائمة كاملة بالخيارات. على سبيل المثال ، يمكنك تكوين نقطة نهاية Jaeger لتتبع ( Tracing ) ، وتشير إلى أنك تتوقع ExpectFailure الاختبار أثناء الاختبار السلبي ( ExpectFailure ) ، وتطبيق سلسلة من "التعديلات" على برنامج انتقالات الحالة المتعاقبة ( EditDirs ) ، وأكثر من ذلك بكثير. دعونا نرى كيفية استخدامها للتحقق من نشر التطبيق.

التحقق من خصائص الموارد

التكامل المذكور أعلاه يضمن أن برنامجنا "يعمل" - لا يتعطل. ولكن ماذا لو أردنا التحقق من خصائص المكدس الناتج؟ على سبيل المثال ، تم إعداد (أو عدم إعداد) أنواع معينة من الموارد ولديها سمات معينة.

تسمح لنا المعلمة ExtraRuntimeValidation لـ ProgramTestOptions على الحالة المسجلة بواسطة Pulumi بعد النشر (حالة ما بعد النشر) ، حتى نتمكن من إجراء اختبارات إضافية. يتضمن ذلك لقطة كاملة لحالة المكدس الناتج ، بما في ذلك التكوين وقيم المخرجات المصدرة وجميع الموارد وقيم خصائصها ، وكذلك جميع التبعيات بين الموارد.

لمشاهدة مثال أساسي على ذلك ، دعنا نتحقق من أن برنامجنا يقوم بإنشاء S3 Bucket :

  integration.ProgramTest(t, &integration.ProgramTestOptions{ // as before... ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) { var foundBuckets int for _, res := range stack.Deployment.Resources { if res.Type == "aws:s3/bucket:Bucket" { foundBuckets++ } } assert.Equal(t, 1, foundBuckets, "Expected to find a single AWS S3 Bucket") }, }) 

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

اختبارات وقت التشغيل

حتى الآن ، كانت جميع الاختبارات تتعلق حصريًا بسلوك النشر وبشأن نموذج موارد Pulumi. ماذا لو كنت تريد التحقق من أن البنية التحتية المعدة لديك تعمل حقًا؟ على سبيل المثال ، أن الجهاز الظاهري قيد التشغيل ، يحتوي دلو S3 على ما نتوقعه ، وما إلى ذلك.

ربما تكون قد اكتشفت بالفعل كيفية القيام بذلك: ExtraRuntimeValidation خيار ProgramTestOptions for ProgramTestOptions فرصة عظيمة لهذا. في هذه المرحلة ، يمكنك تشغيل اختبار Go التعسفي مع الوصول إلى الحالة الكاملة لموارد البرنامج. تتضمن هذه الحالة معلومات مثل عناوين IP للأجهزة الافتراضية وعناوين URL وكل ما هو ضروري للتفاعل الحقيقي مع التطبيقات السحابية والبنية التحتية المستلمة.

على سبيل المثال ، يقوم برنامج الاختبار الخاص بنا بتصدير خاصية دلو webEndpoint تسمى websiteUrl ، وهو عنوان URL الكامل الذي يمكننا من خلاله الحصول على index document مخصصة. على الرغم من أننا استطعنا الخوض في ملف الحالة للعثور على bucket وقراءة هذه الخاصية مباشرةً ، في كثير من الحالات ، تقوم مجموعات البيانات الخاصة بنا بتصدير خصائص مفيدة ، مثل هذه ، والتي هي مناسبة لنا للتحقق:

 integration.ProgramTest(t, &integration.ProgramTestOptions{ // as before ... ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) { url := "http://" + stack.Outputs["websiteUrl"].(string) resp, err := http.Get(url) if !assert.NoError(t, err) { return } if !assert.Equal(t, 200, resp.StatusCode) { return } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if !assert.NoError(t, err) { return } assert.Contains(t, string(body), "Hello, Pulumi!") }, }) 

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

تكامل مستمر للبنية التحتية

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

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

لكل منهم ، يدعم Pulumi التكامل مع نظام التكامل المستمر المفضل لديك. مع التكامل المستمر ، يمنحك هذا تغطية الاختبار نفسه للبنية التحتية كما يفعل لبرامج التطبيق.

يحتوي Pulumi على دعم لأنظمة CI الشائعة. هؤلاء بعض منهم:

• خدمات رمز AWS
• أزور ديفوبس
• CircleCI
• الإجراءات جيثب
• Gitlab ci
• جوجل سحابة البناء
• ترافيس

لمزيد من المعلومات ، راجع وثائق التسليم المستمر .

البيئات سريعة الزوال

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

إذا كنت تستخدم GitHub ، فإن Pulumi يقدم تطبيق GitHub ، والذي سيساعدك على ربط اختبار القبول بمجموعة الطلبات ضمن خط أنابيب CI الخاص بك. فقط قم بتثبيت التطبيق في مستودع GitHub ، وستضيف Pulumi معلومات حول معاينة البنية التحتية والتحديثات ونتائج الاختبار إلى CI ومجموعة الطلبات الخاصة بك:



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

يؤدي

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

Pulumi هو برنامج مفتوح المصدر مجاني للاستخدام ويعمل مع لغات البرمجة والسحب المفضلة لديك - جربها اليوم !

→ الجزء الأول