15 comments

[ 4.1 ms ] story [ 46.4 ms ] thread
Worth checking out docker-compose for more complex setups (if you need a Redis and PostgreSQL database running for example). I have been using it for Node.js development for the past few months and it is really a life changer especially if you are working on multiple projects concurrently. Pro-tip: `echo "alias dc=docker-compose" >> ~/.zshrc`
Yeah. I've been using fig for a while now (and will eventually replace everything with compose), and it's simpler than Vagrant for reproducible environments.

There is one little caveat when using boot2docker, in that when you're running tests on a separate terminal you need to be careful to remember to do $(boot2docker shellinit) _and_ expose container ports so that they're visible outside the boot2docker VM - so check your IPs and make sure your containers log the environment variables they're using for links, so that you can check where to connect your tests :)

Yeah $(boot2docker shellinit) is a bit annoying but I use tmuxinator which does it for me with `pre: boot2docker up && $(boot2docker shellinit);`. You could also add it to your .bashrc/.zshrc.

For automated tests, I simply have a test service which I start with `docker-compose up test` and I can link services my tests need from inside `docker-compose.yml`.

For manual testing, I added `192.168.59.103 docker` to my `/etc/hosts` file (the boot2docker IP doesn't seem to change) and expose ports on the boot2docker VM though that means I can't test two containers which expose the same port simultaneously.

That Makefile is... weird. Why issue a "make sub-target" command? Makefiles are all about understanding dependencies, so you should actually be doing

    target: dependency
        <commands>
...instead of

    target:
        make dependency
        <commands>
Doing it this way actually breaks dependency checks. It's just plain wrong.

Here's a "proper" Makefile, complete with conditionals, expansion, etc.:

https://github.com/rcarmo/sushy/blob/master/Makefile

...and here's one of my Go Makefiles (no sub-targets here, but does vendoring in a way that's quite similar to what Go 1.5 turned out to adopt)

https://github.com/rcarmo/go-rss2imap/blob/master/Makefile

(edit: whitespace)

Thanks rcarmo for bringing this up. You're right, it is a better, and the only right, approach to declare the dependencies like you proposed. I've updated the code!
One thing to point out specifically about "proper" Makefiles: the author should be marking his `.PHONY` targets (https://www.gnu.org/software/make/manual/html_node/Phony-Tar...) and giving sources. This gives you incremental builds for free.

One of my Makefiles: https://github.com/liveplant/liveplant-server/blob/master/Ma...

Definitely open to feedback on the above. Seems like my Makefile doing pretty much the same thing as yours @rcarmo.

good call on the .PHONY.
An improvement I'd make to this is not sending the current directory to docker, but rather a directory containing just the binary. That way you don't send a massive context to docker which you just throw away. (Especially in go projects which vendor in a lot of dependencies)