Server Infrastructure for Rails in 2016
summary
Claims that Docker runs in production with few problems and a six‑month rollout; apps become containerized Ruby 2.3 images with one process per container, env vars for config, and assets baked into images. CI cost rises — Docker builds add 15+ minutes and assets take 3–5 minutes — so self‑hosted Jenkins/Chunky preserves cache. Logs go to stdout and into a pipeline using Fluentd → Elasticsearch/Kibana (and Treasure Data/Redshift); use lograge formatting and Puma/Passenger for improved concurrency.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:59self.inspect
- 3:42Challenge we had
- 6:22Agenda
- 8:40Is Docker stable yet?
- 11:47Docker in 3 steps
- 14:22Minimal Docker setup
- 16:51A good container looks like
- 19:28Rails 5 is container-ready Several ENV variables to tweak default behaviours
- 21:59Our first try Just add Docker image building after Circle testing
- 23:02Why Docker cache fails on Cl services Docker uses time timestamp & other file metadata to compute cache digest.
- 25:17Bring your own CI server
- 30:29Fluentd loves Docker
- 31:08From Rails to Fluentd
- 33:08Recommended approach
- 36:04Is Rails thread safe yet? Major performance boost using threads
- 38:28Rails 5 loves Puma Rails 5 drops WEBrick and uses Puma.
- 40:03Common threading issues
- 41:02Summary
related talks
01h 01mShipping Ruby Apps with Docker
29mPackaging and Shipping Rails Applications in Docker
40mDeveloping Ruby Applications with Docker
40mContainerized Ruby Applications with Docker
07mLightning Talk: How Docker Can Change Rails Deployments
39mReal World Docker for the Rubyist
01h 04mPreparing your Dockerised Application for Production
40mContainerizing Rails: Techniques, Pitfalls, & Best Practices