github.com/StackPointCloud/packer@v0.10.2-0.20180716202532-b28098e0f79b/website/source/docs/provisioners/file.html.md (about) 1 --- 2 description: | 3 The file Packer provisioner uploads files to machines built by Packer. The 4 recommended usage of the file provisioner is to use it to upload files, and 5 then use shell provisioner to move them to the proper place, set permissions, 6 etc. 7 layout: docs 8 page_title: 'File - Provisioners' 9 sidebar_current: 'docs-provisioners-file' 10 --- 11 12 # File Provisioner 13 14 Type: `file` 15 16 The file Packer provisioner uploads files to machines built by Packer. The 17 recommended usage of the file provisioner is to use it to upload files, and then 18 use [shell provisioner](/docs/provisioners/shell.html) to move them to the 19 proper place, set permissions, etc. 20 21 The file provisioner can upload both single files and complete directories. 22 23 ## Basic Example 24 25 ``` json 26 { 27 "type": "file", 28 "source": "app.tar.gz", 29 "destination": "/tmp/app.tar.gz" 30 } 31 ``` 32 33 ## Configuration Reference 34 35 The available configuration options are listed below. 36 37 ### Required 38 39 - `source` (string) - The path to a local file or directory to upload to 40 the machine. The path can be absolute or relative. If it is relative, it is 41 relative to the working directory when Packer is executed. If this is a 42 directory, the existence of a trailing slash is important. Read below on 43 uploading directories. 44 45 - `destination` (string) - The path where the file will be uploaded to in 46 the machine. This value must be a writable location and any parent 47 directories must already exist. 48 49 - `direction` (string) - The direction of the file transfer. This defaults to 50 "upload". If it is set to "download" then the file "source" in the machine 51 will be downloaded locally to "destination" 52 53 ### Optional 54 55 - `generated` (boolean) - For advanced users only. If true, check the file 56 existence only before uploading, rather than upon pre-build validation. 57 This allows to upload files created on-the-fly. This defaults to false. We 58 don't recommend using this feature, since it can cause Packer to become 59 dependent on system state. We would prefer you generate your files before 60 the Packer run, but realize that there are situations where this may be 61 unavoidable. 62 63 ## Directory Uploads 64 65 The file provisioner is also able to upload a complete directory to the remote 66 machine. When uploading a directory, there are a few important things you should 67 know. 68 69 First, the destination directory must already exist. If you need to create it, 70 use a shell provisioner just prior to the file provisioner in order to create 71 the directory. If the destination directory does not exist, the file 72 provisioner may succeed, but it will have undefined results. 73 74 Next, the existence of a trailing slash on the source path will determine 75 whether the directory name will be embedded within the destination, or whether 76 the destination will be created. An example explains this best: 77 78 If the source is `/foo` (no trailing slash), and the destination is `/tmp`, then 79 the contents of `/foo` on the local machine will be uploaded to `/tmp/foo` on 80 the remote machine. The `foo` directory on the remote machine will be created by 81 Packer. 82 83 If the source, however, is `/foo/` (a trailing slash is present), and the 84 destination is `/tmp`, then the contents of `/foo` will be uploaded into `/tmp` 85 directly. 86 87 This behavior was adopted from the standard behavior of rsync. Note that under 88 the covers, rsync may or may not be used. 89 90 ## Uploading files that don't exist before Packer starts 91 92 In general, local files used as the source **must** exist before Packer is run. 93 This is great for catching typos and ensuring that once a build is started, 94 that it will succeed. However, this also means that you can't generate a file 95 during your build and then upload it using the file provisioner later. 96 A convenient workaround is to upload a directory instead of a file. The 97 directory still must exist, but its contents don't. You can write your 98 generated file to the directory during the Packer run, and have it be uploaded 99 later. 100 101 ## Symbolic link uploads 102 103 The behavior when uploading symbolic links depends on the communicator. The 104 Docker communicator will preserve symlinks, but all other communicators will 105 treat local symlinks as regular files. If you wish to preserve symlinks when 106 uploading, it's recommended that you use `tar`. Below is an example of what 107 that might look like: 108 109 ``` text 110 $ ls -l files 111 total 16 112 drwxr-xr-x 3 mwhooker staff 102 Jan 27 17:10 a 113 lrwxr-xr-x 1 mwhooker staff 1 Jan 27 17:10 b -> a 114 -rw-r--r-- 1 mwhooker staff 0 Jan 27 17:10 file1 115 lrwxr-xr-x 1 mwhooker staff 5 Jan 27 17:10 file1link -> file1 116 $ ls -l toupload 117 total 0 118 -rw-r--r-- 1 mwhooker staff 0 Jan 27 17:10 files.tar 119 ``` 120 121 ``` json 122 { 123 "provisioners": [ 124 { 125 "type": "shell-local", 126 "command": "tar cf toupload/files.tar files" 127 }, 128 { 129 "destination": "/tmp/", 130 "source": "./toupload", 131 "type": "file" 132 }, 133 { 134 "inline": [ 135 "cd /tmp && tar xf toupload/files.tar", 136 "rm toupload/files.tar" 137 ], 138 "type": "shell" 139 } 140 ] 141 } 142 ``` 143 144 ## Slowness when transferring large files over WinRM. 145 146 Because of the way our WinRM transfers works, it can take a very long time to 147 upload and download even moderately sized files. If you're experiencing 148 slowness using the file provisioner on Windows, it's suggested that you set up 149 an SSH server and use the [ssh 150 communicator](/docs/templates/communicator.html#ssh-communicator). If you only 151 want to transfer files to your guest, and if your builder supports it, you may 152 also use the `http_directory` directive. This will cause that directory to be 153 available to the guest over http, and set the environment variable 154 `PACKER_HTTP_ADDR` to the address.