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

<p>Packer does support a bunch of providers (<a href="https://www.packer.io/docs/builders/index.html" rel="noreferrer">builders</a> 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).</p>

CC BY-SA 3.0
2017-09-08T12:54:52.880Z
2017-09-08T12:54:52.880Z
Tensibai
<p>I have read <a href="https://www.packer.io/docs/builders/docker.html" rel="noreferrer">https://www.packer.io/docs/builders/docker.html</a>, but I do not see the advantage of using Packer over docker build or docker-compose up --build for building docker images</p>

CC BY-SA 3.0
2017-09-08T12:09:33.950Z
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
CC BY-SA 3.0
2017-09-08T12:12:42.727Z
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
CC BY-SA 3.0
2017-09-08T12:26:09.647Z
Agreed. Perhaps you could transform the comment to an answer for clarity.
030
CC BY-SA 3.0
2017-09-08T12:32:58.560Z
Edited the answer on the other post so the information is not scattered on two posts.
Tensibai
CC BY-SA 3.0
2017-09-08T12:41:37.477Z
@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
CC BY-SA 3.0
2017-09-08T12:51:37.730Z
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
<docker><packer>
What are reasons for using HashiCorp's packer to build docker images instead of using docker build?
030
# What are reasons for using HashiCorp's packer to build docker images instead of using docker build?

(Asked by: username_0 on 2017-09-08)

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

**Tags:** docker, packer

> **Comments:**
> **username_1**: Just because moving from docker image to AWS ami or any other provider type of image is just a matter of changing the provider ?  
> **username_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.  
> **username_0**: Agreed. Perhaps you could transform the comment to an answer for clarity.  
> **username_1**: Edited the answer on the other post so the information is not scattered on two posts.  
> **username_0**: @username_1 Now I am in doubt. I found another reason for using packer over `docker build`: omission of dockerfiles. Where to put this answer?  
> **username_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.  

---

## 1 answers

### Answer by username_1 on 2017-09-08. Score: 10 | Accepted answer

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](https://www.packer.io/docs/builders/index.html) 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).


---

