Container Images

Container Images Skill

This skill extracts every container image reference from the microsoft/aspire product repository and writes a structured JSON file to microsoft/aspire.dev at:

src/frontend/src/data/container-images.json

This JSON is consumed by Astro components on the aspire.dev site to render a browsable catalog of all container images used by Aspire hosting integrations.

Source code pattern

All container image metadata in microsoft/aspire lives in static classes named *ContainerImageTags (or *ContainerImageTags.cs). Each file follows a strict, consistent pattern:

internal static class <Name>ContainerImageTags
{
    public const string Registry = "<registry-host>";
    public const string Image = "<image-path>";
    public const string Tag = "<tag>";

    // Some files have additional companion images, e.g.:
    public const string <Companion>Registry = "<registry-host>";
    public const string <Companion>Image = "<image-path>";
    public const string <Companion>Tag = "<tag>";
}

Where to find them

All files matching the glob pattern:

src/**/ContainerImageTags.cs
src/**/*ContainerImageTags.cs

These span across many projects including (but not limited to):

Important: New hosting packages may be added at any time. Always discover files dynamically — never rely on a hardcoded list.

Extraction procedure

Step 1 — Clone or access the aspire repo at HEAD

# If working locally:
git clone --depth 1 https://github.com/microsoft/aspire.git /tmp/aspire

Step 2 — Find all ContainerImageTags files

find /tmp/aspire/src -name '*ContainerImageTags.cs' -type f

Step 3 — Parse each file

For each file, extract all image groups. A single file can define multiple images (primary + companions). The parsing rules are:

1. Primary image: Fields named exactly Registry, Image, Tag.
2. Companion images: Fields with a prefix, e.g. PgAdminRegistry, PgAdminImage, PgAdminTag — group them by the shared prefix.
3. Alternate tags: Fields like TagVNextPreview, ManagementTag — include these as additional tag variants on the same image.
4. Static properties vs const fields: Most use public const string, but some (e.g. Kusto) use public static string { get; }. Handle both.
5. Computed tags: Some tags are computed, e.g. public const string ManagementTag = $"{Tag}-management"; — resolve these to their literal value.
6. Derive the aspirePackage from the project directory name (e.g. src/Aspire.Hosting.Redis/ → Aspire.Hosting.Redis).
7. Derive the sourceFile as the path relative to the repo root.

Step 4 — Build the JSON

Each entry in the output array represents one distinct container image:

[
  {
    "aspirePackage": "Aspire.Hosting.Redis",
    "name": "Redis",
    "registry": "docker.io",
    "image": "library/redis",
    "tag": "8.6",
    "fullImage": "docker.io/library/redis:8.6",
    "sourceFile": "src/Aspire.Hosting.Redis/RedisContainerImageTags.cs",
    "sourceUrl": "https://github.com/microsoft/aspire/blob/main/src/Aspire.Hosting.Redis/RedisContainerImageTags.cs",
    "isCompanion": false,
    "companionOf": null,
    "alternateTags": []
  },
  {
    "aspirePackage": "Aspire.Hosting.Redis",
    "name": "Redis Commander",
    "registry": "docker.io",
    "image": "rediscommander/redis-commander",
    "tag": "latest",
    "fullImage": "docker.io/rediscommander/redis-commander:latest",
    "sourceFile": "src/Aspire.Hosting.Redis/RedisContainerImageTags.cs",
    "sourceUrl": "https://github.com/microsoft/aspire/blob/main/src/Aspire.Hosting.Redis/RedisContainerImageTags.cs",
    "isCompanion": true,
    "companionOf": "Redis",
    "alternateTags": []
  },
  {
    "aspirePackage": "Aspire.Hosting.Azure.CosmosDB",
    "name": "CosmosDB Emulator",
    "registry": "mcr.microsoft.com",
    "image": "cosmosdb/linux/azure-cosmos-emulator",
    "tag": "stable",
    "fullImage": "mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:stable",
    "sourceFile": "src/Aspire.Hosting.Azure.CosmosDB/CosmosDBEmulatorContainerImageTags.cs",
    "sourceUrl": "https://github.com/microsoft/aspire/blob/main/src/Aspire.Hosting.Azure.CosmosDB/CosmosDBEmulatorContainerImageTags.cs",
    "isCompanion": false,
    "companionOf": null,
    "alternateTags": ["vnext-preview"]
  }
]

Field definitions

Step 5 — Sort and write

Sort the array by aspirePackage (ascending), then by isCompanion (primary first), then by name (ascending).

Write to: src/frontend/src/data/container-images.json

Validation checklist

After generating the file, verify:

• Every *ContainerImageTags.cs file in src/ is represented
• No duplicate entries (same registry + image + tag + aspirePackage)
• All fullImage values are well-formed (registry/image:tag)
• Companion images are correctly linked to their primary
• The JSON is valid and properly formatted (2-space indent)
• The file is sorted per the rules above

Consuming the data in Astro

The JSON file at src/frontend/src/data/container-images.json can be imported directly in Astro components:

import containerImages from '../data/container-images.json';

This follows the same pattern as existing data files like aspire-integrations.json, samples.json, and github-stats.json in the same directory.

Linking to related content

Each container image entry can be cross-referenced with:

• The integration docs at src/frontend/src/data/integration-docs.json (match on aspirePackage)
• The NuGet integrations at src/frontend/src/data/aspire-integrations.json (match on title ≈ aspirePackage)
• The source file link back to microsoft/aspire for contributors

Important rules

• Always discover files dynamically — new hosting packages are added frequently.
• Parse both const and static property patterns — they both exist in the codebase.
• Resolve string interpolation in computed tag values (e.g. $"""{Tag}-management""").
• Do not include devcontainer images, test-only images, or images from the playground/ directory.
• Only extract from src/ directory files matching *ContainerImageTags.cs.
• The aspire.dev repo is an Astro site — the data file lives alongside other JSON data consumed by components.