Using Vespa Cloud for development is easy. See getting started to make your first deployment.
Each deployment of an application to the dev
zone is a separate instance
of the application. Using multiple instances lets developers work with the same application
separately or collaboratively as they prefer.
Consider the deploy command:
$ mvn clean package vespa:deploy -DapiKeyFile=/path-to/uname.tname.pem \ -Denvironment=dev \ -Dregion=aws-us-east-1c \ -Dtenant=mytenant \ -Dapplication=vespacloud-docsearch \ -Dinstance=myuser
This is equivalent to the vespa:deploy
used in the getting started page:
environment
and region
defaults to the dev
zone.
tenant
and application
is normally set in pom.xml
.
instance
must be set and can be anything, e.g a user, experiment or team name.
Deployments to dev are downscaled to one small node by default so that prod
applications can be deployed without changing services.xml.
If you need more resources in the dev application, set nodes or resources
explicitly by adding those tags to services.xml with a
deploy:environment="dev"
,
see variants in services.xml.
The dev
zone is not for production serving, and has no uptime guarantees.
An automated Vespa software upgrade can be triggered by vespa:deploy
and that may lead to some downtime if you have only one node per cluster
(as with the default auto downsizing).
To override the version, use
-Dvespa.runtime.version=<current deployed version>
when deploying.
In addition to dev
there is also a perf
zone for performance testing.
This does less downscaling of resources, such that tests that can be extrapolated to production
are possible. In other ways this zone works the same way as dev. To deploy to perf, use
-Denvironment=perf
Read more in benchmarking.
As Vespa Cloud upgrades daily, a deploy will some times pull the latest Vespa Version. This takes minutes as opposed to the seconds it normally takes. Start the day by deploying to avoid the wait!
A common mistake is pom.xml
mismatch. tenant
and application
is normally pulled from the pom -
details.
Errors here cause a 401 when deploying.
Likewise for data plane -
remember to copy the public sertificate to src/main/application/security/clients.pem
before building and deploying.
Set all keys in the IDE:
-Dtest.categories=system -DapiKeyFile=/path-to/uname.tname.pem -DdataPlaneCertificateFile=/path-to/data-plane-public-cert.pem -DdataPlaneKeyFile=/path-to/data-plane-private-key.pem