Para ser claro, não estou pedindo a “melhor maneira” de usar o saltstack. Eu entendo que existem várias maneiras de usar o saltstack, e o que funciona para você, funciona. Minha pergunta é especificamente sobre a página de documentação de práticas recomendadas encontradaaqui.
Primeiro vou mostrar como é meu ambiente atual
(Isso não é específico do meu ambiente. Já vi essa pergunta antes, mas nunca no stackexchange.com, normalmente nopilha de sal irc)
Depois de ler a documentação do saltstack pela primeira vez, tentei implementar meu próprio ambiente, mas fiquei confuso sobre como realizar o que queria com vários projetos sendo todos implantados com pacotes diferentes. Aqui está a aparência da minha primeira tentativa.
Tenho três projetos diferentes que precisam ser implantados, chamados
Projeto 1,projeto2, eprojeto3.
/etc/salt/master
file_roots:
base:
- /srv/salt
project1:
- /srv/salt/project1
project2:
- /srv/salt/project2
project3:
- /srv/salt/project3
#I have three projects that I need to deploy to, and each has a dev, qa, and prod machine.
nodegroups:
group-project1: 'L@dev-project1,qa-project1,prod-project1'
group-project2: 'L@dev-project2,qa-project2,prod-project2'
group-project3: 'L@dev-project3,qa-project3,prod-project3'
/srv/salt/top.sls
project1:
'group-project1':
- match: nodegroup
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
project2:
'group-project2':
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
project3:
'group-project3':
- match: nodegroup
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
Estrutura de arquivos dentro de /srv/salt
conteúdo de /srv/salt
/srv/salt/project1, project2, project3, top.sls
conteúdo de /srv/salt/project1
/srv/salt/project1/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
conteúdo de /srv/salt/project2
/srv/salt/project2/snort, pulledpork, barnyard, snorby, apache, mysql
conteúdo de /srv/salt/project3
/srv/salt/project3/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
O que eu não gosto nesta configuração
- arquivos duplicados
Se eu tiver projetos que possuem pacotes em comum, por exemplo, todos os três projetos possuem apache, então devo ter um diretório apache para cada projeto dentro de sua pasta. Isso não é terrível, já que o Apache não está configurado da mesma forma, mas não acho que estou aproveitando a organização que o saltstack permite.
- não é facilmente legível
Como você pode ver, essa configuração é meio difícil de ler. Tenho que editar meu group-projectx nos grupos de nós do /etc/salt/masterarquivo toda vez que desejo adicionar um minion associado a um projeto específico.
Melhores práticas do Saltstack
Minha pergunta é: como eu implementaria as políticas de melhores práticas mencionadasaqui, em um ambiente especificado acima. Eu sei que há muitas maneiras de fazer isso, mas eu realmente quero fazer isso de uma maneira que seja mais fácil de entender e que não envolva a criação de um novo diretório apache toda vez que tiver um servidor com apache nele.
Qualquer ajuda é apreciada.
EDITAR 1
Algumas sugestões que recebi, que não foram feitas por meio de superuser.com, foram para me livrar de todos os grupos de nós e apenas especificar no arquivo top.sls quais minions vão com qual estado, usando o mesmo formato que usei em o arquivo /etc/salt/master (L@dev-project1,qa-project1,prod-project1).
Além disso, foi-me sugerido que talvez eu devesse usar um salt-master diferente para cada projeto. Isso faz sentido, e gosto dessa resposta, mas acho que para pessoas que não têm muito espaço para VMs ou máquinas físicas, pode ser difícil.
Responder1
Estou lidando com diferentes configurações de aplicativos por tipo de servidor diretamente no arquivo superior.
# per server hostname : ie.
base:
'websrv*':
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
'monsrv*':
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
Se a nomenclatura de seus minions não permitir classificá-los com base em regex, você poderá fazer o mesmo com grãos.
# per server grains : ie.
base:
'G@role:websrv': # or even a custom grain like 'G@project:1'
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
'G@role:monitoring': # or even a custom grain like 'G@project:1'
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
Em seguida, faço a mesma coisa com os dados dos meus pilares, permitindo-me atribuir pilares diferentes a alguns hosts, de modo que esses sejam os únicos dados duplicados que tenho no Salt, com as mesmas chaves dos pilares, mas valores diferentes para configurar meu ambiente conforme necessário. Eu tenho então, digamos, um estado do Apache e qualquer coisa que seja específica do ambiente nele é renderizada com o valor no meu pilar.
No seu pilar, você poderia ter por exemplo:
/top.sls
/apache /
| init.sls
| project1.sls
| project2.sls
| project3.sls