AWS CodeArtifactによるパッケージと依存関係の管理
AWS CodeArtifactのリポジトリとドメイン、パッケージ形式、上流リポジトリ、外部接続、アクセス制御、ビルドツールとの役割分担を学びます。
AWS CodeArtifactによるパッケージと依存関係の管理
ソフトウェアの開発では、アプリケーション本体だけでなく、ビルドに使うライブラリ、社内で再利用する共通パッケージ、ビルドツールが生成する配布用ファイルなどを扱います。これらをチームごとの端末や個別のビルド環境に分散して置くと、どのバージョンを使ったか追跡しにくくなり、同じ依存関係を何度もインターネットから取得することにもなります。
AWS CodeArtifactは、ソフトウェア開発で使うパッケージを保存、公開、共有するフルマネージドのアーティファクトリポジトリサービスです。サーバーを自分で設置・更新する必要はなく、開発者やビルド環境はパッケージマネージャーなどをCodeArtifactのリポジトリエンドポイントに接続してパッケージを取得・公開します。
パッケージとアーティファクト
パッケージは、ソフトウェアを配布・再利用するためにまとめたファイルと、その名前、バージョン、依存関係などのメタデータです。アプリケーションが利用する外部ライブラリだけでなく、組織が開発した共通ライブラリもパッケージとして保存できます。
アーティファクトは、ソフトウェア開発の工程で作成され、後続の工程や利用者へ渡す成果物の総称です。コンパイル済みコード、依存ライブラリを含む配布パッケージ、実行可能なバイナリなどが含まれます。コンテナイメージもビルド成果物の一種ですが、AWSではコンテナイメージの保管にAmazon ECRを使います。CodeArtifactは、対応する言語パッケージを管理するリポジトリです。
たとえば、気象データを整形する社内ライブラリを複数のアプリケーションで利用する場合、ライブラリのバージョンをパッケージとしてCodeArtifactへ公開します。各アプリケーションのビルドは、必要なバージョンをCodeArtifactから取得します。ビルドの結果としてできるデプロイ用アーカイブやコンテナイメージは、配備先に応じてAmazon S3やAmazon ECRなどへ出力します。
CodeArtifactが対応するパッケージ形式
CodeArtifactは複数の言語やエコシステムのパッケージ形式を扱えます。現在サポートされる形式は次のとおりです。
| 形式 | 主なクライアントや用途 |
|---|---|
| npm | JavaScriptやTypeScriptのパッケージを扱うnpmクライアント |
| PyPI | Pythonパッケージを扱うpipなど |
| Maven | Javaなどで利用されるライブラリやビルド成果物 |
| NuGet | .NETのパッケージ |
| Ruby | RubyGems形式のパッケージ |
| Swift | Swift Package Managerで利用するパッケージ |
| Cargo | Rustのパッケージ |
| generic | CodeArtifactが定義済みの言語形式として扱わない汎用パッケージ |
パッケージ形式を選ぶときは、CodeArtifactの対応形式と、その形式を利用する開発ツールの両方を確認します。CodeArtifactリポジトリは多言語形式に対応しているため、同じリポジトリに異なる形式のパッケージを保存できます。
ドメインとリポジトリ
CodeArtifactでは、リポジトリとドメインを組み合わせてパッケージを管理します。
リポジトリ：パッケージを取得・公開する窓口
リポジトリは、パッケージのバージョンを取得したり、組織内で作成したパッケージを公開したりするためのエンドポイントです。パッケージマネージャーやビルドツールの接続先として指定します。1つのAWSアカウントに複数のリポジトリを作成でき、目的や利用チームに応じて分けられます。
たとえば、開発中のパッケージだけを置くリポジトリ、テストを通過したバージョンを共有するリポジトリ、公開パッケージを取り込むためのリポジトリを分ける設計ができます。リポジトリごとにアクセス権や上流関係を設定できるため、利用者がどのパッケージを見られるか、どこから取得できるかを管理しやすくなります。
ドメイン：リポジトリをまとめる管理境界
ドメインは、複数のリポジトリをまとめる論理的な管理単位です。パッケージのアセットとメタデータはドメインに保存され、パッケージの利用者はリポジトリを通じてアクセスします。同一ドメイン内では、同じパッケージのアセットはリポジトリごとに重複して保存されず、ドメイン内で一度だけ保存されます。
ドメインはリポジトリやパッケージに対する組織的なアクセス制御にも使えます。リポジトリは必ず1つのドメインに属し、別のドメインへ移動できません。また、ドメインに含まれているという理由だけで、利用者がすべてのリポジトリのパッケージを自動的に取得できるわけではありません。リポジトリをまたいでパッケージを利用するには、アクセス権と上流関係を適切に設定します。
上流リポジトリと外部接続
上流リポジトリは、あるCodeArtifactリポジトリが別のCodeArtifactリポジトリの内容を利用できるようにする関係です。開発者のパッケージマネージャーを下流リポジトリに接続し、そのリポジトリから社内パッケージのリポジトリや公開パッケージ用のリポジトリへたどれるようにします。利用者は複数の接続先を個別に切り替えずに、1つのリポジトリエンドポイントからパッケージを要求できます。
公開リポジトリへの接続には、CodeArtifactリポジトリの外部接続を使います。外部接続は、npm RegistryやPyPIのようなパブリックパッケージリポジトリに接続する設定です。外部接続を持つリポジトリを他のリポジトリの上流に指定すれば、下流リポジトリからも公開パッケージを取得できます。
公開パッケージを要求したときの流れは次のとおりです。
- 開発者やビルド環境のパッケージマネージャーが、設定済みのCodeArtifactリポジトリへパッケージを要求する。
- そのリポジトリに対象のパッケージがなければ、設定された上流リポジトリを検索する。
- 上流リポジトリにもなければ、外部接続先の公開リポジトリからCodeArtifactが取得する。
- 取得したパッケージはCodeArtifact内に保持され、その後の要求ではCodeArtifactのリポジトリを通じて利用できる。
たとえば、複数のチームが.NETのサービスを開発するとき、NuGet.orgへの外部接続を持つリポジトリを1つ用意し、各チーム用のリポジトリから上流として参照できます。最初の要求時にCodeArtifactが公開リポジトリから依存パッケージを取得し、以降の要求ではCodeArtifactに保持されたバージョンを利用できます。AWSは、同じドメイン内で同じ公開リポジトリへ複数の外部接続を作るのではなく、公開リポジトリごとに外部接続を持つリポジトリを1つ設け、他のリポジトリがそれを上流として使う構成を案内しています。
上流関係は、パッケージが見つからないときにどこまで検索するかを明示する設定です。必要な内部パッケージだけを参照させたり、信頼できる公開リポジトリ経由の依存取得に限定したりできます。利用するリポジトリと上流の順序を整理し、どのリポジトリからパッケージが取り込まれるかを把握しておくことが重要です。
認証、アクセス制御、暗号化
CodeArtifactの認可には**AWS Identity and Access Management (IAM)**を使います。アイデンティティポリシーでユーザーやロールにCodeArtifactの操作を許可できるほか、ドメインポリシーやリポジトリポリシーのようなリソースベースポリシーで、リソース側からアクセスを許可できます。権限は、必要なユーザー、リポジトリ、操作に絞って付与します。
パッケージマネージャーをCodeArtifactに接続する際は、利用者のIAM認証に加えて、CodeArtifactの認可トークンを取得し、クライアントに設定する方式が使われます。ビルド環境がパッケージを取得する場合は、CodeBuildのサービスロールに対象ドメインやリポジトリへのアクセスを許可します。トークンを取得する権限と、実際にリポジトリから読み取る権限を区別して確認してください。
別のAWSアカウントのリポジトリを使う場合は、リソースを所有するアカウント側でドメインまたはリポジトリのリソースポリシーを設定し、利用するアカウントやロールを許可します。利用者側のIAMポリシーにも必要な操作の許可が必要です。ドメインポリシーは、別アカウントがドメイン内のリポジトリを作成したり、認可トークンを取得したりする権限を制御できます。単にリポジトリのURLを知らせるだけでは、クロスアカウントでアクセスできません。
ドメイン内のパッケージアセットとメタデータは、AWS Key Management Service (AWS KMS) のキーで暗号化されます。AWS管理のキーを使うか、組織で管理するカスタマーマネージドキーを指定できます。カスタマーマネージドキーを利用する場合は、CodeArtifactがそのキーを使えるようKMSキーポリシーも適切に設定します。IAMのCodeArtifact許可とKMSキーの許可は別の制御点です。
ビルドとパッケージ管理の役割分担
パッケージを保存するサービス、ビルド工程を制御するサービス、言語固有のコンパイルや依存関係解決を行うツールは、それぞれ役割が異なります。
| 種類 | 例 | 主な役割 |
|---|---|---|
| アーティファクトリポジトリ | AWS CodeArtifact | パッケージを保存・公開し、開発者やビルド環境に共有する |
| ビルド工程を制御するサービス／ツール | AWS CodeBuild、Jenkins | ソースを取得し、ビルド手順に従って各コマンドや工程を実行する |
| ビルドツール | Apache Maven、Gradle | 依存関係の解決、コンパイル、テスト、パッケージングなどを行う |
| パッケージマネージャー | npm、pip | パッケージの検索、取得、依存関係の管理やインストールを行う |
CodeBuildは、ビルド環境上で指定されたコマンドを実行するマネージドサービスです。たとえば、ビルド仕様にMavenやGradleのコマンドを書けば、それらのビルドツールが依存ライブラリを取得し、コンパイルやテストを進めます。CodeBuild自体が、あらゆる言語に対して固有のコンパイル処理を自動的に選ぶわけではありません。どのコマンドを使うか、必要なツールやランタイムをどう準備するかは、ビルド環境とビルド手順で定義します。
ビルドツールとパッケージマネージャーの役割は重なることがあります。MavenやGradleは依存関係の取得だけでなく、コンパイル、テスト、パッケージングをまとめて実行できるビルドツールです。npmはJavaScriptパッケージの取得・管理に加え、package.jsonに定義したスクリプトを実行する機能もあります。一方、pipはPythonパッケージのインストールや管理が中心です。ツール名だけで分類するのではなく、ビルド手順のどの処理を担当しているかで考えます。
CodeArtifactを使うビルドでは、パッケージマネージャーやビルドツールをCodeArtifactのエンドポイントへ向け、ビルド環境に適切な認証情報を設定します。ビルドの実行役がCodeBuildでもJenkinsでも、CodeArtifactを利用できます。ビルド工程の制御製品とパッケージ保管先は、特定の組み合わせに固定されていません。
CI/CD工程での使い分け
CI/CDパイプラインでは、CodeArtifactは主にビルド時に必要となる依存パッケージや、チームが共有するパッケージを管理します。CodeBuildなどのビルド実行環境は、CodeArtifactから依存関係を取得し、アプリケーションをビルドしてテストします。できあがった配布用アーカイブやコンテナイメージは、後続工程で扱える保存先へ出力します。
| 要件 | 主なサービスやツール |
|---|---|
| 社内外の言語パッケージを一元管理し、ビルドから取得する | CodeArtifact |
| ビルドコマンドやテストを実行する | CodeBuild、Jenkinsなど |
| ビルド済みコンテナイメージを保存する | Amazon ECR |
| パイプラインの工程や順番を制御する | AWS CodePipelineなど |
この区別により、「ソフトウェアパッケージを共有したい」「ビルドコマンドを実行したい」「コンテナイメージを配布したい」といった要件から、適切なサービスを選びやすくなります。
料金を確認する観点
CodeArtifactでは、保存するパッケージデータの量とリポジトリへのリクエスト数が料金に関係します。リクエストの種類による単価差はなく、公開リポジトリからCodeArtifactが取得するアセットもリクエスト数に含まれます。実際の料金はリージョンや利用量などの条件で変わるため、固定額ではなくAWSの最新料金表で確認します。公開パッケージの取得を繰り返す設計では、保存量や要求回数に加え、外部リポジトリへの接続と上流構成も考慮します。
複数のリポジトリで同一ドメイン内の同じパッケージを利用する場合、ドメイン内ではパッケージアセットが一度だけ保存されます。共有可能な構成にしておくことで、同じアセットの重複保存を避けやすくなります。料金だけでなく、どのチームがどのリポジトリを使うか、公開パッケージをどこから取り込むかを合わせて設計してください。
学習ポイント
- CodeArtifactは、ソフトウェアパッケージを保存、公開、共有するフルマネージドサービスである。
- リポジトリはパッケージの取得・公開に使うエンドポイントであり、ドメインは複数リポジトリを束ねる管理単位である。
- パッケージアセットはドメインに保存され、同一ドメイン内では同じアセットをリポジトリごとに重複保存しない。
- ドメイン内の全リポジトリが自動的に相互参照するわけではない。別リポジトリのパッケージを使う場合は、アクセス権と上流関係を構成する。
- 外部接続を持つリポジトリを上流として設定すると、パッケージマネージャーはCodeArtifactの接続先から社内パッケージと公開パッケージを取得できる。
- CodeArtifactはnpm、PyPI、Maven、NuGet、Ruby、Swift、Cargo、genericのパッケージ形式をサポートする。コンテナイメージはAmazon ECRで管理する。
- CodeBuildやJenkinsはビルド工程を実行・制御し、MavenやGradleなどはコンパイル、テスト、パッケージングを行う。CodeArtifactはパッケージの保管・共有を担う。
- npmなど一部のパッケージマネージャーは、依存関係管理に加えてタスク実行機能も備える。ツールの役割は名前ではなく実行する処理から判断する。
- データはドメインに関連付けられたKMSキーで暗号化される。IAMとドメイン／リポジトリポリシーでアクセスを制御する。
- クロスアカウントアクセスには、リソース所有者側のリソースポリシーと、利用者側の必要なIAM権限が必要である。
公式ドキュメント
重要ポイント
- ▸CodeArtifactはソフトウェアパッケージを保存・公開・共有するフルマネージドのアーティファクトリポジトリで、npm、Maven、PyPIなど8種類のパッケージ形式に対応する
- ▸パッケージを取得・公開する窓口はリポジトリであり、ドメインは複数リポジトリをまとめて共有やアクセス制御、暗号化の境界を与える
- ▸リポジトリの上流関係と外部接続を構成すると、開発者はCodeArtifactの単一エンドポイントを使い、内部パッケージとパブリックパッケージを取得できる
- ▸パッケージの保存と配布はCodeArtifact、ビルド手順の実行はCodeBuildやJenkins、コンパイルや依存関係解決はMaven・Gradle・npmなどのツールが担う
- ▸保存データはドメインに関連付けたKMSキーで暗号化され、アクセスはIAMアイデンティティポリシーとドメイン／リポジトリのリソースポリシーで制御する
- ▸別アカウントの利用者に共有する場合は、ドメインやリポジトリのリソースポリシーと利用者側の権限を整え、認可トークンを取得できるようにする
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
AWS CodePipeline に関連するトピックを続けて確認できます。