كيفية إنشاء كتلة Kubernetes آمنة بشكل افتراضي مع خط أنابيب CI / CD أساسي على AWS

كتبه ماثيو شيبارد ودونالد كارنيجي

Kuber-ما-وفاق؟

Kubernetes (تُعرف بـ "koo-burr-NET-eez") هي عبارة عن منصة مفتوحة المصدر لأتمتة تشغيل حاويات التطبيقات ونشرها. غالباً ما يشير إليه الأطفال اللطيفون بواسطة (IOHO) اختصار "k8s" غير جيد جدًا. تتمثل وظيفة Kubernetes في تحقيق الاستفادة القصوى من البنية التحتية الخاصة بك مع ضمان توفر أعباء العمل الخاصة بك في حاويات ويمكن توسيع نطاقها حسب الحاجة. أبلغت بعض الشركات عن قدرتها على خفض تكاليف البنية التحتية السحابية الخاصة بها بنسبة تتراوح بين 50٪ و 70٪ مقارنةً بالتشغيل على بنية VM التقليدية.

يحتوي (erise) نجاحك

Kubernetes هي قصة نجاح هائلة لمؤسسة Cloud Native Computing Foundation ومجتمع المصادر المفتوحة الذي يقف وراءها. تم الإعلان لأول مرة في منتصف عام 2014 كمشروع صغير بقيادة فريق من مهندسي Google ، وقد نمت لتصبح منصة تزامن حاوية فعلية وسلعة عبر النظام البيئي السحابي العام. لدى كل من Microsoft و Google و Amazon و IBM جميعها تقدم Kubernetes مُدار من نوع ما. من حيث المساهمين والسرعة ، تحتل Kubernetes المرتبة الثانية فقط في المشروعات المفتوحة المصدر لنظام Linux Kernel. يتم استخدامه على نطاق واسع للعديد من أعباء العمل الرائعة ، بدءًا من تشغيل Pokemon Go وحتى ضمان إمكانية مشاركة مشتركي HBO GO بسلاسة في لعبة Game of Thrones في الموسم السابع.

Kubernet المستمر

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

GitOps هو مصطلح تم صياغته بواسطة Weaveworks لوصف استخدام Git كمصدر حقيقي للحقيقة في حالة الكتلة Kubernetes. تصبح Git هي وسيلة تتبع حالة النظام لدينا ، ونحن نستخدم تصميمات ضمن git مثل طلبات السحب كوسيلة لدمج الحالة الممسوكة في git مع حالة البنية التحتية السحابية. باختصار ، تؤدي طلبات السحب المعتمدة إلى إجراء تغييرات مباشرة على الإنتاج. يعد هذا أسلوبًا قويًا نظرًا لأن سير عمل التعليمات البرمجية المصدر الذي تم إثباته يمكن تطبيقه لإدارة البنية الأساسية - فهم كاملًا يمكن أن يخلصنا من عمليات التحكم في التغيير البيروقراطية في المدارس القديمة المعقدة ، وتستغرق وقتًا طويلًا ، وتفتقر إلى المساءلة. دائمًا ما تكون التغييرات التي تم إجراؤها على البنية الأساسية الخاصة بك مرئية بنسبة 100٪ ويمكن تتبعها وخضوعها للمساءلة. يتم تخزين السجل بشكل دائم في مستودع git ، والعودة إلى أي نقطة في التاريخ هي قطعة من الكعكة.

لماذا يجب علي استخدام Kubernetes؟

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

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

YATR؟ (بعد درس آخر ، حقا؟)

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

