Flotilla is an alternative to fleet that uncouples from CoreOS/etcd and couples to AWS.
Flotilla uses:
- DynamoDb - for persistence, locking and communication
- ELB - to reroute traffic during an upgrade
- IAM - for access control
- KMS - for encryption of environment variables
- CloudFormation - for provisioning resources
- SQS - for communication between components
Like fleet, flotilla distributes systemd units across a cluster of machines.
Unlike fleet, flotilla manages environment variables for scheduled services, and supports weighted distributions of services (for canaries, A/B, load balancing, etc).
Flotilla introduces the concept of a service to distinguish worker instances. An instance is born into a service and advertises membership in DynamoDb.
A scheduler running in the cluster periodically checks for:
- Which units+configurations are defined for each service? What are their weights?
- How many instances are currently being used for this service?
Given these inputs, the scheduler updates assignments for instances to satsify the current configuration.
Currently there is a single scheduler for the entire cluster. DynamoDb parallel scans are the intended scaling path for multiple schedulers.
Flotilla workers periodically check for assignments in DynamoDb. If a worker's assignment is changed, it executes the following steps:
- Acquire deployment lock for service.
- If ELB is defined:
- Request deregistration from ELB.
- Wait for ELB deregistration (i.e. drain connections)
- Stop and unload all existing flotilla units.
- Start new flotilla units.
- If ELB is defined:
- Request registration to ELB.
- Wait for ELB registration (i.e. health check).
- Release deployment lock for service.
Don't use this in production. This implementation is output from 3x8h "hackathon"s.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
