> You can probably use the chroot builder too.
Tried it, doesn't work. It uses register-image, which cannot maintain the product billing code. Only create-image works. Terraform is a awesome tool to learn and not that hard to get started with. > You will have to define all your infra from the test and then you create > (apply) and after the tests have completed you run destroy and it will > remove everything. Well, I started looking into Terraform since my post, but it doesn't really look like a great fit to me. I'm struggling even to find any examples of anyone doing anything similar. All the examples are _way_ more complicated than we need. At the moment, it appears simpler just to use the EBS builder with Packer, and de-register the unneeded AMIs after the fact. Pretty silly. :( Cheers, -Loren On Wednesday, July 12, 2017 at 8:36:57 AM UTC-4, Rickard von Essen wrote: > > > that PR looks quite promising! Would you consider re-opening it? > > No, don't think we would. We want to keep the scope of Packer narrow. > Ultimately this is a HashiCorp decision (which I'm not an employee of). > > > I personally do not mind the extra time involved with launching a new > instance and conducting the tests there. > > Ok good then Terraform will work nicely for you. > > > We use userdata to pivot /root to tmpfs (in memory), and then > re-partition the root EBS volume and use chroot to complete the build. This > is the only mechanism* we've found that allows us to re-partition the root > volume and preserve the billing product code. > > You can probably use the chroot builder too. > > > So, I'm not sure what hurdles we'd run into getting the tests to execute > against the chroot. > > Agree > > > Also, the tests are sometimes dependent on the instance type, such as > validating that the image is supporting detection of the network interface > speed at 10Gbps. So we'd likely want to launch a new instance anyway, > possibly several, to test different scenarios. > > > I can look into Terraform, also; I don't have any experience with it > currently. Does it also handle the setup and teardown of resources around > launching the instance, running some commands, and terminating the instance > (i.e. create/delete keypair, security group, etc)? > > Terraform is a awesome tool to learn and not that hard to get started > with. You will have to define all your infra from the test and then you > create (apply) and after the tests have completed you run destroy and it > will remove everything. > > Test should run as provisioning on the aws_ec2_instance. > > Regards > Rickard > > On Jul 12, 2017 13:38, "Loren Gordon" <[email protected] <javascript:>> > wrote: > > Hi Rickard, > Thanks, that PR looks quite promising! Would you consider re-opening it? > > I personally do not mind the extra time involved with launching a new > instance and conducting the tests there. I considered running the tests > within the packer instance, before creating the AMI, but our process makes > it a little difficult... We use userdata to pivot /root to tmpfs (in > memory), and then re-partition the root EBS volume and use chroot to > complete the build. This is the only mechanism* we've found that allows us > to re-partition the root volume and preserve the billing product code. So, > I'm not sure what hurdles we'd run into getting the tests to execute > against the chroot. (*Well, we could also chroot a secondary volume, then > shutdown the instance, detach both root and secondary volumes, attach the > secondary volume as root, and then create the image...but that is even more > cumbersome and wouldn't address this problem.) > > Also, the tests are sometimes dependent on the instance type, such as > validating that the image is supporting detection of the network interface > speed at 10Gbps. So we'd likely want to launch a new instance anyway, > possibly several, to test different scenarios. > > I can look into Terraform, also; I don't have any experience with it > currently. Does it also handle the setup and teardown of resources around > launching the instance, running some commands, and terminating the instance > (i.e. create/delete keypair, security group, etc)? The EBS builder in > Packer is _almost_ purpose-built for this...and there is already the null > builder, which serves a sortof-similar use case. > > Cheers, > -Loren > > > > On Wednesday, July 12, 2017 at 12:42:26 AM UTC-4, Rickard von Essen wrote: > >> First see https://github.com/hashicorp/packer/pull/4681 >> >> I have tried running serverspec for educational purposes with Packer. >> First I thougth it should be a second step of a pipeline after >> creating the AMI but after some considerations mostly about the time >> it takes to launch a new instance and the overhead it adds I think >> it's better to do the validation as the last step of your Packer >> provisioning. You can eaither run serverspec localy on the instance >> you are building or run it from the host running Packer. >> >> If you want a second step in your pipeline Terraform might be a better >> option. >> >> // Rickard >> >> On 11 July 2017 at 20:07, Loren Gordon <[email protected]> wrote: >> > Hello, >> > I'd like to run tests using serverspec or testinfra against AMIs >> created >> > using Packer. Is anyone doing something similar? >> > >> > I looked at testkitchen with kitchen-ec2, but it feels pretty weak when >> it >> > comes to setting up the AWS environment...for example, it doesn't >> create the >> > ssh keypair or the security group, and so of course doesn't clean them >> up >> > either. Meaning more setup/teardown that I'd have to manage myself. >> Packer's >> > support for such things is pretty great, so it occurred to me that >> perhaps I >> > could just use Packer to launch the instance and run the tests. >> However, it >> > appears that the ebs builder will _always_ create an AMI and for the >> test >> > run I wouldn't want another AMI. So I looked at the null builder, but >> that >> > seems like it would require me to manage all the same things as >> > testkitchen/kitchen-ec2. >> > >> > I think, ideally, it would be handy if the ebs builder accepted >> something >> > like "null" as an option for the ami_name, or just make it optional >> rather >> > than required, indicating that the builder would not create an AMI or >> any >> > other artifacts. Would anyone else be interested in such a feature? >> > >> > Thanks, >> > -Loren >> > >> > -- >> > 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 [email protected]. >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/packer-tool/a1ac442e-e6cb-4d8b-b2eb-9dc9f9716821%40googlegroups.com. >> >> >> > 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 [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/packer-tool/d6ef75ef-674c-4879-b9aa-ab67d2d82b6d%40googlegroups.com > > <https://groups.google.com/d/msgid/packer-tool/d6ef75ef-674c-4879-b9aa-ab67d2d82b6d%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/433f42fd-28f7-4e04-9564-b32a1233f009%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
