6 ms·

Fig 1.0: Boot2docker compatibility and more

65 points by CSDude 12y ago

deadweight3 12y ago
So is this essentially the same as Vagrant then? I'm really confused now.
- quantisan 12y ago
  the concept is the same as Vagrant. but it's substantially faster. when you `fig up` your app, it spins up almost instantaneously because it's backed by Docker.
- gdw2 12y ago
  Similar ends, but different means. Vagrant would launch a full-blown VM (likely on the order of several minutes), whereas fig'ing will start a container (on the order of a few seconds).
  - nailer 12y ago
    Fig still requires boot2docker, which uses VirtualBox. See linked page at https://docs.docker.com/installation/mac/ https://docs.docker.com/installation/mac/ Note VirtualBox is one of the only modules blacklisted by the Linux kernel not for being proprietary (it's Open Source) but because it's terrible. http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw
    - zenlikethat 12y ago
      Fig only requires boot2docker if you are not working directly on Linux, this is true for docker itself as well. We agree that VBox is not ideal but it is free and we would like to have other options (Fusion, HyperV) available in the future as well.
    - samuel1604 12y ago
      I use fig with volume from my mac under vmware without any problem
    - cpuguy83 12y ago
      boot2docker is a tiny Linux distro and does not require any specific virtualization tool, or even virtualization at all. For the sake of simplicity and distribution the OSX and Windows installers package boot2docker with Virtualbox.
- mitchellh 12y ago
  I haven't seen how it has evolved, but historically it has been basically the same as our Docker provider: http://docs.vagrantup.com/v2/docker/index.html http://docs.vagrantup.com/v2/docker/index.html The other comments at this level saying Vagrant spins up a full VM are incorrect. Vagrant will spin up boot2docker if it isn't running (which Fig requires as well), and then just execute Docker to run containers. On Linux, Vagrant doesn't spin up a VM at all; it just executes Docker directly. I'm not here to talk about Fig vs. Vagrant, since I think this thread should be about congratulating Fig to 1.0, but I did want to make sure that some facts aren't incorrect.
  - deadweight3 12y ago
    Right, I really phrased that poorly. I use vagrant on a windows machine in the office and various macs at home. Without the LXC, fig & docker don't really provide anything above what I'm using. Were I to move to linux, then this would have some advantages. Thanks for the clarification and a fantastic product.
- zenlikethat 12y ago
  They are different tools for different use cases. Fig is a tool written in Python specifically designed to orchestrate groups of docker containers. It does not require virtualization by default, it talks directly to the Docker API (so you can use it directly on Linux without boot2docker/VirtualBox). It is useful because previously people were writing their own custom little Bash scripts etc. to bootstrap containers for e.g. a PHP app to run app code, a MySQL database, a redis instance and an instance of nginx to serve static files which are all meant to be tied together and work together in a specific way. One of the goals of docker is "one concern per container" so this helps people to use it in the right way and you don't have to, say, restart your database to restart your app (like you would if you crammed them all into one container). Vagrant is a general purpose tool for automation and management of virtual machines written in Ruby. You specify configuration in Ruby. One of its goals is choice, so it has swappable "drivers" (so that you can use different hypervisors such as VirtualBox, Fusion, and HyperV) and "provisioners" (for installing software etc. when you bootstrap a new VM). I'm afraid I have to plead ignorance on the Docker provisioner, but mitchellh is the creator so I'm sure his input is sound.
