Table of Contents

Usage in Docker and AWS

This page explains how to run List & Label Cross Platform within a Docker container and deploy your containerized application to AWS using Amazon Elastic Container Service (ECS) with Fargate.

Running in Docker

List & Label Cross Platform is designed for containerized deployments. Docker containers provide consistent, reproducible environments across development, testing, and production.

LLCP supports .NET 10, .NET 9, and .NET 8. The examples below use .NET 10 as the default. To use .NET 9 or .NET 8, keep the structure and only adjust the image tags (as described in the notes below).

Why Docker for LLCP?

Dependency isolation
All required native libraries (font handling, image rendering) are packaged within the container, avoiding conflicts with host system packages.

Cross-platform consistency
The same container image runs identically on Windows, Linux, and macOS (via Docker Desktop), eliminating platform-specific differences.

Scalability
Containers can be replicated and orchestrated (Kubernetes, ECS, Azure Container Instances) to handle variable workloads.

Simplified deployment
A single container image includes application code, runtime dependencies, and native libraries, reducing deployment complexity.

Required dependencies

Important

List & Label Cross Platform requires additional native Linux packages for font handling and image rendering. These must be installed explicitly in your Docker image.

When running on Linux, you must also reference the NuGet package SkiaSharp.NativeAssets.Linux, which provides the required native rendering components.

Dockerfile variants (overview)

Choose the Dockerfile variant that best fits your environment:

Variant Base image Package manager Recommended when
Debian / Ubuntu mcr.microsoft.com/dotnet/aspnet:10.0 apt-get maximum compatibility, easiest troubleshooting
Alpine mcr.microsoft.com/dotnet/aspnet:10.0-alpine apk smaller image size
Note

List & Label Cross Platform supports .NET 10, .NET 9, and .NET 8. Only the image tags need to be changed for different .NET versions. Package names may differ slightly depending on the Linux distribution.

Use this variant when your runtime image is based on Debian or Ubuntu (e.g. mcr.microsoft.com/dotnet/aspnet:10.0).

# Build and publish the application
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Runtime image
FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app/publish ./

USER root

# Install native dependencies required by List & Label Cross Platform
RUN apt-get update && apt-get install -y \
    libc6 \
    libfontconfig1 \
    libfreetype6 \
    libpng16-16 \
    libjpeg62 \
    libgif7 \
    fonts-dejavu-core \
 && apt-get clean && rm -rf /var/lib/apt/lists/*

ENTRYPOINT ["dotnet", "YourApplication.dll"]
Note

Depending on the Debian/Ubuntu version behind the base image, the JPEG package may be named libjpeg62 or libjpeg62-turbo. If installation fails, check the available package names and adjust accordingly.

Tip

To use a different .NET version:

  • .NET 9
    mcr.microsoft.com/dotnet/sdk:9.0
    mcr.microsoft.com/dotnet/aspnet:9.0

  • .NET 8
    mcr.microsoft.com/dotnet/sdk:8.0
    mcr.microsoft.com/dotnet/aspnet:8.0

Deploying to AWS ECS and Fargate

AWS offers several services for running containerized applications. The recommended approach for LLCP is Amazon ECS with Fargate, which provides serverless container execution without managing infrastructure.

Why ECS with Fargate?

Serverless infrastructure
Fargate eliminates the need to provision, configure, and manage EC2 instances. AWS handles capacity planning and scaling.

Flexible scaling
Scale tasks up or down based on demand. Fargate supports both manual scaling and integration with Application Auto Scaling.

Integrated monitoring
CloudWatch Logs and Container Insights provide built-in observability for containerized workloads.

Cost efficiency
Pay only for the vCPU and memory resources your containers consume, with no charges for idle capacity.

Security
Task isolation, IAM integration, and VPC networking provide strong security boundaries.

Steps to deploy

  1. Build your Docker image:
    Build the image locally or within your CI/CD pipeline using your Dockerfile:

    docker build -t mylistlabelapp .

  2. Push the image to Amazon ECR:
    Create an Amazon ECR repository and push your image there. Use the following commands (replace <aws_account_id> and <region> with your actual values):

    aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com
docker tag mylistlabelapp:latest <aws_account_id>.dkr.ecr.<region>.amazonaws.com/mylistlabelapp:latest
docker push <aws_account_id>.dkr.ecr.<region>.amazonaws.com/mylistlabelapp:latest

  3. Create an ECS cluster:
    In the AWS Management Console, create a new ECS cluster configured for Fargate. This provides the orchestration needed to run your containerized application.

  4. Define a task definition:
    Create a task definition that specifies:

    • Container image (from your ECR repository)
    • CPU and memory (e.g., 1 vCPU, 2 GB RAM—adjust based on workload)
    • Port mappings (if exposing HTTP/HTTPS endpoints)
    • Environment variables (licensing, connection strings—use Secrets Manager for sensitive values)
    • Logging configuration (CloudWatch Logs for centralized logging)

  5. Deploy a service:
    Using your task definition, create an ECS service that runs your container on Fargate. Configure:

    • Desired task count (number of container instances)
    • Auto-scaling policies (scale based on CPU, memory, or custom metrics)
    • Load balancing (integrate with Application Load Balancer for HTTP/HTTPS traffic)
    • VPC and networking (private subnets, security groups)

  6. Configure monitoring and alerting:

    • Enable Container Insights for detailed metrics and logs
    • Set up CloudWatch Alarms for CPU/memory utilization, task failures, or response time
    • Use X-Ray for distributed tracing (optional)

Production considerations

Resource sizing
Test with production-like workloads to determine optimal task CPU and memory allocations. Under-provisioning causes failures; over-provisioning increases costs.

Auto-scaling
Configure ECS Service Auto Scaling based on:

  • CPU or memory utilization
  • Request count (via ALB metrics)
  • Custom metrics (e.g., queue depth if using asynchronous processing)

Security best practices

  • Store secrets (licensing, connection strings) in AWS Secrets Manager
  • Use IAM roles for tasks to grant least-privilege access to AWS resources
  • Deploy tasks in private subnets with NAT Gateway for outbound internet access
  • Enable encryption at rest for CloudWatch Logs

Cost optimization

  • Use Fargate Spot for non-critical workloads (up to 70% savings)
  • Right-size task resources based on actual usage
  • Set appropriate auto-scaling policies to avoid over-provisioning

Networking

  • Use Application Load Balancer (ALB) for HTTP/HTTPS traffic distribution
  • Configure health checks to route traffic only to healthy tasks
  • Use VPC endpoints to reduce NAT Gateway data transfer costs

Additional resources

By following these steps, you can successfully containerize your List & Label Cross Platform application and deploy it on AWS ECS with Fargate. This setup ensures that your application benefits from AWS's scalable infrastructure and integrated monitoring tools.