Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fig: Fast, isolated development environments using Docker

orchardup.github.io

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Fig: Fast, isolated development environments using Docker

#31

Post by _delirium »

erichocean wrote: post #30
skybrian wrote: post #27

Earlier quoted context omitted.

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.

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/write files (or all of the above). Super-handy for running untrusted code as a stdin->stdout filter without worrying about it causing other mischief, and not having to encapsulate it in a zone/jail/container just to run one process.

FreeBSD's 'capsicum' [1] also looks promising at the OS API level as a similar initiative to write code with minimal privileges, but afaict you can't use it on the command line to run unmodified code with restricted privileges, at least not yet.

[1] http://www.cl.cam.ac.uk/research/security/capsicum/

Re: Fig: Fast, isolated development environments using Docker

#33

Post by frozenport »

How does Docker handle ABI incompatibility?

For example, EC2 disabled some of there extended instruction sets to ensue uniformity but I am not sure how long this will last. Then we will have to deal with Docker deployment problems.

I propose we dig deep into our Gentoo roots and build the dependencies on demand.

Re: Fig: Fast, isolated development environments using Docker

#34

Post by jetblackio »

thu wrote: 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…

Great explanation, thanks for posting. It cleared up a few things for me.

Re: Fig: Fast, isolated development environments using Docker

#35

Post by amgadhs »

thu wrote: 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…

Thank you that was very helpful.

Re: Fig: Fast, isolated development environments using Docker

#36

Post by Intermernet »

jfroma wrote: post #17
jcurbo wrote: post #10

Earlier quoted context omitted.

When I first looked at the Dockerfile format, my thought was, hey, another provisioning file format to learn. I guess you could just call chef/puppet/ansible/etc in your Dockerfile and call it a day though? I have not heavily used any of these tools so my perception of their overlap might be off.

I've tried this and it is not that easy, docker containers are meant to run one and only one process. So, for instance my puppet started an upstart job, and this crashes the docker build process. I'm a docker newbie, though.

The Dockerfile shouldn't run any processes that need to persist between 2 stages as each stage will be created in a new instance. You can either do fancy one-liner bash scripts (my favorite) to configure simple service / app startup scripts, or include a configuration file from elsewhere using the `ADD` directive. The only non ephemeral command should be the final `CMD` or `ENTRYPOINT` as far as I can work out.

I too am just learning this stuff, but that should hopefully help you out!

Re: Fig: Fast, isolated development environments using Docker

#38

Post by tinco »

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 operating system (ubuntu in this case).

This enables for example in-container build scripts and monitoring.

Re: Fig: Fast, isolated development environments using Docker

#39

Post by justincormack »

_delirium wrote: post #31
erichocean wrote: post #30

Earlier quoted context omitted.

"Tiny datacenter in a box." That's been built into [Open]Solaris for years. You can define the network topology too.

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.

Re: Fig: Fast, isolated development environments using Docker

#40

Post by gizzlon »

thu wrote: post #25
ilaksh wrote: post #23

Earlier quoted context omitted.

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 phy…

There are several use-cases for docker, and they could use different docker images and containers. Right now there's no easy way to distinguish all-in-one image from one-process images.

Seems like the "docker way" is the one-process-image. But one use-case that I find entertaining is to use docker as an super simple way of trying out software. For example I ran Wordpress for 10 minutes just to check it out. In that case it makes sense to have everything in one container as it makes it much easier to run. But in production it might not be a good idea, especially if the app is not totally self contained.

Post reply on HN