

Tug: Use Docker for development - tombenner
https://github.com/nitrous-io/tug

======
bashtoni
Vagrant already does this nicely, and works with more than just Docker. For
those targeting production outside of Docker my company has made these images
available: [https://github.com/BashtonLtd/docker-vagrant-
images](https://github.com/BashtonLtd/docker-vagrant-images)

~~~
ddollar
Nice :) I believe Vagrant also now has built-in support for Docker which is
very useful for starting up ancillary services that your app needs:
[https://docs.vagrantup.com/v2/provisioning/docker.html](https://docs.vagrantup.com/v2/provisioning/docker.html)

I quite like Vagrant myself but my primary complaint is that I seem to spend a
lot of time waiting for VMs to start up and run a lot of bootstrap code.

~~~
mitchellh
Nice to talk to you again David!

You're linking to the wrong thing. This is the proper comparison to Tug:
[https://docs.vagrantup.com/v2/docker/index.html](https://docs.vagrantup.com/v2/docker/index.html)

Re your complaint: with the Docker provider, Vagrant only spins up _one_ VM
(if you're not on Linux). After that, `vagrant up` just executes `docker`
directly so there is no waiting around for bootstrapping. It even detects if
you have Docker installed locally or not to decide whether it needs to run in
the VM or not. And, if you're on Linux, it doesn't use a VM at all, unless
you're on a kernel that doesn't support Docker, in which case it
automatically/transparently starts the VM.

EDIT: Responding to David's comment below since it would go to deep: Vagrant
is basically the same here. It doesn't require Dockerfiles, you can just spin
up images.

~~~
ddollar
Awesome :) I think then that the primary difference with Tug is that it can
work in a "hybrid" virtualized/local mode if you haven't yet written a
Dockerfile/Vagrantfile/other for your app. Tug can start by simply spawning
dependencies like Postgres and Redis and let you incrementally move towards a
Dockerfile for your app.

~~~
ddollar
Thank you for the kind words and the clarifications Mitchell :)

Tug is a simple tool that I wrote to scratch a personal itch around working
with dockerized applications and trying to optimize for startup speed and
writing as absolutely little configuration as possible.

I'm hoping to get a few other people to try it out and let me know if it works
for them and if it's useful, especially given the existence of so many other
tools of this nature.

------
ddollar
Hello everyone! We created tug as a tool to help people dockerize applications
and run them during development.

Please keep in mind that this is a very alpha project still under heavy
development. If you try it I'd love to hear how it goes and whether or not
it's useful for you (you can reach me at david@nitrous.io or find me on
Freenode as ddollar).

~~~
gdamjan1
I don't understand the Tugfile format. How does it know that the first line is
the local app, and the second a docker image?

~~~
ddollar
Sorry about that! I'm trying to get the docs into shape as fast as possible.

If a line starts with "docker/" the rest is assumed to be a docker image tag.

~~~
gdamjan1
thanks

------
marcosnils
Seems like there's a new wave of projects like these lately. Fig and Crane
([https://github.com/michaelsauter/crane](https://github.com/michaelsauter/crane))
are the most popular ones but still I see other small things out there.

~~~
zentrus
And Docker bought Fig, so it is likely it will continue to be supported and
eventually even do multi-host container orchestration.

~~~
ddollar
I'm really excited about the idea of groups that may be coming to Docker. It
seems like a great primitive around which to build tools like fig and tug and
perhaps other tools to orchestrate production.

[https://www.youtube.com/watch?v=YuSq6bXHnOI](https://www.youtube.com/watch?v=YuSq6bXHnOI)

------
xsb
How is it different from [http://www.fig.sh](http://www.fig.sh) ?

~~~
ddollar
Tug primarily differs from fig in two ways:

* Less verbose configuration, tries to assume sensible defaults

* Works with apps that do not yet themselves have a Dockerfile

~~~
dekz
One of the features I heavily use from fig is controlling the runtime docker
parameters in fig.yml, i.e the VOLUME, ENTRYPOINT, EXPOSE, WORKDIR sort of
stuff. I see you guys made the decision to maintain the runtime commands in
your Dockerfile, requiring a rebuild to change it. Everything except
Environment.

I guess my question is, why did you guys choose to do that?

~~~
ddollar
I have not found myself needing to change those things very often once I have
created the initial Dockerfile.

If you've got the time I'd love to hear more about your workflow at
david@nitrous.io

------
freedrull
The problem I see with using docker for development is, you still need
different rails environments(development, test, etc.), the dockerfiles I've
been making are for production, and I'm not sure if they would work in the
other environments. Also you have to use tons of commands (rake, rspec,
migrate, etc) which at this point requires entering the container, which you
really shouldn't have to do unless there is a problem with the container
itself.

~~~
zenlikethat
One thing to note is that you can have multiple fig.yml files. So, you could
set slightly different configuration parameters (perhaps use `environment`
etc.) for different places you are using fig using the `-f` option to specify
a different fig.yml.

I don't think entering a container is bad for development, in fact it's a
frequent pattern (to run things like you describe rake etc.). With the release
of docker exec this becomes easier too. I think of it kind of like bind-
mounting a directory in the container to do code editing without having to
rebuild- as long as you are using ADD for every stage afterwards that should
be fully automated (QA, test, production) then you are in the clear.

------
pencilcheck
How does it know that web is the one to built with linking from other
commands? Also if there is no Dockerfile the web in the README is not running
in docker, how is the env being filled by the linking process? Is it
hardcoded?

