☰

Saltstack ベストプラクティスドキュメントの明確化

tag-icon • tag-icon linux ubuntu deployment yaml
Saltstack ベストプラクティスドキュメントの明確化

誤解のないように言っておきますが、私はソルトスタックを使用する「最良の方法」を尋ねているのではありません。ソルトスタックを使用する方法はたくさんあることは理解していますし、あなたにとってうまくいく方法がうまくいくのです。私の質問は、特にベストプラクティスのドキュメントページについてです。ここ。

まず、私の現在の環境がどのようなものかお見せします

（これは私の環境に限ったことではありません。この質問は以前にも見たことがありますが、stackexchange.comでは見たことがなく、通常はソルトスタック IRC）

初めて saltstack のドキュメントを読んだ後、独自の環境を実装しようとしましたが、複数のプロジェクトがすべて異なるパッケージで展開されている場合、どうすれば目的を達成できるか混乱しました。これが私の最初の試みです。

デプロイする必要がある3つの異なるプロジェクトがあります。

プロジェクト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. 重複ファイル

共通のパッケージを持つプロジェクトがある場合、たとえば 3 つのプロジェクトすべてに Apache がある場合、フォルダー内に各プロジェクトの Apache ディレクトリが必要です。Apache は同じ構成ではないので、これはそれほど問題ではありませんが、saltstack で許可される組織の利点を生かせないと思います。

  1. 読みにくい

ご覧のとおり、この設定は読みにくいです。/etc/salt/master特定のプロジェクトに関連付けられたミニオンを追加するたびに、ファイル内の nodegroups で group-projectx を編集する必要があります。

Saltstackのベストプラクティス

私の質問は、上記のベストプラクティスポリシーをどのように実装するかということです。ここ、上記で指定された環境で。これを行う方法はたくさんあることは知っていますが、もっと分かりやすく、Apache がインストールされているサーバーがあるたびに新しい Apache ディレクトリを作成する必要がない方法でこれを実行したいと考えています。

どのような助けでも大歓迎です。

編集1

私が受け取った、superuser.com 経由ではないいくつかの提案は、ノードグループをすべて削除し、/etc/salt/master ファイルで使用したのと同じ形式 (L@dev-project1、qa-project1、prod-project1) を使用して、どのミニオンがどの状態に対応するかを top.sls ファイルで指定するというものでした。

また、プロジェクトごとに異なる salt-master を使用するのが良いのではないかという提案もありました。それは理にかなっていますし、その答えは気に入っていますが、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 で重複するデータは、同じピラー キーを持ちながら、必要に応じて環境を構成するための異なる値を持つデータのみになります。次に、Apache の状態が 1 つあるとします。その状態にある環境固有のものはすべて、ピラーの値を使用してレンダリングされます。

ピラーには、たとえば次のような内容を含めることができます。

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

関連情報