We have a workflow where we regularly want to build an EBS snapshot but not a whole AMI. It would be cool to provide a source AMI to format the EBS volume and bootstrap the snapshot-builder, then when everything is complete, only retain the snapshot of the EBS volume, tag it as desired, then terminate the builder.
joshk0
All 4 comments
That is an interesting use case. Do you just save the root EBS volume?
mitchellh
on 4 Sep 2014
Not the root. In this case, we would want to create a new EBS volume of an arbitrary size, act on it within the packer script, then take a snap of that volume and clean everything up.
joshk0
on 4 Sep 2014
This still sounds like a good idea but hasn't been requested by anyone else. If we see a PR we'd be happy to accept it but due to the low demand, we don't plan on doing this on our own. Thanks!
mitchellh
on 18 Jun 2015
I have a use case in support of this issue.
It would be very useful in maintaining a group of persistant volumes for a cluster of instances that would potentially use automatic scaling groups to increase the number of instances (and therefore persistent volumes) and to ensure that a persistant EBS volume is handed over from a terminated instance to the instance replacing it.
EBS Snapshots are useful to have as a starting template from which to create multiple persistent EBS Volumes (especially due to the fact that they can created EBS Volumes across multiple availablility zones).
The EBS Volume IDs can then be used as a unique filter for startup scripts of the instances to attach to. On initial boot of an instance (as apposed to a recovery boot), an EBS Volume can simply be requested through the relevant Amazon API... whereas a recovery boot could be instructed to attach to a particular EBS Volume.
dnk8n
on 18 May 2017
Related issues
mwhooker
路
3Comments
jesse-c
路
3Comments
PartyImp
路
3Comments
brettswift
路
3Comments
shashanksinha89
路
3Comments
Most helpful comment
I have a use case in support of this issue.
It would be very useful in maintaining a group of persistant volumes for a cluster of instances that would potentially use automatic scaling groups to increase the number of instances (and therefore persistent volumes) and to ensure that a persistant EBS volume is handed over from a terminated instance to the instance replacing it.
EBS Snapshots are useful to have as a starting template from which to create multiple persistent EBS Volumes (especially due to the fact that they can created EBS Volumes across multiple availablility zones).
The EBS Volume IDs can then be used as a unique filter for startup scripts of the instances to attach to. On initial boot of an instance (as apposed to a recovery boot), an EBS Volume can simply be requested through the relevant Amazon API... whereas a recovery boot could be instructed to attach to a particular EBS Volume.