Save 37% off PRO during our Black Friday Sale! »

CloudNative CICD in OpenShift Commons Japan

CloudNative CICD in OpenShift Commons Japan

2020/12/10 「OpenShift Commons Gathering Japan 2020」
で利用した資料です。
動画もありますので、よかったら見てください。
https://www.youtube.com/watch?v=WsR3YZfdNZg&list=PLaR6Rq6Z4IqeNLyWM4J_IyOgSofhJ-RAo&index=14

#openshift #ArgoCD #Tekton
**OpenShift Commons Gathering Japan 2020
https://www.redhat.com/en/explore/openshift/commons-gathering-ja

269258447d4284b5cb2ce0f048d143b2?s=128

Shingo.Kitayama

December 10, 2020
Tweet

Transcript

  1. 時代の と のあり方

  2. 時代の

  3. 時代の

  4. バリューストリームのプロセス ローカル開発 継続的インテグレーション 継続的デプロイメント どこでも同じ環境で開発 ガバナンスの徹底 失敗しないデプロイ 自動化されたビルドとテストを実行する ことによって、小さな単位で影響範囲を 修正し、品質の高い成果物を生成する。

    ソフトウェアのデプロイやリリースプロセス 全体を自動化することで、人の手を介さ ずに同様のデプロイを行う 開発者が繰り返し開発や修正を繰り返 す上で、使い慣れた環境で、開発を継 続し続ける。
  5. と 任意の環境 物理 コンテナ で利用可能 環境に特化 ツールのインストールと保守運用が必要 パイプラインの実行に ツールは不要 ツールの利用は共有

    プラグイン構成とバージョンに縛られる ツールの利用は独立 各パイプラインは独立な構成 アップデートのタイミングに制約 パイプライン構成タスクのバージョンは パイプライン毎に独立 設定は ツールごとに固有 設定は
  6. ローカル開発 継続的インテグレーション 継続的デプロイメント 開発者 運用者 設定依頼 パイプライン 設定 ビルド実行 テスト実行

    設定依頼 デプロイ 設定 デプロイ実行
  7. ローカル開発 継続的インテグレーション 継続的デプロイメント 開発者 運用者 ビルド実行 テスト実行 デプロイ 実行 パイプライン

    設定 運用の自律化 デプロイ 設定
  8. とは の設定方法 マニフェスト を前提とし て作られたツール。ツールの運用は によって 自律的に行われる。 からソースコードの取得 アプリケーションビルド、ユニットテスト イメージビルド、イメージ

    にて実行 や の順番を定義 マニフェストによる 定義例 実行コンテナの指定 実行コマンドの設定
  9. いかに開発プロセスを自動化するのか からソースコードの取得 アプリケーションビルド、ユニットテスト コンテナイメージビルド、イメージ 開発者 アプリケーション ソースコード リポジトリ デプロイ設定の取得、デプロイ確認 デプロイ設定の修正

    マニフェスト リポジトリ マニフェストの監視と同期
  10. None
  11. はいくつかのコンポーネントで構成されていま すが、 ですべて管理さ れます。 ・ パイプラインを構築するためのビルディングブ ロックとして機能します。 ・ イベントに基づいてパイプラインをインスタンス化する 機能です。

    ・ 用の ベースのグラフィカル・イン ターフェースです。 は、 リソースに基づくクラウドネイティ ブ ソリューションです。 ビルディングブロックを使用することで、 実装の詳細を抽象化でき、複数のプラット フォームにわたる展開を自動化します。 パイプラインを定義するための を 提供します。
  12. の導入 をインストールすると、パイプライン構成に必要なカスタムリソース( )が とともに自動的にインストールされます。

  13. のコンポーネント コンテナ内で実行するコマンドを定義する 同一 内で実行し、複数 を定義する 一連の を実行するためのパイプライン定 義する の実行を表現する の実行を表現する

    と に提供する入力と出力の定 義 など を行う
  14. の定義 apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: mvn-build spec: inputs:

    resources: - name: source type: git outputs: resources: - name: source type: git steps: - name: build image: maven:3.6.0-jdk-8-slim command: - /usr/bin/mvn args: - package - name: test image: maven:3.6.0-jdk-8-slim command: - /usr/bin/mvn args: - verify コマンドの実行単位。実行コンテナ イメージと実行コマンドを定義する。 複数の によって構成される作 業の定義を行う。 は として構成され、各 はコンテナとして実行される。
  15. apiVersion: tekton.dev/v1alpha1 kind: TaskRun metadata: name: mvn-build-taskrun spec: taskRef: kind:

    Task name: mvn-build inputs: resources: - name: source resourceSpec: type: git params: - name: url value: https://github.com/siamaksade/mapit-spring.git の定義 インスタンス作成 参照 を実行するためのリソース。事前 に定義しておいたリソース、トリガーの 情報、および引数などを渡します。 ・ を として実行 ・ 定義を で参照 ・ へ渡される入力値 など ・実行の状態などを管理
  16. ごとのステータス確認

  17. の定義 kind: Pipeline metadata: name: petclinic-deploy-pipeline spec: resources: - name:

    app-git type: git - name: app-image type: image tasks: - name: build taskRef: name: s2i-java-8 resources: inputs: - name: source resource: app-git outputs: - name: image resource: app-image - name: deploy taskRef: name: openshift-client runAfter: - build params: - name: ARGS value: "rollout latest spring-petclinic" 実行したい一連の の流れを定義 する。 ・実行すべき の順序を定義 ・実行時パラメータ ・ のリトライ回数の指定 ・ の実行条件 ・ 間データ共有 ・テンプレートとしての再利用
  18. における 間のデータ共有 ・ の実行結果を提供 ・小さめのデータを共有する場合に有効 例) やブランチ名など ・ マウントとして共有 ・大きめのデータを共有する場合に有効

    例) ソース、バイナリ、レポートファイルなど
  19. の定義 apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: petclinic-deploy-pipelinerun spec: pipelineRef:

    name: petclinic-deploy-pipeline trigger: type: manual resources: - name: app-git resourceRef: name: petclinic-git - name: app-image resourceRef: name: petclinic-image インスタンス作成 参照 を実行するためのリソース。 事前に定義しておいたリソース、トリ ガーの情報、および引数などを渡しま す。 ・各 の を生成し、 を 実行 ・各 は任意の ノードで実行 ・ 経由で共有データ用の を提供
  20. の実行 定義 の実行 の インスタンス化 開発者

  21. の実施 のステータス確認

  22. は コミュニティと協力して、 と の共有と再利用の簡素化に取り組んでいます。 は、 と に関する詳細情報 を提供します。 これによって、開発者が や

    の実装の 詳細を知らなくても、 を構築することを支援します。 では、こ れらの一部を「 」にて提供しています。
  23. でデプロイメントは行わない アプリケーション ソースコード リポジトリ マニフェスト リポジトリ を作成することは可能だが、デプロイ 先の状態変化を検知してデプロイするわけではない。 継続的インテグレーション 継続的デプロイメント

    型 は注意が必要 ・デプロイ作業の属人化 ・デプロイ権限の分離 ・デプロイ操作の統一
  24. と を組み合わせた アプリケーション ソースコード リポジトリ マニフェスト リポジトリ 継続的インテグレーション 継続的デプロイメント デプロイメントプロセスを

    にすることで、 デプロイ先の状態変化を動的に検知し、定義された状態を持ち続ける 型
  25. None
  26. ・ 指定されたターゲット環境へのアプリケーションの自 動展開 ・ 複数の構成管理 テンプレートツール( 、 、 、 、

    )のサポート ・ 複数のクラスタ管理およびデプロイ機能 ・ 統合 ( 、 、 、 、 、 、 、 ) ・ アプリケーションのロールバック機能 ( デプロイ、 デプロイ) ・ アプリケーションリソースのヘルスチェック ・ 構成ドリフトの検出と可視化 ・ 統合( 、 、 ) ・ 自動化のための は、 を基盤とした ソリューションです。 は、 リポジトリで定義されたアプリ ケーション定義と構成を継続的に監視し、それ らの構成情報と、クラスター上のライブ状態と 比較するコントローラーとして実装されます。
  27. とは マニフェスト リポジトリ 状態の確認 状態の変更 状態の更新 クラスタの状態 すべてのリリース変更や運用に対して、コマンドを用いずに 経由で構成管理をすると言う思想

  28. におけるデプロイの課題 単一の環境では はうまく機能するが、複数の環境(開発、ステージング 本番)を管理する場合、管理が複 雑になります。 複数の環境では、環境ごとに異なる構成が必要です。例えば、異なるデータベースへの接続、 の使用、異な るデプロイメント構成 レプリカ数など の使用です。これらを単一のマニフェストで取り扱うと、設定ミスや漏れの恐れ

    があります。 単一の環境 複数の環境
  29. 複数環境におけるデプロイ方法 環境ごとに異なる構成 接続や の切り替えなど を行うための構成管理ツール で活用できる独 自テンプレートで、 から 操作できます。 リポジトリ内のマニフェストを

    テンプレート化することで、 変数を活用できます。 などのクラスタ実行に必要な リソース定義がパッケージ化 されます。これによってアッ プデートやロールバックなど が行えます。 に組み込まれたパッ ケージツールです。 テンプレートの に対して、 各環境毎に変更する設定を 記述したパッチを当てること で、一つの を出力しま す。
  30. は、 をブートストラップし、操作を実行するための です。 用のマニフェストレポジトリの設定と 環境の初期設定 ・ の 設定 ・アプリケーションの 作成

    ・ との連携 ・クラスタ固有設定の ・ との連携
  31. に よる の統合 ・ で の 専用 ・ アプリケーションのグルー プ化と、ステータスの可視化

    ・ へのリンク
  32. 時代の と のあり方

  33. 時代の と のあり方 アプリケーション ソースコード リポジトリ マニフェスト リポジトリ 継続的インテグレーション 継続的デプロイメント

    運用をツールに任せることで 継続的インテグレーションと継続的デリバリの役割 権限 を分離する
  34. None