Path: blob/main/memory-bank/components/service-waiter.md
2488 views
Service-Waiter Component
Overview
The Service-Waiter component in Gitpod is a utility service that waits for other services to become available before proceeding. It's designed to be used in initialization and deployment scenarios where services have dependencies on other services being ready. The component can wait for different types of services, including databases, Redis instances, and Kubernetes components, ensuring that a service doesn't start until its dependencies are fully operational.
Purpose
The primary purposes of the Service-Waiter component are:
Ensure services start in the correct order during deployment
Prevent services from starting before their dependencies are ready
Provide a consistent way to wait for different types of services
Handle timeouts and failure scenarios gracefully
Support different types of service readiness checks
Enable orchestration of complex multi-service deployments
Improve reliability of service startup sequences
Provide clear logging and error reporting for troubleshooting
Architecture
The Service-Waiter component is structured as a command-line tool with several subcommands for different types of services:
Database Waiter: Waits for a MySQL database to become available
Redis Waiter: Waits for a Redis instance to become reachable
Component Waiter: Waits for a Kubernetes component to be ready with the correct image
The component is designed to be run as a Kubernetes init container or as part of a deployment script, blocking until the target service is ready or a timeout is reached.
Key Features
Database Waiting
The database waiter:
Connects to a MySQL database using provided credentials
Checks if the database is reachable and responsive
Optionally verifies that the latest migration has been applied
Supports TLS connections with custom CA certificates
Retries connections with backoff until success or timeout
Redis Waiting
The Redis waiter:
Connects to a Redis instance at the specified host and port
Verifies connectivity by sending a PING command
Retries connections until success or timeout
Provides detailed logging of connection attempts
Component Waiting
The component waiter:
Checks if Kubernetes pods with specific labels are running
Verifies that pods are using the expected container image
Ensures that pods are in the Ready state
Monitors pod status until all pods are ready or timeout
Supports namespace-specific checks
Configuration
The Service-Waiter component can be configured through command-line flags or environment variables:
Global Configuration
--timeout
,-t
: Maximum time to wait (default: 5m orSERVICE_WAITER_TIMEOUT
env var)--verbose
,-v
: Enable verbose logging--json-log
,-j
: Produce JSON log output
Database Waiter Configuration
--host
,-H
: Database host (fromDB_HOST
env var)--port
,-p
: Database port (fromDB_PORT
env var, default: 3306)--username
,-u
: Database username (fromDB_USERNAME
env var, default: gitpod)--password
,-P
: Database password (fromDB_PASSWORD
env var)--caCert
: Custom CA certificate (fromDB_CA_CERT
env var)--migration-check
: Enable checking if the latest migration has been applied
Redis Waiter Configuration
--host
,-H
: Redis host (default: redis)--port
,-p
: Redis port (default: 6379)
Component Waiter Configuration
--image
: The latest image of current installer build--namespace
: The namespace of deployment--component
: Component name of deployment--labels
: Labels of deployment
Usage Patterns
Waiting for a Database
Waiting for Redis
Waiting for a Kubernetes Component
Using as an Init Container
Integration Points
The Service-Waiter component integrates with:
MySQL Databases: For database readiness checks
Redis Instances: For Redis readiness checks
Kubernetes API: For component readiness checks
Deployment Systems: As part of deployment scripts or init containers
Logging Systems: For reporting readiness status
Dependencies
Internal Dependencies
components/common-go
: Common Go utilitiescomponents/gitpod-db
: For database migration information
External Dependencies
MySQL client for database connections
Redis client for Redis connections
Kubernetes client for component checks
Cobra for command-line interface
Viper for configuration management
Security Considerations
The component implements several security measures:
TLS Support: For secure database connections
Password Masking: Passwords are masked in logs
Minimal Permissions: Only requires read access to check service status
Timeout Handling: Prevents indefinite hanging
Error Handling: Proper handling of connection errors
Related Components
Database: The service-waiter checks database availability
Redis: The service-waiter checks Redis availability
Kubernetes Components: The service-waiter checks component readiness
Deployment Systems: Use service-waiter to orchestrate deployments