TechDojo_20210929_OpenShiftアプリ構築デモ

OpenShiftアプリの構築と監視デモ( https://ibm-developer.connpass.com/event/224521/) での「OpenShiftへのアプリのデプロイデモ」セッションの資料です。

本資料の掲載内容は私自身の見解であり、必ずしも所属する会社の立場、戦略、意見を代表するものではありません。

Transcript

1. 5FDI
   %PKP
   0QFO4IJGU 0QFO4IJGUΞϓϦͷߏஙσϞ • ෳ਺ΦϒδΣΫτ %FQMPZNFOU 4UBUFGVM4FU౳ ͷ૊Έ߹Θͤ • ෳ਺؀ڥͰͷ։ൃํ๏ ೥݄೔
2. 1. CI/CD CI/CDͱ͸ S2IͱGitHub Webhooks 2
3. 1. CI/CDとは 3 継続的インテグレーション/継続的デリバリー/継続的デプロイメント n アプリケーション開発に⾃動化を取り⼊れて、システム利⽤者(エンドユーザ)にアプリケーションを 提供する頻度を⾼める⼿法です。 n CI/CD によって、機能間結合やテストのフェーズからデリバリー、デプロイメントに⾄る、アプリ ケーションのライフサイクル全体を通じて、継続的な⾃動化と継続的な監視が導⼊されます。 n これらはまとめて「CI/CD パイプライン」と呼ばれ、アジャイルな⽅法で開発チームと運⽤チームが 共同で実施します。 ビルド テスト CI (継続的インテグレーション) マージ CD (継続的デリバリー) CD (継続的デプロイメント) 実⾏環境へ ⾃動リリース リポジトリへ ⾃動リリース
4. 1. CI/CD⼿法 4 OpenShiftでは様々なCI/CD⼿法が提供されています。 1. OpenShiftが提供する最新CI/CD OpenShift 4.8 (7/28リリース) で⼀般公開(GA)された新CI/CDツールです。 • OpenShift Pipelines (Tekton) • OpenShift GitOps (ArgoCD) 2. GitHubを使ったCD 最もシンプルな⽅法です。 OpenShift Source to Image(S2I)とGitHub Webhooksを連携してCDを実現する⽅法をご紹介します。 少⼈数でのプロジェクトや、ごく短期間に構築するような要件がある場合はこちらをご検討ください。 OpenShift 4.8 2021/07/28リリース https://speakerdeck.com/redhatopenshift/whats-new-in-openshift-4-dot-8 Red Hat OpenShift on IBM Cloudは9/10現在、4.8未対応 こちらは、今後ハンズオンを 企画させていただく予定です。 今回のデモはこちらを 実施します。
5. 1. GitHubを使ったCD – S2Iとは 5 n Source to Image(S2I) ①「Red Hatが⽤意したアプリケーション環境(Dockerイメージ)」と ②「ソースコード」を組み合わせてビ ルド、コンテナイメージを作成しOpenShift上にデプロイ(③)する機能 ① ② ③ Red Hatが⽤意 (カスタムイメージを定義 することも可能です) みなさまが⽤意 (OpenShiftからHTTPSアクセス できる場所にある必要があります) Kubernetesなどの場合、ソースコード管理とは別に コンテナイメージをイメージレジストリに都度コミッ トする必要がありました。 S2Iではこの作業を省き、ソースコードだけでコンテ ナを作ることができます。これにより、開発⽣産性を 向上させることができます。
6. 1. GitHubを使ったCD – S2IとGitHub Webhooks 6 n GitHub Webhooks ソースコードに変更が⽣じた際に、 外部Web APIに変更情報を通知する機能 ⇒CD(継続的デプロイメント)を実現可能 GitHub ① push Webhoo k API ②呼出 ④ 取 得 ③ 実 ⾏ 最新ソースコードで ビルド&デプロイ アプリケーションが 置き換えられる OpenShift 開発者がソース コードをgit push するだけ OpenShiftが最新ソースコードを取得し、 ⾃動的にS2Iによるビルド、デプロイ (アプリ置き換え)が⾏われる GitHubがOpenShift のWebhook APIを 呼び出すことで… ⑤ ⑥ CI(継続的インテグレーション)はローカルで、もしく はJenkins などのCIツールを使って実⾏します。
7. 2. 検証環境と本番環境の複数 構成の場合 7
8. 2. 検証環境と本番環境の複数構成の場合 8 GitHubを使ったCDを実施する場合、OpenShift環境が1つの場合は、前章で説明した以下の⽅式を⽤いるこ とで実現可能です。 では、本番環境や検証環境、開発・テスト環境など複数の環境がある場合は、 どのように運⽤すればよいのでしょうか? GitHub push WebHoo k API 呼出 取 得 実⾏ 最新ソースコードで ビルド&デプロイ アプリケーションが 置き換えられる OpenShift 開発者がソース コードをgit push するだけ OpenShiftが最新ソース コードを取得し、⾃動的 にS2Iによるビルド、デ プロイ (アプリ置き換 え)が⾏われる GitHubがOpenShiftのWebHook APIを呼び出すことで…
9. 2. 検証環境と本番環境の複数構成の場合 9 n ⽅法︓Gitブランチ戦略を採⽤し、環境ごとに参照するブラ ンチを切り替える – 環境ごとにOpenShiftが参照するGitリポジトリのブランチ を切り替える⽅法 • 例) 本番環境はproductionブランチ、検証環境はpre-production ブランチ、開発環境はmasterブランチ… n ブランチ戦略にはGit flow、GitHub flow、GitLab flowなど様々な⼿ 法が提案されています。プロジェクトの規模や要件にあわせ最適な⽅ 法を検討ください。 • 参考(1) GitLab Introduction to GitLab Flow︓ https://docs.gitlab.com/ee/topics/gitlab_flow.html • 参考(2) エクサウィザーズ社 Engineer Blog︓ https://techblog.exawizards.com/entry/2021/01/21/111031 参考) https://docs.gitlab.com/ee/topics/gitlab_flow.html 検証環境 本番環境 開発環境 Gitリポジトリ 環境ごとに、 参照するブラ ンチを切替 参照branch: master 参照branch: pre-production 参照branch: production
10. 2. GitHub WebhooksによるCD 10 GitHubのWebhooksは、各ブランチではなく、リポジトリに対して設定を⾏います。 GitHubのWebhooksは、ブランチとは無関係にGitHubに対するイベント(pushなど)を拾ってWebhooksに設定された外部URLに イベント内容を通知します。 GitHub 検証環境 ブランチに push Webhook API 呼出 実⾏ OpenShift 検証環境 本番環境 – OpenShiftはWebhooksイベントを処理する場 合に、イベント内のブランチ参照が、対応の BuildConfigのブランチ参照と⼀致しているか どうかを確認します。 – ⼀致する場合には、OpenShift Container Platform ビルドの Webhook イベントに記載 されているのと全く同じコミット参照がチェッ クアウトされます。⼀致しない場合には、ビル ドはトリガーされません。 検証環境ブランチが 変更されたことを通知 Gitリファ レンスと ⼀致するこ とを確認 最新ソース取得 Webhook API 呼 出 Gitリファレ ンスと ⼀致しない ことを確認 検証環境ブラン チが変更された ことを通知
11. 3. S2Iを使った サンプルアプリのデプロイ - 説明 - 11
12. 3. S2Iを使ったサンプルアプリのデプロイ © 2021 IBM Corporation n 環境 – 本来、検証環境と本番環境は全く別の環境で準備されますが、今回はOpenShiftの「Project」を使って 1つの環境(クラスタ)に、擬似的に複数の環境を構築します。 n アプリ概要説明 n デモ 1. 事前準備 2. 検証環境デプロイ • MongoDBの作成 • Python Flaskで構築された WebAPIアプリのs2iデプロイ • Reactで構築された WebUIアプリのs2iデプロイ 3. 本番環境デプロイ 4. GitHub Webhooks設定 • 本番/検証環境 5. ソースコードの変更とマージ、CD動作確認 • masterのソースコード変更と検証ブランチへのマージ、アプリ更新確認 • 本番ブランチへのマージ、アプリ更新確認 12
13. 3. [アプリ概要] アプリケーションアーキテクチャ概要 © 2021 IBM Corporation 13 n 右の3つの要素は、以下のやり取 りを⾏います。 ① ユーザは画⾯を操作して、アカウン トの新規作成/ログイン/パスワード リセットを⾏うことができます。 ユーザはログイン後、作業ログを表 ⽰、追加、編集できます。 ② UIは、Reactを通じて処理されます。 Reactは、API呼び出しが初期化さ れる場所です。 ③ API呼び出しは、Kubernetesの Flask APIマイクロサービスで処理 されます。 ④ データは、API呼び出しを通して MongoDBに保存、または変更され ます。 ⑤ API呼び出しは、UIを通して処理さ れます。 Reactで構築され たUIWebアプリ Python Flaskで 構築された WebAPIアプリ WebAPIアプリか らアクセスされる、 ユーザデータを保 存するMongoDB 注) 本資料はアプリをOpenShiftにデプロイする⼿順とCI/CDの設定⼿順の確認を主眼とするため、これ以上アプリケーション内部構造については触れません。 ご興味のある⽅はGitHubのソースコードをご参照いただき、⾃習ください。 •Microservices: 軽量プロトコルを使⽤して、クラウド内の最新のアプリケーション構成で ビルディングブロックを提供する、きめ細かい、緩く結合されたサービス の集合です。 •Python: Pythonは、より迅速に作業し、システムをより効果的に統合できるプログラミン グ⾔語です。 •Flask: WebAPIを構築するためのPythonのマイクロフレームワークです。 •React: ユーザインターフェイスを構築するためのJavaScriptライブラリです。 •MongoDB: ドキュメント志向 NoSQLデータベースです。
14. 3. S2Iを使った サンプルアプリのデプロイ - デモ - © 2021 IBM Corporation 14
15. 3.1. GitHubブランチ / OpenShiftプロジェクト n GitHub: https://github.com/ibmjpcsmdemo1/worklog 1. 開発環境 – masterブランチ 2. 検証環境 – pre-productionブランチ 3. 本番環境 – productionブランチ n OpenShift 1. 開発環境 – developmentプロジェクト 2. 検証環境 – pre-productionプロジェクト 3. 本番環境 – productionプロジェクト 15 今回はpre-productionプロジェクトのみ 作成します。 (development/productionプロジェクトは作成済み) 今回はfork, ブランチ は作成済みです。
16. 3.1 [デプロイ] 永続化ボリュームとMongoDBの作成 16 n 永続化ボリュームとMongoDBの作成 deploy-mongodb.ymlにはMongoDBをコンテナ として公開するための設定が記述されています。 設定内容は – PersistentVolumeClaim(永続化ボリューム) – StatefulSet – Service の3つが記述されています。 ocコマンドで導⼊してみます。 以下のコマンドとなります。 oc create –f deploy-mongodb_ss.yml
17. 3.1 [デプロイ] Python Flaskで構築された WebAPIアプリのs2iデプロイ 17 mongoDBを参照するPython Flask WebAPIアプリをデプロイします。 n S2Iでデプロイ n 参照先はpre-productionブランチ
18. 3.1 [デプロイ] Reactで構築された WebUIアプリのs2iデプロイ 18 WebAPIアプリを参照するWebUIアプリをデプロイします。 n S2Iでデプロイ n 参照先はpre-productionブランチ n WebAPIアプリを参照するために、WebAPIアプリのURLをEnv変数 「REACT_APP_APP_SERVER」にセット 変数︓REACT_APP_APP_SERVER にこのURLを設定 /web/worklog/src/App.js
19. 3.2 [デプロイ] アプリケーションの動作確認 19
20. 3.3. GitHub Webhooksによ るCD 20
21. 3.3 GitHub WebhooksによるCD 21 開発環境、本番環境、検証環境のworklog-api/worklog-uiのそれぞれでwebhookを設定します。 全部で6つ
22. 3.3 GitHub WebhooksによるCD 22 n 開発環境(masterブランチ)へのソース コード修正
23. 3.3 GitHub WebhooksによるCD 23 n developmentプロジェクトのみ更新が適⽤されて いること Project「pre-production」「production」は 「master」ブランチでの変更イベントを受信しても 新たなビルドは実⾏しません。 ⇒検証環境や本番環境は、開発環境での変更の影響 を受けません。 23 参考) https://docs.gitlab.com/ee/topics/gitlab_flow.html 検証環境 本番環境 開発環境 Gitリポジトリ 参照branch: master 参照branch: pre-production 参照branch: production
24. 3.3 GitHub WebhooksによるCD 24 n 検証環境(pre-productionブランチ)へのソースコードマージ masterブランチで Create Pull Request pre-production ブランチで Merge Pull Request OpenShiftの pre-production プロジェクトで 自動ビルドが実行
25. 3.3 GitHub WebhooksによるCD 25 n pre-productionプロジェクトのみ更新が適⽤され ていること 25 参考) https://docs.gitlab.com/ee/topics/gitlab_flow.html 検証環境 本番環境 開発環境 Gitリポジトリ 参照branch: master 参照branch: pre-production 参照branch: production
26. 3.3 GitHub WebhooksによるCD 26 n 本番環境(productionブランチ)へのソースコードマージ pre-production ブランチで Create Pull Request production ブランチで Merge Pull Request OpenShiftの production プロジェクトで 自動ビルドが実行
27. 3.3 GitHub WebhooksによるCD 27 n productionプロジェクトのみ更新が適⽤されてい ること 27 参考) https://docs.gitlab.com/ee/topics/gitlab_flow.html 検証環境 本番環境 開発環境 Gitリポジトリ 参照branch: master 参照branch: pre-production 参照branch: production