iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove docker documentation from website

This commit is contained in:
Wilken Rivera 2021-02-26 17:26:51 -05:00
parent c3e48ebb71
commit 10e1573930
8 changed files with 0 additions and 1070 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

529
website/content/docs/builders/docker.mdx
View File

@ -1,529 +0,0 @@
---
description: >
The docker Packer builder builds Docker images using Docker. The builder
starts
a Docker container, runs provisioners within this container, then exports the
container for reuse or commits the image.
page_title: Docker - Builders
sidebar_title: Docker
---
# Docker Builder
Type: `docker`
Artifact BuilderId: `packer.docker`
The `docker` Packer builder builds [Docker](https://www.docker.io) images using
Docker. The builder starts a Docker container, runs provisioners within this
container, then exports the container for reuse or commits the image.
Packer builds Docker containers _without_ the use of
[Dockerfiles](https://docs.docker.com/engine/reference/builder/). By not using
`Dockerfiles`, Packer is able to provision containers with portable scripts or
configuration management systems that are not tied to Docker in any way. It
also has a simple mental model: you provision containers much the same way you
provision a normal virtualized or dedicated server. For more information, read
the section on [Dockerfiles](#dockerfiles).
The Docker builder must run on a machine that has Docker Engine installed.
Therefore the builder only works on machines that support Docker and _does not
support running on a Docker remote host_. You can learn about what [platforms
Docker supports and how to install onto
them](https://docs.docker.com/engine/installation/) in the Docker
documentation.
## Basic Example: Export
Below is a fully functioning example. It doesn't do anything useful, since no
provisioners are defined, but it will effectively repackage an image.
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker",
"image": "ubuntu",
"export_path": "image.tar"
}
```
</Tab>
<Tab heading="HCL2">
```hcl
source "docker" "example" {
image = "ubuntu"
export_path = "image.tar"
}
build {
sources = ["source.docker.example"]
}
```
</Tab>
</Tabs>
## Basic Example: Commit
Below is another example, the same as above but instead of exporting the
running container, this one commits the container to an image. The image can
then be more easily tagged, pushed, etc.
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker",
"image": "ubuntu",
"commit": true
}
```
</Tab>
<Tab heading="HCL2">
```hcl
source "docker" "example" {
image = "ubuntu"
commit = true
}
build {
sources = ["source.docker.example"]
}
```
</Tab>
</Tabs>
## Basic Example: Changes to Metadata
Below is an example using the changes argument of the builder. This feature
allows the source images metadata to be changed when committed back into the
Docker environment. It is derived from the `docker commit --change` command
line [option to
Docker](https://docs.docker.com/engine/reference/commandline/commit/).
Example uses of all of the options, assuming one is building an NGINX image
from ubuntu as an simple example:
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker",
"image": "ubuntu",
"commit": true,
"changes": [
"USER www-data",
"WORKDIR /var/www",
"ENV HOSTNAME www.example.com",
"VOLUME /test1 /test2",
"EXPOSE 80 443",
"LABEL version=1.0",
"ONBUILD RUN date",
"CMD [\"nginx\", \"-g\", \"daemon off;\"]",
"ENTRYPOINT /var/www/start.sh"
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
source "docker" "example" {
image = "ubuntu"
commit = true
changes = [
"USER www-data",
"WORKDIR /var/www",
"ENV HOSTNAME www.example.com",
"VOLUME /test1 /test2",
"EXPOSE 80 443",
"LABEL version=1.0",
"ONBUILD RUN date",
"CMD [\"nginx\", \"-g\", \"daemon off;\"]",
"ENTRYPOINT /var/www/start.sh"
]
}
```
</Tab>
</Tabs>
Allowed metadata fields that can be changed are:
- CMD
- String, supports both array (escaped) and string form
- EX: `"CMD [\"nginx\", \"-g\", \"daemon off;\"]"` corresponds to Docker exec form
- EX: `"CMD nginx -g daemon off;"` corresponds to Docker shell form, invokes a command shell first
- ENTRYPOINT
- String, supports both array (escaped) and string form
- EX: `"ENTRYPOINT [\"/bin/sh\", \"-c\", \"/var/www/start.sh\"]"` corresponds to Docker exec form
- EX: `"ENTRYPOINT /var/www/start.sh"` corresponds to Docker shell form, invokes a command shell first
- ENV
- String, note there is no equal sign:
- EX: `"ENV HOSTNAME www.example.com"` not
`"ENV HOSTNAME=www.example.com"`
- EXPOSE
- String, space separated ports
- EX: `"EXPOSE 80 443"`
- LABEL
- String, space separated key=value pairs
- EX: `"LABEL version=1.0"`
- ONBUILD
- String
- EX: `"ONBUILD RUN date"`
- MAINTAINER
- String, deprecated in Docker version 1.13.0
- EX: `"MAINTAINER NAME"`
- USER
- String
- EX: `"USER USERNAME"`
- VOLUME
- String
- EX: `"VOLUME FROM TO"`
- WORKDIR
- String
- EX: `"WORKDIR PATH"`
## Configuration Reference
Configuration options are organized below into two categories: required and
optional. Within each category, the available options are alphabetized and
described.
The Docker builder uses a special Docker communicator _and will not use_ the
standard [communicators](/docs/templates/legacy_json_templates/communicator).
### Required:
You must specify (only) one of `commit`, `discard`, or `export_path`.
@include 'builder/docker/Config-required.mdx'
### Optional:
@include 'builder/docker/AwsAccessConfig-not-required.mdx'
@include 'builder/docker/Config-not-required.mdx'
## Build Shared Information Variables
This build shares generated data with provisioners and post-processors via [template engines](/docs/templates/legacy_json_templates/engine)
for JSON and [contextual variables](/docs/templates/hcl_templates/contextual-variables) for HCL2.
The generated variable available for this builder is:
- `ImageSha256` - When committing a container to an image, this will give the image SHA256. Because the image is not available at the provision step,
this variable is only available for post-processors.
## Using the Artifact: Export
Once the tar artifact has been generated, you will likely want to import, tag,
and push it to a container repository. Packer can do this for you automatically
with the [docker-import](/docs/post-processors/docker-import) and
[docker-push](/docs/post-processors/docker-push) post-processors.
**Note:** This section is covering how to use an artifact that has been
_exported_. More specifically, if you set `export_path` in your configuration.
If you set `commit`, see the next section.
The example below shows a full configuration that would import and push the
created image. This is accomplished using a sequence definition (a collection
of post-processors that are treated as as single pipeline, see
[Post-Processors](/docs/templates/legacy_json_templates/post-processors) for more information):
<Tabs>
<Tab heading="JSON">
```json
{
"post-processors": [
[
{
"type": "docker-import",
"repository": "myrepo/myimage",
"tag": "0.7"
},
{
"type": "docker-push"
}
]
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors {
post-processor "docker-import" {
repository = "myrepo/myimage"
tag = ["0.7"]
}
post-processor "docker-push" {}
}
}
```
</Tab>
</Tabs>
In the above example, the result of each builder is passed through the defined
sequence of post-processors starting first with the `docker-import`
post-processor which will import the artifact as a docker image. The resulting
docker image is then passed on to the `docker-push` post-processor which
handles pushing the image to a container repository.
If you want to do this manually, however, perhaps from a script, you can import
the image using the process below:
```shell-session
$ docker import - registry.mydomain.com/mycontainer:latest < artifact.tar
```
You can then add additional tags and push the image as usual with `docker tag`
and `docker push`, respectively.
## Using the Artifact: Committed
If you committed your container to an image, you probably want to tag, save,
push, etc. Packer can do this automatically for you. An example is shown below
which tags and pushes an image. This is accomplished using a sequence
definition (a collection of post-processors that are treated as as single
pipeline, see [Post-Processors](/docs/templates/legacy_json_templates/post-processors) for more
information):
<Tabs>
<Tab heading="JSON">
```json
{
"post-processors": [
[
{
"type": "docker-tag",
"repository": "myrepo/myimage",
"tag": "0.7"
},
{
"type": "docker-push"
}
]
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors {
post-processor "docker-tag" {
repository = "myrepo/myimage"
tag = ["0.7"]
}
post-processor "docker-push" {}
}
}
```
</Tab>
</Tabs>
In the above example, the result of each builder is passed through the defined
sequence of post-processors starting first with the `docker-tag` post-processor
which tags the committed image with the supplied repository and tag
information. Once tagged, the resulting artifact is then passed on to the
`docker-push` post-processor which handles pushing the image to a container
repository.
Going a step further, if you wanted to tag and push an image to multiple
container repositories, this could be accomplished by defining two,
nearly-identical sequence definitions, as demonstrated by the example below:
<Tabs>
<Tab heading="JSON">
```json
{
"post-processors": [
[
{
"type": "docker-tag",
"repository": "myrepo/myimage1",
"tag": "0.7"
},
"docker-push"
],
[
{
"type": "docker-tag",
"repository": "myrepo/myimage2",
"tag": "0.7"
},
"docker-push"
]
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors {
post-processor "docker-tag" {
repository = "myrepo/myimage1"
tag = ["0.7"]
}
post-processor "docker-push" {}
}
post-processors {
post-processor "docker-tag" {
repository = "myrepo/myimage2"
tag = ["0.7"]
}
post-processor "docker-push" {}
}
}
```
</Tab>
</Tabs>
<span id="amazon-ec2-container-registry"></span>
## Docker For Windows
You should be able to run docker builds against both linux and Windows
containers. Windows containers use a different communicator than linux
containers, because Windows containers cannot use `docker cp`.
If you are building a Windows container, you must set the template option
`"windows_container": true`. Please note that docker cannot export Windows
containers, so you must either commit or discard them.
The following is a fully functional template for building a Windows
container.
<Tabs>
<Tab heading="JSON">
```json
{
"builders": [
{
"type": "docker",
"image": "microsoft/windowsservercore:1709",
"container_dir": "c:/app",
"windows_container": true,
"commit": true
}
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
source "docker" "windows" {
image = "ubuntu"
container_dir = "c:/app"
windows_container = true
commit = true
}
build {
sources = ["source.docker.example"]
}
```
</Tab>
</Tabs>
## Amazon EC2 Container Registry
Packer can tag and push images for use in [Amazon EC2 Container
Registry](https://aws.amazon.com/ecr/). The post processors work as described
above and example configuration properties are shown below:
<Tabs>
<Tab heading="JSON">
```json
{
"post-processors": [
[
{
"type": "docker-tag",
"repository": "12345.dkr.ecr.us-east-1.amazonaws.com/packer",
"tag": "0.7"
},
{
"type": "docker-push",
"ecr_login": true,
"aws_access_key": "YOUR KEY HERE",
"aws_secret_key": "YOUR SECRET KEY HERE",
"login_server": "https://12345.dkr.ecr.us-east-1.amazonaws.com/"
}
]
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors {
post-processor "docker-tag" {
repository = "12345.dkr.ecr.us-east-1.amazonaws.com/packer"
tag = ["0.7"]
}
post-processor "docker-push" {
ecr_login = true
aws_access_key = "YOUR KEY HERE"
aws_secret_key = "YOUR SECRET KEY HERE"
login_server = "https://12345.dkr.ecr.us-east-1.amazonaws.com/"
}
}
```
</Tab>
</Tabs>
[Learn how to set Amazon AWS
credentials.](/docs/builders/amazon#specifying-amazon-credentials)
## Dockerfiles
This builder allows you to build Docker images _without_ Dockerfiles.
With this builder, you can repeatedly create Docker images without the use of a
Dockerfile. You don't need to know the syntax or semantics of Dockerfiles.
Instead, you can just provide shell scripts, Chef recipes, Puppet manifests,
etc. to provision your Docker container just like you would a regular
virtualized or dedicated machine.
While Docker has many features, Packer views Docker simply as a container
runner. To that end, Packer is able to repeatedly build these containers using
portable provisioning scripts.
## Overriding the host directory
By default, Packer creates a temporary folder under your home directory, and
uses that to stage files for uploading into the container. If you would like to
change the path to this temporary folder, you can set the `PACKER_TMP_DIR`.
This can be useful, for example, if you have your home directory permissions
set up to disallow access from the docker daemon.

217
website/content/docs/post-processors/docker-import.mdx
View File

@ -1,217 +0,0 @@
---
description: |
The Packer Docker import post-processor takes an artifact from the docker
builder and imports it with Docker locally. This allows you to apply a
repository and tag to the image and lets you use the other Docker
post-processors such as docker-push to push the image to a registry.
page_title: Docker Import - Post-Processors
sidebar_title: Docker Import
---
# Docker Import Post-Processor
Type: `docker-import`
Artifact BuilderId: `packer.post-processor.docker-import`
The Packer Docker import post-processor takes an artifact from the [docker
builder](/docs/builders/docker) and imports it with Docker locally. This
allows you to apply a repository and tag to the image and lets you use the
other Docker post-processors such as
[docker-push](/docs/post-processors/docker-push) to push the image to a
registry.
## Basic Example
<Tabs>
<Tab heading="JSON">
```json
{
"builders": [
{
"type": "docker",
"image": "ubuntu:18.04",
"export_path": "party_parrot.tar"
}
],
"post-processors": [
{
"type": "docker-import",
"repository": "local/ubuntu",
"tag": "latest"
}
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
source "docker" "example" {
image = "ubuntu:18.04"
export_path = "party_parrot.tar"
}
build {
sources = [
"source.docker.example"
]
post-processor "docker-import" {
repository = "local/ubuntu"
tag = "latest"
}
}
```
</Tab>
</Tabs>
## Configuration
The configuration for this post-processor only requires a `repository`, a `tag`
is optional.
### Required:
- `repository` (string) - The repository of the imported image.
### Optional:
- `tag` (string) - The tag for the imported image. By default this is not
set.
- `changes` (array of strings) - Dockerfile instructions to add to the
commit. Example of instructions are `CMD`, `ENTRYPOINT`, `ENV`, and
`EXPOSE`. Example: `[ "USER ubuntu", "WORKDIR /app", "EXPOSE 8080" ]`
- `keep_input_artifact` (boolean) - if true, do not delete the source tar
after importing it to docker. Defaults to false.
## Example
An example is shown below, showing only the post-processor configuration:
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker-import",
"repository": "hashicorp/packer",
"tag": "0.7"
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "docker-import" {
repository = "hashicorp/packer"
tag = "0.7"
}
```
</Tab>
</Tabs>
This example would take the image created by the Docker builder and import it
into the local Docker process with a name of `hashicorp/packer:0.7`.
Following this, you can use the
[docker-push](/docs/post-processors/docker-push) post-processor to push it
to a registry, if you want.
## Changing Metadata
Below is an example using the changes argument of the post-processor. This
feature allows the tarball metadata to be changed when imported into the Docker
environment. It is derived from the `docker import --change` command line
[option to
Docker](https://docs.docker.com/engine/reference/commandline/import/).
Example uses of all of the options, assuming one is building an NGINX image
from ubuntu as an simple example:
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker-import",
"repository": "local/centos6",
"tag": "latest",
"changes": [
"USER www-data",
"WORKDIR /var/www",
"ENV HOSTNAME www.example.com",
"VOLUME /test1 /test2",
"EXPOSE 80 443",
"LABEL version=1.0",
"ONBUILD RUN date",
"CMD [\"nginx\", \"-g\", \"daemon off;\"]",
"ENTRYPOINT /var/www/start.sh"
]
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "docker-import" {
repository = "local/centos6"
tag = "latest"
changes = [
"USER www-data",
"WORKDIR /var/www",
"ENV HOSTNAME www.example.com",
"VOLUME /test1 /test2",
"EXPOSE 80 443",
"LABEL version=1.0",
"ONBUILD RUN date",
"CMD [\"nginx\", \"-g\", \"daemon off;\"]",
"ENTRYPOINT /var/www/start.sh",
]
}
```
</Tab>
</Tabs>
Allowed metadata fields that can be changed are:
- CMD
- String, supports both array (escaped) and string form
- EX: `"CMD [\"nginx\", \"-g\", \"daemon off;\"]"`
- EX: `"CMD nginx -g daemon off;"`
- ENTRYPOINT
- String
- EX: `"ENTRYPOINT /var/www/start.sh"`
- ENV
- String, note there is no equal sign:
- EX: `"ENV HOSTNAME www.example.com"` not
`"ENV HOSTNAME=www.example.com"`
- EXPOSE
- String, space separated ports
- EX: `"EXPOSE 80 443"`
- LABEL
- String, space separated key=value pairs
- EX: `"LABEL version=1.0"`
- ONBUILD
- String
- EX: `"ONBUILD RUN date"`
- MAINTAINER
- String, deprecated in Docker version 1.13.0
- EX: `"MAINTAINER NAME"`
- USER
- String
- EX: `"USER USERNAME"`
- VOLUME
- String
- EX: `"VOLUME FROM TO"`
- WORKDIR
- String
- EX: `"WORKDIR PATH"`

69
website/content/docs/post-processors/docker-push.mdx
View File

@ -1,69 +0,0 @@
---
description: |
The Packer Docker push post-processor takes an artifact from the docker-import
post-processor and pushes it to a Docker registry.
page_title: Docker Push - Post-Processors
sidebar_title: Docker Push
---
# Docker Push Post-Processor
Type: `docker-push`
Artifact BuilderId: `packer.post-processor.docker-import`
The Packer Docker push post-processor takes an artifact from the
[docker-import](/docs/post-processors/docker-import) post-processor and
pushes it to a Docker registry.
## Configuration
This post-processor has only optional configuration:
- `aws_access_key` (string) - The AWS access key used to communicate with
AWS. [Learn how to set
this.](/docs/builders/amazon#specifying-amazon-credentials)
- `aws_secret_key` (string) - The AWS secret key used to communicate with
AWS. [Learn how to set
this.](/docs/builders/amazon#specifying-amazon-credentials)
- `aws_token` (string) - The AWS access token to use. This is different from
the access key and secret key. If you're not sure what this is, then you
probably don't need it. This will also be read from the `AWS_SESSION_TOKEN`
environmental variable.
- `aws_profile` (string) - The AWS shared credentials profile used to
communicate with AWS. [Learn how to set
this.](/docs/builders/amazon#specifying-amazon-credentials)
- `ecr_login` (boolean) - Defaults to false. If true, the post-processor will
login in order to push the image to [Amazon EC2 Container Registry
(ECR)](https://aws.amazon.com/ecr/). The post-processor only logs in for
the duration of the push. If true `login_server` is required and `login`,
`login_username`, and `login_password` will be ignored.
- `keep_input_artifact` (boolean) - if true, do not delete the docker image
after pushing it to the cloud. Defaults to true, but can be set to false if
you do not need to save your local copy of the docker container.
- `login` (boolean) - Defaults to false. If true, the post-processor will
login prior to pushing. For log into ECR see `ecr_login`.
- `login_username` (string) - The username to use to authenticate to login.
- `login_password` (string) - The password to use to authenticate to login.
- `login_server` (string) - The server address to login to.
-> **Note:** When using _Docker Hub_ or _Quay_ registry servers, `login`
must to be set to `true` and `login_username`, **and** `login_password` must to
be set to your registry credentials. When using Docker Hub, `login_server` can
be omitted.
-> **Note:** If you login using the credentials above, the post-processor
will automatically log you out afterwards (just the server specified).
## Example
For an example of using docker-push, see the section on using generated
artifacts from the [docker builder](/docs/builders/docker).

66
website/content/docs/post-processors/docker-save.mdx
View File

@ -1,66 +0,0 @@
---
description: >
The Packer Docker Save post-processor takes an artifact from the docker
builder
that was committed and saves it to a file. This is similar to exporting the
Docker image directly from the builder, except that it preserves the hierarchy
of images and metadata.
page_title: Docker Save - Post-Processors
sidebar_title: Docker Save
---
# Docker Save Post-Processor
Type: `docker-save`
Artifact BuilderId: `packer.post-processor.docker-save`
The Packer Docker Save post-processor takes an artifact from the [docker
builder](/docs/builders/docker) that was committed and saves it to a file.
This is similar to exporting the Docker image directly from the builder, except
that it preserves the hierarchy of images and metadata.
We understand the terminology can be a bit confusing, but we've adopted the
terminology from Docker, so if you're familiar with that, then you'll be
familiar with this and vice versa.
## Configuration
### Required
The configuration for this post-processor only requires one option.
- `path` (string) - The path to save the image.
### Optional
- `keep_input_artifact` (boolean) - if true, do not delete the docker
container, and only save the .tar created by docker save. Defaults to true.
## Example
An example is shown below, showing only the post-processor configuration:
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker-save",
"path": "foo.tar"
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors "docker-save" {
path = "foo.tar"
}
```
</Tab>
</Tabs>

83
website/content/docs/post-processors/docker-tag.mdx
View File

@ -1,83 +0,0 @@
---
description: |
The Packer Docker Tag post-processor takes an artifact from the docker builder
that was committed and tags it into a repository. This allows you to use the
other Docker post-processors such as docker-push to push the image to a
registry.
page_title: Docker Tag - Post-Processors
sidebar_title: Docker Tag
---
# Docker Tag Post-Processor
Type: `docker-tag`
Artifact BuilderId: `packer.post-processor.docker-tag`
The Packer Docker Tag post-processor takes an artifact from the [docker
builder](/docs/builders/docker) that was committed and tags it into a
repository. This allows you to use the other Docker post-processors such as
[docker-push](/docs/post-processors/docker-push) to push the image to a
registry.
This is very similar to the
[docker-import](/docs/post-processors/docker-import) post-processor except
that this works with committed resources, rather than exported.
## Configuration
The configuration for this post-processor requires `repository`, all other
settings are optional.
- `repository` (string) - The repository of the image.
- `tags` (array of strings) - A list of tags for the image. By default this is
not set. Valid examples include: `"tags": "mytag"` or
`"tags": ["mytag-1", "mytag-2"]`
- `force` (boolean) - If true, this post-processor forcibly tag the image
even if tag name is collided. Default to `false`. But it will be ignored if
Docker &gt;= 1.12.0 was detected, since the `force` option was removed
after 1.12.0.
[reference](https://docs.docker.com/engine/deprecated/#/f-flag-on-docker-tag)
- `keep_input_artifact` (boolean) - Unlike most other post-processors, the
keep_input_artifact option will have no effect for the docker-tag
post-processor. We will always retain the input artifact for docker-tag,
since deleting the image we just tagged is not a behavior anyone should ever
expect. `keep_input_artifact will` therefore always be evaluated as true,
regardless of the value you enter into this field.
## Example
An example is shown below, showing only the post-processor configuration:
<Tabs>
<Tab heading="JSON">
```json
{
"type": "docker-tag",
"repository": "hashicorp/packer",
"tag": "0.7,anothertag"
}
```
</Tab>
<Tab heading="HCL2">
```hcl
post-processors "docker-tag" {
repository = "hashicorp/packer"
tag = "0.7,anothertag"
}
```
</Tab>
</Tabs>
This example would take the image created by the Docker builder and tag it into
the local Docker process with a name of `hashicorp/packer:0.7`.
Following this, you can use the
[docker-push](/docs/post-processors/docker-push) post-processor to push it
to a registry, if you want.

18
website/content/partials/builder/docker/AwsAccessConfig-not-required.mdx
View File

@ -1,18 +0,0 @@
<!-- Code generated from the comments of the AwsAccessConfig struct in builder/docker/ecr_login.go; DO NOT EDIT MANUALLY -->
- `aws_access_key` (string) - The AWS access key used to communicate with
AWS. Learn how to set
this.
- `aws_secret_key` (string) - The AWS secret key used to communicate with
AWS. Learn how to set
this.
- `aws_token` (string) - The AWS access token to use. This is different from
the access key and secret key. If you're not sure what this is, then you
probably don't need it. This will also be read from the AWS_SESSION_TOKEN
environmental variable.
- `aws_profile` (string) - The AWS shared credentials profile used to
communicate with AWS. Learn how to set
this.

74
website/content/partials/builder/docker/Config-not-required.mdx
View File

@ -1,74 +0,0 @@
<!-- Code generated from the comments of the Config struct in builder/docker/config.go; DO NOT EDIT MANUALLY -->
- `author` (string) - Set the author (e-mail) of a commit.
- `changes` ([]string) - Dockerfile instructions to add to the commit. Example of instructions
are CMD, ENTRYPOINT, ENV, and EXPOSE. Example: [ "USER ubuntu", "WORKDIR
/app", "EXPOSE 8080" ]
- `container_dir` (string) - The directory inside container to mount temp directory from host server
for work [file provisioner](/docs/provisioners/file). This defaults
to c:/packer-files on windows and /packer-files on other systems.
- `device` ([]string) - An array of devices which will be accessible in container when it's run
without `--privileged` flag.
- `cap_add` ([]string) - An array of additional [Linux
capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
to grant to the container.
- `cap_drop` ([]string) - An array of [Linux
capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
to drop from the container.
- `exec_user` (string) - Username (UID) to run remote commands with. You can also set the group
name/ID if you want: (UID or UID:GID). You may need this if you get
permission errors trying to run the shell or other provisioners.
- `privileged` (bool) - If true, run the docker container with the `--privileged` flag. This
defaults to false if not set.
- `pull` (bool) - If true, the configured image will be pulled using `docker pull` prior
to use. Otherwise, it is assumed the image already exists and can be
used. This defaults to true if not set.
- `run_command` ([]string) - An array of arguments to pass to docker run in order to run the
container. By default this is set to `["-d", "-i", "-t",
"--entrypoint=/bin/sh", "--", "{{.Image}}"]` if you are using a linux
container, and `["-d", "-i", "-t", "--entrypoint=powershell", "--",
"{{.Image}}"]` if you are running a windows container. `{{.Image}}` is a
template variable that corresponds to the image template option. Passing
the entrypoint option this way will make it the default entrypoint of
the resulting image, so running docker run -it --rm will start the
docker image from the /bin/sh shell interpreter; you could run a script
or another shell by running docker run -it --rm -c /bin/bash. If your
docker image embeds a binary intended to be run often, you should
consider changing the default entrypoint to point to it.
- `tmpfs` ([]string) - An array of additional tmpfs volumes to mount into this container.
- `volumes` (map[string]string) - A mapping of additional volumes to mount into this container. The key of
the object is the host path, the value is the container path.
- `fix_upload_owner` (bool) - If true, files uploaded to the container will be owned by the user the
container is running as. If false, the owner will depend on the version
of docker installed in the system. Defaults to true.
- `windows_container` (bool) - If "true", tells Packer that you are building a Windows container
running on a windows host. This is necessary for building Windows
containers, because our normal docker bindings do not work for them.
- `login` (bool) - This is used to login to dockerhub to pull a private base container. For
pushing to dockerhub, see the docker post-processors
- `login_password` (string) - The password to use to authenticate to login.
- `login_server` (string) - The server address to login to.
- `login_username` (string) - The username to use to authenticate to login.
- `ecr_login` (bool) - Defaults to false. If true, the builder will login in order to pull the
image from Amazon EC2 Container Registry (ECR). The builder only logs in
for the duration of the pull. If true login_server is required and
login, login_username, and login_password will be ignored. For more
information see the section on ECR.

14
website/content/partials/builder/docker/Config-required.mdx
View File

@ -1,14 +0,0 @@
<!-- Code generated from the comments of the Config struct in builder/docker/config.go; DO NOT EDIT MANUALLY -->
- `commit` (bool) - If true, the container will be committed to an image rather than exported.
- `discard` (bool) - Throw away the container when the build is complete. This is useful for
the [artifice
post-processor](/docs/post-processors/artifice).
- `export_path` (string) - The path where the final container will be exported as a tar file.
- `image` (string) - The base image for the Docker container that will be started. This image
will be pulled from the Docker registry if it doesn't already exist.
- `message` (string) - Set a message for the commit.