Application Packaging for Armada Edge Platform

This guide covers the complete process of packaging your applications for deployment on the Armada Edge Platform marketplace. Whether you're an Independent Software Vendor (ISV) or internal development team, this section provides everything you need to prepare, package, and certify your applications.

Marketplace Certification Process

The Armada Edge Platform marketplace certification process ensures that applications meet security, performance, and compatibility standards before being available to customers.

Certification Workflow

graph LR
    A[Prerequisites] --> B[Prepare & Upload Package]
    B --> C[Security Scan]
    C --> D[Configure Setup]
    D --> E[Deploy & Validate]
    
    A1[Partner Agreement] --> A
    A2[Metadata Setup] --> A
    A3[Support Agreements] --> A
    
    B1[Container Images] --> B
    B2[K8s Manifests] --> B
    B3[Helm Charts] --> B
    B4[Documentation] --> B
    
    C1[Vulnerability Scan] --> C
    C2[SBOM Analysis] --> C
    C3[CVE Assessment] --> C
    
    D1[Test Environment] --> D
    D2[Node Preparation] --> D
    
    E1[Deployment] --> E
    E2[Smoke Tests] --> E
    E3[Policy Validation] --> E

Key Stakeholders

• ISV (Independent Software Vendor): Application provider responsible for packaging and submission
• Armada Team: Platform team responsible for certification and marketplace management

Prerequisites

Before submitting your application for certification, ensure you have completed the following:

1. Partner Agreement

• Partner Account Registration: Complete the partner onboarding process
• Compliance Requirements: Meet all legal and compliance requirements
• Terms of Service: Accept and comply with marketplace terms

2. Application Metadata

• Application Name: Official display name for the marketplace
• Version Information: Semantic versioning (e.g., 1.2.0)
• Publisher Information: Company name and contact details
• Industry Classification: Select appropriate industry categories
• Release Notes: Document changes and new features

3. Support Agreements

• Support Level: Define support tiers and response times
• Contact Information: Provide technical support contacts
• Escalation Process: Define issue escalation procedures

Application Package Requirements

Your application package must include all necessary components for successful deployment and operation.

Container Images

# Example container image requirements
container_images:
  - name: "myapp-frontend"
    registry: "registry.example.com"
    repository: "mycompany/myapp-frontend"
    tag: "v1.2.0"
    architecture: ["linux/amd64", "linux/arm64"]
    size: "150MB"
    
  - name: "myapp-backend"
    registry: "registry.example.com"
    repository: "mycompany/myapp-backend"
    tag: "v1.2.0"
    architecture: ["linux/amd64", "linux/arm64"]
    size: "200MB"

Kubernetes Manifests

# Required manifest files
manifests:
  - deployment.yaml      # Application deployment
  - service.yaml         # Service definitions
  - ingress.yaml         # Ingress configuration
  - configmap.yaml       # Configuration data
  - secret.yaml          # Sensitive data (templates)
  - pvc.yaml            # Persistent volume claims
  - rbac.yaml           # Role-based access control
  - network-policy.yaml # Network policies

Helm Charts (Optional but Recommended)

# Helm chart structure
chart_structure:
  Chart.yaml:           # Chart metadata
  values.yaml:          # Default values
  values-production.yaml: # Production values
  templates/:
    - deployment.yaml
    - service.yaml
    - ingress.yaml
    - configmap.yaml
    - secret.yaml
    - pvc.yaml
    - rbac.yaml
    - network-policy.yaml
    - _helpers.tpl
    - NOTES.txt
  charts/:              # Dependencies
  .helmignore

Documentation Requirements

# Required documentation
documentation:
  - README.md           # Setup and deployment instructions
  - INSTALL.md          # Detailed installation guide
  - CONFIGURATION.md    # Configuration options
  - TROUBLESHOOTING.md  # Common issues and solutions
  - API.md             # API documentation (if applicable)
  - SECURITY.md        # Security considerations

Security Requirements

Vulnerability Scanning

All container images must undergo security scanning before submission.

# Example scanning workflow
# 1. Generate SBOM
trivy image --format cyclonedx myapp:v1.2.0 > sbom.json

# 2. Scan for vulnerabilities
trivy image --severity HIGH,CRITICAL myapp:v1.2.0

# 3. Generate scan report
trivy image --format json --output scan-report.json myapp:v1.2.0

Acceptable Vulnerability Levels

• CRITICAL: Must be resolved before submission
• HIGH: Must be resolved or documented with mitigation plan
• MEDIUM: Should be resolved, acceptable with justification
• LOW: Acceptable with documentation

Software Bill of Materials (SBOM)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2024-01-15T10:00:00Z",
    "tools": [
      {
        "vendor": "Aqua Security",
        "name": "Trivy",
        "version": "0.40.0"
      }
    ]
  },
  "components": [
    {
      "type": "application",
      "name": "myapp",
      "version": "1.2.0",
      "purl": "pkg:docker/mycompany/myapp@1.2.0"
    }
  ]
}

Resource Requirements

CPU and Memory Specifications

# Example resource requirements
resource_requirements:
  cpu:
    requests: "500m"      # 0.5 CPU cores
    limits: "1000m"       # 1 CPU core
    
  memory:
    requests: "512Mi"     # 512 MB RAM
    limits: "1Gi"         # 1 GB RAM
    
  storage:
    persistent: "10Gi"    # 10 GB persistent storage
    temporary: "1Gi"      # 1 GB temporary storage

