さくらのセキュアモバイルコネクトの 運用に CD の仕組みを導入する話 2023/02/16　開発本部　佐藤 哲也

自己紹介 名前：佐藤 哲也 所属：開発本部 モバイル開発グループ ※ さくらインターネットから出向 ここ最近の活動： 　・CNTOM 2022 でシステム運用について発表しました。 　　URL：https://cntom.jp/program_detail/#s15

本日のお話 さくらのセキュアモバイルコネクトのモバイルコアシステム運用に CD（継続的デリバリー） の仕組みに導入することにした。 導入に関する以下のことを中心にお話します。 　・本番デプロイで失敗しないため、実現したかった２つのこと 　・最終的にどんなシステムとなったのか（社内プルリクこれからです） ※ システム管理・メンテナンスの話が中心です。サービス自体の話は割愛します。 　 参考：さくらのセキュアモバイルコネクトの紹介 URL：https://iot.sakura.ad.jp/sim

そもそも CD（継続的デリバリー）とは ・CI（継続的インテグレーション ） 　　→ 共有されたメインラインにマージ 　　→ 自動ビルド・自動テスト ・CD（継続的デリバリー） 　　→ アプリケーションをいつでもデプロイできる状態にする（直前の状態） 　　→ 上記実現のため、開発環境に自動デプロイメント・自動システムテスト ・継続的デプロイメント 　　→ 本番環境に自動デプロイメント

現在のさくらのセキュアモバイルコネクトの運用 CI は整備されているが、デプロイ作業は手動 　→ 本番環境＆開発環境ともに対象サーバに SSH ログイン & コマンドコピペ 　→ 本番環境へのデプロイは上記 + Wチェック 　→ コンフィグファイル等は一元管理されていない状態 ※ サーバはさくらのクラウド（IaaS）上に構築 < Github > download コンポーネントのリポジトリ ssh & コマンドコピペ 作業端末 開発環境 本番環境

現行の運用に CD を組み込むメリット CD を実現する過程で様々なことが整備される 　→ 各サーバの構成情報を Ansible Playbook として管理 　　　→ Playbook をリポジトリで管理することで一元化可能 　　　→ 本番デプロイを１コマンドで完了できる 　→ デプロイ後の動作は、開発環境で検証済み ansible-playbook < Github > download コンポーネントのリポジトリ 作業端末 開発環境 本番環境 Playbook のリポジトリ 自動デプロイ CD 処理 トリガーとなるイベント（プッ シュ・マージ）

では、その自動化の仕組みは 本番メンテ時に期待した動作をするのか？

完璧な Playbook を作ることの難しさ 過去の API サーバのメンテで一度だけ Ansible Playbook を利用 　→ 実行ファイルの差し替えは無事成功 　→ しかし、NTP クライアントが止まってしまった やってみた感想： Ansible は怖い。

「Ansible は怖い。」と思った理由 Ansible Playbook を採用 　・一回限り・一方通行のシェルスクリプトより相対的に複雑になる 　　　→ 冪等性を意識した記述 　　　　　→ 一方通行のスクリプトより記述量が増える 　　　　　→ Ansible 特有の構文を理解する必要がある 　・開発環境でのテストは適切だったか？ 　　　→ 本番環境で実現すべきことは「状態 A を状態 B にする」なのに、 　　　→ 開発環境でのテストは「状態 A’ を状態 B にする」だったりしてないか 完璧な Ansible Playbook を一発で書けるのだろうか

完璧じゃない Ansible Playbook に備える ・普段から本番デプロイ相当のオペレーションに慣れておく 　→ 開発環境へのデプロイ作業で本番相当の操作を行う ・以前の状態で何度でもテストできる 　→ 各環境（主に開発環境）をある時点の状態に戻せるようにする 一般的な CD の定義にとらわれず、上記のことを容易に実現できる仕組みを整えること にした。

①：開発環境へのデプロイ作業で本番相当の操作を行う 本番デプロイまでにデプロイする機会は何度もある 　１．動作検証デプロイ（期待する動作を確認するまでデプロイ） 　２．Approve 後のデプロイ（本番に適用する実行ファイルの動作確認） 　３．本番環境へのデプロイ 本番デプロイ Approve後の デプロイ 動作検証 デプロイ （N 回目） 動作検証 デプロイ （1 回目） ‥‥‥ 開発環境へのデプロイ 本番環境へのデプロイ

