Live data from Hacker News

Fig: Fast, isolated development environments using Docker

orchardup.github.io

21–30 of 45 posts

Re: Fig: Fast, isolated development environments using Docker

#21
I'm not involved with this project but there is some confusions in this thread, maybe I can share my point of view:

Docker is a tool to run processes with some isolation and, that's the big selling point, nicely packaged with "all" their dependencies as images.

To understand "all" their dependencies, think C dependencies for e.g. a Python or Ruby app. That's not the kind of dependencies e.g. virtualenv can solve properly. Think also assets, or configuration files.

So instead of running `./app.py` freshly downloaded from some Git , you would run `docker run ./app.py`. In the former case, you would need to care of, say, the C dependencies. In the second case, they are packaged in the image that Docker will download from prior to run the ./app.py process in it. (Note that the two are not the same things. One is a Git repo, the other is a Docker repo.)

So really at this point, that's what Docker is about: running processes. Now Docker offers a quite rich API to run the processes: shared volumes (directories) between containers (i.e. running images), forward port from the host to the container, display logs, and so on.

But that's it: Docker as of now, remains at the process level. While it provides options to orchestrate multiple containers to create a single "app", it doesn't address the managemement of such group of containers as a single entity.

And that's where tools such as Fig come in: talking about a group of containers as a single entity. Think "run an app" (i.e. "run an orchestrated cluster of containers") instead of "run a container".

Now I think that Fig comes short of that goal (I haven't played with it, that's just from a glance at its docuementation). Abstracting over the command-line arguments of Docker by wrapping them in a JSON file is the easy part (i.e. launching a few containers). The hard part is about managing the cluster as Docker manages the containers: display aggregated logs, replace a particular container by a new version, move a container to a different host, and thus abstract the networking between different hosts, and so on.

This is not a negative critique of Fig. Many people are working on that problem. For instance I solve that very problem with ad-hoc bash scripts. Doing so we are just exploring the design space.

I believe that Docker itself will provide that next level in the future; it is just that people need the features quickly.

tl;dr:

Docker -> processes

Fig (and certainly Docker in the future) -> clusters (or formations) of processes

Re: Fig: Fast, isolated development environments using Docker

#22
post #15
post #2

I'd love to use this .. but who has time to learn yet another configuration and provisioning management tool? I mean, I can make the time - and will - but since this is just another docker management tool, lets use this moment to pick on it, a little bit.. What this needs is the ability to be pointed at a working VM - lets say, Ubuntu 13.10 server - and then just figure out whats different about it, compared to the d…

I don't have a ton of experience with any of them, but fig.yaml looks dramatically simpler and easier to learn than Chef or Puppet. (It also solves a much narrower problem, but I think the point remains.) What this needs is the ability to be pointed at a working VM - lets say, Ubuntu 13.10 server - and then just figure out whats different about it, compared to the distro release. It sounds like you want Blueprint ( h…

> I found this to not actually be a very useful approach in practice.

Could you expand on this, please? I'm curious to know what the problems were (just so I know what I'm letting myself in for)

Re: Fig: Fast, isolated development environments using Docker

#23
post #21

I'm not involved with this project but there is some confusions in this thread, maybe I can share my point of view: Docker is a tool to run processes with some isolation and, that's the big selling point, nicely packaged with "all" their dependencies as images. To understand "all" their dependencies, think C dependencies for e.g. a Python or Ruby app. That's not the kind of dependencies e.g. virtualenv can solve prop…

You can package all of your apps dependencies in one image and have a script in the container start them.

Re: Fig: Fast, isolated development environments using Docker

#24

can someone explain to me the application of Fig and Docker? Also, how do they differ? One application I thought of is for deploying to client. You just get them to use the instance and there's zero configuration needed. but then, what if you need to make updates to the code base, how do you update the code changes to all the deployed fig/docker instances running already?

Ideally you run a new build and test it before deploying. If you wanted to you could include a gift pull in your startup script or run the pull over ssh in the container although you would need a trick to load the environment cars passed by docker.

