ネットワーク インフラストラクチャを制御する方法。 第四章。 オートメーション。 テンプレート

この記事は、「ネットワーク インフラストラクチャを制御する方法」シリーズの 6 番目です。シリーズのすべての記事の内容とリンクが見つかります。 ここで.

いくつかのトピックを置き去りにして、新しい章を始めることにしました。

もう少ししたらセキュリティに戻ります。ここでは、シンプルだが効果的なアプローチについて説明したいと思います。これは、何らかの形で多くの人に役立つと確信しています。これは、自動化がエンジニアの生活をどのように変えることができるかについての短い物語です。テンプレートの使用について説明します。最後に私のプロジェクトのリストがあり、ここで説明したすべてのことがどのように機能するかを確認できます。

ネットワークのDevOps

スクリプトを使用した構成の作成、GIT を使用した IT インフラストラクチャへの変更の制御、リモートの「アップロード」 - DevOps アプローチの技術的な実装を考えるときに、これらのアイデアが最初に浮かび上がります。利点は明らかです。しかし、残念ながらデメリットもあります。

5 年以上前、開発者が私たちネットワーカーのところにこれらの提案を持ってきたとき、私たちは嬉しくありませんでした。

私たちは、約 10 社の異なるベンダーの機器で構成される、かなり雑多なネットワークを継承したと言わざるを得ません。一部の設定はお気に入りの CLI を使用して行うと便利ですが、その他の設定では GUI を使用することを好みます。さらに、「ライブ」機器での長時間の作業により、リアルタイム制御が可能になりました。たとえば、変更を加える場合、cli を介して直接作業する方がはるかに快適です。こうすることで、何か問題があったことをすぐに確認し、変更をロールバックできます。これらすべては彼らの考えと矛盾していました。

たとえば、インターフェイスがソフトウェアのバージョンごとに若干異なる可能性があるなど、他の疑問も生じます。これにより、最終的にはスクリプトが間違った「構成」を作成することになります。私は「慣らし運転」のためにプロダクションを使いたくありません。

または、構成コマンドが正しく適用されたことをどのように理解して、エラーが発生した場合はどうすればよいでしょうか?

これらすべての問題が解決不可能だと言いたいわけではありません。 「A」と言うだけで「B」と言うのも当然でしょう。開発時と同じプロセスを変更管理に使用したい場合は、運用環境に加えて開発環境とステージング環境が必要です。これで、このアプローチは完了したように見えます。しかし、どれくらいの費用がかかりますか？

しかし、デメリットが実質的に平準化され、メリットだけが残る状況が 1 つあります。デザインの仕事について話しています。

プロジェクト

過去 5 年間、私は大手プロバイダーのデータセンターを構築するプロジェクトに参加してきました。私はこのプロジェクトで F3 とパロアルトを担当しています。シスコの観点からは、これは「サードパーティ製の機器」です。

私個人にとって、このプロジェクトには 2 つの異なる段階があります。

第一段階

最初の年は果てしなく忙しく、夜も週末も働きました。頭を上げることができませんでした。経営陣と顧客からのプレッシャーは強く、継続的でした。一定のルーチンでは、プロセスを最適化しようとすることさえできませんでした。機器の構成だけではなく、設計文書の準備も必要でした。

最初のテストが始まりましたが、どれほど多くの小さなエラーや不正確さがあったのかに驚かれるでしょう。もちろん、すべてうまくいきましたが、名前に文字が抜けていて、コマンドに行が抜けていました...テストは延々と続き、私はすでにエラー、テスト、ドキュメントとの絶え間ない毎日の格闘にさらされていました。 。

これが1年間続きました。私の理解する限り、このプロジェクトは誰にとっても簡単なものではありませんでしたが、徐々にクライアントの満足度が高まり、日常業務の一部を自ら担当できるエンジニアを追加雇用することが可能になりました。

さて、少し周りを見渡すことができました。
そしてこれが第二段階の始まりでした。

第二段階

このプロセスを自動化することにしました。

当時の開発者とのコミュニケーションから私が理解したのは (そして、私たちは強力なチームを持っていたことに敬意を表しなければなりません)、テキスト形式は、一見すると DOS オペレーティング システムの世界のもののように見えますが、数値が含まれているということです。貴重な財産の。
したがって、たとえば、GIT とそのすべての派生機能を最大限に活用したい場合には、テキスト形式が役立ちます。そして私はそうしたいと思いました。

単純に設定やコマンドのリストを保存できるように思えますが、変更するのは非常に不便です。さらに、設計時にはもう一つ重要な作業があります。設計全体 (低レベル設計) と特定の実装 (ネットワーク実装計画) を説明するドキュメントが必要です。この場合、テンプレートの使用は非常に適切なオプションのように見えます。