②：以前の状態で何度でもテストできる 「改修前と改修後」の２つ環境情報を用意して切り替えできる仕組みを 改修前（現在）の環境情報 開発 PGW-C ver1.2.3 本番 PGW-C ver1.2.3 開発 HSS ver2.4.5 本番 HSS ver2.4.5 Playbook ver3.6.7 改修後の環境情報 開発 PGW-C ver1.2.4 本番 PGW-C ver1.2.4 開発 HSS ver2.4.5 本番 HSS ver2.4.5 Playbook ver3.6.8 開発環境 本番環境

デプロイ操作はこのぐらいシンプルに デプロイする環境（dev or prod）を選択 実行する Playbook を選択 ※ Playbook はコンポーネントごとに用意 【 update xxx を選択 】 　→ 改修後の Playbook / 実行ファイルが選択 【 revert xxx を選択 】 　→ 改修前の Playbook / 実行ファイルが選択 Web 画面で操作を完結させる。

ここまでのまとめ ・過去の経験（反省）から以下の方針を採用 　→ （教科書的ではないが）開発・本番ともに同じデプロイ方法にする 　→ 改修前後の状態を行き来きできるようにする 上記２つをシンプルな操作で実現できる実装を！

ここからは実装の話

取り入れた技術 　1. デプロイ操作時に簡易な Web 入力フォームを提供するため 　　→ Github Actions Workflow（dispatch） を採用 　2. 改修前 / 改修後の各環境の状態（定義）を表現するため 　　→ git のブランチの動作、git submodle を採用 【利便性を向上させる取り組み】 　3. デプロイ作業の証跡を残すため 　　→ Pull Request を利用 　4. デプロイ前の作業が増えてきたため 　　→ 初期セットアップも Github Actions Workflow を利用

1. Github Actions Workflow による入力フォーム

CD 用リポジトリ（今回新規作成） 2. 改修前後の状態を表現するため git の仕組みを採用 改修前後の状態 　 → git submodule を保持するリポジトリのブランチを管理することで実現 master （改修前） ブランチ 改修後 ブランチ 開発 PGW-C @ 99c4fc5 本番 PGW-C @ 99c4fc5 開発 HSS @ 15899f2 本番 HSS @ 15899f2 Playbook @ b85e456 開発 PGW-C @ 15899f2 本番 PGW-C @ 15899f2 開発 HSS @ 15899f2 本番 HSS @ 15899f2 Playbook @ f7e1beb

3. デプロイ作業の証跡を残すため Pull Request を利用 Ansible の実行ログを参照 実行後のサーバ状態（どの時点の Playbook の状態にあるか）を表示

4. 初期セットアップも Github Actions Workflow を利用 初期セットアップ 　・ CD 用リポジトリにメンテナンスブランチを新規作成 　・ メンテ対象の submodule を更新 　・ メンテナンスブランチに紐づく PR を生成

デプロイ作業フロー まとめ やること Web UI 操作 Pull Request に 投稿されるコメント ブランチ状態 master ブランチ の状態 メンテ ブランチ の状態 本番/開発環境 の状態 初期 ↓ セットアッ プ ↓ ↓ デプロイ ↓ クローズ PGW-C v1.2.3 HSS v2.4.5 PGW-C v1.2.4 HSS v2.4.5 PGW-C v1.2.3 HSS v2.4.5 PGW-C v1.2.3 HSS v2.4.5 PGW-C v1.2.4 HSS v2.4.5 PGW-C v1.2.4 HSS v2.4.5 PGW-C v1.2.4 HSS v2.4.5 PGW-C v1.2.4 HSS v2.4.5 PGW-C v1.2.3 HSS v2.4.5 PGW-C v1.2.3 HSS v2.4.5

実装の話 まとめ ・以下を実現するためシンプルな操作が可能な UI を用意 　→ 開発・本番ともに同じデプロイ方法 　→ 改修前後の状態を行き来きできるようにする ・取り入れた技術として 　→ Github Actions Workflow 　→ git のブランチの仕組み、git submodule 　→ Pull Request

今後の課題 ・総コード量 500 行程度（想定より大きい） ・DB のスキーマ操作を伴うメンテは、コピペになってしまう ・一回の Run に時間がかかる（２ 〜 ５分程度）

No content