長年塩漬け状態にあるAnsibleの運用から脱却するためのCI/CDパイプライン構築

こんにちは、アドプラットフォーム事業で開発運用業務を行っているリードアプリケーションエンジニアのまっちゃん（@honyanyas）です。

この記事の公開日は2025年2月28日です。
何の日でしょうか？そうです、2001年2月28日に設立された株式会社アドウェイズの24周年です。
事業、プロダクト開発、バックオフィス関係なしに全員が新しいことに挑戦・改善をし続けています。
自分自身もまだまだできることはあると思うので、引き続き成果を意識しつつ貢献していきたい所存です。

今回の記事では所属チームがAnsibleのCI/CDパイプラインの構築を整備しなおし、IaCプロセスを改善した事例を簡単に共有いたします。
ぜひAnsibleを導入・運用しているエンジニアの方や開発チームの方に参考にしていただければと思います。

Ansibleの運用状況

所属部署では2017年ごろからAnsibleを導入をしました。
当時は設定ファイルに書かれた機密情報を暗号化するためにAnsible Vaultを利用したデプロイなどを行っていました。

その後、オンプレミスからパブリッククラウドへの移行作業（以下クラウド移行プロジェクト）がはじまりました。
既存リソースを新しい環境へ持っていくために、各種インストール作業や設定反映の手順をコード化をし、資産として活用したいという目的がありました。

1つのロールに2つのプレイブックを作る方針としました。

{ロール名}_install.yml
- 初期構築目的
- 1回のみ実行
- 主に言語やミドルウェアのインストール
{ロール名}_configure.yml
- 運用目的
- 何回も実行する
- 主に設定ファイルの更新、ミドルウェアの再起動

分けることで役割が明確化され、運用時は基本に{ロール名}_configure.ymlを実行すればよい状態となります。

補足：新規で開発するものはコンテナを活用しています。

Ansibleの課題感

なぜこの取り組みを行うことになったのか、課題感を簡単に説明します。

組織として過去に何度かAnsibleをはじめとした構成管理ツールを導入しましたが、運用に対して向き合うことができず、何度も塩漬けにされていました。
塩漬けされているためメンテナンスがされていません。もちろんテストやCI/CDもありません。
そのため開発者体験が悪く、品質担保も難しい状況が続いていたため、開発難易度も非常に上がっていました。

上記のような課題を抱える状況ではプロダクト開発・運用に悪い影響を与えてしまうため、課題解決が必要でした。

取り組んだこと

進め方は以下のように進めました。

キックオフ
あるべき姿を考える
フェーズ分割
実装
レビュー会

進めるにあたって良かったポイントを3つ紹介します。

理想のパイプラインを考える

IaCのあるべき姿について、たたき台を作ってもらい共有の機会をもらいました。
チームとしては先行して必要になるであろうOffline Testsの整備を先に進めていたので解像度がすこし上がっている状態でした。
その上で過去に運用ができていなかった点も実際の体験から議題に上げ、考慮するべき点を洗い出し、あるべき姿を全員で議論して作ることができました。

最初に考えることで他プロジェクトの兼ね合いも踏まえ、どこまで進めるか、という議論もできました。

※実際に議論で使用したPath to Production、雰囲気だけ共有します。

最小限のパイプラインを実現する

初期見積もり時点では複数のシナリオに対してあるべき姿を適用しようとしました。
ですが長年運用しているサービスのため、シナリオ数も多くすべて適用しようとするとクラウド移行プロジェクトをはじめとして中長期のロードマップに影響が出てしまいます。
議論した結果、CI/CDパイプラインを最小の独立したシナリオ（複数プレイブック）で動かすことをまずは目指すことにしました。

最小の独立したシナリオを構築することで、他シナリオの展開もスムーズに行うことができ、クラウド移行プロジェクトにおいても円滑に進めることができるという判断です。
実際にこの判断は正しく、クラウド移行プロジェクトで開発体験を向上したことを実感しました（後述）

知見を持っている第三者からフィードバックをもらう

当初考えていた理想のパイプラインを独立したシナリオ（複数プレイブック）で動かせる見通しがたったタイミングで実施をしました。
社内でAnsibleを積極的に利用しているSREチーム（技術戦略Divはいつも心強いです）のエンジニアに見てもらい、Moleculeでの品質担保の提案をもらいました。

生成AIも頼りながらペアプロの1タームでプロセスを確認するテストを書くことができ、品質向上に繋げることができました。

e.g: Nginxプロセスを確認するverify.yml

---
- name: Verify {Role}
...
  tasks:
    # プロセスを確認
    - name: Check Nginx process
      shell: ps aux | grep -v grep | grep nginx
      register: nginx_process
    # プロセスが存在しているかのチェック
    - name: Assert Nginx is running
      assert:
        that:
          - nginx_process.stdout | length > 0
        fail_msg: "Nginx is not running."