وفي الحالة التي يتوجب إنشاء بنية التحكم في بيئات متعددة بالقيام بالتوحد والمراقبة الفعالة، يصبح من المهم توفير هذه البيئات بشكل آمن. لإنجاز هذا، يتم اتخاذ مقاربة لا تتغير للبنية التحكمية، حيث تتم تأهيل البيئات كبرمجيات.
هدف هذا المقال هو إظهار طريقة ممكنة لإنجاز هذا باستخدام بنيات جيتلاب لتنفيذ القوالب والمعايير، وتيررافورم لتطبيق وحماية المعايير عبر الخوادم، وأنسبلي لتوفير البرمجيات والتكوين، باستخدام نموذج مشترك للأدوار عبر المخزونات. لإدارة حالة الآلات مع تيررافورم، نستخدم مينيو، لأنها تمكننا من تنفيذ هذه التطبيقة في الموقع الداخلي.
تصميم الهندسة
خطوة 1
يبدأ العمل دائمًا بتقديم قضية قياسية، محددة نموذج البنية التحكمية التي ستستخدم، وما إذا كان من الضروري تمويل الأذواق، وما إذا كان هذا هو إعداد جديد أو مجرد تحديث موارد.
خطوة 2
يقوم المشغل بمراجعة القضية ويبدء العمل. كل المحادثات والوقت المصرفي يتم تسجيله داخل القضية.
خطوة 3
بدء مشروع جديد في جيتلب، يعتمد على نموذج البنية التحتية الذي سينشئ. يتم وضع هذا المشروع داخل المجموعة المناسبة في جيتلب، حيث يورث المتغيرات البيئية الضرورية لخلق بنية تحتية موحدة.
الخطوة 4
عند إنشاء المشروع، يكفي أن تحدد الآيبيات للبنية التحتية التي سيقوم بتخصيصها في البيئة المحددة في المشكلة (KVM، VMware). بعد التخطيط مع Terraform، ينشئ الموارد اللازمة، بما في ذلك إضافة البطاقات إذا كان ذلك مطلوباً، لـVeeam لإجراء النسخ الاحتياطية بناءً على سياسات البطاقات. بمجرد الانتهاء، يتم تخزين حالة البنية التحتية المنشأة في حقيبة.
الخطوة 5
تتم الخطوة التالية بإجراء المهام القياسية لجميع الخوادم، مثل تحديدهم، تحديث الباقات، تثبيت الأدوات الضرورية، وتسجيل المضيف في Zabbix للمراقبة الأساسية لنظام التشغيل والمكوك. وفقاً لمجموعة الموارد، يتم تخصيص المفاتيح الدخولية النموذجية للفرق المسؤولة. على سبيل المثال، يتلقون مسؤولو القواعد البيانية مفاتيح الدخول لخوادم قواعد البيانات.
الخطوة 6
بناءً على النموذج المختار، يتم إجراء عملية تثبيت وتهيئة المكوك بأكمله. بالمثل، ينشئ المستخدمون، وتسجيل الاعتمادات في Vault حينما يكون ذلك ضرورياً.
الخطوة 7
بعد أن يبدأ التطبيق الآن في البيئة الجديدة، يمكن أن يتم مراقبة تعيينية لكل قاعدة، وتسجيل الخوادم الجديدة في Consul. بموجب إيجاد ما يحتاج إليه بروميثيوس لجمع المعلومات من مكانه. لكل قاعدة خاصة لها واحد من واجهات المراقبة المتكيفة بالفعل، وهي تختلف فقط بما يتعلق بإسم المشروع الذي تم إنشاؤه.
الخطوة 8
يتم تقديم البنية التحتية الجديدة للمطالب. في حالة البases البيانية، يتم توفير المعلومات الشخصية مباشرة في Vault.
تكوين المشروع
تنظيم مجلد المشاريع في GitLab يتم تنظيمه بالتالي:
- /infrastructure/: المجموعة الرئيسية، حيث يجب تخزين المتغيرات البينية العالمية والقيم الافتراضية الاولية.
- /infrastructure/gitlab-models: نماذج الخوادم التي يوجد فيها مشروعين رئيسيين
- ansible-pipelines: مشروع مختص بال mantenimiento de las pilas y la composición de los roles.
في الصورة الأعلى، نرى مثال للمهام الشائعة. في البنية، يوجد في المسار:/infrastructure/gitlab-models/ansible-pipelines/common-task/provision.yml
- terraform-pipelines: خوادم البنية التي تتضمن نماذج البنية التحتية المتاحة، مثل vSphere، KVM، AWS، وما إلى ذلك.
في الصورة أعلاه، لدينا مثال على خطوط توفير الموارد التي تقع داخل مجموعة terraform-pipelines، مثل kvm-terraform-pipeline.yml. وكما نرى، إنه نموذج GitLab CI المقصود ليتم توسيعه في خطوط عملية الكومة.
- /infrastructure/templates: في هذه المجموعة، لدينا مشاريع البوت斯特راب، التي ستستخدم لخلق نماذج الكومة.
- /infrastructure/provision/ansible/roles: في هذا المشروع، لدينا فقط أدوار Ansible، مما يسمح لنا بمركزية وتحديث الأدوار بطريقة منعزلة.
- /infrastructure/dependencies-iac: يحتوي هذا الريبوزيتوري على إعتمادات الplatform، مثل Dockerfiles لـTerraform و Ansible، مما يؤكد أن إصدارات الأدوات والمكتبات الضرورية لن تتغير.
- /infrastructure/modules/: يتم تخزين ماوديولات Terraform التي خلقت في هذا الريبوزيتوري، ويحصل كل مشروع على مجلده الخاص.
- /infrastructure/on-premise/: هذه المجموعة هي حيث سيتم الحفاظ على البنية التحتية التي خلقت، ومنقسمة بالبيئة، ومركز البيانات، والكومة، والمشروع. وفي الصورة، يمكننا رؤية التسلسل الهرمي للمجموعات والمجموعات الفرعية إلى المشروع النهائي. في كل واحد من هذه الطبقات، يمكننا تغيير قيم المتغيرات المرتبطة بالمجموعات.
كيفية استخدام الplatform
لتبسيط استخدام الplatform، أنشأنا مخزن يسمى issues-ops، حيث نقدم قالب القضية الذي يمكن اختياره بموجب الاحتياجات الخاصة. بهذه الطريقة، يتم تسجيل طلب البنية التحتية منذ البداية.
حين يتم إنشاء المشكلة، يمكن لفريق الDevSecOps البدء بإعداد البيئة. للقيام بذلك، يتوجب عليهم فقط التوجه إلى المجموعة المناسبة، في هذه الحالة infrastructure/on-premise/staging/dc1/loadbalancer/nginx، وإنشاء مشروع جديد وفقاً للقالب. يجب عليهم من ثم تقديم أسم المشروع الذي سيتم إنشاؤه وتخصيص المتغيرات المطلوبة.
وفي كل قالب، يتم بالفعل تكوين ملف .gitlab-ci.yml المطلوب لإنشاء البيئة. وفي حالة NGINX، يتم تكوينه بهذا التقنيق.
في هذه الإعدادة، يتضمنا كل تمثالات البناء البيئي والقالبات Ansible، متأكدين أن تلك ال roles الافتراضية بالفعل مدمجة في هذه المشاريع. بالإضافة إلى ذلك، نقدم خطوات لتوسيع النموذج. إذا كان علينا تثبيت roles إضافيين، يمكنك ببساطة إضافة القطعة المتعلقة، تمكين منهج متكون، والتكوين القطعي للتكوين.
في الصورة أدناه، نرى الخط التجاري الذي يجرى توليد البيئة المطلوبة. ستلاحظون أن authorized_keys و common تم تنفيذهما، حتى وإن لم يكن لدينا تعيينهم بواسطة الملف .gitlab-ci.yml بوضوح. ذلك لأن لدينا roles افتراضية قياسية تأتي من القالب Ansible المستقل الذي نحن نستيرعه، متأكدين من تطبيق تلك ال roles الافتراضية عبر جميع المشاريع.
خلاصة
المنصة البنية التحتية قدمت إسهامًا كبيرًا في الحفاظ على وتطبيق المعايير لأنها تتطلب نموذج محدد مسبقًا ليتم تخطيطه، واختباره، وتنفيذه، وتتوفر كنموذج قبل إنشاء أي بنية تحتية جديدة. هذه العملية تؤكد أنه في كل مرة نحتاج إلى توفير موارد في بيئة، نقوم بإنشاء معايير متساوية، وتسلسل هذه البيئات، ونؤكد إمكانية إعادة بناءها بإمكانية بالتأكيد في حال الحاجة.
أحد التحديات الرئيسية هو الحفاظ على تحديث النماذج وتصديقها، وخاصة وأن تتطور تطبيقات وتغيير الإصدارات النظامية. من المهم تذكير أنه عند استخدام البنية التحتية ككود، يجب أن تتم جميع التغييرات من خلالها، مؤكدا تسلسل الإعداد الإجمالي والثبات البيئي. فإن فشل في ذلك قد يسبب أن تعيد المنصة البيئة إلى حالتها المحددة، وربما تجاوز التغييرات اليدوية.
النموذج المقترح في هذه المقالة متنوع، وقابل للتطبيق على البيئات الداخلية والمتعددة السحاب، مما يجعله حلاً فعالًا للبنيات الحيوية.
Source:
https://dzone.com/articles/implement-an-iac-platform-with-terraform-ansible-gitlab