Exporting an aws based ami (re)backed with packer as a vmware vm into a S3 bucket

[Nicolas Mas]

So I am using packer to baked a centos7 (ami from aws) into another provisioned centos7 which ends up in the "images/ami" aws ec2 folder (to be used later). I would like to generate a vmware image at the same time. Since packer does not do that (from my research) I looked at the aws-cli and found the following command:

ec2-create-instance-export-task ${EC2INSTANCENAME} -e VMware -f VMDK -c ova -b ${S3STORAGEBUCKET} -d ${INSTANCENAME}

Only problem is that it needs to be a running ami (into an ebs). So I was thinking of doing this at the packer level when the ami is backed, but before the temp ami is destroyed. It seems that it can only be achieved via a postprocessor. Has anyone tried to do this before? I am also wondering if and when during runtime the temp ami id is generated and if the variable is accessible.

[Alvaro Miranda Aguilera]

Hello Nicolas

Based on what the source ami is (OS, packages, disk size), will be
easier add a new provider block in the packer template and have packer
to create one.

Few tips here,

Option 1, that I haven't used, is you can use packer with esx/vsphere
and you end with a vm there.
Option 2, is use packer locally to create a ovf + vmdk file and use
ovftool to create the ova
Option 3, there is a packer plugin that create ova after the build is complete

For option 1 the information is on the same vmware-iso
https://packer.io/docs/builders/vmware-iso.html

For option 3
https://github.com/gosddc/packer-post-processor-vagrant-vmware-ovf


I can comment on option 2, that is the one I use:

you will end with a output-vm-ovf folder and inside you will have a ovf file

My builder block looks like this:

{
"name": "vmware_server",
"type": "vmware-iso",
"vm_name": "{{user `hostname`}}",
"guest_os_type": "oraclelinux-64",
"headless": "false",
"http_directory" : "http",
"iso_url": "{{user `isourl`}}",
"iso_checksum": "{{user `isomd5`}}",
"iso_checksum_type": "md5",
"ssh_username": "{{user `ssh_name`}}",
"ssh_password": "{{user `ssh_pass`}}",
"tools_upload_flavor": "linux",
"boot_wait": "5s",
"boot_command": [
"<tab>",
" text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ks.cfg ",
"<enter>"
],
"ssh_wait_timeout": "40m",
"shutdown_command": "shutdown -h now",
"shutdown_timeout": "40m",
"output_directory": "output-vmx-vmware_server",
"disk_size": 50000
},

then on the shell provisioner I have this:

{
"type": "shell",
"only": ["vmware_vagrant","vmware_server"],
"execute_command": "echo 'vagrant'| {{ .Vars }} sudo -E -S bash
'{{.Path}}'",
"pause_before": "5s",
"scripts": [
"scripts/vmware_tools.sh"
]
},

I have no post processor on this vmware_server builder so I end with
the files i mention

packer build -only vmware_server template.json

Then I run:

/Applications/VMware\ Fusion.app/Contents/Library/VMware\ OVF\
Tool/ovftool output-vmx-vmware_server/oracle6.vmx file.ova

and that's ist.

Alvaro

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/packer/issues
> IRC: #packer-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Packer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to packer-tool...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/packer-tool/6abce65f-de32-46cc-a0d1-7dbfe2ca2d61%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nicolas Mas]

Hi Alvaro,

Tks for the feedback. I thought of the option you describe with details (1), and I can't stop feeling uncomfortable having to build twice the same (or almost) the same box when I could leverage on the export function the aws api provides. On the surface, it seems that being able to capture the artifact ID before the packer instance is discarded and passing it to a post-processor which will invoke the aws api is an ok solution. (I actually wonder if Atlas does that).

But I am still unclear on: 

- When packer copies (convert? export?) the running instance into a "my ami" object and destroys the instance it created before the end of the run.

- At which point are the post processor invocated?

It seems the repo you mention in option 3 is quite old, nevertheless I will have a look and hopefully get inspired, tks for the hint. Option 1 is too specific for me ;-)

Nicolas

[alvaro miranda]

This is 100% Alvaro Miranda opinion, so feel free to disagree with me 

:)

re-reading your first note, you said that packer doesn’t do vmware.. it does!.. what are you after? workstation?/Fusion?/Server (ova)?

My runs create the following for me:

1 packer template

and I get

- virtualbox for vagrant box

- virtualbox stand alone ova

- vmware desktop for vagrant box

- vmware desktop stand alone ova (I can use them in vmware server)

and I can add if required

- AWS

- DigitalOcean

- Google Compute

So, as you can see the same template will create the same box in multiple providers

This is what packer excel, I see it as a bakery factory of base layers, where you build the best cake

Start AMI, modifiy AMI, save ami, export AMI, convert AMI to something else.

Depending on the size of the box, if fits in the free tier of atlas (hdd 20gb and 1gb of ram as today), you can push your template to altas, and atlas will bake and store the 2 artifacts so you can use them later.

If you want to run this locally, then packer will create one the boxes locally (say using virtual box or vmware), and the other will be remotely on AWS.. 

From a SysAdmin point of view, 2 base boxes are the same, if they include the same packages in the same versions. 

Can you share a zip your scripts and packer template you use today? Take any hardcoded secret you may have.. and what do you want additionally? Fusion?

Thanks

Alvaro.

[Nicolas Mas]

Taking it with a pinch of salt then ;-)

Did some homework on this just to find the aws api call "ec2-create-instance-export-task" is not working if you did not import the machine in the first place.. So I am going to ditch it. Although it's a pain not being able to export your own backed ami from aws, I guess I will have to go along with the solution you went for: having a parallel vmware builder and provisionner.

Tks for the comments !

Nicolas