Developer Experience向上のために導入したい「アーティファクト管理」

2022/10/27 JFrog Webinar

今日のIT環境を取り巻く環境は変化しており、オープンソース・ソフトウェア(OSS)の活用、Dockerなどのコンテナ技術の活用、セキュリティに対するニーズの高まりなど、開発者はこれまで以上に多くのことに気を回し、手を動かす必要があります。さらにスピードが求められる世界が来たとき、対応できるでしょうか。

このウェビナーでは、ソフトウェアの「アーティファクト」にスポットを当て、特徴を踏まえた管理方法のベストプラクティスと、導入による現場での効果を挙げつつ、システム開発者のDeveloper Experienceを高めるためのヒントをお話します。

Transcript

1. Developer Experience向上のために 導入したい「アーティファクト管理」 2022/10/27(木) 　JFrog Webinar
2. はじめに 2 Twitterが好きな方は #JFrog 公開後、本ウェビナーに ご登録いただいたメール宛に お知らせします #JFrog ぜひツイートをお願いします 本日の資料と動画は のちほど公開します！ Zoom機能で ぜひ、ご参加ください！ Q&A機能でご質問を 書き込んでください いつでも、何度でも！ チャットもご自由に お使いください ・ ご自身の現場のお話 ・ 賑やかしなど・・・ Q&A チャット
3. 自己紹介 3 ▪ Developer Advocate @ JFrog ▪ 「よしQ」と覚えていだけるとうれしいです ▪ 山形県鶴岡市からリモートワーク ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン サルなど経験 ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで ▪ エンジニア目線で情報発信！ 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato
4. アジェンダ 4 ▪ アーティファクトとは ▪ アーティファクトの管理方法 ▪ 開発/運用におけるアーティファクト管理の重要性 ▪ まとめ・Q&A
5. Happy Employees make Happy Customers 5 ハッピーワーカーは ハッピーカスタマーにします ハッピーに働く人々 Happy Employees💚 ハッピーなお客様 Happy Customers💚
6. Developer Experience 6 Developer Experience(DX) 開発者が製品を開発する際に感じる体験・経験 *1: DX用語時点 Developer Experience https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ 開発環境 組織 システム 評価体制
7. 7 アーティファクトとは
8. 「アーティファクト」とは 8 ▪ 広義の意味では「ソフトウェアを作る過程で生み出されたもの」を指す ◦ 設計書 ◦ ソースコード ◦ ビルドやパッケージングを経て生成されるファイル ◦ テスト仕様書・エビデンス ◦ ログファイル　など
9. このセッションにおける「アーティファクト」 9 ▪ アーティファクト：ビルドやパッケージングを経て生成される実行形式、または配布形式のファイル ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある JAR/WARパッケージ (Java) RPM/DEB パッケージ (Linux) Docker イメージ npm (JavaScript) PyPl パッケージ (Python) RubyGems (Ruby) ZIP/tarball ファイル ダイナミックリンク ライブラリ(DLL) (Windows) NuGet パッケージ (.NET) Go Module (Go) 例：
10. アーティファクトの4つの特徴 10 コーディング ビルド 単体テスト テスト デプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生から運用、 新たなものがデプロイされるまで 使われ続ける アーティファクト誕生 ① コンピュータ上の実行・配布形式である ▪コードとは異なり、依存関係の解決が確定した状態 ▪一度ビルドされたら本番デプロイまで使い続ける ② ビルドすることに形が変わる ▪ソースコードが変化しなくとも、周辺状況によって同じ アーティファクトが生成されるとは限らない 例: 依存関係のバージョン違い 時点A ソース コード OSS-A 1.0.1 OSS-B 1.0.1 OSS-C 1.0.1 ビルドツール アーティファクト 時点B ソース コード OSS-A 1.0.1 OSS-B 1.0.1 OSS-C 1.0.2 ビルドツール アーティファクト 使用するOSSのバージョンが異なる (最新バージョンが出るなど )
11. アーティファクトの4つの特徴 (Cont.) 11 ③ 数も種類も増え続けている ▪新たな開発方法・考え方の普及により、アーティファクト の作成回数や新たな種類のアーティファクトが増えてい る ④ どんなアーティファクトか一見してわからない ▪多くの場合はバイナリファイル ◦ 構成要素や信頼性を確認することができない ◦ 差分を取ることができず、変化を捉えられない Docker / K8s / Serverless Microservices DevOps CD CI IoT Today 2000 ビルド回数が増加 複数サービスの 組み合わせ インフラも アーティファクトに 01010101010010100100 10010101010100101010 10101010010101010101 00101001010101010010 011101010101010010…
12. アーティファクトのメタデータ 12 ▪メタデータ：ビルドの過程で得られるアーティファクトを特徴づける情報 ◦ いつ、だれが、どのような環境で作った、などのビルドにまつわる情報 ◦ ビルド時に取得・利用したOSS外部アーティファクトなどの依存関係に関する情報 ▪ アーティファクトそのものの比較は難しいため、 メタデータを利用して作成時の状況や設定情報などから差分を取る ▪ ビルドの再現を行う際の基礎情報にも利用可能 作成日 作成者・作成環境 依存関係 設定情報 どのような設定下で ビルドしたか どんな依存関係のある 外部アーティファクトを使ったか
13. システム開発におけるアーティファクト管理の必要性 13 利用するアーティファクトを 素早く特定する必要がある アーティファクト作成の背景を把 握する必要がある 利用するアーティファクトを まとめて管理する必要がある • 数多く生成されるアーティファクトの中か ら、正しいものを選択して テストやリリー スする必要がある • メタデータを検索することで、 特定できる ようになる • 一度生成されたら不変的 であり、 「いつ」「誰が」「何を」「どこで」といった情 報を保持する必要がある • 生成過程がわかることで、 信頼性向上 • 問題解決のための情報 としても活用でき る • システムの構成が複数サービスを 利用する場合、組み合わせを含めて管 理する必要がある • 依存関係で使用するもの などの外部 アーティファクトも管理が必要 • ビルド回数を減らし効率化できる • テスト確認できたものを管理することで 品質向上につながる 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 作成環境 設定情報 …. 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 依存関係 取得元 … アーティファクトそのものだけではなく、メタデータと合わせて管理
14. アーティファクト管理によるDX向上にむけた効果 14 1. 開発に関わる全てのエンジニアの負荷軽減 ◦ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減 ◦ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる（＝負荷軽減） 2. システム開発におけるリスクの低減 ◦ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保 ◦ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題 に対する初動対応の迅速化 3. フェーズ間のギャップが埋められる ◦ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援
15. 15 アーティファクトの管理方法
16. アーティファクトをどう管理すべきか 16 ▪ 案1: ファイルサーバでの管理：フォルダ構造やファイル命名規則などの一定ルールを設けて管理 ◦ 命名規則やフォルダ構造に意味があるため、場所・名前で一定判別できる ◦ ファイル名以外の情報が得られず、関連する情報は管理できない(または別管理を要する) ◦ 自動化の際に検討事項が多い(APIをどうするかなど) ▪ 案2: VCSでの管理：ソースコード同様にGitなどのVCSを使った管理 ◦ バージョン管理としての基本的な機能が備わっており、過去生成されたものも含めて管理できる ◦ アーティファクトそのものの管理は可能だが、関連する情報は管理できない(または別管理を要する) ◦ バイナリファイルの管理時に、容量消費が大きい ▪ 案3: バイナリ・リポジトリでの管理 案1、案2はファイルそのものは管理できても 「メタデータ」を合わせもてない
17. バイナリ・リポジトリとは 17 ▪ アーティファクトの貯蔵庫・保管庫 ◦ 作成したアーティファクトをメタデータと共に保管する ◦ アーティファクトは多くの場合、バイナリファイルの形式 ◦ インターネット上にあるパブリックなものが典型的 ▪ プライベートなバイナリ・リポジトリ ◦ アーティファクトをより適切に管理することができる ▪ 開発・運用で生成・使用する全てのアーティファクトを一元管理できる ▪ バージョン管理の他、メタデータも合わせて管理できる ▪ アクセス権限制御も含めて対応可能 Maven Central (Java) mirror.centos.org (Linux) Docker Hub (Docker) npmjs.org (JavaScript) pypi.org (Python) RubyGems.org (Ruby) archive.ubuntu.com (Linux) NuGet Gallery (.NET) Conan (C/C++) gocenter.io (Go) 例：
18. ▪ アプリケーション開発で作成・使用した、すべてのアーティファクトを一元管理する ◦ ローカルリポジトリで自チームで作成したアーティファクトの管理 ▪ システムに関わるすべての人と共有 ▪ バージョン管理機能を有しており、更新された場合も1つの名前で識別可能 ◦ リモートリポジトリで開発に使用する外部アーティファクトの管理 ▪ パブリックなリポジトリのプロキシ・キャッシュとして動作する機能を有する ▪ プロキシを通して取得されたアーティファクトをキャッシュしておき、 開発・ビルド時に使用されるアーティファクトはこれを提供する ▪ セキュリティ担当者により安全性を担保したものを提供（キュレーション） バイナリ・リポジトリによるアーティファクトの一元管理 18 リモート リポジトリ アーティファクトの煩雑な管理が不要 使用すべき外部アーティファクトを高速に提供可能 ローカル リポジトリ QA担当者 運用担当者 開発担当者 新しいアーティファクトと メタデータをいつもの 場所・名前で登録 デプロイする アーティファクトを いつもと同じ形で 迷わず取得 想定外の動作がある場合、 メタデータを照らし合わせて検 証 CIサービス パッケージ 配布元 開発担当者 OSS インター ネット プロキシ キャッシュ キャッシュを利用することで、 開発で使用したものと同一のものを 地理的に近いところから取得可能
19. バイナリ・リポジトリによるメタデータ管理 19 ▪ ビルド時に取得したメタデータをアーティファクトに紐づけて保管し、活用が可能 ◦ 使用すべきアーティファクトの特定のための検索のキー情報として利用 ◦ 問題発生時に、過去のアーティファクト(ビルド結果)との差異を確認する情報として利用 ◦ ビルド対象となったソースコードとの紐付け トレーサビリティの確保ができ、ビルドの正しさ・信頼性の裏付け 作成日 作成者・作成環境 依存関係 設定情報
20. バイナリ・リポジトリによるアクセス管理 20 ▪ 一元管理されたアーティファクトを、適切なアクセス権限に応じて使用させることができる ◦ どのリポジトリにアクセス可能とするか ◦ どのファイルにアクセス可能とするか ◦ 登録・更新が可能か、読み取りのみ可能か ▪ アーティファクトを他チームに対して共有においても、最新のものがすぐに提供できる ◦ 他拠点のメンバーに対しても即時提供できる ◦ 社外パートナーと共有時も、ユーザ管理＋アクセス管理により対応可能 セキュリティ・コンプライアンスの確保ができる チーム開発時の効率的な共有を実現できる QA担当者 運用担当者 開発担当者A Read/Write 開発担当者B Read Read Read 開発者 関連のない ユーザ パートナー開発者 Read/Write 社内開発者 Read Read 参照不可 プロジェクトA プロジェクトB
21. JFrog Artifactoryのご紹介 21 ▪ JFrogが提供するバイナリ・リポジトリマネージャ ◦ クラウド・オンプレミス双方設置可能 ▪ Artifactoryの特徴 ◦ 高いユニバーサル性 ▪ 30以上のパッケージマネージャに対応 ◦ メタデータ管理が容易 ▪ ビルド情報以外にもGitのバージョンやテスト状況など、 メタデータを追加で持たせることが可能 ◦ ストレージ最適化 ▪ チェックサムを用いたファイル管理 ◦ プラットフォーム外部のツールとの統合が容易 ▪ プラグインや専用CLI、汎用APIなどを提供
22. 22 開発/運用におけるアーティファクト管理の重要性
23. ある現場で行われる開発の流れ 23 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ
24. ビルド・デプロイにおけるよくある問題 24 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ ネットワーク的な問題 で、 外部アーティファクトの 取得に時間が かかる、または取得に失敗し、 開発担当の作業が遅延 本番デプロイ依頼のために、 アーティファクトを手動で配置したり、 ファイル名でバージョン管理するなど、 開 発担当の作業が煩雑 運用担当の作業が 自動化されていない場合、 複数人体制で実施したり、 作業そのものに時間がかかる 運用担当が、デプロイ対象の アーティファクトを探す際に時 間がかかる
25. 運用時におけるよくある問題 25 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ 本番環境で障害発生し、 切り戻しが必要となった場合 、 開発担当の依頼がなければ、運用担当は対処できない (場合によっては、開発担当がコードを戻し、再度ビルド ) 本番稼働してから脆弱性が発覚した場合 、 構成がわからない場合に 開発担当へ問い合わせが 発生し、対処に時間がかかる。 運用担当は対処そのものができない。
26. セキュリティに関する問題 26 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ 脆弱性を含むものを利用している場合、 シ ステム全体に波及する 開発担当がバージョン違いなど、 本来使用すべきではないものを利用 し ている場合、手戻りが発生する 開発担当がライセンス違反となるものを 利用している場合、コンプライアンスに影響 本番稼働してから脆弱性が発覚した場合 、 構成がわからない場合に 開発担当へ問い合わせが 発生し、対処に時間がかかる。 運用担当は対処そのものができない。
27. 良いDXを生むための4つのファクター 27 1. アーキテクチャの適合 ◦ プロジェクトやチームに合わせて適切なアーキテクチャを選択する 2. 優れたツール ◦ 繰り返し行う必要があることは自動化していく 3. すべてをバックアップするプロセス ◦ 自動化されたチェックリストとして、毎回行うべき一貫した手順を定義する 4. 毒のないチーム文化 ◦ 会社の存在意義、共通のゴールや社会へのインパクトなどを共有し、失敗も許容する *1: DX用語時点 Developer Experience https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ *2: Developer Experience.io Good Developer Experience https://developerexperience.io/practices/good-developer-experience
28. アーティファクト管理のDX向上のための対応ポイント 28 ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生 開発 開発 開発 QA 運用 運用 2. 優れたツール: ツールの活用と自動化 4. 毒のないチーム文化: チーム文化の醸成 1. アーキテクチャの適合 2. 優れたツール 3. すべてをバックアップするプロセス 4. 毒のないチーム文化 3. すべてをバックアップするプロセス: 各担当が責任を果たせるようなプロセスの整備
29. CIサービス バイナリ・リポジトリ導入イメージ 29 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する リモート リポジトリ ローカル リポジトリ ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 バイナリ・リポジトリ
30. CIサービス バイナリ・リポジトリ導入による効果 30 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する リモート リポジトリ ローカル リポジトリ ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 バイナリ・リポジトリ トレーサビリティが確保されたアーティファクトを 使い回すことによる品質向上 デプロイすべきアーティファクトの特定・取得が容易 になることによる効率向上・エラー軽減
31. CIサービス アーティファクト管理によるセキュリティ強化 31 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する リモート リポジトリ ローカル リポジトリ ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 バイナリ・リポジトリ キュレーションした安全かつ正しいものを高速に提供 することで、セキュリティ・効率が向上 継続的に安全性を確認されている外部 アーティファクトを利用することによる、脆 弱性に対するリスク低減 外部アーティファクトが具体的に何を利用しているか 確認できるため、脆弱性に対しても自律的な対応が 可能
32. JFrog Platformの活用例 32 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の 　プロモーションにより 　本番用に自動コピー 　(メタデータ含む) ※ビルドにより生成 ※キャッシュ提供 　による高速化 ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境
33. 33 まとめ
34. まとめ 34 ▪ アーティファクトの管理方法 ◦ バイナリ・リポジトリを使った管理は、アーティファクトの特徴を考慮した管理が可能 ▪ 一元管理 ▪ メタデータの保管と活用 ▪ 高度なアクセス管理 ▪ 開発/運用におけるアーティファクト管理の重要性 ◦ 適切なアーティファクト管理を行うことで、さまざまな課題の解決に繋がる ◦ 個々が本来集中すべき業務に対する時間を十分に確保しつつ、全体でも繋がる要素を持つ
35. アーティファクト管理によるDX向上にむけた効果(再掲) 35 1. 開発に関わる全てのエンジニアの負荷軽減 ◦ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減 ◦ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる（＝負荷軽減） 2. システム開発におけるリスクの低減 ◦ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保 ◦ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題 に対する初動対応の迅速化 3. フェーズ間のギャップが埋められる ◦ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援 ◦ DevOps(DevSecOps)の一歩として、機械的な作業は自動化するとより効果が得られる
36. 36 Thank you
37. 37 Q & A
38. 参考文献 38 • DX用語時点 「Developer Experience」 https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ • DeveloperExperience.io 「Good Developer Experience」https://developerexperience.io/practices/good-developer-experience
39. 39 Appendix
40. JFrog Platformの全体像 40 監視、設定、管理者ダッシュボード インテリジェンスメトリクスの分析 すべてのソフトウェアパッケージと コンテナイメージを保存、管理 セキュリティとコンプライアンスの問題 解決 (OSS脆弱性・ライセンス問題のチェッ ク) クラウド、データセンターへ 安全なソフトウェア配布 デバイスフリートへの ソフトウェアデプロイ、運用、監視 エンドツーエンドの CI/CD自動化とオーケストレーション BUILD & TEST RELEASE DEPLOY VCS ソースコード リポジトリ On-premise and Hybrid Regional Sites Public Cloud Platforms IoT Edge
41. JFrog Xrayのご紹介 41 ▪ JFrog Artifactoryと統合されたSCAソリューション ◦ Artifactoryに保存されているアーティファクトを分析する ▪ Xrayの特徴 ◦ 高いユニバーサル性 ▪ 主要なパッケージタイプをサポート ◦ 再帰的なスキャンの実施 ▪ Dockerイメージやzipファイルでパッケージ化されたものを含めて、 ベースレイヤーだけでなく、推移的依存関係を含めて確認できる ◦ タイムリーかつ包括的な脆弱性データベースを利用 ▪ VulnDB ＋ NVD ＋ JFrog Security Research ◦ 継続的なモニタリング ▪ 本番環境デプロイ後もスキャン可能
42. JFrog Pipelinesのご紹介 42 ▪ ワンストップDevOpsのためのEnd-to-EndでCI/CDを実現 ◦ サイロ化されたDevOpsツールを一元化 ▪ Pipelinesの特徴 ◦ リアルタイム可視性 ▪ ダッシュボードでCI/CDの状況が確認可能 ◦ Pipelines-as-Code ▪ YAML構文でステップを標準化 バージョン管理、モジュール化され再利用可能 ◦ セキュリティ・ファースト ▪ パスワード情報などのシークレット管理、きめ細かなアクセス管理 ◦ エンタープライズ対応 ▪ 水平方向への拡張、HA環境サポート、集中管理型 リアルタイム可視性 Pipelines設定ファイル