packer-windows integration with Packer EC2-EBS builder unclear

[nfloersch]

Just adding an amazon-ebs section to my packer JSON file that uses the same scripts and such for the VMWare builder does not work - obviously. But it is not obvious what path one takes to simultaneously build a Windows Vagrant box and EC2 machine with Packer? While it is not explicitly stated on the project page here it appears that all of this awesome work done to get Windows working well with Packer is only for using VMware or VirtualBox with a final target of running in Vagrant. Has anyone used the work done in this GitHub project to deploy to EC2 as well?

[isuftin]

If I only had a wish for one Christmas miracle...

This is a feature our organization would very much appreciate if it existed.

[kensykora]

The majority of the work that's done on this project is aimed at installing Windows from an ISO. When you use packer on an AWS Windows image, you already get an installed version that has the latest OS patches, which makes ~80% of the work this project performs unnecessary. The extra 20% are kind of just a collection of extras that can be added in (chocolatey) and minor optimizations for the purpose of vagrant itself (defrag disk)

I don't think this project really aims at doing much work starting from cloud based images. The biggest hurdle for packer to get past before it can really start to communicate with AWS / Azure Windows images is WinRM support. Currently this is available with a community plugin (https://github.com/packer-community/packer-windows-plugins) and your best bet would be to start looking over there.

Actually this is probably a good step in the right direction for this project to remove the dependency on SSH so we might be able to include AWS/Azure as another build target in the future.

[nfloersch]

I've been working on this still. I've created an altered version of this project's Win2k12R2 sysprep unattend.xml file that is merged with the defaults provided by Amazon's Win2k12R2 base AMI. I then created a powershell script that I can use for the user data.

1. Powershell user data downloads the scripts from this project (and those I've modified) and that modified sysprep XML file from an S3 bucket... it puts stuff in place, and starts EC2Config -sysprep.
2. Sysprep follows the unattend.xml file and in doing so executes a bunch of the scripts related to this project... including some chocolatey setup, creating the vagrant user, enabling SSH, etc.

My only hiccups in automation are...

1. Sysprep run by EC2Config shuts-down the instance between prep and first run. I have to manually re-start. I think I can write a script to monitor the state of the instance and auto-start it if it goes off, but that does not fit in with Packer in any way unless I write a plugin perhaps. Still once I start the instance again, the unattend.xml takes over and I end up with a 90% configured machine. The last 10% is shell provisioning post builder stage...
2. Packer so far has had issues with SSH. Using the user data powershell script, I've had packer fully create my machine past sysprep and do everything except the shell script provisioning which happens after the builder. The provisioning fails because Packer can't SSH to the box. At first it couldn't reach the box but that was because it was using the private IP of the box to do so. After I changed that it complained about handshake failure ... presumably certificates don't match, but I'm not sure which ones are broken yet.

Still, it appears that if I could figure out the certificates thing, at least, Packer would be able to lead a new instance through the full setup, even though most of that is triggered by powershell in the user data.

My goal all along has been to be able to build EC2 instances that are as close as possible to our development VMs running on the developer's laptop/desktop. Obvious stuff... but it would be so much easier if my devs used Linux or Mac/BSD. Scripting this Windows stuff is always an interesting challenge, but sometimes you just want to get some development work done! :^)

[nfloersch]

I'm sure the WinRM plugin will be awesome for me eventually... but knowing nothing about WinRM, I haven't minded in theory still using SSH on Windows. It is also useful to have SSH on the Windows servers so I can integrate other automation with our servers such as the SSH hooks from our Assembla projects.

[isuftin]

The approach we're looking at taking right now is spinning up Windows Server EC2 instances via CloudFormation, doing some up-front configuration that way and then making a snapshot from that.

The AMI created from that will be used in other CFN template to actually build stacks.

With Linux, I prep AWS base CentOS and Ubuntu AMIs using Packer and then we use the resultant AMIs in CFN templates or create more AMIs with more Packer scripts.

[nfloersch]

Yeah I guess I just wanted to avoid making my own AMIs for Windows because I like the Packer ideal so much ... one generic machine description JSON that ends up realized in EC2, in Vagrant, wherever. It sounds cool, but we aren't quite there yet for Windows it seems :^\

Your CFN setup sounds like you have a much more complex set of server needs than I do! It also sounds pretty cool! Maybe at some point I'll have a better reason to delve into CFN.

[isuftin]

@nfloersch Yeah the CFN aspect of it is for building out full stacks, but it all starts with the basic AMI which is what we were looking to this project to help with. @kensykora does mention https://github.com/packer-community/packer-windows-plugins which does have an EC2-EBS builder for Windows

[kensykora]

@nfloersch I think what you're asking for is definitely possible to a degree, but your ideal to a have a "Generic" machine description JSON isn't -- primarily because of the core reason that you can't install Windows from an ISO on AWS. Even in your packer .json file, you will have 2 separate blocks for AWS buidler and for a vmware-iso builder. They'll look similar but won't be exactly the same.

I for one am fine with the idea that this packer-windows project gets us to the baseline level for Vagrant while a baseline level for AWS is already maintained by Amazon.

I think of it like this:

{
    [packer-windows project] -> Baseline Windows Vagrant Box
}
->
{
  [Vagrant Box] -> Baseline windows vagrant box
  [AWS]             -> Baseline AWS Windows Server Image
}
->
{
   [Vagrant Box] -> Apply Manifests / Scripts
   [AWS Instance] -> Apply Manifests / Scripts
}
->
{
   Application specific vagrant box
   Application specific AWS image
}

The two will always be synced up, but in parallel and never truly be completely equal because they'll be starting from separate points in time. For instance, AWS might be Windows Server 2012 Data Center edition, and Vagrant might be Server 2012 Standard. Very minor but important to remember.

[sneal]

Packer-windows doesn't support AWS.

Perhaps in the future it will once:

1. We've switched packer-windows to default to WinRM
2. Packer-windows has a secure way to communicate over WinRM

For now you can use Packer directly to do what you need. Here's a blog post I wrote about creating a Windows AMI using Packer.

[pingec]

Is this idea any closer to reality today in 2019?