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

AWS EC2 Container Service

aws.amazon.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: AWS EC2 Container Service

#61

Post by kelleyk »

dividuum wrote: post #42
kalgen wrote: post #18

Earlier quoted context omitted.

These are also properties of Google Container Engine. Which other container service offerings were you thinking of?

Digital Ocean has something called "Private Networking" that's internal to the data center but shared with all other customers. It's not obvious from reading the website that this is the case.

Linode's is the same. I agree that it's annoying and that the terminology is slightly deceptive.

Any of these "datacenter LANs", though, tend to be fast and free (in terms of bandwidth). We just use a VPN overlay and call it a day.

Re: AWS EC2 Container Service

#62

Post by SoreGums »

estsauver wrote: post #54
dividuum wrote: post #42

Earlier quoted context omitted.

Digital Ocean has something called "Private Networking" that's internal to the data center but shared with all other customers. It's not obvious from reading the website that this is the case.

I actually think they're almost intentionally a touch deceptive. "Private" is a really loaded term to use there.

Not really, common to refer to Private IP's as "private IP address space" as per RFC 1918(IPv4)/RFC 4193(IPv6).

If a user of the service is wanting to get on board, it is their responsibility to ensure what they think is accurate or not.

Re: AWS EC2 Container Service

#63

Post by eldavido »

arohner wrote: post #52
Animats wrote: post #43

"All problems in computer science can be solved by another level of indirection" - David Wheeler That's what "containers" are, of course. There's so much state in OS file namespaces that running any complex program requires "installation" first. That's such a mess that virtual machines were created to allow a custom OS environment for a program. Then that turned into a mess, with, for example, a large number of canne…

IMO, the problem is that your standard OS has way too much stuff running. A SaaS app running in production should be about the size of your binary, and the libraries it uses. Instead, we have X, smtp, terminals and a full filesystem running. home directories and uids make no sense in an app that uses no unix users except for the one you're forced to use. I'd really like to see a much smaller, simpler, non-posix OS fo…

This doesn't really pencil out..."your binary, and the libraries it uses" can easily get into the GB when you include components like the .NET framework or java base class library. I don't know exactly how large a fully-loaded NPM repo with warm cache or warmed-up rvm installation directory are, but it isn't tiny.

Second, POSIX is a standard for how the operating system API works that has nothing to do with what packages are installed -- and it's a pretty low-level API, for doing stuff like read, write, fork, exec, etc. This isn't what's adding bloat.

Re: AWS EC2 Container Service

#64

Post by 23david »

shykes wrote: post #39
23david wrote: post #35

Earlier quoted context omitted.

> it's an objective fact that canonical decided to reimplement > what Docker does rather than contribute to it. What was the reason that Docker reimplemented much of LXC rather than contribute patches upstream? Latest LXC supports features that Docker's reimplementation doesn't, and it seems likely to get further ahead feature-wise now that Ubuntu is pouring more resources into LXC/LXD.

You forgot to quote the part where I said "I won't comment on whether it's good or bad". Canonical doesn't need to justify itself to me, no more than the Docker maintainers need to justify themselves to you. It's just how open-source works: you weigh the pros and cons of re-using vs re-implementing, make a decision, and see if the community follows you. In the case of Docker, the community followed. In the case of lx…

Happened to find the pull request discussing the lxc-driver issue. It sounds like there was some interest in contributing upstream, but it didn't really go anywhere.

  https://github.com/docker/docker/pull/5797
From the thread, it seems like the concern was just that lxc-exec wasn't well maintained and the lxc interfaces weren't stable since it was undergoing heavy development. I think that's changed recently with both lxc and docker now post 1.0 release and 'production-ready'.

Docker still uses LXC if you want it to via the lxc-exec driver and the --lxc-conf option. It's just not the default, which probably makes sense since the lxc options mainly apply for advanced users.

So by default, Docker uses libcontainer for a simpler installation experience. But for advanced users, using the lxc driver is an option to look into.

IMO, Docker wins if it continues to play nicely with the other open-source projects people use with Docker, and also give credit where due.

Re: AWS EC2 Container Service

#65

Post by inopinatus »

estsauver wrote: post #54
dividuum wrote: post #42

Earlier quoted context omitted.

