ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

Infrastructure as Codeによるインフラ環境自動化の取り組み

ライター:庄谷 信哉
2005年にネットワンシステムズに入社し、スイッチ製品の新旧技術の調査・検証業務を元に
ネットワーク提案、導入を支援する業務を経て、現在は、クラウド関連製品担当に従事。
最近は、企業システムの今後のマルチクラウド化を見据えたクラウド関連技術の最新動向に注目している。

目次

はじめに

現在、弊社では、インフラをコードで管理するInfrastructure as Codeの取り組みを進めており、作成されたコードをIP(知的財産)化して、GitLabで共有しています。今回は、その取り組みについてご紹介します。

1.Infrastructure as Codeへの取り組み背景

これまで、ネットワークエンジニアは、コンフィグとパラメータシートを作業用PCに保存し、そこから物理機器へCLI操作を行ってコンフィグ投入してきました。

【過去】


最近、ネットワークエンジ
ニアは、SDxコントローラを通じて物理機器へコンフィグを投入する流れに変わってきています。

【最近】


さらに近い将来では、コンフィ
グやパラメータといったものは、ソフトウェアコード管理として使われるGitLab上でコードと同様に管理され、コードのアップロードを含めた「変更」をトリガーに物理機器へ適用されていく流れに変わっていくと考えています。

【近い将来】

GitLab logos by https://about.gitlab.com/

2.Infrastructure as Codeの実施例

今回、弊社にて実施しました2種類のInfrastructure as Codeを利用したPoCをご紹介します。

2-1.コンフィグレーションの差分チェックシナリオ

まず1点目ですが、ルータをバージョンアップした際にコンフィグレーションの差分が発生した場合、自動的にその差分を検知するシナリオとなります(ある機能のコンフィグレーション方法が変わったなど)。

こちらでは、Cisco CSR1000Vルータ(以下よりCSR1000Vと記載)のコンフィグレーションをGitlabにアップロードすると、自動的に異なる2つのIOSバージョンでコンフィグレーションをテストロードし、その起動コンフィグの差分検出結果を出力することが可能です。

本機能では、自動化を実現するため、以下のコンポーネントを利用しています。

 【利用しているコンポーネント】

  ・Gitlab Enterprise Edition(以下より、Gitlabと記載)

  ・Gitlab Runner

  ・Ansible

  ・Cisco Modeling Labs – Personal(以下より、CMLと記載)

本シナリオでは、コンフィグレーション差分検出の自動化を実現するため、Ansible Playbookを利用し、ルータに以下の処理を実行します。

 【ルータへの実行内容】

  1.対象とするコンフィグレーション設定

  2.指定するバージョンのOSダウンロード

  3.指定するバージョンで起動後、前バージョンとの差分を取得し、コンフィグレーションの差分を自動検出

そして、今回は、さらに本シナリオの自動化を促進できるような仕掛けとして以下を組み合わせ、ユーザが検査したいコンフィグレーションをGitlab上にアップするだけで、IOSのバージョンによるコンフィグレーションの差分結果を出力し、Gitlabからダウンロード可能するプロトタイプを作成しました。

 【本シナリオにおける自動化への仕掛け】

 ・Ansible Playbookを格納可能なGitlab

 ・定義に沿ってAnsible Playbookを自動実行するGitlab Runner

 ・物理ルータの確保が困難な場合でも、仮想環境で検証可能なCML上にコンフィグチェック用の仮想ルータ(CSR1000V)を自動作成

GitLab logos by https://about.gitlab.com/

2-2.Windows updatePlaybookチェックシナリオ

次に2点目のシナリオとして、GitlabにアップデートしたAnsible Playbookの正常性をチェックするため、以下の観点で自動チェックするプロトタイプを作成しました。今回のチェックは、Windowsに対してWindows updateを自動実行するAnsible Playbookを対象としています。

 【Playbookの正常性観点】

  以下の異なる2つのAnsibleバージョンを利用して実行しバージョンアップした際に動作に問題が出るかを自動チェック。

  ・Ansible Lint/Yaml Lintを利用した静的解析

  ・VMware vCenter Serve(以下よりvCenterと記載)上にWindows Server VMを作成し、Ansible Playbookの実動作を確認

GitLab logos by https://about.gitlab.com/

こちらのシナリオでは、Ansible Playbookを実際のWindowsが動作するVMに対して実施しています。

そのテスト環境自体も「作成」から「削除」まで自動で実施することでVMリソースの有効活用を実現しました。

3.まとめ

 このようにInfrastructure as CodeGitlabContinuous Integration(CI)の機能を利用することで、インフラに対する動作チェックを自動することが可能となり、これまでテストにかかっていたエンジニア工数を削減することにもつながってくると考えております。

今後も、このようなシナリオをブログ等にてご紹介していきたいと思っています。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND