免責事項

先月、私は3つの製品すべてについて開発者とのインタビューを聞き、「 [Ansible / Salt / StackStorm]接着剤を検討してください」という声明を聞きました。 そして今、私はアマチュアの自家製アマチュアとして、私のガレージには接着剤の唯一の鍋は決してないことを喜んでいます。 用途、接着剤、環境条件に応じて、6種類の接着剤があります。 これら3つの製品はすべて同じ陣営にあり、それぞれを使用して完全に異なる目標を達成できます。 最近、機能が大きく重複しており、それらはすべてネットワーク自動化の分野に浸透しているという事実から成り立っています。 以下の意見は、雇用主（数十億ドル相当のネットワークインフラストラクチャと展開製品を販売している）ではなく、 私に属します。

私は 3つの製品すべてを使用し、そのうちの2つ（SaltとStackStorm）の開発で、Ansibleの開発に大きく貢献し、部分的に貢献しました。 率直に言って、私が最もなじみのない製品はAnsibleですが、同僚と話し、情報を収集して空白を埋めました。

---

テキストをスクロールして、勝者として発表した製品を見つけようとすると、失望するでしょう。 要件について考え、複数の製品を試してください。

---

大人の監督下で使用する

いくつか質問をしてください：

• どの環境をサポートする必要がありますか？ サーバーとネットワークデバイスのセットは何ですか？
• ユーザーは誰ですか？ 筋金入りのシステム管理者、情報セキュリティの専門家、開発者？
• ユーザー開発にいくら費やしますか？

エージェントの有無にかかわらず？

それに注意してください、これは本当に重要です。 この記事では、デバイスの自動化とそのオーケストレーションの問題に焦点を当てます。 これらのデバイスは、ルーター、スイッチ、ファイアウォールであり、次世代のサーキュレーターの電磁波を放出しますが、それは重要ではありません。 本当に重要なこと-エージェントはオペレーティングシステムにインストールされません。 Ansibleには互換性のあるソリューションがありました-SSHをトランスポートとして使用するため、SSHが最も一般的な分母ではないエンドポイント構成の世界にうまく適合します。 SaltStackは、通信を制御する高速で安全なミニオン（エージェント）用のバスとして作成されましたが、エージェントを使用しないモードも備えています。 StackStormは最後に競技場に参入しましたが、そのアーキテクチャにより、どの作品も優先されません。 Chef、Puppet、Saltのパッケージと、独自のSSHベースのリモートコントロールツール、およびスクリプトのコレクションを呼び出すための組み込みサポート-Ansible Playbookを通じて、エージェントベースのツールをサポートします。

API

もう1つの重要な違いはAPIです。

• AnsibleはCLIインターフェースを提供し、Ansible Tower（エンタープライズ版）はAPIを備えています。
• StackStormにはCLIがありますが、無料版のすべてのコンポーネントとサービス用のREST APIもあります。
• SaltにはCLIとREST APIの両方があり（デフォルトでは有効になっていません）、RBACなどの機能を含むエンタープライズ製品の一部として「Enterprise API」を使用することもできます。

アンシブル

アンシブル-マイケル・デハーンの発案。 この製品は、大規模な環境でのサーバー管理の統一タスクを自動化するために開発されました。 マイケルは新しく設立されたRedHatテクノロジーグループに所属し、さまざまなプロジェクト（ Cobblerなど）を設立し、RedHatを離れた後、Ansibleを設立しました（現在AnsibleはRedHatが所有しています）。 プロジェクトの目的を説明するマイケルのAnsible Essentialsブログからの抜粋 ：

「私たちは、Red Hatの新しいオープンソースの問題を解決するために、非常に民主的なプロジェクトをもう1つ作成したかったのです。 busrpcについて思い出しました。 このプロジェクトは、コブラーとパペットの間のギャップを埋めるために存在しました。 Cobblerはシステムを準備でき、Puppetは構成ファイルを追加できます。 ただし、Puppetは記述的すぎるため、サーバーの再起動や、「オンデマンド」でのすべてのタスクの完了などの操作の実行には使用できません 。

これらのオンデマンドタスクはAnsibleプレイブックに進化し、その後Ansibleモジュールエコシステムが出現し、開発を開始しました。

設計

