Re: Building cloud images in sandbox VMs
Le 13/10/2017 à 14:49, Noah Meyerhans a écrit : > any further. We will need to look into tools for making new VMs. I wonder what is meant by "making new VM". You do mean creating the disk image for the VM or starting the VM with a tool like virsh? >>> >>> If I recall correctly this is about creating ephemeral vms (possibly from >>> template) on demand to used them as build machines for cloud images. >> >> I had a look at various possible tools which could make that possible, >> here is a short summary. >> If people have more details, please share, not flame. >> >> Background reason: you need root rights for most of the build tools, and >> the cduser on the build server is an unpriviledged user. >> So we want to use sandbox VMs for the builds. > The proposed solutions all assume that the builder VM must reside on > hardware owned by Debian. I assert that this is not necessary, and that > a VM on a cloud platform is sufficient (for that cloud platform's > images, at the very least). Does the builder VM must be reside on hardware owned by Debian ? I though this was somehow a goal we set to label the images as 'official'. But maybe it's enough if the build is taking place in a Debian controlled environment like you mentioned ? I was mostly researching for a replacement for petterson-live (which builds live image and openstack images), so we can non-priveledged VM builds also locally. Emmanuel signature.asc Description: OpenPGP digital signature
Re: Building cloud images in sandbox VMs
On Fri, Oct 13, 2017 at 05:49:48AM -0700, Noah Meyerhans wrote: :$ aws ec2 run-instances --image-id ami-foo \ : --user-data file://ec2-userdata.yaml : :Where the ec2-userdata.yaml contains configuration for cloud-init :telling it how to set up and run FAI and ami-foo is the current public :stretch AMI on AWS. The resulting VM is completely disposable. Any :desired state, from logs to the entire disk image, can be preserved if :desired. : :It should be straightforward to port this to other cloud platforms. If all your provisioning needs can be expressed in cloud-init userdata (which you can do a lot with) this is a most elegant solution and basicly what I use to providion my production work loads on OpenStack and AWS so I can verify at least those two targets will take the exact userdata file happily. Packer (https://www.packer.io/) is a multitarget / multi provisioner system. I use this to customize distro cloud images to our local "base" state using ansible as the provisioning agent can buld multiple cloud targets from one config. If as a distro you are looking to build a very thin config this is probably overkill (and may be over kill in my case too...). Only practial advantages I can say for Packer -v- usedata are it fails if your provisioning errors, it creates teh image artifacte (snapshot, ami, whatever), and cleans up ephemeral VM at the end. My previous image builds never seemed to have enough error checking , I'm not expressly familiar with Debian build error checks. It does snapshot (or what ever the target calls it) to create and image object and tare down the disposable VM it creates in process. Certainly all of these could be handled in user-data. -Jon signature.asc Description: PGP signature
Re: Building cloud images in sandbox VMs
On Fri, Oct 13, 2017 at 01:48:53PM +0200, Emmanuel Kasper wrote: > >> > Building > >> > > >> > >> > any further. We will need to look into tools for making new VMs. > >> I wonder what is meant by "making new VM". > >> You do mean creating the disk image for the VM or starting the VM with > >> a tool like virsh? > > > > If I recall correctly this is about creating ephemeral vms (possibly from > > template) on demand to used them as build machines for cloud images. > > I had a look at various possible tools which could make that possible, > here is a short summary. > If people have more details, please share, not flame. > > Background reason: you need root rights for most of the build tools, and > the cduser on the build server is an unpriviledged user. > So we want to use sandbox VMs for the builds. The proposed solutions all assume that the builder VM must reside on hardware owned by Debian. I assert that this is not necessary, and that a VM on a cloud platform is sufficient (for that cloud platform's images, at the very least). Thus, my preferred solution for creating a builder vm is in essence: $ aws ec2 run-instances --image-id ami-foo \ --user-data file://ec2-userdata.yaml Where the ec2-userdata.yaml contains configuration for cloud-init telling it how to set up and run FAI and ami-foo is the current public stretch AMI on AWS. The resulting VM is completely disposable. Any desired state, from logs to the entire disk image, can be preserved if desired. It should be straightforward to port this to other cloud platforms. noah signature.asc Description: PGP signature
