Add Docker configuration for Maya1 TTS deployment#4
Add Docker configuration for Maya1 TTS deployment#4hasithdd wants to merge 3 commits intoMayaResearch:masterfrom
Conversation
WalkthroughAdds Docker-based containerization and CI: a CUDA-backed Dockerfile, Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Script as docker/docker-gpu.sh
participant GH as GitHub Actions
participant Builder as Docker Buildx
participant Registry as ghcr.io
participant Image as maya1-tts image
participant Container as Running Container
participant App as uvicorn (maya1.api_v2:app)
participant Health as /health endpoint
Dev->>Script: run helper (local build & run)
Script->>Builder: docker build -f docker/Dockerfile
Builder-->>Image: built image (maya1-tts)
Script->>Container: docker run --gpus ... -p 8000:8000
Container->>App: start uvicorn
Dev->>Health: GET /health
App-->>Health: 200 OK
Note over GH,Registry: CI flow (on push/tags/PR)
GH->>Builder: build & (conditionally) push
Builder-->>Registry: push image (skip on PRs)
GH->>Registry: (conditional) cosign sign
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
docker/.dockerignore (1)
11-11: Consider clarifying the exclusion of thedocker/directory.Excluding
docker/from the build context is functional (since the Dockerfile is specified explicitly with-f), but it's unconventional and may cause confusion for future maintainers. Consider either:
- Removing this pattern if you want the docker directory to be discoverable in the context, or
- Documenting why it's excluded if this is intentional (e.g., to reduce build context size).
docker/docker-gpu.sh (1)
11-11: Add error handling to thecdcommand.If the
cdcommand fails, the script will continue executing in the wrong directory, potentially causing the docker build to fail silently or operate on unintended context.Apply this diff to add proper error handling:
-# Navigate to project root -cd "$(dirname "$0")/.." +# Navigate to project root +cd "$(dirname "$0")/.." || { echo "Failed to navigate to project root"; exit 1; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docker/.dockerignore(1 hunks)docker/Dockerfile(1 hunks)docker/README.md(1 hunks)docker/docker-gpu.sh(1 hunks)
🧰 Additional context used
🪛 Shellcheck (0.11.0)
docker/docker-gpu.sh
[warning] 11-11: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
(SC2164)
🔇 Additional comments (4)
docker/README.md (1)
1-51: Documentation is comprehensive and well-aligned with implementation.The README provides clear prerequisites, usage instructions (both scripted and manual), and helpful notes. All documented details align with the Dockerfile and docker-gpu.sh script.
docker/docker-gpu.sh (1)
14-27: Build and run logic is sound.Docker build correctly targets the Dockerfile with proper context, and the run command includes appropriate flags for GPU support, port mapping, IPC sharing, and cleanup.
docker/Dockerfile (2)
47-48: Verify the health check endpoint exists in the application.The health check references
/health, but we should confirm this endpoint exists inmaya1.api_v2:appbefore deployment.Please verify that the application exposes a health check endpoint at
/health. You can inspect the application code or test the endpoint after running the container.
5-8: Environment variables and dependency installation are properly configured.The environment variables are well-chosen for containerized Python applications (PYTHONUNBUFFERED, PYTHONDONTWRITEBYTECODE), TORCH_CUDA_ARCH_LIST covers modern GPUs, and pip install properly uses
--no-cache-dirto minimize image size.Also applies to: 11-32
…rkflow for Docker build and publish
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/docker-publish.yml (2)
34-38: Normalize theif:condition syntax for consistency.Line 87 uses
if: ${{ github.event_name != 'pull_request' }}with outer braces, while lines 35 and 47 useif: github.event_name != 'pull_request'without them. In GitHub Actionsif:contexts, the outer${{ }}are redundant (they are needed only for value interpolation, such as line 75 in thepush:parameter). Normalize allif:conditions to the idiomatic format for consistency.Apply this diff to normalize the syntax:
# Sign the resulting Docker image digest except on PRs. # This will only write to the public Rekor transparency log when the Docker # repository is public to avoid leaking data. If you would like to publish # transparency data even for private images, pass --force to cosign below. # https://github.com/sigstore/cosign - name: Sign the published Docker image - if: ${{ github.event_name != 'pull_request' }} + if: github.event_name != 'pull_request' env: TAGS: ${{ steps.meta.outputs.tags }} DIGEST: ${{ steps.build-and-push.outputs.digest }}Also applies to: 86-91
1-91: Consider adding Build Provenance and SBOM for enhanced supply chain security.The workflow currently signs the image with cosign, which is excellent. For further hardening:
- Provenance attestation:
docker/build-push-action@v5supportsprovenance=true(default) to generate SLSA provenance, which attests to the build process and inputs.- Software Bill of Materials (SBOM): Enable
sbom=truein the build-push-action to generate and attach a cyclonedx SBOM, improving vulnerability scanning and compliance.These additions provide stronger guarantees about what is in the image and how it was built, which is valuable in regulated or security-sensitive environments.
If you'd like to enable SBOM and provenance, add the following to the
Build and push Docker imagestep (lines 69–79):- name: Build and push Docker image id: build-and-push uses: docker/build-push-action@v5 with: context: . file: docker/Dockerfile push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} + provenance: true + sbom: true cache-from: type=gha cache-to: type=gha,mode=max
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/docker-publish.yml(1 hunks)docker/Dockerfile(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- docker/Dockerfile
🔇 Additional comments (5)
.github/workflows/docker-publish.yml (5)
3-9: Trigger configuration is well-structured.The workflow correctly triggers on master pushes, semver tags, and PRs targeting master—supporting both development/CI on PRs and production releases on tags.
21-26: Permissions are appropriately scoped.The job permissions follow the principle of least privilege:
contents:readfor checkout,packages:writefor registry push, andid-token:writefor cosign OIDC identity exchange with Sigstore.
61-65: Tagging strategy supports both development and release workflows.The metadata tags include
lateston the default branch (for development), branch refs, tag refs, and SHA—providing flexibility for version pinning and rollback scenarios.
78-79: GitHub Actions cache configuration optimizes build performance.Using
cache-from: type=ghawithmode=maxenables multi-stage layer caching, improving build speed on subsequent runs.
34-39: Version pinning and conditional execution reduce supply-chain risk.Explicit version pins on
cosign-installer@v3.5.0(withcosign-release: v2.2.4),docker/login-action@v3, anddocker/build-push-action@v5limit exposure to unexpected upstream changes. Skipping registry login, cosign install, and image push on PR events prevents data leakage and avoids polluting the registry with PR artifacts.Also applies to: 46-52, 69-79
1 participant
Maya1 TTS Docker Deployment
This directory contains the configuration for deploying Maya1 TTS using Docker.
Prerequisites
Files
Dockerfile: The Docker image definition.docker-gpu.sh: Helper script to build and run the container with GPU support..dockerignore: Specifies files to exclude from the build context.Usage
Using the helper script
Run the following command from the project root or the
dockerdirectory:This will:
maya1-tts.Manual Build and Run
Build:
docker build -t maya1-tts -f docker/Dockerfile .Run:
Notes
nvidia/cuda:12.1.1-devel-ubuntu22.04as the base image.requirements.txt.http://localhost:8000.http://localhost:8000/health.Summary by CodeRabbit
New Features
Documentation
Chores
Utilities
✏️ Tip: You can customize this high-level summary in your review settings.