throwaway1979 12y ago
Why does the fig documentation emphasis development environments. Isn't fig a general orchestration tool for deploying containers on a single host?
- enos_feedler 12y ago
  How many production environments deploy all containers on a single host?
  - Zariel 12y ago
    If your not then your missing out on utilising your resources, check out Mesos or Kubernetes for instance.
    - ossreality 12y ago
      I don't know on what planet "Kubernetes" is an answer to "Who runs all containers on a single host". Because that's sure not what Kubernetes or Mesos do.
  - skrebbel 12y ago
    A lot? I Guess? Why not? In fact, I'm amazed at the amount of businesses that don't. Half of what TechCrunch writes about is, in technical terms, Rails CRUD apps. Why would they need more than a single host in the first year?
    - Jare 12y ago
      Because hosts die.
  - TheMakeA 12y ago
    There's fig2coreos[1] which will translate your fig.yml into systemd files. Then you could deploy across a CoreOS cluster[2]. Pretty interesting. [1] https://github.com/centurylinklabs/fig2coreos https://github.com/centurylinklabs/fig2coreos [2] http://www.centurylinklabs.com/building-complex-apps-for-docker-on-coreos-and-fig/ http://www.centurylinklabs.com/building-complex-apps-for-doc...
kolev 12y ago
I'm not sure why Fig got so popular, when Crane [1] was on Go since day one, is actively developed, and pretty much does the same thing maybe even better. I haven't seen the latest Fig features though. Maybe Fig finally does more, but ideally they should merge especially when Fig is planning to migrate to Go! [1] https://github.com/michaelsauter/crane https://github.com/michaelsauter/crane
- nickstinemates 12y ago
  I didn't know about Crane. Time to go play with that!
- cnp 12y ago
  Crane looks so perfectly simple and sweet
andrewstuart2 12y ago
> Beyond that, we’ve got new commands, .dockerignore support Gosh dangit. It's about to the point I need a separate tool just to manage all my .ignore files. Come to think of it, maybe just ln -s will do.
- nickstinemates 12y ago
  Agree, I think ignore files are leaky abstractions. The problem is specificity.
- zenlikethat 12y ago
  Usually I just have a very tiny .dockerignore with .git in it (since .git usually grows so huge), although some applications store logs and stuff that you should probably not send to the docker daemon every time. I've found Github's auto-generated-by-language .gitignore files very useful.
  - andrewstuart2 12y ago
    I think it's just a tiny wrapper that oh-my-zsh has, but I have a `gi` bash function that calls out to gitignore.io/api/$@. Then I just redirect the response to .gitignore. `gi vim,linux,node,grunt,bower > .gitignore` Super handy.
    - zenlikethat 12y ago
      Nice!
- shykes 12y ago
  Glad someone agrees with me :) For what it's worth, I resisted adding .dockerignore as long as I could, basically for the same reason (why not add .gitignore support instead?) but the demand for it was simply too overwhelming to ignore, so I gave up and let it in. See https://github.com/docker/docker/pull/3452 https://github.com/docker/docker/pull/3452 and follow -up mailing list thread. In the end it kind of grows on you :)
general_failure 12y ago
What exactly is Fig?
- Goopplesoft 12y ago
  It links docker containers for local dev environments. You can launch a project with say a webapp, a cache like redis, and a db like mysql with the comamnd 'fig up'. The 3 docker containers in this case are linked via a fig.yml that defines the setup. It also attaches your local development code so realtime changes propgate through the cotainer (e.g live server reloads) Getting a new dev onboarded with your whole dockerized stack involves: - pip install fig - cd into directory with fig.yml -'fig up' Really a great tool. Definitely recommend it. Good intro here: http://www.fig.sh/ http://www.fig.sh/
  - general_failure 12y ago
    Ahh.. Almost heroku style but locally. Looks super useful to me!
  - skrebbel 12y ago
    Not just for local dev environments. You can easily deploy on a host too, works the same.
- rmgraham 12y ago
  I keep thinking of it as kinda like foreman/Procfile but for Docker containers instead of bare processes. And with a much richer config format.
calebm 12y ago
This is awesome. I've been waiting on the docker 1.3 release and integration into Fig to begin using it.
inzax 12y ago
As shown on https://www.facebook.com/pages/Hacker-News/1558365107716690 https://www.facebook.com/pages/Hacker-News/1558365107716690
helfire 12y ago
I was playing with Fig, SpringBoot, Node and postgres stack this afternoon. Playing with Docker since its release this is the first time is really all clicked together. Here's my notes - https://erichelgeson.github.io/blog/2014/10/17/docker-springboot-microservices/ https://erichelgeson.github.io/blog/2014/10/17/docker-spring...
testhater 12y ago
aww hell

