دمية + هيرا. اضغط على الحد الأقصى

في هذه المقالة ، أود أن أتحدث عن كيفية استخدام Puppet و Hiera لتكوين الحديد والخوادم الافتراضية. في الأساس ، سيكون الأمر متعلقًا بالعمارة والتسلسل الهرمي الذي اخترعناه ، مما يسهل وينظم تكوين الخوادم.

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

لمن ستكون هذه المقالة مفيدة

إذا:

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

هذه المقالة لك.

قبل أن تبدأ

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

• اقرأ المزيد عن دمى العرائس هنا: عرائس للمبتدئين .
• كيف تعمل هيرا - مقدمة في هيرا .

بيانات الإدخال

• لدينا حوالي 30 فريق تطوير في SEMrush ، لكل منها خوادمها الخاصة
• يعمل كل فريق مع مجموعته الخاصة من التقنيات (PL ، DBMS ، إلخ.)
• يمكن للفرق ويجب عليها (بشكل مثالي) استخدام التكوين المشترك لمشاريع محددة (إعادة استخدام التعليمات البرمجية)
• تدير الفرق نفسها نشر التطبيقات على خوادمها (لا يتم ذلك من خلال التطبيق)

القليل من التاريخ

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

في الجزء الثالث ، اعتدنا على استخدام النظام الكلاسيكي لملفات العقدة والوحدات النمطية. تم إنشاء الوحدات النمطية في مجموعة خاصة من المشاريع في Gitlab ، وتم استنساخها إلى خادم بابيت (باستخدام r10k ) ، ثم جاء وكلاء pappet إلى المعالج وتلقوا دليلاً لتطبيقه على الخادم.

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

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

عندما يكون لديك 30 فريقًا مع حديقة حيوانات تكنولوجية ، فإن مشكلة كيفية الحفاظ على هذا المدير مع أكثر من 1000 خادم تصبح حادة بشكل خاص. علاوة على ذلك ، سأخبرنا كيف تساعدنا هيرا في ذلك.

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

هيرا (التي حصلت على اسمها في الواقع) تشكل تسلسلاً هرميًا. معنا ، يبدو هذا:

--- :hierarchy: - "nodes/%{::fqdn}" - "teams/%{::team}_team/nodes/%{::fqdn}" - "teams/%{::team}_team/projects/%{::project}/tiers/%{::tier}" - "teams/%{::team}_team/projects/%{::project}/%{::role}" - "teams/%{::team}_team/projects/%{::project}" - "teams/%{::team}_team/roles/%{::role}" - "teams/%{::team}_team/%{::team}" - "projects/%{::project}/tiers/%{::tier}/%{::role}" - "projects/%{::project}/tiers/%{::tier}" - "projects/%{::project}/%{::role}" - "projects/%{::project}" - "tiers/%{::tier}" - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common 

أولاً ، دعنا نتعامل مع المتغيرات الغامضة (الحقائق).

يجب أن يحتوي كل خادم في SEMrush بشكل مثالي على 4 حقائق خاصة مكشوفة تصف انتمائه:

• حقيقة team - أي فريق ينتمي إليه
• project حقيقة - أي مشروع يتعلق به
• حقيقة role - ما هو دور هذا المشروع
• حقيقة tier - أي نوع من المراحل لديها (همز ، اختبار ، ديف)

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

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

على سبيل المثال ، لدينا مشروع خاص . في هذا المشروع ، قد يكون هناك بعض خادم الواجهة الأمامية مع nginx ، خادم الواجهة الخلفية مع الثعبان ، كتلة db مع الخلية ، خادم redis للتخزين المؤقت. يجب وضع جميع هذه الخوادم في مشروع واحد يسمى خاص ، ثم تعيين الأدوار للخوادم.

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

في دور كل خادم ، عادة ما يتم وصف الخدمة وتخصيصها - لما يقصد به هذا الخادم (nginx ، python ، mysql ، إلخ.) الطبقة في هذه الحالة سنحتاج بالتأكيد إذا كنا بحاجة أيضًا إلى نشر نسخة من بيئة الإنتاج على منصة dev ، ولكن تغيير شيء فيه (كلمات المرور ، على سبيل المثال). في هذه الحالة ، سيختلف خادم dev وخادم prod فقط في حقيقة أنه تم تعيين الطبقة على "الموضع" المطلوب (prod أو dev). ثم القليل من السحر والهيرا سيفعلان الخدعة.

