Deploy Application
Run your application in the cloud by deploying your diagram
Last updated
Run your application in the cloud by deploying your diagram
Last updated
Click the deploy button in the upper right to go to the deployment configuration screen.
Once you are on this screen the architecture diagram is set, and the configurations you make here are tied to an environment. That allows us to deploy the same drawing to multiple environments, each with a distinct configuration.
The top portion of the screen is all about setting up some information about the environment to be created.
Name - an easy-to-remember identifier for the environment. It will be used frequently when constructing cloud-based resources and URLs.
Use case - currently, there is only one use case Saas and it describes the network topology that the environment is deployed into.
Environment Type - this is a tag for the environment and is used as the Kubernetes namespace in which your private services run.
Region - the AWS region into which your environment is launched.
Deploy Target - the AWS account into which this environment should be launched. OpsCanvas deploys your software into your cloud and requires permissions to do so, see the next section for details.
Cloud best practices are to configure an organization to create member accounts for different purposes, e.g. one cloud sub-account for lower (non-prod) environments, and another for production.
Each of these sub-accounts will need to be created as an OpsCanvas deploy target, and chosen at deploy time. Once a deploy target is created, it is associated with the account and can be used to deploy multiple diagrams and environments.
There are 2 steps to create a deploy target, first, download a shell script that needs to be executed in a *nix shell with the latest version of the AWS CLI installed.
Click the link that says +Setup deploy targets, and copy the commands presented into the shell and execute them.
Download the script uses wget to fetch the bash script from our server. The token in the URL can only be used once, and will not be available for download again once the script completes. The parameter -O install.shsaves the file to the directory in which the command is executed.
Verifying the checksum is an optional step to ensure that the file wasn't tampered with during transmission. The long hash is specific to the version of the file that you are currently downloading. In this step, you are using the utilitysha256sumto compute the hash of the file and compare it against the known good value we display. If they match, the file hasn't been tampered with.
Configure execute permissions on the script.
Run the script. The script is interactive and will prompt you for information as it goes.
NOTE: You can inspect the script to see exactly what it's doing, and what permissions are being granted to OpsCanvas
Once the deploy target installation script has been completed, it will be available in the deploy target drop-down. Select the appropriate deploy target for the environment being deployed.
One of the big challenges of authoring IaC is knowing which properties to reference and assigning them appropriate values. OpsCanvas makes this easy with t-shirt-sized deployments. We have a point of view, and we're happy to share it.
The next section of the deployment configuration screen is the t-shirt sizes, each of which represents our opinions on what constitutes "Small", "Medium" and "Large" deployments. Each of these buttons corresponds to a different set of default values that are applied to the services included in your diagram.
The video below shows how the t-shirt sizes impact the way in which the RDS database in the diagram is configured.
NOTE each configuration value can be overridden with any value that makes sense for you. The t-shirt sizes are just meant to provide an easy way to get your environment launched
There are 3 important values that must be set on private services
startup_path - an endpoint that the Kubernetes cluster uses to determine the service has started.
readiness_path - an endpoint that the Kubernetes cluster uses to determine whether the service is ready to accept requests.
liveness_path - an endpoint that the Kubernetes cluster uses to determine whether the service is healthy
The values for each of these paths can be the same, the only requirement is that they return HTTP200 to let the cluster know the service is up & running. A very simple implementation using FastAPI and python may look something like the following
The above endpoint could then be configured as values for all 3 paths.
Each service can be configured with 2 types of variables: Provision vars and Runtime vars.
These are used by OpsCanvas to provision environment infrastructure.
For managed services, these are the properties exposed by the cloud provider for the service in question, e.g. disk space, encrypt at rest, etc.
These are the names & values that will be passed into private services as environment variables, the configuration settings your private service exposes. There are 2 flavors of runtime vars
Literal values - these are values that are recorded either in the diagram's service configuration or overridden in the deployment configuration. They are passed into the service as typed.
Lookup values - these are values that reference managed services that will exist in the environment once they've been deployed, for example, a database password, or s3 bucket name.
You can add runtime vars on the deployment configuration screen, and they won't be saved back to the private service.
Once everything is configured, click the Save and continue button in the lower right of the deployment configuration screen.
Then accept the terms and conditions and select deploy.
