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

عرض توضيحي لاستخدام أدوات مفتوحة المصدر مثل Packer و Terraform لتقديم تغييرات البنية الأساسية باستمرار لبيئات السحابة المفضلة لدى المستخدمين.


استندت المادة إلى عرض تقديمي قدمه Paul Stack في مؤتمر الخريف DevOops 2017. Paul هو مطور بنية أساسية اعتاد العمل في HashiCorp وشارك في تطوير أدوات يستخدمها ملايين الأشخاص (على سبيل المثال ، Terraform). غالبًا ما يتحدث في المؤتمرات وينقل الممارسة من واجهة تنفيذ CI / CD ، ومبادئ التنظيم الصحيح لجزء العمليات ، وهو قادر على شرح سبب قيام المسؤولين بذلك على الإطلاق. باقي المقال في السرد.

لذا ، فلنبدأ فورًا ببعض النتائج الرئيسية.

تمتص الخادم لفترة طويلة

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

البنية التحتية الثابتة

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

بنية تحتية يمكن التخلص منها

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

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

سأعطي القياس. لا تعتبر أبقار المزرعة بشكل عام حيوانات أليفة.



عندما يكون لديك ماشية في المزرعة ، لا تمنحهم أسماء فردية. لكل فرد رقم وعلامة. لذلك مع الخوادم. إذا كنت لا تزال تنشئ خوادم يدويًا في الإنتاج في عام 2006 ، فلها أسماء مهمة ، على سبيل المثال ، "SQL Database on Production 01". ولها معنى محدد للغاية. وإذا تعطل أحد الخوادم ، فسيبدأ الجحيم.

إذا مات أحد الحيوانات في القطيع ، يشتري المزارع حيوانًا جديدًا. هذه هي "البنية التحتية لمرة واحدة".

التسليم المستمر

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

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

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

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

تطوير البنية التحتية والتطبيقات هي اتجاهات قريبة جدًا. والأشخاص الذين يكتبون رمز التطبيق يكتبون أيضًا رمز البنية التحتية (والعكس صحيح). تبدأ هذه العوالم في التوحد. لم يعد هناك مثل هذا الفصل والفخاخ المحددة لكل من العوالم.

مبادئ وممارسات التسليم المستمر

التسليم المستمر لديه عدد من المبادئ:

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

ولكن الأهم من ذلك ، أن التسليم المستمر له أربع ممارسات. اصطحبهم وانقلهم مباشرة إلى البنية التحتية:

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

هل قرأ أحد كتاب التسليم المستمر ؟



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

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



يدعم Terraform التفاعل مع مقدمي الخدمة. الموفرون هم الغيوم ، خدمات Saas ، إلخ.

داخل كل مزود خدمة سحابية ، هناك العديد من الموارد ، مثل الشبكة الفرعية ، VPC ، موازن التحميل ، وما إلى ذلك. باستخدام DSL (لغة خاصة بالمجال) ، تخبر Terraform كيف ستبدو البنية التحتية الخاصة بك.

يستخدم Terraform نظرية الرسم البياني.



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



يستخدم Terraform في الواقع رسمًا بيانيًا موجهًا لأنه لا يعرف فقط العلاقات ، ولكن أيضًا ترتيبها: يجب تعيين A (افترض أن A هو VPC) على B ، وهي شبكة فرعية. ويجب إنشاء B قبل C (مثيل) ، نظرًا لوجود إجراء محدد لإنشاء تجريدات في Amazon أو أي سحابة أخرى.
يتوفر مزيد من المعلومات حول هذا الموضوع على موقع YouTube بواسطة Paul Hinze ، الذي لا يزال مدير البنية التحتية في Hashicorp. بالإشارة - محادثة رائعة حول البنية التحتية ونظرية الرسم البياني.

تدرب

كتابة كود أفضل بكثير من مناقشة نظرية.

سبق لي أن أنشأت AMI (Amazon Machine Images). أستخدم Packer لإنشائها وسأوضح لك كيفية القيام بذلك.