الهدف من هذا البرنامج التعليمي هو سد هذه الفجوة والدخول إلى مجموعة نظام Kubernetes:

  • متوفر للغاية: نريد التأكد من أن بيئاتنا يمكن أن تتعامل مع الفشل وأن تطبيقاتنا الحاوية ستستمر في التشغيل في حالة فشل بعض العقد أو تعطلت منطقة توفر AWS. ولتحقيق ذلك ، سنقوم بتشغيل أسياد وعقد Kubernetes عبر 3 مناطق توفر AWS.
  • يفرض "مبدأ الأقل امتيازًا": افتراضيًا ، يجب تشغيل جميع البرامج في سياق أمان مقيد ؛ يجب ألا يكون لديهم القدرة على إجراء تغييرات على نظام Kubernetes أو بيئة AWS الأساسية. يجب على أي جراب يحتاج إلى إجراء تغييرات على نظام Kubernetes استخدام حساب خدمة مسمى مع الدور والسياسات المناسبة المرفقة. إذا كانت هناك حاجة إلى إجراء مكالمة على واجهة برمجة تطبيقات AWS ، فيجب أن يتم التوسط في المكالمات للتأكد من أن pod لديه تفويض كافٍ لإجراءها واستخدام بيانات اعتماد IAM مؤقتة فقط. سنحقق ذلك من خلال استخدام التحكم في الوصول المستند إلى الأدوار (RBAC) في Kubernetes لضمان تشغيل القرون الافتراضية دون أي قدرة على تغيير تكوين الكتلة. عندما تحتاج خدمات نظام معين إلى أذونات ، سنقوم بإنشاء حساب خدمة محدد وربطه بنطاق أذونات مطلوب (أي نظام المجموعة ككل أو في مساحة اسم واحدة فقط) ومنح الأذونات المطلوبة لحساب الخدمة هذا. سيتم الوصول إلى واجهة برمجة تطبيقات AWS من خلال kube2iam ؛ سيتم إعادة توجيه كل حركة المرور من القرون المخصصة لـ AWS API إلى kube2iam. استنادًا إلى التعليقات التوضيحية في تكوينات pod ، سيقوم kube2iam بإجراء مكالمة على واجهة برمجة تطبيقات AWS لاسترداد بيانات الاعتماد المؤقتة المطابقة للدور المحدد في التعليق التوضيحي وإعادتها إلى المتصل. سيتم دعم جميع مكالمات AWS API الأخرى من خلال kube2iam لضمان تطبيق مبدأ الامتياز الأقل وعدم إمكانية تجاوز السياسة.
  • يتكامل مع Route53 و Classic Load Balancers: عندما ننشر تطبيقًا ، نريد أن نعلن في التكوين كيف يتم إتاحته للعالم وأين يمكن العثور عليه ، وجعل هذا تلقائيًا لنا. ستقوم Kubernetes تلقائيًا بتوفير موازن تحميل كلاسيكي لتطبيق ما ، ويسمح لنا نظام أسماء النطاقات الخارجية بتخصيص اسم نطاق مؤهل بالكامل (FQDN) ، كل ذلك من خلال البنية التحتية كرمز.
  • يحتوي على خط أنابيب CI / CD أساسي مُلف حوله: نريد أتمتة الطريقة التي نجري بها التغييرات على الكتلة ، وكيفية نشر / تحديث التطبيقات. سوف تلتزم ملفات التكوين التي تحدد تكوين نظامنا بمخزن Git وسيعمل خط أنابيب CI / CD على تطبيقها. لتحقيق ذلك ، سنستخدم Travis-CI لتطبيق التكوين الذي يتم الالتزام به في فرعنا الرئيسي على مجموعة Kubernetes. هذه هي الخطوة الأولى في اتجاه GitOps ، ولكنها لا تمنحنا قدرة GitOps كاملة.

في نهاية البرنامج التعليمي ، سننتهي بمجموعة Kubernetes التي تبدو كما يلي:

لدينا مجموعة Kubernetes نهاية الدولة

قبل أن تبدأ

نحن نفترض أن لديك بالفعل بعض الألفة مع Kubernetes. إذا كنت جديدًا على Kubernetes ، يوصى بمراجعة البرنامج التعليمي Kubernetes Basics والتعرف على مفاهيمه الأساسية.

لبناء نظامنا ، نحتاج إلى التأكد من أن لدينا الأدوات التالية مثبتة:

  • kubectl
    kubectl (Kubernetes Control) هي أداة لسطر الأوامر للتفاعل مع كتلة Kubernetes ، إما تعمل محليًا على جهازك (باستخدام minikube) أو في السحابة.
  • KOPS
    يوفر مشروع عمليات Kubernetes (kops) الأدوات اللازمة لبناء وتشغيل مجموعات Kubernetes في السحابة. وهو يدعم حاليًا خدمة Google Cloud & AWS (مع موفرين آخرين في مرحلة تجريبية). سنستخدم kops لإنشاء مجموعتنا وإدارتها في هذا البرنامج التعليمي.
  • Terraform
    Terraform هي أداة البنية التحتية كرمز (IAC) التي تتيح للمستخدمين تحديد البنية التحتية بلغة التكوين عالية المستوى والتي يمكن بعد ذلك استخدامها لبناء البنية التحتية في مزود خدمة مثل AWS أو Google Cloud Platform. سنستخدم Terraform لإنشاء المتطلبات المسبقة لدينا في kops ولتعديل سياسات IAM التي أنشأتها kops.
  • AWS CLI
    AWS CLI هي أداة سطر أوامر للتفاعل مع AWS. هذا مطلوب من قبل kops & Terraform لأداء العمليات على AWS.

يمكن العثور على تعليمات التثبيت على الروابط المقدمة.

