packer-cn/website/source/docs/builders/triton.html.md

193 lines
8.7 KiB
Markdown
Raw Normal View History

---
2017-06-14 21:04:16 -04:00
description: |
The triton Packer builder is able to create new images for use with Triton.
These images can be used with both the Joyent public cloud (which is powered
by Triton) as well with private Triton installations. This builder uses the
Triton Cloud API to create images.
2017-03-02 04:06:18 -05:00
layout: docs
2017-06-14 21:04:16 -04:00
page_title: 'Triton - Builders'
sidebar_current: 'docs-builders-triton'
---
# Triton Builder
Type: `triton`
2016-12-29 05:17:24 -05:00
The `triton` Packer builder is able to create new images for use with Triton.
These images can be used with both the [Joyent public
cloud](https://www.joyent.com/) (which is powered by Triton) as well with
private [Triton](https://github.com/joyent/triton) installations.
This builder uses the Triton Cloud API to create these images. Triton also
supports the Docker API however this builder does *not*. If you want to create
Docker images on Triton you should use the Packer Docker builder.
The builder creates and launches a temporary VM based on a specified source
image, runs any provisioning necessary, uses the Triton "VM to image"
functionality to create a reusable image and finally destroys the temporary VM.
2017-04-26 15:17:02 -04:00
This reusable image can then be used to launch new machines.
2016-12-29 05:17:24 -05:00
The builder does *not* manage images. Once it creates an image, it is up to you
to use it or delete it.
2017-06-14 21:04:16 -04:00
~> **Private installations of Triton must have custom images enabled!** To use
the Triton builder with a private/on-prem installation of Joyent's Triton
software, you'll need an operator to manually
[enable custom images](https://docs.joyent.com/private-cloud/install/image-management)
after installing Triton. This is not a requirement for Joyent's public cloud
offering of Triton.
## Configuration Reference
2016-12-29 05:17:24 -05:00
There are many configuration options available for the builder. They are
segmented below into two categories: required and optional parameters.
2016-12-29 05:17:24 -05:00
In addition to the options listed here, a
[communicator](/docs/templates/communicator.html) can be configured for this
builder.
### Required:
2017-06-14 21:04:16 -04:00
- `triton_account` (string) - The username of the Triton account to use when
2016-12-29 05:17:24 -05:00
using the Triton Cloud API.
2017-06-14 21:04:16 -04:00
- `triton_key_id` (string) - The fingerprint of the public key of the SSH key
2017-04-26 15:17:02 -04:00
pair to use for authentication with the Triton Cloud API. If
`triton_key_material` is not set, it is assumed that the SSH agent has the
private key corresponding to this key ID loaded.
2016-12-29 05:17:24 -05:00
2017-06-14 21:04:16 -04:00
- `source_machine_image` (string) - The UUID of the image to base the new
image on. Triton supports multiple types of images, called 'brands' in
Triton / Joyent lingo, for contains and VM's. See the chapter [Containers
and virtual machines](https://docs.joyent.com/public-cloud/instances) in the
Joyent Triton documentation for detailed information. The following brands
are currently supported by this builder:`joyent` and`kvm`. The choice of
base image automatically decides the brand. On the Joyent public cloud a
valid `source_machine_image` could for example be
2016-12-29 05:17:24 -05:00
`70e3ae72-96b6-11e6-9056-9737fd4d0764` for version 16.3.1 of the 64bit
builder/triton: Add a data source for source_machine_image fixes: #5476 Based on this new template addition: ``` { "variables": { "image_version": "", "triton_account": "", "triton_key_id": "", "triton_key_material": "" }, "builders": [{ "type": "triton", "triton_account": "{{user `triton_account`}}", "triton_key_id": "{{user `triton_key_id`}}", "triton_key_material": "{{user `triton_key_material`}}", "source_machine_package": "g4-highcpu-128M", "source_machine_image_filter": { "name": "ubuntu-16.04", "most_recent": "true" }, "ssh_username": "root", "image_version": "{{user `image_version`}}", "image_name": "teamcity-server" }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y nginx" ] } ] } ``` I got the following output from packer: ``` packer-testing % make image packer build \ -var "triton_account=stack72_joyent" \ -var "triton_key_id=40:9d:d3:f9:0b:86:62:48:f4:2e:a5:8e:43:00:2a:9b" \ -var "triton_key_material=""" \ -var "image_version=1.0.0" \ new-template.json triton output will be in this color. ==> triton: Selecting an image based on search criteria ==> triton: Based, on given search criteria, Machine ID is: "7b5981c4-1889-11e7-b4c5-3f3bdfc9b88b" ==> triton: Waiting for source machine to become available... ==> triton: Waiting for SSH to become available... ==> triton: Connected to SSH! ==> triton: Provisioning with shell script: /var/folders/_p/2_zj9lqn4n11fx20qy787p7c0000gn/T/packer-shell797317310 triton: Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB] triton: Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease ``` I can verify from the triton cli tools that the id `7b5981c4` (from the packer output) is indeed the correct ID ``` terraform [master●] % triton images name=~ubuntu-16.04 SHORTID NAME VERSION FLAGS OS TYPE PUBDATE 49b22aec ubuntu-16.04 20160427 P linux lx-dataset 2016-04-27 675834a0 ubuntu-16.04 20160505 P linux lx-dataset 2016-05-05 4edaa46a ubuntu-16.04 20160516 P linux lx-dataset 2016-05-16 05140a7e ubuntu-16.04 20160601 P linux lx-dataset 2016-06-01 e331b22a ubuntu-16.04 20161004 P linux lx-dataset 2016-10-04 8879c758 ubuntu-16.04 20161213 P linux lx-dataset 2016-12-13 7b5981c4 ubuntu-16.04 20170403 P linux lx-dataset 2017-04-03 <------- THIS IS THE LATEST UBUNTU IMAGE ```
2017-10-30 13:26:42 -04:00
SmartOS base image (a 'joyent' brand image). `source_machine_image_filter` can
be used to populate this UUID.
2017-06-14 21:04:16 -04:00
- `source_machine_package` (string) - The Triton package to use while building
2016-12-29 05:17:24 -05:00
the image. Does not affect (and does not have to be the same) as the package
which will be used for a VM instance running this image. On the Joyent
public cloud this could for example be `g3-standard-0.5-smartos`.
2017-06-14 21:04:16 -04:00
- `image_name` (string) - The name the finished image in Triton will be
2016-12-29 05:17:24 -05:00
assigned. Maximum 512 characters but should in practice be much shorter
(think between 5 and 20 characters). For example `postgresql-95-server` for
an image used as a PostgreSQL 9.5 server.
2017-06-14 21:04:16 -04:00
- `image_version` (string) - The version string for this image. Maximum 128
2016-12-29 05:17:24 -05:00
characters. Any string will do but a format of `Major.Minor.Patch` is
strongly advised by Joyent. See [Semantic Versioning](http://semver.org/)
for more information on the `Major.Minor.Patch` versioning format.
### Optional:
2017-06-14 21:04:16 -04:00
- `triton_url` (string) - The URL of the Triton cloud API to use. If omitted
it will default to the `us-sw-1` region of the Joyent Public cloud. If
you are using your own private Triton installation you will have to supply
the URL of the cloud API of your own Triton installation.
2016-12-29 05:17:24 -05:00
2017-06-14 21:04:16 -04:00
- `triton_key_material` (string) - Path to the file in which the private key
2017-04-26 18:54:18 -04:00
of `triton_key_id` is stored. For example `/home/soandso/.ssh/id_rsa`. If
this is not specified, the SSH agent is used to sign requests with the
`triton_key_id` specified.
2017-04-26 15:17:02 -04:00
2017-06-14 21:04:16 -04:00
- `source_machine_firewall_enabled` (boolean) - Whether or not the firewall of
2016-12-29 05:17:24 -05:00
the VM used to create an image of is enabled. The Triton firewall only
filters inbound traffic to the VM. All outbound traffic is always allowed.
Currently this builder does not provide an interface to add specific
firewall rules. Unless you have a global rule defined in Triton which allows
SSH traffic enabling the firewall will interfere with the SSH provisioner.
The default is `false`.
2017-06-14 21:04:16 -04:00
- `source_machine_metadata` (object of key/value strings) - Triton metadata
2016-12-29 05:17:24 -05:00
applied to the VM used to create the image. Metadata can be used to pass
configuration information to the VM without the need for networking. See
[Using the metadata
API](https://docs.joyent.com/private-cloud/instances/using-mdata) in the
Joyent documentation for more information. This can for example be used to
set the `user-script` metadata key to have Triton start a user supplied
script after the VM has booted.
2017-06-14 21:04:16 -04:00
- `source_machine_name` (string) - Name of the VM used for building the image.
2016-12-29 05:17:24 -05:00
Does not affect (and does not have to be the same) as the name for a VM
instance running this image. Maximum 512 characters but should in practice
be much shorter (think between 5 and 20 characters). For example
`mysql-64-server-image-builder`. When omitted defaults to
`packer-builder-[image_name]`.
2017-06-14 21:04:16 -04:00
- `source_machine_networks` (array of strings) - The UUID's of Triton networks
2016-12-29 05:17:24 -05:00
added to the source machine used for creating the image. For example if any
of the provisioners which are run need Internet access you will need to add
2017-04-26 15:17:02 -04:00
the UUID's of the appropriate networks here. If this is not specified,
instances will be placed into the default Triton public and internal
2017-04-26 15:17:02 -04:00
networks.
2017-06-14 21:04:16 -04:00
- `source_machine_tags` (object of key/value strings) - Tags applied to the VM
2016-12-29 05:17:24 -05:00
used to create the image.
2017-06-14 21:04:16 -04:00
- `image_acls` (array of strings) - The UUID's of the users which will have
2016-12-29 05:17:24 -05:00
access to this image. When omitted only the owner (the Triton user whose
credentials are used) will have access to the image.
2017-06-14 21:04:16 -04:00
- `image_description` (string) - Description of the image. Maximum 512
2016-12-29 05:17:24 -05:00
characters.
2017-06-14 21:04:16 -04:00
- `image_eula_url` (string) - URL of the End User License Agreement (EULA) for
2016-12-29 05:17:24 -05:00
the image. Maximum 128 characters.
2017-06-14 21:04:16 -04:00
- `image_homepage` (string) - URL of the homepage where users can find
2016-12-29 05:17:24 -05:00
information about the image. Maximum 128 characters.
2017-06-14 21:04:16 -04:00
- `image_tags` (object of key/value strings) - Tag applied to the image.
builder/triton: Add a data source for source_machine_image fixes: #5476 Based on this new template addition: ``` { "variables": { "image_version": "", "triton_account": "", "triton_key_id": "", "triton_key_material": "" }, "builders": [{ "type": "triton", "triton_account": "{{user `triton_account`}}", "triton_key_id": "{{user `triton_key_id`}}", "triton_key_material": "{{user `triton_key_material`}}", "source_machine_package": "g4-highcpu-128M", "source_machine_image_filter": { "name": "ubuntu-16.04", "most_recent": "true" }, "ssh_username": "root", "image_version": "{{user `image_version`}}", "image_name": "teamcity-server" }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y nginx" ] } ] } ``` I got the following output from packer: ``` packer-testing % make image packer build \ -var "triton_account=stack72_joyent" \ -var "triton_key_id=40:9d:d3:f9:0b:86:62:48:f4:2e:a5:8e:43:00:2a:9b" \ -var "triton_key_material=""" \ -var "image_version=1.0.0" \ new-template.json triton output will be in this color. ==> triton: Selecting an image based on search criteria ==> triton: Based, on given search criteria, Machine ID is: "7b5981c4-1889-11e7-b4c5-3f3bdfc9b88b" ==> triton: Waiting for source machine to become available... ==> triton: Waiting for SSH to become available... ==> triton: Connected to SSH! ==> triton: Provisioning with shell script: /var/folders/_p/2_zj9lqn4n11fx20qy787p7c0000gn/T/packer-shell797317310 triton: Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB] triton: Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease ``` I can verify from the triton cli tools that the id `7b5981c4` (from the packer output) is indeed the correct ID ``` terraform [master●] % triton images name=~ubuntu-16.04 SHORTID NAME VERSION FLAGS OS TYPE PUBDATE 49b22aec ubuntu-16.04 20160427 P linux lx-dataset 2016-04-27 675834a0 ubuntu-16.04 20160505 P linux lx-dataset 2016-05-05 4edaa46a ubuntu-16.04 20160516 P linux lx-dataset 2016-05-16 05140a7e ubuntu-16.04 20160601 P linux lx-dataset 2016-06-01 e331b22a ubuntu-16.04 20161004 P linux lx-dataset 2016-10-04 8879c758 ubuntu-16.04 20161213 P linux lx-dataset 2016-12-13 7b5981c4 ubuntu-16.04 20170403 P linux lx-dataset 2017-04-03 <------- THIS IS THE LATEST UBUNTU IMAGE ```
2017-10-30 13:26:42 -04:00
- `source_machine_image_filter` (object) - Filters used to populate the `source_machine_image` field.
Example:
``` json
{
"source_machine_image_filter": {
"name": "ubuntu-16.04",
"type": "lx-dataset",
"most_recent": true
}
}
```
## Basic Example
Below is a minimal example to create an joyent-brand image on the Joyent public
cloud:
2017-06-14 21:04:16 -04:00
``` json
{
"builders": [
{
"type": "triton",
2017-04-26 15:17:02 -04:00
"triton_account": "triton_username",
"triton_key_id": "6b:95:03:3d:d3:6e:52:69:01:96:1a:46:4a:8d:c1:7e",
2017-04-26 15:17:02 -04:00
"source_machine_name": "image-builder",
"source_machine_package": "g4-highcpu-128M",
builder/triton: Add a data source for source_machine_image fixes: #5476 Based on this new template addition: ``` { "variables": { "image_version": "", "triton_account": "", "triton_key_id": "", "triton_key_material": "" }, "builders": [{ "type": "triton", "triton_account": "{{user `triton_account`}}", "triton_key_id": "{{user `triton_key_id`}}", "triton_key_material": "{{user `triton_key_material`}}", "source_machine_package": "g4-highcpu-128M", "source_machine_image_filter": { "name": "ubuntu-16.04", "most_recent": "true" }, "ssh_username": "root", "image_version": "{{user `image_version`}}", "image_name": "teamcity-server" }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y nginx" ] } ] } ``` I got the following output from packer: ``` packer-testing % make image packer build \ -var "triton_account=stack72_joyent" \ -var "triton_key_id=40:9d:d3:f9:0b:86:62:48:f4:2e:a5:8e:43:00:2a:9b" \ -var "triton_key_material=""" \ -var "image_version=1.0.0" \ new-template.json triton output will be in this color. ==> triton: Selecting an image based on search criteria ==> triton: Based, on given search criteria, Machine ID is: "7b5981c4-1889-11e7-b4c5-3f3bdfc9b88b" ==> triton: Waiting for source machine to become available... ==> triton: Waiting for SSH to become available... ==> triton: Connected to SSH! ==> triton: Provisioning with shell script: /var/folders/_p/2_zj9lqn4n11fx20qy787p7c0000gn/T/packer-shell797317310 triton: Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB] triton: Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease ``` I can verify from the triton cli tools that the id `7b5981c4` (from the packer output) is indeed the correct ID ``` terraform [master●] % triton images name=~ubuntu-16.04 SHORTID NAME VERSION FLAGS OS TYPE PUBDATE 49b22aec ubuntu-16.04 20160427 P linux lx-dataset 2016-04-27 675834a0 ubuntu-16.04 20160505 P linux lx-dataset 2016-05-05 4edaa46a ubuntu-16.04 20160516 P linux lx-dataset 2016-05-16 05140a7e ubuntu-16.04 20160601 P linux lx-dataset 2016-06-01 e331b22a ubuntu-16.04 20161004 P linux lx-dataset 2016-10-04 8879c758 ubuntu-16.04 20161213 P linux lx-dataset 2016-12-13 7b5981c4 ubuntu-16.04 20170403 P linux lx-dataset 2017-04-03 <------- THIS IS THE LATEST UBUNTU IMAGE ```
2017-10-30 13:26:42 -04:00
"source_machine_image_filter": {
"name": "ubuntu-16.04",
"type": "lx-dataset",
"most_recent": "true"
},
2017-04-26 15:17:02 -04:00
"ssh_username": "root",
2017-04-26 15:17:02 -04:00
"image_name": "my_new_image",
"image_version": "1.0.0"
2017-04-26 15:17:02 -04:00
}
]
}
```
In the above example the SSH key used for `triton_key_material` (connecting to
the Cloud API) and the `ssh_private_key_file` (connecting to the VM once it has
started) are the same. This is because Triton automatically configures the root
users to be able to login via SSH with the same key used to create the VM via
the Cloud API. In more advanced scenarios for example when using a
`source_machine_image` one might use different credentials.
Available `triton_key_id`, `source_machine_package`, `source_machine_image`, and
`source_machine_networks` can be found by using the following
[Triton CLI](https://docs.joyent.com/public-cloud/api-access/cloudapi)
commands: `triton key list`, `triton package list`, `triton image list`, and
`triton network list` respectively.