5 ms·

A Go, Docker workflow

32 points by johannesboyne 11y ago

olalonde 11y ago
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`
- johannesboyne 11y ago
  Yes, docker-compose (https://docs.docker.com/compose/ https://docs.docker.com/compose/) is just great. Another sweet tool, but I haven't used it in production yet, is empire (https://github.com/remind101/empire https://github.com/remind101/empire) for deployment (AWS centric).
- rcarmo 11y ago
  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 :)
  - olalonde 11y ago
    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.
- johannesboyne 11y ago
  Has one of you tried xhyve? https://coreos.com/blog/coreos-and-xhyve-tech-preview/ https://coreos.com/blog/coreos-and-xhyve-tech-preview/
  - deleted 11y ago
    [deleted]
  - johannesboyne 11y ago
    https://github.com/ailispaw/boot2docker-xhyve https://github.com/ailispaw/boot2docker-xhyve
  - olalonde 11y ago
    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.
    - johannesboyne 11y ago
      And if it is faster than boot2docker with VirtualBox, great!
rcarmo 11y ago
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 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 https://github.com/rcarmo/go-rss2imap/blob/master/Makefile (edit: whitespace)
- johannesboyne 11y ago
  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!
- austinpray 11y ago
  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-Targets.html 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/Makefile 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.
  - rcarmo 11y ago
    good call on the .PHONY.
vieux 11y ago
Why "FROM tianon/true" ? "FROM scratch" would be even smaller. That's what we use in the docker swarm image: https://github.com/docker/swarm-library-image/blob/master/Dockerfile https://github.com/docker/swarm-library-image/blob/master/Do...
keegancsmith 11y ago
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)

32 points by johannesboyne 11y ago

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`

johannesboyne 11y ago
Yes, docker-compose (https://docs.docker.com/compose/ https://docs.docker.com/compose/) is just great. Another sweet tool, but I haven't used it in production yet, is empire (https://github.com/remind101/empire https://github.com/remind101/empire) for deployment (AWS centric).
rcarmo 11y ago
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 :)
- olalonde 11y ago
  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.
johannesboyne 11y ago
Has one of you tried xhyve? https://coreos.com/blog/coreos-and-xhyve-tech-preview/ https://coreos.com/blog/coreos-and-xhyve-tech-preview/
- deleted 11y ago
  [deleted]
- johannesboyne 11y ago
  https://github.com/ailispaw/boot2docker-xhyve https://github.com/ailispaw/boot2docker-xhyve
- olalonde 11y ago
  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.
  - johannesboyne 11y ago
    And if it is faster than boot2docker with VirtualBox, great!

rcarmo 11y ago

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 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 https://github.com/rcarmo/go-rss2imap/blob/master/Makefile (edit: whitespace)

johannesboyne 11y ago
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!
austinpray 11y ago
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-Targets.html 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/Makefile 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.
- rcarmo 11y ago
  good call on the .PHONY.

vieux 11y ago

Why "FROM tianon/true" ? "FROM scratch" would be even smaller. That's what we use in the docker swarm image: https://github.com/docker/swarm-library-image/blob/master/Dockerfile https://github.com/docker/swarm-library-image/blob/master/Do...

keegancsmith 11y ago

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)