Requirements for Deploying dstack OS on GCP

One of the core design principles of Phala's DStack implementation is the separation of system and application software.
In this implementation, DStack developers focus on developing and releasing system images, while App developers focus on developing applications.
Another option is to package each application with a unique OS Image.

An important distinction between these two approaches is that when system images and application images are released separately, their MRs are also separate. When a system image is released, its MR can be calculated in advance, allowing the system image code to be audited independently.
If application code is bundled into the system image, the MRs become mixed together. When auditing application code, the system layer code must also be audited, which is not acceptable for most simple applications.

To deploy DStack OS on GCP or Azure, we need to address the following requirements:

1. Change the current system image from separate files to a packaged disk image format for easier deployment.
2. Design a new method to transfer application compose files and configuration files.
Currently, DStack's CVM uses shared directories to transfer application compose files and configuration files. We could consider changing this to download from GCP or Azure storage buckets, or from IPFS. This would transform the deployment process to first upload application configurations to a network storage, then use Cloud API to set the file's network address in VM metadata, and after VM startup, retrieve the file's network address from metadata and download the files.
3. Add GCP environment MR calculation logic to the dstack-mr command.