111–120 of 152 posts
Earlier quoted context omitted.
Thanks. I'm a fan of automation but respectfully disagree with this (see my response above for details).
Perfectly valid. This particular tip certainly seems to have caused some great discussion! It worked for my particular case, but I can definitely see it not working for everyone. I've added a link to this thread to my tip, and expanded on it a little to warn people that it's not for everyone.
i'm a devops noob. what tools should i use to log / monitor all my servers? i don't want to learn some complex stuff like cheff/puppet btw.... anything SIMPLE?
Though I haven't tried it, people tell me that ansible is pretty simple - http://www.ansible.com/home For logging, try logstash? http://logstash.net/ Monitoring... well that's a large and complicated topic!
Lots of very useful tips there! There's one that I think could be improved on a little: Uploads should go direct to S3 (don't store on local filesystem and have another process move to S3 for example). You could even use a temporary URL[0,1] and have the user upload directly to S3! [0]: http://stackoverflow.com/questions/10044151/how-to-generate-... [1]: http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlU...
Good article, but I think it touches too little about persistence. The trade-off of EBS vs ephemeral storage, for example, is not mentioned at all. Getting your application server up and running is the easiest part in operation, whether you do it by hand via SSH, or automate and autoscale everything with ansible/chef/puppet/salt/whatever. Persistence is the hard part.
Good point. We're struggling to see the benefits of EBS for Cassandra that has its own replication strategy (ie data is not lost if an instance is lost), voiding the "only store temporary data on ephemeral stores" argument.
"EBS volumes are not recommended for Cassandra data volumes."
http://www.datastax.com/docs/1.1/cluster_architecture/cluste...
As an Australian developer, using an EC2 instance seems to be the cheapest option if you want a server based in this country. Anyone got any other recommendations?
Earlier quoted context omitted.
Good point. We're struggling to see the benefits of EBS for Cassandra that has its own replication strategy (ie data is not lost if an instance is lost), voiding the "only store temporary data on ephemeral stores" argument.
How do you handle entire datacenter outages with ephemeral only setup? You can replicate to another datacenter, but if power is lost to both do you just accept that you'll have to restore from a snapshotted backup?
Using this type of setup, we had 100% availability for our customers over a period of 2 years (up until a couple of weeks ago where the flash 12 upgrade caused a small amount of our customers to be impacted). This includes the large outage in US East 1 from the electrical storm, as well as several other EBS related outages. Overall costs are cheaper than setting up our own geo-diverse set of datacenters (or racks in datacenters) thanks to heavy use of reserved instances. We keep looking at the costs and as soon as it makes sense, we'll switch over, but will still use several of the features of AWS (peak load growth, RDS, Route 53).
The short answer is to design your entire system so that any component can randomly be shot in the face, from a single server to the eastern seaboard falling into the ocean to the United States immediately going the way of Mad Max. Design failure into the system and you get to sleep at night a lot more.
As an Australian developer, using an EC2 instance seems to be the cheapest option if you want a server based in this country. Anyone got any other recommendations?
Ninefold aren't bad either
Earlier quoted context omitted.
Just disabling inbound SSH connections, the servers can still SSH out to other systems to pull in files, configurations, clone git repos, etc. It's just a way to stop yourself from cheating and SSHing in just to fix that one thing, instead of automating it.
except that some automation frameworks rely on inbound ssh access to the machines. ansible would be an example of such a framework, in its default configuration at least.
The goal of the tip is really to stop users SSHing in just to fix that one little thing, so you could still allow your automation frameworks SSH access and just disable it for users.
Can anyone explain how disabling ssh has anything to do with automation? We automate all our deployments through ssh and I was not aware of another way of doing.
I believe the idea is that by preventing SSH the temptation to just pop in and tweak something manually isn't possible.
The idea is that if a user can't SSH in (at least not without modifying the firewall rules to allow it again), it will force them to try and automate what they were going to do instead. It worked well for me, but it's probably not for everyone.