☰

Saltstack 모범 사례 문서 설명

tag-icon • tag-icon linux ubuntu deployment yaml
Saltstack 모범 사례 문서 설명

분명히 말하면, 나는 솔트스택을 사용하는 "최선의 방법"을 요구하는 것이 아닙니다. 나는 솔트스택을 사용하는 방법이 무수히 많다는 것과 자신에게 맞는 방법이 효과가 있다는 것을 알고 있습니다. 내 질문은 특히 발견된 모범 사례 문서 페이지에 관한 것입니다.여기.

먼저 현재 환경이 어떤지 보여드리겠습니다.

(이것은 내 환경에만 국한된 것이 아닙니다. 이전에 이 질문을 본 적이 있지만 stackexchange.com에서는 본 적이 없습니다. 일반적으로소금 더미 irc)

처음으로 saltstack 문서를 읽은 후 나만의 환경을 구현하려고 시도했지만 여러 프로젝트가 서로 다른 패키지로 배포되면서 원하는 것을 어떻게 달성해야 할지 혼란스러웠습니다. 첫 번째 시도는 다음과 같습니다.

배포해야 하는 세 가지 다른 프로젝트가 있습니다.

프로젝트1,프로젝트2, 그리고프로젝트3.

/etc/salt/마스터

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

/srv/salt 내부의 파일 구조

/srv/salt의 내용

/srv/salt/project1, project2, project3, top.sls

/srv/salt/project1의 내용

/srv/salt/project1/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache

/srv/salt/project2의 내용

/srv/salt/project2/snort, pulledpork, barnyard, snorby, apache, mysql

/srv/salt/project3의 내용

/srv/salt/project3/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache

이 설정에서 마음에 들지 않는 점

  1. 중복 파일

공통 패키지가 있는 프로젝트가 있는 경우(예를 들어 세 프로젝트 모두 Apache가 있는 경우 해당 폴더 내부에 각 프로젝트에 대한 Apache 디렉터리가 있어야 합니다.) 아파치가 동일하게 구성되지 않았기 때문에 나쁘지는 않지만 saltstack이 허용하는 조직을 활용하고 있다고 생각하지 않습니다.

  1. 쉽게 읽을 수 없음

보시다시피 이 설정은 읽기가 좀 어렵습니다. /etc/salt/master특정 프로젝트와 관련된 미니언을 추가하고 싶을 때마다 파일 의 노드 그룹에서 내 group-projectx를 편집해야 합니다 .

솔트스택 모범 사례

내 질문은 언급된 모범 사례 정책을 어떻게 구현하는가입니다.여기, 위에 지정된 환경에서. 이를 수행할 수 있는 방법이 많이 있다는 것을 알고 있지만 이해하기 쉽고 Apache가 있는 서버가 있을 때마다 새로운 Apache 디렉토리를 만들지 않아도 되는 방식으로 이 작업을 수행하고 싶습니다.

도움을 주시면 감사하겠습니다.

편집 1

내가 받은 몇 가지 제안은 superuser.com을 통하지 않고 노드 그룹을 모두 제거하고 내가 사용한 것과 동일한 형식을 사용하여 어떤 미니언이 어떤 상태로 이동하는지 top.sls 파일에 지정하는 것이었습니다. /etc/salt/master 파일(L@dev-project1,qa-project1,prod-project1)

또한 각 프로젝트마다 다른 솔트 마스터를 사용해야 한다는 제안도 있었습니다. 일리가 있고 그 답변이 마음에 들지만 VM이나 물리적 시스템을 위한 공간이 많지 않은 사람들에게는 어려울 수 있다고 생각합니다.

답변1

최상위 파일에서 직접 서버 유형별로 다양한 앱 구성을 다루고 있습니다.

# per server hostname : ie. 

base:
  'websrv*':
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
  'monsrv*':
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql

미니언 이름 지정으로 인해 정규 표현식을 기반으로 분류할 수 없는 경우 그레인으로도 동일한 작업을 수행할 수 있습니다.

# 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

그런 다음 기둥 데이터에 대해 동일한 작업을 수행하여 일부 호스트에 다른 기둥을 할당할 수 있으므로 이것이 Salt에 있는 유일한 중복 데이터입니다. 기둥 키는 동일하지만 값이 달라 필요에 따라 환경을 구성합니다. 그런 다음 하나의 아파치 상태와 그 안의 특정 환경에 관련된 모든 것이 내 기둥의 값으로 렌더링된다고 가정하겠습니다.

기둥에는 다음과 같은 내용이 포함될 수 있습니다.

/top.sls
/apache /
        | init.sls
        | project1.sls
        | project2.sls
        | project3.sls

관련 정보