Sal. Diga uma palavra sobre o pilar glorioso

Em um de nossos artigos anteriores sobre Just add some Salt, falamos sobre como migramos mais de 700 servidores para o Salt. Compartilhamos nossa experiência com a otimização do Salt: como aplicá-lo e personalizá-lo sem esforço. Em seguida, apenas tocamos no tópico dos pilares, mas hoje gostaríamos de abordá-lo com mais detalhes.



Diferentes pilares são necessários



Os pilares são um armazenamento de dados seguro (seguro) dentro do Salt. Portanto, em primeiro lugar, eles são usados ​​para delimitar o acesso a dados críticos (certificados, logins, senhas).



Além dos pilares padrão, o Salt também tem o módulo ext_pillar , que fornece uma interface para conexão com fontes de dados externas e gera pilares dessas fontes em um dicionário comum.



Por exemplo, você pode obter dados de mysql, postgres, redis, mongo, git ou mesmo da saída de um script / comando - cmd_json , cmd_yaml .



Uma lista completa de módulos está publicada no site oficial do SaltStack .



Se você tiver uma situação fora do padrão e os módulos disponíveis não forem adequados para você, você pode escrever o seu próprio e colocá-lo em / usr / lib / python3 / dist-packages / salt / pillar /, após o qual você precisa reiniciar o assistente.



Um exemplo de tal módulo:



#/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
      
      







De todos os módulos disponíveis, o pillarstack acabou por ser o mais interessante e relevante para a nossa equipa. Agora vamos dizer por quê.



Introdução ao PillarStack



Stack ou pillarstack é "um pilar YAML simples e flexível que pode ler pilares de pilares", de acordo com a documentação oficial no site .



Ele permite que você use os pilares lidos anteriormente dentro dos pilares. Isso significa que podemos usar o pilar da configuração anterior. E é mega-conveniente! Vamos mostrar como funciona:



,      :
#/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
      
      







Cada configuração pode ser representada como uma camada. Em cada uma dessas camadas, podemos usar dados das camadas anteriores.



As seguintes variáveis ​​estão disponíveis ao configurar os pilares:



  • grãos - segmentação configs por grãos
  • opts - segmentação de configurações por opções na configuração
  • pilar - pilares que foram formados antes de processar o ext_pillar atual : pilha




# ,      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
      
      







Em arquivos yml, você pode usar:



  • __opts__: opções de configuração
  • __grains__: grãos de minion
  • pilar: pilares de outro ext_pillar ou pilares padrão (aqueles em top.sls)
  • pilha: pilha de pilares acumulada, incluindo a configuração atual.




Se você vai apenas mudar para o pilar, a seguir estão alguns pontos que merecem atenção:



1. A inclusão recursiva funciona apenas no pilar. A pilha não inclui diretórios, apenas arquivos.



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

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







2. Comportamento padrão ao mesclar listas:



  • pilar - listas são substituídas
  • pilha - a estratégia mesclar-última é usada (as listas são adicionadas).




As estratégias de fusão de pilares permitem uma personalização muito flexível dos pilares.

Uma descrição detalhada com exemplos está na documentação.



Para resumir cada estratégia:



  • merge-last (padrão): mesclagem recursiva, último dicionário / lista tem precedência
  • mesclar primeiro: mesclagem recursiva, a prioridade é dada ao primeiro dicionário / lista
  • remove: remove os elementos especificados
  • sobrescrever: substituição de dicionário / lista.




Explicação: em cada fusão estão envolvidos dois dicionários / listas, vamos chamá-los de primeiro e último. A



estratégia é indicada como o primeiro elemento do dicionário / lista ao qual deve ser aplicada.

O principal é não se deixar levar pelo uso excessivo de estratégias, pois isso vai complicar a configuração. Talvez, neste caso, valha a pena reconsiderar a organização dos pilares.



Conclusão



Os pilares permitem que você restrinja o acesso a dados confidenciais. Conforme os dados crescem, os cenários para seu uso se tornam mais sofisticados, por isso é importante usar uma ferramenta conveniente para organizá-los. No momento, para nossa equipe, este é o pilar, no futuro planejamos implantar o vault.



Parece-nos surpreendente porque o pilar ainda não suplantou o pilar padrão, porque é muito mais conveniente e flexível, e as estratégias são muito úteis quando é necessário mudar o comportamento da variável da pilha pontualmente. O que você acha? Você usa a pilha de pilares em seu trabalho?



All Articles