WebCamp 2016: DevOps. Николай Дойков: Опыт создания клауда для потокового видео на docker swarm.
0 likes358 views
The document outlines the architecture and operational challenges of an elastic streaming cloud solution, emphasizing its deployment and resource management for over 1000 companies. It discusses the advantages of using Docker containers for quick deployment and updates, as well as the centralized logging and monitoring system. Key goals include responsive resource allocation, regional deployment, and maintaining efficient operations despite varying instance usage.
WebCamp 2016: DevOps. Николай Дойков: Опыт создания клауда для потокового видео на docker swarm.
- 2. Elastic streaming Cloud How we build it .
- 3. Speaker Nick Doikov Sr.Devops Engineer @ nick.doikov@gmail.com
- 4. Introductory - Over 1000 companies - Over 4000 separate users - Over 6000 streaming instances (cloud based and cloud attached) One
- 5. - update mess (application and base OS ) - partial access to client's infrastructure - To many resources need to support all this infrastructure - Instances are in active usage approx 10% max (3% in general) time - Users deploy own local servers (Distro? Kernel?)
- 6. - operational expenses - constant resource freeze (used or not) - core resources allocation (stats etc ...) - not suitable for rapid start-stop (can`t be used for instant start on connection) What we can do with all of this?
- 7. Docker containers : - Can be runned in a seconds - Real transparent start/stop for end customer - No os CPU,RAM overhead - Easily to update via images versioning
- 8. Streaming devices with bonding Bonding and streaming server
- 9. Previous flow with binding streaming server (Sputnik) in Amazon EC2
- 10. Goals - launch on device connect - Stop after streaming finished and all files uploaded - Centralized logging - Every time up to date container (no problems with software updates) - Oversell %) - Multi regions - Easy maintain and provisioning new points of presence
- 11. What we need - Static entry point that do not change due device unregister in Core - Static ports for stream capturing by 3rd party devices
- 15. Few notes : - Consul cluster behind elb - Swarm nodes announce themselves to Consul - Regions separated by DOCKER_OPTS Label - Container starts with region constraint - Inside container there are monitors that check application status and send metrics to core. - After connections from devices and upload connections was closed container “dies” after 30 minutes idle - Jobber delete stopped containers each 5 second - Centralized logging /alerting using async redis pubsub as a buffer and elasticsearch as a storage
- 16. What we get : - End user value (customer get enough resources exactly when he need it ) - Easy few steps node deploy (can be deployed on cloud providers as well as on colo) - Easy reached hybrid cloud model (cloud core and hardware calculation nodes) - Oversell %) - Now we have 9 regions (cloud providers + hardware POP)