mirror of
https://github.com/kemko/nomad.git
synced 2026-01-05 18:05:42 +03:00
d6800c41c1
Some time ago the Windows host we were using as a Nomad client agent test target started failing to allow ssh connections. The underlying problem appears to be with sysprep but I wasn't able to debug the exact cause as it's not an area I have a lot of expertise in. Swap out the deprecated Windows 2016 host for a Windows 2022 host. This will use a base image provided by Amazon and then we'll use a userdata script to bootstrap ssh and some target directories for Terraform to upload files to. The more modern Windows will let us drop some of extra powershell scripts we were using as well. Fixes: https://hashicorp.atlassian.net/browse/NMD-151 Fixes: https://github.com/hashicorp/nomad-e2e/issues/125
55 lines
2.0 KiB
Markdown
55 lines
2.0 KiB
Markdown
# Packer Builds
|
|
|
|
These builds are run as-needed to update the AMIs used by the end-to-end test
|
|
infrastructure.
|
|
|
|
## What goes here?
|
|
|
|
* steps that aren't specific to a given Nomad build: ex. all Linux instances
|
|
need `jq` and `awscli`.
|
|
* steps that aren't specific to a given EC2 instance: nothing that includes an
|
|
IP address.
|
|
* steps that infrequently change: the version of Consul or Vault we ship.
|
|
|
|
## How is this used?
|
|
|
|
The AMIs built by these Packer configs are tagged with `BuilderSha`, which has
|
|
the value of the most recent commit that touched this directory.
|
|
|
|
The nightly E2E job runs a script to see if there are any AMIs that match the
|
|
most recent commit that touched this directory, and if there aren't it will then
|
|
build the AMIs. Then most recent AMI with a matching SHA is used for the nightly
|
|
E2E run.
|
|
|
|
If you are changing this directory to build an AMI for testing, it's recommended
|
|
that you change the name of the AMI or make sure that you've locally committed
|
|
your changes so that your test AMI doesn't get picked up in the next nightly E2E
|
|
run.
|
|
|
|
## Running Packer builds
|
|
|
|
```sh
|
|
$ packer --version
|
|
1.6.4
|
|
|
|
# build Ubuntu Jammy AMI
|
|
$ ./build ubuntu-jammy-amd64
|
|
```
|
|
|
|
## Debugging Packer Builds
|
|
|
|
To [debug a Packer build](https://www.packer.io/docs/other/debugging.html)
|
|
you'll need to pass the `-debug` and `-on-error` flags. You can then ssh into
|
|
the instance using the `ec2_amazon-ebs.pem` file that Packer drops in this
|
|
directory.
|
|
|
|
Packer doesn't have a cleanup command if you've run `-on-error=abort`. So when
|
|
you're done, clean up the machine by looking for "Packer" in the AWS console:
|
|
* [EC2 instances](https://console.aws.amazon.com/ec2/home?region=us-east-1#Instances:search=Packer;sort=tag:Name)
|
|
* [Key pairs](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#KeyPairs:search=packer;sort=keyName)
|
|
* [Security groups](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#SecurityGroups:search=packer;sort=groupName)
|
|
|
|
## Q: What About Windows?
|
|
|
|
For now, we're using an Amazon base image directly.
|