Users of the EGI Cloud create Virtual Machines (VMs) on the providers. Those VMs are started from images: templates for the root volume of the running instances, i.e. operating system and applications available initially on a VM. The AppDB collects the Virtual Machine Images available on the service as Virtual Appliances (VA).
Any user can register new Virtual Appliances at the AppDB, these are then managed by special VO members that curate which appliances are available to their VO.
The AppDB is a browsable catalogue of Virtual Appliances that users can start at the providers. You can find below a set of reference guides for the catalogue:
Packaging your application in a custom VM image is a suggested solution in one of the following cases:
Custom VM images can be crafted in different ways. The two main possibilities are:
In this guide we will focus on the first option, because it tends to produce cleaner images and reduces the risks of hardware conflicts. Snapshotting may be also restricted by the cloud providers or by security policies.
The larger the VM image, the longer it will take to be distributed to the providers and the longer it will take to be started on the infrastructure. As a general rule, always try to make images as smaller as possible following these guidelines:
DO NOT include (big) data in your image. There are other mechanisms for accessing data from your VM (block/object storage, CVMFS)
DO NOT include (big) empty space or swap in your image. Extra space for your computation or swap can be added with block storage once the VM is booted or using VM flavors that have extra disk allocated for your VM.
DO NOT install un-needed software. Tools like GUI are of no-use in most cases since you will have no access to the graphical console of the VM.
DO adjust the size of the images as much as possible. As stated above, empty space can be allocated on runtime easily.
DO use compressed image formats, like qcow2 or vmdk (used in OVA) to minimize the size of the image. Preferred format for images in EGI is OVA as it's standardised.
DO fill with
0 the empty disk space of your image so when compressed it
can be significantly reduced, e.g. using:
dd if=/dev/zero of=/bigemptyfile bs=4096k rm -rf /bigemptyfile
DO use a single partition (no /boot, no swap) for the disk layout and avoid LVM. This will allow the cloud provider to easily resize your partition when instantiated and to modify files in it if needed.
You should never include any kind of credentials on your images, instead you should use contextualization. cloud-init is a tool that will simplify the contextualization process for you. This is widely available as packages in major OS distributions and is supported by all the providers of the EGI Cloud and most of the commercial providers.
cloud-init documentation contains detailed examples on how to create users, run scripts, install packages and several other actions supported by the tool.
For complex setups, especially when applications involve multiple VMs it may be useful to use cloud-init to bootstrap some Configuration Management Software that will manage the configuration of the VMs during runtime.
You should also follow the best practice guides for each service that's exposed to the outside world. See for example guides for:
See also AWS security Best Practices
Whenever possible, automate the process of creating your images. This will allow you to:
EGI uses packer as a tool for automating the creation of our base images. This tool can use VirtualBox as a hypervisor for the creation of the images and guarantees identical results under different platforms and providers.
Check the fedcloud-vmi-templates github repo with all the packer recipes used to build our images and re-use them as needed for your images.