65 points by CSDude 12y ago

deadweight3 12y ago

So is this essentially the same as Vagrant then? I'm really confused now.

quantisan 12y ago
the concept is the same as Vagrant. but it's substantially faster. when you `fig up` your app, it spins up almost instantaneously because it's backed by Docker.
gdw2 12y ago
Similar ends, but different means. Vagrant would launch a full-blown VM (likely on the order of several minutes), whereas fig'ing will start a container (on the order of a few seconds).
- nailer 12y ago
  Fig still requires boot2docker, which uses VirtualBox. See linked page at https://docs.docker.com/installation/mac/ https://docs.docker.com/installation/mac/ Note VirtualBox is one of the only modules blacklisted by the Linux kernel not for being proprietary (it's Open Source) but because it's terrible. http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw
  - zenlikethat 12y ago
    Fig only requires boot2docker if you are not working directly on Linux, this is true for docker itself as well. We agree that VBox is not ideal but it is free and we would like to have other options (Fusion, HyperV) available in the future as well.
  - samuel1604 12y ago
    I use fig with volume from my mac under vmware without any problem
  - cpuguy83 12y ago
    boot2docker is a tiny Linux distro and does not require any specific virtualization tool, or even virtualization at all. For the sake of simplicity and distribution the OSX and Windows installers package boot2docker with Virtualbox.
mitchellh 12y ago
I haven't seen how it has evolved, but historically it has been basically the same as our Docker provider: http://docs.vagrantup.com/v2/docker/index.html http://docs.vagrantup.com/v2/docker/index.html The other comments at this level saying Vagrant spins up a full VM are incorrect. Vagrant will spin up boot2docker if it isn't running (which Fig requires as well), and then just execute Docker to run containers. On Linux, Vagrant doesn't spin up a VM at all; it just executes Docker directly. I'm not here to talk about Fig vs. Vagrant, since I think this thread should be about congratulating Fig to 1.0, but I did want to make sure that some facts aren't incorrect.
- deadweight3 12y ago
  Right, I really phrased that poorly. I use vagrant on a windows machine in the office and various macs at home. Without the LXC, fig & docker don't really provide anything above what I'm using. Were I to move to linux, then this would have some advantages. Thanks for the clarification and a fantastic product.
zenlikethat 12y ago
They are different tools for different use cases. Fig is a tool written in Python specifically designed to orchestrate groups of docker containers. It does not require virtualization by default, it talks directly to the Docker API (so you can use it directly on Linux without boot2docker/VirtualBox). It is useful because previously people were writing their own custom little Bash scripts etc. to bootstrap containers for e.g. a PHP app to run app code, a MySQL database, a redis instance and an instance of nginx to serve static files which are all meant to be tied together and work together in a specific way. One of the goals of docker is "one concern per container" so this helps people to use it in the right way and you don't have to, say, restart your database to restart your app (like you would if you crammed them all into one container). Vagrant is a general purpose tool for automation and management of virtual machines written in Ruby. You specify configuration in Ruby. One of its goals is choice, so it has swappable "drivers" (so that you can use different hypervisors such as VirtualBox, Fusion, and HyperV) and "provisioners" (for installing software etc. when you bootstrap a new VM). I'm afraid I have to plead ignorance on the Docker provisioner, but mitchellh is the creator so I'm sure his input is sound.

throwaway1979 12y ago

Why does the fig documentation emphasis development environments. Isn't fig a general orchestration tool for deploying containers on a single host?

enos_feedler 12y ago
How many production environments deploy all containers on a single host?
- Zariel 12y ago
  If your not then your missing out on utilising your resources, check out Mesos or Kubernetes for instance.
  - ossreality 12y ago
    I don't know on what planet "Kubernetes" is an answer to "Who runs all containers on a single host". Because that's sure not what Kubernetes or Mesos do.
