Docker Containerization
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Docker containerization in the LiveCanvas project is designed to support a modular monolith architecture, where the entire Phoenix/Elixir application is packaged into a single deployable unit. This unit, referred to as an Elixir release, is deployed within Kubernetes pods to handle a diverse range of responsibilities including GraphQL requests, REST webhooks, WebSockets, background jobs, and WebRTC media orchestration.
The containerization strategy ensures that each pod runs the same release, maintaining consistency across the cluster while allowing for future scaling of specialized components, such as dedicated media nodes, without altering the core domain boundaries.
Sources: ARCHITECTURE.md:41-45, ARCHITECTURE.md:104-108
Deployment Architecture
LiveCanvas utilizes a "one deployable per pod" model. This approach leverages the Erlang VM (BEAM) capabilities for distributed realtime coordination via Phoenix PubSub and Phoenix Presence, removing the need for external caches like Redis.
Pod Responsibilities
Each containerized instance is capable of serving the following traffic types:
- API Traffic: GraphQL (primary client API) and REST (webhooks).
- Realtime Traffic: Phoenix Channels and WebSockets for chat and session state.
- Media: Membrane-based WebRTC orchestration for live streaming.
- Async Tasks: Background processing jobs.
Sources: ARCHITECTURE.md:41-46, ARCHITECTURE.md:104-108, ARCHITECTURE.md:120-125
Component Relationship
The following diagram illustrates how containerized pods interact with external stateful dependencies and clients.
Note: Each pod runs an identical Elixir release and communicates via the BEAM for ephemeral state while relying on PostgreSQL for durable facts.
Sources: ARCHITECTURE.md:41-48, ARCHITECTURE.md:104-114
Environment Configuration
The application relies on standard Phoenix setup procedures and environment variables to manage its lifecycle within a container.
Core Service Dependencies
| Service | Role | Persistence Type |
|---|---|---|
| PostgreSQL | Primary system of record for all durable data (Users, Sessions, Posts). | Durable |
| Object Storage | Storage for media binaries (Images/Videos). | Durable |
| Phoenix PubSub | Distributed realtime state coordination. | Ephemeral |
| Phoenix Presence | Tracking active participant presence. | Ephemeral |
Sources: ARCHITECTURE.md:41-48, ARCHITECTURE.md:129-131, ARCHITECTURE.md:188-193
Runtime Connectivity
The frontend assets (JavaScript/CSS) are bundled into the application and expect a specific socket connection for LiveView and Channels.
// Example of socket connection configuration in the containerized environment
const liveSocket = new LiveSocket("/live", Socket, {
longPollFallbackMs: 2500,
params: {_csrf_token: csrfToken},
hooks: {...colocatedHooks},
})
liveSocket.connect()
Sources: assets/js/app.js:28-33, assets/js/app.js:41
Operational Procedures
Containerized deployments are managed through specific runbooks to ensure high availability and data integrity during updates or failures.
Release Management
The project defines several critical operational workflows for the containerized environment:
- Deployment Gates: Quality checks before a release is promoted.
- Live Runtime Failover: Drills to test system resilience when pods fail.
- Staged Rollout: Gradual deployment of new containers to a subset of users.
- Rollback and Restore: Procedures for reverting to a previous stable container image.
Sources: README.md:12-16
Health and Monitoring
Pods are expected to implement specific checks to integrate with container orchestrators:
- Liveness Checks: Verifies the BEAM health and the application process.
- Readiness Checks: Ensures the pod can reach the PostgreSQL database before accepting traffic.
- Telemetry: Instrumentation for auth attempts, session lifecycle, and media errors.
Sources: ARCHITECTURE.md:278-281, ARCHITECTURE.md:285-292
Containerization Summary
The LiveCanvas backend uses Docker to package a modular monolith that prioritizes the use of PostgreSQL for persistence and the BEAM for distributed state. By deploying identical pods, the system simplifies operational overhead while remaining capable of future horizontal scaling for media-intensive tasks.
Sources: ARCHITECTURE.md:41-45, ARCHITECTURE.md:104-108