تم إنشاء هذا البرنامج التعليمي باستخدام Kubernetes v1.8 و kops v1.8.1.

نحن نستخدم نظام التشغيل Mac OS X مع Homebrew ، لذلك كل ما نحتاج إليه هو تشغيل الأوامر التالية لتثبيت هذه:

تحديث الشراب $
الشراب $ تثبيت kubectl
$ الشراب تثبيت kops
الشراب $ تثبيت python3
easy_install $ pip
$ نقطة تثبيت awscli - ترقية - المستخدم
PATH للتصدير $ = ~ / .local / bin: PATH $
الشراب $ تثبيت terraform

إنشاء الكتلة

الخطوة 1: استنساخ مستودعنا

git clone https://github.com/slalom-london/k8s-tutorial

الخطوة 2: إعداد FQDN الذي سيتم استخدامه للكتلة في Route53

سوف تستخدم مجموعة Kubernetes التي سنقوم بإعدادها FQDN المستضافة في Route53 لكشف نقاط نهاية الخدمة وطائرة التحكم في واجهة برمجة التطبيقات. يمكنك تسجيل FQDN جديد أو نقل FQDN موجود. لدى AWS خطوة كاملة لكل من هذه الخيارات:

الخطوة 3: إنشاء المتطلبات الأساسية اللازمة ل kops

لكي يتمكن kops من بناء الكتلة ، فإنه يحتاج إلى متجر S3 للاحتفاظ بتكوين الكتلة وحساب مستخدم IAM له السياسات التالية المرتبطة به:

AmazonEC2FullAccess
AmazonRoute53FullAccess
AmazonS3FullAccess
IAMFullAccess
AmazonVPCFullAccess

سيقوم prereqs / kops_pre_reqs.tf بإنشاء هذا من أجلك. سيؤدي أيضًا إلى إنشاء دلو S3 سيتم استخدامه كمتجر بعيد لحالة Terraform الخاصة بنا. يسمح هذا لعدة مستخدمين بالعمل مع مجموعة واحدة من البنية التحتية كرمز دون التسبب في تعارضات. ستحتاج إلى تحديث الملف لاستبدال {my_bucket_name} و {my_tf_bucket_name} باسم اسم المجموعة.

ثم قم بتشغيل الأوامر التالية:

prereqs $ cd
$ terraform init
خطة terraform $
تطبيق terraform $

إذا قمت بتسجيل الدخول إلى حساب AWS الخاص بك ، سترى الآن مستخدم IAM kops تم إنشاؤه حديثًا ، ودلو S3 لمتجر kops State ، ودلو S3 آخر لمتجر حالة Terraform

الخطوة 4: استخدام kops للوقوف على الكتلة

في الخطوة السابقة ، أنشأنا حساب IAM لأجهزة kops. نحن الآن بحاجة إلى إعداد عميل AWS CLI لاستخدام هذا الحساب. يمكننا الحصول على kops IAM ID والمفتاح السري من الملف الذي تستخدمه Terraform لتخزين حالة ما قام بإنشائه في الخطوة السابقة. افتح terraform.tfstate في محرر النصوص وابحث عن القسم الموضح أدناه:

قم بتدوين القيمة في الحقلين {iam_id} و {aws_secret_key} ، وقم بتشغيل الأمر التالي:

$ aws تكوين - ملف تعريف kops
معرف مفتاح الوصول AWS [بلا]: {iam_id}
مفتاح الوصول السري لـ AWS [بلا]: {aws_secret_key}
اسم المنطقة الافتراضي [بلا]: {your_chosen_aws_region}
تنسيق الإخراج الافتراضي [بلا]: النص

بعد ذلك ، نحتاج إلى تعيين اثنين من المتغيرات البيئية حتى يعرف kops حساب AWS IAM الذي يجب استخدامه ومكانه:

تصدير $ AWS_PROFILE = kops
$ export KOPS_STATE_STORE = s3: // {my_bucket_name}

الآن للحدث الرئيسي - دعنا نستخدم kops لبناء مجموعتنا. قم بتشغيل الأمر التالي ، مع استبدال منطقة AWS الخاصة بك ، ومنطقة DNS الخاصة بك واسم الكتلة الذي اخترته:

kops $ إنشاء كتلة - كلاود أوس \
 - معقل \
 - عدد العد 3 \
 - حجم العقدة t2.medium \
 - ماجستير الحجم t2.medium \
 - مناطق {your_chosen_aws_region} أ ، {your_chosen_aws_region} ب ، {your_chosen_aws_region} c \
 - المناطق الرئيسية {your_chosen_aws_region} a ، {your_chosen_aws_region} b ، {your_chosen_aws_region} c \
 --dns-zone {your_dns_zone} \
 - علم الأحياء الخاص \
 - شبكة كاليكو \
 - التخويل RBAC \
 - اسم {your_cluster_name} \
 - خارج = k8s \
 - الهدف = terraform - نعم

