Live data from Hacker News

A Go, Docker workflow

blog.crowdpatent.com

11–16 of 16 posts

Re: A Go, Docker workflow

#11
post #5
post #2

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 che…

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.

Re: A Go, Docker workflow

#12

Earlier quoted context omitted.

Has one of you tried xhyve? https://coreos.com/blog/coreos-and-xhyve-tech-preview/

Haven't heard but thanks for pointing out. It might be pretty useful actually as I develop on OS X and use CoreOS in production.

And if it is faster than boot2docker with VirtualBox, great!

Re: A Go, Docker workflow

#13
post #4

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 ...instead of target: make dependency 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…

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.

Re: A Go, Docker workflow

#15
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)

Re: A Go, Docker workflow

#16
post #4

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 ...instead of target: make dependency 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…

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…

good call on the .PHONY.
Post reply on HN