7

I have read https://www.packer.io/docs/builders/docker.html, but I do not see the advantage of using Packer over docker build or docker-compose up --build for building docker images

030
  • 13,235
  • 16
  • 74
  • 173
  • Just because moving from docker image to AWS ami or any other provider type of image is just a matter of changing the provider ? – Tensibai Sep 08 '17 at 12:09
  • 1
    I'm tempted to close this one as duplicate of your other question as the answer I provided there does answer this question also. – Tensibai Sep 08 '17 at 12:12
  • Agreed. Perhaps you could transform the comment to an answer for clarity. – 030 Sep 08 '17 at 12:26
  • 1
    Edited the answer on the other post so the information is not scattered on two posts. – Tensibai Sep 08 '17 at 12:32
  • @Tensibai Now I am in doubt. I found another reason for using packer over docker build: omission of dockerfiles. Where to put this answer? – 030 Sep 08 '17 at 12:41
  • 1
    Well, the omission of dockerfiles is exactly what I state by changing provider, your describe the content of your image whatever the image is. But I've reopen to let others bring more details if needed. I'll add as an answer my comment above also. – Tensibai Sep 08 '17 at 12:51

1 Answers1

9

Mainly the reason is to keep your image building steps intact if you get to move from docker to another image building system.

Packer does support a bunch of providers (builders in packer terminology), and changing the target "container" is just a matter of changing the builder (or using multiple builders in the same packer file), the build steps (provisionner step) are kept intact and will be the same if you build a docker image or an AWS ami for example (you can even build both at the same time).

Tensibai
  • 11,366
  • 2
  • 35
  • 62