Over here in cloud-land, we periodically need to deploy multiple Urchin installations to a single machine. Some pieces of that puzzle are obvious, but doing it right for a production environment gets tricky.
One major factor is our client’s privacy, but this gets conveniently resolved by another (pre-emptive) security move: chroot jails. Jailing an Urchin installation locks it into its dedicated directory structure. No Urchin user can navigate other parts of the host server, only what the jail contains.
Relocating an Urchin installation is also useful. If a client needs to upgrade to a more powerful server, we can simply copy the entire jail to a bigger host and restart it. Additionally, if a client should desire to move off our platform, we can easily export their Urchin installation (as well as their data) in a rapidly re-deployable fashion.
From a systems administration perspective, “canning” the installations – jailing and storing them in a file-backed virtual filesystem – also refines the update process. Updates can be applied to the jail without effecting the host, and vice versa – vastly simplifying patch management – much like virtualization. The major difference between canning and a virtual machine is that the jail still relies on the host system’s kernel (directly) for memory management and such.