يخبر هذا الأمر kops أننا نرغب في إنشاء كتلة:

  • سوف تستخدم AWS
  • يحتوي على عقدة رئيسية بحجم t2.medium في كل منطقة من مناطق التوافر المحددة
  • لديه 3 العقد عامل من حجم t2.medium. ستقوم kops بنشر العقد العاملة بالتساوي عبر كل من مناطق التوافر
  • يستخدم طوبولوجيا شبكة خاصة ، مما يعني أن جميع العقد لها عناوين IP خاصة ولا يمكن الوصول إليها مباشرة من الإنترنت العام
  • يستخدم كاليكو كواجهة لشبكة حاوية تستبدل kubenet كنتيجة لمتطلبات طوبولوجيا الشبكة الخاصة
  • يستخدم RBAC لأذونات الوصول Kubernetes
  • يوصف في ملف تكوين Terraform ليتم كتابته إلى الدليل المحدد بواسطة - الخروج

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

$ k8s القرص
$ terraform init
خطة terraform $
تطبيق terraform $

سوف يستغرق الأمر ما بين 10 و 15 دقيقة حتى تصبح المجموعة متوفرة. يمكنك التحقق من حالة الكتلة عن طريق تشغيل الأمر التالي:

التحقق من صحة $ kops الكتلة

عند الانتهاء من بناء المجموعة ، سترى مخرجات مثل هذه:

باستخدام الكتلة من سياق kubectl: cluster.zigzag-london.com
التحقق من صحة الكتلة cluster.zigzag-london.com
مجموعات INSTANCE
اسم آلة دوارة الشبكات الفرعية MAX MAIN
معقلات Bastion t2.micro 1 1 الأداة المساعدة eu-west-1a ، الأداة المساعدة eu-west-1b ، الأدوات المساعدة
master-eu-west-1a Master t2.medium 1 1 eu-west-1a
master-eu-west-1b master t2.medium 1 1 eu-west-1b
master-eu-west-1c ماجستير t2.medium 1 1 eu-west-1c
عقده t2.medium 3 3 eu-west-1a، eu-west-1b، eu-west-1c
حالة العقد
اسم الدور جاهز
ip-172-20-107-234.eu-west-1.compute.internal master True
ip-172-20-124-39.eu-west-1.compute.internal العقدة صحيح
ip-172-20-44-152.eu-west-1.compute.internal master True
ip-172-20-60-188.eu-west-1.compute.internal العقدة صحيح
ip-172-20-79-79.eu-west-1.compute.internal master True
ip-172-20-87-125.eu-west-1.compute.internal العقدة صحيح
الكتلة cluster.zigzag-london.com جاهزة

الوقوف على بيئة CI / CD

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

في هذا البرنامج التعليمي ، سوف نستخدم TravisCI ، خدمة CI المستندة إلى مجموعة النظراء. TravisCI مجاني طالما:

  • تستضيف مستودعك في جيثب
  • المستودع متاح للجمهور

الخطوة 1: إعداد حسابات ومستودع استنساخ

  • انتقل إلى GitHub وقم بالتسجيل \ تسجيل الدخول
  • قم بإنشاء مستودع جديد وفارغ وتسميته "k8s-ci"
  • استنساخ هذا المستودع في جهازك المحلي:
$ git clone 
  • انتقل إلى TravisCI واشترك باستخدام حساب جيثب الخاص بك. انتقل إلى ملف تعريف المستخدم الخاص بك عن طريق النقر على اسمك في أعلى اليمين.
  • انقر على شريط التمرير في مقابل GitHub repo لتمكين TravisCI لهذا المستودع.

الخطوة 2: مشغلات الإعداد

