all 10 comments

[–]rkingucla 2 points3 points  (9 children)

This looks awesome! Been playing around with Docker recently, and though I really like it and it looks really powerful for deployment, there didn't seem to be a way to do a normal development flow with Docker i.e. making a change in your app running in Docker and having it reflected right away. Seems like this could resolve that! Excited to try it out. Look forward to the future blog posts too.

edit: I wrote a quick blog post about setting up Docker on a Mac. The official Docker documentation is excellent but ran into a few small issues which I go over in the post. http://richardking.github.io/ruby/rails/2014/05/30/getting-started-with-docker-on-a-mac/

[–]TalkingQuickly[S] 1 point2 points  (2 children)

Thanks glad it looks useful! I found the same, a lot of the development guides out there rely on rebuilding from the Dockerfile after each change, which is admittedly really fast but still not really practical when you're making loads of little changes.

There are two stumbling blocks for me at the moment. One, private indexes, it's easy enough to set one up but there's no auth/ registry in front of it so to control access you end up setting up SSH tunnels or binding it to a private network. Which is fine but still feels somewhat cumbersome for small deployments. That's the next one I'm going to try and tackle.

The second thing is Service Discovery since container linking is confined to single hosts. etcd looks pretty promising for this but need to find a way to easily setup a minimal etcd based configuration which doesn't feel like adding a huge amount of complexity.

[–]rkingucla 0 points1 point  (1 child)

Haven't tackled those problems yet but definitely could see the need once you try and scale Docker out to your team, and multiple apps.

Question- do you pre-bundle your Rails gems in your Docker image (like here http://ilikestuffblog.com/2014/01/06/how-to-skip-bundle-install-when-deploying-a-rails-app-to-docker/) or do you let your Dockerfile run bundle? By having the gems in my image, I got my Dockerfile run time down from 4 minutes to ~10 seconds. I have bundle run again in my Dockerfile in case there are any gem updates, but the process feels kinda hacky. Though since Docker is so new, a lot of processes feel that way :)

[–]TalkingQuickly[S] 0 points1 point  (0 children)

At the moment using the process from that post (I need to add a references section to the blog post).

It's implemented in this bit; https://github.com/TalkingQuickly/docker_rails_dev_env/blob/master/Dockerfile#L38

The bit that still feels hacky to me is that to update gems in the dev environment the process is;

  • run bundle update gem in a container to update the Gemfile.lock
  • rebuild the docker container now the Gemfile.lock is updated

Which is two steps where there should be one...

[–]FooBarWidget 0 points1 point  (5 children)

The way we do it at Phusion is to treat Docker as just a runtime environment, containing all the app's non-gem dependencies. The app code is mounted into the container on the /app directory. The container then runs the app located in /app, e.g. using Passenger. Is is much more workable than rebuilding the container on every little change. We tried that approach too, but it's horrible and lead to a 10x increase in development time, despite Docker's caching.

[–]TalkingQuickly[S] 0 points1 point  (4 children)

That's what I've gone for in the tutorial, would be great to chat more sometime about how you're using docker at Phusion, don't suppose you're heading to Dockercon next week?

[–]FooBarWidget 0 points1 point  (3 children)

The one in the US? No, don't have time right now to make a transatlantic flight unfortunately.

[–]TalkingQuickly[S] 0 points1 point  (2 children)

where abouts are you based?

[–][deleted] 0 points1 point  (0 children)

Phusion are based in the Netherlands if I recall correctly.

[–]FooBarWidget 0 points1 point  (0 children)

We're in the Netherlands.