- skrebbel 12y ago
  A lot? I Guess? Why not? In fact, I'm amazed at the amount of businesses that don't. Half of what TechCrunch writes about is, in technical terms, Rails CRUD apps. Why would they need more than a single host in the first year?
  - Jare 12y ago
    Because hosts die.
- TheMakeA 12y ago
  There's fig2coreos[1] which will translate your fig.yml into systemd files. Then you could deploy across a CoreOS cluster[2]. Pretty interesting. [1] https://github.com/centurylinklabs/fig2coreos https://github.com/centurylinklabs/fig2coreos [2] http://www.centurylinklabs.com/building-complex-apps-for-docker-on-coreos-and-fig/ http://www.centurylinklabs.com/building-complex-apps-for-doc...

kolev 12y ago

I'm not sure why Fig got so popular, when Crane [1] was on Go since day one, is actively developed, and pretty much does the same thing maybe even better. I haven't seen the latest Fig features though. Maybe Fig finally does more, but ideally they should merge especially when Fig is planning to migrate to Go! [1] https://github.com/michaelsauter/crane https://github.com/michaelsauter/crane

nickstinemates 12y ago
I didn't know about Crane. Time to go play with that!
cnp 12y ago
Crane looks so perfectly simple and sweet

andrewstuart2 12y ago

> Beyond that, we’ve got new commands, .dockerignore support Gosh dangit. It's about to the point I need a separate tool just to manage all my .ignore files. Come to think of it, maybe just ln -s will do.

nickstinemates 12y ago
Agree, I think ignore files are leaky abstractions. The problem is specificity.
zenlikethat 12y ago
Usually I just have a very tiny .dockerignore with .git in it (since .git usually grows so huge), although some applications store logs and stuff that you should probably not send to the docker daemon every time. I've found Github's auto-generated-by-language .gitignore files very useful.
- andrewstuart2 12y ago
  I think it's just a tiny wrapper that oh-my-zsh has, but I have a `gi` bash function that calls out to gitignore.io/api/$@. Then I just redirect the response to .gitignore. `gi vim,linux,node,grunt,bower > .gitignore` Super handy.
  - zenlikethat 12y ago
    Nice!
shykes 12y ago
Glad someone agrees with me :) For what it's worth, I resisted adding .dockerignore as long as I could, basically for the same reason (why not add .gitignore support instead?) but the demand for it was simply too overwhelming to ignore, so I gave up and let it in. See https://github.com/docker/docker/pull/3452 https://github.com/docker/docker/pull/3452 and follow -up mailing list thread. In the end it kind of grows on you :)

general_failure 12y ago

What exactly is Fig?

Goopplesoft 12y ago
It links docker containers for local dev environments. You can launch a project with say a webapp, a cache like redis, and a db like mysql with the comamnd 'fig up'. The 3 docker containers in this case are linked via a fig.yml that defines the setup. It also attaches your local development code so realtime changes propgate through the cotainer (e.g live server reloads) Getting a new dev onboarded with your whole dockerized stack involves: - pip install fig - cd into directory with fig.yml -'fig up' Really a great tool. Definitely recommend it. Good intro here: http://www.fig.sh/ http://www.fig.sh/
- general_failure 12y ago
  Ahh.. Almost heroku style but locally. Looks super useful to me!
- skrebbel 12y ago
  Not just for local dev environments. You can easily deploy on a host too, works the same.
rmgraham 12y ago
I keep thinking of it as kinda like foreman/Procfile but for Docker containers instead of bare processes. And with a much richer config format.

calebm 12y ago

This is awesome. I've been waiting on the docker 1.3 release and integration into Fig to begin using it.

inzax 12y ago

As shown on https://www.facebook.com/pages/Hacker-News/1558365107716690 https://www.facebook.com/pages/Hacker-News/1558365107716690

helfire 12y ago

I was playing with Fig, SpringBoot, Node and postgres stack this afternoon. Playing with Docker since its release this is the first time is really all clicked together. Here's my notes - https://erichelgeson.github.io/blog/2014/10/17/docker-springboot-microservices/ https://erichelgeson.github.io/blog/2014/10/17/docker-spring...

testhater 12y ago

aww hell