Whats the Terraform API to add a route53 record to every instance provisioned by Auto-scaling ?
I also need to destroy the A record once instance is terminated.
My code deployment scripts make use of DNS name.
When autoscaling is in use, Terraform controls the overall autoscaling process but does not manage the instances produced by the auto-scaling system. Any actions that need to be taken as a result of instances being created and destroyed must therefore be triggered by auto-scaling itself, rather than by Terraform.
The Auto Scaling Lifecycle Hooks provide a way to trigger actions in response to changes in the statuses of instances in an autoscaling group.
In principle one could use auto-scaling lifecycle hooks to trigger running Terraform, but automatic, unattended Terraform runs are not a common usage and so there are currently no built-in mechanisms to make this work. A wrapper script of some kind would need to be written to orchestrate Terraform and deal with any errors that occur when running it.
Thanks Martin.
Used Lambda and boto3 with Events in Cloudwatch to get around with this one.
Passed a Tag 'cname' while starting instances via ASG.
Insert and Upsert was fine.
Delete was bit tricky as the Terminating Instance does not retain IP.
To delete, queried Route53 table using the CNAME while creating instances.
And then ran a delete using boto3 on Route53 with IP as the 'Value'
Thanks.
Related
I would like to tweak some settings in AKS node group with something like userdata in AWS. Is it possible to do in AKS?
how abt using
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/virtual_machine_scale_set_extension
The underlying Virtual Machine Scale Set (VMSS) is an implementation detail, and one that you do not get to adjust outside of SKU and disk choice. Just like you cannot pick the image that goes on the VMSS; you also cannot use VM Extensions on that scale set, without being out of support. Any direct manipulation of those VMSSs (from an Azure resource provider perspective) behind your nodepools puts you out of support. The only supported affordance to perform host (node)-level actions is via deploying your custom script work in a DaemonSet to the cluster. This is fully supported, and will give you the ability to run (almost) anything you need at the host level. Examples being installing/executing custom security agents, FIM solutions, anti-virus.
From the support FAQ:
Any modification done directly to the agent nodes using any of the IaaS APIs renders the cluster unsupportable. Any modification done to the agent nodes must be done using kubernetes-native mechanisms such as Daemon Sets.
I have a Terraform file that creates a resource group, storage account, storage shares, database and VMs on Azure. My proposed use case is that in production once the resource group, storage account, storage shares and database are created database, they should stay in place. However, there are cases where the VMs may need to be destroyed and re-created with different specs. I know that I can run the file once to create everything and then taint the VMs and re-create them with an apply, but that doesn't seem like the ideal method.
In regular use, changes to infrastructure should be made by changes to configuration, rather than by running imperative commands like terraform taint. If you change something about the configuration of a VM that requires it to be created then the underlying provider should produce a plan to replace that object automatically, leaving others unchanged.
When you have different objects that need to change on different rhythms -- particularly when some of them are stateful objects like databases -- a good way to model this in Terraform is to decompose the problem into multiple separate Terraform configurations. You can use data sources in one configuration to retrieve information about objects created in another.
Splitting into at least two separate configurations means that the risk of running terraform apply on one of them can be reduced, because the scope of actions it can take is just on the objects managed in that particular configuration. Although in principle you can carefully review the Terraform plan to see when it's planning to make a change that would be harmful, splitting into multiple configurations is extra insurance that many teams use to reduce the possible impact of human error.
Not a Terraform expert here,
Is there a way to have Terraform create a node in an empty AWS Autoscale Group, wait, then create all other nodes as quickly as possible with no wait?
The situation is I have an application that uses a shared directory to store common files and is set up with a primary/secondary architecture. The only difference between primary and secondary is primary will create the required files and binaries where as all secondaries consume them. Currently the application cluster is falling down because it tries to create the entire Autoscale Group in one go, creating a race condition where each node thinks it is a primary.
Replace your single autoscaling group with two autoscaling groups, one for the primary server and the other for the secondary servers. Use a depends_on block in the second group to make it dependent on the first. With this, the second group will not start until after the first group has successfully started. You may also need to use a lifecycle hook so that the primary server can signal to Autoscaling (and then Terraform) that it has started up and completed creating those shared resources.
Assuming a cloud infrastructure across multiple cloud provider accounts (AWS, Azure and GC) built with Terraform. Is there any way to reboot instances using Terraform? If not, how do people easily and centrally reboot their instances created with Terraform?
Thanks!
Terraform does not provide capacity to reboot your instances. At best, you could taint a resource, that means that terraform will destroy and recreate (which is obviously not the same the rebooting). Terraform is not the right tool to manage the lifecycle of your instance.
Usually, the best practice is to get your instance automatically rebooted, using cloudwatch on AWS. You need to configure it to detect unhealthy instances. I guess other cloud providers have a similar feature.
If you need to do it manually, next step would be to use the cloud API (such as aws cli) to perform this action. I am not aware of a tool that let you do that across cloud providers centrally.
What is the difference between updating an deployment and deleting and then creating a new deployment for a cloud service ?
We have a cloud service set up which during deployment, first deletes the existing deployment in staging and then creates a new deployment. Due to this the VIP for staging is always changing. We have a requirement where we want to make sure that both the PROD and Staging VIP always remains same.
Before changing the deployment option i would like to know what is the real difference and the need to have these two options.
I tried to search but found nothing on this.
EDIT: In the Azure Pub XML, we have a node named 'AzureDeploymentReplacementMethod' and the different options for this field are 'createanddelete', 'automaticupgrade' and 'blastupgrade'
Right now we are using 'createanddelete' and we are interested to use blastupgrade.
Any help would be much appreciated.
THanks,
Javed
When you use Create&Delete deployment the process simply deletes an existing deployment, then creates new one.
The other two options do upgrade deployment. The difference between automaticupdate and blastupgrade are in the value of Mode element of the Upgrade Deployment operation. As their name suggests, automaticupdate sends Auto for that element. While blastupdate would send Simultaneous. As per documentation:
Mode Required. Specifies the type of update to initiate. Role instances are allocated to update domains when the service is
deployed. Updates can be initiated manually in each update domain or
initiated automatically in all update domains. Possible values are:
Auto
Manual
Simultaneous
If not specified, the default
value is Auto. If set to Manual, WalkUpgradeDomain must be called to
apply the update. If set to Auto, the update is automatically applied
to each update domain in sequence. The Simultaneous setting is only
available in version 2012-12-01 or higher.
You can read more on Update Cloud Service here.
Although, if you really want to persist VIP in all situations, I would suggest you to:
Do not use staging for cloud services at all - just use two separate cloud services (one for production and one for staging)
use the Reserved IP Address feature of the Azure Platform.