本記事は
AWSアワード記念！夏のアドベントカレンダー
11日目の記事です。
🎆🏆
10日目
▶▶ 本記事 ▶▶
12日目
🏆🎆
はじめに
ozawaです。今年もAllCert継続となりました。引き続きよろしくお願いします。 先ほどエアコンの水漏れ対応工事が終わり、ようやく灼熱地獄から抜け出せそうです。
ふと、ECRを眺めてて気づいた
最近はIaC化も進んでおり、なかなかAWSコンソールをまじまじ見る機会も減りました。 そんな中、ふとECRコンソールを眺めた時になにやら見慣れない項目を見つけました。
アーティファクトタイプ。。。？なにそれ？
ちなみにImage, Image Indexという記述にマウスオーバーできるので見てみるとこんな表示が。
これが気になって私は夜しか眠れませんでした。
調べてみると、OCI Artifactなるものが存在するようでして、そちらと関連していそうでした。 OCI Artifactについては、下記でORASが公開しているページでの説明がわかりやすかったです。
今回は、上記ページの内容を踏まえながら、OCI Artifactについてざっくり共有したいと思います。
そもそもOCIってなんぞや
OCI Artifactを説明する前に、OCIについてもざっくり説明します。
ちなみに、OCIと聞いて赤くて丸いクラウドベンダーをイメージされていた方々へ。
恐れ入りますがこのブログをブックマークしていただいて、そっ閉じしていただけると幸いです。
この後赤くて丸いものは一切登場しません。
Open Container Initiative
そうです。OCIとはOpen Container Initiative の略称です。
Open Container Initiative - Open Container Initiative
詳細は上記を確認いただけると幸いですが、
ざっくりいうと、Docker社を中心としたコンテナ技術の業界標準を定めるための団体です。
現在はLinux Foundation配下のプロジェクトとなっており、2024年2月15日にOCI v1.1.0という標準仕様が公開されました。Artifactの仕様についてはこのバージョンで確定しているようです。
OCI Image and Distribution Specs v1.1 Releases - Open Container Initiative
また、Amazon ECRにおいてもOCI v1.1.0に対応する旨のアナウンスが発表されています。
aws.amazon.com
OCI Artifactってなんぞや
結論からいうと、OCIに準拠した方式でパッケージ化されたコンテンツ（コンテナイメージ以外も含む）です。
とは言っても具体的になにを指すのかはイメージしづらいかもしれません。
主な内容としては下記に規定されるmediaTypeがベースになるようです。
代表的なものだと、
- Image Index
- Image Manifest
- Image Config
- Image Layer
といったものが指定されるようです。
ちなみにImage Indexとかってなに？
個人的にもふわふわした理解度だったので、改めて関係性も含めて整理しました。
- Image Index
- コンテナイメージダイジェストに紐づくイメージマニフェストのリストと、それらに紐づくプラットフォーム情報（OS・CPUアーキテクチャ）を管理
- Image Manifest
- コンテナイメージの構成情報を管理
- 具体的には、イメージに対する変更セットとなるConfigとイメージの実態であるイメージレイヤーのリスト
- Image Config
- イメージのルートファイルシステムに対する変更セット（Dockefile内のコマンドライン命令に相当）を管理
- Image Layer
- 変更セットによるファイルシステムの差分データ
Image Manifestの中身やこれに紐づくArtifactはこのようになっているそうです。
では実際にECRコンソールから見えたアーティファクトタイプという項目ではどういった情報が見えるのでしょうか。
先ほどのキャプチャを例に見てみます。
Image manifest media type- ここでいう
mediaTypeに相当する箇所です - Dockerを利用してイメージ管理している場合、現状この箇所には
vnd.docker.distribution.manifest.v2というDocker定義のマニフェスト形式が指定されます
- ここでいう
Artifact media type- Artifactが定義するコンテンツの種類を指します
- この場合はコンテナイメージを指しており、Docker管理のイメージになるため、
vnd.docker.container.image.v1というDocker定義のイメージ形式が指定されます - コンテナイメージ以外のコンテンツをArtifactとして定義する場合、この箇所の指定が変わります。具体的な例は後述します
もう一例、Image Indexの場合も見てみます。
- Image Indexの場合はImage manifest media typeに
vnd.oci.image.index.v1が指定されます - Indexについては、blobのような実態がないためか、Artifact media typeは指定されません
結局OCI Artifactはどこで活躍するの？
個人的な観測範囲で、OCI Artifactが活躍するのは下記です。
- OCI準拠のイメージ署名
- SOCI Indexを利用したLazy Loading
OCI準拠のイメージ署名
具体的にはAWS Signerを用いたイメージ署名がこちらにあたります。これについては以前登壇した資料がありますので詳しくはこちらをご覧いただければと思います。
資料はこちら↓↓↓
speakerdeck.com
登壇動画はこちら↓↓↓
www.youtube.com
この方式の場合、SignatureというArtifactが生成されます。これにより、コンテナイメージが格納されているレポジトリ上でイメージ署名も合わせて管理することができます。
AWS SignerとNotaryという署名検証ツールを組み合わせることで、コンテナイメージの署名・検証時におけるファイル管理をECRレポジトリ上で完結することができ、処理を簡素化できます。
vnd.cncf.notary.signatureというNotary定義の形式が指定されます。
SOCI Indexを利用したLazy Loading
詳細についてはAWSのブログがわかりやすいのでこちらをみていただければと思いますが、
内容としては、Soci IndexというArtifactを生成してECRレポジトリにPushし、これをAmazon ECSでのコンテナ起動時に読み込むことでLazy Loading（遅延ローディング）を実現するという方式です。
- finchを使ってSOCI Indexを付与したイメージをECRにPushすると上記のArtifactも一緒にPushされます
- この場合は
vnd.amazon.soci.index.v1というArtifact media type が割り当てられます
まとめ
あまり馴染みがないかもしれないOCI Artifactですが、SignatureやSOCI IndexといったArtifactを使うことで、コンテナワークロードにおいて少しずつ嬉しい機能が追加されていってるのかなーと改めて感じました。 まだまだ理解しきれていない部分もありますので、今後の動向を追いつつより深めていきたいです。
