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 H.'s Rails Tutorial the
Docker
way?
On Wed, Aug 19, 2015 at 10:31 AM, Jason H., Ruby on High Speed Rails [email protected] wrote:
Is anyone here using Docker for Ruby on Rails?
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.)
Just curious – what exactly do you mean by “reset” here?
And what is the perceived problem with “reinstalling”? A fresh rails
install on Ruby 2.2.3 just now took ~30 seconds on a relatively old
MacbBook Air, and half that time was building nokogiri extensions.
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 H., Ruby on High Speed Rails [email protected] wrote:
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.
On Wed, Aug 19, 2015 at 3:32 PM, Jason H., Ruby on High Speed Rails [email protected] wrote:
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.
That’s like saying “the front door I installed sticks, so I need to be
able to burn the house down and build a new one.”