Network Requirements

# Network configuration
network_requirements:
  inbound_ports:
    - port: 80
      protocol: TCP
      purpose: "HTTP web interface"
    - port: 443
      protocol: TCP
      purpose: "HTTPS web interface"
      
  outbound_ports:
    - port: 53
      protocol: UDP
      purpose: "DNS resolution"
    - port: 443
      protocol: TCP
      purpose: "External API calls"

Compatibility Matrix

Kubernetes Versions

kubernetes_compatibility:
  minimum_version: "1.20.0"
  maximum_tested_version: "1.25.4"
  supported_versions:
    - "1.20.x"
    - "1.21.x"
    - "1.22.x"
    - "1.23.x"
    - "1.24.x"
    - "1.25.x"

Container Runtimes

container_runtime_support:
  - name: "containerd"
    minimum_version: "1.6.0"
    recommended_version: "1.6.8"
    
  - name: "cri-o"
    minimum_version: "1.24.0"
    recommended_version: "1.24.3"

Operating Systems

os_compatibility:
  - name: "Ubuntu"
    versions: ["20.04", "22.04"]
    architectures: ["x86_64", "arm64"]
    
  - name: "RHEL"
    versions: ["8.6", "9.0"]
    architectures: ["x86_64", "arm64"]
    
  - name: "CentOS"
    versions: ["8", "9"]
    architectures: ["x86_64", "arm64"]

Testing Requirements

Pre-Submission Testing

testing_requirements:
  functional_testing:
    - smoke_tests: true
    - integration_tests: true
    - performance_tests: false
    - security_tests: true
    
  environment_testing:
    - kubernetes_versions: ["1.20", "1.22", "1.25"]
    - container_runtimes: ["containerd", "cri-o"]
    - os_distributions: ["Ubuntu 22.04", "RHEL 9.0"]
    
  edge_specific_testing:
    - offline_operation: true
    - resource_constraints: true
    - network_latency: true
    - intermittent_connectivity: true

Test Scenarios

test_scenarios:
  - name: "Basic Deployment"
    description: "Verify application deploys successfully"
    steps:
      - "Deploy application using provided manifests"
      - "Verify all pods are running"
      - "Check service endpoints"
      - "Validate ingress configuration"
      
  - name: "Configuration Management"
    description: "Test configuration updates"
    steps:
      - "Update ConfigMap values"
      - "Verify application picks up changes"
      - "Test secret rotation"
      
  - name: "Scaling Operations"
    description: "Test horizontal scaling"
    steps:
      - "Scale deployment to 3 replicas"
      - "Verify load distribution"
      - "Scale back to 1 replica"
      
  - name: "Failure Recovery"
    description: "Test application resilience"
    steps:
      - "Delete a pod and verify restart"
      - "Simulate node failure"
      - "Test persistent data retention"

Submission Process

1. Package Preparation

# Create application package
tar -czf myapp-v1.2.0.tar.gz \
  manifests/ \
  charts/ \
  docs/ \
  sbom.json \
  scan-report.json \
  metadata.yaml

2. Metadata File

# metadata.yaml
app_name: "MyApp"
version: "1.2.0"
publisher_name: "MyCompany Inc."
contact_email: "support@mycompany.com"
submission_date: "2024-01-15"

# Container registry information
container_registry:
  registry_url: "registry.example.com"
  authentication_required: true
  images:
    - "mycompany/myapp-frontend:v1.2.0"
    - "mycompany/myapp-backend:v1.2.0"

# Resource requirements
resources:
  cpu_requests: "500m"
  cpu_limits: "1000m"
  memory_requests: "512Mi"
  memory_limits: "1Gi"

# Compatibility
compatibility:
  kubernetes_min_version: "1.20.0"
  kubernetes_max_tested: "1.25.4"
  container_runtimes: ["containerd", "cri-o"]

3. Submission Checklist

• All required files included in package
• Security scan completed and passed
• SBOM generated and included
• Documentation complete and accurate
• Resource requirements documented
• Compatibility matrix verified
• Test scenarios validated
• Metadata file completed

Certification Timeline

Typical Timeline

certification_timeline:
  submission_review: "2-3 business days"
  security_scanning: "1-2 business days"
  environment_setup: "1 business day"
  deployment_testing: "2-3 business days"
  final_approval: "1 business day"
  
  total_timeline: "7-10 business days"
  
  expedited_review: "3-5 business days"  # For urgent submissions

Review Process

1. Initial Review: Package completeness and basic requirements
2. Security Assessment: Vulnerability scanning and SBOM analysis
3. Technical Validation: Deployment and functionality testing
4. Documentation Review: Completeness and accuracy verification
5. Final Approval: Marketplace publication approval

Post-Certification

Ongoing Requirements

• Security Updates: Regular vulnerability scanning and updates
• Version Compatibility: Maintain compatibility with supported platforms
• Documentation Updates: Keep documentation current
• Support Commitment: Provide ongoing technical support

Update Process

update_process:
  minor_updates:
    - notification_required: true
    - timeline: "2 weeks advance notice"
    - testing_required: "regression testing"
    
  major_updates:
    - notification_required: true
    - timeline: "4 weeks advance notice"
    - testing_required: "full certification testing"
    - breaking_changes: "require customer notification"