VMwareの運用シーンでもできるCI/CD

【IIJ 2020 TECHアドベントカレンダー 12/20（日）の記事です】

はじめに

こんにちは。クラウドサービスの開発を担当している山本です。私たちのチームでは2009年より提供し続けている「IIJ GIO」の次世代を実現させる「GRP（GIO Re-birth Project）」を実行中です。次世代のサービス、ということで開発体制だけでなく、調達、物理設計から業務・工程を見直し、次世代のIaaSを開発するプロジェクトを進めています。その中での取り組みを一つご紹介します。

VMwareの運用と課題

いろいろなご意見もあるかとは思いますが、エンタープライズのお客様にご利用いただくにあたり、IaaSをVMware (vSphere)で構成するということは一つの重要なポイントです。「クラウド移行」のニーズにお応えするにはvSphereであることがメリットの一つでもあり、ハイパーバイザーをvSphereにすることで移行や運用をサポートするソフトウェア・サービスとの強力な連携と、VMwareの持つ仮想化テクノロジーのとの融合が実現、そのメリットをお客様に享受いただくことができます。(ここは今回の本筋から外れるのでまたの機会に)

GRPの一要素である次世代IaaSでもVMwareのテクノロジーを活用しサービス基盤を作っています。VMwareは仮想化プラットフォームで圧倒的なシェアを持っており、ナレッジが山程あります。こちらをみていただいているみなさまも(なんらかの)vSphere Clientでオペレーションをされたことがあると思います。GUIベースで誰でもオペレーションができる良いものです。

ただ、大量のリソースを扱うサービス基盤の運用においてGUIだけでオペレーション、特に構成変更を行う、というのは非常に手間がかかり、どんどん状況が変わるビジネス要件に柔軟・迅速に対応するのは大変です。1台2台ならまだしも、複数のお客様を収容するための設備、物理数百台、仮想マシン延べ数千台超にものぼる対象を手作業で構築、構成管理することは、現代に求められるクラウドやインフラの変化スピードには応えられないことは必然です。運用中もニーズに応じて最短のリードタイムで拡張や、必要に応じて縮小できることもインフラに求められる重要な要件です。

そこで、VMwareレイヤとそれを稼働させるためのホスト(VM)群の運用においても構成管理、作業の自動化を実現させました。

DevOpsの思想でGitベースのCI/CDパイプラインを構築

本プロジェクトではIaaSを構成するインフラの情報はすべてGitLab上のGitリポジトリで管理しています。構成管理はAnsibleでおこなっています。わかりやすいところでhost_varsのスクリーンショットを貼ります。お見せできないところをモザイク入れてしまったのでわかりにくいのですが、ESXiがAnsibleで管理されているのがわかると思います。

複数のコンポーネントを統合的に管理

それだけでなく、ネットワーク仮想化の機能を提供するNSX-Tや、管理機能を提供するVCSA(vCenter)やvRealize Log Insight、その他VMwareコンポーネント、さらにはVMware環境を管理するためのVM(DNSやその他Utility系のホスト)もすべて単一のリポジトリで構成(設定)を管理しています。

また、ココがキモなのですが、ESXiのインストール〜ブートは自社開発のツールを利用したり、vSphere, NSX-T, Cloud Directorなどの様々なコンポーネント群を統合的に管理するため、AnsibleのRoleを利用しています。一部のコンポーネントについては、Ansible Galaxyに最適なRoleが存在しなかったため、スクラッチで開発しました。

(Role周りは今回の要なのですが文字数の都合で省略します。またの機会に詳しいメンバーに紹介してもらいたい。。。)

設定変更の自動化

このGitLabリポジトリで構成管理し、設定の反映はAnsibleで行います。GitLabにはGitLab Runnerというジョブの実行ツールがありますので、設定の反映はGitLab Runnerに任せることができます。インフラの構成変更時にはエンジニアがリポジトリのコードを変更し、それを(機械的 and 人的なレビュー/承認工程を経て)マージさせ、GitLab Runner経由でAnsibleを実行することで設定変更が自動化できます。(こちらもモザイクだらけですみません)

これにより、リポジトリベースで「構成変更のイベント発生〜コード修正〜テスト〜デプロイ〜運用」のCI/CDパイプラインができました。

よかったこと

GitLabベースの構成管理・自動化を実施することで様々なメリットを享受できました。

• 構成管理(設定シート)のExcelがいらない（コードどおりなのでパラメータシート不要)
• ログイン情報等機密情報管理の省力化（機密情報を自動参照）
• 過去の変更が追える（万一変更による致命的な障害があっても短時間で戻せる）
• レビュー工程の高速化
  • (他にもたくさんある)

この成果を踏まえ、VMwareの運用シーンでもSRE (Site Reliability Engineering) を意識しチームが自律的に動けるようになっています。
# チームのリードをしている山本の負担も減る

今後の展望

GRP（GIO Re-birth Project）は次世代サービスということで色々新しいチャレンジをしています。現在は新サービスのリリースに向けて更に技術領域を広げながら開発・運用を行っています。アプリケーション実行基盤としてのコンテナ環境など、新たな領域もチームの担当範囲となりつつあり、ある意味嬉しい状況です。

ただし、色々尖った技術に向き合うにあたって一点、課題があります。

サーバ・ネットワーク仮想化のスキルを持ちつつ、Infrastructure as Codeの理解があるエンジニアは少ない

です。今のチームメンバーは幸いそのようなバックグラウンドを持つ優秀なエンジニア揃いなのですが、将来的にはまだまだ仲間を求めています。

VMwareのソフトウェアスタックに習熟していて、SRE, DevOpsに馴染める人材というのも(意外と)貴重です。インフラエンジニアでSRE, DevOpsに取り組んでみたいという方、ぜひ一緒に働きましょう。

IaaSだけで完結するものでなく、エッジコンピューティングやネットワーク、アプリケーションのポータビリティまで含めた世界を作っていきたいと考えています。

この記事で書ききれなかった技術要素もまたの機会にぜひご紹介します。