نظرًا لأننا نمارس GitOps ، فنحن نريد فقط نشر طلب سحب معتمد. يمكننا تهيئة هذا في ترافيس بالنقر فوق المزيد من الخيارات → الإعدادات.

  • تأكد من ضبط "إنشاء فروع مدفوعة" على
  • تأكد من ضبط "إنشاء طلبات السحب المدفوعة" على

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

  • السطر 1: يحدد أننا نريد فقط إنشاء بناء على الفرع الرئيسي. في بيئة حقيقية ، من المحتمل أن ننتشر أيضًا عند الضغط على الفرع ، ولكن في بيئة اختبار بدلاً من بيئة الإنتاج. إحدى الطرق التي يمكن القيام بها هي استخدام متغيرات البيئة لتطبيق المنطق الشرطي على البرنامج النصي للنشر ، ولكن هذا خارج عن نطاق هذا المنشور.
  • السطر 4: يحدد أننا نطلب أذونات الجذر باستخدام sudo من أجل تثبيت تبعياتنا
  • السطر 5: هذه هي بداية الكتلة حيث نقوم بتعيين الأذونات على كل من البرامج النصية لدينا بحيث تكون قابلة للتنفيذ.
  • السطر 10: هذه هي بداية الكتلة حيث نحدد البرامج النصية التي يجب تشغيلها أولاً من أجل إعداد بيئة CI قبل أن نتمكن من تنفيذ البرامج النصية التي تقوم بعملية النشر الفعلية.
  • السطر 13: هذه هي بداية الكتلة حيث نحدد البرامج النصية التي سيتم تشغيلها لتنفيذ مهام النشر.

الخطوة 3: إدارة الأسرار

لا نريد الاحتفاظ بأسرار AWS الخاصة بنا في مستودع عام بنص واضح ؛ هذا سيكون ممارسة سيئة للغاية لأمن المعلومات. Handily ، يوفر Travis أداة CLI والتي يمكن استخدامها لتخزين أسرارك ليتم حقنها في وقت البناء. ينشئ Travis زوج مفاتيح عامًا / خاصًا جديدًا لكل حساب جديد ، وسيتم تشفير هذه الأسرار باستخدام زوج المفاتيح هذا ويتم حقنه كمتغيرات بيئية في كل مرة يتم فيها تشغيل البنية. لإعداد هذا الأمر ، قم بتشغيل الأوامر التالية في جذر المستودع الخاص بك وقم بتسجيل الدخول باستخدام التفاصيل المطلوبة:

جوهرة سودو $ تثبيت ترافيس
$ ترافيس تسجيل الدخول -

هناك نصان تم تحميلهما مسبقًا في دليل نصوص البناء في مستودعنا جاهزان لإدخال أسرارك. انسخ دليل build_scripts من نسختك المحلية من مستودع تعليمي k8s إلى مستودع k8s-ci الخاص بك وقم بتحديثه كما يلي:

  • large-secrets.txt: أضف مفاتيح وصول Kubernetes الخاصة بك. هذه يمكن العثور عليها في ~ / .kube / config
  • setup-secrets.sh: أضف كلمة مرور Kubernetes (وجدت مرة أخرى في ~ / .kube / config) ومفاتيح الوصول إلى AWS من ~ / .aws / بيانات الاعتماد

بعد ذلك ، من جذر مستودعك ، قم بتشغيل البرنامج النصي setup-secrets.sh باستخدام الأمر التالي:

chmod $ 755 بناء البرامج النصية / الإعداد - سيكريتس
$ ./build-scripts/setup-secrets.sh

قم بتدوين الأمر openssl الذي سيعود البرنامج النصي setup-secrets.sh إليه في وقت لاحق ، حيث سنحتاج إلى فك تشفير الأسرار.

سيقوم هذا البرنامج النصي بتشفير أسرارك باستخدام Travis وتحديث ملف .travis.yml. ارتكب الأسرار المشفرة على مستودعك:

git add build-scripts / large-secrets.txt.enc .travis.yml
$ git -m "ارتكاب الأسرار المشفرة"

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

الشراب $ تثبيت بوابة أسرار
أسرار $ بوابة - تثبيت

الخطوة 4: تثبيت التبعيات

نظرًا لأن TravisCI يدير كل بناء في حاوية Docker نظيفة ، فنحن بحاجة إلى تثبيت تبعياتنا في كل مرة. هذه التبعيات هي نفسها التي حددناها في قسم "قبل البدء" في هذا المنشور. قم بإنشاء ملف يسمى install-dependencies.sh في مجلد برامج الإنشاء ولصق التكوين التالي فيه:

الآن قم بإرسال هذا الملف إلى مستودعك:

$ git add install-dependencies.sh
git $ - الالتزام "إضافة برنامج نصي لتثبيت التبعيات"

الخطوة 5: حقن أسرارنا

نحتاج الآن إلى برنامج نصي لإعداد أسرارنا في حاوية Docker التي سنفعلها خطوات البناء الخاصة بنا. قم بإنشاء ملف باسم inject-secrets.sh في مجلد برامج الإنشاء. الصق في البرنامج النصي أدناه وتحديثه على النحو التالي:

  • استبدل {رابط نظام المجموعة هنا} بعنوان URL الخاص بمجموعة Kubernetes
  • استبدل أمر OpenSSL الذي قدمناه في الخطوة 3 من هذا القسم بـ {أمر opensl الخاص بك من مرحلة تشفير الأسرار هنا} إلحاق ./build-scripts/ قبل large-secrets.txt.enc
  • استبدل {your-aws-region} بمنطقة AWS التي تستخدمها

