This issue was originally opened by @dnk8n as hashicorp/packer#7963. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.
Why? For the same reason ebs-builder doesn't install everything locally and leave you with an AMI on your own dev machine, then push to Amazon.
I speak specifically about Amazon AWS, but other cloud providers should also apply (so this is a general request which applies to all builders)
Use-case: The host is often a docker container with minimal resources, using docker image: hashicorp/packer:1.4.2 for example. In many cases the docker run command is locked down as well.
It would be great if you could allow a similar workflow to ebs-builder, except end up with a Docker image being pushed instead of an AMI. That is, instead of provisioning locally, a temporary instance is created in ones' own VPC to do the heavy lifting.
Currently, everything is in place to allow that (if Packer and Docker are pre-installed on the remote instance which does the provisioning), except you are forced to create an AMI you don't care about.
Another use cases, say I need 8GB of RAM to compile something, then it would be useful to be able to use Packer's functionalities to use a tiny 'pilot' CI/CD runner to just run packer, with all heavy lifting done in one's own VPC.
This issue was originally opened by @dnk8n as hashicorp/packer#7963. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.
Why? For the same reason ebs-builder doesn't install everything locally and leave you with an AMI on your own dev machine, then push to Amazon.
I speak specifically about Amazon AWS, but other cloud providers should also apply (so this is a general request which applies to all builders)
Use-case: The host is often a docker container with minimal resources, using docker image:
hashicorp/packer:1.4.2for example. In many cases thedocker runcommand is locked down as well.It would be great if you could allow a similar workflow to ebs-builder, except end up with a Docker image being pushed instead of an AMI. That is, instead of provisioning locally, a temporary instance is created in ones' own VPC to do the heavy lifting.
Currently, everything is in place to allow that (if Packer and Docker are pre-installed on the remote instance which does the provisioning), except you are forced to create an AMI you don't care about.
Another use cases, say I need 8GB of RAM to compile something, then it would be useful to be able to use Packer's functionalities to use a tiny 'pilot' CI/CD runner to just run packer, with all heavy lifting done in one's own VPC.