AWS user_data with Packer
Asked Answered
A

3

14

So I'm trying to use Packer to create an AWS image and specify some user data via user_data_file. The contents of this file needs to be run when the instance boots as it will be unique each time. I can't bake this into the AMI.

Using packer I have the following:

{
  "variables": {
  "ami_name": ""
  },
  "builders": [
  {
    "type": "amazon-ebs",
    "region": "us-east-1",
    "source_ami": "ami-c8580bdf",
    "instance_type": "t2.micro",
    "ssh_username": "ubuntu",
    "ami_name": "{{ user `ami_name` }}-{{ isotime | clean_ami_name }}",
    "user_data_file": "user_data.sh",
    "tags": {
      "os_version": "ubuntu",
      "built_by": "packer",
      "build_on": "{{ isotime | clean_ami_name }}",
      "Name": "{{ user `ami_name` }}"
    }
  }],
  "provisioners": [
  {
    "type": "ansible",
    "playbook_file": "playbook.yml",
    "user": "ubuntu"
  }]
}

The contents of my user_data shell script are just a few basic config lines for a package that was installed via the ansible scripts that were run in the provisioners step. Watching the output of Packer I can confirm that the ansible scripts all run.

Packer completes and creates the AMI, but the user data piece is never executed. No record of it exists in resulting image. There is no /userdata.log file and /var/lib/cloud/instance/user-data.txt is empty I feel like I missing something basic as this should be a very simple thing to do with Packer.

Ayurveda answered 14/7, 2017 at 20:3 Comment(5)
Could you add the user_data.sh file.Ginglymus
And logs go into /var/log/cloud-init-output.log and /var/log/cloud-init.log.Ginglymus
Richard von Essen set me straight in the answer below. It only executes when the initial packer based instance is launched. It won't exist when I try and launch an instance from this AMI.Ayurveda
How can I make a launched instance from AMI built with packer runs the user data each time so that it is unique per instance? Putting the script the path doesn't work, only works for packer instance. @DavidFicocielloDinnerware
so you're saying you put a very simple script in this path: /var/lib/cloud/scripts/per-instance and it isn't run? for a test you should put something very basic in there and prove that it works. following the direction I got on this issue I was able to have my Instance boot and execute the scripts in that directoryAyurveda
A
14

As pointed out by Rickard von Essen the answer was to copy my script to /var/lib/cloud/scripts/per-instance which would execute my script on every instance launched from this AMI.

Alternately you can put your script in /var/lib/cloud/scripts/per-boot if you needed this to happen each time the instance boots.

In my case since I wanted to register the instance with a 3rd party service I only had it execute once per instance creation.

Ayurveda answered 17/7, 2017 at 14:11 Comment(4)
It doesn't work for me. Are there any other ways to try?Dinnerware
It looks like the paths are still the same. cloudinit.readthedocs.io/en/latest/topics/dir_layout.htmlAyurveda
After putting the userdata sh script to that directory, will cloud-init automatically run that script? Or should I run it during packer provisioning?Dinnerware
I used the file provisioner and ran into permissions issues. How do you copy the script to this location?Raquel
G
14

Rereading this I think maybe you misunderstood how user-data scripts work with Packer.

user_data is provided when the EC2 instance is launched by Packer. This instance is in the end, after provisioning snapshoted and saved as an AMI.

When you launch new instances from the created AMI it doesn't have the same user-data, it gets the user-data you specify when launching this new instance.

The effect of the initial (defined in your template) user-data might or might not be present in the new instance depending if the change was persisted in the AMI.

Ginglymus answered 15/7, 2017 at 9:45 Comment(3)
Ah OK so it does look like I completely missed the point of Packer's user_data section. I assumed it would bake user_data into the image so that it would execute it each time it launched it. I'll have to figure out a different solution. Thank you.Ayurveda
Just upload the script (when provisioning in Packer) to /var/lib/cloud/scripts/per-boot/ or per-instance and make it executable. It will the be executed by cloud-init on each boot or once per instance. See the cloud-init docs for more info.Ginglymus
Rickard von Essen that did it! Thank you. I didn't know about those script directories.Ayurveda
A
14

As pointed out by Rickard von Essen the answer was to copy my script to /var/lib/cloud/scripts/per-instance which would execute my script on every instance launched from this AMI.

Alternately you can put your script in /var/lib/cloud/scripts/per-boot if you needed this to happen each time the instance boots.

In my case since I wanted to register the instance with a 3rd party service I only had it execute once per instance creation.

Ayurveda answered 17/7, 2017 at 14:11 Comment(4)
It doesn't work for me. Are there any other ways to try?Dinnerware
It looks like the paths are still the same. cloudinit.readthedocs.io/en/latest/topics/dir_layout.htmlAyurveda
After putting the userdata sh script to that directory, will cloud-init automatically run that script? Or should I run it during packer provisioning?Dinnerware
I used the file provisioner and ran into permissions issues. How do you copy the script to this location?Raquel
T
1

Uploading to /var/lib/cloud/scripts/* will work, but it depends on how you want your images built. Do you need to be able to spin up an instance quickly?

The best solution would be to us Packer provisioners. Provisioners are used to install and configure the machine image after booting by using ansible/salt/puppet/cheff/shell scripts etc, you can provision your image with what ever you need. That way you are not tied down to having to provision deps on each instance launch, which can cause some issues (think intermittent network issues/failures, which could cause some deps not to be installed)

The provisioners for packer are third party u

Targum answered 11/6, 2019 at 17:17 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.