إذا كنا بحاجة إلى نشر خادمين متطابقين في نفس الدور ، ولكن يجب أن يختلف شيء فيهما ، على سبيل المثال ، بعض الخطوط في التكوين ، فسيأتي جزء آخر من التسلسل الهرمي إلى الإنقاذ. نضع الملفات باسم التنسيق {fqdn }.yaml في المكان الصحيح (على سبيل المثال ، nodes/myserver.domain.net ) ، ونعين القيم اللازمة للمتغيرات على مستوى خادم معين ، وسيطبق البابيت نفس التكوين لكل من الخوادم للدور ، وفريدًا لكل منهما من الخوادم.

مثال: يوجد خلفيتان برمز php في نفس الدور وهما متطابقان تمامًا. من الواضح أننا لا نريد عمل نسخة احتياطية من كلا الخادمين - فلا معنى لذلك. يمكننا إنشاء دور لوصف نفس التكوين لكلا الخادمين ، ثم إنشاء ملف nodes/backend1.semrush.net لوضع التكوين للنسخ الاحتياطي.

تشير teams/team-name.yaml الملف الدفعي teams/team-name.yaml إلى التكوين لكافة الخوادم التي تنتمي إلى الفريق. في أغلب الأحيان ، يصف المستخدمين الذين يمكنهم التفاعل مع هذه الخوادم ، بالإضافة إلى حقوق الوصول الخاصة بهم.

بناءً على هذه المتغيرات ، قمنا ببناء هذا التسلسل الهرمي . كلما زاد حجم الملف الموجود في التسلسل الهرمي ، زادت أولوية التكوين المحدد فيه.

ويترتب على ذلك أن المتغيرات يمكن تجاوزها بناءً على هذا التسلسل الهرمي. أي أن المتغير في ملف الدور " projects/%{::project}/%{::role} " له الأسبقية على المتغير في ملف المشروع " projects/%{::project} ". يمكن أيضًا دمج المتغيرات في جميع مستويات التسلسل الهرمي إذا كان لديك وحدة و / أو ملف تعريف / دور مكتوب بطريقة يمكن القيام بها. من خلال تحديد الجزء المشترك من mysql config لجميع خوادم المشروع ، يمكنك إضافة أجزاء خاصة لها وزن لهذا الدور إلى نفس المتغير في المستويات الأخرى من التسلسل الهرمي (سيكون هناك قسم إضافي في التكوين للعبد).

وتبين أن ملف العقدة المحددة الموجودة على المسار " hieradata/nodes/%{::fqdn} " له الأولوية القصوى. بعد ذلك يأتي ملف العقدة ، ولكن بالفعل على مستوى الأمر. يوجد أدناه الكتلة التي تصف حقائق أخرى أكثر عمومية:

  - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common 

وفقًا لذلك ، في الملف common.yaml لدينا تكوين يجب أن يأتي بالتأكيد إلى جميع الخوادم ، في ملف المستخدمين. يتم وصف جميع المستخدمين (ولكن لا يتم إنشاؤها جميعًا على الخوادم ، بالطبع) ، في os/%{::operatingsystem} التكوين العام النموذجي للخوادم ذات نظام تشغيل معين ( ::operatingsystem fact ::operatingsystem ) وما إلى ذلك.

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

الملامح

يعد استخدام ملفات التعريف نقطة مهمة في تكوين الخوادم باستخدام الوحدات. وهي تقع على site/profiles المسار وهي نقاط الدخول إلى الوحدات. بفضلها ، يمكنك تكوين الوحدات المعلقة على الخادم بشكل أكثر دقة وإنشاء الموارد اللازمة.

فكر في مثال بسيط. هناك وحدة تقوم بتثبيت وتكوين redis. ونريد أيضًا تعيين معلمة vm.overcommit_memory على 1 عند توصيل هذه الوحدة ، لأنه هنا . ثم نكتب ملفًا شخصيًا صغيرًا يوفر هذه الوظيفة:

 # standalone redis server class profiles::db::redis ( Hash $config = {}, String $output_buffer_limit_slave = '256mb 64mb 60', ) { # https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram sysctl { 'vm.overcommit_memory': ensure => present, value => '1', } class { '::redis': * => $config, } } 

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

