スレッドの切断: Puppet Enterprise から Ansible Tower への移行。 パート1

National Environmental Satellite Data Information Service (NESDIS) は、Puppet Enterprise から Ansible Tower に移行することにより、Red Hat Enterprise Linux (RHEL) の構成管理コストを 35% 削減しました。この「私たちのやり方」ビデオでは、システム エンジニアの Michael Rau がこの移行の事例を説明し、ある SCM から別の SCM への移行から得た役立つヒントと教訓を共有しています。

このビデオから次のことを学びます:

• Puppet Enterprise から Ansible Tower への切り替えの実現可能性を管理者に正当化する方法。
• 移行をできるだけスムーズにするためにどのような戦略を使用するか。
• PE マニフェストを Ansible Playbook にトランスコードするためのヒント。
• Ansible Tower の最適なインストールに関する推奨事項。

皆さん、こんにちは。私の名前は Michael Rau です。ActioNet のシニア システム エンジニアです。米国海洋大気庁 (NOAA) の NESDIS サービスに勤務しています。今日は文字列のトリミングについてお話します。これは、Puppet Enterprise から Ansible Tower に移行した私自身の経験です。このプレゼンテーションのテーマは、今年初めにこの移行を行った後に残された「私の傷跡を見てください」です。このプロセスを通じて学んだことを共有したいと思います。したがって、このようなことに取り組むとき、私の経験を活用すると、追加の作業なしで移行することができます。

Ansible Fest では、すべてのプレゼンテーションの冒頭にこれに似たスライドが表示されます。このスライドは、私の会社の自動化の歴史を概説しています。私は 2007 年から Puppet/Puppet Enterprise を使用しているので、これについては初めてではありません。私は 2016 年に Ansible を使い始めましたが、この製品の他の多くのユーザーと同様に、コマンドラインと単純なスクリプト (プレイブック) を使用した「トリック」の可能性に惹かれました。 2017 年末、私は Ansible Tower に移行する強い理由について経営陣に相談しました。私がこのステップを踏むきっかけとなった理由については、後ほど説明します。経営陣の同意を得てからさらに数カ月をかけて計画を立て、今年１～２月に移行した。そこで、私たちは Puppet を完全に放棄して Ansible を採用しました。これは素晴らしいことです。

私にとって Ansible について最も魅力的なのは、ロールとプレイブックを作成して使用できることです。ロールは、個別ではあるが関連するタスクを作成し、それらのタスクに関連するすべてのデータを XNUMX か所に置くのに最適です。プレイブックは、XNUMX つ以上のホストのアクションを記述する YAML 構文のスクリプト ファイルです。私はこれらの機能について、主にソフトウェア開発者であるユーザーに説明します。 Ansible Tower を使用すると、「いいえ、シェルへのアクセス権はありませんが、すべての Tower プロセスを実行し、必要なときにサービスを再起動する機能は与えられます。」と言うことができます。作業環境や使用している設備についてご紹介します。

これは、連邦 LAN、クラウド MPLS 経由で接続された 7 つの物理サイト、140% が仮想 (vSphere) である 99 台の RHEL サーバー、SuperMicro ハードウェア、NexentaStore ネットワーク ストレージ、Cisco、Arista、Cumulus スイッチのセット、および Fortinet UTM 統合脅威管理です。各サイトのツール。

連邦ネットワークは、法律で規定されているすべての情報セキュリティ対策を使用する必要があることを意味します。 Puppet Enterprise は、当社が使用するハードウェアのほとんどをサポートしていないことに注意してください。政府機関がこの経費項目の資金調達に問題があるため、私たちは予算ハードウェアを使用せざるを得ません。そのため、当社は SuperMicro ハードウェアを購入し、個々の部品から機器を組み立てており、そのメンテナンスは政府契約によって保証されています。私たちは Linux を使用しており、これが Ansible に切り替える重要な理由の XNUMX つです。

当社とPuppetの歴史は以下の通りです。

2007 年には、20 ～ 25 ノードの小規模なネットワークがあり、そこに Puppet を導入しました。基本的に、これらのノードは単なる RedHat の「ボックス」でした。 2010 年に、45 ノードで Puppet Dashboard Web インターフェイスの使用を開始しました。ネットワークが拡大し続けるにつれて、2014 年に PE 3.3 に移行し、75 ノードのマニフェストを書き換えて完全に移行しました。 Puppet はゲームのルールを変更することを好み、この場合は言語を完全に変更したため、これを行う必要がありました。 3 年後、Puppet Enterprise バージョン 2015.2 のサポートが終了したとき、PE 100 への移行を余儀なくされました。新しいサーバー用にマニフェストを再度書き直し、85 ノードを確保したライセンスを購入する必要がありました (当時は XNUMX ノードしかありませんでした)。

