有没有办法使用Terraform在已经存在的基础设施内运行脚本?

huangapple go评论67阅读模式
英文:

Is there any way to run a script inside alredy existing infrastructre using terraform

问题

我想在预先创建的任何云中的现有实例内使用terraform运行脚本。该实例是手动创建的,是否有方法将我的脚本推送到此实例并使用terraform运行它?
如果是的话,那么我如何使用terraform连接到该实例、推送我的脚本并运行它?

英文:

I want to run a script using terraform inside an existing instance on any cloud which is pre-created .The instance was created manually , is there any way to push my script to this instance and run it using terraform ?
if yes ,then How can i connect to the instance using terraform and push my script and run it ?

答案1

得分: 1

我相信Ansible是一个更容易实现这个目标的选择。

参考这里提供的示例 -
https://docs.ansible.com/ansible/latest/modules/script_module.html

英文:

I believe ansible is a better option to achieve this easily.

Refer the example give here -
https://docs.ansible.com/ansible/latest/modules/script_module.html

答案2

得分: 0

  1. 创建一个.tf文件,并在其中描述您已经存在的资源(例如VM)。
  2. 使用Terraform import导入现有的资源。
  3. 如果这是一个VM,则使用file配置程序将您的脚本添加到远程机器上,并使用remote-exec运行它 - 这两个步骤都在Terraform文件中描述,无需手动更改。
  4. 运行terraform plan以查看预期的更改是否正确,然后如果计划正常,请运行terraform apply
英文:
  1. Create a .tf file and describe your already existing resource (e.g. VM) there
  2. Import existing thing using terraform import
  3. If this is a VM then add your script to remote machine using file provisioner and run it using remote-exec - both steps are described in Terraform file, no manual changes needed
  4. Run terraform plan to see if expected changes are ok, then terraform apply if plan was fine

答案3

得分: 0

Terraform的核心任务是创建、更新和销毁长寿命的基础设施对象。它通常不关心部署的计算实例中运行的软件。相反,它通常期望它正在部署的每个对象表现为一种专门的“设备”,要么是由您的云供应商提供的托管服务,要么是因为您已经在Terraform之外准备了自己的机器映像,该映像设计成在系统启动时立即启动相关工作负载。然后,Terraform只提供系统所需的任何配置信息,以便查找和与周围基础设施进行交互。

与Terraform一起工作的一种不太理想的方式是使用其提供的 provisioners 功能,在创建映像后立即对其进行后期自定义,但这被认为是最后的选择,因为Terraform的生命周期不设计为强力支持此类工作流程,而且通常需要在主系统和其编排层之间有更多的耦合。

Terraform没有旨在将任意文件推送到现有虚拟机的机制。如果您的虚拟机在创建后(无论是由Terraform还是其他方式创建)需要持续的配置维护,那么这就是传统配置管理软件(如Ansible、Chef、Puppet等)的用例,而不是Terraform的用例。

英文:

Terraform's core mission is to create, update, and destroy long-lived infrastructure objects. It is not generally concerned with the software running in the compute instances it deploys. Instead, it generally expects each object it is deploying to behave as a sort of specialized "appliance", either by being a managed service provided by your cloud vendor or because you've prepared your own machine image outside of Terraform that is designed to launch the relevant workload immediately when the system boots. Terraform then just provides the system with any configuration information required to find and interact with the surrounding infrastructure.

A less-ideal way to work with Terraform is to use its provisioners feature to do late customization of an image just after it's created, but that's considered to be a last resort because Terraform's lifecycle is not designed to include strong support for such a workflow, and it will tend to require a lot more coupling between your main system and its orchestration layer.

Terraform has no mechanism intended for pushing arbitrary files into existing virtual machines. If your virtual machines need ongoing configuration maintenence after they've been created (by Terraform or otherwise) then that's a use-case for traditional configuration management software such as Ansible, Chef, Puppet, etc, rather than for Terraform.

huangapple
  • 本文由 发表于 2020年1月6日 15:14:40
  • 转载请务必保留本文链接:https://go.coder-hub.com/59608056.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定