Re: Fig: Fast, isolated development environments using Docker

#25
post #23
post #21

I'm not involved with this project but there is some confusions in this thread, maybe I can share my point of view: Docker is a tool to run processes with some isolation and, that's the big selling point, nicely packaged with "all" their dependencies as images. To understand "all" their dependencies, think C dependencies for e.g. a Python or Ruby app. That's not the kind of dependencies e.g. virtualenv can solve prop…

You can package all of your apps dependencies in one image and have a script in the container start them.

Yes you can but I don't think that's the philosophy behind Docker.

To expand on the "dependencies" idea of my previous post, although you technically can put a process supervisor, a web server, an application server, and a database in the same container, this is not the best practice. It makes your app simpler to distribute (a single image, no orchestration) but harder to evolve (e.g. move the database to its own physical server, or replicate it and put them behind a connection pooler).

For instance if you have a tool to manage a cluster of containers, you will be able to manage the different processes/containers logs in a repeatable way.

But sure, if you know you don't need the added flexibility, you can put everything you want in the same image.

Re: Fig: Fast, isolated development environments using Docker

#27
post #21

I'm not involved with this project but there is some confusions in this thread, maybe I can share my point of view: Docker is a tool to run processes with some isolation and, that's the big selling point, nicely packaged with "all" their dependencies as images. To understand "all" their dependencies, think C dependencies for e.g. a Python or Ruby app. That's not the kind of dependencies e.g. virtualenv can solve prop…

So, simulate a cluster of machines instead of a single machine? Seems like a good thing. "Tiny datacenter in a box."

The question whether it's close enough to production to be useful; any testing environment simulates some things well and others poorly. Load testing would be right out, I'd presume, but it might be useful for testing some machine failures.

Re: Fig: Fast, isolated development environments using Docker

#28
post #22
post #15

Earlier quoted context omitted.

I don't have a ton of experience with any of them, but fig.yaml looks dramatically simpler and easier to learn than Chef or Puppet. (It also solves a much narrower problem, but I think the point remains.) What this needs is the ability to be pointed at a working VM - lets say, Ubuntu 13.10 server - and then just figure out whats different about it, compared to the distro release. It sounds like you want Blueprint ( h…

> I found this to not actually be a very useful approach in practice. Could you expand on this, please? I'm curious to know what the problems were (just so I know what I'm letting myself in for)

(Disclaimer: I haven't found any solution I really like... so the problem may be me.)

It turns out that installing and configuring services on a server touches many files and only some of them are important. Even the basic assumption that Ubuntu is the same everywhere wasn't quite right. Linode has some of its own packages installed and I think they tweaked the kernel. Running it in VMWare, you probably have the guest additions installed, etc. These things aren't important, but Blueprint doesn't know that. So I ended up with this massive number of changed files and the tooling for filtering through them to get just the important bits wasn't so hot (or at least it wasn't a year ago).

Re: Fig: Fast, isolated development environments using Docker

#29
Looks interesting. I know that Docker is all about the single process model, but there's are some images I've been meaning to play with that align themselves more with the single app (including dependencies) model (which fig also seems to attempt to solve).

https://github.com/phusion/baseimage-docker

https://github.com/phusion/passenger-docker

Re: Fig: Fast, isolated development environments using Docker

#30
post #21

I'm not involved with this project but there is some confusions in this thread, maybe I can share my point of view: Docker is a tool to run processes with some isolation and, that's the big selling point, nicely packaged with "all" their dependencies as images. To understand "all" their dependencies, think C dependencies for e.g. a Python or Ruby app. That's not the kind of dependencies e.g. virtualenv can solve prop…

So, simulate a cluster of machines instead of a single machine? Seems like a good thing. "Tiny datacenter in a box." The question whether it's close enough to production to be useful; any testing environment simulates some things well and others poorly. Load testing would be right out, I'd presume, but it might be useful for testing some machine failures.

"Tiny datacenter in a box."

That's been built into [Open]Solaris for years. You can define the network topology too.

Post reply on HN