したがって、YAML と Jinja2 を使用する場合、IP アドレス、BGP AS 番号などの構成パラメータを含む YAML ファイルは NIP の役割を完全に果たしますが、Jinja2 テンプレートには設計に対応する構文が含まれています。 LLDの反映。

YAML と Jinja2 を学ぶのに 5 日かかりました。これがどのように機能するかを理解するには、いくつかの良い例を参照するだけで十分です。その後、デザインに一致するすべてのテンプレートを作成するのに約 XNUMX 週間かかりました。パロアルトでは XNUMX 週間、FXNUMX ではさらに XNUMX 週​​間かかりました。これらはすべて企業の githab に投稿されました。

変更プロセスは次のようになります。

• YAMLファイルを変更しました
• テンプレート（Jinja2）を使用して構成ファイルを作成しました
• リモートリポジトリに保存される
• 作成した設定を機器にアップロードします
• エラーが発生しました
• YAML ファイルまたは Jinja2 テンプレートを変更しました
• テンプレート（Jinja2）を使用して構成ファイルを作成しました
• ...

最初は編集に多くの時間が費やされたことは明らかですが、1 ～ 2 週間後には、これはむしろ珍しいことになりました。

命名規則を変更したいというクライアントの要望は、すべてをデバッグするための良いテストと機会でした。 F5 で働いていた人たちは、状況の深刻さを理解しています。しかし、私にとってそれはすべて非常に単純でした。 YAML ファイル内の名前を変更し、機器から設定全体を削除し、新しい設定を生成してアップロードしました。バグ修正を含むすべての作業には 4 日かかり、各テクノロジに XNUMX 日かかりました。その後、次の段階、つまり DEV およびステージング データ センターの構築の準備が整いました。

開発とステージング

ステージングは​​実際には本番環境を完全に複製します。 Dev は、主に仮想ハードウェア上に構築された、大幅に機能が削減されたコピーです。新しいアプローチにとって理想的な状況です。全体のプロセスから費やした時間を分離すると、作業には 2 週間もかからなかったと思います。主な時間は、相手を待ち、一緒に問題を探す時間です。サードパーティの実装は、他の人にはほとんど注目されませんでした。何かを学び、ハブレについていくつかの記事を書く時間もありました :)

要約します

では、結局のところ何を考えているのでしょうか?

• 構成を変更するには、構成パラメーターを含む単純で明確に構造化された YAML ファイルを変更するだけです。私は Python スクリプトを変更することはありません。ごくまれに (エラーがあった場合のみ) Jinja2 ヒートレートを変更します。
• ドキュメントの観点から見ると、これはほぼ理想的な状況です。ドキュメントを変更し (YAML ファイルが NIP として機能する)、この設定を機器にアップロードします。こうすることでドキュメントは常に最新の状態になります

これらすべてが、次のような事実につながりました。

• エラー率はほぼ0にまで低下しました
• ルーティンの90パーセントがなくなった
• 導入のスピードが大幅に向上しました

PAY、F5Y、ACY

それがどのように機能するかを理解するには、いくつかの例で十分であると言いました。
これは、私の仕事中に作成されたものの短い (そしてもちろん修正された) バージョンです。

お支払い = 展開 PALO Aからの Yaml = Yaml のパロアルト
F5Y = 展開 F5 から Yアムール = F5 から Yaml (近日公開予定)
ACY = 展開 AC私はから Yアムール = F5 から Yaml

ACY について少し補足します (ACI と混同しないでください)。

ACI で働いたことのある人は、この奇跡 (そして良い意味でも) がネットワーカーによって生み出されたものではないことを知っています :)。ネットワークについて知っていたことはすべて忘れてください。役に立ちません。
少し大げさですが、私がこの 3 年間、ACI で働き続けてきた感覚をざっくりと伝えています。

この場合、ACY は変更管理プロセスを構築する機会であるだけでなく (ACI の場合、データセンターの中心的かつ最も重要な部分であると考えられているため、これは特に重要です)、また、次のことも提供します。構成を作成するためのユーザーフレンドリーなインターフェイス。

このプロジェクトのエンジニアは、まったく同じ目的で YAML の代わりに Excel を使用して ACI を構成します。もちろん、Excel を使用することには次のような利点があります。

• NIP を 1 つのファイルにまとめてあります
• お客様が見ても楽しい美しい看板
• いくつかの Excel ツールを使用できます

しかし、マイナス点が 1 つあり、私の意見では、それが長所を上回っています。変更を制御し、チーム作業を調整することは、はるかに困難になります。

ACY は、実際には、サードパーティが ACI を構成するために使用したものと同じアプローチを応用したものです。

出所： habr.com