cloudlet - readthedocs.org
Embed Size (px)
TRANSCRIPT
cloudletIntroduction
1 Cloudlet Overview 1 1.1 High Level Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Deployment model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Trusted Cloudlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7 Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Implementations 7 2.1 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Services 13 3.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Sub Systems 25 4.1 Cloudlet Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Data Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Federated Orchestrated Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.6 Trust Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Actors 57 5.1 Application Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Actor Operations Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Actor Stack Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Use Cases 67 6.1 Manage Cloudlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2 Manage Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.3 Manage Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.4 Manage Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.5 Use Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
i
ii
CHAPTER 1
Cloudlet Overview
The Cloudlet Architecture enables the connection of multiple data centers, devices, remote locations or edge devices to be managed and utilized as one cloud ecosystem. The architecture describes the Use Cases, Actors, and subsystems that define the cloudlet architecture. The C3 architecture is used as the base to the Cloudlet architecture.
1.1 High Level Use Case
• Manage Cloudlet - Manage Cloudlets to Cloud helps setup the federation of clouds.
• Manage Policies - Manage policies that apply to the federation and to specific clouds or data centers
• Manage Services - Register a service in the cloud federation.
• Use Service - Use a service in the federation. This could use a service in the local or one of the remote clouds.
cloudlet
1.3 Logical Architecture
The Cloudlet Architecture contains a small set of services that establishes a federation of cloud by standardizing on a common CMP layer from the Hybrid Cloud architecture. Each cloud has a Cloudlet Manager Service running that will help establish the federations between the clouds. Coordination between the Clouds in the Federation will be handled by a set of services that give the federation connectivity, security and manageability. This same architecture has been extended to Edge and Cloud connectivity in the cases that an edge device includes the minimal “micro” cloud architecture. The C3 architecture is the base to this architecture.
• Trust Manager - Manages Securee keys in TPMs across multiple data centers.
• Cloudlet Manager - Each Cloud Has a Cloudlet manager that becomes part of the Federation
• Data Coordinator - Coordinates data between Clouds
• Federated Orchestrated Cloud - Federated Orchestrated to schedule service requests acrosss multiple clouds
• Identity Manager - Manages Identity across multiple clouds
• Telemetry - Aggregates Telemetry before sharing the telemetry to the other cloudlets.
• C3 - This is a common hybrid cloud architecture that must be present in each cloud. The key elements that must be there are a Cloud management platform, an automation framework, and a platform as a service framework. This a requirement of the architecture not part of the architecture.
1.4 Process Architecture
There are several activities that an Operations Manager performs with the Cloudlet Architecture including: Setting up the federation of clouds to form cloudlets, Establishing Local and Global (Federated Policies), Creating Secure geo-fenced domains, and updating and patching infrastructure across the cloudlets.
1.3. Logical Architecture 3
1.5 Deployment model
The Cloudlet architecture should be as light weight as possible and should integrate existing infrastructure and systems with minimal impact on the current system. Existing cloud installations are used to handle the heavy lifting in the system. The cloudlet architecture requires a hybrid cloud architecture that includes Cloud Management Platform, Automation Framework & Platform as a Service, or the functions defined in those sets of tools.
The Cloudlet Architecture has a Cloudlet Manager is that placed as a connectivity layer between the hybrid cloud and the Federated Connectivity. The connectivity gives all of the functionality that is needed to federate the different
4 Chapter 1. Cloudlet Overview
cloudlet
clouds systems together. This let’slets the cloud operate independently from other cloud(s). Allowing for them to operate in a disconnected or semi-connected state.
1.6 Trusted Cloudlets
Setting up a cloudlet architecture does not mean they are secure or trusted. Trusted Cloudlets give the ability to set up a trusted federation of cloud and to segment that federation with geo fencing technology using Intel CIT, TXT and TPMs. Intel TXT and CIT technologies provide the trusted launch and attestation of the cloud workloads and infrastructure. Overall trust and security in a cloud computing infrastructure must begin with the servers and base compute systems. The basic elements of this trusted platform span hardware, firmware, and software to provide the best balance of tamper-resistance and functionality.
In this example Each cloud has a geo fenced data set that can be shared with other clouds but not all of the clouds.
1.6. Trusted Cloudlets 5
1.7 Physical Architecture
The goal of the architecture is to connect multiple clouds together that are scattered across an organization. This could be physically as well as logically. There is the concept of a base Cloud that could offer multiple clouds and remote clouds named cloudlets.
6 Chapter 1. Cloudlet Overview
CHAPTER 2
2.1 Solution Overview
Cloudlets represent an architecture of federated cloud that have a CMP+Automation+PaaS+CloudOS bundle as de- scribed in the C3 architecture. The architecture targets cloud operations managers and should be as transparent to the end user and developer as possible.
2.1.1 High Level Use Case
• Manage Cloudlet
• Manage Policies
• Manage Services
• Use Service
• Actor Operations Manager
• Actor Stack Developer
2.1.3 Logical Architecture
What is the smallest size of the data for a cloudlet to: Authenticate all users in the cloud federation All other data required to run any job or at least start a job remotely.
8 Chapter 2. Implementations
This should help answer the storage requirements for the Cloudlet.
Where is data impacted: 1. Data Latency? 1. Does data Gravity have a big play 1. What VMs do you want localized 1. What images are required on the Remote Clouds 1. Updates to Cloudlets.
• Cloudlet Manager - Each Cloud Has a Cloudlet manager that becomes part of the Federation
• Federated Orchestrated Cloud - Federated Orchestrated to schedule service requests acrosss multiple clouds
• Data Coordinator - Coordinates data between Clouds
• Identity Manager - Manages Identity across multiple clouds
• Trust Manager - Manages Securee keys in TPMs across multiple data centers.
• Telemetry - Aggregates Telemetry before forwarding it own to a cloudlet telemetry
• C3 - Common Cloud Core including a Cloud Management Platform
2.1.4 Process Architecture
There are several activities that an Operations Manager performs with the Cloudlet Architecture including: Setting up the federation of clouds to form cloudlets, Establishing Local and Global (Federated Policies), Creating Secure geo-fenced domains, and updating and patching infrastructure across the cloudlets.
2.1. Solution Overview 9
2.1.5 Deployment model
The Cloudlet architecture should be as light weight as possible and should integrate existing infrastructure and systems with minimal impact on the current system. Existing cloud installations are used to handle the heavy lifting in the system. The cloudlet architecture requires a hybrid cloud architecture that includes Cloud Management Platform, Automation Framework & Platform as a Service, or the functions defined in those sets of tools.
The Cloudlet Architecture has a Cloudlet Manager is that placed as a connectivity layer between the hybrid cloud and the Federated Connectivity. The connectivity gives all of the functionality that is needed to federate the different clouds systems together. This let’slets the cloud operate independently from other cloud(s). Allowing for them to
10 Chapter 2. Implementations
2.1.6 Physical Architecture
The goal of the architecture is to connect multiple clouds together that are scattered across an organization. This could be physically as well as logically. There is the concept of a base Cloud that could offer multiple clouds and remote clouds named cloudlets.
2.1. Solution Overview 11
Services
These are the micro-services of the cloudlet Solution that are used to implement the solutions.
3.1 Services
The system is implemented using micro-services that are deployed across a cloudified architecture.
3.1.1 cloudlet-manager
Use Cases
Deployment Architecture
This is the deployment of the micro-service. The micro-service is deployed when trigger and should scale from # to # based on condition. The micro-service is deployed with the imagename image. The ports exposed are 5000 for external and 3000 for internal.
16 Chapter 3. Services
Physical Architecture
The micro-services are physically deployed on to a hybrid cloud infrastructure.
3.1. Services 17
Use Cases
Deployment Architecture
This is the deployment of the micro-service. The micro-service is deployed when trigger and should scale from # to # based on condition. The micro-service is deployed with the imagename image. The ports exposed are 5000 for external and 3000 for internal.
3.1. Services 21
Physical Architecture
The micro-services are physically deployed on to a hybrid cloud infrastructure.
22 Chapter 3. Services
These are the high level Subsystems of the cloudlet Solution
4.1 Cloudlet Manager
The Cloudlet Manager is responsible for connecting a “Cloud” into the Cloud Federation. Once the Cloud is connected to th Cloud Federation it will be known as a Cloudlet in that federation.
25
cloudlet
cloudlet
cloudlet
cloudlet
4.1.8 Physical Architecture
4.2 Data Coordinator
Data Coordinator is a subsystem of Cloudlet architecture and is responsible for coordinating data between the clouds. This is for data that can be moved between data centers based on policies and bandwidth capabilities.
Typical data that should be shared between Data Centers are
• Service Images
• Service Templates
• Application Templates
• Shared Registries
• Application Data
The Data Coordinator is responsible for creating secure domains between the multiple Cloudlets and moving data or applications between the Cloudlets. It will work with the Trust Manager to establish geofenced federated secure domains that the data can freely move.
There are three modes that the Data Coordinator can use to move data or applications. 1. Data Movement - Move data between the Cloudlets 1. Data Exchange - Split and application into multiple services and distribute the services on the different cloudlets. 1. App Movement - Move an application to the Data.
4.2.1 Use Cases
cloudlet
• Portal - Web Portal
4.2.5 Logical Artifacts
• Data Mover - Moves data between trusted geofenced secure domains between the Cloudlets.
• Application Mover - Find the data required for the application and moves the application to the proper Cloudlet.
• Data Exchange - Create a results Agregator and sets up the Data Exchange Source micro-services in each Cloudlet.
4.2. Data Coordinator 33
cloudlet
4.3 Federated Orchestrated Cloud
Federated Orchestrated Cloud is a subsystem of the Cloudlet Architecture. The Federated Orchestrated Cloud (FOC) is responsible for coordinating service requests between the clouds. It has three major components. SNAP, Analytics and and Orchestrator. The FOC should be the majority of the added integration required for the federation.
4.3. Federated Orchestrated Cloud 35
cloudlet
cloudlet
4.3.5 Logical Artifacts
Information from the analytics. Would be used to determine what services should be on the cloud. It will also determine what pre-staged Images or VMs would be best on the Cloud. This information is dynamic.
A cloud is responsible for itself. Other clouds cannot push jobs or services to a cloud. A Cloud pulls services/data/ etc.. From other clouds and makes the services available
Policy will determine how often a Service will be removed from the Cloudlet and force other Cloudlets to use the Cloud.
4.3. Federated Orchestrated Cloud 37
cloudlet
cloudlet
4.4. Identity Manager 39
cloudlet
cloudlet
4.5. Telemetry 43
cloudlet
4.5. Telemetry 45
4.5.7 Deployment Architecture
This subsystem is deployed using micro-services as shown in the diagram below. The ‘micro’ module is used to implement the micro-services in the system. The subsystem also has an CLI, REST and Web Interface exposed through a sailajs application. The sailsjs application will interface with the micro-services and can monitor and drive work-flows through the mesh of micro-services.
46 Chapter 4. Sub Systems
cloudlet
4.5.8 Physical Architecture
The Telemetry subsystem is is physically laid out on a hybrid cloud infrastructure. Each microservice is shown how they connect to each other. All of the micro-services communicate to each other and the main app through a REST interface. A CLI, REST or Web interface for the app is how other subsystems or actors interact. Requests are forwarded to micro-services through the REST interface of each micro-service.
4.5. Telemetry 47
4.6 Trust Manager
Setting up a cloudlet architecture does not mean they are secure or trusted. Trusted Cloudlets give the ability to set up a trusted federation of cloud and to segment that federation with geo fencing technology using Intel CIT, TXT
48 Chapter 4. Sub Systems
cloudlet
and TPMs. Intel TXT and CIT technologies provide the trusted launch and attestation of the cloud workloads and infrastructure. Overall trust and security in a cloud computing infrastructure must begin with the servers and base compute systems. The basic elements of this trusted platform span hardware, firmware, and software to provide the best balance of tamper-resistance and functionality.
Intel Trusted Execution Technology (TXT) is available with servers featuring the Intel® Xeon® processor E3, E5, and E7 families. Platform-level enhancements provide the building blocks to enable visibility, trust, and control in the cloud.
Intel TXT is a combination of hardware and software aimed at securing the execution of sensitive workloads. In contrast to solutions that protect the Operating System, Intel TXT builds a chain of trust from the system firmware all the way to the server or hypervisor to prevent attacks on system firmware or BIOS, MBR, boot loader, OS and hypervisor. Every component in this chain is verified against known good states and, depending on the result, marked either trusted or untrusted.
4.6. Trust Manager 49
cloudlet
This approach allows detection of not only threats to the OS itself, such as viruses, but also attacks on the configuration and even manipulation of the server’s boot firmware and hardware. When a breach is detected, workloads that require secure execution cannot be executed on this server.
50 Chapter 4. Sub Systems
cloudlet
Designed to measure the execution environment and protect sensitive information from attacks, it operates with Trusted Platform Module (TPM), an industry-standard device that can securely store artifacts used to verify integrity of the platform Hardware-based root of trust—when coupled with an enabled operating system, hypervisor, and solutions—is the foundation for a more secure computing platform that can ensure hypervisor and VMM integrity at boot from rootkits or other low-level attacks. It establishes the trust-worthiness of the server and host platforms. The hardware- based root of trust uses open industry standards developed by Trusted Computing Group (TCG) to establish and ensure platform trust and store measurements in a TPM.
The solution works by providing a root of trust—a processor-based, tamper-resistant environment that compares firmware, BIOS, and operating system or hypervisor code to known good configurations to establish a measured, trusted environment prior to launch. If integrity and trust are not verified in the launch process, Intel TXT identifies that the code has been compromised, which lets you protect the system and remediate the problem. Because Intel TXT can evaluate and report on platform integrity using attestation mechanisms, it can provide valuable insights and controls when used in the context of cloud computing models. This allows other key software—virtualization, cloud orchestration and management, and security policy applications—to understand and use platform integrity attributes to control workloads and data and better address security risks by keeping sensitive or regulated workloads separate from platforms with unknown integrity status. This is a concept that Intel and like-minded solution companies call Trusted Compute Pools.
Trustable pools created using Intel® Trusted Execution Technology (Intel® TXT)-enabled platforms help ensure safe migration between hosts.
4.6. Trust Manager 51
cloudlet
Intel OpenCIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters. The solution leverages Intel processors with Intel® Trusted Execution Technology (Intel® TXT) to establish HW root of trust and builds the chain of trust across hardware, OS, hypervisor, vm and docker container and including asset tagging for Location and boundary control. The Platform trust and asset tag attestation information is used by Orchestrators and/or Policy Compliance management to ensure workloads are launched on trusted and location/boundary compliant platforms, and they provide the needed visibility and Auditability of your infrastructure in both public and private cloud environments.
In this example each cloud has a geo fenced data set that can be shared with other clouds but not all of the clouds. This gives an example of “virtual” air-gapping classifications of data in the same datacenter and even across the multiple clouds and tactical edges.
In this example data can only be moved and unencrypted in the geoB geo-fence between the Cloud, Cloudlet1 and Cloudlet2. This also prevents man in the middle attacks because the cloudlets are attested and trusted between them- selves. Since the trusted keys are stored in secure TPMs on physical machines in each “cloudlet”, only the physical machines with the appropriate keys can encrypt and decrypt the data, vms, or containers moving between the physical machines, using Intel’s TXT and CIT technologies.
4.6.1 Use Cases
cloudlet
cloudlet
CHAPTER 5
5.1 Application Developer
The Application Developer develops cloud aware applications. This is the same actor as in the C3 architecture which can be found in the architect C3-App-Dev .
5.1.1 Use Cases
5.1.2 Activities
Application Developer will typically use existing services as well as develop new services. In order to use existing services they can look up the services or service stacks in the Cloudlet service registry either locally or globally. One the service or service stacks is selected. It can be used by the Application Developer to developer their application.
If the service or service stack cannot be found then the Application Developer can create a new service in the cloudlet federation. They first need to request infrastructure to build the new service. Then they build the service and then add it to the cloudlet federation. The service could be local or global in the federation.
5.1.3 Workflow
Propagation of activities to the underlying C3 architecture is normal mode of operation.
58 Chapter 5. Actors
5.2 Actor Operations Manager
The Operation Manager is responsible for managing the operations of the system. This includes the creation and management of environments, users, and connectivity to the Clouds.
This is the same Operations Manager as defined in the CAADE Architecture. Click here to see the base Operation Manager Specification.
5.2.1 Use Cases
• Manage Cloudlet
• Manage Policies
5.2.2 Activities
The Operations Manager focuses on the management of the cloudlet federation and the establishment of the federation through adding cloudlets to the federation, adding policies to the federation, managing infrastructure and managing the cloudlets.
60 Chapter 5. Actors
5.2.3 Workflow
Before the Cloudlet can be used the Cloudlet service needs to be installed for the C3 instance. Once it has been installed the cloudlet is registered with other cloudlets to form the federation. Once the federation has been formed the Operations Managaer can perform day to day operations, such as managing infrastructure and policies.
5.2. Actor Operations Manager 61
cloudlet
The Stack Developer is responsible for developing Application Stacks and Service Templates This includes developing the configurations of services and applications for multiple environments and clouds.
This is the same Operations Manager as defined in the CAADE Architecture. Click here to see the base Operation Manager Specification.
5.3.1 Use Cases
• Manage Services
• Use Service
5.3.2 Activities
All activities by the stack developer are proxies to the C3 Architecture. The Stack Developer is not a primary user of the Cloudlet. It is basically a passthru layer that allows the connection and then propigation of services and stacks to all of the Clouds in the cloudlet.
5.3. Actor Stack Developer 63
5.3.3 Workflow
As the stack developer makes changes to services and application stacks those changes are propagated to remote cloudlets or to a centralized repository that all remote cloudlets can access.
64 Chapter 5. Actors
cloudlet
68 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Add Cloudlet Scenario.
# cloudlet cloudlet add <parameters> # cloudlet cloudlet add exmaple
Web Interface
This is a mock up of the Web Interface for the Add Cloudlet Scenario.
REST
cloudlet/add
6.1. Manage Cloudlet 69
CLI
This is the command line interface for the List Cloudlet Scenario.
# cloudlet cloudlet list <parameters> # cloudlet cloudlet list exmaple
Web Interface
This is a mock up of the Web Interface for the List Cloudlet Scenario.
REST
cloudlet/list
cloudlet
Monitor Cloudlet
CLI
This is the command line interface for the Monitor Cloudlet Scenario.
# cloudlet cloudlet monitor <parameters> # cloudlet cloudlet monitor exmaple
Web Interface
This is a mock up of the Web Interface for the Monitor Cloudlet Scenario.
6.1. Manage Cloudlet 71
cloudlet/monitor
Remove Cloudlet
CLI
This is the command line interface for the Remove Cloudlet Scenario.
# cloudlet cloudlet remove <parameters> # cloudlet cloudlet remove exmaple
Web Interface
This is a mock up of the Web Interface for the Remove Cloudlet Scenario.
72 Chapter 6. Use Cases
cloudlet
REST
cloudlet/remove
6.2 Manage Infrastructure
CLI
This is the command line interface for the Release Compute Scenario.
# cloudlet compute release <parameters> # cloudlet compute release exmaple
Web Interface
This is a mock up of the Web Interface for the Release Compute Scenario.
74 Chapter 6. Use Cases
cloudlet
REST
compute/release
Release Network
CLI
This is the command line interface for the Release Network Scenario.
# cloudlet network release <parameters> # cloudlet network release exmaple
6.2. Manage Infrastructure 75
Web Interface
This is a mock up of the Web Interface for the Release Network Scenario.
REST
network/release
Release Storage
CLI
This is the command line interface for the Release Storage Scenario.
76 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Release Storage Scenario.
REST
storage/release
Request Compute
6.2. Manage Infrastructure 77
cloudlet
CLI
This is the command line interface for the Request Compute Scenario.
# cloudlet compute request <parameters> # cloudlet compute request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Compute Scenario.
REST
compute/request
78 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Request Network Scenario.
# cloudlet network request <parameters> # cloudlet network request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Network Scenario.
REST
network/request
Request Storage
CLI
This is the command line interface for the Request Storage Scenario.
# cloudlet storage request <parameters> # cloudlet storage request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Storage Scenario.
80 Chapter 6. Use Cases
cloudlet
REST
storage/request
6.3 Manage Policies
CLI
This is the command line interface for the Create Policy Scenario.
# cloudlet policy create <parameters> # cloudlet policy create exmaple
Web Interface
This is a mock up of the Web Interface for the Create Policy Scenario.
REST
82 Chapter 6. Use Cases
cloudlet
policy/create
Destroy Policy
CLI
This is the command line interface for the Destroy Policy Scenario.
# cloudlet policy destroy <parameters> # cloudlet policy destroy exmaple
Web Interface
This is a mock up of the Web Interface for the Destroy Policy Scenario.
6.3. Manage Policies 83
policy/destroy
Evaluate Policy
CLI
This is the command line interface for the Evaluate Policy Scenario.
# cloudlet policy evaluate <parameters> # cloudlet policy evaluate exmaple
84 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Evaluate Policy Scenario.
REST
policy/evaluate
List Policy
CLI
This is the command line interface for the List Policy Scenario.
6.3. Manage Policies 85
Web Interface
This is a mock up of the Web Interface for the List Policy Scenario.
REST
policy/list
Manage Federated Policies
Manage Federated Policies using CLI and Web Interface with . . . <parameters>
86 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Manage Federated Policies Scenario.
# cloudlet federated manage <parameters> # cloudlet federated manage exmaple
Web Interface
This is a mock up of the Web Interface for the Manage Federated Policies Scenario.
REST
federated/manage
6.3. Manage Policies 87
Manage Local Policies using CLI and Web Interface with . . . <parameters>
CLI
This is the command line interface for the Manage Local Policies Scenario.
# cloudlet local manage <parameters> # cloudlet local manage exmaple
Web Interface
This is a mock up of the Web Interface for the Manage Local Policies Scenario.
REST
local/manage
cloudlet
6.4 Manage Services
6.4. Manage Services 89
cloudlet
CLI
This is the command line interface for the Add Service Scenario.
# cloudlet service add <parameters> # cloudlet service add exmaple
Web Interface
This is a mock up of the Web Interface for the Add Service Scenario.
REST
service/add
90 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Create Service Scenario.
# cloudlet service create <parameters> # cloudlet service create exmaple
Web Interface
This is a mock up of the Web Interface for the Create Service Scenario.
REST
service/create
List Service
CLI
This is the command line interface for the List Service Scenario.
# cloudlet service list <parameters> # cloudlet service list exmaple
Web Interface
This is a mock up of the Web Interface for the List Service Scenario.
92 Chapter 6. Use Cases
cloudlet
REST
service/list
Remove Service
CLI
This is the command line interface for the Remove Service Scenario.
# cloudlet service remove <parameters> # cloudlet service remove exmaple
Web Interface
This is a mock up of the Web Interface for the Remove Service Scenario.
6.4. Manage Services 93
service/remove
6.5 Use Service
cloudlet
CLI
This is the command line interface for the Deploy Service Scenario.
# cloudlet service deploy <parameters> # cloudlet service deploy exmaple
Web Interface
This is a mock up of the Web Interface for the Deploy Service Scenario.
6.5. Use Service 95
service/deploy
Launch Service
CLI
This is the command line interface for the Launch Service Scenario.
# cloudlet service launch <parameters> # cloudlet service launch exmaple
96 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Launch Service Scenario.
REST
service/launch
Monitor Service
CLI
This is the command line interface for the Monitor Service Scenario.
6.5. Use Service 97
Web Interface
This is a mock up of the Web Interface for the Monitor Service Scenario.
REST
service/monitor
98 Chapter 6. Use Cases
cloudlet
1 Cloudlet Overview 1 1.1 High Level Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Deployment model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Trusted Cloudlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7 Physical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Implementations 7 2.1 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Services 13 3.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Sub Systems 25 4.1 Cloudlet Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Data Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Federated Orchestrated Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.6 Trust Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Actors 57 5.1 Application Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Actor Operations Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Actor Stack Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Use Cases 67 6.1 Manage Cloudlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2 Manage Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.3 Manage Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.4 Manage Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.5 Use Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
i
ii
CHAPTER 1
Cloudlet Overview
The Cloudlet Architecture enables the connection of multiple data centers, devices, remote locations or edge devices to be managed and utilized as one cloud ecosystem. The architecture describes the Use Cases, Actors, and subsystems that define the cloudlet architecture. The C3 architecture is used as the base to the Cloudlet architecture.
1.1 High Level Use Case
• Manage Cloudlet - Manage Cloudlets to Cloud helps setup the federation of clouds.
• Manage Policies - Manage policies that apply to the federation and to specific clouds or data centers
• Manage Services - Register a service in the cloud federation.
• Use Service - Use a service in the federation. This could use a service in the local or one of the remote clouds.
cloudlet
1.3 Logical Architecture
The Cloudlet Architecture contains a small set of services that establishes a federation of cloud by standardizing on a common CMP layer from the Hybrid Cloud architecture. Each cloud has a Cloudlet Manager Service running that will help establish the federations between the clouds. Coordination between the Clouds in the Federation will be handled by a set of services that give the federation connectivity, security and manageability. This same architecture has been extended to Edge and Cloud connectivity in the cases that an edge device includes the minimal “micro” cloud architecture. The C3 architecture is the base to this architecture.
• Trust Manager - Manages Securee keys in TPMs across multiple data centers.
• Cloudlet Manager - Each Cloud Has a Cloudlet manager that becomes part of the Federation
• Data Coordinator - Coordinates data between Clouds
• Federated Orchestrated Cloud - Federated Orchestrated to schedule service requests acrosss multiple clouds
• Identity Manager - Manages Identity across multiple clouds
• Telemetry - Aggregates Telemetry before sharing the telemetry to the other cloudlets.
• C3 - This is a common hybrid cloud architecture that must be present in each cloud. The key elements that must be there are a Cloud management platform, an automation framework, and a platform as a service framework. This a requirement of the architecture not part of the architecture.
1.4 Process Architecture
There are several activities that an Operations Manager performs with the Cloudlet Architecture including: Setting up the federation of clouds to form cloudlets, Establishing Local and Global (Federated Policies), Creating Secure geo-fenced domains, and updating and patching infrastructure across the cloudlets.
1.3. Logical Architecture 3
1.5 Deployment model
The Cloudlet architecture should be as light weight as possible and should integrate existing infrastructure and systems with minimal impact on the current system. Existing cloud installations are used to handle the heavy lifting in the system. The cloudlet architecture requires a hybrid cloud architecture that includes Cloud Management Platform, Automation Framework & Platform as a Service, or the functions defined in those sets of tools.
The Cloudlet Architecture has a Cloudlet Manager is that placed as a connectivity layer between the hybrid cloud and the Federated Connectivity. The connectivity gives all of the functionality that is needed to federate the different
4 Chapter 1. Cloudlet Overview
cloudlet
clouds systems together. This let’slets the cloud operate independently from other cloud(s). Allowing for them to operate in a disconnected or semi-connected state.
1.6 Trusted Cloudlets
Setting up a cloudlet architecture does not mean they are secure or trusted. Trusted Cloudlets give the ability to set up a trusted federation of cloud and to segment that federation with geo fencing technology using Intel CIT, TXT and TPMs. Intel TXT and CIT technologies provide the trusted launch and attestation of the cloud workloads and infrastructure. Overall trust and security in a cloud computing infrastructure must begin with the servers and base compute systems. The basic elements of this trusted platform span hardware, firmware, and software to provide the best balance of tamper-resistance and functionality.
In this example Each cloud has a geo fenced data set that can be shared with other clouds but not all of the clouds.
1.6. Trusted Cloudlets 5
1.7 Physical Architecture
The goal of the architecture is to connect multiple clouds together that are scattered across an organization. This could be physically as well as logically. There is the concept of a base Cloud that could offer multiple clouds and remote clouds named cloudlets.
6 Chapter 1. Cloudlet Overview
CHAPTER 2
2.1 Solution Overview
Cloudlets represent an architecture of federated cloud that have a CMP+Automation+PaaS+CloudOS bundle as de- scribed in the C3 architecture. The architecture targets cloud operations managers and should be as transparent to the end user and developer as possible.
2.1.1 High Level Use Case
• Manage Cloudlet
• Manage Policies
• Manage Services
• Use Service
• Actor Operations Manager
• Actor Stack Developer
2.1.3 Logical Architecture
What is the smallest size of the data for a cloudlet to: Authenticate all users in the cloud federation All other data required to run any job or at least start a job remotely.
8 Chapter 2. Implementations
This should help answer the storage requirements for the Cloudlet.
Where is data impacted: 1. Data Latency? 1. Does data Gravity have a big play 1. What VMs do you want localized 1. What images are required on the Remote Clouds 1. Updates to Cloudlets.
• Cloudlet Manager - Each Cloud Has a Cloudlet manager that becomes part of the Federation
• Federated Orchestrated Cloud - Federated Orchestrated to schedule service requests acrosss multiple clouds
• Data Coordinator - Coordinates data between Clouds
• Identity Manager - Manages Identity across multiple clouds
• Trust Manager - Manages Securee keys in TPMs across multiple data centers.
• Telemetry - Aggregates Telemetry before forwarding it own to a cloudlet telemetry
• C3 - Common Cloud Core including a Cloud Management Platform
2.1.4 Process Architecture
There are several activities that an Operations Manager performs with the Cloudlet Architecture including: Setting up the federation of clouds to form cloudlets, Establishing Local and Global (Federated Policies), Creating Secure geo-fenced domains, and updating and patching infrastructure across the cloudlets.
2.1. Solution Overview 9
2.1.5 Deployment model
The Cloudlet architecture should be as light weight as possible and should integrate existing infrastructure and systems with minimal impact on the current system. Existing cloud installations are used to handle the heavy lifting in the system. The cloudlet architecture requires a hybrid cloud architecture that includes Cloud Management Platform, Automation Framework & Platform as a Service, or the functions defined in those sets of tools.
The Cloudlet Architecture has a Cloudlet Manager is that placed as a connectivity layer between the hybrid cloud and the Federated Connectivity. The connectivity gives all of the functionality that is needed to federate the different clouds systems together. This let’slets the cloud operate independently from other cloud(s). Allowing for them to
10 Chapter 2. Implementations
2.1.6 Physical Architecture
The goal of the architecture is to connect multiple clouds together that are scattered across an organization. This could be physically as well as logically. There is the concept of a base Cloud that could offer multiple clouds and remote clouds named cloudlets.
2.1. Solution Overview 11
Services
These are the micro-services of the cloudlet Solution that are used to implement the solutions.
3.1 Services
The system is implemented using micro-services that are deployed across a cloudified architecture.
3.1.1 cloudlet-manager
Use Cases
Deployment Architecture
This is the deployment of the micro-service. The micro-service is deployed when trigger and should scale from # to # based on condition. The micro-service is deployed with the imagename image. The ports exposed are 5000 for external and 3000 for internal.
16 Chapter 3. Services
Physical Architecture
The micro-services are physically deployed on to a hybrid cloud infrastructure.
3.1. Services 17
Use Cases
Deployment Architecture
This is the deployment of the micro-service. The micro-service is deployed when trigger and should scale from # to # based on condition. The micro-service is deployed with the imagename image. The ports exposed are 5000 for external and 3000 for internal.
3.1. Services 21
Physical Architecture
The micro-services are physically deployed on to a hybrid cloud infrastructure.
22 Chapter 3. Services
These are the high level Subsystems of the cloudlet Solution
4.1 Cloudlet Manager
The Cloudlet Manager is responsible for connecting a “Cloud” into the Cloud Federation. Once the Cloud is connected to th Cloud Federation it will be known as a Cloudlet in that federation.
25
cloudlet
cloudlet
cloudlet
cloudlet
4.1.8 Physical Architecture
4.2 Data Coordinator
Data Coordinator is a subsystem of Cloudlet architecture and is responsible for coordinating data between the clouds. This is for data that can be moved between data centers based on policies and bandwidth capabilities.
Typical data that should be shared between Data Centers are
• Service Images
• Service Templates
• Application Templates
• Shared Registries
• Application Data
The Data Coordinator is responsible for creating secure domains between the multiple Cloudlets and moving data or applications between the Cloudlets. It will work with the Trust Manager to establish geofenced federated secure domains that the data can freely move.
There are three modes that the Data Coordinator can use to move data or applications. 1. Data Movement - Move data between the Cloudlets 1. Data Exchange - Split and application into multiple services and distribute the services on the different cloudlets. 1. App Movement - Move an application to the Data.
4.2.1 Use Cases
cloudlet
• Portal - Web Portal
4.2.5 Logical Artifacts
• Data Mover - Moves data between trusted geofenced secure domains between the Cloudlets.
• Application Mover - Find the data required for the application and moves the application to the proper Cloudlet.
• Data Exchange - Create a results Agregator and sets up the Data Exchange Source micro-services in each Cloudlet.
4.2. Data Coordinator 33
cloudlet
4.3 Federated Orchestrated Cloud
Federated Orchestrated Cloud is a subsystem of the Cloudlet Architecture. The Federated Orchestrated Cloud (FOC) is responsible for coordinating service requests between the clouds. It has three major components. SNAP, Analytics and and Orchestrator. The FOC should be the majority of the added integration required for the federation.
4.3. Federated Orchestrated Cloud 35
cloudlet
cloudlet
4.3.5 Logical Artifacts
Information from the analytics. Would be used to determine what services should be on the cloud. It will also determine what pre-staged Images or VMs would be best on the Cloud. This information is dynamic.
A cloud is responsible for itself. Other clouds cannot push jobs or services to a cloud. A Cloud pulls services/data/ etc.. From other clouds and makes the services available
Policy will determine how often a Service will be removed from the Cloudlet and force other Cloudlets to use the Cloud.
4.3. Federated Orchestrated Cloud 37
cloudlet
cloudlet
4.4. Identity Manager 39
cloudlet
cloudlet
4.5. Telemetry 43
cloudlet
4.5. Telemetry 45
4.5.7 Deployment Architecture
This subsystem is deployed using micro-services as shown in the diagram below. The ‘micro’ module is used to implement the micro-services in the system. The subsystem also has an CLI, REST and Web Interface exposed through a sailajs application. The sailsjs application will interface with the micro-services and can monitor and drive work-flows through the mesh of micro-services.
46 Chapter 4. Sub Systems
cloudlet
4.5.8 Physical Architecture
The Telemetry subsystem is is physically laid out on a hybrid cloud infrastructure. Each microservice is shown how they connect to each other. All of the micro-services communicate to each other and the main app through a REST interface. A CLI, REST or Web interface for the app is how other subsystems or actors interact. Requests are forwarded to micro-services through the REST interface of each micro-service.
4.5. Telemetry 47
4.6 Trust Manager
Setting up a cloudlet architecture does not mean they are secure or trusted. Trusted Cloudlets give the ability to set up a trusted federation of cloud and to segment that federation with geo fencing technology using Intel CIT, TXT
48 Chapter 4. Sub Systems
cloudlet
and TPMs. Intel TXT and CIT technologies provide the trusted launch and attestation of the cloud workloads and infrastructure. Overall trust and security in a cloud computing infrastructure must begin with the servers and base compute systems. The basic elements of this trusted platform span hardware, firmware, and software to provide the best balance of tamper-resistance and functionality.
Intel Trusted Execution Technology (TXT) is available with servers featuring the Intel® Xeon® processor E3, E5, and E7 families. Platform-level enhancements provide the building blocks to enable visibility, trust, and control in the cloud.
Intel TXT is a combination of hardware and software aimed at securing the execution of sensitive workloads. In contrast to solutions that protect the Operating System, Intel TXT builds a chain of trust from the system firmware all the way to the server or hypervisor to prevent attacks on system firmware or BIOS, MBR, boot loader, OS and hypervisor. Every component in this chain is verified against known good states and, depending on the result, marked either trusted or untrusted.
4.6. Trust Manager 49
cloudlet
This approach allows detection of not only threats to the OS itself, such as viruses, but also attacks on the configuration and even manipulation of the server’s boot firmware and hardware. When a breach is detected, workloads that require secure execution cannot be executed on this server.
50 Chapter 4. Sub Systems
cloudlet
Designed to measure the execution environment and protect sensitive information from attacks, it operates with Trusted Platform Module (TPM), an industry-standard device that can securely store artifacts used to verify integrity of the platform Hardware-based root of trust—when coupled with an enabled operating system, hypervisor, and solutions—is the foundation for a more secure computing platform that can ensure hypervisor and VMM integrity at boot from rootkits or other low-level attacks. It establishes the trust-worthiness of the server and host platforms. The hardware- based root of trust uses open industry standards developed by Trusted Computing Group (TCG) to establish and ensure platform trust and store measurements in a TPM.
The solution works by providing a root of trust—a processor-based, tamper-resistant environment that compares firmware, BIOS, and operating system or hypervisor code to known good configurations to establish a measured, trusted environment prior to launch. If integrity and trust are not verified in the launch process, Intel TXT identifies that the code has been compromised, which lets you protect the system and remediate the problem. Because Intel TXT can evaluate and report on platform integrity using attestation mechanisms, it can provide valuable insights and controls when used in the context of cloud computing models. This allows other key software—virtualization, cloud orchestration and management, and security policy applications—to understand and use platform integrity attributes to control workloads and data and better address security risks by keeping sensitive or regulated workloads separate from platforms with unknown integrity status. This is a concept that Intel and like-minded solution companies call Trusted Compute Pools.
Trustable pools created using Intel® Trusted Execution Technology (Intel® TXT)-enabled platforms help ensure safe migration between hosts.
4.6. Trust Manager 51
cloudlet
Intel OpenCIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters. The solution leverages Intel processors with Intel® Trusted Execution Technology (Intel® TXT) to establish HW root of trust and builds the chain of trust across hardware, OS, hypervisor, vm and docker container and including asset tagging for Location and boundary control. The Platform trust and asset tag attestation information is used by Orchestrators and/or Policy Compliance management to ensure workloads are launched on trusted and location/boundary compliant platforms, and they provide the needed visibility and Auditability of your infrastructure in both public and private cloud environments.
In this example each cloud has a geo fenced data set that can be shared with other clouds but not all of the clouds. This gives an example of “virtual” air-gapping classifications of data in the same datacenter and even across the multiple clouds and tactical edges.
In this example data can only be moved and unencrypted in the geoB geo-fence between the Cloud, Cloudlet1 and Cloudlet2. This also prevents man in the middle attacks because the cloudlets are attested and trusted between them- selves. Since the trusted keys are stored in secure TPMs on physical machines in each “cloudlet”, only the physical machines with the appropriate keys can encrypt and decrypt the data, vms, or containers moving between the physical machines, using Intel’s TXT and CIT technologies.
4.6.1 Use Cases
cloudlet
cloudlet
CHAPTER 5
5.1 Application Developer
The Application Developer develops cloud aware applications. This is the same actor as in the C3 architecture which can be found in the architect C3-App-Dev .
5.1.1 Use Cases
5.1.2 Activities
Application Developer will typically use existing services as well as develop new services. In order to use existing services they can look up the services or service stacks in the Cloudlet service registry either locally or globally. One the service or service stacks is selected. It can be used by the Application Developer to developer their application.
If the service or service stack cannot be found then the Application Developer can create a new service in the cloudlet federation. They first need to request infrastructure to build the new service. Then they build the service and then add it to the cloudlet federation. The service could be local or global in the federation.
5.1.3 Workflow
Propagation of activities to the underlying C3 architecture is normal mode of operation.
58 Chapter 5. Actors
5.2 Actor Operations Manager
The Operation Manager is responsible for managing the operations of the system. This includes the creation and management of environments, users, and connectivity to the Clouds.
This is the same Operations Manager as defined in the CAADE Architecture. Click here to see the base Operation Manager Specification.
5.2.1 Use Cases
• Manage Cloudlet
• Manage Policies
5.2.2 Activities
The Operations Manager focuses on the management of the cloudlet federation and the establishment of the federation through adding cloudlets to the federation, adding policies to the federation, managing infrastructure and managing the cloudlets.
60 Chapter 5. Actors
5.2.3 Workflow
Before the Cloudlet can be used the Cloudlet service needs to be installed for the C3 instance. Once it has been installed the cloudlet is registered with other cloudlets to form the federation. Once the federation has been formed the Operations Managaer can perform day to day operations, such as managing infrastructure and policies.
5.2. Actor Operations Manager 61
cloudlet
The Stack Developer is responsible for developing Application Stacks and Service Templates This includes developing the configurations of services and applications for multiple environments and clouds.
This is the same Operations Manager as defined in the CAADE Architecture. Click here to see the base Operation Manager Specification.
5.3.1 Use Cases
• Manage Services
• Use Service
5.3.2 Activities
All activities by the stack developer are proxies to the C3 Architecture. The Stack Developer is not a primary user of the Cloudlet. It is basically a passthru layer that allows the connection and then propigation of services and stacks to all of the Clouds in the cloudlet.
5.3. Actor Stack Developer 63
5.3.3 Workflow
As the stack developer makes changes to services and application stacks those changes are propagated to remote cloudlets or to a centralized repository that all remote cloudlets can access.
64 Chapter 5. Actors
cloudlet
68 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Add Cloudlet Scenario.
# cloudlet cloudlet add <parameters> # cloudlet cloudlet add exmaple
Web Interface
This is a mock up of the Web Interface for the Add Cloudlet Scenario.
REST
cloudlet/add
6.1. Manage Cloudlet 69
CLI
This is the command line interface for the List Cloudlet Scenario.
# cloudlet cloudlet list <parameters> # cloudlet cloudlet list exmaple
Web Interface
This is a mock up of the Web Interface for the List Cloudlet Scenario.
REST
cloudlet/list
cloudlet
Monitor Cloudlet
CLI
This is the command line interface for the Monitor Cloudlet Scenario.
# cloudlet cloudlet monitor <parameters> # cloudlet cloudlet monitor exmaple
Web Interface
This is a mock up of the Web Interface for the Monitor Cloudlet Scenario.
6.1. Manage Cloudlet 71
cloudlet/monitor
Remove Cloudlet
CLI
This is the command line interface for the Remove Cloudlet Scenario.
# cloudlet cloudlet remove <parameters> # cloudlet cloudlet remove exmaple
Web Interface
This is a mock up of the Web Interface for the Remove Cloudlet Scenario.
72 Chapter 6. Use Cases
cloudlet
REST
cloudlet/remove
6.2 Manage Infrastructure
CLI
This is the command line interface for the Release Compute Scenario.
# cloudlet compute release <parameters> # cloudlet compute release exmaple
Web Interface
This is a mock up of the Web Interface for the Release Compute Scenario.
74 Chapter 6. Use Cases
cloudlet
REST
compute/release
Release Network
CLI
This is the command line interface for the Release Network Scenario.
# cloudlet network release <parameters> # cloudlet network release exmaple
6.2. Manage Infrastructure 75
Web Interface
This is a mock up of the Web Interface for the Release Network Scenario.
REST
network/release
Release Storage
CLI
This is the command line interface for the Release Storage Scenario.
76 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Release Storage Scenario.
REST
storage/release
Request Compute
6.2. Manage Infrastructure 77
cloudlet
CLI
This is the command line interface for the Request Compute Scenario.
# cloudlet compute request <parameters> # cloudlet compute request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Compute Scenario.
REST
compute/request
78 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Request Network Scenario.
# cloudlet network request <parameters> # cloudlet network request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Network Scenario.
REST
network/request
Request Storage
CLI
This is the command line interface for the Request Storage Scenario.
# cloudlet storage request <parameters> # cloudlet storage request exmaple
Web Interface
This is a mock up of the Web Interface for the Request Storage Scenario.
80 Chapter 6. Use Cases
cloudlet
REST
storage/request
6.3 Manage Policies
CLI
This is the command line interface for the Create Policy Scenario.
# cloudlet policy create <parameters> # cloudlet policy create exmaple
Web Interface
This is a mock up of the Web Interface for the Create Policy Scenario.
REST
82 Chapter 6. Use Cases
cloudlet
policy/create
Destroy Policy
CLI
This is the command line interface for the Destroy Policy Scenario.
# cloudlet policy destroy <parameters> # cloudlet policy destroy exmaple
Web Interface
This is a mock up of the Web Interface for the Destroy Policy Scenario.
6.3. Manage Policies 83
policy/destroy
Evaluate Policy
CLI
This is the command line interface for the Evaluate Policy Scenario.
# cloudlet policy evaluate <parameters> # cloudlet policy evaluate exmaple
84 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Evaluate Policy Scenario.
REST
policy/evaluate
List Policy
CLI
This is the command line interface for the List Policy Scenario.
6.3. Manage Policies 85
Web Interface
This is a mock up of the Web Interface for the List Policy Scenario.
REST
policy/list
Manage Federated Policies
Manage Federated Policies using CLI and Web Interface with . . . <parameters>
86 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Manage Federated Policies Scenario.
# cloudlet federated manage <parameters> # cloudlet federated manage exmaple
Web Interface
This is a mock up of the Web Interface for the Manage Federated Policies Scenario.
REST
federated/manage
6.3. Manage Policies 87
Manage Local Policies using CLI and Web Interface with . . . <parameters>
CLI
This is the command line interface for the Manage Local Policies Scenario.
# cloudlet local manage <parameters> # cloudlet local manage exmaple
Web Interface
This is a mock up of the Web Interface for the Manage Local Policies Scenario.
REST
local/manage
cloudlet
6.4 Manage Services
6.4. Manage Services 89
cloudlet
CLI
This is the command line interface for the Add Service Scenario.
# cloudlet service add <parameters> # cloudlet service add exmaple
Web Interface
This is a mock up of the Web Interface for the Add Service Scenario.
REST
service/add
90 Chapter 6. Use Cases
cloudlet
CLI
This is the command line interface for the Create Service Scenario.
# cloudlet service create <parameters> # cloudlet service create exmaple
Web Interface
This is a mock up of the Web Interface for the Create Service Scenario.
REST
service/create
List Service
CLI
This is the command line interface for the List Service Scenario.
# cloudlet service list <parameters> # cloudlet service list exmaple
Web Interface
This is a mock up of the Web Interface for the List Service Scenario.
92 Chapter 6. Use Cases
cloudlet
REST
service/list
Remove Service
CLI
This is the command line interface for the Remove Service Scenario.
# cloudlet service remove <parameters> # cloudlet service remove exmaple
Web Interface
This is a mock up of the Web Interface for the Remove Service Scenario.
6.4. Manage Services 93
service/remove
6.5 Use Service
cloudlet
CLI
This is the command line interface for the Deploy Service Scenario.
# cloudlet service deploy <parameters> # cloudlet service deploy exmaple
Web Interface
This is a mock up of the Web Interface for the Deploy Service Scenario.
6.5. Use Service 95
service/deploy
Launch Service
CLI
This is the command line interface for the Launch Service Scenario.
# cloudlet service launch <parameters> # cloudlet service launch exmaple
96 Chapter 6. Use Cases
cloudlet
Web Interface
This is a mock up of the Web Interface for the Launch Service Scenario.
REST
service/launch
Monitor Service
CLI
This is the command line interface for the Monitor Service Scenario.
6.5. Use Service 97
Web Interface
This is a mock up of the Web Interface for the Monitor Service Scenario.
REST
service/monitor
98 Chapter 6. Use Cases
cloudlet