docs/content/sips/001-spin-deploy.md
Summary: A Spin CLI command that will deploy a Spin application to the cloud
Owner: [email protected]
Created: March 18, 2022
Updated: March 31, 2022
A Spin application — (currently described as a spin.toml file) — is a collection of one or more components, each invoked as a result of an event generated by a trigger. The Spin CLI currently enables running a Spin application locally via the spin up command. The Spin CLI also offers a set of commands enabling users to package and push a Spin application to a Bindle registry.
Hippo is a self-hosted, open source, Web Assembly PaaS that allows users to deploy and scale Web Assembly applications. Hippo takes a reference to a bindle, deploys it to the cloud and makes it publicly available. Hippo currently only works with Wagi applications and can currently deploy Wagi applications on a Nomad cluster with Traefik for routing. Additionally, Hippo has a concept called “channels” enabling users to track different version categories of an application (ex. alpha, beta, stable, pre-releases, minor versions, etc.).
A desired feature is to be able to deploy a Spin application to the cloud using Hippo so that it is accessible via a publicly available domain or IP address.
Create a spin deploy command. This command packages a Spin application as a bindle, pushes it to a bindle registry and instructs Hippo to deploy the application to the cloud.
This command needs the following configuration to be passed via either flags or environment variables or config file (config file to be defined at a later date) to deploy the application properly and to the right place:
Hippo authentication information. A token is needed to communicate with the Hippo server. This can be retrieved either from requesting it from the Hippo server with a username and password, from the Hippo config file on the system (if a user has already logged in) or from the user if they already know the token information. The following flags and environment variables support authenticating with Hippo.
The --hippo-token flag cannot be set in combination with the --hippo-username and --hippo-password flags. If so, Spin will return an error. If the username/password flags are set, Spin will request a token from the Hippo server and use it. If the username flag was provided but the password was not, Spin will prompt the user for a password. If none of the Hippo auth flags are provided, Spin will find the Hippo token in the Hippo config file on disk. If Hippo cannot find the file or the token in the file is expired, Spin will prompt the user for username/password.
As part of the deploy flow, Spin will:
In order to use the spin deploy command, a user must already have Hippo installed and running using the nomad scheduler and a bindle url.
A bindle is immutable once pushed and the tag cannot be overwritten. Therefore, we'll need a way to construct unique tags. One way to do this is to hash the bindle invoice that is generated. Note: I believe Hippo only allows semver versions though and in that case, this would not work or we'd need to see if we can make Hippo pick up non-semver bindle tags.
The following is a list of assumptions we are making about the Hippo platform that we would need to build in order for this command to work.
In the future, we should make this command a plugin for the Spin CLI. People may not want to use the Spin deploy command to deploy to Hippo. They may want to deploy to a different target using a different platform. They should be able to do that via plugins. However, there is no plugin system in Spin at this time and that may require further debate and discussion and consideration, so it's best to continue with spin deploy as a built-in subcommand for the time being to be focused about the scope of work.