As @csammy wrote below your post on diaspora*, he is willing to continue and finish the work. Let’s give him the time he needs, it doesn’t really matter if we wait a few months more. As for making anything official, I usually like postponing even thinking about that to a point where we actually have something to make official…
The following has to be taken with some grains of salt (and pepper), as I only started understanding and learning Docker recently (a year ago or so) and the amount of Docker images I produced for actual use is still single-digit, so I may be missing something in terms of maintainability etc.
We want to have something for development, so there are a few things I particularly dislike about @koehn’s container. The implementation may be fine for someone to use in production (although I still feel bad about this, but that’s a different discussion), but it is not suitable for a development env:
- Brads image has the sources inside the container. On build time, you pass in a Git URL, which the script will then clone inside the container. If someone wants to run a custom code base, they either have to commit it to some Git repo (which makes testing a pain) or manually bind the sources from a local directory inside the container (which requires knowledge of Docker). Sammys image always makes a git clone into a local directory, mounts the directory into the container and runs from there. Therefore, editing the source files is easy, and even auto-reloading works.
- The only reason we have people install RVM in production is so that we can control the Ruby version. For Docker, there are base images for every Ruby version out there, so that is not needed. Using the Ruby base images makes it much easier to update Ruby if needed, and also test with different versions.
- As for database support, Brads image only supports PG. This, again, is okay for production, but there are valid cases where we need to switch to MySQL for development. Sammys image sets up both, and decides which DB server to start based on the current
database.yml. For developers, all they have to do is change their database config and run
- The wrapper script makes it easy to run common commands like running tests or migrating the database inside the container without any hassle.
Ultimately, Brads image is fine for production installations if someone feels like it, but IMO, Sammys approach is much more suitable for providing a development environment. That’s probably because Brad designed the image for production setups, while Sammy designed a development environment, eh… I’d even go so far to say that we could tell someone with zero Docker experience to “clone this repo, run this script, and do development work” without any issues whatsoever, as the wrapper resolves all the points where someone would actually need to know Docker.
As Sammy started, and clearly states he is interested in finishing the work, I see no reason why we shouldn’t let him do that. If we have to wait a few months before publishing the blog post, so be it. It’s not like we have something to lose.