سيقوم هذا البرنامج النصي بسحب أسرارنا من بيئة Travis وفك تشفيرها وإدخالها في ملفات التكوين ذات الصلة.

ستلاحظ في البرنامج النصي أعلاه أنه يشير إلى ملف في دليل نصوص البناء المسمى kubeconfig - سنحتاج إلى إنشاء هذا أيضًا. الصق المحتويات الموجودة أدناه ، واستبدل المتغير {Your cluster url here} بعنوان URL الخاص بمجموعة Kubernetes.

قم بربط كلا الملفين بمستودعك:

git add inject-secrets.sh kubeconfig
git الالتزام - م "إضافة برنامج نصي لحقن الأسرار وملف kubeconfig"

الخطوة 6: إعداد البيئة

قبل أن نكون مستعدين لنشر التطبيقات ، نحتاج إلى إعداد الكتلة من خلال نشر التكوين لـ kube2iam و DNS الخارجية. يجب تطبيق التكوين لكل من هذه الأدوات بترتيب محدد:

  • تطبيق تكوين Terraform لإنشاء دور AWS IAM جديد (ومنح السياسة المطلوبة لذلك الدور) وعلاقة ثقة مرة أخرى إلى دور AWS IAM الذي تعمل به العقد. تسمح علاقة الثقة للعقدة بتولي دور IAM الجديد.
  • قم بتطبيق تكوين Kubernetes RBAC لإنشاء حساب خدمة ، وقم بربطه بنطاق إذن مطلوب ، ومنح الأذونات المطلوبة لحساب الخدمة هذا. يتم بعد ذلك تحديد حساب الخدمة هذا كجزء من تكوين البرامج التي توفر كل خدمة من الخدمات المحددة.
  • تطبيق تكوينات Kubernetes لنشر الخدمات. اعتمادًا على الخدمة التي يتم نشرها ، قد يكون هذا نشر Kubernetes أو DaemonSet.

سننشئ برنامجنا النصي للنشر بحيث تتم تهيئة المجموعة دائمًا أولاً.

انسخ عبر المجلدات التي تحتوي على قوالب لنظام أسماء النطاقات الخارجية و kube2iam من مستودعنا إلى مستودعك.

أولاً ، سننشئ برنامج نصي سيطبق تكوين Terraform الخاص بنا. قم بإنشاء ملف يسمى publish-terraform.sh في دليل build-scripts وقم بإضافة التعليمة البرمجية التالية إليه:

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

(ملاحظة: في بيئة الإنتاج الحقيقية ، نضيف شيكات في خط أنابيب CI الخاص بنا للتأكد من عدم استخدام Terraform بشكل ضار)

ارتكب هذا إلى مستودعك:

$ git add publish-terraform.sh
git $-الالتزام "إضافة برنامج Terraform للنشر"

نحن الآن على استعداد لتحديث وتهيئة تهيئة Terraform لكل من خدماتنا الثلاث إلى المستودع:

  • قم بتحديث external_dns / pod-role-trust-policy.json واستبدل {your-node-iam-role-arn} بـ IAM ARN لعقد Kubernetes في نظامك. يمكن العثور على هذا عن طريق تشغيل الأمر التالي:
$ aws لام قائمة الأدوار | عقدة grep
  • قم بتحديث external_dns / main.tf لاستبدال {your-aws-region} بمنطقة AWS التي تعمل فيها و {your-tf-bucket} باسم المجموعة التي اخترت الاحتفاظ بها في Terraform state store.

الالتزام بتكوين الخدمة إلى مستودعك:

git add external_dns / pod-role-trust-policy.json external_dns / external-dns-iam-setup.tf external_dns / external-dns-role-rights.json external_dns / main.tf
git الالتزام - م "إضافة تكوين خدمة Terraform الكتلة"

يتم تكوين Travis لتطبيق التكوين على كل دفعة لإتقانها لذلك إذا قمنا بتنفيذ عملية دفع الآن:

دفع بوابة git

يجب أن نكون قادرين على رؤية جميع إعدادات Terraform الخاصة بنا يتم تطبيقها على حساب AWS الخاص بنا في سجل الوظائف.