わずか 2 年が経過しましたが、新しいバージョン PE 2016.4 に移行するには、再び多くの作業を行う必要がありました。 300 ノードのライセンスを購入しましたが、ノード数は 130 しかありませんでした。新しいバージョンの言語の構文は 2015 バージョンの言語とは異なるため、マニフェストに再び大きな変更を加える必要がありました。その結果、当社の SCM は SVN バージョン管理から Bitbucket (Git) に切り替わりました。それが私たちパペットとの「関係」でした。

そのため、次の議論を使用して、なぜ別の SCM に移行する必要があるのか​​を経営陣に説明する必要がありました。 300つ目はサービスの価格が高いことです。 RedHat の担当者と話をしたところ、Ansible Tower で XNUMX ノードのネットワークを実行するコストは、Puppet Enterprise のコストの半分であるとのことでした。 Ansible Engine も購入すると、コストはほぼ同じになりますが、PE よりも多くの機能を利用できるようになります。当社は連邦予算から資金調達されている国有企業であるため、これは非常に強力な議論です。

XNUMX 番目の引数は汎用性です。 Puppet は、Puppet エージェントを備えたハードウェアのみをサポートします。これは、エージェントがすべてのスイッチにインストールされ、最新バージョンである必要があることを意味します。また、一部のスイッチがあるバージョンをサポートし、別のスイッチが別のバージョンをサポートしている場合、すべてのスイッチが同じ SCM システムで動作できるように、新しいバージョンの PE エージェントをそれらのスイッチにインストールする必要があります。

Ansible Tower システムにはエージェントがないため動作が異なりますが、Cisco スイッチおよびその他すべてのスイッチをサポートするモジュールはあります。この SCM は、Qubes OS、Linux、および 4.NET UTM をサポートします。 Ansible Tower は、オープンソースの Unix ベースのオペレーティング システムである Illumos カーネルに基づく NexentaStore ネットワーク ストレージ コントローラーもサポートしています。これはほとんどサポートされていませんが、Ansible Tower はとにかくそれを行います。

10 番目の議論は、私にとっても私たちの政権にとっても非常に重要ですが、使いやすさです。私は Puppet モジュールとマニフェスト コードをマスターするのに XNUMX 年を費やしましたが、Ansible については XNUMX 週間以内に習得しました。これは、この SCM の方がはるかに扱いやすいためです。もちろん、不必要に実行しない限り、実行可能ファイルを実行すると、インテリジェントで応答性の高いハンドラーがそれらのファイルを処理します。 YAML ベースの Playbook は学習が簡単で、すぐに使用できます。 YAML について聞いたことがない人でも、スクリプトを読むだけで、YAML がどのように機能するかを簡単に理解できます。

正直に言うと、Puppet は Puppet Master の使用に基づいているため、開発者としての仕事をはるかに困難にします。これは、Puppet エージェントと通信できる唯一のマシンです。マニフェストに変更を加えてコードをテストしたい場合は、Puppet Master のコードを書き直す必要があります。つまり、すべてのクライアントに接続し、Puppet Server サービスを開始するように Puppet Master /etc/hosts ファイルを構成します。この後初めて、XNUMX 台のホスト上でネットワーク機器の動作をテストできるようになります。これはかなり痛みを伴う手順です。
Ansible ではすべてがはるかに簡単です。必要なのは、テスト対象のホストと SSH 経由で通信できるマシンのコードを開発することだけです。これは作業がはるかに簡単です。

Ansible Tower の次の大きな利点は、既存のサポート システムを活用し、既存のハードウェア構成を維持できることです。この SCM は、追加の手順を行わずに、インフラストラクチャとハードウェア、仮想マシン、サーバーなどに関する利用可能な情報をすべて使用します。 RH Satellite サーバーがある場合はそれと通信でき、Puppet では決して得られない統合を実現します。

もう一つ重要なことは、詳細な制御です。 Puppet はモジュール式システムであり、クライアント/サーバー アプリケーションであるため、すべてのマシンの既存の側面を XNUMX つの長いマニフェストで定義する必要があることはご存知でしょう。この場合、システムの個々の要素の状態を XNUMX 分ごとにテストする必要があります。これがデフォルトの期間です。これがパペットの仕組みです。

タワーはそこからあなたを救います。さまざまな機器上でさまざまなプロセスを制限なく実行できます。基本的な作業を実行したり、他の重要なプロセスを実行したり、セキュリティ システムをセットアップしたり、データベースを操作したりできます。 Puppet Enterprise では難しいことはすべてできます。したがって、XNUMX つのホストで構成した場合、変更が残りのホストに反映されるまでに時間がかかります。 Ansible では、すべての変更が同時に有効になります。

