Ask HN: Do you bake AMIs for AWS deployments?

I think more flexible is a better word -- it can do more than what you can do when you bake a static image because you also use it to dynamically manage a running system post-boot.

Ansible can deploy all of your dependencies, keep them updated, push out configuration changes, and deploy your main application code.

I don't use AutoScaling, but no reason it couldn't be used with Ansible. The docs have a bit of detail on how to do it. http://docs.ansible.com/guide_aws.html

Using Docker in production is about stability of API, not technology.

Meaning, for those companies/projects with fast, iterative cycles, who want to take advantage of Docker but understand it's an investment in time over the long run, it's a great fit today.

For those companies/projects with slower cycles, who want a solution which will fit their needs out of the box backed by some sort of support.. 1.0 is the target.

Since building Docker support into Packer, I've heard a few beneficial points from some companies I've helped integrate it into as well as some users. I'm not here to convince you, but just to share what I feel are some valid use cases. Alas, portability is not the only reason, but is one.

* Software installation/configuration knowledge remains solely in existing Chef/Puppet/etc. code-bases. Dockerfiles can add another format for software to be "installed" (or "packaged" if you prefer). Packer + Docker allows you to use your existing expertise, CI process, etc in order to create these containers.

* Common "image" configuration format: again Dockerfiles represent a Docker-specific way of building images. This is all well and good, but it is still very common to have multiple types of images (AMIs, Docker containers, VirtualBox, etc.). In a world where Docker isn't used everywhere, it is a burden to maintain multiple methods of building images. Packer provides a single way to do it that is flexible to multiple platforms. And even if an org decides to transition completely to Docker, Packer helps get them there. Perhaps they want to switch to Dockerfiles after that, but there is still point #1 above.

* Portability: Packer represents a low-risk way to adopt Docker containers, if you use Docker. Dockerfiles are somewhat of an "all-in" approach to Docker. If you don't like Docker, or Docker isn't good for this specific use case (yet, or ever, doesn't matter), then Dockerfiles have to be translated over to another format. As I'm sure you know, big IT is all about minimizing risk when adopting new technologies (actually, a top point to NOT adopt new technologies that we have to fight!). Packer represents a way to say "yes, Docker is new, but Packer provides a pretty low-risk way to get into it. Let's first build vSphere images, like you're used to, and see how those transition to Docker containers. If you don't like it, we still built automation to build vSphere VMs!"

* Extensibility: Packer is very plugin-friendly. You can hook into almost anything. This allows some nice plugins to exist to help augment the process for building images, whether they be containers or not. If Dockerfiles don't support a command to do something, then Packer plugins can very easily do that for you. Maybe it doesn't make sense for this certain feature to be a core feature of Dockerfiles, OR Packer. Either way, it doesn't matter, because the org can just build a plugin for themselves and use it internally. No harm done.

* Process friendliness: In addition to the portability above, centralizing on Packer for image creation is 1..N less processes to adhere to. Docker has a different process for building containers. Aminator has a different process. Every new process is a new special snowflake CI handler to run them, new education for employees, new maintenance. By using Packer, you can use the same CI runners/parsers/steps (Bamboo, Jenkins, etc.) to build any sort of image.

And to answer your question on "what does a Packer config file look like" here is a basic, but fairly typical config file:

    {
      "builders": {{
        "type": "docker",
        "image": "ubuntu",
        "export_path": "image.tar"
      }],

      "provisioners": [{
        "type": "shell",
        "scripts": ["base.sh", "nginx.sh"]
      }]
    }

Pretty simple. Easily human and machine editable/readable. Also, if you happened to want to build an AMI too, it is not much different. And finally, if you use Chef/Puppet/etc, you can just drop that in there, and it works just like you'd expect. Packer even installs Puppet/Chef for you (if you want)!

I hope that clears things up. Packer has been helping with adoption of Docker for many...

Right now I'm just using an ansible playbook to provision the box, create the AMI, and destroy the box within a playbook.

In the near future I plan on moving to Packer since it's the perfect tool for the job.