لقد أنشأنا الآن جميع أدوار IAM وعلاقات الثقة التي تحتاجها بيئة Kubernetes الخاصة بنا.

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

  • external_dns / external_dns.yaml: استبدل {your-dns-zone} بمنطقة DNS التي تستخدمها ، {your-identifier} بشيء يميز سجلات DNS التي ستنتجها DNS الخارجية (مثل اسمك) ، و {your -external-dns-iam-role-arn} مع IAM ARN للدور الذي تم إنشاؤه عند تطبيق تكوين Terraform. يمكن العثور على هذا عن طريق تشغيل الأمر التالي:
$ aws i-get get - role - name external_dns_pod_role
  • kube2iam و rbac /: لا توجد تحديثات مطلوبة

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

الآن قم بإدخال هذه الملفات في المستودع:

git add external_dns / external_dns.yaml rbac / kube2iam /
git الالتزام - م "إضافة التكوين k8s الخارجية DNS"

سنبدأ الآن في إنشاء نص نشر خاص بخدمات Kubernetes الخاصة بنا. إنشاء ملف باسم نشر- k8s.sh في مجلد البرامج النصية الإنشاء. ابدأ تشغيل الملف برأس مثل هذا:

بعد ذلك ، أضف الخطوات التالية التي تنشر تكوين Kubernetes RBAC إلى الكتلة:

هناك حاجة إلى هذه الخطوات لأن خدمة DNS الخارجية تتطلب حقوق Kubernetes API من أجل تشغيل وتقديم خدماتها إلى الكتلة. كتذكير ، تضمن RBAC أن القرون لا يمكنها الوصول إلى واجهة برمجة تطبيقات Kubernetes بشكل افتراضي. وهذا يتماشى مع "مبدأ امتياز أقل" ويمنع القرون من تغيير إعدادات الكتلة إذا تم اختراقها لأي سبب من الأسباب.

من أجل جعل TravisCI يطبق هذه التغييرات ، نحتاج إلى إضافة خطوة إضافية إلى .travis.yml لدينا لتنفيذ publish-k8s.sh. أضف التالي إلى before_install: قسم:

- chmod + x ./build-scripts/deploy-k8s.sh

وفيما يلي في البرنامج النصي: قسم:

- "./build-scripts/deploy-k8s.sh"

الآن ، قم بنشر -k8s.sh و .travis.yml وادفع مستودع التخزين الخاص بك لإتقانه والتأكد من عدم وجود أخطاء في سجل إنشاء Travis:

git add build-scripts / publish-k8s.sh .travis.yml
git $ - الالتزام "إضافة تكوين Travis لنشر تهيئة k8s"
دفع بوابة git

الآن بعد أن تمت إضافة تكوين Terraform و RBAC إلى خط أنابيب CI / CD الخاص بنا ، دعنا نضيف خطوات لنشر kube2iam في برنامجنا للنشر- k8s.sh:

يتم نشر kube2iam أولاً نظرًا لأن DNS الخارجية ستجري مكالمات على واجهة برمجة تطبيقات AWS باستخدام kube2iam كوسيط.

ادفع الآن مستودعك لإتقانه والتأكد من عدم وجود أخطاء في سجل البناء:

git add build-scripts / publish-k8s.sh
$ g-الالتزام - "تحديث تهيئة Travis لنشر تهيئة k8s"
دفع بوابة git

الآن ، دعونا نتحقق من نظامنا للتأكد من أن جميع الخدمات قد تم نشرها بشكل صحيح. external-dns هو نشر ، لذلك يمكننا تنفيذ الأمر التالي للحصول على حالته:

kubectl $ الحصول على عمليات النشر - مساحة الاسم = نظام kube

إذا تم نشر كل شيء بشكل صحيح ، يجب أن نرى شيئًا مثل:

الاسم المطلوب عصر محدث متاح
كاليكو-كوب-تحكم 1 1 1 1 1 ساعة
كاليكو سياسة تحكم 0 0 0 0 1H
DNS تحكم 1 1 1 1 1H
نظام أسماء النطاقات الخارجية 1 1 1 1 1m
kube-dns 2 2 2 2 1h
kube-dns-autoscaler 1 1 1 1 1h

يتم نشر kube2iam كـ DaemonSet لأنه يحتاج إلى التشغيل على جميع العقد للتوسط في المكالمات إلى واجهة برمجة تطبيقات AWS. نقوم بتشغيل الأمر التالي للحصول على حالته:

kubectl $ الحصول على ds - مساحة الاسم = نظام kube

إذا كان كل شيء على ما يرام ، يجب أن نرى شيئًا مثل:

الاسم الحالي المرغوب فيه جاهز لتحديث عصر العقدة المتاح
calico-node 6 6 6 6 6 <بلا> ساعة واحدة
kube2iam 3 3 3 3 3 <لا شيء> 7 م

