d686a51d60
The cloud-init configuration runs on boot, which can result in a race condition between that and service startup. This has caused provisioning failures because Nomad expects the userdata to have configured a host volume directory. Diagnosing this was also compounded by a warning being fired by systemd for the Nomad unit file. * Update the location of the `StartLimitIntervalSec` field to it's post-systemd-230 location. * Ensure that the weekly AMI build is up-to-date to reduce the risk of unexpected system software changes. * Move the host volume to a directory we can set up at AMI build time rather than in userdata. |
||
|---|---|---|
| .. | ||
| ubuntu-bionic-amd64 | ||
| windows-2016-amd64 | ||
| README.md | ||
| ubuntu-bionic-amd64.pkr.hcl | ||
| windows-2016-amd64.pkr.hcl | ||
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
jqandawscli. - 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.
Running Packer builds
$ packer --version
1.6.4
# build Ubuntu Bionic AMI
$ packer build ubuntu-bionic-amd64.pkr.hcl
# build Windows AMI
$ packer build windows-2016-amd64.pkr.hcl
Debugging Packer Builds
To debug a Packer build
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: