28 ms·

Tug: Use Docker for development

92 points by tombenner 12y ago

xsb 12y ago
How is it different from http://www.fig.sh http://www.fig.sh ?
- scast 12y ago
  Less powerful.
  - callumjones 12y ago
    (Disclaimer: I work for Nitrous.IO) I wouldn't describe tug as less powerful, it's less complicated from my usage of it. For each service I only need to write one line and tug will figure out (from the Dockerfile) what needs to be forwarded. The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host.
    - cmwelsh 12y ago
      > The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host. That's easily achieved with a Vagrantfile for your Docker VM...
      - callumjones 12y ago
        I wouldn't say it's that easy, if you add more containers to your Docker VM and need them forwarded you then need to update your Vagrantfile and reload. With tug any port you expose on the containers is brought locally to you instantly.
- ddollar 12y ago
  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 12y ago
    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 12y ago
      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
marcosnils 12y ago
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 12y ago
  And Docker bought Fig, so it is likely it will continue to be supported and eventually even do multi-host container orchestration.
  - ddollar 12y ago
    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
  - nnutter 12y ago
    Except Docker said Fig is a dead end and that its functionality would be integrated into `docker` itself.
bashtoni 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      thanks
deleted 12y ago
[deleted]
Tepix 12y ago
There's a naming conflict, tug is also the name of an open world game on steam that is currently in early access.
freedrull 12y ago
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 12y ago
  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 12y ago
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?

92 points by tombenner 12y ago

xsb 12y ago

How is it different from http://www.fig.sh http://www.fig.sh ?

scast 12y ago
Less powerful.
- callumjones 12y ago
  (Disclaimer: I work for Nitrous.IO) I wouldn't describe tug as less powerful, it's less complicated from my usage of it. For each service I only need to write one line and tug will figure out (from the Dockerfile) what needs to be forwarded. The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host.
  - cmwelsh 12y ago
    > The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host. That's easily achieved with a Vagrantfile for your Docker VM...
    - callumjones 12y ago
      I wouldn't say it's that easy, if you add more containers to your Docker VM and need them forwarded you then need to update your Vagrantfile and reload. With tug any port you expose on the containers is brought locally to you instantly.
ddollar 12y ago
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 12y ago
  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 12y ago
    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

marcosnils 12y ago

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 12y ago
And Docker bought Fig, so it is likely it will continue to be supported and eventually even do multi-host container orchestration.
- ddollar 12y ago
  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
- nnutter 12y ago
  Except Docker said Fig is a dead end and that its functionality would be integrated into `docker` itself.

bashtoni 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago

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 12y ago
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 12y ago
  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 12y ago
    thanks

deleted 12y ago

[deleted]

Tepix 12y ago

There's a naming conflict, tug is also the name of an open world game on steam that is currently in early access.

freedrull 12y ago

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 12y ago
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 12y ago

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?