الخطوة 7: نشر تطبيق اختبار

حان الآن وقت جني ثمار العمل الشاق المتمثل في إعداد المجموعة الخاصة بنا ومعرفة قوة سير العمل والبنية التحتية الخاصة بنا كرمز لنشر تطبيق اختبار بسهولة!

أولاً ، نحتاج إلى إضافة خطوة نشر إلى البرنامج النصي للنشر -k8s.sh الذي سينشر تطبيقاتنا:

ستطبق هذه الخطوة أي ملفات تكوين Kubernetes في دليل التطبيقات لمستودعنا على الكتلة. ارتكب هذا التغيير واضغط لإتقان:

git add build-scripts / publish-k8s.sh
$ g الالتزام - م "تحديث التكوين ترافيس لنشر التكوين k8s للتطبيقات"
دفع بوابة git

نظرًا لأننا بدأنا رحلتنا نحو GitOps ، فلنتبع تدفق عملية GitOps لنشر تطبيق اختبار:

  • قم بإنشاء فرع محلي عن طريق تشغيل الأمر التالي:
git checkout -b testapp
  • قم بإنشاء مجلد تحت تطبيقات تسمى في مستودعك
  • في مجلد التطبيقات ، قم بإنشاء ملف يسمى hello_app_deployment.yaml وأضف ما يلي إليه:

يحتوي هذا التكوين على قسمين:

  1. النشر: يحدد هذا تفاصيل الحاوية التي سنقوم بتشغيلها ، وكمية الموارد التي يجب تقديمها لها ، والمنفذ الذي يمكن الوصول إلى التطبيق داخل الحاوية عليه ، وعدد النسخ المتماثلة لهذا التطبيق الذي نريد تشغيله. في هذه الحالة ، سنقوم بتشغيل حاوية بسيطة تطبع "التحية ، الكرة الأرضية!" ثم اسم مضيف الحاوية إلى المنفذ 8080. نحدد أننا سنقوم بتشغيل 3 نسخ متماثلة - واحدة لكل عقد من مجموعاتنا.
  2. الخدمة: هذا يحدد كيفية تعريض النشر ، داخليًا أو خارجيًا. في حالة تطبيق الاختبار الخاص بنا ، فإننا نعرضه داخليًا على عنوان IP للكتلة على المنفذ 80. ونحدد أيضًا FQDN الودي (مثل شيء مثل saluations.yourdomain.com) الذي يمكن الوصول إلى تطبيقنا هنا. ستحتاج إلى استبدال {your FQDN هنا} بـ FQDN الخاص بك.

الآن ، قم بإرسال هذا الملف إلى فرعك المحلي وادفع الفرع إلى مستودع التخزين عن بُعد:

git add hello_app_deployment.yaml
git ارتكاب -m "إضافة تطبيق اختبار"
بوابة git دفع يو أصل testapp

إذا قمنا بتسجيل الدخول إلى GitHub ، يجب أن نرى الآن لدينا فرع جديد يسمى "testapp":

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

بمجرد اكتمال النشر ، يمكننا التحقق من نشر تطبيق الاختبار بشكل صحيح عن طريق تشغيل الأوامر أدناه والتحقق من مخرجات مماثلة:

kubectl $ الحصول على نشر التحيات نشر
الاسم المطلوب عصر محدث متاح
التحية-نشر 3 3 3 3 24d
kubectl $ الحصول على خدمات التحية الخدمة
اسم الفئة (IP) لبطاقات (IP) الخارجية لبروتوكول الإنترنت (IP)
التحية الخدمة 100.65.66.9 a78b874f74ed0 ... 80: 32439 / TCP 6d

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

نجاح! إذا قمت الآن بتحديث هذه الصفحة ، فسترى تغيير اسم المضيف عندما يصل متصفحك إلى التطبيق الذي يعمل على عقدة Kubernetes مختلفة من خلال Classic Load Balancer.

ملخص

باستخدام هذا البرنامج التعليمي ، قمنا ببناء مجموعة Kubernetes مع مجموعة جيدة من الإعدادات الافتراضية للأمان ، ثم لفنا خط أنابيب CI / CD بسيط من حوله. بعد ذلك حددنا من خلال البنية التحتية ككود كيف أردنا نشر تطبيق حاويات بسيط واستخدمنا مجموعة أنابيب CI / CD ومجموعة Kubernetes لنشرها على النحو المحدد - تلقائيًا.

هذا مجرد مثال بسيط للفوائد الغنية التي يمكن أن تقدمها Kubernet للمطورين وقدرات DevOps الخاصة بك عند تضمينها كجزء من سلسلة أدواتك!