Digital Ocean has something called "Private Networking" that's internal to the data center but shared with all other customers. It's not obvious from reading the website that this is the case.

I actually think they're almost intentionally a touch deceptive. "Private" is a really loaded term to use there.

When a door is marked "Private", then the room beyond is generally a shared space for all those authorized to access.

Re: AWS EC2 Container Service

#66

Post by joshpadnick »

St-Clock wrote: post #7

Security-wise, if I understand correctly, this is a very interesting offering. 1. The containers live on "your" VMs so you get the isolation of a virtual machine and do not worry about the other tenants' containers. 2. The VMs are part of a "private cloud", i.e., the internal network is not accessible by other tenants' VMs and containers. #2 is what worried me the most in other container service offerings. It's easy…

I'm here at AWS reinvent and just saw the EC2 Container Service presentation. They specifically targeted security as part of their design.

Basically, you launch a cluster of EC2 instances that are "available" for containers to launch into. So these are your instances, running in your VPCs. It's really the same security profile as the standard VPCs plus any other security issues your particular docker containers expose.

Re: AWS EC2 Container Service

#67

Post by joshpadnick »

incision wrote: post #14

I'm disappointed that this requires an invite, particularly so close after Container Engine which I was able to try out immediately while still watching Cloud Platform Live the other day. Is this typical for new AWS offerings? It makes me wonder if it's something that truly isn't ready for prime time, but is being rushed / forced by the mounting Docker hype and GKE announcement.

According to one of the AWS devs, they plan to start honoring invite requests in about 2 - 4 weeks. It appears to be in preview right now mostly b/c the loose ends aren't tied up yet. For example, in their demo today, they launched EC2 instances in a cluster using an AMI that's specially enabled for the EC2 Container Service but which is not yet publicly available.

Re: AWS EC2 Container Service

#69

Post by beat »

Docker in general is just another swing of the granularity pendulum. Since the rise of distributed environments in the late 1980s, the pendulum has swung back and forth between microservices (which become a version control tangle as they move independently) and monolithic applications (which become a bloatware problem as they have whole kitchen sinks to move around). The core problem is that software is complex, and at a certain level, you can't take complexity away - just push it around here and there. A large number of small pieces, or a small number of large pieces. Which kneecap do you want shot in?

After a few years of trending toward monoliths via chef/puppet/ansible DevOps automation, Docker is going in a different direction, toward fragmented SOA. It'll go that way for a while until it becomes too painful, and then new tech will come to push us back to the monolithic approach, until that hurts too much...

The good thing is, these cycles come in response to improvements in technology and performance. Our tools get better all the time, and configuration management struggles to keep up. It's awesome! Docker will rule for a while and then be passed by in favor of something new, but it'll leave a permanent mark, just as Chef did, and Maven, and Subversion, and Ant, and Make, and CVS, and every other game-changer.

Re: AWS EC2 Container Service

#70

Post by jobposter1234 »

eldavido wrote: post #46
Animats wrote: post #43

"All problems in computer science can be solved by another level of indirection" - David Wheeler That's what "containers" are, of course. There's so much state in OS file namespaces that running any complex program requires "installation" first. That's such a mess that virtual machines were created to allow a custom OS environment for a program. Then that turned into a mess, with, for example, a large number of canne…

It's more like a ping-pong. Things start off simply, but over time as the layers of abstraction pile up, things become brittle and unworkable. I view containers as more of a reworking of a key computational abstraction (VMs) than an evolution of them. We finally have operating systems with enough inter-process isolation, sufficiently capable filesystems (layering), etc. that we can throw out 80% of the other unnecess…

I'm genuinely curious, although a bit naive WRT containers. Outside of an aesthetic preference (for being able to remove 80% unnecessary cruft), what is the advantage of containers? I was under the impression that VM overhead was marginal in terms of today's computing.

I ask because I'm familiar with VMs, having worked with them extensively for a number of years. VMs work quite well for any application I've needed, so what would be the benefit of switching to containers? I've got lots to do, and lots to learn, but I can't see learning containers (and being out of sync with the rest of my coworkers) being a priority.

But I'm willing to change my mind if there's a concrete benefit. Right now, VMs work just fine, but maybe there's something I'm missing...

Post reply on HN