最後に、セキュリティモジュールを見てみましょう。 Ansible Tower は、非常に正確かつ慎重に、驚くほど簡単にそれを実装します。ユーザーに特定のサービスまたは特定のホストへのアクセスを許可できます。私はこれを Windows での作業に慣れている従業員に対して行い、Linux シェルへのアクセスを制限しています。彼らが Tower にアクセスできるようにして、自分たちに関連する作業だけを実行し、サービスだけを実行できるようにします。

Ansible Tower への移行を容易にするために、事前に行う必要があることを見てみましょう。まず最初に、機器を準備する必要があります。インフラストラクチャの一部の要素がまだデータベースにない場合は、そこに追加する必要があります。特性が変わらないため Puppet データベースに含まれていないシステムもありますが、Tower に移行する前にそれらをデータベースに追加しないと、多くの利点が失われます。これは「汚い」予備データベースかもしれませんが、所有しているすべての機器に関する情報が含まれている必要があります。したがって、すべてのインフラストラクチャの変更をデータベースに自動的にプッシュする動的ハードウェア スクリプトを作成する必要があります。そうすれば、Ansible は新しいシステムにどのホストが存在すべきかを認識します。 SCM はこれらすべてを自動的に認識するため、追加したホストと存在しないホストをこの SCM に伝える必要はありません。データベース内のデータが増えるほど、Ansible はより便利で柔軟になります。これは、単にデータベースからハードウェア ステータス バーコードを読み取るかのように動作します。

時間をかけて、Ansible のコマンドラインに慣れてください。カスタム コマンドを実行してハードウェア スクリプトをテストし、シンプルだが便利な Playbook スクリプトを作成して実行し、必要に応じて Jinja2 テンプレートを使用します。一般的で一般的に使用されるハードウェア構成を使用して、複雑な複数ステップのプロセス用のロールとスクリプトを作成してみてください。これらのものを試して、それがどのように機能するかをテストしてください。このようにして、Tower で使用されるライブラリ作成ツールの使用方法を学習します。移行の準備に約 3 か月かかったとすでに述べました。私の経験に基づいて、これをより速く行うことができると思います。この時間を無駄だと考えないでください。後で、実行した作業のすべての利点を体験することになるからです。

次に、Ansible Tower に何を期待するか、このシステムが正確に何をするかを決定する必要があります。

システムをベアハードウェアやベア仮想マシンにデプロイする必要がありますか?それとも既存の機器の元の動作条件や設定を維持したいですか?これは上場企業にとって非常に重要な側面であるため、既存の構成に Ansible を移行してデプロイできることを確認する必要があります。自動化したい日常的な管理プロセスを特定します。新しいシステムに特定のアプリケーションとサービスを展開する必要があるかどうかを確認します。やりたいことをリストアップして優先順位を付けましょう。

次に、完了する予定のタスクを実行できるようにするスクリプト コードとロールの作成を開始します。それらを、関連する Playbook の論理的なコレクションであるプロジェクトに結合します。各プロジェクトは、使用するコード マネージャーに応じて、別個の Git リポジトリまたは別のリポジトリに属します。 Playbook スクリプトと Playbook ディレクトリを管理するには、それらを Tower サーバー上のプロジェクト ベース パスに手動で配置するか、Tower でサポートされている任意のソース コード管理 (SCM) システム (Git、Subversion、Mercurial、Red Hat など) にプレイブックを配置します。洞察。 XNUMX つのプロジェクト内に、必要な数のスクリプトを配置できます。たとえば、基本的なプロジェクトを XNUMX つ作成し、そこに RedHat コア要素のスクリプト、Linux コアのスクリプト、および残りのベースラインのスクリプトを配置しました。したがって、XNUMX つのプロジェクトには、XNUMX つの Git リポジトリから管理されるさまざまなロールとシナリオがありました。

これらすべてをコマンド ラインから実行することは、機能をテストする良い方法です。これにより、Tower のインストールの準備が整います。

Puppet マニフェストのトランスコーディングについて少し話しましょう。実際に何を行う必要があるのか​​を理解するまで、これに多くの時間を費やしたからです。

前に述べたように、Puppet はすべての設定とハードウェア オプションを XNUMX つの長いマニフェストに保存し、このマニフェストにはこの SCM が行うべきすべてのものが保存されます。移行するときは、すべてのタスクを XNUMX つのリストに詰め込む必要はありません。代わりに、新しいシステムの構造 (ロール、スクリプト、タグ、グループ、およびそこに何を入れる必要があるか) を検討します。自律ネットワーク要素の一部は、スクリプトを作成できるグループにグループ化する必要があります。自己完結型クラスなど、多数のリソースを必要とするより複雑なインフラストラクチャ要素をロールに組み合わせることができます。移行する前に、これを決定する必要があります。 XNUMX つの画面に収まらない大規模なロールまたはシナリオを作成している場合は、タグを使用してインフラストラクチャの特定の部分をキャプチャできるようにする必要があります。

18:00

スレッドの切断: Puppet Enterprise から Ansible Tower への移行。 パート2

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com