update deps, remove internal index.html's
This commit is contained in:
Jeff Escalante
parent
8ca9f2a58c
commit
86b6a4562b
|
|
@ -8,15 +8,16 @@ export default function PackerSubnav() {
|
|||
<Subnav
|
||||
titleLink={{
|
||||
text: 'packer',
|
||||
url: '/'
|
||||
url: '/',
|
||||
}}
|
||||
ctaLinks={[
|
||||
{ text: 'GitHub', url: 'https://www.github.com/hashicorp/packer' },
|
||||
{ text: 'Download', url: '/downloads' }
|
||||
{ text: 'Download', url: '/downloads' },
|
||||
]}
|
||||
currentPath={router.pathname}
|
||||
menuItemsAlign="right"
|
||||
menuItems={subnavItems}
|
||||
constrainWidth
|
||||
/>
|
||||
)
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -6,7 +6,7 @@
|
|||
"dependencies": {
|
||||
"@bugsnag/js": "^6.5.2",
|
||||
"@bugsnag/plugin-react": "^6.5.0",
|
||||
"@hashicorp/nextjs-scripts": "^6.0.0-2",
|
||||
"@hashicorp/nextjs-scripts": "^6.2.0-9",
|
||||
"@hashicorp/react-alert": "^2.0.0",
|
||||
"@hashicorp/react-button": "^2.1.6",
|
||||
"@hashicorp/react-consent-manager": "^2.0.6",
|
||||
|
|
@ -23,7 +23,7 @@
|
|||
"@hashicorp/react-mega-nav": "^4.0.1-2",
|
||||
"@hashicorp/react-product-downloader": "^3.0.3",
|
||||
"@hashicorp/react-section-header": "^2.0.0",
|
||||
"@hashicorp/react-subnav": "^2.2.0",
|
||||
"@hashicorp/react-subnav": "^3.0.0",
|
||||
"@hashicorp/react-text-and-content": "^4.0.6",
|
||||
"@hashicorp/react-text-split": "^0.2.3",
|
||||
"@hashicorp/react-text-split-with-code": "0.0.6",
|
||||
|
|
@ -36,7 +36,7 @@
|
|||
"imagemin-svgo": "^7.1.0",
|
||||
"isomorphic-unfetch": "^3.0.0",
|
||||
"marked": "^0.7.0",
|
||||
"next": "9.3.1",
|
||||
"next": "9.3.3",
|
||||
"nprogress": "^0.2.0",
|
||||
"nuka-carousel": "^4.6.6",
|
||||
"react": "^16.13.1",
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ content and enables some capabilities that are not possible with the
|
|||
This builder works by creating a new MD from either an existing source or from
|
||||
scratch and attaching it to the (already existing) Azure VM where Packer is
|
||||
running. Once attached, a [chroot](https://en.wikipedia.org/wiki/Chroot) is set
|
||||
up and made available to the [provisioners](/docs/provisioners/index.html).
|
||||
up and made available to the [provisioners](/docs/provisioners).
|
||||
After provisioning, the MD is detached, snapshotted and a MD image is created.
|
||||
|
||||
Using this process, minutes can be shaved off the image creation process
|
||||
|
|
|
|||
|
|
@ -12,6 +12,6 @@ sidebar_current: docs-builders-community
|
|||
|
||||
The following builders are developed and maintained by various members of the
|
||||
Packer community, not by HashiCorp. For more information on how to use community
|
||||
builders, see our docs on [extending Packer](/docs/extending/index.html).
|
||||
builders, see our docs on [extending Packer](/docs/extending).
|
||||
|
||||
@include 'builders/community_builders.mdx'
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ like what variables a template accepts, the builders it defines, the
|
|||
provisioners it defines and the order they'll run, and more.
|
||||
|
||||
This command is extra useful when used with [machine-readable
|
||||
output](/docs/commands/index.html) enabled. The command outputs the components
|
||||
output](/docs/commands) enabled. The command outputs the components
|
||||
in a way that is parseable by machines.
|
||||
|
||||
The command doesn't validate the actual configuration of the various components
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ sidebar_current: docs-commands-validate
|
|||
# `validate` Command
|
||||
|
||||
The `packer validate` Packer command is used to validate the syntax and
|
||||
configuration of a [template](/docs/templates/index.html). The command will
|
||||
configuration of a [template](/docs/templates). The command will
|
||||
return a zero exit status on success, and a non-zero exit status on failure.
|
||||
Additionally, if a template doesn't validate, any error messages will be
|
||||
outputted.
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ rest of the documentation.
|
|||
|
||||
If you are unfamiliar with how to use a preseed file for automatic
|
||||
bootstrapping of an image, please either take a look at our
|
||||
[quick guides](/guides/automatic-operating-system-installs/index.html) to
|
||||
[quick guides](/guides/automatic-operating-system-installs) to
|
||||
image bootstrapping, or research automatic configuration for your specific
|
||||
guest operating system. Knowing how to automatically initalize your operating
|
||||
system is critical for being able to successfully use Packer.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ refer to each builder's documentation for more information on how to supply the
|
|||
winrm configuration script.
|
||||
|
||||
If you are unfamiliar with how to use an autounattend file, take a look at our
|
||||
[quick guides](/guides/automatic-operating-system-installs/index.html); knowing
|
||||
[quick guides](/guides/automatic-operating-system-installs); knowing
|
||||
how to automatically initalize your operating system is critical for being able
|
||||
to successfully use Packer to build from an iso.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,5 +37,5 @@ a
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`index`](./index.html) finds the index for a particular element value.
|
||||
- [`lookup`](./lookup.html) retrieves a value from a _map_ given its _key_.
|
||||
- [`index`](/docs/from-1.5/functions/collection/index-fn) finds the index for a particular element value.
|
||||
- [`lookup`](/docs/from-1.5/functions/collection/lookup) retrieves a value from a _map_ given its _key_.
|
||||
|
|
|
|||
|
|
@ -12,6 +12,6 @@ sidebar_current: docs-provisioners-community
|
|||
|
||||
The following provisioners are developed and maintained by various members of the
|
||||
Packer community, not by HashiCorp. For more information on how to use community
|
||||
provisioners, see our docs on [extending Packer](/docs/extending/index.html).
|
||||
provisioners, see our docs on [extending Packer](/docs/extending).
|
||||
|
||||
@include 'provisioners/community_provisioners.mdx'
|
||||
|
|
|
|||
|
|
@ -50,4 +50,4 @@ system is critical for being able to successfully use Packer.
|
|||
## Communicator-Specific Options
|
||||
|
||||
For more details on how to use each communicator, visit the
|
||||
[communicators](/docs/communicators/index.html) page.
|
||||
[communicators](/docs/communicators) page.
|
||||
|
|
|
|||
|
|
@ -15,4 +15,4 @@ please see the [Packer introduction][intro] instead and then continue on to the
|
|||
guides. These guides provide examples for common Packer workflows and actions
|
||||
for users of Packer.
|
||||
|
||||
[intro]: /intro/index.html
|
||||
[intro]: /intro
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ images with Packer.
|
|||
- [How to Build Immutable Infrastructure with Packer and CircleCI Workflows](https://circleci.com/blog/how-to-build-immutable-infrastructure-with-packer-and-circleci-workflows/)
|
||||
- [Using Packer and Ansible to Build Immutable Infrastructure in CodeShip](https://blog.codeship.com/packer-ansible/)
|
||||
|
||||
The majority of the [Packer Builders](/docs/builders/index.html) can run in
|
||||
The majority of the [Packer Builders](/docs/builders) can run in
|
||||
a container or VM, a common model used by most CI/CD services. However, the
|
||||
[QEMU builder](/docs/builders/qemu.html) for
|
||||
[KVM](https://www.linux-kvm.org/page/Main_Page) and
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ re-packaging it into a new AMI.
|
|||
The additional keys within the object are configuration for this builder,
|
||||
specifying things such as access keys, the source AMI to build from and more.
|
||||
The exact set of configuration variables available for a builder are specific to
|
||||
each builder and can be found within the [documentation](/docs/index.html).
|
||||
each builder and can be found within the [documentation](/docs).
|
||||
|
||||
Before we take this template and build an image from it, let's validate the
|
||||
template by running `packer validate example.json`. This command checks the
|
||||
|
|
@ -350,7 +350,7 @@ Here's a basic example of a file that will configure the instance to allow
|
|||
Packer to connect in over WinRM. As you will see, we will tell Packer about
|
||||
our intentions by referencing this file and the commands within it from
|
||||
within the `"builders"` section of our
|
||||
[build template](/docs/templates/index.html) that we will create later.
|
||||
[build template](/docs/templates) that we will create later.
|
||||
|
||||
Note the `<powershell>` and `</powershell>` tags at the top and bottom of
|
||||
the file. These tags tell Amazon we'd like to run the enclosed code with
|
||||
|
|
@ -427,7 +427,7 @@ your Packer build to stall irrecoverably or fail!
|
|||
Now we've got the business of getting Packer connected to our instance
|
||||
taken care of, let's get on with the _real_ reason we're doing all this,
|
||||
which is actually configuring and customizing the instance. Again, we do this
|
||||
with [Provisioners](/docs/provisioners/index.html).
|
||||
with [Provisioners](/docs/provisioners).
|
||||
|
||||
The example config below shows the two different ways of using the [PowerShell
|
||||
provisioner](/docs/provisioners/powershell.html): `inline` and `script`.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ builders defined in our template, such as both Amazon and DigitalOcean, then the
|
|||
shell script would run as part of both builds. There are ways to restrict
|
||||
provisioners to certain builds, but it is outside the scope of this getting
|
||||
started guide. It is covered in more detail in the complete
|
||||
[documentation](/docs/index.html).
|
||||
[documentation](/docs).
|
||||
|
||||
The one provisioner we defined has a type of `shell`. This provisioner ships
|
||||
with Packer and runs shell scripts on the running machine. In our case, we
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
- `vault_aws_engine` (VaultAWSEngineOptions) - Get credentials from Hashicorp Vault's aws secrets engine. You must
|
||||
already have created a role to use. For more information about
|
||||
generating credentials via the Vault engine, see the [Vault
|
||||
docs.](https://www.vaultproject.io/api/secret/aws/index.html#generate-credentials)
|
||||
docs.](https://www.vaultproject.io/api/secret/aws#generate-credentials)
|
||||
If you set this flag, you must also set the below options:
|
||||
|
||||
- `name` (string) - Required. Specifies the name of the role to generate
|
||||
|
|
|
|||
Loading…
Reference in New Issue