OpenShift_BootCamp_2章デプロイ

Transcript

1. OpenShift Boot Camp OpenShift入門コース 2章 デプロイ Tech Dojo
2. 目次 © 2021 IBM Corporation 2 2-1. OpenShiftでのアプリのデプロイ（講義） 2-2. 演習の準備 2-3. 演習 1. S2Iで検証環境にデプロイ 2-4. 演習 2. GitHubとの連携 オプションの演習（演習時間に余裕のある方は実施してください） オプション演習1. Dockerイメージを使ったデプロイ オプション演習2. 本番環境でのS2Iデプロイ
3. 2-1. OpenShiftでのアプリのデプロイ（講義） © 2021 IBM Corporation 3
4. OpenShift：アプリの新規作成 © 2021 IBM Corporation 4 ◼ [+追加]メニュー画面
5. OpenShiftでのアプリデプロイ方法 © 2021 IBM Corporation 5
6. GitHubを使ったデプロイ – S2I(Source to Image)とは 6 ①Red Hatが用意したアプリ環境(Dockerイメージ) ＋ ③ OpenShift上にデプロイ ②ソースコード ① ② ③ Red Hatが用意 みなさまが用意 S2Iではソースコードだけで コンテナを作成しデプロイまで 1アクションで実行可能 © 2021 IBM Corporation ビルド
7. GitHubを使ったCD – S2IとGitHub Webhooks © 2021 IBM Corporation 7 ◼ GitHub Webhooks ソースコードに変更が生じた際に、 外部Web APIに変更情報を通知する機能 ⇒CDを実現可能 GitHub Webhook API ③ 実 行 最新ソースコードで ビルド&デプロイ アプリケーションが 置き換えられる OpenShift 開発者が ソースコードを git pushするだけ OpenShiftが最新ソースコードを取得し、 自動的にS2Iによるビルド、デプロイ (アプリ置き換え)が行われる GitHubがOpenShiftの Webhook APIを 呼び出すことで… ⑤ ⑥
8. 検証環境と本番環境の複数構成の場合 © 2021 IBM Corporation 8 ◼ 方法：Gitブランチ戦略を採用し、環境ごとに参照する ブランチを切り替える – 環境ごとにOpenShiftが参照するGitリポジトリのブランチ を 切り替える • 例) 本番環境はproductionブランチ、検証環境は pre-productionブランチ、開発環境はmasterブランチ… ◼ ブランチ戦略には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
9. 2-2. 演習の準備 © 2021 IBM Corporation 9
10. [アプリ概要] 作業ログアプリケーション - Work Log © 2021 IBM Corporation 10 ◼ Flask、MongoDB、Kubernetesを使用して「作業ログ(Work Log)」Webアプリを作成します。 ◼ 作業ログアプリケーションは、以下に示す作業者の日勤状況を記録・追記することができます。 – オフィス勤務 – テレワーク(リモートワーク) – 休暇 – 休日 – 病欠 ◼ ここでは、以下の作業を行います。 – Python Flask アプリケーションを作成する – MongoDBをPythonアプリケーションに組み込む – OpenShift上にマイクロサービスを デプロイし実行する
11. アプリケーション全体像 © 2021 IBM Corporation 11 Reactで構築された WebUIアプリ Python Flaskで 構築された WebAPIアプリ WebAPIアプリから アクセスされる、 ユーザデータを 保存するMongoDB
12. 演習概要：S2Iを使ったサンプルアプリのデプロイ © 2021 IBM Corporation ◼ 環境 – 本来、検証環境と本番環境は全く別のクラスタで作成する方法もありますが、今回はOpenShiftの「プロジェクト」を使って 1つのクラスタに複数の環境を構築します。 本番環境の構築はオプション（オプション演習2.）とします。時間に余裕のある人は試してみてください。 ◼ 演習の流れ 2-2. 準備 2-3. 検証環境デプロイ • MongoDBの作成（公開されているイメージの取り込み） • Python Flaskで構築された WebAPIアプリのS2Iデプロイ • Reactで構築された WebUIアプリのS2Iデプロイ 2-4. GitHubとの連携 • 検証環境のGitHub Webhooks設定 • ソースコードの変更とマージ、CD動作確認 オプション演習2. 本番環境デプロイ • 本番環境へのデプロイ • 本番ブランチへのマージ、アプリ更新確認 12
13. 演習注意事項 © 2021 IBM Corporation 13 ◼ 演習では、「GitHub」画面と「OpenShift Webコンソール」画面を操作します。 どちらの画面か迷わない様に、それぞれの画面左上にアイコンが付けてあります。 GitHub OpenShift Webコンソール
14. [準備] ハンズオンラボ環境の利用設定 © 2021 IBM Corporation 14 1. ハンズオンラボにアクセスし、Key、IBMidを入力してSubmit – URL：チャット欄に貼り付けられたもの – Lab Key：oslab 2. 「Account: You are invited to join an account in IBM Cloud」という件名のE-mail受信 3. ”Join Now”をクリック 4. “アカウントに参加”をクリック 5. ログイン 6. 右上が「（7桁の番号）-Advowork」となっていることを確認。 – なっていなければ、「ｖ」をクリックして選択。
15. [準備] IBM CloudからのOpenShiftへのログイン © 2021 IBM Corporation 15 IBM Cloudにログイン後、 トップ画面左上のナビゲーション・ メニューボタンを押下 リストから「OpenShift」を選択 「クラスター」を選択 tokyo-oslab-xxxxを選択 （xxxxはランダムな英数字） 「OpenShift Webコンソール」を 押下 https://cloud.ibm.com/
16. [準備] プロジェクトの作成 © 2021 IBM Corporation 16 ◼ プロジェクトの作成 検証環境「pre-production」と 本番環境「production」を用意します。 ① [管理者]パースペクティブにて [プロジェクト]を選択し、 [Projectの作成]ボタンをクリックします。 ② ダイアログが表示されたら、プロジェクトを 作成します。 ⚫ プロジェクト名は 「 pre-production 」で作成 ⚫ 本番環境も同様に、プロジェクト名を 「 production 」にして作成 ③ プロジェクト一覧から [pre-production ]リンクを選択します。 これにより、今後作成するオブジェクトは pre-productionプロジェクトのオブジェクトとなります。 pre-production production
17. [準備] GitHubのfork © 2021 IBM Corporation ◼ GitHub上でブランチの作成、編集（push/merge）を おこなっていただきます。 ① GitHubアカウントを作成してください。(無料です) – GitHubアカウントの作成方法 (2021年版) https://qiita.com/ayatokura/items/9eabb7ae20752e6dc79d ② 作成したGitHubアカウントに以下のリポジトリをforkしてください。 – https://github.com/tty-kwn/worklog 注) 上記で参照するQiita記事、及びGitHubリポジトリはすべてIBM社員が作成しています。 自身のアカウントのGitHubアカウントページ に移動し、リポジトリ「worklog」が できていることを確認します。 下記の「ibmjpcsmdemo1」の部分が自身の アカウント名になっているのを確認します。 17 Forkを クリック
18. [準備] ブランチ作成 © 2021 IBM Corporation ◼ GitHub上でブランチの作成、編集（push/merge）をおこなっていただきます。 ③ 開発環境、検証環境、本番環境を意識したブランチを新しく作成します。 – デフォルトはmasterブランチです。pre-production, productionブランチを作成します。 18 Gitリポジトリ 検証環境用 本番環境用 注) 本番環境はオプション演習2.でのみ使用となりますが、理解の為にここで作成しておきます。
19. 注意点 © 2021 IBM Corporation 19 本日の演習では、MongoDBを永続化(外部ディスク)させない方法でデプロイ します。資料は永続化方法で作成しているため、皆さまが作成されたものと 画面表示が異なります。 資料：永続化方式 本日の演習：非永続化
20. 2-3. 演習 1. S2Iで検証環境にデプロイ © 2021 IBM Corporation 20
21. MongoDBの作成 © 2021 IBM Corporation 21 ◼ MongoDBの作成 MongoDBは、Docker Hubに公開されている イメージを取り込んでデプロイします。 GitHubのworklogにあるdeploy-mongodb.ymlには MongoDBをコンテナとしてデプロイするための 設定が記述されています。 設定内容は、 ① Deployment ② Service の2つが記述されていますので、テキストエディタや Webブラウザなどでファイルを開き、それぞれを コピーしていきます。詳細な手順は次ページを参照 してください。
22. MongoDBの作成：Deploymentの作成 © 2021 IBM Corporation 22 ◼ Deploymentの作成 MongoDB用のDeploymentを作成します。 次ページへ続く ① 事前に、deploy-mongodb.ymlから apiVersion: apps/v1と記載された箇所を エディターなどにコピーしておきます。 (17行目以下、最後まで) ② OpenShiftのWebコンソールから、 [管理者]パースペクティブを選択し、 [ワークロード] → [デプロイメント]を 選択します。 ③ 右上の[Deploymentの作成]ボタンを クリックし、「Create Deployment」 画面を表示します。 deploy-mongodb.yml ①17行目から 最下部まで ②OpenShiftの Webコンソール ③
23. MongoDBの作成：Deploymentの作成 © 2021 IBM Corporation 23 ◼ Deploymentの作成 続き ④ 「Create Deployment」画面のエディター欄に初期状態で記載されている内容を削除します。 deploy-mongodb.ymlからコピーしたテキストをそこに貼り付けて[作成]ボタンをクリックします。 これで、MongoDBが作成されました。 ④上書きして [作成]実施
24. MongoDBの作成：Serviceの作成 © 2021 IBM Corporation 24 ◼ Serviceの作成 続けて、Serviceを作成します。 ① 事前に、deploy-mongodb.ymlから 2行目 apiVersion: v1と記載された箇所から 15行目までコピーしておきます。 (---で囲まれた箇所です) ② OpenShiftのWebコンソールから、 [管理者]パースペクティブを選択し、 [ネットワーク] → [サービス]を選択します。 ③ [Serviceの作成] ボタンをクリックし、 「Create Service」画面を表示します。 deploy-mongodb.yml 次ページへ続く ②OpenShiftの Webコンソール ③ ①この部分 のみコピー
25. MongoDBの作成：Serviceの作成 © 2021 IBM Corporation 25 ◼ Serviceの作成 続き ④ 「Create Deployment」画面のエディター欄に初期状態で記載されている内容を削除します。 deploy-mongodb.ymlからコピーしたテキストをそこに貼り付けて[作成]ボタンをクリックします。 これで、mongoDBを他のアプリから参照可能となりました。
26. Python Flaskで構築された WebAPIアプリのS2Iデプロイ © 2021 IBM Corporation 26 ◼ mongoDBを参照するPython Flask WebAPIアプリをデプロイします。 手順は以下のとおりです。 ① [Developer]パースペクティブのトポロジーを選択し、「mongo」が青丸で表示されていることを確認します。 ② [+追加] [ソース: Git]を選択します。 「mongo」が濃い青丸で 表示されていることを確認
27. Python Flaskで構築された WebAPIアプリのS2Iデプロイ © 2021 IBM Corporation 27 ③ gitリポジトリURLを取得します。GitHubの画面で[code]ボタンをクリックし「HTTPS」タブに書かれたURLの右側にある コピーボタンをクリックします。 ④ OpenShiftのWebコンソール画面に戻り「Git リポジトリー URL」に、コピーしたgitリポジトリURLを貼り付けます。 ⑤ [詳細の Git オプションの表示]リンクをクリックし、表示された「Git リファレンス」に「pre-production」 (本番環境の場合は「production」)を入力します。 ③GitHub画面 ④⑤OpenShiftの Webコンソール画面
28. Python Flaskで構築された WebAPIアプリのS2Iデプロイ © 2021 IBM Corporation 28 ⑥ 「ビルダーイメージ」で[Python]を選択します。 ⑦ 「アプリケーション名」に「worklog」を、「名前」には「worklog-api」を入力します。 ⑧ [ルーティング]リンクをクリックします。「ターゲットポート」に「5000」を入力し[Create “5000”]を選択します。 ⑨ [作成]ボタンをクリックします。 これで、Python Flask WebAPIアプリのデプロイが開始されました。
29. S2Iデプロイについて補足 © 2021 IBM Corporation 29 (A)で書かれているのは 「アプリケーション」を 意図しており、Deployment などのオブジェクトを グルーピングする概念です。 先程の設定画面にて、 「アプリケーション名」で指定した 「worklog」が表示されていることを 確認することができます。 (同じく 設定した「名前」は、Deploymentの Name、「worklog-api」になります) Kubernetesに慣れた方は、Dockerリポジトリを通さずにソースコードを直接デプロイ できることに驚かれたのではないでしょうか。 これがOpenShiftの利点の1つ、S2I(source to image)機能です。
30. 2つのコンテナを1つのApplicationにマージ © 2021 IBM Corporation 30 ◼ 「(D)mongo」をShift+ドラッグで「worklog-api」に移動し同じApplicationに属させます。 – オブジェクトが多くある場合はこのようにApplicationで区分けすると見やすくなります。 (システムの動作自体には影響のない作業です) – 操作は下記です。下記は、動画になっています。クリックして再生してください。 動画が再生できない場合は、資料と一緒に配布されている「OpenShiftCamp010.mov」をダウンロードして再生してください。
31. S2Iデプロイについて補足 © 2021 IBM Corporation 31 ビルド完了後のアプリログは 「Pods」にある[View logs]という リンクをクリックすることで 動作ログを確認することができます。 「Builds」には「Build #n is xxxx」とい う ビルド状況が表示されています。また、 [View logs]というリンクがあるので、 クリックすることでビルドログを 確認することができます。 Deploymentの項目を クリックして表示
32. Reactで構築された WebUIアプリのS2Iデプロイ © 2021 IBM Corporation 32 ◼ WebAPIアプリを参照するWebUIアプリをデプロイします。 手順は以下のとおりです。 ① [Developer]パースペクティブを選択し、 [トポロジー]を選択します。 ② WebAPIアプリ(worklog-api)をクリックし、 Resourcesタブの最下部にあるRoutesから、 Location URLをコピーします。 コピーしたURLはテキストエディタなどに 退避します(後で使います)。 ③ 左のメニューから[+追加]を選択し、 [ソース: Git]を選択します。 URLをコピーし、 テキストエディタ等に コピーしてください。
33. Reactで構築された WebUIアプリのS2Iデプロイ © 2021 IBM Corporation 33 ④ gitリポジトリURLを取得します。GitHub画面の[code]ボタンをクリックし「HTTPS」タブに書かれたURLの右側にあるコ ピーボタンをクリックします。 ⑤ OpenShiftのWebコンソール画面に戻り、「Git リポジトリーURL」に、コピーしたgitリポジトリURLを貼り付けます。 ⑥ [詳細の Git オプションの表示]リンクをクリックし、表示された「Git リファレンス」に「pre-production」 (本番環境の場合は「production」)を入力します。 ⑦ WebUIアプリはアプリケーションルートが(gitリポジトリルート)/web/worklogです。「コンテキストディレクトリー」に 「/web/worklog」を指定します。 web/worklog
34. Reactで構築された WebUIアプリのS2Iデプロイ © 2021 IBM Corporation 34 ⑦ 「ビルダーイメージ」で[Node.js]を選択します。 ⑧ 「アプリケーション名」に「worklog」を、「名前」には「worklog-ui」を入力します。 ⑨ [ルーティング]リンクをクリックします。「ターゲットポート」に「3000」を入力し[Create “3000”]を選択します。 worklog-ui 3000 3000
35. Reactで構築された WebUIアプリのS2Iデプロイ © 2021 IBM Corporation 35 ⑩ [デプロイメント]リンクをクリックします。ここでは環境変数を指定できます。 このアプリでは内部でREACT_APP_APP_SERVERという変数をWebAPIサーバのURLとして利用しています。 「名前」には「REACT_APP_APP_SERVER」、「値」には②で保存しておいたURLをペーストします。 ⑪ 画面下部の[作成]ボタンをクリックします。 これで、 Reactで構築された WebUIアプリのデプロイが開始されました。
36. アプリケーションの動作確認 © 2021 IBM Corporation 36 ① [Developer]パースペクティブで[トポロジ]を選択します。 ② [worklog-ui]を選択し、「Routes」のLocationURLをクリックします。 アプリが開きます
37. アプリケーションの動作確認 © 2021 IBM Corporation 37 ① Welcome画面にて[Create Account]をクリックし、Create Account画面を表示します。 ② ユーザ名（自分の名前）、好きなパスワードを入力し、[Create]をクリックします。WorkLog本画面に遷移すれば アプリケーションはデプロイ成功です。 ③ WorkLog画面では作業ログを入力することができます。これらの情報はMongoDBに保存されています。 ④ ログアウトします。 入力値がカレンダー に反映されます。 日付を選択し、 項目を入力して [Update」を クリック
38. アプリケーションの動作確認 © 2021 IBM Corporation 38 ④ Login画面で先程作成したユーザ・パスワードでログインします。([Login]ボタンをクリックします) ⑤ 先程入力した情報が再度表示されることを確認します。
39. 2-4. 演習 2. GitHubとの連携 © 2021 IBM Corporation 39
40. GitHub Webhooks設定 © 2021 IBM Corporation 40 ◼ OpenShiftのWebhook URLの取得 – 「管理者」パースペクティブから[ビルド]の[ビルド設定]を選択し、右側のワークスペースに表示される [worklog-ui]をクリックします。 – 画面で下にスクロールして一番下「GitHub」の右の[Copy URL with Secret]をクリックし、WebhookのURLと Secretの内容をエディターなどにコピーしてください。 – [worklog-api]でも同様の操作を行います。
41. GitHub Webhooks設定 © 2021 IBM Corporation 41 ◼ GitHubにWebhookを設定 ① GitHubの自分のリポジトリーへ戻り、[Settings] -> [Webhooks] -> [Add webhook]を選択します。 ② 先ほどクリップボードにコピーしたURL+secretを[Payload URL]に貼り付けてください。[Control type]は[application/json] を選択してください。 ③ [Add webhook]ボタンをクリックします。
42. GitHub Webhooks設定 © 2021 IBM Corporation 42 検証環境のworklog-apiとworklog-uiのそれぞれの設定をおこなってください。 完了すると、下図のように２つのWebhooks設定が並びます。 これでwebhookの設定は完了です。 後はソースコードの修正で自動的に アプリケーションがデプロイされます。
43. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 43 ◼ 開発環境(masterブランチ)へのソースコード修正 ① GitHubの自分のリポジトリーへ戻り、masterブランチのソースコードを直接編集します。[<>Code] 配下でブランチ選択が 「master」になっていること(masterに✓が表示されていること)を確認します。
44. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 44 ② 表示されている項目から、web/worklog -> src -> components -> Welcome.js を選択します。 ③ ソースコード画面右上の鉛筆マークをクリックします。
45. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 45 ④ 12行目、「Welcome」という文言をお好きな 文字列に変更します。 ⑤ 画面下側に移動し、「Commit Changes」の箇所に わかりやすいコメントを入れて[Commit Changes] ボタンをクリックします。
46. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 46 ⑥ GitHubの自分のリポジトリーへ戻り、[Settings] -> [Webhooks] にて設定済みのWebhooks URLをクリックします。 ⑦ [Recent Deliveries]タブを選択し、コミットした時間にWebhooksが実行されたことを確認します。 2つすべてで実行されて いることが確認できます。
47. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 47 ◼ 開発環境(masterブランチ)変更後のOpenShift側でビルドが実行されていないことを確認 ① Project「pre-production」にて、トポロジー上で worklog-ui, worklog-apiをそれぞれクリックし、Buildsに新しい ビルドが実施されていないことを確認します。 ビルドの番号が更新 されていません。 Project「pre-production」に配置されたアプリは GitHubの「pre-production」ブランチを参照する 設定を行っているため、「master」ブランチでの 変更イベントを受信しても新たなビルドは実行 しません。 ⇒ 検証環境や本番環境は、開発環境での変更の 影響を受けません。
48. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 48 ◼ 検証環境(pre-productionブランチ)へのソースコードマージ ① GitHubの自分のリポジトリーへ戻り、masterブランチの変更をpre-productionに反映します。 [Pull requests] 配下で[New pull Request]をクリックします。
49. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 49 ② （重要）「base repository」の箇所を、自分の リポジトリに変更します。 (forkしている場合は、fork元が自動選択されて しまうため、手動で修正します) ③ 「base」の箇所を「pre-production」に変更し ます。
50. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 50 ④ 「✓Able to merge」という文字が表示されて いること、マージ内容が開発環境で修正した 箇所だけであることを確認します。 ⑤ [Create pull request]をクリックします。
51. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 51 ⑥ コメントを確認のうえ、[Create pull request]をクリックします。Pull Requestが作成されました。
52. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 52 ⑦ [Merge pull request]をクリックします。 ⑧ 内容を確認して[Confirm merge]をクリックします。
53. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 53 ⑨ Mergeされたことを確認します。 ⑩ OpenShift Webコンソールにて、プロジェクト 「pre-production」のトポロジーを選択します。 ⑪ worklog-uiの状況を確認し、新たにビルドが 実行されていることが確認できます。
54. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 54 ◼ 検証環境動作確認 (アプリが変更されていること) ① Projectで[pre-production]を選択し、[Developer]パースペクティブで[トポロジ]を選択します。 ② [worklog-ui]を選択し、「Routes」のLocationURLをクリックします。 Welcome画面で、変更が反映 されていることを確認できます。
55. 参考 © 2021 IBM Corporation 55 ◼ Kubernetes - リソースの管理 – https://kubernetes.io/ja/docs/concepts/cluster-administration/manage-deployment/ ◼ Kubernetes – 更新戦略 – https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/#%E6%9B%B4%E6%96%B0%E6%88%A6%E7%95%A5 ◼ OpenShift アプリケーションライフサイクルマネジメント – https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/applications/application-life-cycle-management#olm-creating-etcd-cluster-from- operator_odc-creating-applications-using-developer-perspective ◼ Google Cloud アーキテクチャセンター – https://cloud.google.com/architecture/addressing-continuous-delivery-challenges-in-a-kubernetes-world?hl=ja#environments ◼ Kubernetes環境を複数持つ場合のメリット・デメリット(Pro/Cons) – http://vadimeisenberg.blogspot.com/2019/03/multicluster-pros-and-cons.html ◼ Kubernetesクラスター内の複数のサービスまたはアプリの環境の管理 – https://humanitec.com/blog/managing-environments-in-a-kubernetes-cluster ◼ GitLab CI + ArgoCDでk8sのGitOpsを試してみる – https://www.forcia.com/blog/001535.html ◼ Production-grade delivery workflow using Argo CD – https://blog.kintone.io/entry/production-grade-delivery-workflow-using-argocd ◼ Red Hat OpenShift GitOps リリースノート – https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/cicd/gitops ◼ GitOpsで絶対に避けて通れないブランチ戦略 – https://amaya382.hatenablog.jp/entry/2019/12/02/192159
56. オプション演習 1. Dockerイメージを使ったデプロイ © 2021 IBM Corporation 56
57. Dockerイメージを使ったデプロイ © 2021 IBM Corporation ◼ OpenShiftでもKubernetesと同様にDockerイメージを使ってデプロイを行うことができます。 – 以下のDockerイメージをOpenShiftにデプロイする手順をご紹介します • 単純なJavaマイクロサービス • Dockerイメージ：https://hub.docker.com/r/nheidloff/authors ※ • 今回は省略しますが、実際のプロジェクトでは以下の作業を実施した上で、 ご紹介する処理を実施します。 » gitなどのソースコード管理へソースコードをpush » 最新ソースコードのpullとDockerイメージのビルド » DockerリポジトリにDockerイメージをpush 57 注) 上記Docker Hubリポジトリ, DockerイメージはIBM社員が作成しています。 これまでの演習で実施した「S2I」とい うデプロイ方式では、下2つを実施する ことなくOpenShiftにアプリをデプロイ することができます。
58. Dockerイメージを使ったデプロイ © 2021 IBM Corporation 58 ◼ Dockerイメージのデプロイ ① Developerパースペクティブに変更し、[コンテナイメージ]を選択します。 ② イメージ名に「nheidloff/authors:v1」を入力し、[作成]をクリックします。 pre-production
59. Dockerイメージを使ったデプロイ © 2021 IBM Corporation 59 ◼ デプロイの確認 ① DockerイメージがOpenShiftにデプロイされました。 ② RoutesのURLリンクをクリックすることで、アプリケーションを確認することができます。 pre-production
60. Dockerイメージを使ったデプロイ – 削除 © 2021 IBM Corporation 60 ◼ サービスの削除 公開されているネットワーク設定を削除します。 ① トポロジ画面にて、[Services]のリンクをクリックします。 ② 表示されたService画面にある右上の「アクション」から[Serviceの削除]を選択します。 ③ ダイアログが表示されるので、確認後[削除]をクリックします。 ① ② ③
61. Dockerイメージを使ったデプロイ - 削除 © 2021 IBM Corporation 61 ◼ デプロイメントの削除 デプロイメントを削除すると、そのデプロイメントが持つ全てのオブジェクトも削除されます。 ① 再度トポロジ画面を表示し、表示されているアプリをクリックします。 ② 右上の「アクション」から[Deploymentの削除]を選択します。 ③ ダイアログが表示されるので、確認後[削除]をクリックします。(チェックはONのままでOKです) ① ② ① ③
62. オプション演習 2. 本番環境でのS2Iデプロイ © 2021 IBM Corporation 62
63. 本番環境へのデプロイ © 2021 IBM Corporation 63 作業内容は検証環境と同じです。 「2-3. 演習 1. 検証環境にS2Iでデプロイ」を参照して実施してください。 プロジェクト、及びGitHubのブランチ指定を「production」に置き換えてデプロイを実行してください。 プロジェクトには 「production」を指定 Gitリファレンス(=ブランチ) に「production」を指定
64. 本番環境用GitHub Webhooks設定 © 2021 IBM Corporation 64 本番環境のworklog-apiとworklog-uiのそれぞれの設定をおこなってください。 設定方法は検証環境と同じです。「2-4. 演習 2. GitHubとの連携」を参照してください。 完了すると、下図のように検証環境分と合わせて4つのWebhooks設定が並びます。 これでwebhookの設定は完了です。 後はソースコードの修正で自動的に アプリケーションがデプロイされます。
65. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 65 ◼ 本番環境動作確認 (アプリが変更されていないこと) ① Projectで[production]を選択し、[Developer]パースペクティブで[トポロジ]を選択します。 ② [worklog-ui]を選択し、「Routes」のLocationURLをクリックします。 Welcome画面がオリジナルの 状態であることを確認できます。 ②
66. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 66 ◼ 本番環境(productionブランチ)へのソースコードマージ ① GitHubの自分のリポジトリーへ戻り、pre-productionブランチの変更をproductionに反映します。[Pull requests] タブ内で [New pull Request]をクリックします。
67. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 67 ◼ 本番環境(productionブランチ)への ソースコードマージ ② （重要）「base repository」の箇所を、自分の リポジトリに変更します (forkしている場合は、fork元が自動選択されて しまうため、手動で修正します) ③ 「base」の箇所を「production」に変更します。 ④ 「compare」の箇所を「pre-production」に 変更します。
68. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 68 ◼ 本番環境(productionブランチ)への ソースコードマージ ④ 「✓Able to merge」という文字が表示されて いること、マージ内容が開発環境で修正した 箇所だけであることを確認します。 ⑤ [Create pull request]をクリックします。
69. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 69 ◼ 本番環境(productionブランチ)へのソースコードマージ ⑥ コメントを確認のうえ、[Create pull request]をクリックします。Pull Requestが作成されました。
70. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 70 ◼ 本番環境(productionブランチ)へのソースコードマージ ⑦ [Merge pull request]をクリックします。 ⑧ 内容を確認して[Confirm merge]をクリックします。
71. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 71 ◼ 本番環境(productionブランチ)への ソースコードマージ ⑨ Mergeされたことを確認します。 ⑩ OpenShift Webコンソールにて、 Project[production]のトポロジーを選択します。 ⑪ worklog-uiの状況を確認し、新たにビルドが実行 されていることが確認できます。
72. ソースコードの変更とマージ、CD動作確認 © 2021 IBM Corporation 72 ◼ 本番環境動作確認 (アプリが変更されていること) ① Projectで[production]を選択し、[Developer]パースペクティブで[トポロジ]を選択します。 ② [worklog-ui]を選択し、「Routes」のLocationURLをクリックします。 ② Welcome画面で、変更が反映 されていることを確認できます。
73. © 2021 IBM Corporation 73