Ashwin Velappan:
Hi everyone,
Can someone help me to terminate the instance through script without entering the below comment??
terraform destroy apply
Ashwin Velappan:
Also please let me how to reboot using terraform script
Alistair Mackay:
You can use terrafrom apply/terraform destroy in scripts without it asking for confirmation by use of -auto-approve argument, e.g.
terraform apply -auto-approve
As for rebooting, that’s not really terraform’s job. All it does is to assert the instance is in the desired state, i.e. that it exists with the configuration as stored since the last apply.
MK:
Using Ansible as a provisioner to issue Reboot could do the job.
Cai Walkowiak:
You would usually use
terraform destroy and the confirm at the prompt with yes
As Alistair said you can avoid the prompt with auto-apply but that is really advised against - you want to review what the plan shows before destroying.
If you are looking to destroy a specific resource you can use terraform destroy -target=resourcename
Ashwin Velappan:
Hi everyone, Thanks for sharing your inputs.
@Alistair Mackay @Cai Walkowiak Yea, I’m aware about the -auto-approve option, but I’m not preferring to use those commands to reboot and terminate the instance since I’m working on terraform enterprise. so manually I’m not going enter any commands for execution. Basically it has to be on the script and that should automatically do such activities.
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ec2_instance_state
By referring the above link, we are able to stop and start the resources through script, we expect the same for termination and rebooting process. Unfortunately I couldn’t find something like that. Can you able to understand my requirements??
@MK Is there way to stop, start, reboot and terminate the instances via ansible?? for the terraform enterprise aws resources provisioning, please help me with your inputs briefly if possible
Alistair Mackay:
Started, Stopped and Terminated are all defined states which can be managed by TF. Obviously to terminate, this implies removing the aws_instance resource from the configuration. Deleting the resource when it comes to an instance is what needs to be done to terminate - the resource ceases to exist in AWS, therefore it cannot be in the TF config, or it will be recreated.
reboot is an action, not a state so it can’t be managed directly. You would have to apply instance_state stopped, followed by another apply with instance_state running to effectively reboot.
Cai Walkowiak:
As referenced above using Terraform to determine the state, stopped, running, restarting is not the function of Terraform. If you are using Terraform Enterprise / self-hosted you definitely have options with Ansible playbook ( https://galaxy.ansible.com/amazon/aws ).
As far as it being part of an obfuscated pipeline process and you need to submit code or otherwise manage the resources there is nothing that TFE prevents you from using an auto-apply. In the Workspace section will have the ‘auto-apply’ option which would put the deployment control on the VCS or code-submission process.
Cai Walkowiak:
aws_instance termination in Terraform is achieved with the removal of the instance from the state - this would be a code change.
If the code is not updated Terraform will recreate.
If using single resource blocks: deleting aws_instance or
if using for_each / count reducing the number deployed.
for_each is preferred as you can be exacting in the removal of the instance you need terminated.
Controlling state / provisioning of the instance itself (os level) is a function of provisioning, just as we would not recommend using Terraform to install updates, or deploy configurations to the instance.
As Alistair points out, I would not manage state (running / stopped ) with Terraform as it would require two executions and code changes to achieve a single action: restart
Whether the instance exists or is terminated should continue to be managed by your Terraform Enterprise instance, any external changes to the infrastructure itself will need to be controlled by the code / *.tf files.
Ashwin Velappan:
Okay @Alistair Mackay @Cai Walkowiak, I’ll explain what kinda scenario currently I’m working on. Please give me your suggestion based on that.
In service now, we are using a specific catalogs to provision windows and linux EC2 machines in AWS. Catalog means kinda online form to fill the requirements(such as server name, instancetype, AZ, environment, volume details etc) to provision the EC2 instance in AWS environment.
End user or developers will create the testing servers from this catalog by filling and submitting it. Later they will usually reach AWS ops to terminate or modify the existing server.
To avoid reaching other teams for modification or deletion process, we created another separate catalog called lifecycle, which should modify the existing server based on their own requirements by filling and submitting it.
Modification contains operations types such as stopping, rebooting, linux volume attach & detach, windows volume attach & detach etc…
For the first catalog, we already written a terraform script and had shared to service now team to integrate with service now application for that specific catalogs(Eg, either windows or linux). So integration has been implemented for server creation through catalog.
but when comes to lifecycle catalog(modification), not sure how to cope with first script… Though I’m currently written general separate script for start and stop the instance by referring those links which I shared earlier, not very sure how to link this script with the first script to modify the server. Just need guidance to go on further in right path, since I’m new to terraform activities. It would be great, if anyone of you guide me on this??
Alistair Mackay:
Yeah. I know you can integrate service now in that manner. However the integration does not have to be solely terraform. If you have a requirement that terraform does not meet, such as rebooting a server, then it requires a different solution, such as a shell script to call aws cli to do the reboot.
Volume attachments, server provision and deprivision, power on/off are defined states so can be managed with TF.
Bear in mind that just because some manager says do it all in TF does not necessarily mean that is possible. If you come across blockers, you must raise in team meetings.
agree on your last sentence. Thanks for the inputs.