Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Yoshihisa Sato
September 06, 2022

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

2022/09/01 JFrog Webinar

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

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

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

Yoshihisa Sato

September 06, 2022
Tweet

More Decks by Yoshihisa Sato

Other Decks in Technology

Transcript

  1. システムに関わる人たちを支える
    アーティファクト管理の3つのポイント
    2022/09/01(木)  JFrog Webinar

    View full-size slide

  2. はじめに
    2
    ▪ 資料・動画は後ほど公開します
    ○ 公開後、本ウェビナーにご登録いただいたメール宛にお知らせします
    ▪ Zoom機能を使って、是非ご参加ください
    ○ Q&Aで質問を随時書き込んでください
    ○ チャットは自由にお使いください(ご自身の現場のお話、賑やかしなど)
    ▪ Twitterが好きな方は #JFrog でツイートをお願いします

    View full-size slide

  3. 自己紹介
    3
    ▪ Developer Advocate @ JFrog
    ▪ 「よしQ」と覚えていだけるとうれしいです
    ▪ 山形県鶴岡市からリモートワーク
    ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン
    サルなど経験
    ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで
    ▪ エンジニア目線で情報発信!
    佐藤 由久
    SATO Yoshihisa
    @umekichi1984 @yoshiq-sato

    View full-size slide

  4. Ice Break - 私ごとについて
    4
    ▪ JFrogにJoinしてから今日でちょうど3ヶ月が経過...
    ○ 会社を知る
    ■ JFrogの一員として、JFrog製品やカルチャーに関する学習
    ■ DevOps・DevSecOpsに関する学習
    ○ 外部へ発信する
    ■ ブログの執筆
    ■ ウェビナーやカンファレンスへの登壇
    ○ 他の現場を知る
    ■ ユーザーやパートナーとミーティングする
    ▪ より今の現場を知り、求められる情報を提供したい
    ○ ぜひチャットやQAなどを通して、みなさんの現場のお話も教えてください

    View full-size slide

  5. アジェンダ
    5
    ▪ アーティファクトとは
    ○ アーティファクトの特徴
    ○ アーティファクトの管理方法
    ▪ 開発/運用におけるアーティファクト管理の重要性
    ▪ まとめ・Q&A

    View full-size slide

  6. 6
    アーティファクトとは

    View full-size slide

  7. Webで見つけた「アーティファクト」の説明
    7
    英辞郎 on the WEB: https://eow.alc.co.jp/search?q=artifact
    Wikipedia: https://en.wikipedia.org/wiki/Artifact_(software_development)
    アーティファクトは、ソフトウェアの開発中に生成される多くの種類の 有形の副産物
    の1 つです。
    一部の成果物 (例:...) は、ソフトウェアの機能、アーキテクチャ、および設計の記述
    に役立ちます。その他の成果物は、プロジェクト計画、ビジネス ケース、リスク評価
    など、開発プロセス自体に関係しています。
    ビルド ツールでは、テスト用にコンパイルされたソース コードをアーティファクトと呼ぶことが
    よくあります。これは、実行可能ファイルがテスト計画の実行に必要であるためです。

    View full-size slide

  8. Webで見つけた「アーティファクト」の説明 (Cont.)
    8
    Unified Modeling Language: Superstructure version 2.0
    https://www.omg.org/spec/UML/2.0/Superstructure/PDF
    UMLでは、システムの実行形式となるファイルの配
    置やその依存関係に関する表現例がある

    View full-size slide

  9. 「アーティファクト」とは
    9
    ▪ 広義の意味では「ソフトウェアを作る過程で生み出されたもの」を指す
    ○ 設計書
    ○ ソースコード
    ○ ビルドやパッケージングを経て生成されるファイル
    ○ テスト仕様書・エビデンス
    ○ ログファイル など

    View full-size slide

  10. このセッションにおける「アーティファクト」
    10
    ▪ アーティファクト:ビルドやパッケージングを経て生成されるファイル
    ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある
    JAR/WARパッケージ
    (Java)
    RPM/DEB パッケージ
    (Linux)
    Docker イメージ npm
    (JavaScript)
    PyPl パッケージ
    (Python)
    RubyGems
    (Ruby)
    ZIP/tarball ファイル ダイナミックリンク
    ライブラリ(DLL)
    (Windows)
    NuGet パッケージ
    (.NET)
    Go Module
    (Go)
    例:

    View full-size slide

  11. 11
    アーティファクトの特徴

    View full-size slide

  12. 特徴1: コンピュータ上の実行・配布形式である
    12
    ▪ アーティファクト=ビルドによって生成されるコンピュータ上の実行・配布形式
    ○ コンパイル型言語の場合、バイナリファイルが出力
    ○ インタプリタ型言語の場合、実行形式のファイルが出力
    ○ OSSとして配布される場合、主にバイナリファイルの形(開発効率化のために活用)
    ▪ ソースコードとは異なり、依存関係のあるアーティファクトの取得・紐付けが確定した状態
    ▪ 一度ビルドされたら本番デプロイまで使い続ける(問題があれば別のアーティファクトを生成)
    コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用
    アーティファクトが使われ続ける
    (1度生成したら本番デプロイまで同じものを使う )
    アーティファクト誕生

    View full-size slide

  13. 特徴2: ビルドするごとに形が変わる
    13
    ▪ ソースコードが変化しなくとも、ビルド時に同じアーティファクトが生成されるとは限らない
    ○ 使用するOSSのアーティファクトが異なるなど、依存関係のバージョン違い
    ■ 依存するアーティファクトのバージョン指定が曖昧な場合、更新によって結果が変わる
    ■ 依存するアーティファクトが使用している別のアーティファクトが変更される場合も同様に結果が変わ

    ○ 環境変数で指定されている値が異なるなど、ビルド環境や実行環境の設定違い
    ■ ビルド時に環境情報を埋め込む場合、結果が変わる
    ソースコードは、システムを形作る上で重要!
    ただし、環境に応じた情報を扱ったり曖昧な定義ができるも
    のも可能な場合が多い。 (これが悪いわけではない。 )
    アーティファクトの生成時に状況が変わり、同じ結果がえられ
    ないかもしれないということを認識しているのは重要!

    View full-size slide

  14. 特徴3: 数も種類も増え続けている
    14
    ▪ アジャイル開発やCI/CDの広がり
      → ビルド回数が増えており、都度アーティファクトが
        生成される
    ▪ OSSなどのサードパーティが作成したアーティファクトの活用
      → 配布されるアーティファクトが増加している
    ▪ サーバレスなアーキテクチャやマイクロサービスの広がり
      → 1システムで利用するサービスが複数あり、
        それぞれで使用されるアーティファクトが異なる
    ▪ IaC(Infrastructure as Code)やコンテナ技術の活用
      → 実行環境そのものがアーティファクトとして
        扱われるようになった
    ▪ IoTの普及
      → 1つのシステムに必要なデバイスが増加している
    Docker / K8s / Serverless
    Microservices
    DevOps
    CD
    CI
    IoT
    2000
    Today

    View full-size slide

  15. 特徴4: アーティファクトの特徴が一見してわからない
    15
    ▪ 多くの場合、アーティファクトはバイナリ形式であり、その内容を読むことができない
    ○ いつ、だれが、どの環境で作られたものか、信頼できるものかわからない
    ○ アーティファクトは何で構成されているのか捉えるのが難しい
    ▪ ソースコードと同じよう差分を取ることができない
    ○ ビルドによって生成されるのがバイナリファイルの場合はそもそも不可
    ○ ビルドによって生成されたのが複数ファイルの場合、全体を差分を取ることは難しい
    ▪ アーティファクトはメタデータで特徴を示す
    ○ いつ、だれが、どの環境で作った、などビルドにまつわる情報を指す
     → アーティファクトの特徴として利用し、他との区別に利用する
    ○ メタデータを比較することで差分を取ることが可能
     → 以前のビルドとの差異を確認することができ、問題発生時の助けになる

    View full-size slide

  16. アーティファクト管理の必要性
    16
    特徴1
    コンピュータ上の実行形式である
    特徴2
    ビルドするごとに異なるものが作成される
    特徴3
    数も種類も増え続けている
    特徴4
    アーティファクトの特徴が一見してわからない
    実行環境で利用するアーティファクトを素早く特定
    する必要がある
    いつ、どのような状態で作られたアーティファクトか
    を把握する必要がある
    個々のアーティファクトを独立して管理するのでは
    なく、まとめて管理する必要がある
    ● 数多く生成されるアーティファクトの中から、正しいものを選択し
    てテストやリリースしたり、本番環境での問題解決を行うため、特
    定や検索が行えるようにする
    ● 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と
    いった特徴をメタデータを保持する必要がある
    ● アーティファクトの生成過程を知るための情報であり、アーティ
    ファクトの信頼性にも繋がる
    ● システムの構成が複数サービスを利用する場合、組み合わせを
    含めて管理することで品質が向上できる
    ● 依存関係として利用する OSSなどのサードパーティ製のアーティ
    ファクトも管理が必要

    View full-size slide

  17. アーティファクト管理の必要性
    17
    特徴1
    コンピュータ上の実行形式である
    特徴2
    ビルドするごとに異なるものが作成される
    特徴3
    数も種類も増え続けている
    特徴4
    アーティファクトの特徴が一見してわからない
    実行環境で利用するアーティファクトを素早く特定
    する必要がある
    いつ、どのような状態で作られたアーティファクトか
    を把握する必要がある
    個々のアーティファクトを独立して管理するのでは
    なく、まとめて管理する必要がある
    ● 数多く生成されるアーティファクトの中から、 正しいものを
    選択してテストやリリースしたり、本番環境での問題解決を行うた
    め、特定や検索が行えるようにする
    ● 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と
    いった特徴をメタデータを保持する必要がある
    ● アーティファクトの生成過程を知るための情報(トレーサビリティ)
    であり、アーティファクトの信頼性にも繋がる
    ● システムの構成が複数サービスを利用する場合、組み合わせを
    含めて管理することで品質が向上できる
    ● 依存関係として利用する OSSなどのサードパーティ製のアーティ
    ファクトも管理が必要

    View full-size slide

  18. アーティファクト管理の必要性
    18
    特徴1
    コンピュータ上の実行形式である
    特徴2
    ビルドするごとに異なるものが作成される
    特徴3
    数も種類も増え続けている
    特徴4
    アーティファクトの特徴が一見してわからない
    実行環境で利用するアーティファクトを素早く特定
    する必要がある
    いつ、どのような状態で作られたアーティファクトか
    を把握する必要がある
    個々のアーティファクトを独立して管理するのでは
    なく、まとめて管理する必要がある
    ● 数多く生成されるアーティファクトの中から、正しいものを選択し
    てテストやリリースしたり、本番環境での問題解決を行うため、特
    定や検索が行えるようにする
    ● 一度生成されたら不変的 であり、「いつ」「誰が」「何を」「どこで」と
    いった特徴をメタデータを保持する必要がある
    ● アーティファクトの生成過程を知るための情報であり、アーティ
    ファクトの信頼性にも繋がる
    ● システムの構成が複数サービスを利用する場合、組み合わせを
    含めて管理することで品質が向上できる
    ● 依存関係として利用する OSSなどのサードパーティ製のアーティ
    ファクトも管理が必要

    View full-size slide

  19. アーティファクト管理の必要性
    19
    特徴1
    コンピュータ上の実行形式である
    特徴2
    ビルドするごとに異なるものが作成される
    特徴3
    数も種類も増え続けている
    特徴4
    アーティファクトの特徴が一見してわからない
    実行環境で利用するアーティファクトを素早く特定
    する必要がある
    いつ、どのような状態で作られたアーティファクトか
    を把握する必要がある
    個々のアーティファクトを独立して管理するのでは
    なく、まとめて管理する必要がある
    ● 数多く生成されるアーティファクトの中から、正しいものを選択し
    てテストやリリースしたり、本番環境での問題解決を行うため、特
    定や検索が行えるようにする
    ● 一度生成されたら不変的であり、「いつ」「誰が」「何を」「どこで」と
    いった特徴をメタデータを保持する必要がある
    ● アーティファクトの生成過程を知るための情報であり、アーティ
    ファクトの信頼性にも繋がる
    ● システムの構成が複数サービスを利用 する場合、組み合わせを
    含めて管理することで品質が向上 できる
    ● 依存関係として利用する OSSなどのサードパーティ製のアーティ
    ファクトも管理が必要

    View full-size slide

  20. 20
    アーティファクトの管理方法

    View full-size slide

  21. アーティファクトをどう管理すべきか
    21
    ▪ 案1: ファイルサーバでの管理:フォルダ構造やファイル命名規則などの一定ルールを設けて管理
    ○ 命名規則やフォルダ構造に意味があるため、場所・名前で一定判別できる
    ○ ファイル名以外の情報が得られず、組み合わせなどの情報が管理できない
    ○ 自動化の際に検討事項が多い(APIをどうするかなど)
    ▪ 案2: VCSでの管理:ソースコード同様にGitなどのVCSを使った管理
    ○ バージョン管理としての基本的な機能が備わっている
    ○ アーティファクトの特徴を保持できず、検索が難しい
    ○ バイナリファイルの管理時に、容量消費が大きい
    ▪ 案3: バイナリ・リポジトリでの管理

    View full-size slide

  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)
    例:

    View full-size slide

  23. JFrog Artifactoryのご紹介
    23
    ▪ JFrogが提供するバイナリ・リポジトリマネージャ
    ○ クラウド・オンプレミス双方設置可能
    ▪ Artifactoryの特徴
    ○ 高いユニバーサル性
    ■ 30以上のパッケージマネージャに対応
    ○ メタデータ管理が容易
    ■ ビルド情報以外にもGitのバージョンやテスト状況など、
    メタデータを追加で持たせることが可能
    ○ ストレージ最適化
    ■ チェックサムを用いたファイル管理
    ○ Platform外部のツールとの統合が容易
    ■ APIや専用CLI、プラグインなどを提供

    View full-size slide

  24. 24
    開発/運用におけるアーティファクト管理の重要性

    View full-size slide

  25. 開発現場でよくある実情
    25
    ▪ 外部パッケージ・ライブラリの利用
    ○ 98%のシステム開発でOSSを活用(*1)し、開発の効率化・高速化が図られている
    ○ 自社開発したパッケージやライブラリの利用するケースがある(例:共通部品)
    ○ 開発者は、パッケージマネージャを利用してインターネットから取得したり、ファイルサーバから取得し
    て配置するなどする
    ▪ ビルド方法(アーティファクトを生む方法)
    ○ ビルド担当者を置き、その人の環境でのみ有効なものを作る
    ○ CIサーバを利用して自動化
    ▪ ビルドタイミング(アーティファクトが生まれるタイミング)
    ○ 開発者のソースコードがマージされたタイミングで1回実施し、アーティファクトを使い回す
    ○ 環境配置の都度ビルドを行い、生成されたアーティファクトは1回のみ利用
    *1: MONOist 「オープンソースソフトウェアの採用率は
    98%に拡大、脆弱性を含む割合も増加の一途」
    https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html

    View full-size slide

  26. ある現場でのシステム開発の流れ
    26
    VCS
    ファイルサーバ
    開発チーム
    ビルド・デプロイ担当者 運用担当者
    アーティファクト
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③ビルドして
     アーティファクトを
     生成する
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    ⑤QA実施
    ⑥アーティファクト
     を保管する
    ⑦開発チームの
     依頼に基づき、
     アーティファクトを
     本番環境にデプロイ
     (リリース)する
    ②開発したコードを
     保管する

    View full-size slide

  27. 開発チームにおけるよくある課題
    27
    VCS
    ファイルサーバ
    開発チーム
    ビルド・デプロイ担当者 運用担当者
    アーティファクト
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③ビルドして
     アーティファクトを
     生成する
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    ⑤QA実施
    ⑥アーティファクト
     を保管する
    ⑦QAで問題なければ
     保管されていた
     アーティファクトを
     本番環境にデプロイ
     (リリース)する
    ②開発したコードを
     保管する
    課題 アーティファクト管理のメリット
    (特にバイナリ・リポジトリを利用した場合)
    依存するアーティファクトを開発者自身が取得・配置
    することで、誤ったものを利用する可能性がある
    ❏ 一元管理された場所を作ることで、正しいものを迷
    わず取得できる
    ❏ SCAなどと組み合わせて利用することで脆弱性の
    チェックできる(シフトレフト)
    ネットワークの問題などでインターネット経由で依存
    するアーティファクトが取得できない
    ❏ インターネット経由で取得するものに対してプロキ
    シ・キャッシュとして機能し、外部の状況に左右さ
    れずに対象を取得可能
    外部公開されていないが、自社開発で共通利用する
    アーティファクトの管理が煩雑
    ❏ 細かなアクセス管理が可能
    ❏ 監査時の情報収集が比較的容易
    開発者が自身で環境設定を行うため、環境差異が
    発生する可能性がある
    ❏ メタデータによる差分比較により、アーティファクト
    の生成過程での差異を発見することができる

    View full-size slide

  28. ビルドにおけるよくある課題
    28
    ファイルサーバ
    ビルド・デプロイ担当者 運用担当者
    アーティファクト
    ③ビルドして
     アーティファクトを
     生成する
    トを
    デプロイ
    アーティファクト
    ⑤QA実施
    ⑥アーティファクト
     を保管する
    ⑦QAで問題なければ
     保管されていた
     アーティファクトを
     本番環境にデプロイ
     (リリース)する

    課題 アーティファクト管理のメリット
    (特にバイナリ・リポジトリを利用した場合)
    依存するアーティファクトを開発者自身が取得・配置
    することで、誤ったものを利用する可能性がある (開
    発と同じ)
    ❏ 一元管理された場所を作ることで、正しいものを迷
    わず取得できる
    ネットワークの問題などでインターネット経由で依存
    するアーティファクトが取得できない (開発と同じ)
    ❏ インターネット経由で取得するものに対してプロキ
    シ・キャッシュとして機能するため、外部の状況に
    左右されずに対象を取得可能
    ❏ 外部ネットワークへの接続が減ることによるネット
    ワーク負荷の軽減
    依存するアーティファクトがビルドを要するものの場
    合、全体のビルド完了までに時間がかかる
    ❏ ビルド済みのアーティファクトを取得可能であり、
    時間短縮が可能
    ❏ メタデータを用いた検索可能であり、特定に時間に
    かかる時間を短縮
    新たに生成したアーティファクトの管理が煩雑(例
    :
    ファイルサーバで管理する場合、命名規則などに
    従って配置する必要がある)
    ❏ システム開発全体で使用可能な名前のまま保管
    でき、煩わしさが軽減
    ❏ 他チームに配布する場合の取得元としてそのまま
    利用可能

    View full-size slide

  29. 運用におけるよくある課題
    29
    運用担当者
    アーティファクト
    ⑦開発チームの
     依頼に基づき、
     アーティファクトを
     本番環境にデプロイ
     (リリース)する
    課題 アーティファクト管理のメリット
    (特にバイナリ・リポジトリを利用した場合)
    リリースすべきパッケージ・ライブラリが、誤ったもの
    を利用する可能性がある
    (開発と同じ)
    ❏ 一元管理された場所を作ることで、正しいものを迷
    わず取得できる
    リリース後に問題があった場合の切り戻し作業が発
    生した際、使用すべきアーティファクトの取得に時間
    がかかる
    ❏ すべてのアーティファクトが保管されているため、
    直前のバージョンの特定が容易
    ❏ 稼働実績のあるアーティファクトをそのままリリー
    ス可能であるため、対応を早くできる
    実行環境で問題が発生した場合、問題発生の原因
    を特定するのに時間を要する可能性がある
    ❏ メタデータを利用して依存関係や他の環境との差
    分を確認することができ、問題特定が容易になる
    外部パッケージ・ライブラリの脆弱性情報に対して、
    素早く対応できない
    (開発チームに問い合わせるなど、確認に時間を要
    する)
    ❏ 開発側から積み重ねられたメタデータを元にした
    SCAにより、問題の有無の認識が早められる
    ❏ 開発側と問題のあるアーティファクトや付随する情
    報の共有が容易になる

    View full-size slide

  30. まとめ
    31
    ▪ アーティファクトとは
    ○ ビルドやパッケージングを経て生成されるファイル
    ○ 特徴:コンピュータ上の実行・配布形式である、ビルドごとに形が変わる
       数も種類も増え続けている、一見してどんなものなのかわからない
    ○ 一度生成されると不変であり、上記の特徴を考慮した適切な管理が重要
    ▪ アーティファクトの管理方法
    ○ バイナリ・リポジトリを使った管理は、アーティファクトの特徴を考慮した管理が可能
    ■ 一元管理、メタデータの保管と活用、高度なアクセス管理
    ○ JFrog Artifactoryによる管理のご紹介(おすすめ!)
    ▪ 開発/運用におけるアーティファクト管理の重要性
    ○ 適切なアーティファクト管理を行うことで、さまざまな課題の解決に繋がる

    View full-size slide

  31. アーティファクト管理が支える3つのポイント
    32
    1. エンジニアの負荷軽減
    ○ 開発のための環境構築における外部アーティファクト準備に対する負荷軽減
    ○ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減
    ○ 新たなアーティファクトを生成する際のビルドにかかる時間短縮
    2. システム開発におけるコンプライアンスの向上
    ○ メタデータを利用したビルドにかかるトレーサビリティの確保
    ○ OSSなどの外部アーティファクトの取得元として利用することで均一化と、
    脆弱性などの問題に対する初動対応の迅速化
    ○ アーティファクトに対するアクセス管理や監査対応に対しても有効
    3. 開発・運用のギャップが埋められる
    ○ メタデータを通じた相互理解、情報共有が容易になる
    ○ DevOps(DevSecOps)導入の一歩として、機械的な作業は自動化するとより効果が得られる

    View full-size slide

  32. 今後開催のウェビナーのお知らせ
    33
    こちらをチェック!
    https://jfrog.connpass.com/

    View full-size slide

  33. 参考文献
    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

    View full-size slide