Fig: Fast, isolated development environments using Docker • Hacker News Board

Re: Fig: Fast, isolated development environments using Docker

#41

Post by airnomad » Tue, Jan 28, 2014, 11:05 AM UTC

I just spent few days dockerize my development enviroment and now Im able to recreate complete enviroment in one command - It took less then 100 lines of bash and dockerfiles.

So I put those files in VCS so the next guy could just clone the repo, run make devel and get the app running, ready to code on.

So unless you want to use Docker at deployment, dont split app in multiple containers - you got more running parts to integrate and no gain, instead use supervisord and run all processes in single container.

Theres few hacky parts (how to inject ssh keys into container) but so far its really cool.

I too wrote few wrapper scripts around lxc-attach so i can run ./build/container/command.sh tail -n 20 -f /path/to/log/somewhere/on/container

I cant share any code but im happy to answer questions at [HNusername]@gmail.com

Re: Fig: Fast, isolated development environments using Docker

#42

Post by aidos » Tue, Jan 28, 2014, 11:38 AM UTC

tinco wrote: post #38

aidos wrote: post #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

Hi, I work at Phusion, the idea of these images is not to run both your app and your database in the same container. We agree that the Docker philosophy would be to run those in separate containers, and link them. The idea is to make sure your app runs in an environment that's actually a fully functioning valid operating system. This means besides your apps process there's also the supporting processes of the operati…

Good to know the use case, thanks. I would still have run the db in a different docker container. Just nice to have a bit more of the os available to your process.

I haven't actually deployed anything with docker yet, just used it on my local machine (so I could run neo4j in isolation). It's a slightly different way of thinking from how we've traditionally managed these things so it's going to take a little time to find the best patterns to work with them. I'm sure some people have already figure it out - I just haven't had the time to dedicate to it yet.

Re: Fig: Fast, isolated development environments using Docker

#43

Post by _delirium » Tue, Jan 28, 2014, 12:09 PM UTC

justincormack wrote: post #39

_delirium wrote: post #31

Earlier quoted context omitted.

I've only recently been playing around with Solaris derivatives, and am pretty impressed at how far it is with some of this stuff. My recent favorite is discovering 'ppriv', which lets you drop processes' privileges on a process-by-process basis without even starting up a new container/zone to encapsulate them. E.g. you can run a process with no network access or with no ability to fork, or with no ability to read/wr…

Writing a command line wrapper should be relatively simple for capsicum. Designing the interface might need some work. I think the idea mainly has been to get code to sandbox itself but I can see a use case.

Yeah, for the base system that approach makes sense to me (build privilege-dropping into the code), but sometimes I just want to sandbox an existing binary. One recent example where it's come up is a student AI competition, where their submissions aren't supposed to do anything but read/write stdin/stdout, and it'd be nice to be able to enforce that externally by just lowering the process's privileges.

Re: Fig: Fast, isolated development environments using Docker

#44

Post by ewindisch » Tue, Jan 28, 2014, 5:34 PM UTC

I'm an employee of Docker, Inc. although my thoughts are my own, etc...

I must say that this is great. I've been advocating this sort of usage of Docker for a while as most still think of Docker or containers as individual units. I'm happy to see others adopting the viewpoint of using container groups.

However, it is something I do hope to eventually see supported within Docker itself.

Also, recently, I've been telling others how since October you could do this exact same thing using OpenStack Heat. Using Heat and Docker is similar to Fig, the configuration syntax is quite similar even, but it requires the heavy Heat service and an OpenStack cloud. That means that for most people, it isn't even an option. It's great that Fig now provides a solid lightweight alternative.

As 'thu' has said already, people want and need these features quickly and I expect in the next year we'll see serious interest growing around using these solutions and solving these problems.

Re: Fig: Fast, isolated development environments using Docker

#45

Post by mmcdaris » Fri, Jan 31, 2014, 8:31 PM UTC

bfirsh wrote: post #20

bryanlarsen wrote: post #11

Is this meant to be a next-generation Vagrant? What advantages does it have over vagrant-lxc?

A few things: - System configuration is managed for you using Docker (you don't need to figure out how to hook up Puppet/Chef/shell scripts) - You can aggregate log output from all of your containers - You can model your application as a collection of services - starting, stopping, scaling them etc - You can ship exactly the same Docker image you use in development to production More importantly, all this stuff works…

This is really cool! I am going to use it! :D