I’ve been boning up on Docker due to the promise of being able to reset Ruby on Rails instantly. (It takes a few minutes to destroy and rebuild my Debian Stable Vagrant box. And forget about trying to reinstall Ruby on Rails if you have it installed directly on the host OS.)
If you’re using Docker for Ruby on Rails, I’d like to learn more about your workflow. My standard operating procedure is to boot up my Debian Stable Vagrant box (https://github.com/jhsu802701/vagrant-debian-jessie-rvm) in one window, open up additional tabs in my command line shell program, and use “vagrant ssh” to enter my Vagrant box in these extra tabs. I use one terminal window for running the Rails server, one of running Guard, and one for executing other commands. I keep a browser window open for viewing my site locally. If I’m using the SQLite database in development, I use the SQLite browser program on my host OS to look at the data. If I’m using the PostgreSQL database in development, I use the pgadmin3 program on my host OS to look at the data.
If you’re using Docker for Ruby on Rails, I’d like to learn about your workflow. How do you go through Michael Hartl’s Rails Tutorial the Docker way?
By “reset”, I’m talking about returning Ruby on Rails to its original state from just after you first installed it and before you did anything with it.
My Debian Stable Vagrant base box comes with RVM pre-installed, along with multiple versions of Ruby, each with multiple versions of Rails. This takes several hours to build, but I use a Packer script to automate the process. The end result is stored as my Vagrant base box.
If you decided to use the “rvm implode” command just for kicks, how long would it be before you could start working on your Rails projects again? If you rely on Ruby on Rails installed directly in your host OS, this would take hours. On the other hand, if you were using my Vagrant box, it would be just a matter of destroying and rebuilding the box, and you’d be back in business in just a few minutes.
Since Docker avoids the overhead of having a virtual machine (which has to be booted up), the Docker way would allow you to return to the original state immediately. You can be back in business in seconds.
On Wed, Aug 19, 2015 at 12:16 PM, Jason Hsu, Ruby on High Speed Rails
By "reset", I'm talking about returning Ruby on Rails to its original state
from just after you first installed it and before you did anything with it.
What "state" do you imagine is associated with a collection of gems
after you "do anything" with them?
So, let's say I do `gem install rails`. Now I do
% cd projects
% rails new arff
% rails new blarg
What "state" about your gem installation has changed between the
first and second invocation of `rails`? What do you need to "reset"?
RVM problems (or possible RVM problems) are rare but have happened to me.
A much more common situation I’ve run into is a cascade of error messages when I tried to transfer my project to another development environment or when I tried to deploy my project.
In the case of Ruby gems, I’ve had times when I thought I was finished with my gem development, only to find I was missing one last critical step when I tried to use my gem in another gem or in a Rails app. This is why I insist on having the ability to quickly reinstall RVM. My Debian Stable Vagrant box allows me to do this in minutes. It’s not an option when using Ruby on Rails directly on the host OS.
For Rails projects, I’ve had times when my app worked in one development environment but didn’t work when I tried to transfer my work to another development environment or when I tried to deploy it in production, and I’d get flooded with error messages.
My Vagrant base box gives me a known good reference setup that behaves exactly the same every time, even on bad hair days and even when the cosmic dice come up snake eyes. For my Ruby gems, I now maintain a test_gem.sh script that does the setup and testing. When I rebuild my Vagrant box and git clone my Ruby gem source code, I just run this script to verify that everything works as expected. For my Rails apps, I now maintain a test_app.sh script that does the setup and testing. When I rebuild my Vagrant box and git clone my Rails app source code, I just run this script to verify that everything works as expected.
Using Ruby on Rails directly installed on the host OS doesn’t give me the ability to reinstall Ruby on Rails in a reasonable amount of time. When it comes to picking my primary development environment, this is a dealbreaker for me. The only reason I’d bother installing Ruby on Rails directly on the host OS is to have the ability to address complaints that my code doesn’t work in OS X or Windows.