Hi Rickard, Thanks for the reply. I will take a closer look at the "encrypted volumes" support. I thought this was just for encrypting the additional "data" volumes on an instance, not the boot instance.
If encrypting the boot volume is possible, how it this approach different than creating an encrypted AMI using copy-image? does each approach lead to the same result?, If so, I dont need my post-processor at all Scott On Wednesday, September 14, 2016 at 3:18:34 AM UTC-4, Rickard von Essen wrote: > > Why don't you use the amazon-ebs support for encrypted volumes? > > 1) You can build in parallel via launching multiple go routines inside > your post-processor. > > 2) You should have "keep_input_artifact": true and your post-processor > should handle not removing the input artifact. See > > https://github.com/mitchellh/packer/blob/master/post-processor/vagrant/post-processor.go#L149 > > > On 13 September 2016 at 17:27, Scott Kellish <skel...@comcast.net > <javascript:>> wrote: > >> Hi, >> New to packer and go for that matter. I created a post-processor to >> generate encrypted AMI's following creation of unencrypted AMI by the AWS >> builder. Its working and I assumed based on what I read that it made sense >> to do this as a post-processing function rather than modifying the existing >> 'ebs' builder but I see some limitations surrounding post-processing so >> wanted to ask here >> >> 1. When I have the AWS builder copy the AMI to other regions via >> ami_regions, post-processor gets called once with the list of AMI's >> created. Wouldnt it be more efficient for packer to call post-processor >> separately for the original and each copy so they can run in parallel? >> >> 2. At least for the aws artifact, theres no way to specify multiple AMI's >> per region so my post-processor can't return the id of the encrypted AMI it >> encrypted. Not being able to return the AMI basically breaks the >> post-processing pipeline (we keep both the unencrypted and encrypted) amis >> >> Thanks, >> I guess I'm not really asking a question here, but any input/comments >> would be appreciated. >> >> Scott >> >> -- >> 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 <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/packer-tool/5687a0b6-6c45-4fde-aab8-8b637ef768c7%40googlegroups.com >> >> <https://groups.google.com/d/msgid/packer-tool/5687a0b6-6c45-4fde-aab8-8b637ef768c7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/75351ca6-f8cd-49ec-b32c-ef44308007e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
