システムに関わる人たちを支える アーティファクト管理の3つのポイント

2022/09/01 JFrog Webinar

アーティファクトとは、自社の開発チームにより作成されたソースコードのビルド結果、その中で利用されているオープンソース・ソフトウェア(OSS)、Dockerなどのコンテナなど、ソフトウェア開発の結果として生成されるものを指し、今後ますます増えていくと言われています。

みなさんはそんなアーティファクトをどのように管理していますか？

このウェビナーでは、アーティファクトを管理することがシステムに関わるすべての関係者をどのように支えるか、ポイントを3つ挙げて解説します。

Transcript

1. システムに関わる人たちを支える アーティファクト管理の3つのポイント 2022/09/01(木) 　JFrog Webinar
2. はじめに 2 ▪ 資料・動画は後ほど公開します ◦ 公開後、本ウェビナーにご登録いただいたメール宛にお知らせします ▪ Zoom機能を使って、是非ご参加ください ◦ Q&Aで質問を随時書き込んでください ◦ チャットは自由にお使いください（ご自身の現場のお話、賑やかしなど） ▪ Twitterが好きな方は #JFrog でツイートをお願いします
3. 自己紹介 3 ▪ Developer Advocate @ JFrog ▪ 「よしQ」と覚えていだけるとうれしいです ▪ 山形県鶴岡市からリモートワーク ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン サルなど経験 ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで ▪ エンジニア目線で情報発信！ 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato
4. Ice Break - 私ごとについて 4 ▪ JFrogにJoinしてから今日でちょうど3ヶ月が経過... ◦ 会社を知る ▪ JFrogの一員として、JFrog製品やカルチャーに関する学習 ▪ DevOps・DevSecOpsに関する学習 ◦ 外部へ発信する ▪ ブログの執筆 ▪ ウェビナーやカンファレンスへの登壇 ◦ 他の現場を知る ▪ ユーザーやパートナーとミーティングする ▪ より今の現場を知り、求められる情報を提供したい ◦ ぜひチャットやQAなどを通して、みなさんの現場のお話も教えてください
5. アジェンダ 5 ▪ アーティファクトとは ◦ アーティファクトの特徴 ◦ アーティファクトの管理方法 ▪ 開発/運用におけるアーティファクト管理の重要性 ▪ まとめ・Q&A
6. 6 アーティファクトとは
7. Webで見つけた「アーティファクト」の説明 7 英辞郎 on the WEB: https://eow.alc.co.jp/search?q=artifact Wikipedia: https://en.wikipedia.org/wiki/Artifact_(software_development) アーティファクトは、ソフトウェアの開発中に生成される多くの種類の 有形の副産物 の1 つです。 一部の成果物 (例:...) は、ソフトウェアの機能、アーキテクチャ、および設計の記述 に役立ちます。その他の成果物は、プロジェクト計画、ビジネス ケース、リスク評価 など、開発プロセス自体に関係しています。 ビルド ツールでは、テスト用にコンパイルされたソース コードをアーティファクトと呼ぶことが よくあります。これは、実行可能ファイルがテスト計画の実行に必要であるためです。
8. Webで見つけた「アーティファクト」の説明 (Cont.) 8 Unified Modeling Language: Superstructure version 2.0 https://www.omg.org/spec/UML/2.0/Superstructure/PDF UMLでは、システムの実行形式となるファイルの配 置やその依存関係に関する表現例がある
9. 「アーティファクト」とは 9 ▪ 広義の意味では「ソフトウェアを作る過程で生み出されたもの」を指す ◦ 設計書 ◦ ソースコード ◦ ビルドやパッケージングを経て生成されるファイル ◦ テスト仕様書・エビデンス ◦ ログファイル　など
10. このセッションにおける「アーティファクト」 10 ▪ アーティファクト：ビルドやパッケージングを経て生成されるファイル ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある JAR/WARパッケージ (Java) RPM/DEB パッケージ (Linux) Docker イメージ npm (JavaScript) PyPl パッケージ (Python) RubyGems (Ruby) ZIP/tarball ファイル ダイナミックリンク ライブラリ(DLL) (Windows) NuGet パッケージ (.NET) Go Module (Go) 例：
11. 11 アーティファクトの特徴
12. 特徴1: コンピュータ上の実行・配布形式である 12 ▪ アーティファクト＝ビルドによって生成されるコンピュータ上の実行・配布形式 ◦ コンパイル型言語の場合、バイナリファイルが出力 ◦ インタプリタ型言語の場合、実行形式のファイルが出力 ◦ OSSとして配布される場合、主にバイナリファイルの形（開発効率化のために活用） ▪ ソースコードとは異なり、依存関係のあるアーティファクトの取得・紐付けが確定した状態 ▪ 一度ビルドされたら本番デプロイまで使い続ける（問題があれば別のアーティファクトを生成） コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクトが使われ続ける (1度生成したら本番デプロイまで同じものを使う ) アーティファクト誕生
13. 特徴2: ビルドするごとに形が変わる 13 ▪ ソースコードが変化しなくとも、ビルド時に同じアーティファクトが生成されるとは限らない ◦ 使用するOSSのアーティファクトが異なるなど、依存関係のバージョン違い ▪ 依存するアーティファクトのバージョン指定が曖昧な場合、更新によって結果が変わる ▪ 依存するアーティファクトが使用している別のアーティファクトが変更される場合も同様に結果が変わ る ◦ 環境変数で指定されている値が異なるなど、ビルド環境や実行環境の設定違い ▪ ビルド時に環境情報を埋め込む場合、結果が変わる ソースコードは、システムを形作る上で重要！ ただし、環境に応じた情報を扱ったり曖昧な定義ができるも のも可能な場合が多い。 (これが悪いわけではない。 ) アーティファクトの生成時に状況が変わり、同じ結果がえられ ないかもしれないということを認識しているのは重要！
14. 特徴3: 数も種類も増え続けている 14 ▪ アジャイル開発やCI/CDの広がり 　　→ ビルド回数が増えており、都度アーティファクトが 　　　 生成される ▪ OSSなどのサードパーティが作成したアーティファクトの活用 　　→ 配布されるアーティファクトが増加している ▪ サーバレスなアーキテクチャやマイクロサービスの広がり 　　→ 1システムで利用するサービスが複数あり、 　　　 それぞれで使用されるアーティファクトが異なる ▪ IaC(Infrastructure as Code)やコンテナ技術の活用 　　→ 実行環境そのものがアーティファクトとして 　　　 扱われるようになった ▪ IoTの普及 　　→ 1つのシステムに必要なデバイスが増加している Docker / K8s / Serverless Microservices DevOps CD CI IoT 2000 Today
15. 特徴4: アーティファクトの特徴が一見してわからない 15 ▪ 多くの場合、アーティファクトはバイナリ形式であり、その内容を読むことができない ◦ いつ、だれが、どの環境で作られたものか、信頼できるものかわからない ◦ アーティファクトは何で構成されているのか捉えるのが難しい ▪ ソースコードと同じよう差分を取ることができない ◦ ビルドによって生成されるのがバイナリファイルの場合はそもそも不可 ◦ ビルドによって生成されたのが複数ファイルの場合、全体を差分を取ることは難しい ▪ アーティファクトはメタデータで特徴を示す ◦ いつ、だれが、どの環境で作った、などビルドにまつわる情報を指す 　→ アーティファクトの特徴として利用し、他との区別に利用する ◦ メタデータを比較することで差分を取ることが可能 　→ 以前のビルドとの差異を確認することができ、問題発生時の助けになる
16. アーティファクト管理の必要性 16 特徴1 コンピュータ上の実行形式である 特徴2 ビルドするごとに異なるものが作成される 特徴3 数も種類も増え続けている 特徴4 アーティファクトの特徴が一見してわからない 実行環境で利用するアーティファクトを素早く特定 する必要がある いつ、どのような状態で作られたアーティファクトか を把握する必要がある 個々のアーティファクトを独立して管理するのでは なく、まとめて管理する必要がある • 数多く生成されるアーティファクトの中から、正しいものを選択し てテストやリリースしたり、本番環境での問題解決を行うため、特 定や検索が行えるようにする • 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と いった特徴をメタデータを保持する必要がある • アーティファクトの生成過程を知るための情報であり、アーティ ファクトの信頼性にも繋がる • システムの構成が複数サービスを利用する場合、組み合わせを 含めて管理することで品質が向上できる • 依存関係として利用する OSSなどのサードパーティ製のアーティ ファクトも管理が必要
17. アーティファクト管理の必要性 17 特徴1 コンピュータ上の実行形式である 特徴2 ビルドするごとに異なるものが作成される 特徴3 数も種類も増え続けている 特徴4 アーティファクトの特徴が一見してわからない 実行環境で利用するアーティファクトを素早く特定 する必要がある いつ、どのような状態で作られたアーティファクトか を把握する必要がある 個々のアーティファクトを独立して管理するのでは なく、まとめて管理する必要がある • 数多く生成されるアーティファクトの中から、 正しいものを 選択してテストやリリースしたり、本番環境での問題解決を行うた め、特定や検索が行えるようにする • 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と いった特徴をメタデータを保持する必要がある • アーティファクトの生成過程を知るための情報（トレーサビリティ） であり、アーティファクトの信頼性にも繋がる • システムの構成が複数サービスを利用する場合、組み合わせを 含めて管理することで品質が向上できる • 依存関係として利用する OSSなどのサードパーティ製のアーティ ファクトも管理が必要
18. アーティファクト管理の必要性 18 特徴1 コンピュータ上の実行形式である 特徴2 ビルドするごとに異なるものが作成される 特徴3 数も種類も増え続けている 特徴4 アーティファクトの特徴が一見してわからない 実行環境で利用するアーティファクトを素早く特定 する必要がある いつ、どのような状態で作られたアーティファクトか を把握する必要がある 個々のアーティファクトを独立して管理するのでは なく、まとめて管理する必要がある • 数多く生成されるアーティファクトの中から、正しいものを選択し てテストやリリースしたり、本番環境での問題解決を行うため、特 定や検索が行えるようにする • 一度生成されたら不変的 であり、「いつ」「誰が」「何を」「どこで」と いった特徴をメタデータを保持する必要がある • アーティファクトの生成過程を知るための情報であり、アーティ ファクトの信頼性にも繋がる • システムの構成が複数サービスを利用する場合、組み合わせを 含めて管理することで品質が向上できる • 依存関係として利用する OSSなどのサードパーティ製のアーティ ファクトも管理が必要
19. アーティファクト管理の必要性 19 特徴1 コンピュータ上の実行形式である 特徴2 ビルドするごとに異なるものが作成される 特徴3 数も種類も増え続けている 特徴4 アーティファクトの特徴が一見してわからない 実行環境で利用するアーティファクトを素早く特定 する必要がある いつ、どのような状態で作られたアーティファクトか を把握する必要がある 個々のアーティファクトを独立して管理するのでは なく、まとめて管理する必要がある • 数多く生成されるアーティファクトの中から、正しいものを選択し てテストやリリースしたり、本番環境での問題解決を行うため、特 定や検索が行えるようにする • 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と いった特徴をメタデータを保持する必要がある • アーティファクトの生成過程を知るための情報であり、アーティ ファクトの信頼性にも繋がる • システムの構成が複数サービスを利用 する場合、組み合わせを 含めて管理することで品質が向上 できる • 依存関係として利用する OSSなどのサードパーティ製のアーティ ファクトも管理が必要
20. 20 アーティファクトの管理方法
21. アーティファクトをどう管理すべきか 21 ▪ 案1: ファイルサーバでの管理：フォルダ構造やファイル命名規則などの一定ルールを設けて管理 ◦ 命名規則やフォルダ構造に意味があるため、場所・名前で一定判別できる ◦ ファイル名以外の情報が得られず、組み合わせなどの情報が管理できない ◦ 自動化の際に検討事項が多い(APIをどうするかなど) ▪ 案2: VCSでの管理：ソースコード同様にGitなどのVCSを使った管理 ◦ バージョン管理としての基本的な機能が備わっている ◦ アーティファクトの特徴を保持できず、検索が難しい ◦ バイナリファイルの管理時に、容量消費が大きい ▪ 案3: バイナリ・リポジトリでの管理
22. バイナリ・リポジトリとは 22 ▪ アーティファクトの貯蔵庫・保管庫 ◦ 作成したアーティファクトをメタデータと共に保管する ◦ インターネット上にあるパブリックなものが典型的 ▪ プライベートなバイナリ・リポジトリ ◦ アーティファクトをより適切に管理することができる ▪ 開発・運用で生成・使用する全てのアーティファクトを一元管理できる ▪ バージョン管理の他、メタデータも合わせて管理できる ▪ アクセス権限制御も含めて対応可能 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) 例：
23. JFrog Artifactoryのご紹介 23 ▪ JFrogが提供するバイナリ・リポジトリマネージャ ◦ クラウド・オンプレミス双方設置可能 ▪ Artifactoryの特徴 ◦ 高いユニバーサル性 ▪ 30以上のパッケージマネージャに対応 ◦ メタデータ管理が容易 ▪ ビルド情報以外にもGitのバージョンやテスト状況など、 メタデータを追加で持たせることが可能 ◦ ストレージ最適化 ▪ チェックサムを用いたファイル管理 ◦ Platform外部のツールとの統合が容易 ▪ APIや専用CLI、プラグインなどを提供
24. 24 開発/運用におけるアーティファクト管理の重要性
25. 開発現場でよくある実情 25 ▪ 外部パッケージ・ライブラリの利用 ◦ 98%のシステム開発でOSSを活用(*1)し、開発の効率化・高速化が図られている ◦ 自社開発したパッケージやライブラリの利用するケースがある（例：共通部品） ◦ 開発者は、パッケージマネージャを利用してインターネットから取得したり、ファイルサーバから取得し て配置するなどする ▪ ビルド方法（アーティファクトを生む方法） ◦ ビルド担当者を置き、その人の環境でのみ有効なものを作る ◦ CIサーバを利用して自動化 ▪ ビルドタイミング（アーティファクトが生まれるタイミング） ◦ 開発者のソースコードがマージされたタイミングで1回実施し、アーティファクトを使い回す ◦ 環境配置の都度ビルドを行い、生成されたアーティファクトは1回のみ利用 *1: MONOist 「オープンソースソフトウェアの採用率は 98%に拡大、脆弱性を含む割合も増加の一途」 https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html
26. ある現場でのシステム開発の流れ 26 VCS ファイルサーバ 開発チーム ビルド・デプロイ担当者 運用担当者 アーティファクト ①開発チームで 　複数メンバーの 　ソースコード開発 ③ビルドして 　アーティファクトを 　生成する ④アーティファクトを 　テスト環境にデプロイ アーティファクト ⑤QA実施 ⑥アーティファクト 　を保管する ⑦開発チームの 　依頼に基づき、 　アーティファクトを 　本番環境にデプロイ 　(リリース)する ②開発したコードを 　保管する
27. 開発チームにおけるよくある課題 27 VCS ファイルサーバ 開発チーム ビルド・デプロイ担当者 運用担当者 アーティファクト ①開発チームで 　複数メンバーの 　ソースコード開発 ③ビルドして 　アーティファクトを 　生成する ④アーティファクトを 　テスト環境にデプロイ アーティファクト ⑤QA実施 ⑥アーティファクト 　を保管する ⑦QAで問題なければ 　保管されていた 　アーティファクトを 　本番環境にデプロイ 　(リリース)する ②開発したコードを 　保管する 課題 アーティファクト管理のメリット （特にバイナリ・リポジトリを利用した場合） 依存するアーティファクトを開発者自身が取得・配置 することで、誤ったものを利用する可能性がある ❏ 一元管理された場所を作ることで、正しいものを迷 わず取得できる ❏ SCAなどと組み合わせて利用することで脆弱性の チェックできる(シフトレフト) ネットワークの問題などでインターネット経由で依存 するアーティファクトが取得できない ❏ インターネット経由で取得するものに対してプロキ シ・キャッシュとして機能し、外部の状況に左右さ れずに対象を取得可能 外部公開されていないが、自社開発で共通利用する アーティファクトの管理が煩雑 ❏ 細かなアクセス管理が可能 ❏ 監査時の情報収集が比較的容易 開発者が自身で環境設定を行うため、環境差異が 発生する可能性がある ❏ メタデータによる差分比較により、アーティファクト の生成過程での差異を発見することができる
28. ビルドにおけるよくある課題 28 ファイルサーバ ビルド・デプロイ担当者 運用担当者 アーティファクト ③ビルドして 　アーティファクトを 　生成する トを デプロイ アーティファクト ⑤QA実施 ⑥アーティファクト 　を保管する ⑦QAで問題なければ 　保管されていた 　アーティファクトを 　本番環境にデプロイ 　(リリース)する を 課題 アーティファクト管理のメリット （特にバイナリ・リポジトリを利用した場合） 依存するアーティファクトを開発者自身が取得・配置 することで、誤ったものを利用する可能性がある (開 発と同じ) ❏ 一元管理された場所を作ることで、正しいものを迷 わず取得できる ネットワークの問題などでインターネット経由で依存 するアーティファクトが取得できない (開発と同じ) ❏ インターネット経由で取得するものに対してプロキ シ・キャッシュとして機能するため、外部の状況に 左右されずに対象を取得可能 ❏ 外部ネットワークへの接続が減ることによるネット ワーク負荷の軽減 依存するアーティファクトがビルドを要するものの場 合、全体のビルド完了までに時間がかかる ❏ ビルド済みのアーティファクトを取得可能であり、 時間短縮が可能 ❏ メタデータを用いた検索可能であり、特定に時間に かかる時間を短縮 新たに生成したアーティファクトの管理が煩雑（例 : ファイルサーバで管理する場合、命名規則などに 従って配置する必要がある） ❏ システム開発全体で使用可能な名前のまま保管 でき、煩わしさが軽減 ❏ 他チームに配布する場合の取得元としてそのまま 利用可能
29. 運用におけるよくある課題 29 運用担当者 アーティファクト ⑦開発チームの 　依頼に基づき、 　アーティファクトを 　本番環境にデプロイ 　(リリース)する 課題 アーティファクト管理のメリット （特にバイナリ・リポジトリを利用した場合） リリースすべきパッケージ・ライブラリが、誤ったもの を利用する可能性がある (開発と同じ) ❏ 一元管理された場所を作ることで、正しいものを迷 わず取得できる リリース後に問題があった場合の切り戻し作業が発 生した際、使用すべきアーティファクトの取得に時間 がかかる ❏ すべてのアーティファクトが保管されているため、 直前のバージョンの特定が容易 ❏ 稼働実績のあるアーティファクトをそのままリリー ス可能であるため、対応を早くできる 実行環境で問題が発生した場合、問題発生の原因 を特定するのに時間を要する可能性がある ❏ メタデータを利用して依存関係や他の環境との差 分を確認することができ、問題特定が容易になる 外部パッケージ・ライブラリの脆弱性情報に対して、 素早く対応できない (開発チームに問い合わせるなど、確認に時間を要 する) ❏ 開発側から積み重ねられたメタデータを元にした SCAにより、問題の有無の認識が早められる ❏ 開発側と問題のあるアーティファクトや付随する情 報の共有が容易になる
30. 30 まとめ
31. まとめ 31 ▪ アーティファクトとは ◦ ビルドやパッケージングを経て生成されるファイル ◦ 特徴：コンピュータ上の実行・配布形式である、ビルドごとに形が変わる 　　　数も種類も増え続けている、一見してどんなものなのかわからない ◦ 一度生成されると不変であり、上記の特徴を考慮した適切な管理が重要 ▪ アーティファクトの管理方法 ◦ バイナリ・リポジトリを使った管理は、アーティファクトの特徴を考慮した管理が可能 ▪ 一元管理、メタデータの保管と活用、高度なアクセス管理 ◦ JFrog Artifactoryによる管理のご紹介（おすすめ！） ▪ 開発/運用におけるアーティファクト管理の重要性 ◦ 適切なアーティファクト管理を行うことで、さまざまな課題の解決に繋がる
32. アーティファクト管理が支える3つのポイント 32 1. エンジニアの負荷軽減 ◦ 開発のための環境構築における外部アーティファクト準備に対する負荷軽減 ◦ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減 ◦ 新たなアーティファクトを生成する際のビルドにかかる時間短縮 2. システム開発におけるコンプライアンスの向上 ◦ メタデータを利用したビルドにかかるトレーサビリティの確保 ◦ OSSなどの外部アーティファクトの取得元として利用することで均一化と、 脆弱性などの問題に対する初動対応の迅速化 ◦ アーティファクトに対するアクセス管理や監査対応に対しても有効 3. 開発・運用のギャップが埋められる ◦ メタデータを通じた相互理解、情報共有が容易になる ◦ DevOps(DevSecOps)導入の一歩として、機械的な作業は自動化するとより効果が得られる
33. 今後開催のウェビナーのお知らせ 33 こちらをチェック！ https://jfrog.connpass.com/
34. 34 Thank you
35. 35 Q & A
36. 参考文献 36 • 英辞郎 on the WEB 「artifact」 https://eow.alc.co.jp/search?q=artifact • Wikipedia 「Artifact (Software Development)」 https://en.wikipedia.org/wiki/Artifact_(software_development) • Unified Modeling Language: Superstructure version 2.0　https://www.omg.org/spec/UML/2.0/Superstructure/PDF • MONOist 「オープンソースソフトウェアの採用率は98%に拡大、脆弱性を含む割合も増加の一途」　https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html