148 lines
5.6 KiB
Markdown
148 lines
5.6 KiB
Markdown
---
|
|
description: |
|
|
The Atlas post-processor for Packer receives an artifact from a Packer build
|
|
and uploads it to Atlas. Atlas hosts and serves artifacts, allowing you to
|
|
version and distribute them in a simple way.
|
|
layout: docs
|
|
page_title: 'Atlas - Post-Processor'
|
|
sidebar_current: 'docs-post-processors-atlas'
|
|
---
|
|
|
|
# Atlas Post-Processor
|
|
|
|
!> The Packer and Artifact Registry features of Atlas will no longer be
|
|
actively developed or maintained and will be fully decommissioned on Friday,
|
|
March 30, 2018. Please see our [guide on building immutable infrastructure with
|
|
Packer on CI/CD](/guides/packer-on-cicd/) for ideas on implementing these
|
|
features yourself.
|
|
|
|
Type: `atlas`
|
|
|
|
The Atlas post-processor uploads artifacts from your packer builds to Atlas for
|
|
hosting. Artifacts hosted in Atlas are automatically made available for use
|
|
with Terraform, and Atlas provides additional features for managing
|
|
versions and releases. [Learn more about packer in
|
|
Atlas.](https://atlas.hashicorp.com/help/packer/features)
|
|
|
|
You can also use the push command to [run packer builds in
|
|
Atlas](/docs/commands/push.html). The push command and Atlas post-processor
|
|
can be used together or independently.
|
|
|
|
~> If you'd like to publish a Vagrant box to [Vagrant Cloud](https://vagrantcloud.com), you must use the [`vagrant-cloud`](/docs/post-processors/vagrant-cloud.html) post-processor.
|
|
|
|
## Workflow
|
|
|
|
To take full advantage of Packer and Atlas, it's important to understand the
|
|
workflow for creating artifacts with Packer and storing them in Atlas using this
|
|
post-processor. The goal of the Atlas post-processor is to streamline the
|
|
distribution of public or private artifacts by hosting them in a central
|
|
location in Atlas.
|
|
|
|
Here is an example workflow:
|
|
|
|
1. Packer builds an AMI with the [Amazon AMI
|
|
builder](/docs/builders/amazon.html)
|
|
2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
|
|
The `atlas` post-processor is configured with the name of the AMI, for
|
|
example `hashicorp/foobar`, to create the artifact in Atlas or update the
|
|
version if the artifact already exists
|
|
3. The new version is ready and available to be used in deployments with a
|
|
tool like [Terraform](https://www.terraform.io)
|
|
|
|
## Configuration
|
|
|
|
The configuration allows you to specify and access the artifact in Atlas.
|
|
|
|
### Required:
|
|
|
|
- `artifact` (string) - The shorthand tag for your artifact that maps to
|
|
Atlas, i.e `hashicorp/foobar` for `atlas.hashicorp.com/hashicorp/foobar`.
|
|
You must have access to the organization—hashicorp in this example—in order
|
|
to add an artifact to the organization in Atlas.
|
|
|
|
- `artifact_type` (string) - For uploading artifacts to Atlas.
|
|
`artifact_type` can be set to any unique identifier, however, the following
|
|
are recommended for consistency - `amazon.image`, `azure.image`,
|
|
`cloudstack.image`, `digitalocean.image`, `docker.image`,
|
|
`googlecompute.image`, `hyperv.image`, `oneandone.image`,
|
|
`openstack.image`, `parallels.image`, `profitbricks.image`, `qemu.image`,
|
|
`triton.image`, `virtualbox.image`, `vmware.image`, and `custom.image`.
|
|
|
|
### Optional:
|
|
|
|
- `token` (string) - Your access token for the Atlas API.
|
|
|
|
-> Login to Atlas to [generate an Atlas
|
|
Token](https://atlas.hashicorp.com/settings/tokens). The most convenient way to
|
|
configure your token is to set it to the `ATLAS_TOKEN` environment variable, but
|
|
you can also use `token` configuration option.
|
|
|
|
- `atlas_url` (string) - Override the base URL for Atlas. This is useful if
|
|
you're using Atlas Enterprise in your own network. Defaults to
|
|
`https://atlas.hashicorp.com/api/v1`.
|
|
|
|
- `metadata` (map) - Send metadata about the artifact.
|
|
|
|
- `description` (string) - Inside the metadata blob you can add a information
|
|
about the uploaded artifact to Atlas. This will be reflected in the box
|
|
description on Atlas.
|
|
|
|
- `provider` (string) - Used by Atlas to help determine, what should be used
|
|
to run the artifact.
|
|
|
|
- `version` (string) - Used by Atlas to give a semantic version to the
|
|
uploaded artifact.
|
|
|
|
## Environment Variables
|
|
|
|
- `ATLAS_CAFILE` (path) - This should be a path to an X.509 PEM-encoded public key. If specified, this will be used to validate the certificate authority that signed certificates used by an Atlas installation.
|
|
|
|
- `ATLAS_CAPATH` - This should be a path which contains an X.509 PEM-encoded public key file. If specified, this will be used to validate the certificate authority that signed certificates used by an Atlas installation.
|
|
|
|
### Example Configuration
|
|
|
|
``` json
|
|
{
|
|
"variables": {
|
|
"aws_access_key": "ACCESS_KEY_HERE",
|
|
"aws_secret_key": "SECRET_KEY_HERE",
|
|
"atlas_token": "ATLAS_TOKEN_HERE"
|
|
},
|
|
"builders": [
|
|
{
|
|
"type": "amazon-ebs",
|
|
"access_key": "{{user `aws_access_key`}}",
|
|
"secret_key": "{{user `aws_secret_key`}}",
|
|
"region": "us-east-1",
|
|
"source_ami": "ami-fce3c696",
|
|
"instance_type": "t2.micro",
|
|
"ssh_username": "ubuntu",
|
|
"ami_name": "atlas-example {{timestamp}}"
|
|
}
|
|
],
|
|
"provisioners": [
|
|
{
|
|
"type": "shell",
|
|
"inline": [
|
|
"sleep 30",
|
|
"sudo apt-get update",
|
|
"sudo apt-get install apache2 -y"
|
|
]
|
|
}
|
|
],
|
|
"post-processors": [
|
|
{
|
|
"type": "atlas",
|
|
"token": "{{user `atlas_token`}}",
|
|
"artifact": "hashicorp/foobar",
|
|
"artifact_type": "amazon.image",
|
|
"metadata": {
|
|
"created_at": "{{timestamp}}"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
More information on the correct configuration of the `amazon-ebs` builder in this example can be found in the [amazon-ebs builder documentation](/docs/builders/amazon-ebs.html).
|