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

Docker 0.8: Quality, new builder features, btrfs, OSX support

blog.docker.io

Post reply on HN
Print view View original

101–110 of 128 posts

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#101

Post by comex »

shykes wrote: post #97
_wmd wrote: post #89

Earlier quoted context omitted.

Look, I'm really glad that you're excited for docker, but name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave. In fact I've really no idea what purpose your reply was hoping to serve. In the default configuration (and according to all docs I've seen), regardless of some imagined rosy future, today docker is a wrapper around Linux containers, a…

> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering…

> But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine.

> In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment.

If I understand services like Heroku correctly, they give customers standard access to run arbitrary code inside a container as a standard user. Therefore, I expect it would be standard and unavoidable to have many different customers' applications running on the same machine, leading to the ability to exploit vulnerabilities similar to the recent x32 one. If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available.

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#102

Post by bstar77 »

hootener wrote: post #43
shykes wrote: post #4

Earlier quoted context omitted.

Hi Matt, you are not alone :) It turns out that shared folders are not a sustainable solution (independently of whether boot2docker supports them), so the best practices are converging towards this: 1) While developing, your dev environment (including the source code and method for fetching it) should live in a container. This container could be as simple as a shell box with git and ssh installed, where you keep a te…

"- It's less infrastructure-specific...." - "a very common problem with shared folders is "oops the container creates files as root but I don't have root on my mac", or "apache complains that the permissions are all wrong because virtualbox shared folders threw up on me"." Thank you for taking the time to write this, just to emphasize these two pain points. I've been using Docker since 0.5 and my current setup is sti…

I configure my local containers to my ($5/month) quay.io account to address the problem you are describing. If all of your containers start with quay.io/name then you don't have to worry about exposing your docker images.

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#103

Post by jamtur01 »

smtddr wrote: post #88
newman314 wrote: post #79

IMO, it would be fantastic if there was something like Docker for Windows. Imagine being able to bundle up games in individual containers and easily being able to move them from machine to machine as you upgrade. Same thing applies for other Windows apps.

The developers of DRM for Windows games would probably make sure that doesn't work.

Not if it's an option for installation. Or if they start shipping them like that. Steam springs to mind. :)

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#105

Post by FooBarWidget »

mwcampbell wrote: post #92
shykes wrote: post #83

Earlier quoted context omitted.

Our priority in the short term is definitely to focus on the Linux ABI and making it available on as many physical machines as possible. This is the reasoning behind our current OSX support, and support for more platforms coming soon. Longer term we do need to support multiple ABIs, if only because a lot of people want to use Docker on x86-32 and ARM. Having ELF binaries built on Linux isn't of much help if they're b…

Your reply primarily addresses architecture support and the implications for pre-built payloads. But I think a more important concern is the fragmentation that would result if Docker attempted to natively support other operating systems. Consider that practically every Dockerfile starts with a Linux distro, and includes commands specific to that distro (e.g. installing packages with apt). Everybody assumes that the p…

I think what he's saying is that although Docker will support other Linux ABIs, it will stay with Linux.

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#106

Post by 72deluxe »

pekk wrote: post #41
darkarmani wrote: post #30

Earlier quoted context omitted.

Are you sure it isn't caused by the mid-2010 macbook video card bug? I had it re-exposed when i upgraded past 10.6 and that laptop now reboots 8 times a day. Mostly from mac mail or when the power drops and it shifts video cards.

and I'm always told that macs are superior because they "just work," hmm

That's marketing. They have the same number of problems as all other OSes and computers. I have found a higher percentage of Windows users to know where to look for system messages compared to the number of Mac users who know how to look for system messages. Perhaps it is because I have met more Windows users or perhaps they need to look these things up more...? But in any case, you meet more "hardcore" Windows users who know their way around compared to Mac users, perhaps because the end-user expectation of a Mac user is that it "just works" so doesn't need to poke around as much.

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#107

Post by _wmd »

shykes wrote: post #97
_wmd wrote: post #89

Earlier quoted context omitted.

Look, I'm really glad that you're excited for docker, but name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave. In fact I've really no idea what purpose your reply was hoping to serve. In the default configuration (and according to all docs I've seen), regardless of some imagined rosy future, today docker is a wrapper around Linux containers, a…

> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering…

You keep saying I'm wrong, because in future docker/containers might work in a different way to how they work today, and will be used in a way entirely different to how people use them today (and utterly contrary to how docker has been marketed to date).

AFAICT through the wall of text, the only problem you have with what I said is that Docker loses its value when combined with a VM. That's fair enough, but that was 1% of my comment.

If you're replying, please don't quote yet another wall of text, it's almost impossible to read.

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#108

Post by nl »

comex wrote: post #101
shykes wrote: post #97

Earlier quoted context omitted.

> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering…

> But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine. > In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your origin…

>> In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment.

>If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available.

The parent is suggesting you can use Docker as a supplement to any additional security measure one might choose (to quote: "Docker is commonly used in combination of VMs for security, so at least some people find it useful").

In your example, a person would run Docker on top of the VM, and gain "a system for managing and distributing repeatable execution environments".

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#109

Post by 1stop »

_wmd wrote: post #107
shykes wrote: post #97

Earlier quoted context omitted.

> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering…

You keep saying I'm wrong, because in future docker/containers might work in a different way to how they work today, and will be used in a way entirely different to how people use them today (and utterly contrary to how docker has been marketed to date). AFAICT through the wall of text, the only problem you have with what I said is that Docker loses its value when combined with a VM. That's fair enough, but that was…

I think the problem the parent has with you're statement is you are saying "Docker is a crap security alternative"... but docker isn't marketed as a security solution, it's a "logical" process isolation.

It solves the "I want to run two apache's how do I stop them conflicting" problem. Not the "I don't trust what is being run here" problem, it has never been marketed as that, and you are presenting it as if it was.

Docker is a great way to build up a machine, and logically define a machines capabilities.

Your gripe about security is just completely irrelevant, it'd be like complaining that iPhoto doesn't increase OS X Security.

Edit: So the answer to the original "Is docker good for security?" I would say "maybe, but that's not its intention or focus".

Re: Docker 0.8: Quality, new builder features, btrfs, OSX support

#110

Post by [deleted] »

1stop wrote: post #109
_wmd wrote: post #107

Earlier quoted context omitted.

You keep saying I'm wrong, because in future docker/containers might work in a different way to how they work today, and will be used in a way entirely different to how people use them today (and utterly contrary to how docker has been marketed to date). AFAICT through the wall of text, the only problem you have with what I said is that Docker loses its value when combined with a VM. That's fair enough, but that was…

I think the problem the parent has with you're statement is you are saying "Docker is a crap security alternative"... but docker isn't marketed as a security solution, it's a "logical" process isolation. It solves the "I want to run two apache's how do I stop them conflicting" problem. Not the "I don't trust what is being run here" problem, it has never been marketed as that, and you are presenting it as if it was. D…

[deleted]
Post reply on HN