Updated Packer to 1.0.3 which removes the need for the AWS credential…

[goofygrin]

… workaround (also removed). Note: the article should also be updated.

[heitorlessa]

That is awesome! Thanks for the PR.

We'll test that this week unless you have a build.log handy in there as we didn't build automated tests for it

[heitorlessa]

For reference, it looks like this feature was added in June:

• https://github.com/hashicorp/packer/blob/master/CHANGELOG.md#101-june-19-2017

[goofygrin]

I have a build log. I'll attach it (tomorrow likely).

Also, I'm stripping some things out to make a basis for starting from for all my clients. As such, I'm cleaning up the image before I snapshot it by uninstalling ansible and cleaning up its stuff in /tmp. Happy to make a separate pr for that... I know my infosec clients wouldn't allow those vestiges in a hardened image =).

I did try and use ansible vs ansible-local, but the use of galaxy (which I feel is a good thing) makes this harder due to needing to install ansible inside of the container that codebuild uses.

Also... I'll be triggering the pipeline to the sns topic(s) that Aws publishes when there is a new base ami made available. Not sure quite yet how I'll have two triggers (I may eventually want more than two to allow for client specific agent upgrades/uploads to s3 to trigger a new build).

[heitorlessa]

Hey - I just tested (sorry for the delay) and LGTM ;)

I initially thought about having a hook to uninstall Ansible and such, but then I realized it was better to leave that to the user - Open to discussion tho if we can have it as a pluggable and doesn't add much to the build time.

Not sure I got the codebuild part since the container will only live to that particular run, and will be destroyed afterwards - Mind expanding this part?

From a pipeline perspective you can:

• Call Start Pipeline Execution API to trigger the pipeline from the last commit, of which Packer will get the latest AMI that was published to that SNS
  • I can think of Lambda or using API Gateway as a Service Proxy to CodePipeline (API GW->CodePipeline StartExecution based on Apache Velocity)
• Enhance that pipeline and make it more of a complete service including validations and variations as to how that AMI build process should be triggered
  • That again comes Lambda functions, potentially SSM Parameter Store, etc.

Happy to discuss this in more details over an Issue as it's more appropriate than a PR ;)

Merging this now and creating a new Issue to update Blog Post to reflect that