ملح. قل كلمة عن العمود المجيد

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

هناك حاجة إلى أعمدة مختلفة

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



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



على سبيل المثال ، يمكنك أخذ بيانات من mysql أو postgres أو redis أو mongo أو git أو حتى من إخراج البرنامج النصي / الأمر - cmd_json ، cmd_yaml .



يتم نشر قائمة كاملة بالوحدات على موقع SaltStack الرسمي .



إذا كان لديك موقف غير قياسي والوحدات النمطية المتاحة لا تناسبك ، يمكنك كتابة الوضع الخاص بك ووضعه في / usr / lib / python3 / dist -pack / salt / pillar / ، وبعد ذلك تحتاج إلى إعادة تشغيل المعالج.



مثال على هذه الوحدة:

#/etc/salt/master/conf.d/pillar.conf
ext_pillar:
  - dummy: dummy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

#/usr/lib/python3/dist-packages/salt/pillar/dummy.py
def ext_pillar(minion_id, pillar, *args, **kwargs):
    dummy = {'dummy': 'what u want mann?'}
    return dummy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

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

مقدمة إلى PillarStack

Stack أو pillarstack هو "عمود YAML بسيط ومرن يمكنه قراءة الأعمدة من الأعمدة" ، وفقًا للوثائق الرسمية على الموقع .



يسمح لك باستخدام الأعمدة التي تمت قراءتها مسبقًا داخل الأعمدة. هذا يعني أنه يمكننا استخدام العمود من التكوين السابق. وهي مريحة للغاية! دعنا نوضح كيف يعمل:

,      :
#/etc/salt/conf.d/pillarstack.conf
ext_pillar:
  - stack:
    - /srv/pillar/stack1.cfg
    - /srv/pillar/stack2.cfg
    - /srv/pillar/stack3.cfg

#/srv/pillar/stack1.cfg
#    stack  "" ,
#    2      yml ,    

core.yml
common/*.yml
osarchs/{{ __grains__['osarch'] }}.yml
oscodenames/{{ __grains__['oscodename'] }}.yml
hosts/{{ minion_id }}/roles.yml

#/srv/pillar/stack2.cfg
#   stack      stack1.cfg
#      , , roles
#  stack   yml 

{% for role in stack.roles %}
roles/{{ role }}/*.yml
{% endfor %}

#/srv/pillar/stack3.cfg
#    stack ""   stack1.cfg  stack2.cfg
#       
creds/{{ stack.db.host }}/*.yml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

يمكن تمثيل كل تكوين كطبقة. في كل طبقة ، يمكننا استخدام البيانات من الطبقات السابقة.



تتوفر المتغيرات التالية عند تكوين الأعمدة:

• الحبوب - استهداف التكوينات بالحبوب
• opts - استهداف التكوينات حسب الخيارات في config
• الدعامة - الأعمدة التي تم تشكيلها قبل معالجة ext_pillar: المكدس الحالي

# ,      stack

#      stack      grains   pillar
# stack.cfg   ,    pillar 
ext_pillar:
  - stack:
      grains:cpuarch:
        x86_64:
          - /srv/pillar/stack1.cfg
          - /srv/pillar/stack2.cfg
      pillar:environment:
        dev: /srv/pillar/dev/stack.cfg
        prod: /srv/pillar/prod/stack.cfg


#       stack:     grains,   pillar
#   pillar     stack1.cfg, stack2.cfg
#      'environment',  stack.cfg  
ext_pillar:
  - stack:
      grains:custom:grain:
        value:
          - /srv/pillar/stack1.cfg
          - /srv/pillar/stack2.cfg
  - stack:
      pillar:environment:
        dev: /srv/pillar/dev/stack.cfg
        prod: /srv/pillar/prod/stack.cfg
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

في ملفات yml ، يمكنك استخدام:

• __opts__: خيارات التكوين
• __grains__: حبوب العميل
• الدعامة: أعمدة من ركائز ext_pillar أو ركائز افتراضية أخرى (تلك الموجودة في top.sls)
• كومة: كومة أعمدة متراكمة ، بما في ذلك التكوين الحالي.

إذا كنت ستنتقل فقط إلى pillarstack ، فإليك بضع نقاط تستحق الاهتمام بها:



1. يعمل التضمين المتكرر في الدعامة فقط. لا يتضمن المكدس أدلة ، بل يتضمن ملفات فقط.

# pillar
# top.sls
base:
  '*':
    - dir1.* #  /dir1/dir2/dir3/*

# stack    
# stack.cfg
/dir1/*
/dir1/dir2/*
/dir1/dir2/dir3/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

2. السلوك الافتراضي عند دمج القوائم:

• عمود - يتم الكتابة فوق القوائم
• المكدس - يتم استخدام استراتيجية الدمج الأخير (يتم إضافة القوائم).

تسمح استراتيجيات دمج الأعمدة بالتخصيص المرن للغاية للأعمدة.

يوجد وصف مفصل مع أمثلة في الوثائق.



لوصف كل من الاستراتيجيات بإيجاز:

• merge-last (افتراضي): دمج متكرر ، والقاموس / القائمة الأخيرة لها الأسبقية
• الدمج أولاً: الدمج العودي ، تعطى الأولوية للقاموس / القائمة الأولى
• إزالة: إزالة العناصر المحددة
• الكتابة فوق: تجاوز القاموس / القائمة.

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



الاستراتيجية على أنها العنصر الأول في القاموس / القائمة التي يجب تطبيقها عليها.

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

خاتمة

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



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