アーティファクトリポジトリーとは

アーティファクトリポジトリーは、ビルドおよびデプロイメントプロセスで生成されたアーティファクトを安全に保管します。主な検討事項について今すぐご確認ください。

ソフトウェア開発プロセスにおいて、アーティファクト管理は欠かすことのできない重要な要素です。 ビルドプロセスを通じてアーティファクトが作成され、継続的インテグレーションプロセスが完了すると、新しいアーティファクトが作成・保存され、継続的デリバリープロセスがそれを受け取り、本番環境につながるさまざまな環境を通じてアーティファクトを促進できるようにします。アーティファクトは、デリバリープロセスの生命線であり、パフォーマンス、一貫性、および持続可能な結果を得るためには、よく考えられたアーティファクト管理が必要です。バージョン管理、セキュリティー、依存関係管理は、CI/CDプロセスの途中で提供される重要な利点の序の口に過ぎません。

アーティファクトリポジトリーとは

アーティファクトリポジトリーの中核的な機能は、生成されたアーティファクトを安全に保管することです。これらのアーティファクトは、ビルド時の最適化や、最終的な配布に使用されます。コンテナイメージ、バイナリーアーティファクト、Javaアーティファクト、ソフトウェアパッケージは、管理する必要があるアーティファクトの種類のほんの一例です。これは、ソースコード管理とは異なる機能で、アーティファクトは別個のオブジェクトとして扱われ、バージョン管理されます。

アーティファクトリポジトリーの使用例

簡潔にするために（読む時間の短縮のためにも）、現代のDevOpsで遭遇する最も一般的な２つのハイレベルなユースケースに焦点を当てることにします。使用するツールは重複することもあれば、全く異なることもあります。

ビルドのアーティファクト

ほとんどの複雑なソフトウェアシステムの場合、ビルドには複数の段階、多くの依存関係、そしてデプロイメントを目的としたアーティファクトを作成するための複数のコンポーネントがあります。ビルドツールは、これらの依存関係を管理し、ソースコードからコンパイルされたバイナリーアーティファクトまでのプロセスを最適化するためのフレームワークを提供します。注目すべきビルドツールには、Maven、Gradle、Make、Bazel、および多くの言語とユースケースに特化したアーティファクト管理ツールが含まれます。

 デプロイメントのアーティファクト

中間アーティファクトとは異なり、デプロイメントアーティファクトはバージョン管理され、セキュリティー保護され、唯一の信頼できる情報源として一元管理されます。通常、リモートリポジトリーとして構成され、CIからCDへのハンドオフ地点として使用されます。コンテナイメージは最も一般的なフォーマットの１つになりつつありますが、バイナリーやHelmチャートのような構成も非常によく使われています。今日、最も人気のあるリポジトリーは、DockerHub、ECR、JFrogなどです。

アーティファクトリポジトリーに関する主な考慮事項

どのリポジトリーがニーズを満たすか決める際、見るべき最も重要な項目のいくつかをまとめてみます。

中央集中型と分散型

セキュリティー上の理由と効率性から、リポジトリーをどこに設定するかが重要です。集中型、ローカルキャッシュ利用型、分散型／公開型があります。ガバナンスと簡素化のために、集中型のリモートリポジトリーを使用すると、どのソフトウェアが使用されているかを詳細に追跡し、リリースプロセスを合理化することができます。集中化のトレードオフとして、パフォーマンスが低下する可能性があり、異なる地域間でアーティファクトのプッシュとプルに時間がかかる場合があります。

ローカルに管理されたリポジトリーはより高性能ですが、サーバー、ソフトウェア、ストレージを管理するためのオーバーヘッドが発生します。クラウドプロバイダーがユビキタス化するにつれ、異なる地域にあるデータを一元化してホストすることで、パフォーマンスを向上させることができるようになります。

バージョニング対応

命名規則だけでなく、日付、バージョン、その他の一般的な属性などのメタデータを適切に保存することで、適切な文書化とトレーサビリティーを実現できます。アドホックな手法が好まれなくなったのとは対照的に、個別のアーティファクトは、間違ったコードがデプロイされるリスクや、何がいつデプロイされたかを監査する能力が失われるリスクを低減します。

アクセス権

レイヤーにおけるセキュリティーはベストプラクティスであり、アーティファクトを保護するための多くの方法の１つは、アーティファクトの保存と配布の方法を制御することです。 ロールベースアクセス制御（RBAC）は、誰がどのリポジトリーにアーティファクトを保存できるか、そして誰が同じアーティファクトを引き出せるかを規定する必要があります。

監査可能性

バージョニングとパーミッションの融合。監査可能性とは、アクセス、アーティファクトの履歴、アーティファクトに影響を与えるその他のイベントに関する完全な証跡を持つことを意味します。

スキャニング

よく設計されたソフトウェアデリバリープロセスの一部として、アーティファクトリポジトリーは、コードが実運用に入る直前の便利なボトルネックとなります。サーバーに送られる全てのものがリポジトリーを通過しなければならない場合（アドホックなホットフィックスができない）、運用では出荷前にアーティファクトのあらゆる側面を精査することができます。これには、脆弱なライブラリーや悪意のあるコードを探すセキュリティースキャン、ライセンス使用の検証などが含まれます。

