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

Developer Experience向上のために知っておきたい「アーティファクト」

Developer Experience向上のために知っておきたい「アーティファクト」

2022/10/20 JFrog Webinar

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

このウェビナーでは、開発者がソフトウェア開発を通して感じる”Developer Experience”を高めるために知っておいてほしいソフトウェアの「アーティファクト」について、それがどんなものなのかからお話しします。

Yoshihisa Sato

October 20, 2022
Tweet

More Decks by Yoshihisa Sato

Other Decks in Technology

Transcript

  1. はじめに 2 Twitterが好きな方は #JFrog 公開後、本ウェビナーに ご登録いただいたメール宛に お知らせします #JFrog ぜひツイートをお願いします 本日の資料と動画は

    のちほど公開します! Zoom機能で ぜひ、ご参加ください! Q&A機能でご質問を 書き込んでください いつでも、何度でも! チャットもご自由に お使いください ・ ご自身の現場のお話 ・ 賑やかしなど・・・ Q&A チャット
  2. 自己紹介 3 ▪ Developer Advocate @ JFrog ▪ 「よしQ」と覚えていだけるとうれしいです ▪

    山形県鶴岡市からリモートワーク ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン サルなど経験 ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで ▪ エンジニア目線で情報発信! 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato
  3. Developer Experience 5 Developer Experience(DX) 開発者が製品を開発する際に感じる体験・経験 *1: DX用語時点 Developer Experience

    https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ 開発環境 組織 システム 評価体制
  4. このセッションにおける「アーティファクト」 9 ▪ アーティファクト:ビルドやパッケージングを経て生成される実行形式、または配布形式のファイル ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある JAR/WARパッケージ (Java) RPM/DEB パッケージ

    (Linux) Docker イメージ npm (JavaScript) PyPl パッケージ (Python) RubyGems (Ruby) ZIP/tarball ファイル ダイナミックリンク ライブラリ(DLL) (Windows) NuGet パッケージ (.NET) Go Module (Go) 例:
  5. 特徴1: コンピュータ上の実行・配布形式である 11 ▪ アーティファクト=ビルドによって生成されるコンピュータ上の実行・配布形式 ◦ コンパイル型言語の場合、バイナリファイルが出力 ◦ インタプリタ型言語の場合、実行形式のファイルが出力 ◦

    OSSとして配布される場合、主にバイナリファイルの形(ソフトウェア開発において、 98%がOSSを活用(*2)) ▪ ソースコードとは異なり、依存関係の解決が確定した状態 ▪ 一度ビルドされたら本番デプロイまで使い続け、ビルド以降のテストから運用までの各工程で使われる コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクトが使われ続ける (1度生成したら本番デプロイまで同じものを使う ) アーティファクト誕生 *2: MONOist 「オープンソースソフトウェアの採用率は 98%に        拡大、脆弱性を含む割合も増加の一途」 https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html
  6. 特徴2: ビルドするごとに形が変わる 12 ▪ ソースコードが変化しなくとも、ビルド時に同じアーティファクトが生成されるとは限らない 依存関係のバージョン違い ビルド環境や実行環境の設定違い 時点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のバージョンが異なる (最新バージョンが出るなど ) ビルド時に環境変数を埋め込む場合、端末による設定違い アーティファクト アーティファクト 環境変数 LIB=AAA,BBB SOME_VALUE1=XXXX SOME_VALUE2=YYYY … 環境変数 LIB=AAA,BBB,CCC SOME_VALUE1=XXXX SOME_VALUE2=ZZZ … 端末A 端末B
  7. 特徴3: 数も種類も増え続けている 13 ▪ アジャイル開発やCI/CDの広がり   → ビルド回数が増えており、都度アーティファクトが     生成される ▪

    OSSなどのサードパーティが作成したアーティファクトの活用   → 配布されるアーティファクトが増加している ▪ サーバレスなアーキテクチャやマイクロサービスの広がり   → 1システムで利用するサービスが複数あり、     それぞれで使用されるアーティファクトが異なる ▪ IaC(Infrastructure as Code)やコンテナ技術の活用   → 実行環境そのものがアーティファクトとして     扱われるようになった ▪ IoTの普及   → 1つのシステムに必要なデバイスが増加している Docker / K8s / Serverless Microservices DevOps CD CI IoT Today 2000
  8. 特徴4: どんなアーティファクトか一見してわからない 14 ▪ アーティファクトはメタデータで状態を示し、他と区 別する ◦ いつ、だれが、どの環境で作った、などビル ドにまつわる情報 ◦

    構成に含まれる依存関係の情報 ▪ メタデータを比較により差分を取る ▪ 内容を読むことができない ◦ 構成要素を捉えるのが難しい ◦ 信頼できるものかわからない ▪ 差分を取ることができない ◦ バイナリファイルの場合、そもそも不可 ◦ 複数ファイルの場合、全体比較が難しい 01010101010010100100 10010101010100101010 10101010010101010101 00101001010101010010 011101010101010010… 作成日 作成者・作成環境 依存関係 設定情報
  9. システム開発におけるアーティファクト管理の必要性 15 利用するアーティファクトを 素早く特定する必要がある アーティファクト作成の背景を把 握する必要がある 利用するアーティファクトを まとめて管理する必要がある • 数多く生成されるアーティファクトの中か

    ら、正しいものを選択して テストやリリー スする必要がある • メタデータを検索することで、 特定できる ようになる • 一度生成されたら不変的 であり、 「いつ」「誰が」「何を」「どこで」といった情 報を保持する必要がある • 生成過程がわかることで、 信頼性向上 • 問題解決のための情報 としても活用でき る • システムの構成が複数サービスを 利用する場合、組み合わせを含めて管 理する必要がある • 依存関係で使用するもの などの外部 アーティファクトも管理が必要 • ビルド回数を減らし効率化できる • テスト確認できたものを管理することで 品質向上につながる 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 作成環境 設定情報 …. 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 依存関係 取得元 … アーティファクトそのものだけではなく、メタデータと合わせて管理
  10. ソースコード管理とアーティファクト管理の違い 17 コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生

    開発 開発 開発 開発 QA 運用 運用 ソースコード管理が 必要な範囲 アーティファクト管理が 必要な範囲 ソースコード管理 ▪ コーディングを行う間に必要(可変) ▪ 開発担当間のコラボレーションを促進 ◦ バージョン管理、トラッキング、ブランチ、タグ... アーティファクト管理 ▪ ビルド後からずっと管理が必要(不変) ▪ 開発担当〜QA担当〜運用担当といった 組織・責務を横断したコラボレーションを促進 ◦ メタデータ(ビルドにまつわる情報)を中心とした情報を共有 どちらも重要
  11. ある現場で行われる開発の流れ 18 VCS 開発チーム 運用担当者 ①開発チームで  複数メンバーの  ソースコード開発 ③CIサービスがソースコードと、  外部で配布されている依存する

     パッケージ(外部アーティファクト )を  取得・ビルドしてアーティファクトを  生成する ⑤QA担当者が    QA実施 ⑥開発チームが  アーティファクトを  所定の場所に  保管する ⑦運用チームが  開発チームの依頼に基いて  アーティファクトを取得し、  本番環境にデプロイ  (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが  開発したコードを  VCSに保管する ④アーティファクトを  テスト環境に  デプロイ
  12. システム開発時に起こりうる問題 19 VCS 開発チーム 運用担当者 ①開発チームで  複数メンバーの  ソースコード開発 ③CIサービスがソースコードと、  外部で配布されている依存する

     パッケージ(外部アーティファクト )を  取得・ビルドしてアーティファクトを  生成する ⑤QA担当者が    QA実施 ⑥開発チームが  アーティファクトを  所定の場所に  保管する ⑦運用チームが  開発チームの依頼に基いて  アーティファクトを取得し、  本番環境にデプロイ  (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが  開発したコードを  VCSに保管する ④アーティファクトを  テスト環境に  デプロイ 昨今は脆弱性をつくようなセキュリティに 対する課題も多く挙がっている 自動化されている範囲が 限定的で、手作業も多い デプロイや実行時エラーの 原因究明で遅延 システム不具合で切り 戻しが発生する場合、戻 すアーティファクトも開発 側の申請ベース いずれの課題も開発側の戻ってくることが多く、DXの低減に繋がる可能性 前バージョンでビルドできたが、 新バージョンでビルドに失敗した際の原 因究明で遅延
  13. 良いDXを生むための4つのファクター 20 1. アーキテクチャの適合 ◦ プロジェクトやチームに合わせて適切なアーキテクチャを選択する 2. 優れたツール ◦ 繰り返し行う必要があることは自動化していく

    3. すべてをバックアップするプロセス ◦ 自動化されたチェックリストとして、毎回行うべき一貫した手順を定義する 4. 毒のないチーム文化 ◦ 会社の存在意義、共通のゴールや社会へのインパクトなどを共有し、失敗も許容する *1: DX用語時点 Developer Experience https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ *3: Developer Experience.io Good Developer Experience https://developerexperience.io/practices/good-developer-experience
  14. アーティファクト管理のDX向上のための対応ポイント 21 ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生 開発

    開発 開発 QA 運用 運用 2. 優れたツール: ツールの活用と自動化 4. 毒のないチーム文化: チーム文化の醸成 1. アーキテクチャの適合 2. 優れたツール 3. すべてをバックアップするプロセス 4. 毒のないチーム文化 3. すべてをバックアップするプロセス: 各担当が責任を果たせるようなプロセスの整備
  15. JFrog Platformの活用例 22 VCS 開発チーム ①開発チームで  複数メンバーの  ソースコード開発 ③CIサービスがソースコードと、  外部で配布されている依存する

     パッケージ(外部アーティファクト)を  取得・ビルドしてアーティファクトを  生成する ⑤QA担当者が  QA実施し、  問題なければ  プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが  QA結果を受けて  本番環境にデプロイ  (リリース)する 運用担当者 ②開発チームが  開発したコードを  VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の  プロモーションにより  本番用に自動コピー  (メタデータ含む) ※ビルドにより生成 ※キャッシュ提供  による高速化 ④アーティファクトを  テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境
  16. JFrog Platform全体を活用したときの課題への対応 23 VCS 開発チーム ①開発チームで  複数メンバーの  ソースコード開発 ③CIサービスがソースコードと、  外部で配布されている依存する

     パッケージ(外部アーティファクト)を  取得・ビルドしてアーティファクトを  生成する ⑤QA担当者が  QA実施し、  問題なければ  プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが  QA結果を受けて  本番環境にデプロイ  (リリース)する 運用担当者 ②開発チームが  開発したコードを  VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の  プロモーションにより  本番用に自動コピー  (メタデータ含む) ※ビルドにより生成 ※キャッシュ提供  による高速化 ④アーティファクトを  テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 メタデータ メタデータ メタデータ 全体でツール活用による 自動化への移行が可能 開発はもちろん、 運用時もスキャンし、 セキュリティに配慮 メタデータ 問題発生時、 メタデータを利用して 自 律的に調査が可能 メタデータを使って過去 情報も簡単に探せるので、 切り戻しへの初動が早い メタデータ ビルド失敗時、前バージョンのメタデータと比較 し、原因ポイントを探しやすい
  17. アーティファクト管理によるDX向上にむけた効果 25 1. 開発に関わる全てのエンジニアの負荷軽減 ◦ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減 ◦ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる(=負荷軽減) 2. システム開発におけるリスクの低減

    ◦ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保 ◦ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題 に対する初動対応の迅速化 3. フェーズ間のギャップが埋められる ◦ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援 ◦ DevOps(DevSecOps)の一歩として、機械的な作業は自動化するとより効果が得られる
  18. JFrog Platformの全体像 31 監視、設定、管理者ダッシュボード インテリジェンスメトリクスの分析 すべてのソフトウェアパッケージと コンテナイメージを保存、管理 セキュリティとコンプライアンスの問題 解決 (OSS脆弱性・ライセンス問題のチェッ

    ク) クラウド、データセンターへ 安全なソフトウェア配布 デバイスフリートへの ソフトウェアデプロイ、運用、監視 エンドツーエンドの CI/CD自動化とオーケストレーション BUILD & TEST RELEASE DEPLOY VCS ソースコード リポジトリ On-premise and Hybrid Regional Sites Public Cloud Platforms IoT Edge 本日使用するもの
  19. JFrog Artifactoryのご紹介 32 ▪ JFrogが提供するバイナリ・リポジトリマネージャ ◦ アーティファクト管理に適した機能を用意 ▪ Artifactoryの特徴 ◦

    高いユニバーサル性 ▪ 30以上のパッケージマネージャに対応 ◦ メタデータ管理が容易 ▪ ビルド情報以外にもGitのバージョンやテスト状況など、 メタデータを追加で持たせることが可能 ◦ ストレージ最適化 ▪ チェックサムを用いたファイル管理 ◦ Platform外部のツールとの統合が容易 ▪ APIや専用CLI、プラグインなどを提供
  20. JFrog Xrayのご紹介 33 ▪ JFrog Artifactoryと統合されたSCAソリューション ◦ Artifactoryに保存されているアーティファクトを分析する ▪ Xrayの特徴

    ◦ 高いユニバーサル性 ▪ 主要なパッケージタイプをサポート ◦ 再帰的なスキャンの実施 ▪ Dockerイメージやzipファイルでパッケージ化されたものを含めて、 ベースレイヤーだけでなく、推移的依存関係を含めて確認できる ◦ タイムリーかつ包括的な脆弱性データベースを利用 ▪ VulnDB + NVD + JFrog Security Research ◦ 継続的なモニタリング ▪ 本番環境デプロイ後もスキャン可能
  21. JFrog Pipelinesのご紹介 34 ▪ ワンストップDevOpsのためのEnd-to-EndでCI/CDを実現 ◦ サイロ化されたDevOpsツールを一元化 ▪ Pipelinesの特徴 ◦

    リアルタイム可視性 ▪ ダッシュボードでCI/CDの状況が確認可能 ◦ Pipelines-as-Code ▪ YAML構文でステップを標準化 バージョン管理、モジュール化され再利用可能 ◦ セキュリティ・ファースト ▪ パスワード情報などのシークレット管理、きめ細かなアクセス管理 ◦ エンタープライズ対応 ▪ 水平方向への拡張、HA環境サポート、集中管理型 リアルタイム可視性 Pipelines設定ファイル