intro nav
This commit is contained in:
Jeff Escalante
parent
37300c7203
commit
a159d6f9b3
|
|
@ -24,3 +24,5 @@
|
|||
/docs/machine-readable/* /docs/commands/index.html 301!
|
||||
/docs/command-line/* /docs/commands/:splat 200
|
||||
/docs/extend/* /docs/extending/:splat 200
|
||||
/intro/getting-started/install /intro/getting-started 301!
|
||||
/intro/getting-started/install.html /intro/getting-started 301!
|
||||
|
|
|
|||
|
|
@ -5,4 +5,11 @@
|
|||
// - All directories must have an "index.mdx" file to serve as
|
||||
// the landing page for the category
|
||||
|
||||
export default []
|
||||
export default [
|
||||
'why',
|
||||
'use-cases',
|
||||
{
|
||||
category: 'getting-started',
|
||||
content: ['build-image', 'provision', 'parallel-builds', 'vagrant', 'next']
|
||||
}
|
||||
]
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ function IntroLayoutWrapper(pageMeta) {
|
|||
}}
|
||||
sidenav={{
|
||||
Link,
|
||||
category: 'guides',
|
||||
category: 'intro',
|
||||
currentPage: props.path,
|
||||
data,
|
||||
order
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-build-image
|
||||
page_title: Build an Image - Getting Started
|
||||
sidebar_title: 'Build an Image'
|
||||
description: |-
|
||||
With Packer installed, let's just dive right into it and build our first
|
||||
image. Our first image will be an Amazon EC2 AMI with Redis pre-installed.
|
||||
|
|
@ -197,7 +198,7 @@ how to validate and build templates into machine images.
|
|||
|
||||
Create a file named `welcome.txt` and add the following:
|
||||
|
||||
```
|
||||
```text
|
||||
WELCOME TO PACKER!
|
||||
```
|
||||
|
||||
|
|
@ -211,7 +212,7 @@ echo "hello"
|
|||
Set your access key and id as environment variables, so we don't need to pass
|
||||
them in through the command line:
|
||||
|
||||
```
|
||||
```text
|
||||
export AWS_ACCESS_KEY_ID=MYACCESSKEYID
|
||||
export AWS_SECRET_ACCESS_KEY=MYSECRETACCESSKEY
|
||||
```
|
||||
|
|
@ -270,7 +271,7 @@ it might look something like this: `"source_ami": "ami-fce3c696"`.
|
|||
|
||||
Your output will look like this:
|
||||
|
||||
```
|
||||
```shell
|
||||
amazon-ebs output will be in this color.
|
||||
|
||||
==> amazon-ebs: Prevalidating AMI Name: packer-linux-aws-demo-1507231105
|
||||
|
|
@ -407,29 +408,22 @@ https://cloudywindows.io/post/winrm-for-provisioning-close-the-door-on-the-way-o
|
|||
|
||||
Save the above code in a file named `bootstrap_win.txt`.
|
||||
|
||||
-> **A quick aside/warning:**<br />
|
||||
Windows administrators in the know might be wondering why we haven't simply
|
||||
-> **A quick aside/warning:** Windows administrators in the know might be wondering why we haven't simply
|
||||
used a `winrm quickconfig -q` command in the script above, as this would
|
||||
_automatically_ set up all of the required elements necessary for connecting
|
||||
over WinRM. Why all the extra effort to configure things manually?<br />
|
||||
over WinRM. Why all the extra effort to configure things manually?<br /><br />
|
||||
Well, long and short, use of the `winrm quickconfig -q` command can sometimes
|
||||
cause the Packer build to fail shortly after the WinRM connection is
|
||||
established. How?<br />
|
||||
|
||||
1. Among other things, as well as setting up the listener for WinRM, the
|
||||
quickconfig command also configures the firewall to allow management messages
|
||||
to be sent over HTTP.<br />
|
||||
2. This undoes the previous command in the script that configured the
|
||||
firewall to prevent this access.<br />
|
||||
3. The upshot is that the system is configured and ready to accept WinRM
|
||||
connections earlier than intended.<br />
|
||||
4. If Packer establishes its WinRM connection immediately after execution of
|
||||
the 'winrm quickconfig -q' command, the later commands within the script that
|
||||
restart the WinRM service will unceremoniously pull the rug out from under
|
||||
the connection.<br />
|
||||
5. While Packer does _a lot_ to ensure the stability of its connection in to
|
||||
your instance, this sort of abuse can prove to be too much and _may_ cause
|
||||
your Packer build to stall irrecoverably or fail!
|
||||
established. How?<br /><br />1. Among other things, as well as setting up the listener for WinRM, the
|
||||
quickconfig command also configures the firewall to allow management messages
|
||||
to be sent over HTTP.<br />2. This undoes the previous command in the script that configured the
|
||||
firewall to prevent this access.<br />3. The upshot is that the system is configured and ready to accept WinRM
|
||||
connections earlier than intended.<br />4. If Packer establishes its WinRM connection immediately after execution of
|
||||
the 'winrm quickconfig -q' command, the later commands within the script that
|
||||
restart the WinRM service will unceremoniously pull the rug out from under
|
||||
the connection.<br />5. While Packer does _a lot_ to ensure the stability of its connection in to
|
||||
your instance, this sort of abuse can prove to be too much and _may_ cause
|
||||
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,
|
||||
|
|
@ -462,13 +456,13 @@ Write-Host "Finally, VAR4 is:" $Env:VAR4
|
|||
Write-Host "None of the special characters needed escaping in the template"
|
||||
```
|
||||
|
||||
Finally, we need to create the actual [build template](/docs/templates/index.html).
|
||||
Finally, we need to create the actual [build template](/docs/templates).
|
||||
Remember, this template is the core configuration file that Packer uses to
|
||||
understand what you want to build, and how you want to build it.
|
||||
|
||||
As mentioned earlier, the specific builder we are using in this example
|
||||
is the [Amazon EBS builder](/docs/builders/amazon-ebs.html).
|
||||
The template below demonstrates use of the [`source_ami_filter`](/docs/builders/amazon-ebs.html#source_ami_filter) configuration option
|
||||
is the [Amazon EBS builder](/docs/builders/amazon-ebs).
|
||||
The template below demonstrates use of the [`source_ami_filter`](/docs/builders/amazon-ebs#source_ami_filter) configuration option
|
||||
available within the builder for automatically selecting the _latest_
|
||||
suitable source Windows AMI provided by Amazon.
|
||||
We also use the `user_data_file` configuration option provided by the builder
|
||||
|
|
@ -478,8 +472,8 @@ actually spinning up the instance, so that later on, our instance is
|
|||
configured to allow Packer to connect in to it.
|
||||
|
||||
The `"provisioners"` section of the template demonstrates use of the
|
||||
[powershell](/docs/provisioners/powershell.html) and
|
||||
[windows-restart](/docs/provisioners/windows-restart.html) provisioners to
|
||||
[powershell](/docs/provisioners/powershell) and
|
||||
[windows-restart](/docs/provisioners/windows-restart) provisioners to
|
||||
customize and control the build process:
|
||||
|
||||
```json
|
||||
|
|
@ -555,7 +549,7 @@ Finally, we can create our new AMI by running `packer build firstrun.json`
|
|||
|
||||
You should see output like this:
|
||||
|
||||
```
|
||||
```shell
|
||||
amazon-ebs output will be in this color.
|
||||
|
||||
==> amazon-ebs: Prevalidating AMI Name: packer-demo-1518111383
|
||||
|
|
@ -626,18 +620,18 @@ set the value for the name field within `source_ami_filter` as required:
|
|||
For Windows 2008 SP2:
|
||||
|
||||
```
|
||||
"name": "*Windows_Server-2008-SP2*English-64Bit-Base*",
|
||||
"name": "*Windows_Server-2008-SP2*English-64Bit-Base*",
|
||||
```
|
||||
|
||||
For Windows 2016:
|
||||
|
||||
```
|
||||
"name": "*Windows_Server-2016-English-Full-Base*",
|
||||
"name": "*Windows_Server-2016-English-Full-Base*",
|
||||
```
|
||||
|
||||
The bootstrapping and sample provisioning should work the same across all
|
||||
Windows server versions.
|
||||
|
||||
[Continue to provisioning an image](./provision.html)
|
||||
[Continue to provisioning an image »](/intro/getting-started/provision)
|
||||
|
||||
[platforms]: /docs/builders/index.html
|
||||
[platforms]: /docs/builders
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-install
|
||||
page_title: Install Packer - Getting Started
|
||||
sidebar_title: 'Getting Started'
|
||||
description: >-
|
||||
Packer must first be installed on the machine you want to run it on. To make
|
||||
|
||||
|
|
@ -30,7 +31,7 @@ Packer may be installed in the following ways:
|
|||
|
||||
## Precompiled Binaries
|
||||
|
||||
To install the precompiled binary, [download](/downloads.html) the appropriate
|
||||
To install the precompiled binary, [download](/downloads) the appropriate
|
||||
package for your system. Packer is currently packaged as a zip file. We do not
|
||||
have any near term plans to provide system packages.
|
||||
|
||||
|
|
@ -131,4 +132,4 @@ To fix this, you can create a symlink to packer that uses a different name like
|
|||
`packer.io`, or invoke the `packer` binary you want using its absolute path,
|
||||
e.g. `/usr/local/packer`.
|
||||
|
||||
[Continue to building an image](./build-image.html)
|
||||
[Continue to building an image »](/intro/getting-started/build-image)
|
||||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-next
|
||||
page_title: Next Steps - Getting Started
|
||||
sidebar_title: 'Next Steps'
|
||||
description: |-
|
||||
That concludes the getting started guide for Packer. You should now be
|
||||
comfortable with basic Packer usage, should understand templates, defining
|
||||
|
|
@ -17,10 +18,10 @@ builds, provisioners, etc. At this point you're ready to begin playing with and
|
|||
using Packer in real scenarios.
|
||||
|
||||
From this point forward, the most important reference for you will be the
|
||||
[documentation](/docs/index.html). The documentation is less of a guide and more of a
|
||||
[documentation](/docs). The documentation is less of a guide and more of a
|
||||
reference of all the overall features and options of Packer.
|
||||
|
||||
As you use Packer more, please voice your comments and concerns on the [mailing
|
||||
list or IRC](/community.html). Additionally, Packer is [open
|
||||
list or IRC](/community). Additionally, Packer is [open
|
||||
source](https://github.com/hashicorp/packer) so please contribute if you'd like
|
||||
to. Contributions are very welcome.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-parallel-builds
|
||||
page_title: Parallel Builds - Getting Started
|
||||
sidebar_title: 'Parallel Builds'
|
||||
description: |-
|
||||
So far we've shown how Packer can automatically build an image and provision
|
||||
it. This on its own is already quite powerful. But Packer can do better than
|
||||
|
|
@ -178,4 +179,4 @@ At the end of the build, Packer outputs both of the artifacts created (an AMI
|
|||
and a DigitalOcean snapshot). Both images created are bare bones Ubuntu
|
||||
installations with Redis pre-installed.
|
||||
|
||||
[Continue to Vagrant boxes](./vagrant.html)
|
||||
[Continue to Vagrant boxes »](/intro/getting-started/vagrant)
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-provision
|
||||
page_title: Provision - Getting Started
|
||||
sidebar_title: 'Provision'
|
||||
description: |-
|
||||
In the previous page of this guide, you created your first image with Packer.
|
||||
The image you just built, however, was basically just a repackaging of a
|
||||
|
|
@ -104,4 +105,4 @@ pre-installed. Additionally, since everything is pre-installed, you can test the
|
|||
images as they're built and know that when they go into production, they'll be
|
||||
functional.
|
||||
|
||||
[Continue to parallel builds](./parallel-builds.html)
|
||||
[Continue to parallel builds »](/intro/getting-started/parallel-builds)
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-getting-started-vagrant
|
||||
page_title: Vagrant Boxes - Getting Started
|
||||
sidebar_title: 'Vagrant Boxes'
|
||||
description: |-
|
||||
Packer also has the ability to take the results of a builder (such as an AMI
|
||||
or plain VMware image) and turn it into a Vagrant box.
|
||||
|
|
@ -12,7 +13,7 @@ description: |-
|
|||
Packer also has the ability to take the results of a builder (such as an AMI or
|
||||
plain VMware image) and turn it into a [Vagrant](https://www.vagrantup.com) box.
|
||||
|
||||
This is done using [post-processors](/docs/templates/post-processors.html).
|
||||
This is done using [post-processors](/docs/templates/post-processors).
|
||||
These take an artifact created by a previous builder or post-processor and
|
||||
transforms it into a new one. In the case of the Vagrant post-processor, it
|
||||
takes an artifact from a builder and transforms it into a Vagrant box file.
|
||||
|
|
@ -44,9 +45,9 @@ Your template should look like the following:
|
|||
|
||||
In this case, we're enabling a single post-processor named "vagrant". This
|
||||
post-processor is built-in to Packer and will create Vagrant boxes. You can
|
||||
always create [new post-processors](/docs/extending/custom-post-processors.html), however.
|
||||
always create [new post-processors](/docs/extending/custom-post-processors), however.
|
||||
The details on configuring post-processors is covered in the
|
||||
[post-processors](/docs/templates/post-processors.html) documentation.
|
||||
[post-processors](/docs/templates/post-processors) documentation.
|
||||
|
||||
Validate the configuration using `packer validate`.
|
||||
|
||||
|
|
@ -77,4 +78,4 @@ image, if you turn it into a Vagrant box, the files of the VMware image will be
|
|||
deleted since they were compressed into the Vagrant box. With creating AWS
|
||||
images, however, the AMI is kept around, since Vagrant needs it to function.
|
||||
|
||||
[Continue to Next Steps](./next.html)
|
||||
[Continue to Next Steps »](/intro/getting-started/next)
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-use-cases
|
||||
page_title: Use Cases - Introduction
|
||||
sidebar_title: 'Use Cases'
|
||||
description: |-
|
||||
By now you should know what Packer does and what the benefits of image
|
||||
creation are. In this section, we'll enumerate *some* of the use cases for
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
layout: intro
|
||||
sidebar_current: intro-why
|
||||
page_title: Why Packer - Introduction
|
||||
sidebar_title: 'Why Use Packer?'
|
||||
description: |-
|
||||
Pre-baked machine images have a lot of advantages, but most have been unable
|
||||
to benefit from them because images have been too tedious to create and
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
- `/intro/getting-started/install` redirects to `/intro/getting-started`
|
||||
Loading…
Reference in New Issue