ソフトウェア部品表（SBOM）

部品表（BOM）は、物理的な製品の近代的な製造に不可欠な要素となっています。ソフトウェアがより複雑になり、サードパーティーのライブラリーに依存するようになると、ソフトウェアチームは、複雑なシステムを構築するために必要な全てのコンポーネントをコンパイルして理解する時間がなくなります。全ての情報を収集するプロセスはソフトウェア開発にまたがっており、本番環境に向けたソフトウェアの構築に使用された全コンポーネントの完全なインベントリーを取得する最終的なゲートとなるのがリポジトリーです。

アーティファクトリポジトリーの種類

可能なアーティファクトは無数にあり、ここで全てを網羅することはできません。特定のアーティファクトのための優れたツールがありますし、普遍的なパッケージリポジトリーマネージャーもあります。ここでは、最も一般的なカテゴリーを簡単にリストアップしています。

コンテナイメージ

Docker化が進む中、このカテゴリーは開発チームにとって急速に最重要視されるようになってきています。コンテナの主な利点は、全てのコードと依存関係を１つにして出荷できることです。一方、大きなアーティファクトや出荷の脆弱性が抽象化されたいくつかの層の下に隠されている可能性があることが欠点です。このカテゴリーで最も優れたツールは、レイヤーの適切な保存を解決し、潜在的な脆弱性をスキャンする機能を提供します。

ビルドのリポジトリー

Mavenリポジトリーはよく知られた例です。中間アーティファクトのためにローカルで使用されるだけでなく、一般に公開されている多くのリポジトリーを含め、リモートでも使用されています。

アプリケーションパッケージリポジトリー

Pip、npm、Ivyなどのパッケージ管理ツールは、PyPiやnpmrepositoryなど、言語／技術に特化した多種多様なパッケージマネージャーに依存しています。

アーティファクトリポジトリーの管理ツールにはどのようなものがあるか

ここでは、現在チームで使用されているさまざまなツールの一部を紹介します。このトピックがいかに広いかを考えると、これらは全て競合するツールではなく、アーティファクト管理のさまざまな側面に触れるツールであると言えます。

Apache Maven

Mavenは、Javaに最もよく使用されますが、他の言語をサポートするために使用することも可能です。Mavenは、主にソフトウェアのビルドと依存関係の管理を担当します。Mavenプロジェクト内では、依存関係やその他のビルド情報はXMLファイルに記述されます。ビルドプロセスの一部として、MavenはリモートMavenリポジトリーからライブラリーをダウンロードします。

Bazel

2015年にGoogleからリリースされ、驚異的なスピードと依存関係グラフ解析による優れた依存関係管理で瞬く間に人気となりました。Harnessでは、最近、開発プロセスを加速させるために、MavenからBazelに切り替えました。要するに、Mavenが提供する依存関係の管理の多くは、動きの速い組織である私たちのニーズに合っていなかったのです。Bazelでは、Bzlmodの助けを借りて、パブリックとプライベートの両方の外部依存関係を使用することもできます。

Dockerイメージリポジトリー

ここで１つだけ選ぶのは難しいです。AmazonのECR、GoogleのGCR、AzureのACRなど、各クラウドプロバイダーが独自に提供しています。もし、これらが合っていなくても、素晴らしいツールがたくさんあります。JFrog Artifactoryは多くのパッケージフォーマットを提供し、Dockerhubはデフォルトのリポジトリーとして選ばれています（名前に書いてありますね！）また、VMWareのHarborはセキュリティーを考慮して構築されたオープンソースのオプションです。

CI/CDにおけるアーティファクト管理

シンプルで重要なベストプラクティスをいくつか紹介します。

セキュリティー第一

CI/CDは悪意ある行為者の主要なターゲットの１つであると最近報告書で名指しされました。システムや最終アーティファクトへの高レベルアクセスができることが理由です。セキュリティーを考慮したパイプラインの設計を行い、対策が後手に回らないようにしましょう。

全てを自動化する

自動化によって再現性が高まり、手作業の労力が軽減されます。手動プロセスにおける小さな矛盾は、プロセスの崩壊や監査の失敗のリスクになります。

車輪の再発明はしない

CI/CDにおけるアーティファクト管理は、何度も解決されています。カスタム統合を書いて後でメンテナンスする羽目にならないようにしましょう。

結論

今日のビルドプロセスはますます複雑になっており、ソフトウェア部品表の確保、適切なテスト、スピード、リソースの効率的な使用など、多くの考慮事項があります。これまで以上に迅速に提供することが求められているチームに余計な負担をかけずに。

お使いのビルドツールは、このような要望を全て満たしていますか？Harness CDはクラス最高のアーティファクトリポジトリーに統合され、Harness CIはビルドツールの管理にかかる手間を自動化します。これで顧客のニーズ対応に集中することができます。今日、試してみてください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。