خفضت خدمة معلومات بيانات الأقمار الصناعية البيئية الوطنية (NESDIS) تكاليف إدارة تكوين Red Hat Enterprise بنسبة 35٪. Linux انتقلت منصة (RHEL) من Puppet Enterprise إلى Ansible Tower. في هذا الفيديو الذي يشرح كيفية القيام بذلك، يوضح مهندس الأنظمة مايكل راو الأساس المنطقي وراء هذه العملية، ويشارك نصائح مفيدة، والدروس المستفادة من الانتقال من نظام إدارة برمجيات إلى آخر.
من هذا الفيديو ستتعلم:
- كيفية تبرير للإدارة جدوى التحول من Puppet Enterprise إلى Ansible Tower؛
- ما هي الاستراتيجيات التي يجب استخدامها لجعل عملية الانتقال سلسة قدر الإمكان؛
- تظهر النصائح الخاصة بتحويل ترميز PE في Ansible Playbook؛
- توصيات للتثبيت الأمثل لبرج Ansible.
مرحبًا بالجميع، اسمي مايكل راو، أنا مهندس أنظمة أول في ActioNet، الذي يعمل في خدمة NESDIS التابعة للإدارة الوطنية للمحيطات والغلاف الجوي (NOAA). سنتحدث اليوم عن تقليم السلسلة - تجربتي الخاصة في الانتقال من Puppet Enterprise إلى Ansible Tower. موضوع هذا العرض هو "إلقاء نظرة على ندباتي" التي تركتها بعد أن قمت بهذا التحول في وقت سابق من العام. أريد أن أشارك ما تعلمته من خلال هذه العملية. لذلك عندما تقوم بشيء كهذا، باستخدام خبرتي، يمكنك إجراء التحول دون أي عمل إضافي.
ترى شرائح مشابهة لهذه في بداية كل عرض تقديمي في Ansible Fest. توضح هذه الشريحة تاريخ التشغيل الآلي لشركتي. أنا لست جديدًا على هذا لأنني أستخدم Puppet/Puppet Enterprise منذ عام 2007. بدأت العمل مع Ansible في عام 2016، ومثل العديد من المستخدمين الآخرين لهذا المنتج، انجذبت إلى إمكانية "الحيل" باستخدام سطر الأوامر والبرامج النصية البسيطة (كتب اللعب). في نهاية عام 2017، تواصلت مع إدارتي بشأن الأسباب القوية التي دفعتني للانتقال إلى برج أنسيبل. وبعد دقيقة سأخبركم عن الأسباب التي دفعتني إلى اتخاذ هذه الخطوة. بعد الحصول على موافقة الإدارة، استغرق الأمر عدة أشهر أخرى لإكمال الخطة، وقمت بالانتقال في يناير وفبراير من هذا العام. لذا، فقد تخلينا تمامًا عن Puppet لصالح Ansible، وهو أمر رائع.
أكثر ما يجذبني في Ansible هو القدرة على كتابة واستخدام الأدوار وقواعد اللعب. تعتبر الأدوار رائعة لإنشاء مهام متميزة ولكن ذات صلة ووضع جميع البيانات المتعلقة بتلك المهام في مكان واحد. دليل التشغيل عبارة عن صيغة YAML، وهو ملف نصي يصف الإجراءات لمضيف واحد أو أكثر. أخبر المستخدمين عن هذه الميزات، وفي المقام الأول مطوري البرامج. يمنحك Ansible Tower القدرة على القول: "لا، ليس لديك وصول إلى Shell، لكنني أعطيك القدرة على تشغيل جميع عمليات Tower وإعادة تشغيل الخدمة عندما تحتاج إليها." سأخبرك عن بيئة العمل والمعدات التي نستخدمها.
هذه شبكة محلية اتحادية، و7 مواقع فعلية متصلة عبر سحابة MPLS، و140 خادم RHEL، 99% منها افتراضية (vSphere)، وأجهزة SuperMicro، وتخزين شبكة NexentaStore، ومجموعة من محولات Cisco وArista وCumulus وإدارة التهديدات الموحدة Fortinet UTM الأدوات الموجودة في كل موقع .
يعني وجود شبكة فيدرالية أنه يجب عليّ استخدام جميع تدابير أمن المعلومات التي يقتضيها القانون. يجب أن تضع في اعتبارك أن شركة Puppet Enterprise لا تدعم معظم المعدات التي نستخدمها. نحن مضطرون لاستخدام أجهزة اقتصادية، حيث تواجه الوكالات الحكومية صعوبة في تمويل هذه النفقات. لذلك، نشتري أجهزة من فئة SuperMicro ونقوم بتجميع معداتنا من مكونات فردية، ويتم ضمان صيانتها بموجب عقود حكومية. Linuxوهذا أحد الأسباب المهمة للتحول إلى Ansible.
تاريخنا مع Puppet هو كما يلي.
في عام 2007، كانت لدينا شبكة صغيرة مكونة من 20 إلى 25 عقدة، حيث قمنا بنشر Puppet. في الأساس، كانت هذه العقد مجرد "صناديق" RedHat. في عام 2010، بدأنا باستخدام واجهة الويب Puppet Dashboard لـ 45 عقدة. مع استمرار الشبكة في التوسع، انتقلنا إلى PE 2014 في عام 3.3، وقمنا بإجراء انتقال كامل مع إعادة كتابة البيان لـ 75 عقدة. كان لا بد من القيام بذلك لأن Puppet يحب تغيير قواعد اللعبة، وفي هذه الحالة قاموا بتغيير اللغة بالكامل. وبعد مرور عام، عندما انتهى دعم الإصدار 3 من Puppet Enterprise، اضطررنا إلى الانتقال إلى PE 2015.2. كان علينا إعادة كتابة البيان مرة أخرى للخوادم الجديدة وشراء ترخيص باحتياطي يبلغ 100 عقدة، على الرغم من أنه كان لدينا في ذلك الوقت 85 عقدة فقط.
لقد مرت سنتان فقط، وكان علينا مرة أخرى القيام بالكثير من العمل للانتقال إلى الإصدار الجديد PE 2. لقد اشترينا ترخيصًا لـ 2016.4 عقدة، وكان لدينا 300 عقدة فقط. واضطررنا مرة أخرى إلى إجراء تغييرات كبيرة على البيان لأن الإصدار الجديد من اللغة كان له بناء جملة مختلف عن لغة إصدار 130. ونتيجة لذلك، تحول نظام SCM الخاص بنا من التحكم في إصدار SVN إلى Bitbucket (Git). كانت هذه "علاقتنا" مع الدمية.
لذلك، كان علي أن أشرح للإدارة سبب حاجتنا إلى الانتقال إلى نظام إدارة سلسلة توريد مختلف باستخدام الحجج التالية. الأول هو ارتفاع أسعار الخدمة. لقد تحدثت إلى الموظفين في RedHat وأخبروني أن تكلفة تشغيل شبكة مكونة من 300 عقدة مع Ansible Tower هي نصف تكلفة Puppet Enterprise. إذا قمت أيضًا بشراء Ansible Engine، فستكون التكلفة هي نفسها تقريبًا، لكنك ستحصل على ميزات أكثر بكثير من PE. وبما أننا شركة مملوكة للدولة ويتم تمويلها من الميزانية الفيدرالية، فهذه حجة قوية جدًا.
الحجة الثانية هي التنوع. يدعم Puppet فقط الأجهزة التي تحتوي على وكيل Puppet. وهذا يعني أنه يجب تثبيت الوكيل على كافة المحولات، ويجب أن يكون الإصدار الأحدث. وإذا كانت بعض المحولات الخاصة بك تدعم إصدارًا واحدًا، والبعض الآخر يدعم إصدارًا آخر، فستحتاج إلى تثبيت إصدار جديد من وكيل PE عليها حتى تتمكن جميعها من العمل في نفس نظام SCM.
يعمل نظام Ansible Tower بشكل مختلف لأنه لا يحتوي على أي وكلاء، ولكنه يحتوي على وحدات تدعم محولات Cisco وجميع المحولات الأخرى. يدعم نظام إدارة التحكم في البرمجيات هذا نظام التشغيل Qubes OS. Linux يدعم Ansible Tower أيضًا وحدات تحكم تخزين الشبكة NexentaStore، المبنية على نواة Illumos - وهو نظام تشغيل مفتوح المصدر قائم على Unix. هذا دعم محدود للغاية، لكن Ansible Tower لا يزال يوفره.
الحجة الثالثة، وهي مهمة جدًا بالنسبة لي ولإدارتنا، هي سهولة الاستخدام. لقد أمضيت 10 سنوات في إتقان وحدات Puppet وكود البيان، لكنني تعلمت Ansible في غضون أسبوع لأن التعامل مع SCM أسهل بكثير. إذا قمت بتشغيل ملفات قابلة للتنفيذ، بالطبع، إلا إذا قمت بذلك دون داعٍ، فإن المعالجات الذكية وسريعة الاستجابة تعمل معها. تعتبر أدلة اللعب المبنية على YAML سهلة التعلم وسريعة الاستخدام. أولئك الذين لم يسمعوا عن YAML من قبل يمكنهم ببساطة قراءة النصوص وفهم كيفية عملها بسهولة.
لكي نكون صادقين، فإن Puppet يجعل عملك كمطور أكثر صعوبة لأنه يعتمد على استخدام Puppet Master. إنها الآلة الوحيدة المسموح لها بالتواصل مع عملاء الدمى. إذا قمت بإجراء أي تغييرات على البيان وأردت اختبار التعليمات البرمجية الخاصة بك، فيجب عليك إعادة كتابة التعليمات البرمجية لـ Puppet Master، أي تكوين ملف Puppet Master /etc/hosts لتوصيل جميع العملاء وبدء خدمة Puppet Server. فقط بعد ذلك ستتمكن من اختبار تشغيل معدات الشبكة على مضيف واحد. هذا إجراء مؤلم إلى حد ما.
كل شيء أبسط بكثير في Ansible. كل ما عليك فعله هو تطوير التعليمات البرمجية لجهاز يمكنه الاتصال عبر SSH مع المضيف قيد الاختبار. هذا أسهل بكثير في العمل معه.
الميزة الكبيرة التالية لـ Ansible Tower هي القدرة على الاستفادة من نظام الدعم الحالي لديك والحفاظ على تكوين أجهزتك الحالية. يستخدم هذا SCM جميع المعلومات المتاحة حول البنية التحتية والأجهزة والأجهزة الافتراضية والخوادم وما إلى ذلك دون أي خطوات إضافية. يمكنه التحدث إلى خوادم RH Satellite الخاصة بك، إذا كان لديك واحدة، ويمنحك عمليات تكامل لن تحصل عليها أبدًا مع Puppet.
شيء آخر مهم هو التحكم التفصيلي. أنت تعلم أن Puppet عبارة عن نظام معياري، وهو تطبيق خادم عميل، لذا يجب عليك تحديد الجوانب الموجودة لجميع أجهزتك في بيان واحد طويل. في هذه الحالة، يجب اختبار حالة كل عنصر على حدة في النظام كل نصف ساعة - وهذه هي الفترة الافتراضية. هذه هي الطريقة التي تعمل بها الدمية.
برج ينقذك من ذلك. يمكنك تشغيل مجموعة متنوعة من العمليات على مجموعة متنوعة من المعدات دون قيود؛ يمكنك القيام بالأعمال الأساسية، وتشغيل العمليات المهمة الأخرى، وإعداد نظام الأمان، والعمل مع قواعد البيانات. يمكنك القيام بكل ما هو صعب في Puppet Enterprise. لذلك، إذا قمت بتكوينه على مضيف واحد، فسوف يستغرق الأمر بعض الوقت حتى تدخل التغييرات حيز التنفيذ على المضيفين المتبقين. في Ansible، تصبح جميع التغييرات سارية المفعول في نفس الوقت.
أخيرًا، دعونا نلقي نظرة على وحدة الأمان. لقد تم تطبيقها في Ansible Tower بشكل مذهل، بدقة وشمولية عاليتين. يمكنك منح المستخدمين إمكانية الوصول إلى خدمات أو مضيفين محددين. أقوم بذلك مع موظفيّ الذين اعتادوا العمل على Windowsتقييد وصولهم إلى الصدفة Linuxأقوم بتزويدهم بإمكانية الوصول إلى نظام Tower حتى يتمكنوا من القيام بالعمل وتشغيل الخدمات التي تقع ضمن اختصاصهم فقط.
دعونا نلقي نظرة على الأشياء التي يتعين عليك القيام بها مسبقًا لتسهيل انتقالك إلى Ansible Tower. بادئ ذي بدء، تحتاج إلى إعداد المعدات الخاصة بك. إذا لم تكن بعض عناصر البنية الأساسية الخاصة بك موجودة بالفعل في قاعدة البيانات، فستحتاج إلى إضافتها هناك. هناك أنظمة لا تتغير خصائصها وبالتالي فهي غير موجودة في قاعدة بيانات Puppet، ولكن إذا لم تقم بإضافتها هناك قبل الانتقال إلى Tower، فستفقد عددًا من المزايا. قد تكون هذه قاعدة بيانات أولية "قذرة"، ولكنها يجب أن تحتوي على معلومات حول جميع المعدات الموجودة لديك. لذلك، يجب عليك كتابة برنامج نصي ديناميكي للأجهزة والذي سيدفع تلقائيًا جميع تغييرات البنية التحتية إلى قاعدة البيانات، ثم سيعرف Ansible المضيفين الذين يجب أن يكونوا موجودين في النظام الجديد. لن تحتاج إلى إخبار SCM بالمضيفين الذين أضفتهم والمضيفين الذين لم يعودوا موجودين، لأنه سيعرف كل هذا تلقائيًا. كلما زاد عدد البيانات الموجودة في قاعدة البيانات، أصبح Ansible أكثر فائدة ومرونة. إنه يعمل كما لو أنه يقرأ ببساطة الرمز الشريطي لحالة الأجهزة من قاعدة البيانات.
اقض بعض الوقت في التعرف على سطر الأوامر في Ansible. قم بتشغيل بعض الأوامر المخصصة لاختبار البرنامج النصي للأجهزة، وكتابة وتشغيل بعض البرامج النصية البسيطة والمفيدة لدليل التشغيل، واستخدام قوالب Jinja2 حيثما كان ذلك مناسبًا. حاول كتابة دور وبرنامج نصي لعملية معقدة ومتعددة الخطوات باستخدام تكوين أجهزة شائع الاستخدام. العب بهذه الأشياء، واختبر كيفية عملها. بهذه الطريقة ستتعلم كيفية استخدام أدوات إنشاء المكتبة المستخدمة في Tower. لقد قلت بالفعل إن الأمر استغرق مني حوالي 3 أشهر للتحضير لعملية الانتقال. أعتقد أنه بناءً على تجربتي، ستتمكن من القيام بذلك بشكل أسرع. لا تعتبر هذا الوقت ضائعًا، لأنك ستستمتع لاحقًا بجميع فوائد العمل المنجز.
بعد ذلك، عليك أن تقرر ما تتوقعه من Ansible Tower، وما الذي يجب أن يفعله هذا النظام لك بالضبط.
هل تحتاج إلى نشر النظام على الأجهزة العارية، على الأجهزة الافتراضية العارية؟ أم أنك ترغب في الحفاظ على ظروف التشغيل والإعدادات الأصلية للمعدات الموجودة؟ يعد هذا جانبًا مهمًا جدًا للشركات العامة، لذا عليك التأكد من أنك ستتمكن من ترحيل Ansible ونشره على التكوين الحالي الخاص بك. حدد العمليات الإدارية الروتينية التي تريد أتمتتها. اكتشف ما إذا كنت بحاجة إلى نشر تطبيقات وخدمات محددة على النظام الجديد. قم بإعداد قائمة بما تريد القيام به وحدد أولوياته.
بعد ذلك، ابدأ بكتابة البرامج النصية والأدوار التي ستنفذ المهام التي خططت لها. قم بتجميعها في مشاريع، وهي عبارة عن مجموعة منطقية من البرامج النصية ذات الصلة. سيشير كل مشروع إلى مستودع Git منفصل أو مستودع آخر، وذلك حسب مدير التعليمات البرمجية الذي تستخدمه. يمكنك إدارة البرامج النصية ومجلدات البرامج النصية عن طريق وضعها يدويًا في مسار المشروع الأساسي على خادم Tower، أو عن طريق وضع البرنامج النصي في أي نظام لإدارة التعليمات البرمجية المصدرية (SCM) يدعمه Tower، بما في ذلك Git وSubversion وMercurial وRed Hat Insights. يمكنك وضع أي عدد تريده من البرامج النصية داخل مشروع واحد. على سبيل المثال، أنشأتُ مشروعًا أساسيًا واحدًا يحتوي على برنامج نصي للعناصر الأساسية لـ Red Hat، وبرنامج نصي للأساسيات، وبرنامج نصي للأساسيات. Linux، وسيناريوهات لمقاييس خط الأساس المتبقية. وبالتالي، احتوى مشروع واحد على مجموعة واسعة من الأدوار والسيناريوهات، وكلها تُدار من مستودع Git واحد.
يعد تشغيل كل هذه الأشياء عبر سطر الأوامر طريقة جيدة لاختبار وظائفها. سيؤدي هذا إلى إعدادك لتثبيت البرج.
دعونا نتحدث قليلاً عن تحويل شفرة بيان الدمية، لأنني قضيت الكثير من الوقت في هذا الأمر حتى اكتشفت ما يجب القيام به بالفعل.
كما قلت من قبل، يقوم Puppet بتخزين جميع الإعدادات وخيارات الأجهزة في بيان واحد طويل، وهذا البيان يخزن كل ما يجب أن يفعله SCM. عند إجراء عملية النقل، لا تحتاج إلى حشر جميع مهامك في قائمة واحدة؛ بدلاً من ذلك، فكر في بنية النظام الجديد: الأدوار، والبرامج النصية، والعلامات، والمجموعات وما يجب أن يكون هناك. يجب تجميع بعض عناصر الشبكة المستقلة في مجموعات يمكن إنشاء البرامج النصية لها. يمكن دمج عناصر البنية التحتية الأكثر تعقيدًا والتي تتضمن عددًا كبيرًا من الموارد، بما في ذلك الفئات المستقلة، في أدوار. قبل الهجرة، عليك أن تقرر هذا الأمر. إذا كنت تقوم بإنشاء أدوار أو سيناريوهات كبيرة لا تتناسب مع شاشة واحدة، فيجب عليك استخدام العلامات لتتمكن من التقاط أجزاء معينة من البنية الأساسية.
18:00
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com