AMI هو مثيل لخادم افتراضي في Amazon ، وهو محدد مسبقًا (من حيث التكوين والتطبيقات وما إلى ذلك) ويتم إنشاؤه من صورة. أنا أحب أنه يمكنني إنشاء AMIs جديدة. بشكل أساسي ، AMIs هي حاويات Docker الخاصة بي.

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



يمكنني أن أريكم ما هو في AMI. كل شيء بسيط للغاية.

لدي نموذج ملف JSON:

{ "variables": { "source_ami": "", "region": "", "version": "" }, "builders": [{ "type": "amazon-ebs", "region": "{{user 'region'}}", "source_ami": "{{user 'source_ami'}}", "ssh_pty": true, "instance_type": "t2.micro", "ssh_username": "ubuntu", "ssh_timeout": "5m", "associate_public_ip_address": true, "ami_virtualization_type": "hvm", "ami_name": "application_instance-{{isotime \"2006-01-02-1504\"}}", "tags": { "Version": "{{user 'version'}}" } }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y ntp nginx" ] }, { "type": "file", "source": "application-files/nginx.conf", "destination": "/tmp/nginx.conf" }, { "type": "file", "source": "application-files/index.html", "destination": "/tmp/index.html" }, { "type": "shell", "start_retry_timeout": "5m", "inline": [ "sudo mkdir -p /usr/share/nginx/html", "sudo mv /tmp/index.html /usr/share/nginx/html/index.html", "sudo mv /tmp/nginx.conf /etc/nginx/nginx.conf", "sudo systemctl enable nginx.service" ] } ] } 

لدينا متغيرات نمررها ، ولدى باكر قائمة بما يسمى بناة لمناطق مختلفة ؛ هناك الكثير منهم. يستخدم Builder مصدر AMI خاصًا ، والذي أمرر به معرف AMI. أعطيته اسم المستخدم وكلمة المرور لـ SSH ، وأشير أيضًا إلى ما إذا كان يحتاج إلى عنوان IP عام حتى يتمكن الأشخاص من الوصول إليه من الخارج. في حالتنا ، لا يهم هذا حقًا ، لأنه مثيل AWS لـ Packer.
قمنا أيضًا بتعيين اسم وعلامات AMI.

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

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

لذلك ، لدي خادم تطبيق ويعمل. يمكنني استخدامه في المستقبل. ومع ذلك ، دائمًا ما أتحقق من نماذج باكر. لأنه تكوين JSON حيث قد تواجه بعض المشاكل.
للقيام بذلك ، قم بتشغيل الأمر:

make validate

أحصل على إجابة بأن قالب باكر تم التحقق منه بنجاح:



هذا مجرد أمر ، لذا يمكنني توصيله بأداة CI (أي شخص). في الواقع ، ستكون عملية: إذا قام المطور بتغيير القالب ، يتم إنشاء طلب السحب ، ستتحقق أداة CI من الطلب ، وتقوم بتنفيذ ما يعادل فحص القالب وتنشر القالب إذا نجح الفحص. كل هذا يمكن دمجه في "السيد".
نحصل على دفق لقوالب AMI - ما عليك سوى رفع الإصدار.

لنفترض أن المطور أنشأ إصدارًا جديدًا من AMI.



سأقوم فقط بإصلاح الإصدار في الملفات من 1.0.0 إلى 1.0.1 لتظهر لك الفرق:

 <html> <head> <tittle>Welcome to DevOops!</tittle> </head> <body> <h1>Welcome!</h1> <p>Welcome to DevOops!</p> <p>Version: 1.0.1</p> </body> </html> 

سأعود إلى سطر الأوامر وأبدأ في إنشاء AMI.
لا أحب أن أدير نفس الفرق. أحب إنشاء AMI بسرعة ، لذلك أستخدم ملفات makefiles. دعونا نلقي نظرة مع cat في ملفي:

cat Makefile




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



لذا ، سنقوم بإنشاء إصدار جديد من AMI 1.0.1.

make ami




عودة إلى Terraform.

أؤكد أن هذا ليس رمز الإنتاج. هذه مظاهرة. هناك طرق للقيام بنفس الشيء بشكل أفضل.

أستخدم وحدات Terraform في كل مكان. نظرًا لأنني لم أعد أعمل في Hashicorp ، لذا يمكنني التعبير عن رأيي في الوحدات. بالنسبة لي ، الوحدات في مستوى التغليف. على سبيل المثال ، أحب أن أغلف كل شيء يتعلق بـ VPC: الشبكات والشبكات الفرعية وجداول التوجيه وما إلى ذلك.

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




هنا سوف أقوم بإنشاء مورد AWS ووحدة VPC. ما الذي يحدث هنا؟ خذ cidr_block المستوى cidr_block بإنشاء ثلاث شبكات فرعية خاصة وثلاث شبكات فرعية عامة. فيما يلي قائمة بمناطق التوفر. لكننا لا نعرف ما هي مناطق الوصول هذه.



سنقوم بإنشاء VPN. فقط لا تستخدم وحدة VPN هذه. هذا هو openVPN ، الذي يقوم بإنشاء مثيل AWS واحد ليس لديه شهادة. يستخدم عنوان IP العام فقط ويذكر هنا فقط لإظهار أنه يمكننا الاتصال بـ VPN. هناك أدوات أكثر ملاءمة لإنشاء VPN. استغرق الأمر مني حوالي 20 دقيقة وبيرتين لكتابة بلدي.





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

لقد ذكرت بالفعل مناطق التوفر. وهي تختلف باختلاف حسابات AWS. قد يكون لحسابي في الولايات المتحدة في الشرق حق الوصول إلى المناطق A و B و D. قد يكون لحساب AWS الخاص بك حق الوصول إلى B و C و E. وبالتالي ، عند إصلاح هذه القيم في الرمز ، سنواجه مشاكل. اقترحنا في Hashicorp أنه يمكننا إنشاء مصادر البيانات هذه حتى نتمكن من سؤال أمازون عما هو متاح لنا. تحت الغطاء ، نطلب وصفًا لمناطق التوفر ، ثم نرجع قائمة بجميع المناطق لحسابك. بفضل هذا ، يمكننا استخدام مصادر البيانات لـ AMI.

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

عندما ننشر الإصدار الجديد من AMI ، سأبدأ تكوين Terraform مرة أخرى ، سيؤدي هذا إلى تغيير تكوين التشغيل ، وستتلقى الخدمة الجديدة الإصدار التالي من الرمز ، وما إلى ذلك ، ويمكننا التحكم فيه.



نرى أن باكر قد انتهى ولدينا AMI جديد.
أعود إلى أمازون ، وقم بتحديث الصفحة ورؤية AMI ثانية.



عودة إلى Terraform.

بدءًا من الإصدار 0.10 ، قسمت Terraform الموفرين إلى مستودعات منفصلة. ويحصل الأمر init terraform على نسخة من الموفر المطلوب للتشغيل.



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

الخطوة التالية هي بناء رسم بياني.

ابدأ بـ

terraform plan




سيأخذ Terraform الحالة المحلية الحالية ويقارن مع حساب AWS ، مشيرًا إلى الاختلافات. في حالتنا ، سيخلق 35 موارد جديدة.



الآن نطبق التغييرات:

terraform apply


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

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

لذا ، تم إنشاء البنية التحتية بالنسبة لي.



يمكن لـ Terraform إنشاء رسم بياني:

terraform graph


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

سيكون الرسم البياني عبارة عن قائمة JSON يمكن حفظها في ملف PNG أو DOC.

عودة إلى Terraform. نحن بالفعل نقوم بإنشاء مجموعة قياس تلقائي.



مجموعة التحجيم التلقائي بسعة 3.



سؤال مثير للاهتمام: هل يمكننا استخدام Vault لإدارة الأسرار في Terraform؟ للأسف لا. لا يوجد مصدر بيانات Vault لقراءة الأسرار في Terraform. هناك طرق أخرى ، مثل متغيرات البيئة. بمساعدتهم ، لا تحتاج إلى إدخال أسرار في التعليمات البرمجية ؛ يمكنك قراءتها كمتغيرات بيئة.

لذا ، لدينا بعض مرافق البنية التحتية:



أدخل VPN الخاص بي السري للغاية (لا تكسر شبكات VPN الخاصة بي).

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


كل شيء حقًا وراء VPN:



إذا أخذت هذا ( application-elb-1069500747.eu-west-1.elb.amazonaws.com ) وقمت بلصقه في شريط عنوان المتصفح ، أحصل على ما يلي:



دعني أذكرك بأنني متصل بشبكة VPN. إذا قمت بتسجيل الخروج ، فلن يكون العنوان المحدد متاحًا.
نرى الإصدار 1.0.0. وبغض النظر عن مدى تحديث الصفحة ، نحصل على 1.0.0.
ماذا يحدث إذا قمت بتغيير الإصدار من 1.0.0 إلى 1.0.1 في التعليمات البرمجية؟

 filter { name = "tag:Version" values = ["1.0.1"] } 

من الواضح أن أدوات CI ستضمن لك إنشاء الإصدار الصحيح.
ألاحظ عدم وجود تحديثات يدوية! نحن غير كاملين ، نرتكب أخطاء ، ويمكننا وضع الإصدار 1.0.6 بدلاً من 1.0.1 عند التحديث يدويًا.

 filter { name = "tag:Version" values = ["1.0.6"] } 

ولكن دعنا ننتقل إلى نسختنا (1.0.1).

terraform plan


حالة تحديثات Terraform:





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

هذا لا يغير حالات التشغيل. هذا مهم حقًا. يمكنك متابعة هذه العملية واختبارها دون تغيير المثيلات في الإنتاج.

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

دعنا نطبق التغييرات:

terraform apply


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



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

دعنا ننتقل إلى التجارب.

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

لذا ، احذف إحدى الحالات:





ماذا سيحدث في مجموعة التحجيم التلقائي عند إيقاف تشغيلها؟ سيظهر مثيل جديد في مكانه.



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

هنا يصبح كل شيء أكثر إثارة للاهتمام. لماذا لا تفعل ذلك مع البرامج النصية والأدوات CI ، وليس يدويًا ، كما أظهر؟ هناك أدوات يمكنها القيام بذلك ، مثل أدوات AWS الممتازة المفقودة على GitHub.



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

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

تتيح لك برامج التحكم النصية هذه الحصول على أحدث إصدار دائمًا مع أخطاء ثابتة وتحديثات أمنية.

يمكنك استخدام البرنامج النصي فقط عن طريق تشغيل:

aws-ha-relesae.sh -a my-scaling-group


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

عودة إلى أمازون. لدينا مثال جديد:



بعد تحديث الصفحة في المتصفح ، حيث رأينا سابقًا الإصدار 1.0.0 ، نحصل على:



الشيء المثير للاهتمام هو أنه منذ أن أنشأنا نص إنشاء AMI ، يمكننا اختبار إنشاء AMI.

هناك بعض الأدوات الرائعة ، مثل ServerScript أو Serverspec.

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

 require 'spec_helper' describe package('nginx') do it { should be_installed } end describe service('nginx') do it { sould be_enabled } it { sould be_running } end describe port(80) do it { should be_listening } end 

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

بدلا من الاستنتاج

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

وسألت السؤال: كم من الوقت ستستغرق مؤسستك لنشر التغييرات المرتبطة بسطر واحد من التعليمات البرمجية؟ هل يمكنك جعل هذه العملية موثوقة وقابلة للتكرار؟

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

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

الآن كل شيء مكتوب. لدينا العديد من الأدوات والأمثلة ، هناك GitHub. لذلك ، خذ أفكارًا من مؤتمرات مثل DevOops ، نفذها في مؤسستك. لا تحاول تنفيذ كل شيء. خذ شيئًا صغيرًا وبيعه. أظهر شخص ما. يمكن قياس تأثير التغيير البسيط وقياسه والمضي قدمًا!

سيصل بول ستاك إلى سان بطرسبرغ في مؤتمر DevOops 2018 مع تقرير "اختبار النظام المستدام مع الفوضى" . سيتحدث بول عن منهجية هندسة الفوضى ويوضح كيفية استخدام هذه المنهجية في المشاريع الحقيقية.