Ansibleはシンプルで、これが主な品質です（他の2つの品質を見るとすぐに明らかになります）。 デーモンやデータベースは含まれておらず、インストール要件は最小限です。 AnsibleはLinuxマシンにインストールするだけです。 ターゲットサーバーを静的ファイルで定義し、意味のあるセクションにグループ化するか、動的ホスト検出モジュール（Amazon EC2やOpenStackなど）を使用して、API呼び出しに基づいて仮想マシンを検索できます。 インベントリが実行された後、プレイブックで使用するホスト固有またはグループ固有の変数を選択できます。 再び、それらは静的テキストファイルに格納されます。

次に、Ansibleは選択したホストまたはグループに接続し、プレイブックを開始します。 スクリプトブック（プレイブック）は、YAMLで記述されたリモートホストで実行するための一連のAnsibleモジュールです。

リモートホストへの接続は、 よく計画された軍事演習のようなものです。ログインして、仕事をして、ログアウトします。

Ansibleは、SSH（またはWS-Man / WinRM for Windows）を介してサーバーに接続し、Pythonコードをコピーし、自身を実行および削除するアルゴリズムに従って動作します。

建築

Ansibleのアーキテクチャは簡単です。ローカルコンピューターで実行されるアプリケーションと、リモートホストで実行されるタスクがあり、SSHとSCP / SFTP経由で転送されるファイルを介して相互に通信します。 Ansibleは、他の2つの製品とは異なり、サーバーとクライアントのアーキテクチャを持たないため、ローカルマシンでタスクの並列化が行われますが、複数のサーバーに拡張しません（Towerを使用しない場合）。

リモートマシンを管理する場合、Ansibleは独自のコードを残さないため、新しいバージョンに切り替えるときにAnsibleを更新する方法についての質問は、実際には価値がありません。

拡張性

実際 、Ansibleのモジュールは、他の2つの製品と同様、開発が非常に簡単です。 後でリファクタリングするのではなく、ソリューションをオープンソース製品リポジトリに踏み込むことにした場合は、スタイルガイドをお読みください。

