7日間学会SALTACK自動化運営(3)

7865 ワード
saltstack
7日間学会SALTACK自動化運営(3)
  • 導読み
  • SLS
  • TOP.SLS
  • ミニセレクタ
  • SLSファイルのコンパイル
  • 総括
  • 参照リンク
    • 読み解く
    SLS
    SLS(aka SaLt State file)は、salkstackにおける非常に基礎的かつ重要な構成ファイルであり、重要度はminionとmasterに次ぐ主な構成ファイル(またはデータ構造の一つであり、yamlを用いて作成)であり、SLSプロファイルは、私たちが定義した命令の実行経路を決定しています.ターゲットが完了したらコマンドの実行を開始します.またはコマンドのセットを実行します.または設定ファイルの同期を行います.どのターゲットを確定しますか?どのコマンドを実行しますか?または操作しますか?対応する環境を探すのはsmsファイルの機能の一つです.また、第一歩学習会のSLSに関する知識もあります.環境構成については、ほとんどはtop.smsに書いています.各環境には独自のtop.slasがあり、多環境構成に便利であり、他のslasは、プロファイルの同期やコマンド実行などの動作を制御するために多く使われる.
    TOP.SLS
    私のfile_roots
    /etc/master
file_roots:
  base:
    - /srv/salt/base
  dev:
    - /srv/salt/dev
  test:
    - /srv/salt/test
    私のtop.sl
    /srv/salt/base/top.sls
base:
  '*':
    - salt.minion
    - base

/srv/salt/dev/top.sls
dev:
  'dev*':
    - development_config
    - dev_db

/srv/salt/test/top/sls
test:
  'env:test':
    - match: grain
    - test_config
    - test_db
    私の配置ファイルには3つの環境があります.環境によっては異なる環境設定ディレクトリに対応しています.rootsに配置されています.つまり、各minionはbaseのプロファイルを読み取り、devはdevの環境を読み取り、testはtestの環境を読み取り、settings.py、nginx.com f、my.cnfなどを同じディレクトリに置くことを避けることができます.
    今私の/srv/salt/base/の中でただいくつかの共通の配置だけを放して、state.highstateを実行する時base.slasの中のすべての操作を実行して私のminionの上に行って、次に私のbase.slasを参照します.
    minion_config:
  file.managed:
    - name: /etc/base/minion.config
    - source: salt://minion.config

apache:
  pkg.installed:
    - watch:
      - file: minion_config
    非常に簡単で、かつsaltstack自動処理が非常によく、minionにファイルを保存すべき位置を教えてくれればいいです.sourceは全く配置しなくてもいいです.salt自身は現在のminion対応のどの環境ディレクトリを知っていますか?自動的にminion.co figファイルを探して、自分の/etc/base/minion.co figの下に同期します.ただし、一つ注意したいのは、カタログが存在しないと同期して失敗するので、あらかじめカタログが存在するかどうかを確認しておくことです.
    MINIONセレクタ
    公式文書のtop.slasについての一節には、完璧な使い方がありますが、自分の理解を書くなら、一番簡単でよく使われるものを書いてください.
    実はこれをjqueryのセレクタとして使えばいいのです.jqueryのセレクタの出現はdomノードが非常に多いので、自分がコントロールしたいノードを一つの方法で選びます.saltstackのセレクタも同じ理由で設計されています.それは別のminionノードの選択です.あなたが夢まぼろしの西旅行のサーバーを管理するかもしれないため、夢まぼろしの西旅行のサーバーは少なく何千台もあると言ってもいいでしょう、saltstackがあって選びやすいです.
    Saltstackのセレクタは文書によって大きく2つに分けられています.一つはCompund Matchに基づいているものとNode groupsに基づいているものです.実は筆者の立場から見れば、前者だけです.後者は前者が提供する方法によって、グループを分けただけです.異なる機能のminionを異なるグループに分けています.これは長い正則で毎回idやgrainsに合わせなくてもいいです.
    compund:
    Letter    Match Type        Example
