Yes, we do it at Basecamp for all of our legacy apps (and our newest one, HEY), and we've ran Basecamp 2 in production via Kubernetes (we no longer do it, but we did it for a lengthy period of time).
Nothing Kubernetes-related, it was provider-related. We hurriedly moved Basecamp 2 back on-prem after a string of outages caused by our cloud provider at the time. There are a bunch of blog posts on Signal v Noise from early 2019 that talk about it.
Kubernetes for HEY, ECS for the other legacy apps that I mentioned are using Docker, bare metal for Basecamp 2 & 3 (but K8s is on the roadmap for both of them)
GitLab has a pretty nice image for running their Community Edition in Docker.
I've investigated it a few times for several Rails applications that I maintain, but I've never completed a rollout. Running Rails on Docker isn't a huge hurdle, but Capistrano's default git-based deploys are just so _easy and fast_ once the server is set up. I also have to balance deploying Docker with ops' expertise.
I do recommend getting a copy of _Docker for Rails Developers_ to avoid needing to read a bunch of disparate blogs, though it covers Docker Swarm instead of Kubernetes.
We have a number of Dockerized Rails apps hosted on AWS Elastic Beanstalk. It isn't quite as smooth as Heroku but once setup it has been quite solid. The parity between develop and prod is decent, we use docker-compose and localstack to simulate backing services.
We've had our Rails like apps (Sinatra, Padrino) Dockerized for 5 years now and running on container orchestration systems. First Mesos, now Kubernetes. And some running as Lambdas as well. We do not have a single production app not in a container and we are mostly Ruby.
I use docker as a build server. At the end of the project it spits out a debian package that I can install on a machine. It doesn't need bundler, only ruby and the gem command (up to a certain version). Quite a nice setup if you look for bare metal performance
I run my side project in Docker on Kubernetes, works well and wasn’t too annoying to set up. Compared to getting my Go deployments to run it was kind of a pain though.
COPY drkiq/Gemfile Gemfile
WORKDIR /opt/app/drkiq
RUN bundle install
This appears to be leaving out copying Gemfile.lock so you have no real idea what versions of dependencies are being installed here. This is not safe. Also it's installing a bunch of dependencies that are not needed in production, a better bundle command would be something like: `RUN bundle install --no-cache --jobs 4 --without development test`
RUN rails webpacker:install
RUN rails assets:precompile
Why is `rails webpacker:install` being run here? This is very odd. As a general tip, I would also not compile assets as part of the docker build, but rather externally then only copy over the `public` directory afterward. This removes any need for `node` or any related development tools/packages in the production image.
You can but I've not found the value in the complexity. The CI container image already requires node and all the needed dev packages for tests to run anyway so I just run the precompile in the CI container after tests pass then copy the resulting `public` directory into the production container.
This also means the same exact environment is used to generate the production assets that was used to generate them for test.
> This appears to be leaving out copying Gemfile.lock so you have no real idea what versions of dependencies are being installed here. This is not safe.
As someone who's only touched Ruby for a few years (and not even Ruby on Rails): I wouldn't have even known to look for a Gemfile.lock.
> As someone who's only touched Ruby for a few years
Well... Gemfile.lock has nothing to do with rails and all to do with Bundler, but if you've never used Bundler for dependency management it's possible that it's new to you.
I only have a couple of years of experience with rails and haven't touched it in 6 years, but I'd be very sceptical of any article that tries to teach how to build projects in rails and doesn't even get those basics right.
Yes you could do that for all your gems... Or you could just copy in Gemfile.lock. One of the big reasons to run in containers is repeatability and knowing if it runs in your local Docker fine it will run the same on another Docker like system.
Any suggestions on how to do zero-downtime deploys with a Rails app running on Docker?
I guess an obvious one is to use two running images, pull incoming requests from one of them, take it down, update, bring it up, start traffic flow again. Repeat for the other.
You don’t need to take your old app down or update during your cutover. Your new app will be a new docker image, so just run an instance ahead of time.
When it comes to deploy, just repoint your load balancer/proxy.
28 comments
[ 2.9 ms ] story [ 26.1 ms ] threadI've been using Rails for years, I haven't yet experienced much pain by way of language/library versioning (etc). Python is a different story...
I've investigated it a few times for several Rails applications that I maintain, but I've never completed a rollout. Running Rails on Docker isn't a huge hurdle, but Capistrano's default git-based deploys are just so _easy and fast_ once the server is set up. I also have to balance deploying Docker with ops' expertise.
I do recommend getting a copy of _Docker for Rails Developers_ to avoid needing to read a bunch of disparate blogs, though it covers Docker Swarm instead of Kubernetes.
[1] https://www.amazon.com/Docker-Rails-Developers-Applications-...
This also means the same exact environment is used to generate the production assets that was used to generate them for test.
As someone who's only touched Ruby for a few years (and not even Ruby on Rails): I wouldn't have even known to look for a Gemfile.lock.
Perhaps the author doesn't know either.
Well... Gemfile.lock has nothing to do with rails and all to do with Bundler, but if you've never used Bundler for dependency management it's possible that it's new to you.
But Bundler (and the Gemfile and Gemfile.lock) are one of the core components of rails, they even get mentioned in the getting started page (https://guides.rubyonrails.org/getting_started.html).
I only have a couple of years of experience with rails and haven't touched it in 6 years, but I'd be very sceptical of any article that tries to teach how to build projects in rails and doesn't even get those basics right.
gem 'byebug', '1.1.0'
I guess an obvious one is to use two running images, pull incoming requests from one of them, take it down, update, bring it up, start traffic flow again. Repeat for the other.
But is there any other method?
When it comes to deploy, just repoint your load balancer/proxy.