Confirmed users
396
edits
Webdev:DevBoxVMImages: Difference between revisions
→Building a plain VM: OVA explained
LesOrchard (talk | contribs) |
(→Building a plain VM: OVA explained) |
||
| (13 intermediate revisions by 4 users not shown) | |||
| Line 4: | Line 4: | ||
of our websites. That way, a new contributor can focus on contributing, | of our websites. That way, a new contributor can focus on contributing, | ||
rather than learning how to install and configure a website first. | rather than learning how to install and configure a website first. | ||
A second use case is continuous integration against a VM hosted environment. As | |||
a first stab, we're using a vagrant based VM. We'll refer to this as CI use case below. | |||
== Open questions == | == Open questions == | ||
| Line 15: | Line 18: | ||
** How would this work? Seems resource intensive | ** How would this work? Seems resource intensive | ||
** See also: {{bug|670471}} - [tracker] set up jenkins job to export socorro vagrant VM | ** See also: {{bug|670471}} - [tracker] set up jenkins job to export socorro vagrant VM | ||
=== Is Vagrant the right tool (vs libcloud)? === | |||
* Seems like I'm fighting against some of the core Vagrant features, eg: | |||
** Shared folder from Host to VM | |||
** Custom box format rather than straight VM appliance or image | |||
** For CI case, we want vanilla Vagrant behaviors, but libcloud thingie would work too | |||
* [http://libcloud.apache.org/getting-started.html libcloud]+Puppet better than Vagrant+Puppet? | |||
** libcloud could [https://bitbucket.org/ianb/libcloud-vbox target VirtualBox] locally and Rackspace / Amazon EC2 remotely | |||
** Generate self-contained VMs with source included | |||
=== Vagrantfile as part of project, or separate repo? === | === Vagrantfile as part of project, or separate repo? === | ||
| Line 26: | Line 38: | ||
=== Code on host or in VM? === | === Code on host or in VM? === | ||
* Vagrant wants to wrap a VM around a directory of source on the Host. | * Vagrant wants to wrap a VM around a directory of source on the Host. | ||
** Can use familiar tools, etc | |||
** Shared folders from VBox to Host are slow; NFS is faster but not available to Windows. | |||
* Better if the source for the project were <code>git clone</code>'ed inside the VM and shipped along with the image? | * Better if the source for the project were <code>git clone</code>'ed inside the VM and shipped along with the image? | ||
** No more shared folder from host to VM. | ** No more shared folder from host to VM. | ||
** Would need to install Samba inside VM to edit code from host. | ** Would need to install Samba inside VM to edit code from host. | ||
*** That's one of the major benefits of Vagrant | |||
** Need to configure and use <code>git</code> or <code>svn</code> inside VM | ** Need to configure and use <code>git</code> or <code>svn</code> inside VM | ||
*** Might be a bummer, might help contributors have a consistent revision control scenario | |||
*** eg. <code>~/.gitconfig</code> with contributor's name and email, etc | |||
** Need instructions advising a <code>git pull</code> after initial boot-up | ** Need instructions advising a <code>git pull</code> after initial boot-up | ||
** Vagrant defaults are probably fine for CI use case | |||
=== Blank slate content === | === Blank slate content === | ||
* See also: https://landfill.addons.allizom.org/db/ | |||
* Need to import / generate some sample data / content to make the site useful | * Need to import / generate some sample data / content to make the site useful | ||
* Anonymized export from prod? | * Anonymized export from prod? | ||
| Line 40: | Line 59: | ||
* Synthetic test data | * Synthetic test data | ||
** Need to hand-maintain | ** Need to hand-maintain | ||
** CI use case provides test data | |||
=== Local hardware vs Rackspace VM? === | |||
* Running a VM image oneself needs a capable machine | |||
** Might not be an option for a MacBook Air or netbook owner | |||
* Running a VM on Rackspace costs $$$ | |||
** How to get an image loaded into a Rackspace VM? | |||
* CI use case requires Jenkins server to be able to run Vagrant | |||
** Finding the right mix of CentOS / Ruby / vagrant gem / VirtualBox is challanging | |||
== Participating sites == | == Participating sites == | ||
* AMO? | * AMO? | ||
* SUMO | * SUMO | ||
** https://github.com/aclark4life/kitsune-vagrant | |||
* Socorro | * Socorro | ||
* Mozillians | * Mozillians | ||
* MDN? | * MDN? | ||
** Need proper hosting | ** Need proper hosting | ||
| Line 54: | Line 83: | ||
* AUS | * AUS | ||
* Graphserver | * Graphserver | ||
* sasl-browserid | |||
== Maintaining VM images == | == Maintaining VM images == | ||
| Line 61: | Line 91: | ||
Jenkins. | Jenkins. | ||
=== Building a plain VM === | |||
Here's the general process for building a plain VM by hand, without using Vagrant: | |||
* Grab an ISO of your base OS. (eg. MDN is using CentOS) | |||
* Create a VirtualBox VM. | |||
* Install the bare minimum of server packages. | |||
** You might want to export an OVA (Open Virtualization Format archive) of this base install for future from-scratch builds. | |||
* Create a [https://raw.github.com/mozilla/kuma/HEAD/scripts/rackspace-bootstrap.sh bootstrap script] that gets Puppet installed and prepares a git clone of the project's source | |||
* As root, run <code>puppet apply /vagrant/puppet/manifests/dev-vagrant.pp</code> (or whatever you named it) | |||
* Once Puppet has finished, verify that the project is working. | |||
* Shutdown the VM and export an OVA | |||
* Upload the exported appliance to hosting | |||
With some more thinking, much or most of the above could be automated using libcloud or VBoxManage | |||
=== Building a Vagrant box === | |||
Needs work: | |||
* Use <code>vagrant destroy && vagrant up</code> to spin up a VM in VirtualBox | * Use <code>vagrant destroy && vagrant up</code> to spin up a VM in VirtualBox | ||
* Build Puppet manifests to install packages and configure the VM with a running site | * Build Puppet manifests to install packages and configure the VM with a running site | ||
** If set up by hand, then it will always need to be done by hand. | |||
** If automated by Puppet manifests or other scripts, then it can be run by machine | |||
** Do whatever is expedient, since the VM images are the important thing | |||
** Someday, it might be nice to steal whatever Puppet manifests IT uses, though. | |||
* Use <code>vagrant package</code> to extract a <code>{sitename}.box</code> image, once the site is verified to be running. | * Use <code>vagrant package</code> to extract a <code>{sitename}.box</code> image, once the site is verified to be running. | ||
* Upload the exported <code>{sitename}.box</code> image to hosting site for download. | * Upload the exported <code>{sitename}.box</code> image to hosting site for download. | ||
| Line 79: | Line 131: | ||
== Hints, tips, HOWTOs == | == Hints, tips, HOWTOs == | ||
===Guest Machine Loses Internet Access=== | |||
If your host machine changes network address while the guest machine is up, the guest machine will lose 'net access. Restart the guest machine to fix. | |||