📄️ Getting Started with Cloud Provider Development
In this chapter, we’ll learn how to create a Cloud Provider shell. The goal is to demonstrate the end-to-end cycle, from generating a new shell project to implementing the cloud provider interface and automation processes, as well as testing the shell in CloudShell.
📄️ Creating the Cloud Provider Shell
Before you start, make sure to set up your machine for shell development and implementations, as explained in Getting Started with Cloud Provider Development.
📄️ The Cloud Provider Shell Model
In this article, we’ll learn about the Cloud Provider shell’s model.
📄️ Extending the Shell's Data Model
In this article, we will learn how to add attributes to our shell. For information about modifying or deleting attributes from the shell, scroll down to the bottom of this article.
📄️ Removing the Address Field
For some cloud providers, like AWS EC2 and Azure, the Address field is irrelevant. If this is the case, you can easily remove the field from the shell by setting the hide_address property in the shell-definition.yaml. In the capabilities section, under properties, uncomment the property and set it to true:
📄️ Configuring Deployment Paths
In this article, we’ll learn how to set up the App’s deployment paths.
📄️ Controlling App Deployment Orchestration
In this article, we’ll learn how to customize the App’s behavior during the sandbox’s out-of-the-box Setup process. This article does not apply to Teardown, which by design powers off and deletes the App VMs from the cloud provider.
📄️ The Cloud Provider Interface
The rest of this chapter is dedicated to implementing the cloud provider driver that will be called by the server when interaction with the cloud provider is needed. This includes setting up communication between CloudShell and the cloud provider of choice, implementing the driver commands required from the resource, such as Deploy App, Power On and Refresh IP, and setting the resource’s live status icon (for example, "online” and "offline”).
📄️ Resource Discovery
The get\_inventory command "discovers” the resource in CloudShell, or in other words, validates the values of the cloud provider attributes that were entered by the user. It is executed when creating the resource in CloudShell, and can be manually run later on, for example, if you change some of the resource’s attribute values.
📄️ App Deployment
In this article, we’ll learn how to implement the App’s deployment.
📄️ Power off and Delete VM
In this article, we’ll learn how to implement the PowerOff and DeleteInstance commands, which shut down and delete the VM from the cloud provider, respectively.
📄️ L2 Network Connectivity
Now that we’ve set up the cloud provider shell’s automation, let’s learn how to implement network connectivity. CloudShell supports two networking modes, L2 for VLAN-level management and L3 for subnet-level management. This article discusses layer 2 connectivity. If you’re developing an L3 cloud provider, skip to the next article.
📄️ L3 Network Connectivity
In this article, we’ll learn how to implement L3 network connectivity. Cloudshell recognizes a cloud provider shell as an L3 networking cloud provider if the method PrepareSandboxInfra exists in the shell driver. If the method doesn’t exist, CloudShell considers the shell as an L2 networking shell.