website: add outscale bsu builder webite documentation
This commit is contained in:
Marin Salinas
Megan Marsh
parent
35c7c6163c
commit
6b3da118fb
|
|
@ -0,0 +1,355 @@
|
|||
---
|
||||
description: |
|
||||
The osc-bsu Packer builder is able to create Outscale OMIs backed by BSU volumes for use in Outscale. For more information on the difference between
|
||||
BSU-backed VMs and VM-store backed VMs, see the storage for
|
||||
the root device section in the Outscale documentation.
|
||||
layout: docs
|
||||
page_title: 'Outscale BSU - Builders'
|
||||
sidebar_current: 'docs-builders-osc-bsubacked'
|
||||
---
|
||||
|
||||
# OMI Builder (BSU backed)
|
||||
|
||||
Type: `osc-bsu`
|
||||
|
||||
The `osc-bsu` Packer builder is able to create Outscale OMIs backed by BSU
|
||||
volumes for use in [Flexible Compute Unit](https://wiki.outscale.net/pages/viewpage.action?pageId=43060893). For more information on
|
||||
the difference between BSU-backed VMs and VM-store backed
|
||||
VMs, see the ["storage for the root device" section in the Outscale
|
||||
documentation](https://wiki.outscale.net/display/EN/Defining+Block+Device+Mappings).
|
||||
|
||||
This builder builds an OMI by launching an Outscale VM from a source OMI,
|
||||
provisioning that running machine, and then creating an OMI from that machine.
|
||||
This is all done in your own Outscale account. The builder will create temporary
|
||||
keypairs, security group rules, etc. that provide it temporary access to the
|
||||
VM while the image is being created. This simplifies configuration quite
|
||||
a bit.
|
||||
|
||||
The builder does *not* manage OMIs. Once it creates an OMI and stores it in
|
||||
your account, it is up to you to use, delete, etc. the OMI.
|
||||
|
||||
-> **Note:** Temporary resources are, by default, all created with the
|
||||
prefix `packer`. This can be useful if you want to restrict the security groups
|
||||
and key pairs Packer is able to operate on.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
There are many configuration options available for the builder. They are
|
||||
segmented below into two categories: required and optional parameters. Within
|
||||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](../templates/communicator.html) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale.html#authentication)
|
||||
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine.html) for more info).
|
||||
|
||||
- `vm_type` (string) - The Outscale VM type to use while building the OMI, such as `t2.small`.
|
||||
|
||||
- `region` (string) - The name of the region, such as `us-east-1`, in which to launch the Outscale VM to create the OMI.
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale.html#authentication)
|
||||
|
||||
- `source_omi` (string) - The initial OMI used as a base for the newly created machine. `source_omi_filter` may be used instead to populate this automatically.
|
||||
|
||||
### Optional:
|
||||
|
||||
- `omi_block_device_mappings` (array of block device mappings) - Add one or more [block device mappings](https://wiki.outscale.net/display/EN/Defining+Block+Device+Mappings) to the OMI. These will be attached when booting a new VM from your OMI. To add a block device during the Packer build see `launch_block_device_mappings` below. Your options here may vary depending on the type of VM you use. The block device mappings allow for the following configuration:
|
||||
|
||||
- `delete_on_vm_deletion` (boolean) - Indicates whether the BSU volume is deleted on VM termination. Default `false`. **NOTE**: If this value is not explicitly set to `true` and volumes are not cleaned up by an alternative method, additional volumes will accumulate after every build.
|
||||
|
||||
- `device_name` (string) - The device name exposed to the VM (for example, `/dev/sdh` or `xvdh`). Required for every device in the block device mapping.
|
||||
|
||||
- `iops` (number) - The number of I/O operations per second (IOPS) that the volume supports. See the documentation on
|
||||
[IOPs](https://wiki.outscale.net/display/EN/About+Volumes#AboutVolumes-VolumeTypesVolumeTypesandIOPS)
|
||||
for more information
|
||||
|
||||
- `no_device` (boolean) - Suppresses the specified device included in the
|
||||
block device mapping of the OMI
|
||||
|
||||
- `snapshot_id` (string) - The ID of the snapshot
|
||||
|
||||
- `virtual_name` (string) - The virtual device name. See the documentation on [Block Device Mapping](https://wiki.outscale.net/display/EN/Defining+Block+Device+Mappings) for more information
|
||||
|
||||
- `volume_size` (number) - The size of the volume, in GiB. Required if not specifying a `snapshot_id`
|
||||
|
||||
- `volume_type` (string) - The volume type. `gp2` for General Purpose (SSD) volumes, `io1` for Provisioned IOPS (SSD) volumes, and `standard` for Magnetic volumes
|
||||
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s). By default this description is empty. This is a [template engine](../templates/engine.html), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `omi_account_ids` (array of strings) - A list of account IDs that have access to launch the resulting OMI(s). By default no additional users other than the user creating the OMIS has permissions to launch it.
|
||||
|
||||
- `omi_virtualization_type` (string) - The type of virtualization for the OMI you are building. This option must match the supported virtualization type of `source_omi`. Can be `paravirtual` or `hvm`.
|
||||
|
||||
- `associate_public_ip_address` (boolean) - If using a non-default Net, public IP addresses are not provided by default. If this is toggled, your new VM will get a Public IP.
|
||||
|
||||
- `subregion_name` (string) - Destination subregion to launch VM in. Leave this empty to allow Outscale to auto-assign.
|
||||
|
||||
- `custom_endpoint_oapi` (string) - This option is useful if you use a cloud
|
||||
provider whose API is compatible with Outscale OAPI. Specify another endpoint
|
||||
like this `outscale.com/oapi/latest`.
|
||||
|
||||
- `disable_stop_vm` (boolean) - Packer normally stops the build
|
||||
VM after all provisioners have run. For Windows VMs, it is
|
||||
sometimes desirable to [run Sysprep](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc721940(v=ws.10)) which will stop the VM for you. If this is set to `true`, Packer
|
||||
*will not* stop the VM but will assume that you will send the stop
|
||||
signal yourself through your final provisioner. You can do this with a
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
|
||||
|
||||
Note that Packer will still wait for the VM to be stopped, and
|
||||
failing to send the stop signal yourself, when you have set this flag to
|
||||
`true`, will cause a timeout.
|
||||
|
||||
- `bsu_optimized` (boolean) - If true, the VM is created with optimized BSU I/O.
|
||||
|
||||
- `force_delete_snapshot` (boolean) - Force Packer to delete snapshots
|
||||
associated with OMIs, which have been deregistered by `force_deregister`.
|
||||
Default `false`.
|
||||
|
||||
- `force_deregister` (boolean) - Force Packer to first deregister an existing
|
||||
OMIS if one with the same name already exists. Default `false`.
|
||||
|
||||
- `insecure_skip_tls_verify` (boolean) - This allows skipping TLS
|
||||
verification of the OAPI endpoint. The default is `false`.
|
||||
|
||||
- `launch_block_device_mappings` (array of block device mappings) - Add one
|
||||
or more block devices before the Packer build starts. If you add VM
|
||||
store volumes or BSU volumes in addition to the root device volume, the
|
||||
created OMIS will contain block device mapping information for those
|
||||
volumes. Outscale creates snapshots of the source VM's root volume and
|
||||
any other BSU volumes described here. When you launch an VM from this
|
||||
new OMI, the VM automatically launches with these additional volumes,
|
||||
and will restore them from snapshots taken from the source VM.
|
||||
|
||||
- `run_tags` (object of key/value strings) - Tags to apply to the VM
|
||||
that is *launched* to create the OMI. These tags are *not* applied to the
|
||||
resulting OMIS unless they're duplicated in `tags`. This is a [template
|
||||
engine](../templates/engine.html), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `run_volume_tags` (object of key/value strings) - Tags to apply to the
|
||||
volumes that are *launched* to create the OMI. These tags are *not* applied
|
||||
to the resulting OMIS unless they're duplicated in `tags`. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `security_group_id` (string) - The ID (*not* the name) of the security
|
||||
group to assign to the VM. By default this is not set and Packer will
|
||||
automatically create a new temporary security group to allow SSH access.
|
||||
Note that if this is specified, you must be sure the security group allows
|
||||
access to the `ssh_port` given below.
|
||||
|
||||
- `security_group_ids` (array of strings) - A list of security groups as
|
||||
described above. Note that if this is specified, you must omit the
|
||||
`security_group_id`.
|
||||
|
||||
- `shutdown_behavior` (string) - Automatically terminate VMs on
|
||||
shutdown in case Packer exits ungracefully. Possible values are "stop" and
|
||||
"terminate", default is `stop`.
|
||||
|
||||
- `skip_region_validation` (boolean) - Set to true if you want to skip
|
||||
validation of the region configuration option. Default `false`.
|
||||
|
||||
- `snapshot_groups` (array of strings) - A list of groups that have access to
|
||||
create volumes from the snapshot(s). By default no groups have permission
|
||||
to create volumes from the snapshot(s). `all` will make the snapshot
|
||||
publicly accessible.
|
||||
|
||||
- `snapshot_users` (array of strings) - A list of account IDs that have
|
||||
access to create volumes from the snapshot(s). By default no additional
|
||||
users other than the user creating the OMIS has permissions to create
|
||||
volumes from the backing snapshot(s).
|
||||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override OMIS tags if already applied to snapshot. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `source_omi_filter` (object) - Filters used to populate the `source_ami` field.
|
||||
- `filters` (map of strings) - filters used to select a `source_omi`.
|
||||
- `owners` (array of strings) - Filters the images by their owner. You may specify one or more Outscale account IDs, "self" (which will use the account whose credentials you are using to run Packer). This option is required for security reasons.
|
||||
|
||||
Example:
|
||||
|
||||
``` json
|
||||
{
|
||||
"source_omi_filter": {
|
||||
"filters": {
|
||||
"virtualization-type": "hvm",
|
||||
"image-name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
|
||||
"root-device-type": "ebs"
|
||||
},
|
||||
"owners": ["099720109477"],
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This selects an Ubuntu 16.04 HVM BSU OMIS from Canonical. NOTE:
|
||||
This will fail unless *exactly* one OMIS is returned. In the above example,
|
||||
`most_recent` will cause this to succeed by selecting the newest image.
|
||||
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator.html#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator.html#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
|
||||
- `ssh_agent_auth` (boolean) - If true, the local SSH agent will be used to authenticate connections to the source VM. No temporary keypair will be created, and the values of `ssh_password` and `ssh_private_key_file` will be ignored. To use this option with a key pair already configured in the source OMI, leave the `ssh_keypair_name` blank. To associate an existing key pair in Outscale with the source VM, set the `ssh_keypair_name` field to the name of the key pair.
|
||||
|
||||
- `ssh_interface` (string) - One of `public_ip`, `private_ip`, `public_dns`, or `private_dns`. If set, either the public IP address, private IP address, public DNS name or private DNS name will used as the host for SSH. The default behaviour if inside a Net is to use the public IP address if available, otherwise the private IP address will be used. If not in a Net the public DNS name will be used. Also works for WinRM.
|
||||
|
||||
Where Packer is configured for an outbound proxy but WinRM traffic should be direct, `ssh_interface` must be set to `private_dns` and `<region>.compute.internal` included in the `NO_PROXY` environment variable.
|
||||
|
||||
- `subnet_id` (string) - If using Net, the ID of the subnet, such as `subnet-12345def`, where Packer will launch the VM. This field is required if you are using an non-default Net.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMIS and relevant snapshots. This is a [template engine](../templates/engine.html), see [Build template data](#build-template-data) for more information.
|
||||
|
||||
- `temporary_key_pair_name` (string) - The name of the temporary key pair to generate. By default, Packer generates a name that looks like `packer_<UUID>`, where <UUID> is a 36 character unique identifier.
|
||||
|
||||
- `temporary_security_group_source_cidr` (string) - An IPv4 CIDR block to be authorized access to the VM, when packer is creating a temporary security group. The default is `0.0.0.0/0` (i.e., allow any IPv4 source). This is only used when `security_group_id` or `security_group_ids` is not specified.
|
||||
|
||||
- `user_data` (string) - User data to apply when launching the VM. Note that you need to be careful about escaping characters due to the templates being JSON. It is often more convenient to use `user_data_file`, instead. Packer will not automatically wait for a user script to finish before shutting down the VM this must be handled in a provisioner.
|
||||
|
||||
- `user_data_file` (string) - Path to a file that will be used for the user data when launching the VM.
|
||||
|
||||
- `net_id` (string) - If launching into a Net subnet, Packer needs the Net ID in order to create a temporary security group within the Net. Requires `subnet_id` to be set. If this field is left blank, Packer will try to get the Net ID from the `subnet_id`.
|
||||
|
||||
- `net_filter` (object) - Filters used to populate the net_id` field.
|
||||
Example:
|
||||
|
||||
``` json
|
||||
{
|
||||
"net_filter": {
|
||||
"filters": {
|
||||
"is-default": "false",
|
||||
"ip-range": "/24"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This selects the Net with a IPv4 CIDR block of `/24`. NOTE: This will fail unless *exactly* one Net is returned.
|
||||
|
||||
- `filters` (map of strings) - filters used to select a `vpc_id`. NOTE: This will fail unless *exactly* one Net is returned.
|
||||
|
||||
`net_id` take precedence over this.
|
||||
|
||||
- `windows_password_timeout` (string) - The timeout for waiting for a Windows password for Windows VMs. Defaults to 20 minutes. Example value: `10m`
|
||||
|
||||
## Basic Example
|
||||
|
||||
Here is a basic example. You will need to provide access keys, and may need to change the OMIS IDs according to what images exist at the time the template is run:
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"access_key": "{{env `OUTSCALE_ACCESSKEYID`}}",
|
||||
"secret_key": "{{env `OUTSCALE_SECRETKEYID`}}"
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "osc-bsu",
|
||||
"access_key": "{{user `access_key`}}",
|
||||
"secret_key": "{{user `secret_key`}}",
|
||||
"region": "us-east-1",
|
||||
"source_omi": "ami-abcfd0283",
|
||||
"vm_type": "t2.micro",
|
||||
"ssh_username": "outscale",
|
||||
"ami_name": "packer_osc {{timestamp}}"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
-> **Note:** Packer can also read the access key and secret access key from
|
||||
environmental variables. See the configuration reference in the section above
|
||||
for more information on what environmental variables Packer will look for.
|
||||
|
||||
Further information on locating OMIS IDs and their relationship to VM
|
||||
types and regions can be found in the Outscale Documentation [reference](https://wiki.outscale.net/display/EN/Official+OMIs+Reference).
|
||||
|
||||
## Accessing the Instance to Debug
|
||||
|
||||
If you need to access the VM to debug for some reason, run the builder
|
||||
with the `-debug` flag. In debug mode, the Outscale builder will save the private key in the current directory and will output the DNS or IP information as well.
|
||||
You can use this information to access the VM as it is running.
|
||||
|
||||
## OMIS Block Device Mappings Example
|
||||
|
||||
Here is an example using the optional OMIS block device mappings. Our
|
||||
configuration of `launch_block_device_mappings` will expand the root volume
|
||||
(`/dev/sda`) to 40gb during the build (up from the default of 8gb). With
|
||||
`ami_block_device_mappings` Outscale will attach additional volumes `/dev/sdb` and
|
||||
`/dev/sdc` when we boot a new VM of our OMI.
|
||||
|
||||
``` json
|
||||
{
|
||||
"type": "osc-bsu",
|
||||
"access_key": "YOUR KEY HERE",
|
||||
"secret_key": "YOUR SECRET KEY HERE",
|
||||
"region": "us-east-1",
|
||||
"source_ami": "ami-fce3c696",
|
||||
"VM_type": "t2.micro",
|
||||
"ssh_username": "ubuntu",
|
||||
"ami_name": "packer-quick-start {{timestamp}}",
|
||||
"launch_block_device_mappings": [
|
||||
{
|
||||
"device_name": "/dev/sda1",
|
||||
"volume_size": 40,
|
||||
"volume_type": "gp2",
|
||||
"delete_on_vm_deletion": true
|
||||
}
|
||||
],
|
||||
"omi_block_device_mappings": [
|
||||
{
|
||||
"device_name": "/dev/sdb",
|
||||
"virtual_name": "ephemeral0"
|
||||
},
|
||||
{
|
||||
"device_name": "/dev/sdc",
|
||||
"virtual_name": "ephemeral1"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Build template data
|
||||
|
||||
In configuration directives marked as a template engine above, the following variables are available:
|
||||
|
||||
- `BuildRegion` - The region (for example `eu-west-2`) where Packer is building the OMI.
|
||||
- `SourceOMI` - The source OMIS ID (for example ami-a2412fcd`) used to build the OMI.
|
||||
- `SourceOMIName` - The source OMIS Name (for example `ubutu-390`) used to build the OMI.
|
||||
- `SourceOMITags` - The source OMIS Tags, as a `map[string]string` object.
|
||||
|
||||
## Tag Example
|
||||
|
||||
Here is an example using the optional OMIS tags. This will add the tags `OS_Version` and `Release` to the finished OMI. As before, you will need to provide your access keys, and may need to change the source OMIS ID based on what images exist when this template is run:
|
||||
|
||||
``` json
|
||||
{
|
||||
"type": "osc-bsu",
|
||||
"access_key": "YOUR KEY HERE",
|
||||
"secret_key": "YOUR SECRET KEY HERE",
|
||||
"region": "us-east-1",
|
||||
"source_ami": "ami-fce3c696",
|
||||
"VM_type": "t2.micro",
|
||||
"ssh_username": "ubuntu",
|
||||
"ami_name": "packer-quick-start {{timestamp}}",
|
||||
"tags": {
|
||||
"OS_Version": "Ubuntu",
|
||||
"Release": "Latest",
|
||||
"Base_OMI_Name": "{{ .SourceOMIName }}",
|
||||
"Extra": "{{ .SourceOMITags.TagName }}"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
-> **Note:** Packer uses pre-built OMIs as the source for building images.
|
||||
These source OMIs may include volumes that are not flagged to be destroyed on
|
||||
termination of the VM building the new image. Packer will attempt to
|
||||
clean up all residual volumes that are not designated by the user to remain
|
||||
after termination. If you need to preserve those source volumes, you can
|
||||
overwrite the termination setting by specifying `delete_on_vm_deletion=false`
|
||||
in the `launch_block_device_mappings` block for the device.
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
description: |
|
||||
Packer is able to create Outscale Machine Images (OMIs). To achieve this, Packer comes with
|
||||
multiple builders depending on the strategy you want to use to build the OMI.
|
||||
layout: docs
|
||||
page_title: 'Outscale OMI - Builders'
|
||||
sidebar_current: 'docs-builders-outscale'
|
||||
---
|
||||
|
||||
# Outscale OMI Builder
|
||||
|
||||
Packer is able to create Outscale OMIs. To achieve this, Packer comes with
|
||||
multiple builders depending on the strategy you want to use to build the OMI.
|
||||
Packer supports the following builders at the moment:
|
||||
|
||||
- [osc-bsu](/docs/builders/osc-bsu.html) - Create BSU-backed OMIs by
|
||||
launching a source OMI and re-packaging it into a new OMI after
|
||||
provisioning. If in doubt, use this builder, which is the easiest to get
|
||||
started with.
|
||||
|
||||
- [osc-chroot](/docs/builders/osc-chroot.html) - Create EBS-backed OMIs
|
||||
from an existing OUTSCALE VM by mounting the root device and using a
|
||||
[Chroot](https://en.wikipedia.org/wiki/Chroot) environment to provision
|
||||
that device. This is an **advanced builder and should not be used by
|
||||
newcomers**. However, it is also the fastest way to build an EBS-backed OMI
|
||||
since no new OUTSCALE VM needs to be launched.
|
||||
|
||||
- [osc-bsusurrogate](/docs/builders/osc-bsusurrogate.html) - Create BSU-backed OMIs from scratch. Works similarly to the `chroot` builder but does
|
||||
not require running in Outscale VM. This is an **advanced builder and should not be
|
||||
used by newcomers**.
|
||||
|
||||
-> **Don't know which builder to use?** If in doubt, use the [osc-bsu
|
||||
builder](/docs/builders/osc-bsu.html). It is much easier to use and Outscale generally recommends BSU-backed images nowadays.
|
||||
|
||||
# Outscale BSU Volume Builder
|
||||
|
||||
Packer is able to create Outscale BSU Volumes which are preinitialized with a filesystem and data.
|
||||
|
||||
- [osc-bsuvolume](/docs/builders/osc-bsuvolume.html) - Create EBS volumes by launching a source OMI with block devices mapped. Provision the VM, then destroy it, retaining the EBS volumes.
|
||||
|
||||
## Authentication
|
||||
|
||||
The OUTSCALE provider offers a flexible means of providing credentials for authentication. The following methods are supported, in this order, and explained below:
|
||||
|
||||
- Static credentials
|
||||
- Environment variables
|
||||
- Shared credentials file
|
||||
- Outscale Role
|
||||
|
||||
### Static Credentials
|
||||
|
||||
Static credentials can be provided in the form of an access key id and secret.
|
||||
These look like:
|
||||
|
||||
``` json
|
||||
{
|
||||
"access_key": "AKIAIOSFODNN7EXAMPLE",
|
||||
"secret_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
|
||||
"region": "us-east-1",
|
||||
"type": "osc-bsu",
|
||||
"oapi_custom_endpoint": "outscale.com/oapi/latest"
|
||||
}
|
||||
```
|
||||
|
||||
### Environment variables
|
||||
|
||||
You can provide your credentials via the `OUTSCALE_ACCESSKEYID` and
|
||||
`OUTSCALE_SECRETKEYID`, environment variables, representing your Outscale Access
|
||||
Key and Outscale Secret Key, respectively. The `OUTSCALE_REGION` and
|
||||
`OUTSCALE_OAPI_URL` environment variables are also used, if applicable:
|
||||
|
||||
Usage:
|
||||
|
||||
$ export OUTSCALE_ACCESSKEYID="anaccesskey"
|
||||
$ export OUTSCALE_SECRETKEYID="asecretkey"
|
||||
$ export OUTSCALE_REGION="eu-west-2"
|
||||
$ packer build packer.json
|
||||
|
||||
### Checking that system time is current
|
||||
|
||||
Outscale uses the current time as part of the [request signing
|
||||
process](http://docs.aws.osc.com/general/latest/gr/sigv4_signing.html). If
|
||||
your system clock is too skewed from the current time, your requests might
|
||||
fail. If that's the case, you might see an error like this:
|
||||
|
||||
==> osc-bsu: Error querying OMI: AuthFailure: OUTSCALE was not able to validate the provided access credentials
|
||||
|
||||
If you suspect your system's date is wrong, you can compare it against
|
||||
<http://www.time.gov/>. On Linux/OS X, you can run the `date` command to get
|
||||
the current time. If you're on Linux, you can try setting the time with ntp by
|
||||
running `sudo ntpd -q`.
|
||||
|
|
@ -151,6 +151,14 @@
|
|||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-builders-outscale") %>>
|
||||
<a href="/docs/builders/outscale.html">Outscale</a>
|
||||
<ul class="nav">
|
||||
<li<%= sidebar_current("docs-builders-osc-bsubacked") %>>
|
||||
<a href="/docs/builders/osc-bsu.html">BSU</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-builders-parallels") %>>
|
||||
<a href="/docs/builders/parallels.html">Parallels</a>
|
||||
<ul class="nav">
|
||||
|
|
|
|||
Loading…
Reference in New Issue