Recently I've started seeing some instances with the metadata key http://169.254.169.254/latest/meta-data/events/maintenance/ but most of the instances I manage do not have this key. I believe it's new but I have no proof either way.
Anyone have more info about this?
I hit this issue as well, SaltStack is affected by this (while building grains).
The endpoint previously was available only when a maintenance was scheduled.
I was able to confirm through support that this URI is now always available. Support was not sure if this was intentional or a bug. But this affects us-east-1 (for some use cases like mine with Salt) for now and will possibly affect other regions in future if they decide to roll it out.
Related
I am trying to shift from environment files in Chef to using Policyfiles. https://docs.chef.io/policy.html. I really like the concept, especially since you can include a policy from policy into another, but I am trying to understand how do a simple attribute change.
For instance, if I want to change a globally-used attribute that may be an error message for a problem that is happening now. ("The system will be down for 10 minutes. Thanks for your patience"). Or perhaps I want to turn off some AB testing with an attribute working as a flag. From what I can tell, the only way I can do this is to change an attribute in the policyfile, and then I need to create a new version of the policy file.
And if the policyfile is an included in many other policyfiles, like in the case of a base policyfile, then I have a lot of work to do for a simple change.
default['production']['maintenance_message'] = 'We will be down for the next 15 minutes!'
default['production']['start_new_feature'] = true
How do I make a simple change to an attribute that affects an entire policy group? Is there a simple way to change an attribute, or do I have to move all my environment properties to a data bag??
OK, I used Chef Support and got an answer: Nope.
This is their response:
"You've called out one of the main reasons we recommend that people use something like Jenkins pipelines to deliver cookbooks to their infrastructure. All that work can be kicked off by a build system recognizing a change in a dependency and initiating new builds for all the downstream consumer jobs.
For what it's worth, I don't really like putting application configurations like that maintenance message example you used in configuration management, I think something like Habitat is a better system for that kind of rapid-change configuration delivery, although you could also go down the route of storing application configuration like that in a system like Hashicorp Vault, Consul, or etcd, and ensuring that whatever apps need to ingest those changes are able to do so without configuration management fighting with the key-value config store.
If that was just an example to illustrate things, ignore the previous comment and refer only to my recommendation to use pipelines to deliver cookbooks, attributes, etc to your infrastructure (and I would generally recommend against data bags these days, but that's mostly a preference thing)."
I'm working on large scale enterprise application hosted in azure. Security is top priority and have been asked to secure only handful of pages.
I'm aware that there's a biding element in configuration where we can specify https/http. But, haven't found any thing where we can bind https only to number of selected pages.
Please confirm, if above is possible and if yes how would be much appreciated.
I know it can be done, not sure how though... However, I half heartedly participated in a discussion last week regarding this very issue. The people working on it declared there is no performance loss setting it up for the entire site(something about 1/100 of a second load time the first pageload then no difference). The cost of the work to set it up is higher than buying better machines to evaporate this performance loss.
Don't forget that if you use Azure Web Roles, you own the VM. So, you can use a start-up task that configures IIS however you'd like it.
So, if you already have an on-premise solution that you like and simply want to know how to use that in Windows Azure... then the answer is - launch that process from a start-up task and it will work the same way.
Here's an article on MSDN: Define Startup Tasks for a Role
We have some 20 or so servers in EC2, most are dynamically spawned (scaling groups).
We're looking for a solution to monitor the uptime of our application.
As an added bonus this solution could also extend to actually monitoring the servers involved so its easy to go back in time and see what happened just before a downtime or whatnot.
We're looking for a hosted solution ideally, and it should be easy to scale with it (it needs to somehow dynamically deal with servers being added/removed with no interaction from us).
Anyways, hoping for some recommendations from you guys.
A bit of background ...
We're currently using a custom Nagios setup, its been reduced to basically doing a simple http check now that the servers have become fully dynamic. We've already been using PagerDuty to deliver the pages. It does ok, but for the maintenance cost we could well be using a http check # Server Density of Pingdom.
I've looked briefly at ServerDensity, and it does look promising, I especially like their install mechanism of just dumping their files into your AMI and it takes care of the rest.
I'd like to know what options there are tho before diving deeper into any particular solution.
We use a combination of Server Density for monitoring and PagerDuty for alerting. The two work quite well together.
I'm starting to use EC2 with a lot of SPOT instances (>100), I'm trying to find a way to retrieve all my IC2 instances private ip's in order to use them later to deploy binaries and so on.
Can anyone help me to do it?
Thanks in advance.
Since you didn't list a framework or language:
Use the AWS Console.
Use ElasticFox.
Use the commandline tools.
Use the .NET SDK.
Use the Java SDK.
Amazon will start and stop spot instances without your involvement but based on your spot instance request parameters. Because of this, the list of spot instance IP addresses you query at time A might not be accurate at time B.
Problem 1: You think IP address A is one of your spot instances, but in the interim Amazon has terminated your spot instance and started somebody else's instance using the same private IP address. You'll want to make sure that an instance you are contacting is really yours before you pass it anything sensitive or trust any answers it gives you.
Problem 2: In the time since you got the query results, Amazon has started new spot instances for you based on the spot price. When you go to "deploy binaries and so on" you could miss some of the instances leaving them in unstable or out-of-date states.
You might consider having the spot instances configure and update themselves when they start up, and perhaps on regular intervals.
I'm just started out with Ehcache, and it seems pretty good so far. I'm using it in a simplistic fashion to speed up reads against a database, but I wonder whether I can also use it to let the application stay up if the database is unavailable for short periods. (Update - my context is a application with high-availability modules that only read from the database)
It seems like I could do that by disabling expiry in the event of a database read problem, and re-enabling it when a read works again.
What do you think? Is that a reasonable approach or have I missed something? If it's a fair approach, any tips for how best to implement appreciated.
Update - ehcache supports a dynamically configurable option to un/set the cache to 'eternal'. This seems to do what I need.
Interesting question - usually, the answer would be "it depends".
Firstly, if you have database reliability problems, I'd invest time and energy in fixing them, rather than applying a bandaid solution.
Secondly, most applications need both reading and writing to work - it doesn't seem to make sense to keep your app up for reads only.
However, if your app has a genuine "read only" function, and there's a known and controlled reason for database down time (e.g. backups), then yes, you can use your cache to keep the application up and running while the database is down. I would do this by extending the cache periods, rather than trying to code specific edge cases. For instance, you might have a background process which checks whether the database is available and swaps in a different configuration file when there's trouble.