Развертывание на Fly.io

Relevant source files

The following files were used as context for generating this wiki page:

• fly.toml
• README.md
• internal/core/config/config.go
• cmd/app/main.go
• docker-compose.yml

The music-service project is configured for production deployment on the Fly.io platform. This setup leverages containerization through Docker and provides an automated infrastructure for running the Go-based REST API alongside PostgreSQL and Redis instances. Deployment is managed via the flyctl CLI tool and integrated into a continuous delivery pipeline.

Sources: README.md:215-220, fly.toml:1-5

Infrastructure Configuration

The application infrastructure on Fly.io is defined by the fly.toml configuration file. The service is primarily hosted in the ams (Amsterdam) region and utilizes a shared CPU environment with 256MB of RAM.

Service Specifications

The application runs as an HTTP service listening on internal port 8080. Fly.io manages the routing, including automatic HTTPS enforcement and machine management (auto-starting and stopping based on traffic).

Deployment Process

The project supports both manual and automated deployment workflows. Manual deployment requires the flyctl tool, while automated deployment is handled by GitLab CI/CD.

Manual Deployment Steps

1. Initialization: Users must authenticate via flyctl auth login and initialize the project using flyctl launch.
2. Resource Provisioning: PostgreSQL and Redis databases must be created within the Fly.io environment and linked to the application.
3. Secret Management: Sensitive environment variables must be configured as Fly secrets.
4. Execution: The flyctl deploy command triggers the build and release process.

Automated CI/CD Pipeline

The deployment is automated through GitLab CI/CD, which triggers on every push to the main branch. The pipeline consists of two primary stages:

• Test: Executes all unit tests (skipping DB-heavy integration tests).
• Deploy: Automatically pushes the new version to Fly.io using a FLY_API_TOKEN stored in GitLab variables.

Configuration and Secrets

The application relies on environment variables for configuration. When deployed on Fly.io, these are managed via the flyctl secrets set command to ensure security.

Key Environment Variables

Variable	Usage	Source
DATABASE_URL	Connection string for Postgres	internal/core/config/config.go:34
DB_HOST/DB_USER	Individual DB params (fallback)	internal/core/config/config.go:37-41
REDIS_HOST	Host for the Redis instance	internal/core/config/config.go:43
JWT_ACCESS_SECRET	Secret key for access tokens	internal/core/config/config.go:46
JWT_REFRESH_SECRET	Secret key for refresh tokens	internal/core/config/config.go:47

Database Migrations

Fly.io is configured to run database migrations automatically during the deployment phase. This is controlled by the release_command in fly.toml, which executes the migration binary before the new application version goes live.

[deploy]
  release_command = "/bin/sh -c '/app/migrate -path /app/migrations -database \"$DATABASE_URL\" up'"

Sources: fly.toml:7-8, README.md:230-235

Application Entry Point

The application's main.go is designed to handle the environment provided by Fly.io. It specifically checks for a DATABASE_URL environment variable (standard for Fly.io Postgres attachments) before falling back to individual connection parameters.

// From cmd/app/main.go:61-66
var db *sqlx.DB
if cfg.DatabaseURL != "" {
    db, err = postgres.NewConnectionFromURL(cfg.DatabaseURL)
} else {
    db, err = postgres.NewConnection(cfg.DBHost, cfg.DBPort, cfg.DBUser, cfg.DBPassword, cfg.DBName, cfg.DBSSLMode)
}

Sources: cmd/app/main.go:61-66, internal/core/config/config.go:34

Summary

Deployment on Fly.io provides a robust production environment for the music-service. By utilizing fly.toml for infrastructure definition and GitLab CI/CD for automation, the project ensures consistent releases with integrated database migrations and secure secret management.