إخفاء الأسرار في الحيره

واحدة من المزايا الهامة للهيرا مقارنة مع لوحة العارية هي قدرتها على تخزين البيانات الحساسة في ملفات التكوين في شكل مشفر في المستودع. ستكون كلمات المرور الخاصة بك آمنة.

باختصار ، يمكنك استخدام المفتاح العام لتشفير المعلومات التي تحتاجها ووضعها بمثل هذا الخط في ملف hiera. يتم تخزين الجزء الخاص من المفتاح على سيد pappet ، والذي يسمح لك بفك تشفير هذه البيانات. يمكن العثور على مزيد من التفاصيل في صفحة المشروع .

على العميل (الكمبيوتر العامل) ، يتم تثبيت الأداة ببساطة باستخدام gem install hiera-eyaml . علاوة على ذلك ، باستخدام أمر شكل eyaml encrypt --pkcs7-public-key=/path/to/public_key.pkcs7.pem -s 'hello' يمكنك تشفير البيانات ولصقها في ملف بالملحق eyaml أو yaml فقط ، اعتمادًا على كيفية تكوين ، ومن ثم سوف pappet معرفة ذلك. تحصل على شيء مثل:

 roles::postrgresql::password: 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y+VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTewqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UMm6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkvKqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAMblkKgBCR/f9KGXUgLh3/Ok60OIT5]' 

أو سلسلة متعددة الأسطر:

 roles::postgresql::password: > ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw DQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y +VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF 2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTe wqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UM m6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkv KqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7 iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAM blkKgBCR/f9KGXUgLh3/Ok60OIT5] 

يبدو أننا انتهينا من التحضير ، الآن يمكننا أن نفكر في مثال.

مثال الإصبع

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

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

المهمة هي: نحن بحاجة إلى نشر:

• خادمي db متطابقين يتم نشر postgresql عليهما
• خادمان آخران - الواجهة الأمامية مع nginx
• الخادم الخامس والسادس - backth python in docker
• كل شيء هو نفسه في بيئة مطور البرامج ، باستثناء بعض إعدادات الخادم

سننشئ التسلسل الهرمي الخاص بنا بالترتيب وسنبدأ بملف المشروع.

المشروع

قم projects/kicker.yaml ملف المشروع projects/kicker.yaml . نضع فيه ما هو مشترك بين جميع الخوادم: نحتاج إلى بعض المستودعات والمجلدات للنشر ، بالإضافة إلى مستخدم النشر نفسه.

 --- classes: - apt::debian::semrush files: "/srv/data": ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0755' '/srv/data/shared_temp': ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0775' user_management::present: - deploy 

دور ديسيبل

إنشاء ملف دور projects/kicker/db.yaml قاعدة بيانات projects/kicker/db.yaml . حتى الآن ، سنفعل ذلك دون تقسيم الخوادم إلى بيئات:

 --- classes: - profiles::db::postgresql profiles::db::postgresql::globals: manage_package_repo: true version: '10' profiles::db::postgresql::db_configs: 'listen_addresses': value: '*' profiles::db::postgresql::databases: kicker: {} profiles::db::postgresql::hba_rules: 'local connect to kicker': type: 'local' database: 'kicker' user: 'kicker' auth_method: 'md5' order: '001' 'allow connect from 192.168.1.100': type: 'host' database: 'kicker' user: 'kicker' auth_method: 'md5' address: '192.168.1.100/32' order: '002' 

نقوم هنا بتوصيل ملف تعريف واحد مكتوب للاستخدام العام من قبل كل من يريد تثبيت postgres على خادمهم. الملف الشخصي قابل للتهيئة ويسمح لك بتهيئة الوحدة بمرونة قبل تطبيقها.

