Upgrade to Pro — share decks privately, control downloads, hide ads and more …

さくらのセキュアモバイルコネクトの運用に CD の仕組みを導入する話

さくらのセキュアモバイルコネクトの運用に CD の仕組みを導入する話

BBSakura Networks, Inc

February 17, 2023
Tweet

More Decks by BBSakura Networks, Inc

Other Decks in Technology

Transcript

  1. そもそも CD(継続的デリバリー)とは ・CI(継続的インテグレーション )   → 共有されたメインラインにマージ   → 自動ビルド・自動テスト ・CD(継続的デリバリー)   →

    アプリケーションをいつでもデプロイできる状態にする(直前の状態)   → 上記実現のため、開発環境に自動デプロイメント・自動システムテスト ・継続的デプロイメント   → 本番環境に自動デプロイメント
  2. 現在のさくらのセキュアモバイルコネクトの運用 CI は整備されているが、デプロイ作業は手動  → 本番環境&開発環境ともに対象サーバに SSH ログイン & コマンドコピペ  →

    本番環境へのデプロイは上記 + Wチェック  → コンフィグファイル等は一元管理されていない状態 ※ サーバはさくらのクラウド(IaaS)上に構築 < Github > download コンポーネントのリポジトリ ssh & コマンドコピペ 作業端末 開発環境 本番環境
  3. 現行の運用に CD を組み込むメリット CD を実現する過程で様々なことが整備される  → 各サーバの構成情報を Ansible Playbook として管理

       → Playbook をリポジトリで管理することで一元化可能    → 本番デプロイを1コマンドで完了できる  → デプロイ後の動作は、開発環境で検証済み ansible-playbook < Github > download コンポーネントのリポジトリ 作業端末 開発環境 本番環境 Playbook のリポジトリ 自動デプロイ CD 処理 トリガーとなるイベント(プッ シュ・マージ)
  4. 完璧な Playbook を作ることの難しさ 過去の API サーバのメンテで一度だけ Ansible Playbook を利用  →

    実行ファイルの差し替えは無事成功  → しかし、NTP クライアントが止まってしまった やってみた感想: Ansible は怖い。
  5. 「Ansible は怖い。」と思った理由 Ansible Playbook を採用  ・一回限り・一方通行のシェルスクリプトより相対的に複雑になる    → 冪等性を意識した記述      → 一方通行のスクリプトより記述量が増える

         → Ansible 特有の構文を理解する必要がある  ・開発環境でのテストは適切だったか?    → 本番環境で実現すべきことは「状態 A を状態 B にする」なのに、    → 開発環境でのテストは「状態 A’ を状態 B にする」だったりしてないか 完璧な Ansible Playbook を一発で書けるのだろうか
  6. ②:以前の状態で何度でもテストできる 「改修前と改修後」の2つ環境情報を用意して切り替えできる仕組みを 改修前(現在)の環境情報 開発 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 開発環境 本番環境
  7. デプロイ操作はこのぐらいシンプルに デプロイする環境(dev or prod)を選択 実行する Playbook を選択 ※ Playbook はコンポーネントごとに用意

    【 update xxx を選択 】  → 改修後の Playbook / 実行ファイルが選択 【 revert xxx を選択 】  → 改修前の Playbook / 実行ファイルが選択 Web 画面で操作を完結させる。
  8. 取り入れた技術  1. デプロイ操作時に簡易な Web 入力フォームを提供するため   → Github Actions Workflow(dispatch) を採用

     2. 改修前 / 改修後の各環境の状態(定義)を表現するため   → git のブランチの動作、git submodle を採用 【利便性を向上させる取り組み】  3. デプロイ作業の証跡を残すため   → Pull Request を利用  4. デプロイ前の作業が増えてきたため   → 初期セットアップも Github Actions Workflow を利用
  9. 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
  10. 4. 初期セットアップも Github Actions Workflow を利用 初期セットアップ  ・ CD 用リポジトリにメンテナンスブランチを新規作成

     ・ メンテ対象の submodule を更新  ・ メンテナンスブランチに紐づく PR を生成
  11. デプロイ作業フロー まとめ やること 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