7 ms·

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