بالنسبة إلى الأكثر فضولًا ، أسفل رمز القط لهذا الملف الشخصي:

 class profiles::db::postgresql ( Hash $globals = {}, Hash $params = {}, Hash $recovery = {}, Hash[String, Hash[String, Variant[String, Boolean, Integer]]] $roles = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $db_configs = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $databases = {}, Hash[String, String] $db_grants = {}, Hash[String, Hash[String, String]] $extensions = {}, Hash[String, String] $table_grants = {}, Hash[String, Hash[String, String]] $hba_rules = {}, Hash[String, String] $indent_rules = {}, Optional[String] $role = undef, # 'master', 'slave' Optional[String] $master_host = undef, Optional[String] $replication_password = undef, Integer $master_port = 5432, String $replication_user = 'repl', String $trigger_file = '/tmp/pg_trigger.file', ){ case $role { 'slave': { $_params = { manage_recovery_conf => true, } if $globals['datadir'] { file { "${globals['datadir']}/recovery.done": ensure => absent, } } $_recovery = { 'recovery config' => { standby_mode => 'on', primary_conninfo => "host=${master_host} port=${master_port} user=${replication_user} password=${replication_password}", trigger_file => $trigger_file, } } $_conf = { 'hot_standby' => { value => 'on', }, } file { $trigger_file: ensure => absent, } } 'master': { $_conf = { 'wal_level' => { value => 'replica', }, 'max_wal_senders' => { value => 5, }, 'wal_keep_segments' => { value => 32, }, } file { $trigger_file: ensure => present, } } default: { $_params = {} $_recovery = {} $_conf = {} } } class { '::postgresql::globals': * => $globals, } class { '::postgresql::server': * => deep_merge($_params, $params), } create_resources('::postgresql::server::config_entry', deep_merge($_conf, $db_configs)) create_resources('::postgresql::server::role', $roles) create_resources('::postgresql::server::database', $databases) create_resources('::postgresql::server::database_grant', $db_grants) create_resources('::postgresql::server::extension', $extensions) create_resources('::postgresql::server::table_grant', $table_grants) create_resources('::postgresql::server::pg_hba_rule', $hba_rules) create_resources('::postgresql::server::pg_indent_rule', $indent_rules) create_resources('::postgresql::server::recovery', deep_merge($_recovery, $recovery)) } 

وبالتالي ، نقوم بتثبيت Postgresql 10 ضربة واحدة ، وتكوين التكوين ( listen ) ، وإنشاء قاعدة بيانات kicker ، وكذلك كتابة قاعدتين للوصول إلى قاعدة البيانات هذه في pg_hba.conf . رائع!

دور الواجهة

نتخذ frontend . قم projects/kicker/frontend.yaml ملف projects/kicker/frontend.yaml بالمحتويات التالية:

 --- classes: - profiles::webserver::nginx profiles::webserver::nginx::servers: 'kicker.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker.semrush.com' proxy: 'http://kicker-backend.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5' 

كل شيء بسيط هنا. نقوم بتوصيل profiles::webserver::nginx الشخصية ، التي تعد الدخول إلى وحدة nginx ، كما نحدد المتغيرات ، وتحديدًا server location لهذا الموقع.

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

دور عامل الميناء

دور projects/kicker/docker.yaml docker projects/kicker/docker.yaml

 --- classes: - profiles::docker profiles::docker::params: version: '17.05.0~ce-0~debian-stretch' packages: 'python3-pip': provider: apt 'Fabric3': provider: pip3 ensure: 1.12.post1 user_management::users: deploy: groups: - docker 

profiles/docker.pp بسيط للغاية وأنيق. سأقدم رمزه:

 class profiles::docker ( Hash $params = {}, Boolean $install_kernel = false, ){ class { 'docker': * => $params, } if ($install_kernel) { include profiles::docker::kernel } } 

كل شيء جاهز. هذا يكفي بالفعل لنشر المنتج الذي نحتاجه على العديد من الخوادم ، ببساطة تعيين مشروع ودور معين لهم (على سبيل المثال ، وضع الملف بالتنسيق المطلوب في دليل facts.d ، والذي يعتمد موقعه على طريقة تثبيت العميل).

الآن لدينا هيكل الملف التالي:

 . ├── kicker │ ├── db.yaml │ ├── docker.yaml │ └── frontend.yaml └── kicker.yaml 1 directory, 4 files 

سنتعامل الآن مع البيئات وتعريف التهيئة الفريدة لدور على موقع معين.

البيئة وتجاوز

لنقم بإنشاء التكوين العام لجميع المبيعات. يحتوي ملف projects/kicker/tiers/prod.yaml على إشارة إلى أننا بحاجة إلى توصيل فئة بجدار حماية بهذه البيئة (حسنًا ، كل نفس الشيء) ، بالإضافة إلى فئة معينة توفر مستوى أعلى من الأمان:

 --- classes: - semrush_firewall - strict_security_level 

بالنسبة لبيئة التطوير ، إذا كنا بحاجة إلى وصف شيء محدد ، يتم إنشاء نفس الملف ويتم إدخال التكوين الضروري فيه.

بعد ذلك ، ما زلت بحاجة إلى إعادة تعريف المتغيرات لتكوين nginx لدور frontend في بيئة التطوير. للقيام بذلك ، تحتاج إلى إنشاء ملف projects/kicker/tiers/dev/frontend.yaml . انتبه إلى مستوى جديد من التسلسل الهرمي.

 --- profiles::webserver::nginx::servers: 'kicker-dev.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker-dev.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker-dev.semrush.com' proxy: 'http://kicker-backend-dev.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker-dev.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5' 

لم تعد بحاجة إلى تحديد فئة ؛ فهي موروثة من المستويات السابقة للتسلسل الهرمي. هنا قمنا بتغيير server_name proxy_pass و proxy_pass . الخادم الذي له دور الحقائق = frontend و tier = dev سيجد أولاً ملف projects/kicker/frontend.yaml لنفسه ، ولكن بعد ذلك سيتم تجاوز المتغيرات من هذا الملف بملف projects/kicker/tiers/dev/frontend.yaml بأولوية أعلى .

إخفاء كلمة المرور لـ PostgreSQL

وهكذا لدينا البند الأخير في جدول الأعمال - تعيين كلمات المرور لـ PostgreSQL.

يجب أن تختلف كلمات المرور في البيئات. سنستخدم Eyaml لتخزين كلمات المرور بشكل آمن. إنشاء كلمات المرور:

 eyaml encrypt -s 'verysecretpassword' eyaml encrypt -s 'testpassword' 

نقوم بلصق الخطوط الناتجة في الملفات **projects/kicker/tiers/prod/db.yaml** و **projects/kicker/tiers/prod/db.yaml** **projects/kicker/tiers/dev/db.yaml** (أو يمكنك استخدام امتداد eyaml ، هذا قابل للتخصيص) ، على التوالي. هنا مثال:

 --- profiles::db::postgresql::roles: 'kicker': password_hash: > 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAsdpb2P0axUJzyWr2duRKAjh0WooGYUmoQ5gw0nO9Ym5ftv6uZXv25DRMKh7vsbzrrOR5/lLesx/pAVmcs2qbhd/y0Vr1oc2ohHlZBBKtCSEYwem5VN+kTMhWPvlt93x/S9ERoBp8LrrsIvicSYZByNfpS2DXCFbogSXCfEPxTTmCOtlOnxdjidIc9Q1vfAXv7FRQanYIspr2UytScm56H/ueeAc/8RYK51/nXDMtdPOiAP5VARioUKyTDSk8FqNvdUZRqA3cl+hA+xD5PiBHn5T09pnH8HyE/39q09gE0pXRe5+mOnU/4qfqFPc/EvAgAq5mVawlCR6c/cCKln5wJTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDNKijGHBLPCth0sfwAjfl/gBAaPsfvzZQ/Umgjy1n+im0s]' 

بعد ذلك ، ستأتي كلمة مرور دور kicker ، وسيتم فك تشفيرها وتطبيقها على خادم قاعدة البيانات في PostgreSQL.

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

 . ├── db.yaml ├── docker.yaml ├── frontend.yaml └── tiers ├── dev │ ├── db.yaml │ └── frontend.yaml ├── prod │ └── db.yaml └── prod.yaml 3 directories, 7 files 

يمكنك مشاهدة هذه الملفات مباشرة عن طريق استنساخ مستودع تم إنشاؤه خصيصًا

الخلاصة

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

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

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

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

ائتمانات

شكرا:

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