G         Grains glob       G@os:Ubuntu
E         PCRE Minion ID 	E@web\d+\.(dev|qa|prod)\.loc
P         Grains PCRE       P@os:(RedHat|Fedora|CentOS)
L         List of minions   [email protected],minion3.domain.com or bl*.domain.com
I         Pillar glob       I@pdata:foobar
S         Subnet/IP address [email protected]/24 or [email protected]
R         Range cluster     R@%foo.bar
    上の表は公式文書から出ていますが、初めての使用経験があり、inxの配置ファイルのように柔軟です.
    sudo salt-C
    <!--
    h='&ハx 65;ヽoo.ツ110;ヽoo.ツ118;';a='&ハ64;n='&菗x 27;ヽoo.ツx 47;e=n+a+h
    document.write('<a h'+'ref'="="ma'+ilto'':'+e+'''''''''t');'''＋e+''''
    //-->
    'G at env
    :dev and
    <!--
    h='&ハx 63;ヽoo.ツ112;ヽoo.ツx 75;ヽoo.ツx 5 f;ヽoo.ツ110;ヽoo.ツx 75;ヽoo.ツx 6 d;ヽoo.ツx 73;';a='&ハ64;n='&菗x 47;e=n+a+h
    document.write('<a h'+'ref'="="ma'+ilto'':'+e+'''''''''t');'''＋e+''''
    //-->
    G at.cpunums
    :8 and
    <!--
    h='&ハ116;ヽoo.ツx 6 f;ヽoo.ツx 6 b;ヽoo.ツx 79;ヽoo.ツx 6 f;a='&ハ64;n='&菗x 45;e=n+a+h
    document.write('<a h'+'ref'="="ma'+ilto'':'+e+'''''''''t');'''＋e+''''
    //-->
    E at tokyo
    ＊and
    <!--
    h='&ハx 6 f;ヽoo.ツx 73;';a='&ハ64;n='&菗80;e=n+a+h
    document.write('<a h'+'ref'="="ma'+ilto'':'+e+'''''''''t');'''＋e+''''
    //-->
    P at os
    :(CentOS)'
    上の複雑な表現は長いですが、一目で分かります.
    Node groups:
    このパケットはマスターのプロファイルに配置されています.具体的な書き方はここですを参照してください.簡単な配置で使用できます.注意すべき点は多くありません.
    SLSファイルのコンパイル
    この結果も公式文書を読んだ後に得られたもので、ここではジンja 2テンプレートエンジンを使ってslasファイルをコンパイルする方法を説明するのではなく、slasファイルの定義順序が環境変数に与える影響を説明するために、前の構成ですでに見られました.各環境のディレクトリにtop.slasファイルを配置して自分の構成を定義することができます.そして、各環境のtop.slasは自分の構成だけを定義しています.つまりbase/top.slasはbaseだけを配置しています.他の配置はありません.baseディレクトリの下にtop.slasがない場合(またはbaseがないsection)、他のbaseが含まれているtop.slasをアルファベット順に検索します.これはフォールトポリシーです.配置の柔軟性を強化する方法でもあります.この例は文書を見ることができます.ここでは自分の理解だけを話して、できるだけ避けます.
    base/top.slasファイルは特殊です.一般的にはbaseの目標はすべてのminionです.そしてbase/top.slasにも他の環境のsectionを配置することができます.ここで一つの点があります.base/top.slasでdevのsectionを見つけたら、この環境はbase/top.ssのdevの配置を使います.dev/top.slasの中に自分の配置があるかどうかに関わらず、代わりにbase.slasは第一時間で解析的にコンパイルされたので、コードを読んで検証することができますが、これは使えるようになりました.
    base/top.slas以外の環境のtop.slasについても、ベース/top.slasと同じ策略に従って、自分のtop.slasは自分のコレクションが存在しないので、アルファベット順に自分のコレクションを含むtop.slasを探して、見つけたらこのアクションを自分の環境として使う.
    最後にISSUEについて、ISSUEはまだ閉鎖されていません.このバグはまだ存在していることを示していますが、ここでは安全方法と言いますが、安全方法も安全前提があります.
    作者の意味は、彼のbase、qa、dev、master環境、それぞれの環境に自分のtop.slasがあります.そしてこのtop.slasは同じファイルですが、このtop.slasの内容は同じではないです.なぜですか?top.slasはgitの異なるバージョンなので、同じファイルですが、内容が違っています.重複した配置が含まれていますので、最後の配置は前の配置を覆っています.最後の一つはqaです.実は作者はいくつかのあいまいな話があります.各top.slasは自分の仕事だけをして、他のセレクションを含めないでください.
    もし著者がなぜ違うバージョンのtop.slasを使って異なるディレクトリに置いたのかを知っているなら、
    <!--
    h='&ハx 67;ヽoo.ツx 6 d;ヽoo.ツx 61;ヽoo.ツx 69;ヽoo.ツ108;ヽoo.ツ46;ヽoo.ツx 63;ヽoo.ツx 6 f;ヽoo.ツx 6 d;';a='&ハ64;n='&菗x 79;ヽoo.ツx 6 f;ヽoo.ツx 75;ヽoo.ツ110;ヽoo.ツx 67;ヽoo.ツx 65;ヽoo.ツ114;ヽoo.ツ46;ヽoo.ツ120;ヽoo.ツ46;ヽoo.ツx 73;ヽoo.ツ104;ヽoo.ツx 65;ヽoo.ツ110;e=n+a+h
    document.write('<a h'+'ref'="="ma'+ilto'':''+e+''''gt;''''に連絡してください.
    //-->
    私に連絡してください.
    締め括りをつける
    完全に自分の理解に基づいて、基本的にSLSに対して説明しました.次のステップはデバッグに行きます.あるいは実践によって研究します.しかし、他の人が私の意味を完全に理解できるとは限らないと思います.痛い点はほとんど見つけました.以下は実践を見て、saltstackに基づくキャリブレーションコンポーネントを開発するかもしれません.結局はapiを提供しました.
    参照リンク
    ISSUE
    http://salt.readthedocs.org/en/latest/topics/tutorials/starting_states.
    http://salt.readthedocs.org/en/latest/ref/states/top.html#other-ways-off-targting-minions
    https://github.com/saltstack/salt/issues/12483#issuecomment-64181598
    NETシーケンサ