e0d72930fa
For a long time now we've been advising against the use of provisioners, but our documentation for them is pretty prominent on the website in comparision to the better alternatives, and so it's little surprise that many users end up making significant use of them. Although in the longer term a change to our information architecture would probably address this even better, this is an attempt to be explicit about the downsides of using provisioners and to prominently describe the alternatives that are available for common use-cases, along with some reasons why we consider them to be better. I took the unusual step here of directly linking to specific provider documentation pages about the alternatives, even though we normally try to keep the core documentation provider-agnostic, because otherwise that information tends to be rather buried in the provider documentation and thus the reader would be reasonable to use provisioners just because we're not giving specific enough alternative recommendations.
3.5 KiB
| layout | page_title | sidebar_current | description |
|---|---|---|---|
| docs | Provisioner: file | docs-provisioners-file | The `file` provisioner is used to copy files or directories from the machine executing Terraform to the newly created resource. The `file` provisioner supports both `ssh` and `winrm` type connections. |
File Provisioner
The file provisioner is used to copy files or directories from the machine
executing Terraform to the newly created resource. The file provisioner
supports both ssh and winrm type connections.
-> Note: Provisioners should only be used as a last resort. For most common situations there are better alternatives. For more information, see the main Provisioners page.
Example usage
resource "aws_instance" "web" {
# ...
# Copies the myapp.conf file to /etc/myapp.conf
provisioner "file" {
source = "conf/myapp.conf"
destination = "/etc/myapp.conf"
}
# Copies the string in content into /tmp/file.log
provisioner "file" {
content = "ami used: ${self.ami}"
destination = "/tmp/file.log"
}
# Copies the configs.d folder to /etc/configs.d
provisioner "file" {
source = "conf/configs.d"
destination = "/etc"
}
# Copies all files and folders in apps/app1 to D:/IIS/webapp1
provisioner "file" {
source = "apps/app1/"
destination = "D:/IIS/webapp1"
}
}
Argument Reference
The following arguments are supported:
-
source- This is the source file or folder. It can be specified as relative to the current working directory or as an absolute path. This attribute cannot be specified withcontent. -
content- This is the content to copy on the destination. If destination is a file, the content will be written on that file, in case of a directory a file namedtf-file-contentis created. It's recommended to use a file as the destination. Atemplate_filemight be referenced in here, or any interpolation syntax. This attribute cannot be specified withsource. -
destination- (Required) This is the destination path. It must be specified as an absolute path.
Directory Uploads
The file provisioner is also able to upload a complete directory to the remote machine. When uploading a directory, there are a few important things you should know.
First, when using the ssh connection type the destination directory must already exist.
If you need to create it, use a remote-exec provisioner just prior to the file provisioner
in order to create the directory. When using the winrm connection type the destination
directory will be created for you if it doesn't already exist.
Next, the existence of a trailing slash on the source path will determine whether the directory name will be embedded within the destination, or whether the destination will be created. An example explains this best:
If the source is /foo (no trailing slash), and the destination is /tmp, then the contents
of /foo on the local machine will be uploaded to /tmp/foo on the remote machine. The
foo directory on the remote machine will be created by Terraform.
If the source, however, is /foo/ (a trailing slash is present), and the destination is
/tmp, then the contents of /foo will be uploaded directly into /tmp.
This behavior was adopted from the standard behavior of rsync.
-> Note: Under the covers, rsync may or may not be used.