We've been using EC2 Container Service for a few months now and at first glance it appears great but we've ran into quite a few problems using it:
- You can only bind 1 port and 1 ELB to a service. This means, for example, if you have nginx listening on port 80 and 443 you need to manually configure the ELB and can't take advantage of automatically generated port numbers on the host (So you basically can only have 1 HTTP(s) server on a host)
- There is no way to cleanly decommission a host from a cluster. Say if you want to reboot or replace a server in the cluster you can't tell ECS to drain connections from the ELB and move the containers off the host
- Unable to specify rules for which hosts services should run on. For example you can't say that the service needs to make sure it has instances in X AZs or don't run multiple instances of the same service on the same host.
- No easy way to implement any kind of service discovery, you have to roll this yourself or set up loads of internal ELBs as a sort of service discovery.
- Worst of all the ecs-agent is very buggy. It has releases where it just keeps crashing [1] and leaving untracked running containers just hanging around to an issue where they released a new version with a newer docker library that changed how it handled certain parameters causing our entire cluster to fail until they hot fixed it with a change to how their API sent data to the client.
We're currently looking at alternatives for our docker infrastructure.
This is shameless self promotion but check out rancher.com. It's open source and allows you to spin up a container service like GKE or ECS but cloud independent.
Wow - my company is getting into the EC2-Docker idea pretty heavily at the moment (and I'm going to wind up in charge of monitoring it). This is...not great to hear.
I'm very interested in ECS's startup latency characteristics. Do you know offhand about how long it takes to provision a new container, and if this is subject to wide fluctuation?
I've not done any measurements in terms of latency but from my experience an agent on the host will ask the docker daemon to start a new container in the order of seconds after making an API request to ECS that calls for an additional container to be provisioned.
I'd recommend setting up a private registry within EC2 though, otherwise you'll have a fairly significant delay while it pulls the image from wherever and incur bandwidth charges for doing so. You'll still have some delay while it pulls the image from your registry running on EC2 but not as significant if it were externally hosted.
I've been doing a lot of playing with Google Container Engine (hosted Kubernetes) on Google Cloud, and have been very impressed so far. Can anyone who has worked with both offer some thoughts on how the two compare?
I don't know if Amazon's Container Service has substantial parts that have been open sourced, but I've been super happy with how Kubernetes is being developed in the open. It's also nice that it runs just about everywhere (in theory). It's pretty rough to set up manually right now, but I assume that will improve with time.
+1 for Google Cloud (GCE). Google is really putting in effort into the platform. Seems like they are pushing updates to the web interface often, and really improving UX/UI.
Agreed on all counts. The only thing that is frustrating is that I haven't found a great way to keep up with changes aside from manually visiting their GCE release notes page.
What would be ideal for you here? I can't guarantee anything (I'm an engineer on GCE, but not even really customer facing unless you count the PCI devices exposed to your VM), but if it's something simple like getting an e-mail with release notes as they're posted, I can suggest it up to the folks who handle those sorts of comms.
I'd say some form of alert when you login of changes that you can read more up on, link to examples or video etc beyond release notes.
Could see when last logged into and with that be able to pull changes that are new from that time and now.
That way, you have the information alerted at a point the user will not miss and from there they are aware to read up more or not if they like.
Email's are nice, but be shame not to have that information more tailored at point of interaction. That way if a user login say 6 months later they would be advised of changes since last logged in, compared to going thru how many emails that build up and end up getting filtered into some folder hardly viewed.
But the ability to view changes from a point outside the release cycle of changes allows somebody to glean what is new for them and if case of some feature tried and then withdrawn during there last login then no need for them to even read about it as moot to them. Sadly many release notes gear towards having read all the previous, even ones that later get superseded.
This also avails the ability to alert to changes when the user approaches those options and if some subset they do not use then they won't need to read upon those changes as a priority. But that is another angle of approaching how changes are communicated to a user.
RSS/Atom would be ideal for me in particular, but I'm not sure if this would be the majority's preference. An email would be just fine. Both would be superb.
This is a bit of an issue I have with GC as a whole. Some products don't even have release notes. And I have to check a bunch of different release notes pages for each service, unless something gets announced on the blog.
I really want to stay on top of this stuff, but it's pretty difficult to right now.
I've been playing with both and conceptually they're very similar. ECS is a little less sophisticated and extensible than Kubernetes, but that's by design since it only works with AWS services. For example, ECS uses ELB to abstract services whereas Kubernetes has its own service load balancer and service replication mechanism.
I'm a bit new to this, so not quite sure why you say Kuebernetes has its own load balancer. E.g. you can run Kubernetes on AWS. If you do then it uses ELB for load balancing.
So this Amazon EC2 Container Service Agent[1] is the AWS's own equivalent of Google Cloud Platform's Kubernetes? (Granted, Kubernetes is platform agnostic.)
- You can only bind 1 port and 1 ELB to a service. This means, for example, if you have nginx listening on port 80 and 443 you need to manually configure the ELB and can't take advantage of automatically generated port numbers on the host (So you basically can only have 1 HTTP(s) server on a host)
- There is no way to cleanly decommission a host from a cluster. Say if you want to reboot or replace a server in the cluster you can't tell ECS to drain connections from the ELB and move the containers off the host
- Unable to specify rules for which hosts services should run on. For example you can't say that the service needs to make sure it has instances in X AZs or don't run multiple instances of the same service on the same host.
- No easy way to implement any kind of service discovery, you have to roll this yourself or set up loads of internal ELBs as a sort of service discovery.
- Worst of all the ecs-agent is very buggy. It has releases where it just keeps crashing [1] and leaving untracked running containers just hanging around to an issue where they released a new version with a newer docker library that changed how it handled certain parameters causing our entire cluster to fail until they hot fixed it with a change to how their API sent data to the client.
We're currently looking at alternatives for our docker infrastructure.
[1]: https://github.com/aws/amazon-ecs-agent/issues/156