#!/usr/bin/python import datetime import json date = str(datetime.datetime.now()) print json.dumps({ "time" : date })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 ansible/hacking/test-module -m ./timetest.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなものが表示されるはずです。

 {"time": "2012-03-14 22:13:48.539183"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モジュールでは、「 コレクション 」段階でリモートホストに関する「 ファクト 」を生成するための独自のコードを定義できます。これは、独自またはサードパーティのモジュールで使用できます。 これは、インストールされたファイルと構成の両方を表示して、サービスの構成方法を決定する形式で実装できます。

コーポレートサポート

Ansible Towerは、AnsibleコマンドラインをWebインターフェイス、スケジューラ、および通知システムを備えたサービスに変換するエンタープライズバージョンです。



タスクスケジューラ

また、プレイブック用のユーザーインターフェイスもあります。これにより、クラウドインフラストラクチャの展開を自動化し、リストに仮想マシンを自動的に追加できます。

タスクスケジューラ、クラウド展開、およびサーバーが、SaltとStackStormの両方の無料バージョンの機能であることは注目に値します。

ネットワークサポート

Ansible Network Supportセクションは、3つの製品すべての中で最も包括的なものであり、すべての主要なネットワーク機器およびプラットフォームベンダーを対象としています。 Ansibleでは次のことが可能です。

• 特定のネットワークプラットフォーム用のモジュールとプレイブックを使用して、接続するシステムの指定から基本サービスの構成まで、ネットワーク機器に関連するすべての構成を自動化します。
• ネットワークの現在の状態をテストおよび検証するか、既存の構成に関する事実調査プロセスを実行または延期します。
• ネットワーク設定の変更を継続的に確認します。

Ansibleは、Arista、Cisco（すべてのプログラム可能なプラットフォーム）、F5、Juniper、およびその他のメーカーをサポートしています。 Ansible単独では、サポートは主にコミュニティではなくベンダーによって提供および提供されます。 現時点では、これらは最高のAPI、最高の機能であり、最新のプラットフォームで動作します（新しいバージョンがサポートされているため）。

強み

• すぐに始められます。
• コミュニティからの多くの例、ドキュメント、およびモジュール。
• Ansible Towerは、大規模なエンタープライズ展開向けの機能を実装しています。
• ベンダーがサポートするネットワークモジュール。

弱点

• 適切な制御がない場合、オペレーターはプレイブックとSSHキーをラップトップに保存できます。 Ansibleの完全な欠陥ではありませんが、継続的な監視が必要です。
• 自動化イベントの履歴はありません。ターゲットホストの制御は、プレイブックの実行中のみ維持され、それ以上はありません。 長期的なタスクには使用できません。

Stackstorm

バージョンv0.11（初期のベータプレビュー）から最新バージョンv2.2までStackStormを使用しました。 これは、Saltのような洗練された広範なアプリケーションプラットフォームです。 それについての話は時間がかかりますが、それでも多くの場合、リスナーはシステムの間違った印象を作成します。 私はこれを長所と短所の両方と考えています。 システムの複雑さにより、デプロイメントを完全に放棄したり、StackStormが適切な代替手段となる単純で誤ったソリューションを使用したりすることがあるため（多くの場合、独自のソリューションをゼロから作成することもあります）。 強みは、強みの使用方法が明確になるとすぐに、システムが本当に柔軟になることです。





StackStormインターフェース

設計

StackStormのコアは、深くカスタマイズ可能なIFTTTサービスとして設計されたプラグインルールを備えた実行可能エンジンです（if-this-then-that、“ if this、then that”）。 StackStormは、単純な「アクション」（コマンド）または複雑なワークフローをトリガーすることにより、イベントに応答するように設定できます。 ワークフローには2つのバージョンがあります。ActionChain-アクションのチェーン（独自のDSLワークフロー）として、またはOpenStack Mistralのワークフロー（YAMLに基づくエンジン）です。

StackStormには、「chatops」のサービスも含まれています。このサービスを使用して、イベントからワークフローを開始したり、チャットプラットフォーム（Slackなど）からのメッセージを開始したりできます。

StackStormの主要コンポーネントのリスト：

• センサーは、イベントを受信または監視するインバウンドまたはアウトバウンド統合用のPythonプラグインです。 外部システムで発生したイベントがセンサーによって処理されると、StackStormトリガーが起動します。
• トリガー -StackStormの外部イベントの表現。 一般的なトリガー（タイマーやwebhookなど）と統合トリガー（SensuのアラームやJIRAのタスク更新など）があります。 新しいタイプのトリガーは、センサープラグインを記述することで識別できます。
• アクションは、発信StackStorm統合です。 一般的なアクション（ssh、REST呼び出し）、統合（OpenStack、Docker、Puppet）またはカスタムアクションがあります。 アクションは、Pythonプラグイン、または数行のメタデータを追加してStackStormと統合する他のスクリプトのいずれかです。 アクションは、CLIまたはAPIを介してユーザーが直接呼び出すことも、ルールとワークフローの一部として使用して呼び出すこともできます。
• ルールは 、一致基準を適用し、トリガーから受け取った情報をアクションの入力にリンクすることにより、トリガーをアクション（またはワークフロー）にバインドします。
• ワークフローは 、アクションを「ユーバーアクション」に組み合わせ、順序、遷移条件、およびワークフロー間のデータ転送を定義します。 ほとんどの自動化ソリューションには複数のステップがあるため、複数のアクションが必要です。 アトミックアクションのようなワークフローはアクションライブラリで利用でき、手動で呼び出すか、ルールに従って実行できます 。
• パッケージはコンテンツの展開単位です。 統合ツール（トリガーとアクション）と自動化（ルールとワークフロー）をグループ化することにより、StackStorm対応コンテンツの管理と共有を簡素化します。 StackStormコミュニティで利用可能なパッケージが増えています。 ユーザーはパッケージを作成したり、Githubにアップロードしたり、 StackStorm Exchangeに送信したりできます。
• コンテキストの起動に関する完全な情報と、手動または自動で開始されたアクションの結果を含む監査証跡 。

設計

StackStormは、メッセージキュー（ウサギ）とデータストレージ（mongo）を使用して状態を保存し、相互にデータを交換する多数のサービスで構成されています。 StackStormにはWebベースのインターフェイスもあります（無料版でもそうです！）。これにより、ルールを構成し、「オンデマンド」でアクションを実行し、監査ログを確認できます。

建築

AnsibleやSaltとは異なり、StackStormはワークステーションや通信を構成するようには設計されていません。 StackStormには、Salt、Chef、Puppet、およびAnsibleのパッケージが含まれているため、エージェントおよび構成管理システムにChefを使用する必要がある場合は、StackStormを使用して、SensuやKubernetesなどのAPIベースのサービスを呼び出します。 これは簡単に達成でき、明らかなソリューションです。 Saltには、最終マシンまたはマスター（オプション）での実行の概念がまだ存在します。 Kubernetes APIを呼び出す必要がある場合、どのコンピューターがAPIを呼び出したかという問題が議論の的になります。 ネットワークデバイスの構成についても同じことが言えます。

MongoDBは、十分に文書化されたテンプレートを使用してスケーリングできます。RabbitMQについても同様です。 サービス自体はHTTP / RESTful APIを使用して開発され、ロードバランシングを使用して拡張できます。 役割は、ニーズに応じて、単一のサーバーに展開することも、複数のサーバーに分散することもできます。

StackStormの拡張性が本当に好きです。これは間違いなく他の2つの製品よりも重要な利点です。 StackStorm拡張ポイントはパッケージと呼ばれます 。 これらは自己完結型であり、Gitに保存でき、Pythonの仮想パッケージレベル環境を介して依存関係を管理できます。 パッケージをインストールするときに、Git URLまたはHTTP URL（オプション）資格情報が指定され、StackStormは既にパッケージをダウンロード、構成、およびインストールします。

StackStormがプログラミング言語である場合、 強く型付けされます。 アクションの場合、すべての入力データのタイプが示され、トリガーの場合、フィールドとタイプが示されます。 これにより、サードパーティの拡張機能によって何が返されるかを簡単に予測できます。これはStackStormのユニークな機能です。

SaltやAnsibleとは異なり、StackStormには配信時に拡張機能が含まれていません 。それらはすべて個別にインストールする必要があります。 これにより、展開が容易になり、依存関係が簡素化されます。

StackStormの統合メカニズムを開発する場合、1つの定義でセンサー、アクション、およびワークフローを作成できます。 SaltおよびAnsibleモジュールはスタンドアロンです。 したがって、拡張機能（Saltなど）にビーコン、ランタイムモジュール、およびステータスモジュールが含まれている場合、タイトルと作成者を除いて共通の機能はありません。 これにより、pip依存関係を管理するときに問題が発生する可能性があります。

StackStormでのこの問題の解決策は、各パッケージに独自のrequirements.txtファイルと、パッケージの目的、要件、およびバージョンを説明するYAMLファイルがあることです。 既存の構成を維持しながら、パッケージを線形にアップグレードできます。 パッケージには、モジュールの構成形式がドキュメントにのみ保存されるAnsibleやSaltとは異なり、テンプレート構成も含まれており、ユーザーエラーの影響を受けやすくなっています。 さらに、開発者がわざわざ構成パラメータを適切に文書化しない場合、モジュールのコードを調べる必要があります。

もう1つのユニークな機能は、ChatOpsエイリアス（チャットコマンド）がパッケージに組み込まれていることです。 したがって、たとえばNAPALMパッケージをインストールすると、NAPALMのすべてのチャットコマンドもインストールされます。

コーポレートサポート

StackStormは、GitHubでホストされるオープンソースのApache-2ライセンス製品です。 StackStormの所有者はBrocadeです（最近資産の一部を売却し、StackStormの一部は現在Extreme Networksが所有しています）。

StackStormのライセンスを取得すると、「Brocade Workflow Composer」という製品が購入され、ライセンス所有者は追加の機能とエンタープライズレベルのサポートを受け取ります。 実稼働環境で使用したシステムにはライセンスが付与されていたため、サポートチームは応答性と知識が豊富であるという印象を受けました。 RBACも取得します。RBACでは、アクションの各レベルに対して、だれがどのアクションにアクセスできるかを指定できます。

Brocadeワークフローコンポーザー

ネットワークサポート

Brocade VLXまたはSDXを使用する場合は、幸運にもサポートされています。これは予想されることです。

2017年4月に、NAPALMライブラリのサポートと、Cisco、Juniper、Arista、およびその他のベンダー向けのクロスプラットフォームPython抽象化パッケージを組み合わせました。 これで、ルーティング、インターフェース、BGPピアリング、およびその他の優れた機能に関してNAPALM機能を使用できます。 Matt Oswalt（ネットワーク自動化に関するO'Reillyの本の共著者）は、この方向での進歩についての良いブログを書いています。

StackStormのNAPALMデモ

強み

• 無料のWebインターフェースはデフォルトで使いやすく、PythonやDevOpsの深い知識は必要ありません。
• ChatOps統合は組み込みであり、そのまま使用でき（Slackを使用すると、APIキーが単純にデプロイされます）、他の多くのチャットプラットフォームをサポートします。
• OpenStack Mistralは非常に強力であり、マスターすれば、いくつかのDevOpsツールをすぐにカバーできるようになり、ブランチとループを簡単に作成できます。
• Brocade Workflow Composerは、開発者以外がシステムを使用できるようにする優れた方法です。

弱点

• 利用可能なソルトとアンシブルほど多くの拡張パックはありません。 まず、システムおよびAPIでパッケージが利用可能かどうか、および含まれている機能を確認します。
• OpenStack Mistralシステムの文書化はまだ不十分ですが、YAQLクエリの構文には多くの試行錯誤があります。

塩

まず第一に、Saltは製品であり、SaltStackは会社です。 したがって、Saltについて話すとき、私はSalt Open-オープンソースバージョンについて話します。

Saltには膨大なコンポーネントのリストがあり、最初（そして「最初」と言うときは「1年目」を意味します）、本当に素晴らしいものになります。 Saltには多くの機能があるため、通常、SaltをAnsibleと比較すると、Saltファンは「はい、しかし、私たちにとってはもっと多くのことをします」と言います。 StackStormと同様に、これはSaltに対しても賛成にも反対にも機能します。 鉱山から穀物（結晶）を持ち込むように言ったなら、トールキンの小説を意味すると思いますが、塩の用語（塩鉱山）が塩の用語でわかるとすぐに、すべてが明らかになります。

設計

Saltは、リモートノードまたはミニオンでコマンドとクエリデータをリモートで実行するための分散システムとして生まれました。 リモート実行は、任意の選択基準（「 ターゲティング 」）に従って、個別のノードまたはグループで実行できます。

Saltは、指定された状態のリモートホストをサポートできる構成管理システムに拡張されました（たとえば、特定のパッケージがそれらにインストールされ、特定のサービスが実行されていることを確認します）。 ソルトには多くのコンポーネントがあり、何かを見逃したと確信しています！

• ソルトミニオンと通信するための基本サービスを実行するマスターサーバー。 また、それとミニオンの間で暗号化するためのキーストアも含まれています。
• ミニオンは、ローカル実行およびマスターとの通信にソルトのマイクロバージョンを使用するエージェントです。

• エンジン-また、Saltエンジン（塩エンジン）-これらは、長時間実行され、Saltで動作する外部プロセスです。

  
  
  
  
  
  
  
• 状態または式 -ミニオンを設定するためのYAMLおよびテンプレートデータを含むファイル。 テンプレートエンジンも非常に柔軟です。 Jinjaのサポートに限定されませんが、チェタ、genshi、mako（Puppetの経験がある人にとって非常に重要）、ウェンピー、または純粋なPythonさえもサポートします。

ミニオン（プロキシまたはレギュラー）は、グレイン（グレイン、クリスタル）、ピラー（ピラー、コラム）、または識別子を使用してアドレス指定できます。 SQLクエリやKVPリポジトリのようなものに基づいて独自のターゲットを作成する機能だけでなく、ターゲティング用のプラグインもあります。

• 穀物 -ソルトには、ダウンストリームシステムに関する情報を取得するためのインターフェイスが含まれています。 情報の「粒」で構成される「塩」であるため、「粒」インターフェースと呼ばれます。 オペレーティングシステム、ドメイン名、IPアドレス、カーネル、OSタイプ、メモリ、および他の多くのシステムプロパティのグレインが収集されます。 グレインインターフェースは、Saltモジュールおよびコンポーネントで使用できるため、必要なミニオンコマンドはそれぞれのシステムで自動的に使用可能になります。

  
  
  
  
  
  
  
• Pillarsは、ミニオンに分散されたグローバルな値を提供するように設計されたSaltインターフェースです。 Pillarは、JSON、YAML、またはその他の必須の自由形式のデータリソースであり、ファイルまたは外部に保存できます。 これは、共通のデータウェアハウスが役立つ他のシステム（たとえば、ITSMやリソースレジストリ）と統合できる固有のSaltプロパティです。

データを抽出するために、ミニオンからのデータを使用して、それらをソルトマイン （ソルトマイン）に保存することもできます。 将来、このデータは、テンプレートに基づく状態の構成など、他のタスクで使用できます。 （YAMLのみをサポートする）Ansibleとは異なり、異なる形式で実装できます。

建築

ソルトアーキテクチャは、ホイールハブとスポーク（ファン構造）の原理に基づいています。 非常に大規模な展開では、いくつかのウィザードを使用しますが、これはめったに起こりません。 ウィザードは、ZeroMQメッセージバスが軽量であるため、数千のノードに簡単に拡張できます。 その他の展開モデル：

1. ウィザードなしのインストール。
2. シンジケートの助けを借りて相互接続された階層マスター。

ウィザードには、通常、共有ストレージボリュームに配置されるステータスファイルが含まれています。 ターゲティングを使用して、構成用のサーバーグループと展開用の環境/アプリケーションを定義できるように、ツリービューで構成されます。

イベントベースのSaltシステムはビーコンを使用します。 StackStormセンサーおよびトリガーシステムと同様に、Saltビーコンはメッセージバスでイベントをトリガーし、その後、リアクター（マスター）で処理できます。 通常、イベントをトリガーするビーコンの背後で状態または実行コマンドがアクティブ化されるため、リアクターのルールメカニズムはStackStormと比較するとかなり粗雑です。 ただし、ビーコンはミニオンで動作するため、サーバーでイベントが検出された場合、すべてが非常に明確です。 StackStormとAnsibleにはエージェントがないため、これはユニークなSalt機能になります。

トリウム （トリウム）-塩の複雑な反応器は、実験として最後のリリースに含まれており、 おそらく 、将来のリリースでサポートされるでしょう 。 Thoriumは、より複雑なルールとイベント収集のサポートを追加します。

拡張性

Saltのすべては、CLIでランタイム結果を表示するモジュールに至るまで拡張可能です。 これは、Saltにとって大きなプラスです。メインプロジェクトで並列分岐を維持する必要なく、独自の変更を簡単に実装できるためです。 Saltの各機能もプラグイン可能です。

最も一般的な拡張シナリオは、状態モジュールの開発（ソフトウェアまたはサービスの構成方法を説明するため）または実行モジュール （APIまたはシステムと対話するためのコード）の開発です。 どちらのタイプのモジュールも、比較的小さなテンプレートを使用して作成できます。どちらも十分に文書化されており、優れた組み込みテスト環境を使用してテストできます。 PyTestを使用して、ウィザードを使用したり、ウィザードをまったく使用しなくても、モジュールのノードテストを実行できます。 統合テストにはLinuxシステムが必要ですが、ハッカースキルをほとんど使用せずにOSXでモジュールを実行することもできます（StackStorm with Ansibleの場合のように、Windowsは問題外です）。

スタンドアロンパッケージを維持するか、GitHubのSaltプロジェクトに直接貢献することができます。 , . 3-5 , , Salt « », .

Salt , SPM , (state files). , , ( ).

Salt . - . ( Salt), , , .

«Salt Open» — , "Salt Enterprise", , :

• - , , LDAP;
• ServiceNow, ServiceNow ITSM;
• RBAC LDAP ();
• «Enterprise API», Enterprise REST API.

Salt , ZeroMQ , , Salt. Salt « ». - — — , SSH, HTTP . , , . Puppet ( , ), , , , . , . 40 . -, Python, . Salt SaltConf.

:

• JunOS (Juniper);
• NXOS (Cisco);
• Cisco NSO ( NETCONF Cisco);
• NAPALM.
  
  
  
  Salt NAPALM Cloudflare. NSO NAPALM , NSO Cisco, , .

NAPALM Salt

• Salt , ( salt-ssh
  
  
  
  ).
• ZeroMQ.
• Windows, Linux .
• (, LinkedIn) .
• Salt API- .

弱点

• , , .
• , . . pip-.

おわりに

?

. Salt StackStorm . StackStorm , (), , , . Salt — , , . . Ansible ( ) .

, Ansible , ( Brocade StackStorm) . , Ansible . NAPALM NSO StackStorm, Salt , Arista, JunOS (Juniper), Cisco APIC-EM, NXOS ..

Ansible — (, , ). CLI - . (, ), , . , , .

Salt , . Hashicorp Vault, . SQL, , , « ». , , .

安全性

Ansible Salt, Salt , Ansible SSH . Ansible, , , (, ). Salt . , grains . StackStorm MongoDB, , , , .

トレーニング

, , . Salt Ansible , StackStorm — . Salt (RedHat) Ansible , StackStorm — (). Salt Ansible PluralSight, .

免許

Salt, StackStorm Apache-2, Ansible — GPLv3. OSS, - «TLDR Legal». Salt SuSE ( - OSS).

( ), Ansible DevOps . , Ansible , Salt StackStorm. DevOps , , .

?

, . , , DevOps, , , .

, , , — .

: Salt, StackStorm, Ansible .

Dimension Data, , , Python, opensource, .

参照資料

1. Ansible vs Salt (SaltStack) vs StackStorm .