Under the Hood of the Amazon EC2 Container Service
allthingsdistributed.com
allthingsdistributed.com
- 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.
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.
Combined with Watchtower it's a potent container solution.
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.
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.
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.
I'll track down some Cloud Console product folks and ask if it's feasible.
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.