JP2023511111A - Techniques for Detecting Drift in Deployment Orchestrators - Google Patents

Abstract

Techniques for performing infrastructure orchestration services are described. A security plan may be received that includes a list of resources and actions based at least in part on the deployment configuration file. Upon receiving approval of the safety plan, actions corresponding to at least one of the list of resources may be prepared to be performed. Actions can be compared to a safety plan. If the action is part of the safety plan, the action can be performed. If the action is not part of the safety plan, the deployment can be stopped and a notification sent that the deployment is not compliant with the safety plan.

Description

REFERENCE TO RELATED APPLICATIONS This application is based on 35 U.S.C. No. 62/963,413, entitled "TECHNIQUES FOR DETECTING DRIFT IN A DEPLOYMENT ORCHESTRATOR," filed September 21, 2020, entitled "TECHNIQUES FOR DETECTING DRIFT IN A DEPLOYMENT ORCHESTRATOR." U.S. Application Serial No. 17/027,527, entitled, and entitled "TECHNIQUES FOR MANAGING DRIFT IN A DEPLOYMENT ORCHESTRATOR," filed September 21, 2020; No. 17/027,507, the entire contents of which are incorporated by reference for all purposes.

Background Today, cloud infrastructure services utilize many individual services to provision and deploy code and configuration (respectively) across many regions of the cloud infrastructure service. These tools require a great deal of manual effort to use, especially considering that provisioning is largely declarative and requires code to be deployed. In addition, cloud infrastructure services must continue to grow as the number of service teams and geographies increases. Some strategies for cloud infrastructure services that deploy to a larger number of smaller geographies involve per-region spending, but these may not scale well.

Brief Overview Describes techniques for implementing infrastructure orchestration services. In some examples, a safety plan may be received that includes a list of resources and actions based at least in part on a deployment configuration file. Upon receiving approval of the safety plan, actions corresponding to at least one of the list of resources may be ready to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action may be performed. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment does not comply with the safety plan. In some instances, if drift occurs, action may not be part of the safety plan.

In another example, a computer-readable storage medium may contain instructions that, when executed by a processor, can cause the processor to perform various operations described herein. A security plan may be received that may include a list of resources and actions based on the deployment configuration file. Approval of the safety plan may be received. An action corresponding to at least one of the list of resources according to the deployment configuration file may be arranged to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action may be performed. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment is not compliant with the safety plan.

In yet another example, a system includes a processor and memory capable of storing instructions that, when executed by the processor, configure the system to perform the operations described herein. obtain. A security plan may be received that may include a list of resources and actions based at least in part on the deployment configuration file. Approval of the safety plan may be received. Based on the approval, an action corresponding to at least one of the list of resources can be arranged to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action may be performed. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment does not comply with the safety plan.

In another example, the method may comprise at least one of the plurality of computer processors receiving a safety plan including a list of resources and respective actions based at least in part on the deployment configuration file. The method may further comprise preparing at least one of the plurality of computer processors to perform operations corresponding to at least one of the list of resources according to the deployment configuration file upon receiving the indication of approval of the safety plan. . The method may further comprise comparing the action to a safety plan. The method may further comprise performing the action by at least one of the plurality of computer processors in accordance with the determination that the action is part of the safety plan. The method further comprises: at least one of the plurality of computer processors halting deployment pursuant to a determination that the operation is not part of the safety plan; and sending a notification of non-compliance.

In another example, a computer-readable storage medium may contain instructions that, when executed by a processor, can cause the processor to perform various operations described herein. The actions may include receiving a safety plan that includes a list of resources and respective actions based at least in part on the deployment configuration file. The actions may further include preparing to perform an action corresponding to at least one of the list of resources according to the deployment configuration file upon receiving an indication of approval of the safety plan and comparing the action to the safety plan. . The action may further include performing the action in accordance with the determination that the action is part of the safety plan. The action may further include stopping the deployment upon determining that the action is not part of the safety plan and sending a notification that the deployment is not compliant with the safety plan.

In another example, the system may comprise a processor and a memory capable of storing instructions that, when executed by the processor, configure the system to perform the operations described herein. The actions may include receiving a safety plan that includes a list of resources and respective actions based at least in part on the deployment configuration file. The actions may further include preparing to perform actions corresponding to at least one of the list of resources according to the deployment configuration file upon receipt of the indication of approval of the safety plan. The action may further include comparing the action to a safety plan. The action may further include performing the action in accordance with the determination that the action is part of the safety plan. The action may further include stopping the deployment upon determining that the action is not part of the safety plan and sending a notification that the deployment is not compliant with the safety plan.

An apparatus comprising means for the steps of any of the methods described herein.
To easily identify the description of any particular element or act, the most significant digit(s) of a reference number refer to the figure number in which that element is first introduced.

1 is a block diagram illustrating an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment; FIG. 1 is a block diagram illustrating an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment; FIG. [0014] Figure 4 is a flow diagram for illustrating an example flock in accordance with at least one embodiment; [0014] Figure 4 is a flow diagram for illustrating an example flock in accordance with at least one embodiment; 1 is a block diagram illustrating a cloud infrastructure orchestration service in accordance with at least one embodiment; FIG. [0014] Figure 4 is a flow chart illustrating a process for using secure plans in a cloud infrastructure orchestration service, according to at least one embodiment; [0014] Figure 4 is a flow chart illustrating a process for generating a safety plan in a cloud infrastructure orchestration service, according to at least one embodiment; FIG. 4 is a swimlane diagram for explaining how safety plans are generated and used in accordance with at least one embodiment; FIG. 12 is a block diagram illustrating a cutting area in accordance with at least one embodiment; FIG. 11 is a flow chart illustrating a process for using a safety plan in a cutting area, according to at least one embodiment; FIG. 1 is a block diagram of a distributed system in accordance with at least one embodiment; FIG. 1 is a block diagram illustrating one or more components of a system environment in which services provided by one or more components of an embodiment system may be provided as cloud services, in accordance with at least one embodiment; FIG. 1 is a block diagram illustrating an example computer system upon which various embodiments of the disclosure may be implemented; FIG.

DETAILED DESCRIPTION In some examples, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (eg, the Internet). In some examples, IaaS is one of three main categories (or subcategories) of cloud computing services. Most people consider the other major categories to be Software as a Service (SaaS) and Platform as a Service (PaaS), with SaaS encompassing both PaaS and IaaS It is sometimes considered a broader category, and some even consider IaaS to be a subcategory of PaaS.

In the IaaS model, cloud computing providers host infrastructure components such as servers, storage devices, network nodes (e.g. hardware), deployment software, or platform virtualization (e.g. hypervisor layer). can be done.

In some cases, the IaaS provider may also supply various services (eg, billing, monitoring, logging, security, load balancing, clustering, etc.) to accompany these infrastructure components. Thus, these services can be policy driven, enabling IaaS users to enforce policies to drive load balancing and maintain application availability and performance.

In some examples, IaaS customers can access resources and services over a wide area network (WAN), such as the Internet, and use the cloud provider's services to install the rest of the application stack. be able to. For example, a user logs into an IaaS platform, creates virtual machines (VMs), installs an operating system (OS) on each VM, deploys middleware (such as databases), and storage for workloads and backups. You can even create a bucket and install corporate software on that VM. Customers can then use the provider's services to perform a variety of functions such as network traffic balancing, troubleshooting application issues, performance monitoring, and managing disaster recovery.

In most cases, cloud computing models require the participation of cloud providers. A cloud provider may or may not be a third party service that specializes in providing (eg, selling) IaaS. An entity may also choose to deploy a private cloud that becomes its own infrastructure service provider.

In some examples, IaaS deployment is the process of putting a new application or new version onto a provisioned application server or the like. It may also include the process of preparing the server (eg, installing libraries, daemons, etc.). This is often managed by cloud providers below the hypervisor layer (eg, servers, storage, network hardware and virtualization). Thus, a customer can be responsible for processing such as (OS), middleware and/or application deployment (eg, on a self-service virtual machine (eg, which can be spun up on demand)).

In some examples, IaaS provisioning may even mean obtaining computers or virtual hosts for use and installing the necessary libraries or services on them. In most cases deployment does not involve provisioning, and sometimes provisioning needs to be performed first.

In some cases, there are two different issues with IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything is running. Second, there is the challenge of deploying the existing infrastructure once everything is provisioned (eg, adding new services, changing services, removing services, etc.). In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be declaratively defined. In other words, the infrastructure (eg, what components are required and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (eg, which resources depend on which and how each of them work together) can be declaratively described. In some examples, once a topology is defined, a workflow can be generated that creates and/or manages the different components listed in the configuration file.

In some examples, an infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (eg, pools of configurable and/or shared computing resources, possibly on demand). . In some instances, there may also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how security for the network is set up. be. Other infrastructure elements such as load balancers or databases may also be provisioned. The infrastructure may be deployed in stages as more infrastructure elements are required and/or added.

As mentioned above, one way to provision infrastructure is to describe it declaratively. As such, the configuration file may simply be a declarative file that describes each of the above infrastructure components and how they interact. A configuration file can describe the resources and associated fields needed to create an element, and thus other elements that refer to previously described elements. In some examples, the provisioning tool can then generate workflows to create and manage the elements described in the configuration files.

In some examples, provisioning tool workflows are configurable to execute various commands. One function that can be performed is view reconciliation, where the provisioning tool compares the current view of the infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually running. can be done. In some examples, performing the view reconciliation function may include querying various resource providers or infrastructure resources to identify which resources are actually operating. Another function that a provisioner can perform is plan generation, where the provisioner identifies the infrastructure components that are actually working and how the provisioner wants that state to look (e.g., the desired configuration). can be compared. In other words, the plan generator can determine what changes need to be made to bring the resources closer to the latest expectations. In some examples, the third function is an execution (eg, apply) function, and the provisioning tool can execute the plan generated by the plan generation function.

In general, a provisioner can be configured to receive a configuration file, parse the declarative information it contains, and programmatically/automatically determine the order in which resources should be provisioned to execute the plan. is. For example, if the security group rules and the VPC must be booted before the VM is booted, the provisioning tool will be able to set the That decision can be made to perform the boot in that order.

In some examples, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques can enable infrastructure management within these environments. In some instances, a service team may want to be deployed in one or more (but often many) different production environments (e.g., in various different geographic locations, sometimes across the world). You can write code that However, in some instances, the infrastructure on which the code will be deployed must first be set up. In some examples, provisioning can be done manually, resources can be provisioned using a provisioning tool, and/or code can be deployed using a deployment tool once the infrastructure is provisioned. is possible.

As noted above, there are generally two different tools used to handle each of the provisioning of infrastructure resources and the deployment of code to control infrastructure resources, and the orchestration between these two tools is done manually. However, at scale, manual execution always introduces lag. Automated tools that can both provision and deploy virtual infrastructure therefore enable a more efficient and reliable technique for realizing virtual cloud environments.

In some instances, when two tools are used, problems can arise when users manually make changes to code between the provisioning and deployment phases. The technique of using a single tool for both provisioning and deployment, as described herein, alleviates that problem by automating the process so there is no opportunity for manual code changes. can do. Small changes to the way one user encodes something can cause big problems in the deployment phase. In some instances, the first time an operator performs an action (eg, a typographical error in code) in a new region, the object encoded with the typographical error may remain forever. If the application is deployed with the typo but the application is not affected by the typo (e.g. the application still works), it is possible that further code changes in the future will be affected by the typo and crash the entire system. . Accordingly, the techniques provided herein can eliminate the gap between provisioning and deployment that can often lead to problems.

In general, deployment modeling is declarative, such that infrastructure resources can be declared using configuration files. For example, deployment Generate files. However, the deployment itself generally does not follow this concept. Additionally, infrastructure provisioning tools tend to be very powerful and/or expressive, while tools for deployment tend to be far more restrictive in terms of what they can do. (e.g. they are imperative as opposed to declarative). Therefore, there has long been a need for tools that can address both functional requirements (eg provisioning and deployment of infrastructure elements) within a cloud environment.

In some examples, techniques for implementing cloud infrastructure orchestration services (CIOS) are described herein. Such technology, as briefly described above, can be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment. In some examples, CIOS may include two classes of services: a central component and a regional component (eg, central CIOS and regional CIOS). The following terms are used throughout the specification.

Infrastructure components: Long-lived pieces of infrastructure that support running code. Examples: deployment applications, load balancers, domain name system (DNS) inputs, object storage buckets, etc.

• Artifacts: Code is deployed to a deployment application or Kubernetes engine cluster, or configuration information (hereinafter "config") is applied to infrastructure components. These may be read-only resources.

Deployment Tasks: Short-lived tasks often associated with deploying or testing code. Additionally, deployment tasks are modeled as resources that do not live as long as the release that creates them.

Examples: "deploy $artifact to $environment", "watch $alarm for 10 minutes", "run $ test suite "execute $testSuite" or "wait for $manualApproval"
For example, CIOS may model the deployment of a deployment orchestrator as the creation of a resource that transitions to an available state when it completes.

Since CIOS maintains the state of its associated declarative provisioners, CIOS can control the lifecycle of these short-lived resources when it relates to releases.

Resources: CRUDable Resources CIOS models each of the above constructs as a resource. The next section describes this modeling in detail.

• Floc: the only control plane resource of the CIOS. It exists primarily to model infrastructure component ownership and represent infrastructure components.

• Flock config: Describes the set of all infrastructure components, artifacts and deployment tasks related to a single service.

Each floc has exactly one floc config. The block config is checked into source control.

A floc config is declarative. They expect CIOS to provide region, region, ad and artifact version as input.

Flocs are fine-grained. A floc consists of a single service and supporting infrastructure.

State: A snapshot in time of the state of every resource in the block.
• Release: a tuple of a specific version of the flock config and a specific version of any artifact it references A release is considered to describe a state that cannot yet exist.

Release Plan: The set of steps that CIOS will take to transition all regions from their current states to the states described by the release.

A release plan has a finite number of steps and well-defined start and end times.

Application: This is a noun. A single attempt to execute a release plan. Execution changes the current state of the block.

CIOS can be said to be an orchestration layer that applies settings to downstream systems (eg, worldwide). It is designed to enable worldwide infrastructure provisioning and code deployment without manual effort from service teams (e.g., possibly beyond initial approval). Senior responsibilities of the CIOS include, but are not limited to:

• Providing teams with a view into the current state of resources managed by the CIOS, including any pending change activity.

- Help the team plan and release new changes.
• Coordinating activities across various downstream systems in the region to execute approved release plans without human intervention.

• Coordinating activities across geographies/territories to execute approved release plans on a global basis.

Handles onboarding by allowing information to be provided to the CIOS. CIOS can also automate more things, so this is a heavier task than previous implementations. In some examples, CIOS handles pre-deployment by providing teams with the ability to automatically deploy and test code. In some instances, CIOS improves change management (CM ) can process policy writes. This can be done by examining the current state of each region and the current CIOS config (which itself can be an artifact). Additionally, the team can examine these plans and repeat them by asking the CIOS to change the CIOS config and re-plan. Once the team is satisfied with the plan, they can create a 'release' that references the plan. This plan can then be marked as approved or rejected. Teams can still write CMs, but they are just pointers to the CIOS plan. Therefore, the team does not spend much time reasoning about this plan. Plans are more accurate because they are machine generated. Plans are too detailed for human reading, but can be displayed by a sophisticated user interface (UI).

In some examples, CIOS can handle CM execution by automatically executing a deployment plan. Once a release plan has been created and approved, engineers will not participate in CM unless CIOS initiates a rollback. In some cases, this requires teams to automate tasks that are currently manual. In some examples, CIOS implements change management by automatically generating a plan to return a block to its original (e.g., pre-release) state when CIOS detects service health degradation while CIOS is running. (CM) rollbacks can be processed. In some examples, the CIOS receives a release plan that is scoped to a subset of geographies and/or a subset of resources managed by the CIOS, and then executes that plan to enable sudden/tactical Can handle deploying changes.

Additionally, CIOS can support the primitives necessary to define fully automated worldwide deployments. For example, CIOS can measure service health by monitoring alarms and running integration tests. CIOS can help teams quickly define rollback behavior in the event of a service degradation, which can then be executed automatically. CIOS can automatically generate and display release plans and track approvals. In some examples, the language the team uses to describe the desired deployment behavior can be declarative. CIOS can combine the functions of code deployment and infrastructure configuration (eg, provisioning) within one system. CIOS also supports flexible ordering across regions and across components within a region. Teams can express ordering by checked-in configs. Teams can invoke CIOS planning to programmatically release APIs.

FIG. 1 shows an architecture 100 for describing techniques for running at least central CIOS 102 . In some examples, the central CIOS 102 may be a service that handles operations at the level of "flocks." Central CIOS 102 has several responsibilities, including but not limited to:

• Act as an authentication gateway for floc metadata change and release operations.

- Storing the deployment artifacts for the floc and the formal mapping of floc metadata to the CIOS repository.

• Align global releases across phases and targets.
• Synchronization to enforce policies such as "only one release at a time in progress to flock".

- Detecting changes to flock settings (configs) and artifacts and triggering release generation upon such changes.

In some examples, the Source Code Version Control Management Service (SCVMS) 104 can be configured to store formal flock settings, and the Artifact Notification Service (ANS) 106 informs the central CIOS 102 of new artifact builds. can be subscribed by the central CIOS 102 as it can. Central CIOS 102 may then map incoming changes to affected blocks and initiate release planning if desired. Additionally, in some instances, an Artifact Push Service (APS) is invoked by the central CIOS 102 prior to release to the target to ensure that any artifacts required for a successful release are present within the target region prior to release. can be guaranteed to

In some examples, a customer (eg, engineer) 108 can call central CIOS 102 to CRUD a block and/or release to view the status of ongoing CIOS activities. The floc management service 110 can include one or more APIs for manipulating flocs, and the view/plan/approval service 112 creates and approves plans to update the state of all CIOS-managed resources. change monitoring service 114 can monitor SCVMS 104 for changes to flock configs and receive notifications from ANS 106 for changes to other artifacts. , the state ingester service 116 can make a copy of the regional state in the central CIOS database (DB) 118 so that the view/plan/approval 112 can publish them. In some examples, the central CIOS DB 118 may be a block, plan and state DB. The flock information may be formal, but all others may be old copies of data from the regional CIOS 120 .

In some examples, engineer 108 may make an API call to floc management service 110 (eg, via ingress proxy fleet 122) to create a list of flocs. A protocol for making such API calls may be Hypertext Transport Protocol Secure (HTTPS), or the like. The associated access control list (ACL) for this operation may include local area network (LAN) 124 or other private connections. For example, the CIOS manages/manages network connections (e.g., dedicated, leased and/or private connections) that replace the use of the public internet to connect the customer's on-premises data center or network with the CIOS. control. Additionally, authentication and authorization (eg, of engineer 108) can be performed by a booking system portal that allows users to manage machine interfaces (eg, booking services). In some examples, central CIOS 102 may store block metadata, plans and states in central DB 118 using Java database connectivity (JDBC) or the like. In some examples, ANS 106 can be configured to notify change monitoring service 114 when new artifacts are published. ANS 106 can use HTTPS and both authentication and authorization can be handled by mutual transport layer security services. Further, in some examples, change monitoring service 114 may poll SCVMS 104 for flock configuration changes. This polling can be done using Secure Shell (SSH) or other protocols. Authentication of change monitoring service 114 can be handled by CIOS system accounts and authorization can be handled by SCVMS 104 .

In some examples, engineer 108 may use view/plan/approval service 112 to perform one or more of the following actions. Engineer 108 may plan and/or approve by calling central CIOS 102 to generate and approve the plan. Engineer 108 can view by calling central CIOS 102 to see the status of ongoing worldwide CIOS activities. In addition, engineers 108 can use central CIOS 102 to view replicas of the state of resources managed by the worldwide CIOS. These API calls (or the like) can be made via the HTTPS protocol or a similar protocol. Additionally, associated ACLs can be controlled by the LAN 124 and both authentication and authorization can be handled by the reservation service. In some examples, view/plan/approval service 112 may request planning (eg, using HTTPS, etc.) and push plan approvals to all regions of regional CIOS 120 . Associated ACLs can be controlled using security lists managed by wide area network (WAN) gateway 126 . Authentication can be handled by mutual transport layer security and authorization can be handled by various identity policies. In addition, state ingester service 116 communicates with regional CIOS 120 about those job status or state changes so that CIOS can provide a central view of job status or state changes on demand (e.g., also using HTTPS, etc.). can be observed. ACLS for this can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by mutual transport layer security services.

FIG. 2 shows an architecture 200 for describing techniques for implementing at least the regional CIOS 202. As shown in FIG. In some examples, the regional CIOS 202 is where much of the declarative provisioning and planning work, as well as approved release applications, can occur. In some examples, each instance of regional CIOS 202 may have a regional front end that can handle operations at the level of "execution targets." It can be configured to do the following:

- Handling all CIOS authentication for actions coming from the central CIOS 102;

Enforcing the rule that for a given execution target, only one "execution" (plan/resource import/apply plan) can be done at a time.

- Managing binary artifact storage for declarative provisioning artifacts used for input and output during declarative infrastructure provisioning. Examples of inputs are declarative infrastructure provisioning configuration files and input state files. A typical output is the final state file.

• For any given execution, request polling for work from the CIOS executor and results from the CIOS executor.

In some examples, the CIOS front end may rely on the CIOS executor, which can handle the actual execution. In some examples, the CIOS executor operates at the "execution" level, which can do the following:

Tracking the pool of available worker nodes Queries incoming job requests and assigns them as available to eligible workers Worker status and execution updates for reporting to clients Detect dead nodes via a leasing protocol and, depending on the task status, can fail tasks assigned to dead nodes Provide functions to cancel/kill/pause/resume execution , that they may be mapped to functions for passing cancel/kill/resume information to worker nodes. In some examples, a CIOS executor may depend on a CIOS worker, which may It is possible to assign tasks to workers for execution and provide functions for workers to update job progress. Worker services operate at the granularity of "tasks". Each worker is an agent that performs tasks assigned to that worker and reports task status and output. Each worker can do the following:

Poll the execute worker API for assigned work items and take action to match the assignment state with its local state Start a container for polling task items that do not exist locally Corresponding assignments Killing containers for running containers locally that do not have task items assigned to them Reporting job status Doing stage input/output for job container execution Start and monitor declarative infrastructure provisioning containers to do work. CIOS Workers to the CIOS Executor to poll for work from the CIOS Executor and report the results to the CIOS Executor's worker endpoint. can depend. A worker can rely on an executor for all collaborations. In addition, CIOS workers can also depend on regional CIOS 202, where worker services read input from one or more APIs related to regional front-end services and send them to these one or more APIs. Write the output of Examples of inputs are configuration and starting state files, and importing mappings. Examples of outputs are the declarative provisioning process, declarative provisioning state file output, and result state imports.

In some examples, regional CIOS 202 may be a regional service for managing regional instances/deployments of CIOS. Regional CIOS 202 covers responsibility for formally storing and managing plans and states associated with a particular region. Regional DB 204 may be a CIOS DB for conditions and plans in that particular region. This is a formal copy of the regional subset of central DB 118 of FIG. The scheduler 206 may be responsible for managing worker fleet capacity, assigning tasks to workers, and tracking the progress of task states. In some examples, task DB 208 is another CIOS DB for task states. The data in this DB is mostly operational. Additionally, workers 210 can be a fleet of java virtual machines (JVMs) that manage declaratively provisioned images. They receive instructions from scheduler 206 and communicate results to both scheduler 206 and regional CIOS 202 . The CIOS container 212 can perform declarative provisioning actions in its own private docker 214 container. This container may not contain confidential information. Further, in some examples, signing proxy 216 is configurable to prevent exfiltration of secrets by declarative provisioning tools to avoid putting secrets in declaratively provisioned images. Alternatively, the CIOS can perform the signature request or initiate a Mutual Transport Layer Security (mTLS) service at the proxy. This facilitates the use of FIPS compliant cryptographic libraries.

In some examples, the central CIOS 102 can call the regional CIOS 202 to create plans, push approvals, watch job status (service principal), and extract declarative provisioner state (service principal). . Ingress proxy 218 can be configured as an ACL and various identity policies can be used for both authentication and authorization. In some examples, regional CIOS 202 may run a declarative provisioner by asking scheduler 206 to do so. Worker 210 can ask scheduler 206 what it should be doing and report status to scheduler 206 when complete. In some cases, mTLS may handle both authentication and authorization for regional CIOS 202 and workers 210 . Additionally, workers 210 run declarative provisioners in docker containers by interacting with local docker 214 when they need to run declarative provisioners. Authentication in this phase can be handled by a local unix socket. The Docker protocol may be used in this last step, while HTTPS may be utilized in the previous steps.

In some examples, the CIOS container 212 allows a declarative provisioner to interact (via an API) with the signing proxy 216, which the declarative provisioner thinks is calling various CIOS services. . The signing proxy 216 listens on one ephemeral port per invocation of an instance of a declarative provisioner, known only to the declarative provisioner. The signing proxy 216 can initiate signature or mTLS requests and can pass declarative provisioner calls to other CIOS services within the service enclave. In some examples, signing proxy 216 may also communicate with one or more public CIOS services 220 . For example, signing proxy 216 uses internal endpoints of public services whenever possible. Services that do not have internal endpoints must use egress proxy 222 to reach external endpoints. This use of signing proxy 216 may not be for cross-regional communications. For example, each region's egress proxy whitelist may be only for that region's public IP ranges. In some examples, workers 210 may maintain state and logs from declarative provisioners in regional CIOS 202 such that they may then be flushed to central CIOS 102 .

With CIOS, a typical customer experience has several phases: onboarding, pre-release, worldwide release and tactical release. For the pre-release phase, the following is an example of what happens between building a new artifact and releasing the artifact to Release 1 (eg, R1). This should replace some or most of the current change management process. Once the relevant artifacts are built, CIOS can automatically generate a release using the "latest version of everything in the block". A release is a specific version of a flock config with specific inputs (eg, artifact version, region, region and ad). A release contains one roll-forward plan per region and metadata describing the region ordering. Each regional plan is a set of actions that the declarative provisioner will perform to implement the floc configuration in that region. Teams with pre-release environments can use CIOS to automatically release and test their software in these environments. Teams can configure CIOS to automatically test rollback plans. Teams will be able to review and approve releases via the CIOS UI. Teams can approve some (but not all) of the regional plans within a release. If "latest version of everything" does not yield a suitable plan, the team can ask CIOS to generate a plan for the cherry-picked artifact version.

For the worldwide release phase, the following is an example of how the team will execute tomorrow's version of today's "regular CM". Once the release is approved, CIOS pushes each approved regional plan to their respective regions. CIOS operates independently within each region to enforce the approved plans. The CIOS only performs the set of actions explicitly listed in the local plan. Instead of 'thinking independently', it will fail. The CIOS UI shows the execution progress to the team. The CIOS UI will prompt the team if manual approval is required. If an execution fails due to an outage in CIOS or a downstream service, CIOS can notify the team and prompt the team for next steps (eg, abort, retry). The CIOS performs retries, but some downstream system outages exceed its retry intentions. If the execution fails due to poor service health or failed tests, the CIOS assists the team by rolling back the block to its starting state. The CIOS will notify (eg, page) the team when it initiates an automatic rollback. The team must approve the rollback plan, which CIOS then implements.

For the tactical release phase, the following is an example of how a team could run tomorrow's version of a "Burst CM". When generating a plan, the team can, in several ways, i.e., topologically (e.g., region, region, AD, etc.), resource types (e.g., "metrics configuration only" or "deployment orchestration service deployment only"). etc.), or a combination of the above (eg, in a disjunctive manner), may ask the CIOS to direct plans to specific resources. The team approves tactical releases as well as global releases. CIOS orchestrates them as well. If a team needs to deploy a Tactical Release while there is an active Worldwide Release, CIOS will stop the execution of the Worldwide Release in the target region and then proceed with the Tactical Release. Start execution.

In some examples, a declarative provisioner's state (eg, traditionally a file) is a formal record of a set of resources managed by the declarative provisioner. It contains a mapping between each resource's logical identifier from the config and the resource's actual identifier. When a declarative provisioner creates a resource, certain kinds of failures can prevent the actual identifier from being recorded into the state. When this happens, the actual identifier is lost from the declarative provisioner. These are sometimes called "orphaned resources".

For most resources, orphans mean waste. A declarative provisioner will (for example) start the forgotten instance and then start another instance instead the next time it runs. For resources with uniqueness constraints or client-supplied identifiers, orphans prevent declarative provisioners from advancing. For example, if the declarative provisioner creates the user 'nglass' and orphans it by failure, the next run of the declarative provisioner will run 'nglass' because a user with that username already exists. will fail when trying to create a In some cases, orphans only matter when adding new resources to the state. In some instances, the refresh behavior of declarative provisioners may recover naturally from failures to record updates and deletes.

The CIOS must be robust even in the event of downstream service outages or outages of the CIOS itself. Since CIOS can leverage declarative provisioners to apply changes, this means that it must be robust with respect to executing declarative provisioners and maintaining declarative provisioner state. The Declarative Provisioner provider performs enough "small" retries to avoid outages lasting several minutes. For example, the cloud provider performs retries for up to 30 minutes. Declarative provisioners will fail if the downstream system is down for longer than 30 minutes. If the declarative provisioner fails, it records all successful changes to state and exits. To retry, CIOS needs to rerun the declarative provisioner. Rerunning the declarative provisioner allows the CIOS to perform retries if the CIOS itself fails. In some examples, the CIOS may perform the following operations in a loop.

Refresh: The declarative provisioner calls Get API to retrieve new snapshots of any resources listed in its state.

• Plan: The Declarative Provisioner generates a plan (a concrete set of API calls) that achieves the desired state given the current, recently refreshed state.

• Apply: A declarative provisioner executes a set of steps in a plan.
CIOS may always perform all three of these steps when running the declarative provisioner. A refresh operation helps recover from any unrecorded updates or deletions. The CIOS examines the results of the plan operation and compares it with the approved release plan. If the newly created plan contains actions that were not in the approved release plan, the CIOS may fail and notify the service team.

FIG. 3 is a diagram showing a directed acyclic graph (DAG) 300 for explaining an example of a block 302. As shown in FIG. For one block config in CIOS, the code/config progress from check-in to production can be described all the way from the first test deployment to the last prod deployment. CIOS internally calls each element in a progress an execution target (ET). This goes all over our internal API, but doesn't leak into the flock config. CIOS executes ET based on the DAG 200 defined in the flocconfig. Each ET (eg, ET-1, ET-2, ET-3, ET-4, ET-5, ET-6 and ET-7) is, broadly speaking, one of the services described by FlockConfig. is a copy.

FIG. 4 is a diagram showing a DAG 400 for explaining an example of the block 402. As shown in FIG. In flocconfig, CIOS is very arbitrary about how the team expresses this progress. Teams must model it using cloud infrastructure tenancies and regions. Teams should not use areas to model progress. CIOS allows teams to use many tenancies within a region and many regions within a tenancy. However, CIOS does not allow teams to use the same region twice within one tenancy (although it is possible to use the same region twice within one region in different tenancies). DAG 400 shows a version of DAG 300 from FIG. 3 represented with tenancy and region. This example is for an overlay service where the pre-prod ET is within the prod region. A service enclave service will have an unstable tenancy and a stable tenancy in Release 1. In DAG400, IAD is the local airport code for Dulles Airport in Washington DC, YYZ is the local airport code for Toronto, Ontario, and PHX, LHR and FRA are the local airport codes for Phoenix, London and Frankfurt respectively. , LUF and LFI are from two different air force bases.

In one embodiment, CIOS and/or other technologies described herein are improvements to each of Terraform (a declarative provisioning tool), Tanden (a code generation tool), and ODO (Oracle Deployment Orchestrator). Further, in some examples, CIOS and/or other techniques described herein may be implemented using at least some of the Terraform, Tanden and ODO tools.

In some examples, a safety plan may be generated to handle drift safely. The configuration file may contain information that dictates how the CIOS makes changes to the region (eg, the geographic region in which the cloud infrastructure is (or has already been) set). CIOS validates that what the client has reviewed as a change set (e.g., the delta between the current state of the cloud infrastructure and the expected new state after the change) is actually changed within the region can be done. When a client interacts with the CIOS to generate a global plan, the safety plan must change the current world (e.g. current state) to reach the world described in the configuration file (e.g. target state). Identify what changes are expected to be made by the CIOS based on As described herein, "world" may also refer to the expected state of the cloud infrastructure, including all settings and configurations of the cloud setup. In some cases, drift is the idea that one or more device configurations/settings may have changed between the time the plan was generated and the time the regional deployment began (e.g., virtual machine may be broken). That change is the drift. The CIOS can create a safety plan and send it to different regions around the world (eg, send it to different regional CIOS). The planning task can be repeated whenever the CIOS is about to implement a change. For example, a current state can be predicted, compared to a target state, and a diff (eg, delta, difference, etc.) between the two can be generated. If that diff is a subset of the safety plan, no drift has occurred and the safety plan can still be implemented. Otherwise, a problem with the safety plan has been detected and changes must be made prior to deployment. Additionally, in some examples, the CIOS can compare different safety plans (eg, to handle phase changes). For example, for deployment into phases (eg, deploying resources in a first phase before other phases), a safety plan may be reviewed and approved, and deployment may be performed accordingly. A new safety plan can then be generated and compared with the first safety plan later for Phase 2 deployment. If the new safety plan is a subset of the first safety plan, the new safety plan can be automatically approved without sending anything to the client that generated the configuration file. This accelerates the deployment process as no delays are introduced associated with waiting for approval of new safety plans, but also maintains the integrity of the deployment as drift has not occurred in this situation. will be understood. Alternatively, if there is something new in the new safety plan (e.g., something not present in the first safety plan), the new aspects are presented to the user (e.g., client) via a user interface (UI). can be presented. The user can then approve or reject the new aspect (eg, allow or disallow deployment changes to occur).

Techniques for running infrastructure orchestration services are described. In some examples, a safety plan may be received that includes a list of resources and actions based at least in part on a deployment configuration file. Upon receiving approval of the safety plan, actions corresponding to at least one of the list of resources may be arranged to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action may be performed. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment does not comply with the safety plan. In some instances, if drift is occurring, action may not be part of the safety plan.

In another example, a computer-readable storage medium may contain instructions that, when executed by a processor, can cause the processor to perform various operations described herein. A security plan may be received that may include a list of resources and actions based on the deployment configuration file. Approval of the safety plan may be received. An action corresponding to at least one of the list of resources according to the deployment configuration file may be arranged to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action can be taken. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment is not compliant with the safety plan.

] In yet another example, a system includes a processor and a memory capable of storing instructions that, when executed by the processor, configure the system to perform the operations described herein. can be provided. A security plan may be received that may include a list of resources and actions based at least in part on the deployment configuration file. Approval of the safety plan may be received. Based on the approval, an action corresponding to at least one of the list of resources can be arranged to be performed. Actions can be compared to a safety plan. If the action is determined to be part of the safety plan, the action can be taken. If it is determined that the operation is not part of the safety plan, the deployment can be stopped and a notification can be sent that the deployment does not comply with the safety plan.

In another example, the method may include at least one of the plurality of computer processors receiving a list of safety plans including resources and respective actions based at least in part on the deployment configuration file. The method may further comprise preparing at least one of the plurality of computer processors to perform operations corresponding to at least one of the list of resources according to the deployment configuration file upon receiving the indication of approval of the safety plan. . The method may further comprise comparing the action to a safety plan. The method may further comprise at least one of the plurality of computer processors performing the action in accordance with the determination that the action is part of the safety plan. The method further comprises: at least one of the plurality of computer processors halting deployment pursuant to a determination that the operation is not part of the safety plan; sending a notification of non-compliance.

In another example, a computer-readable storage medium may contain instructions that, when executed by a processor, can cause the processor to perform various operations described herein. The actions may include receiving a safety plan that includes a list of resources and respective actions based at least in part on the deployment configuration file. The actions may further include preparing to perform an action corresponding to at least one of the list of resources according to the configuration file upon receiving the indication of approval of the safety plan, and comparing the action to the safety plan. . Actions may further include performing actions in accordance with the determination that the actions are part of the safety plan. The action may further include stopping the deployment upon determining that the action is not part of the safety plan and sending a notification that the deployment is not compliant with the safety plan.

In another example, the system may comprise a processor and a memory capable of storing instructions that, when executed by the processor, configure the system to perform the operations described herein. The actions may include receiving a safety plan that includes a list of resources and respective actions based at least in part on the deployment configuration file. The actions may further include preparing to perform actions corresponding to at least one of the list of resources according to the deployment configuration file upon receipt of the indication of approval of the safety plan. The action may further include comparing the action to a safety plan. The action may further include performing the action in accordance with the determination that the action is part of the safety plan. The action may further include stopping the deployment upon determining that the action is not part of the safety plan and sending a notification that the deployment is not compliant with the safety plan.

FIG. 5 is a block diagram 500 illustrating a CIOS capable of generating and using safety plans in accordance with at least one embodiment. In some examples, a safety plan may be a set of actions that are approved by a user and executable by the CIOS. Block diagram 500 illustrates an example CIOS architecture that may include a central control plane 502 and a regional data plane 504 . Central control plane 502 may include central CIOS 506 (eg, similar to central CIOS 102 of FIG. 1), which may include control plane 508, change management module 510, view/plan/approval module 512, and state ingester 514. Central control plane 508 and view/plan/approval module module 512 may be communicatively coupled to a local area network (LAN) gateway 516 through which users 518 may communicate with central CIOS 506 . View/plan/approval module module 512 and state ingester 514 may be communicatively coupled to regional CIOS 522 included in regional data plane 504 (e.g., similar to regional CIOS 120 of FIG. 1 or regional CIOS 202 of FIG. 2). It may be communicatively coupled to an area network (WAN) 520 (eg, the Internet).

Regional CIOS 522 may be communicatively coupled to scheduler node 524 and worker node 526 . Worker 526 may be communicatively coupled to scheduler 524 , which may be communicatively coupled to task database (DB) 528 . Worker 526 may be communicatively coupled to docker 530 , which may include CIOS container 532 . CIOS container 532 may be communicatively coupled to signing proxy 534 , which may be communicatively coupled to cloud service 536 .

Regional CIOS 522 can receive tasks from central CIOS 506 and can send tasks to scheduler 524 . Tasks may include executing CRUD operations or any other suitable task for deploying infrastructure resources to the execution target(s) region. The scheduler 524 can log the task to a task DB 528 and can send the task to workers 526, which can be included in a worker fleet. A worker fleet can include many workers 526, and a scheduler 524 can select the worker 526 with the least amount of work or the greatest amount of available computing resources to assign a task. Scheduler 524 can assign tasks to workers 526 one at a time. Workers 526 can perform tasks, and in performing tasks, workers can make calls to a CIOS container 532 contained in Docker 530 . CIOS container 532 can perform tasks including infrastructure provisioning and/or deployment instructions (eg, Terraform instructions). The instructions may direct API calls to cloud services 536, which may include locally available services that may not be available over a public network (eg, the Internet). To make an API call to cloud service 536, CIOS container 532 can send a request to make the API call to signing proxy 534, which determines whether the request is valid. be able to. In response to determining that the request is valid, signing proxy 534 may make an API call to cloud service 536 .

In some examples, user 518 may create a configuration file that may include actions to perform within regional data plane 504 . User 518 can send configuration files to central CIOS 506 , which can be a computing device included in central control plane 502 , via LAN gateway 516 . The configuration file may be received by central CIOS 506 at control plane 508 or at view/plan/approval module 512 . Change management module 510 can compile configuration files into region-agnostic (RA) configuration files that can be used by regional data plane 504 . View/plan/approval module 512 or state ingester 514 may send the RA configuration file via WAN gateway 520 to regional CIOS 522 , which may be a computing device included in regional data plane 504 .

Regional CIOS 522 can receive RA configuration files from central CIOS 506 , and regional CIOS 522 can create tasks and send RA configuration files to scheduler 524 , which can send tasks to task DB 528 . A task may include compiling a set of operations to be performed on an execution target, and may include comparing a current state of a resource in the execution target with a desired state of the resource in the execution target. Tasks may be sent to workers 526 who may execute the tasks. In performing tasks, workers 526 can help create a safety plan, which is a set of approved actions. An action may include deploying a resource to an execution target, or any other suitable action for execution on an execution target. Workers 526 may transmit the safety plan to regional CIOS 522 , which may transmit the safety plan to central CIOS 506 via WAN gateway 520 .

The central CIOS 506 may receive the safety plan from the regional CIOS 522 and compare the set of changes contained in the safety plan with the actions on the execution targets. The change management module 510 can perform this comparison and make one of two determinations: that the action is a subset of the set of safety plan changes, or that the action is not a subset of the set of safety plan changes. You can do one. Although only these two decisions are detailed, other decisions may be made (eg, what percentage difference is there between the set of changes and the safety plan). An action may be performed in response to determining that the action is a subset of the set of changes contained in the safety plan, which may include deploying the resource to the execution target. A notification can be sent to the user 518 in response to determining that the action is not a subset of the set of changes included in the safety plan. A notification can be sent to the user 518 via the LAN gateway 516 that drift may have occurred or that an action that may be scheduled to be performed on the execution target may not be included in the safety plan. Information may be included to alert user 518 that there is no In response to viewing the notification, user 518 can approve or reject actions not included in the safety plan. If the user 518 approves the action, the action may be executed and the resource deployed to the execution target. If user 518 declines the action, the action may not be performed, user 518 may decide to create a new configuration file, or may decide to abandon the action. Thus, the safety plan either allows execution of the action if it is a subset of the set of changes contained in the safety plan, or aborts execution of the action if the action is not a subset of the changes contained in the safety plan. By either means, it can be understood to be a data structure that controls the functionality of the processor(s) executing the deployment process.

In another example, user 518 may create a set of configuration files that may contain desired states of resources for a set of execution targets in a set of regions. The configuration files may be sent to central CIOS 506, which may compile the configuration files into a set of RA configuration files, including one RA configuration file per region. The RA configuration file may be sent to each region via the WAN gateway 520 and received by the regional CIOS 522 included in each region.

In each region, regional CIOS 522 may receive respective RA configuration files from central CIOS 506, and regional CIOS 522 may create tasks and send tasks to task DB 528 schedulers. 524. The tasks may include compiling a set of operations to be performed on execution targets within each region, including comparing current states of resources in the execution targets to desired states of resources in the execution targets. obtain. Tasks may be sent to workers 526 who can execute the tasks. In performing tasks, workers 526 can help create a safety plan, which is a set of approved actions. An action may include deploying a resource to an execution target, or any other suitable action for execution on an execution target. Workers 526 may transmit the safety plan to regional CIOS 522 , which may transmit the safety plan to central CIOS 506 via WAN gateway 520 .

The central CIOS 506 can receive a set of safety plans from the region and convert the safety plans into a master safety plan (e.g., one safety plan of a plurality of safety plans), also referred to as a compiled safety plan. can be compiled. Each safety plan included in the compiled safety plan may contain similar changes. A difference in change between safety plans included in the compiled safety plans may indicate that drift has occurred in at least one region. The central CIOS 506 can compare the changes included in each safety plan included in the compiled safety plans to the behavior in the execution targets included in the respective regions. The change management module 510 can perform this comparison and determine that the action is a subset of the set of compiled safety plan changes, or that the action is not a subset of the set of compiled safety plan changes. One of two decisions can be made. Actions can be executed in response to a determination that the action is a subset of the set of changes contained in the compiled safety plan, which means deploying resources to the execution targets contained in their respective regions. may contain. A notification may be sent to user 518 in response to a determination that the action is not a subset of the set of changes contained in the compiled safety plan. A notification can be sent to the user 518 via the LAN gateway 516 that drift may have occurred in at least one region, or that there is an action that can be scheduled to be performed on at least one execution target. Information may be included to alert user 518 that it may not be included in the compiled safety plan. User 518 can approve or reject actions not included in the safety plan in response to viewing the notification. Once the user 518 approves the action, the action may be executed and the resources deployed to the execution targets contained in the respective regions. If user 518 declines the action, the action may not be performed, user 518 may decide to create a new configuration file, or may decide to abandon the action.

6 and 7 illustrate example flowcharts illustrating processes 600 and 700 for performing CIOS techniques, in accordance with certain embodiments of the present disclosure. These processes are depicted as logic flow diagrams, each act of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, operations may refer to computer-executable instructions stored on one or more computer-readable storage media that perform the recited operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the acts are described is not intended to be construed as limiting, and any number of the described acts may be combined in any order and/or in parallel to implement a process. can be done.

In addition, processes 600 and 700 may be executed under the control of one or more computing devices or computer systems made up of executable instructions and code that collectively executes on one or more processors ( For example, it may be implemented as executable instructions, one or more computer programs, or one or more applications), by hardware, or by a combination thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors. In some embodiments, processes 600 and 700 may be executed in parallel by multiple processors. A computer-readable storage medium may be non-transitory.

FIG. 6 is a flowchart illustrating a process 600 for using safety plans in a cloud infrastructure orchestration service, according to at least one embodiment. Process 600 may begin at block 602, where a central CIOS (eg, central CIOS 506 of FIG. 5) receives a security plan from a regional CIOS (eg, regional CIOS 522 of FIG. 5) of a region containing execution targets. A security plan may include a list of resources and actions based on a deployment configuration file. An action may include instructions to deploy a resource on an execution target. In some examples, the central CIOS may receive a set of safety plans from a set of regional CIOS corresponding to a set of regions. A secure plan can be compiled by a central CIOS into a compiled secure plan that can include resources and actions based on deployment configuration files corresponding to execution targets, each of which is contained in a different region.

At block 604, the central CIOS prepares to perform at least one operation corresponding to at least one resource contained in the deployment configuration file. In response to receiving the safety plan from the regional CIOS, the central CIOS prepares to execute at least one operation on at least one execution target by, for example, compiling a local plan that may include the at least one operation. It can be carried out. The action may include deploying at least one resource on the execution target. In some examples, the central CIOS may prepare to perform a set of operations corresponding to a set of resources contained in a set of deployment configuration files. In this example, the central CIOS can receive a set of safety plans corresponding to a set of regions from a set of regional CIOS.

At block 606, the central CIOS compares the action to the safety plan. A change management module that may be included in the central CIOS (eg, change management module 510 of FIG. 5) may perform the comparison. A comparison may include determining whether the action is a subset of the safety plan. An action may be considered a subset of a safety plan if the safety plan contains the action. In some examples, the action may not change the current state of the execution target. In this case, the central CIOS may not perform any action, but the action may be considered a subset of the safety plan.

At block 608, operations are performed. In response to the change management module determining that the action is a subset of the secure plan, the central CIOS can send commands to perform the action. Commands may be sent by the central CIOS to regional CIOS within their respective regions and may include deploying resources contained in deployment configuration files to execution targets. Multiple safety plans may be received by the central CIOS in instances where a resource is desired to be deployed to multiple execution targets. In this case, the central CIOS may prepare to execute the action, and the change management module may compare the action to the safety plan to determine if the action is a subset of the safety plan. In response to the change management module determining that the action is a subset of the safety plan, the central CIOS can send commands to each region to perform the action. The command may be sent from the central CIOS to the regional CIOS in each region and may include deploying the resources contained in the deployment configuration file to each execution target.

At block 610, no action is performed and the deployment is stopped. In response to the change management module determining that the action is not a subset of the secure plan, the central CIOS may not send commands to execute the action; You can stop. Multiple safety plans may be received by the central CIOS if a resource is desired to be deployed to multiple execution targets. In this case, the central CIOS may prepare to execute the action, and the change management module may compare the action to the safety plan to determine if the action is a subset of the safety plan. In response to the change management module determining that the action is not a subset of the safety plan, the central CIOS may not send commands to execute the action. Alternatively, the central CIOS may stop the deployment. In other examples, the central CIOS may halt operations that are not a subset of the safety plan and may send commands to perform operations that are a subset of the safety plan.

At block 612, the central CIOS sends a notification to the user (eg, user 518 of FIG. 5) that the deployment does not comply with the safety plan. In response to determining that the operation is not a subset of the safety plan (as done at block 610), the central CIOS creates and sends to the user a notification that the deployment is no longer compliant with the safety plan. may The notification may present the user with the option of choosing to continue the deployment even though the action is not a subset of the safety plan. The user may choose to continue the deployment or may choose to abandon the deployment. If the user chooses to abandon the deployment, the user can create another configuration file and attempt a different deployment. Notifications sent to users may include deployments that do not comply with the safety plan if they wish to deploy resources to multiple execution targets. The central CIOS can send commands to perform operations determined to be a subset of operations.

FIG. 7 is a flowchart illustrating a process 700 for generating safety plans in a cloud infrastructure orchestration service, according to at least one embodiment. At block 702, a regional CIOS included in the region (eg, regional CIOS 522 of FIG. 5) receives a configuration file from the central CIOS (eg, central CIOS 506 of FIG. 5) for deploying infrastructure resources. The configuration file may include actions that include instructions for deploying resources to execution targets contained in the region.

At block 704, the regional CIOS identifies the new current state of the cloud infrastructure within the region. The configuration file may define the desired state of the cloud infrastructure within the region, and in response to receiving the configuration file, the regional CIOS may identify the current state of resources within the region. In some examples, the current state may be similar or identical to the desired state. In other examples, the current state may contain no resources and the desired state may contain most resources desired to be deployed to the execution target.

At block 706, the regional CIOS generates a safety plan for deploying infrastructure resources based on the comparison of the current state and the desired state. A safety plan may include actions that can be performed on an execution target. The actions may include deploying infrastructure resources to execution targets. In some instances where the current state and desired state are similar or identical, the safety plan compiled by the regional CIOS may be empty or may not contain any actions.

At block 708, the regional CIOS sends a security plan for deploying infrastructure resources to the central CIOS. In response to creating the safety plan, the regional CIOS may send the safety plan to the central CIOS for comparison. The central CIOS, similar to block 608 of process 600, may determine that the action to be performed on the execution target is a subset of the safety plan. In response to this determination, the regional CIOS may execute the operation and deploy the resources contained in the configuration file to the execution target.

FIG. 8 illustrates an example swimlane diagram showing a process 800 for performing CIOS techniques, in accordance with certain embodiments of the present disclosure. The process is depicted as a logic flow diagram, each act of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, operations may refer to computer-executable instructions stored on one or more computer-readable storage media that perform the recited operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be limiting, and any number of the described operations can be combined in any order and/or in parallel to perform a process. .

Further, process 800 can be executed under the control of one or more computing devices or computer systems made up of executable instructions, code collectively executed on one or more processors (e.g., executable instructions, one or more computer programs, or one or more applications), by hardware, or by any combination thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors. In some embodiments, process 800 can be executed in parallel by multiple processors. Computer-readable storage media may be non-transitory.

FIG. 8 is a swimlane diagram illustrating a process 800 for describing how safety plans are generated and used, according to at least one embodiment. The diagram includes three lanes, a user lane 802, a central lane 804, and a regional lane 806, as shown. User lane 802 may include actions performed by a user (eg, user 518 in FIG. 5) or commands given to the computing system by a user. Central lane 804 may include operations performed by a central CIOS (eg, central CIOS 506 of FIG. 5). Regional lane 806 may include operations performed by a regional CIOS (eg, regional CIOS 522 of FIG. 5).

Process 800 may begin at block 808 where a user creates a configuration file. A user may wish to deploy infrastructure resources to execution targets contained within a region. In response to this desire, the user can create a configuration file that can define the desired state of the execution target. At block 810, the user sends the settings to the central CIOS. In response to creating the configuration file, the user can send the configuration file to the central CIOS to initiate deployment.

At block 812, the central CIOS receives the configuration file from the user. In response to receiving the configuration file from the user, the central CIOS can initiate the deployment. At block 814, the central CIOS compiles a region independent (RA) configuration file. In response to initiating the deployment, the central CIOS may compile the RA settings, which may be configuration files that may be independent of the region to which the RA configuration files are sent. At block 816, the central CIOS sends the RA configuration file to the regional CIOS. In response to creating the RA configuration file, the central CIOS can send the RA configuration file to the regional CIOS in the region where the resource is desired to be deployed.

At block 818, the regional CIOS within the region where the resource is desired to be deployed receives the RA configuration file. An RA configuration file may contain actions to perform to deploy infrastructure resources to execution targets. The regional CIOS can send the RA configuration file to a worker node (eg, worker 526 in FIG. 5) that can perform the comparison. At block 820, the regional CIOS creates a security plan based on the new current state. Workers can compare the new current state of infrastructure resources in the region to the desired state of infrastructure resources defined in the RA configuration file. The regional CIOS can develop a safety plan based at least in part on comparisons performed by workers. A safety plan may include approved changes to resources in an execution target.

At block 822, the regional CIOS sends the security plan to the central CIOS. In response to creating the safety plan, the regional CIOS can send the safety plan to the central CIOS to determine if the action can be deployed to execution targets. At block 824, the central CIOS receives the security plan from the regional CIOS. In some instances where resources are desired to be deployed in multiple regions, the central CIOS may receive multiple safety plans. In this case, the central CIOS can compile one of the multiple safety plans, hereinafter referred to as the compiled safety plan. At block 826, the central CIOS compares the behavior of the deployment to the safety plan. A deployment operation may include instructions to deploy infrastructure resources to an execution target. In the case of a compiled safety plan, the central CIOS can compare operations with the compiled safety plan. At block 828, the central CIOS determines whether the action is a subset of the safety plan. In the case of a compiled safety plan, the central CIOS can determine if an action is a subset of the compiled safety plan.

At block 830, in response to the central CIOS determining that the action is a subset of the safety plan, the central CIOS sends a command to the regional CIOS to perform the action. In this case, infrastructure resources may be deployed to execution targets, and in the case of compiled safety plans, resources may be deployed to multiple execution targets. In other examples, the operation may not change the state of the execution target, in which case the central CIOS may take no action. At block 832, the central CIOS stops the deployment in response to the central CIOS determining that the operation is not a subset of the safe plan. In this case, the central CIOS sends a notification to the user that can inform the user that drift has occurred and that the operation is not in compliance with the safety plan. This notification allows the user to authorize the execution of the action. If the user chooses not to allow the operation to run, the user can either abandon the deployment or create a new configuration file, send the new configuration file to the central CIOS, and initiate a second deployment. can be done. For compiled safety plans, the central CIOS can send a notification to the user if the action is not a subset of the compiled safety plan.

FIG. 9 is a block diagram illustrating a cutting area 900 in accordance with at least one embodiment. Disconnection area 900 may be communicatively coupled to connected central CIOS 902 (eg, central CIOS 506 of FIG. 5). However, the connection between the disconnected area 900 and the connected central CIOS 902 may not be real-time and may be delayed. Disconnection region 900 includes central CIOS 904 (e.g., central CIOS 506 in FIG. 5), scheduler node 906 (e.g., scheduler 524 in FIG. 5), worker node 908 (e.g., worker 526 in FIG. 5), CIOS container 912 (e.g., worker 526 in FIG. 5). Docker 910 (eg, docker 530 of FIG. 5), which may include a CIOS container 532 of FIG. 5), and signing proxy 914 (eg, signing proxy 534 of FIG. 5). In some examples, disconnected area 900 may be able to receive information/instructions from connected central CIOS 902, but connected central CIOS 902 may be disconnected with respect to communications from disconnected area 900. . In other words, the communication may be one-way, and once the connected central CIOS 902 sends information, the disconnected region 900 cannot be sure what action to perform.

Central CIOS 904 can receive tasks from connected central CIOS 902 and can send tasks to scheduler 906 . Tasks may include executing CRUD operations or any other suitable task for deploying infrastructure resources within the region of the execution target(s). Scheduler 906 may send tasks to workers 908, which may be included in a worker fleet. A worker fleet can include many workers 908, and a scheduler 906 can select workers 908 with the least amount of work or the most available amount of computing resources to assign tasks. Scheduler 906 can assign tasks to workers 908 one at a time. Worker 908 can perform tasks and, in performing tasks, can make calls to CIOS container 912 contained in docker 910 . The CIOS container 912 is capable of executing tasks that include Terraform instructions. The instructions may direct API calls to cloud services 916, which may include services available to disconnected region 900 that may not be available over a public network (eg, the Internet). . To make an API call to cloud service 916, CIOS container 912 can send a request to make an API call to signing proxy 914, and signing proxy 914 can determine if the request is valid. can. In response to determining that the request is valid, signing proxy 914 may make an API call to cloud service 916 .

Connected central CIOS 902 can send a first safety plan and configuration files to central CIOS 904 for deployment of infrastructure resources on execution targets within disconnected region 900 . Central CIOS 904 can send the configuration file to scheduler 906, and scheduler 906 can assign tasks to workers 908 to create a second safety plan based on the configuration file. The first safety plan may be created from a different configuration file that is similar or identical to the configuration file. In response to creating the second safety plan, worker 908 can send the second safety plan to central CIOS 904, which can compare the first safety plan with the second safety plan. Central CIOS 904 may determine that the second safety plan is a subset of the first safety plan in response to the comparison. In this case, the second safety plan can be automatically approved and the infrastructure resources based on the configuration file deployed to execution targets within the cutting region 900 . Central CIOS 904 may determine that the second safety plan is not a subset of the first safety plan. In this case, the deployment may be halted and a notification sent to the user (eg, user 518 in FIG. 5) informing the user that drift may be occurring and that the deployment is not in compliance with the second safety plan. can be sent to Further, in this example, if the second safety plan is not a subset of the first safety plan, the connected central CIOS 902 instructs the disconnected region 900 to stop any originally planned deployments. can be sent.

FIG. 10 illustrates an example flow diagram illustrating a process 1000 for performing CIOS techniques, in accordance with certain embodiments of the present disclosure. The process is depicted as a logic flow diagram, each act of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, operations may refer to computer-executable instructions stored on one or more computer-readable storage media that perform the recited operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the acts are described is not intended to be limiting, and any number of the described acts may be combined in any order and/or in parallel to implement a process. can be done.

In addition, process 1000 can be executed under the control of one or more computing devices or computer systems made up of executable instructions and code that collectively executes on one or more processors (e.g., execution executable instructions, one or more computer programs, or one or more applications), by hardware, or by any combination thereof. As noted above, the code may be stored on a computer readable medium in the form of a computer program comprising instructions executable by one or more processors. In some embodiments, process 1000 can be executed in parallel by multiple processors. Computer-readable storage media may be non-transitory.

FIG. 10 is a flowchart illustrating a process 1000 for using a safety plan in a cutting area, according to at least one embodiment. At block 1002, a configuration file is received for deploying infrastructure resources to a first execution target and a second execution target. The configuration file may include infrastructure resources that a user (eg, user 518 of FIG. 5) wishes to deploy to the first execution target and the second execution target. In some examples, a configuration file may include resources for deployment at a first execution target and a second configuration file may include resources for deployment at a second execution target.

At block 1004, a first safety plan is generated based on the configuration file. A safety plan may include a list of approved changes that the user wishes to execute on the first execution target. The first safety plan may be generated by a central CIOS (eg, central CIOS 506 of FIG. 5). The first execution target may be included in the coverage area. A first safety plan may be created based on a comparison of a current state of the resource in the first execution target and a desired state of the resource in the first execution target that may be defined in a configuration file.

At block 1006, approval of the first safety plan is received. The user may be given the option of approving the first safety plan, or the first safety plan may be automatically approved based on actions performed on the first execution target. In response to approval at block 1006, infrastructure resources may be deployed to execution targets based on the configuration files.

At block 1008, a second safety plan is generated for a second execution target based on the configuration file. A second safety plan may be generated by a central CIOS, which may be included in a disconnection zone (eg, disconnection zone 900 in FIG. 9). A second execution target may also be included in the cutting region. In some examples, a second safety plan may be created for the second execution target based on the second configuration file. In some examples, the first execution target and the second execution target may be similar or identical, and the first safety plan and the second safety plan may be similar or identical.

At block 1010, the central CIOS determines whether the second safety plan is a subset of the first safety plan. A central CIOS can be included in the disconnection area and can compare the approved changes to the second safety plan with the approved changes to the first safety plan. The central CIOS may determine that the second safety plan is a subset of the first safety plan or that the second safety plan is not a subset of the first safety plan.

At block 1012, the second safety plan is automatically approved based on the approval of the first safety plan in accordance with the central CIOS' determination that the second safety plan is a subset of the first safety plan. be. The central CIOS will in this case execute the second safety plan without input from the user, as the first safety plan has already been approved and may have successfully executed the first safety plan. can be automatically approved. In some examples, the current state of the second execution target may be similar or the same as the desired state of the second execution target defined in the configuration file. In this example, the second safety plan may not include changes to execute on the second execution target. The second safety plan in this case may be automatically approved by the central CIOS because the empty second safety plan is a subset of the first safety plan.

At block 1014, upon the central CIOS determining that the second safety plan is not a subset of the first safety plan, the central CIOS stops deployment on the second execution target and the second safety plan is non-subset. Notify users that they are compliant. The central CIOS confirms that the deployment of infrastructure resources on the second execution target may be stopped, that drift may have occurred, and that the second safety plan is not a subset of the first safety plan. A notification can be sent to the user informing the user of the The notification can be presented to the user at a user interface that can present at least one difference between the first safety plan and the second safety plan. The notification indicates that the user (i) elected to deploy the resource despite the central CIOS determining that the second safety plan was non-compliant; (iii) submitting a new configuration file to initiate a new deployment in the second execution target, or a combination thereof.

At block 1016, in response to approval of the second safety plan by the central CIOS, the central CIOS transmits the second safety plan to a second execution target for deploying infrastructure resources. A central CIOS and a second execution target may be included in the disconnection region. A second safety plan may include instructions for deploying resources on a second execution target. In some examples, the current state of the second execution target may be similar or identical to the desired state of the execution target defined by the configuration file, so the second safety plan provides instructions to deploy the resource. may not be included. In this case, the central CIOS may take no action.

Exemplary Systems FIGS. 11-13 illustrate aspects of example environments for implementing aspects of the present disclosure, in accordance with various embodiments. FIG. 11 is a simplified diagram of a distributed system 1100 for implementing an embodiment of the present disclosure. In the illustrated embodiment, distributed system 1100 includes one or more client computing devices 1102 , 1104 , 1106 and 1108 , which are connected via one or more networks 1110 to web browsers, proprietary client (for example, Oracle Forms) is configured to run and operate. Server 1112 can be communicatively coupled to remote client computing devices 1102 , 11104 , 1106 and 1108 via network 1110 .

In various embodiments, server 1112 may be adapted to run one or more services or software applications, such as services and applications that provide identity management services. In particular embodiments, server 1112 may also provide other services or software applications, which may include non-virtual and virtual environments. In some embodiments, these services are provided to client computing devices 1102, 1104, 1106 and/or 1108 as web-based or cloud services, or under a Software as a Service (SaaS) model. provided to the user. Users operating client computing devices 11102, 1104, 1106 and/or 1108 may then utilize one or more client applications to interact with server 1112 and utilize the services provided by these components. .

In the configuration shown in FIG. 11, software components 1118 , 1120 and 1122 of system 1100 are shown running on server 1112 . In other embodiments, one or more of the components of system 1100 and/or the services provided by those components are also provided by one or more of client computing devices 1102, 11104, 1106 and/or 1108. client computing device. Users operating these client computing devices can then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be appreciated that a variety of different system configurations are possible and may differ from distributed system 1100 . The embodiment shown in FIG. 11 is thus an example of a distributed system for implementing the system of embodiments and is not intended to be limiting.

Client computing devices 1102, 1104, 1106 and/or 1108 may include various types of computing systems. For example, client computing devices run software (such as Microsoft Windows Mobile) and/or various mobile operating systems (such as iOS, Windows Phone, Android, Blackberry 10, Palm OS, etc.). Portable handheld devices (e.g. iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g. Google Glass head-mounted) type display). These client computing devices are capable of supporting a variety of applications (such as various Internet-related applications, e-mail, short message service (SMS) applications, etc.) and using various other communication protocols. The client computing devices may also include general-purpose personal computers, which may include various versions of Microsoft Windows®, Apple Macintosh® and/or Linux® operating systems, by way of example. including personal and/or laptop computers running versions. A client computing device may be a workstation computer running any of a variety of commercially available UNIX or UNIX-like operating systems, which may run on a variety of Including but not limited to GNU/Linux operating systems (eg, Google Chrome OS, etc.). Client computing devices may also be thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox with or without a Kinect® gesture input device) capable of communicating over network(s) 1110 . gaming consoles) and/or personal messaging devices.

Although the distributed system 1100 of FIG. 11 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with server 1112 .

Network(s) 1110 in distributed system 1100 may be any type of network familiar to those skilled in the art capable of supporting data communication using any of a variety of available protocols; These protocols include, but are not limited to, TCP/IP (Transmission Control Protocol/Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk, and the like. Solely by way of example, network(s) 1110 can be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual network, a virtual private network (VPN), an intranet, an extra network. Internet, public switched telephone network (PSTN), infrared network, wireless network (e.g., any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 protocol suite, Bluetooth® and/or other wireless protocols) network it operates under), and/or any combination of these and/or other networks.

Server 1112 includes one or more of a plurality of general purpose computers, dedicated server computers (examples include PC (personal computer) servers, UNIX servers, midrange servers, mainframe computers, rack mount servers, etc.). ), server farms, server clusters, or any other suitable arrangement and/or combination. Server 1112 may include one or more virtual machines running virtual operating systems or other computing architectures that include virtualization. One or more flexible pools of logical storage devices may be virtualized to maintain virtual storage devices for servers. The virtual network can be controlled by the server 1112 using software defined networking. In various embodiments, server 1112 may be adapted to run one or more services or software applications described in the foregoing disclosures. For example, server 1112 may correspond to a server for performing the above processing according to one embodiment of the present disclosure.

Server 1112 may run an operating system, including any of those listed above, and any commercially available server operating system. Server 1112 may also run any of a variety of additional server applications and/or middle-tier applications, such as HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, , CGI (Common Gateway Interface) servers, JAVA servers, and database servers. Examples of database servers include, but are not limited to, those marketed by Oracle, Microsoft, Sybase, International Business Machines (IBM), and the like.

In some implementations, server 1112 runs one or more applications for parsing and consolidating data feeds and/or event updates received from users of client computing devices 1102, 1104, 1106 and 1108. can contain. As an example, data feeds and/or event updates are received from one or more third party sources and continuous data streams, Twitter feeds, Facebook updates or real-time updates. These may include, but are not limited to, sensor data applications, stock tickers, network performance measurement tools (e.g. network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring may include real-time events related to Server 1112 may also include one or more applications for displaying data feeds and/or real-time events via one or more display devices of client computing devices 1102 , 1104 , 11106 and 1108 .

Distributed system 1100 may also include one or more databases 1114 and 1116 . These databases may provide mechanisms for storing information such as identity information and other information used by embodiments of the present disclosure. Databases 1114 and 1116 may reside in various locations. As an example, one or more of databases 1114 and 1116 may reside on non-transitory storage media local to (and/or residing within) server 1112 . Alternatively, databases 1114 and 1116 may be remote from server 1112 and communicate with server 1112 via network-based or dedicated connections. In one set of embodiments, databases 1114 and 1116 may reside within a storage area network (SAN). Similarly, any files necessary to perform functions attributable to server 1112 may be stored locally and/or remotely on server 1112, as appropriate. In one set of embodiments, databases 1114 and 1116 comprise relational databases, such as those provided by Oracle Corporation, adapted to store, update and retrieve data in response to SQL formatted commands. obtain.

FIG. 12 is a diagram illustrating an example computer system 1200 that can be used to implement an embodiment of the present disclosure. In some embodiments, computer system 1200 may be used to implement any of the various servers and computer systems described above. As shown in FIG. 12, computer system 1200 includes various subsystems, including processing subsystem 1204 , which communicates with multiple peripheral subsystems via bus subsystem 1202 . These peripheral subsystems may include processing acceleration unit 1206 , input/output subsystem 1208 , storage subsystem 1218 and communication subsystem 1224 . Storage subsystem 1218 may include tangible computer-readable storage media 1622 and system memory 1210 .

Bus subsystem 1202 provides a mechanism for allowing the various components and subsystems of computer system 1200 to communicate with each other as intended. Although bus subsystem 1202 is shown schematically as a single bus, alternate embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1202 can be any of several types of bus structures, including memory buses or memory controllers, peripheral buses, and local buses using any of a variety of bus architectures. including. For example, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the IEEE P1386.1 standard. such as a Peripheral Component Interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured in accordance with US Pat.

Processing subsystem 1204 controls the operation of computer system 1200 and may include one or more processing units 1232, 1234, and the like. A processing unit may include one or more processors, including single-core or multi-core processors, one or more cores of processors, or combinations thereof. In some embodiments, processing subsystem 1204 may include one or more special purpose co-processors such as graphics processors or digital signal processors (DSPs). In some embodiments, some or all of the processing units of processing subsystem 1204 can be implemented using customized circuitry such as an application specific integrated circuit (ASIC) or field programmable gate array (FPGA). be.

In some embodiments, the processing units within processing subsystem 1204 can execute instructions stored within system memory 1210 or on computer-readable storage media 1222 . In various embodiments, the processing unit may execute various programs or code instructions and may maintain multiple concurrently executing programs or processes. At any given time, some or all of the executed program code may reside in system memory 1210 and/or on computer readable storage media 1222, including on one or more storage devices, as the case may be. can be done. Through suitable programming, processing subsystem 1204 can provide the various functions described above for dynamically modifying documents (eg, web pages) in response to usage patterns.

In particular embodiments, processing acceleration unit 1206 is used to accelerate the overall processing performed by computer system 1200, to perform customized processing, or to perform one of the processing performed by processing subsystem 1204. may be provided for offloading units.

Input/output subsystem 1208 may include devices and mechanisms for inputting information into computer system 1200 and/or for outputting information from or through computer system 1200 . In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for entering information into computer system 1200 . User interface input devices are, for example, keyboards, pointing devices (such as mice or trackballs), touchpads or touchscreens built into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice command recognition systems , microphones, and other types of input devices. User interface input devices include motion-sensing and/or gesture-recognition devices that allow users to control and interact with input devices (such as the Microsoft Kinect® motion sensor), Microsoft Xbox® 360 game controllers, devices that provide an interface for receiving input using gestures and verbal commands. A user interface input device detects eye movements from a user (e.g., "blinking" while taking a picture and/or making a menu selection) and recognizes eye gestures as an input device (e.g., Google Glass). It may also include an eye gesture recognition device (such as the Google Glass® Blink Detector) that translates as input to the . Additionally, user interface input devices may include voice recognition sensing devices that allow users to interact with a voice recognition system (eg, Siri® navigator) via voice commands.

Other examples of user interface input devices include three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphics tablets, and audio/visual devices (speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, bar code readers 3D scanners, 3D printers, laser range finders, eye tracking devices, etc.). Further, user interface input devices may include medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasonography devices, and the like. User interface input devices may also include audio input devices such as, for example, MIDI keyboards and digital musical instruments.

User interface output devices may include display subsystems, indicator lights, or non-visual displays (such as audio output devices). Display subsystems can be cathode ray tubes (CRTs), flat panel devices (such as those that use liquid crystal displays (LCDs) or plasma displays), projection devices, touch screens, and the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1200 to a user or other computer. For example, user interface output devices include various display devices such as monitors, printers, speakers, headphones, automotive navigation systems, plotters, audio output devices and modems that visually convey text, graphics and audio/visual information. obtain, but are not limited to.

Storage subsystem 1218 provides a repository or data store for storing information used by computer system 1200 . Storage subsystem 1218 provides tangible, non-transitory computer-readable storage media for storing the basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the functions described above when executed by processing subsystem 1204 may be stored in storage subsystem 1218 . This software is executable by one or more processing units of processing subsystem 1204 . Storage subsystem 1218 may also provide a repository for storing data used in accordance with this disclosure.

Storage subsystem 1218 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown in FIG. 12, storage subsystem 1218 includes system memory 1210 and computer readable storage media 1222 . System memory 1210 may include a number of memories, including volatile main random access memory (RAM) for storing instructions and data during program execution, and non-volatile main random access memory (RAM) in which fixed instructions are stored. includes permanent read-only memory (ROM) or flash memory. In some implementations, the basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1200, such as during start-up, can be stored in ROM. The RAM may contain data and/or program modules currently being operated on and executed by processing subsystem 1204 . In some implementations, system memory 1210 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

By way of example, and not limitation, as shown in FIG. 12, system memory 1210 includes application programs 1212 (which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc.); program data 1214; , operating system 1216 . By way of example, operating system 1216 may include various versions of Microsoft Windows®, Apple Macintosh® and/or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including various GNU /Linux operating systems, Google Chrome OS, etc.) and/or mobile operating systems (iOS, Windows phones, Android OS, Blackberry ( 10 OS, and Palm ® OS operating systems).

Computer-readable storage media 1222 may store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 1204 causes the processor to provide the functions described above, may be stored in storage subsystem 1218 . By way of example, computer-readable storage medium 1222 may include non-volatile memory such as a hard disk drive, magnetic disk drive, optical disk drive (such as CD ROM, DVD, Blu-ray disc, etc.), or other optical media. Computer readable storage media 1222 can include Zip drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital video tapes, and the like, including but not limited to Not limited. The computer readable storage medium 1222 includes solid state drives (SSDs) based on nonvolatile memory (such as flash memory based SSDs, enterprise flash drives, solid state ROM, etc.), SSDs based on volatile memory (such as solid state RAM, dynamic RAM, static RAM, etc.), DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM-based SSDs and flash memory-based SSDs. Computer readable media 1222 may provide storage of computer readable instructions, data structures, program modules and other data for computer system 1200 .

In particular embodiments, the storage subsystem 1200 may also include a computer readable storage media reader 1220 that may further connect to computer readable storage media 1222 . Along with and optionally in combination with system memory 1210, computer-readable storage media 1222 are remote, local, fixed, and/or removable media for storing computer-readable information. Storage devices and storage media may be collectively referred to.

In particular embodiments, computer system 1200 may provide support for running one or more virtual machines. Computer system 1200 can execute programs such as a hypervisor to facilitate configuration and management of virtual machines. Each virtual machine may be allocated memory, computation (eg, processors, cores), input/output, and networking resources. Each virtual machine may run its own operating system, which may be the same as or different from the operating systems run by other virtual machines run by computer system 1200 . Thus, multiple operating systems may be run by computer system 1200 at the same time. Each virtual machine generally operates independently of other virtual machines.

Communications subsystem 1224 provides an interface to other computer systems and networks. Communications subsystem 1224 serves as an interface for sending and receiving data between other systems and computer system 1200 . For example, communications subsystem 1224 may enable computer system 1200 to establish a communications channel to one or more client devices over the Internet for sending and receiving information to and from the client devices. Additionally, the communications subsystem 1224 may be used to convey notification of a successful login or notification from a privileged account manager to the requesting user to re-enter the password.

Communication subsystem 1224 may support both wired and/or wireless communication protocols. For example, in certain embodiments, the communications subsystem 1224 may include (eg, cellular telephony, advanced data network technologies such as 3G, 4G or enhanced data rates for global evolution (EDGE)), WiFi (IEEE 802.11 family of standards) radio frequency (RF) transceiver components, global positioning system (GPS) receiver components for accessing wireless voice and/or data networks, using other mobile communication technologies, or any combination thereof; and/or may include other components. In some embodiments, communication subsystem 1224 may provide a wired network connection (eg, Ethernet) in addition to or instead of a wireless interface.

Communication subsystem 1224 can send and receive data in a variety of formats. For example, in some embodiments, communications subsystem 1224 may receive input communications in the form of structured and/or unstructured data feeds 1226, event streams 1228, event updates 1230, and the like. . For example, the communication subsystem 1224 may receive data feeds 1226 and/or other communication services (Twitter® feeds, Facebook® updates, web feeds (rich sites) in real-time from users of social media networks. summary (RSS) feeds) and/or real-time updates from one or more third party sources).

In certain embodiments, the communications subsystem 1224 may be configured to receive data in the form of a continuous data stream, which is continuous or infinite in nature with no definite end. An event stream 1228 of possible real-time events and/or event updates 1230 may be included. Examples of applications that generate continuous data include, for example, sensor data applications, stock tickers, network performance measurement tools (eg, network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring. can be done.

Communication subsystem 1224 also stores structured and/or unstructured data feeds 1226, event It can be configured to output streams 1228, event update information 1230, and the like.

Computer system 1200 can be used for handheld portable devices (eg, iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (eg, Google Glass® head-mounted displays). ), personal computers, workstations, mainframes, kiosks, server racks, or other data processing systems.

Due to the ever-changing nature of computers and networks, the description of computer system 1200 shown in FIG. 12 is intended to be exemplary only. Many other configurations are possible, having more or fewer components than the system shown in FIG. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other aspects and/or methods for implementing various embodiments.

The system shown in some figures may be provided in various configurations. In some embodiments, these systems may be configured as distributed systems in which one or more components of the system are distributed across one or more networks within one or more cloud infrastructure systems.

A cloud infrastructure system is a collection of one or more server computing devices, network devices and/or storage devices. These resources may be divided by the cloud service provider and allocated in some way to its customers. For example, a cloud service provider (such as Oracle Corporation of Redwood Shores, Calif.) offers one or more services offered under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) services provided under the Infrastructure as a Service (IaaS) category, or other categories of services, including hybrid services. type of cloud services. Examples of SaaS services include, but are not limited to, the ability to build and deliver a suite of on-demand applications such as Oracle Fusion applications. SaaS services allow customers to take advantage of applications running on cloud infrastructure systems without having to purchase the software for those applications. Examples of PaaS services include services for organizations (such as Oracle) to integrate existing applications onto a shared common architecture, as well as services provided by platforms such as Oracle Java Cloud Services (JCS) and Oracle Database Cloud Services (DBCS). These include, but are not limited to, the ability to build new applications that leverage shared services provided by IaaS services can facilitate management and control of basic computing resources such as storage, networks and other basic computing resources for customers who utilize services provided by SaaS and PaaS platforms. .

FIG. 13 is a simplified block diagram illustrating one or more components of a system environment 1300 in which services provided by one or more components of the system of embodiments may be provided as cloud services, in accordance with one embodiment of the present disclosure. be. In the illustrated embodiment, the system environment 1300 includes one or more client computing devices 1304, 1306, and 1308 that interact with a cloud infrastructure system 1302 that provides cloud services. can be used by the user to These client computing devices may be configured to run a web browser, a proprietary client application (eg, a client application such as Oracle Forms, or some other application, etc.), which may be used by cloud infrastructure system 1302. can be used by users of client computing devices to interact with and use services provided by cloud infrastructure system 1302 .

It should be appreciated that the illustrated cloud infrastructure system 1302 may have components other than those shown. Additionally, the illustrated embodiment is only one example of a cloud infrastructure system that may incorporate an embodiment of the present disclosure. In some other embodiments, cloud infrastructure system 1302 may have more or fewer components than those shown in the figure, may combine two or more components, or It may have different configurations or arrangements of components.

Client computing devices 1304 , 1306 and 1308 can be devices similar to those described above for client computing devices 1102 , 1104 , 1106 and 1108 .

Although the example system environment 1300 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with cloud infrastructure system 1302 .

Network(s) 1310 may facilitate communication and exchange of data between clients 1304 , 1306 and 1308 and cloud infrastructure system 1302 . Each network is any type of network familiar to those skilled in the art capable of supporting data communication using any of a variety of commercially available protocols, including those described above for network(s) 1110. obtain.

Cloud infrastructure system 1302 may comprise one or more computers and/or servers, which may include those described above for server 1112 .

In certain embodiments, the services provided by the cloud infrastructure system include a number of services made available to users of the cloud infrastructure system on demand (online data storage and backup solutions, web-based email services, hosted office suite and document collaboration services, database processing, managed technical support services, etc.). Services provided by cloud infrastructure systems can be dynamically scaled to meet the needs of their users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, any service that is made available to users from a cloud service provider's system over a communication network such as the Internet is referred to as a "cloud service." In a public cloud environment, the servers and systems that make up a cloud service provider's system are distinct from the customer's own on-premises servers and systems. For example, a cloud service provider's system can host the application, and users can order and use the application on demand over a communication network such as the Internet.

In some examples, the services in the computer network cloud infrastructure are storage, hosted databases, hosted web servers, software applications, or other services provided to users by cloud vendors or otherwise in the art. may include protected computer network access to other services such as those known in . For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a web services-based hosted relational database and scripting language middleware engine for personal use by networked developers. As another example, a service may include access to an email software application hosted at a cloud vendor's website.

In particular embodiments, cloud infrastructure system 1302 is a set of cloud infrastructures provided to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. May include application, middleware, and database service offerings. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the Assignee.

In various embodiments, cloud infrastructure system 1302 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by cloud infrastructure system 1302 . Cloud infrastructure system 1302 may provide cloud services via different deployment models. For example, services may be under a public cloud model where the cloud infrastructure system 1302 is owned by an organization that sells cloud services (e.g., owned by Oracle Corporation) and the services are made available to the general public or to companies in different industries. may be provided. As another example, services may be provided under a private cloud model where cloud infrastructure system 1302 may operate solely for a single organization and may provide services for one or more entities within that organization. good. Cloud services may also be provided under a community cloud model in which the cloud infrastructure system 1302 and the services provided by the cloud infrastructure system 1302 are shared by several organizations in related communities. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

In some embodiments, the services provided by the cloud infrastructure system 1302 are in the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (PaaS) category, It may include one or more services provided under a service (IaaS) category, or other categories of service, including hybrid services. A customer may order one or more services provided by cloud infrastructure system 1302 via a subscription order. Cloud infrastructure system 1302 then performs processing to provide the service in the customer's subscription order.

In some embodiments, services provided by cloud infrastructure system 1302 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided via a SaaS platform by a cloud infrastructure system. A SaaS platform can be configured to provide cloud services that fall under the SaaS category. For example, a SaaS platform may provide the ability to build and deliver a suite of on-demand applications on an integrated development and deployment platform. A SaaS platform may manage and control the underlying software and infrastructure for providing SaaS services. By using the services provided by the SaaS platform, customers can take advantage of applications running on cloud infrastructure systems. Customers can acquire application services without having to purchase separate licenses and support. A variety of different SaaS services may be offered. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise consolidation, and business flexibility for large organizations.

In some embodiments, platform services may be provided via a PaaS platform by a cloud infrastructure system. A PaaS platform can be configured to provide cloud services that fall under the PaaS category. Examples of platform services include services that enable organizations (such as Oracle) to integrate existing applications on a shared common architecture, and build new applications that leverage shared services provided by the platform. This includes, but is not limited to, functions that A PaaS platform may manage and control the underlying software and infrastructure for providing PaaS services. Customers can acquire PaaS services provided by cloud infrastructure systems without having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Services (JCS) and Oracle Database Cloud Services (DBCS).

By utilizing the services provided by the PaaS platform, customers can use programming languages and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (eg, Oracle Fusion middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that allows an organization to pool database resources and offer customers a database-as-a-service in the form of a database cloud. In the cloud infrastructure system, middleware cloud services can provide a platform for customers to develop and deploy various business applications, and Java cloud services can provide a platform for customers to deploy Java applications. , can be provided in a cloud infrastructure system.

Various different infrastructure services can be provided in the cloud infrastructure system by the IaaS platform. Infrastructure services facilitate the management and control of basic computing resources (such as storage, networks and other basic computing resources) for customers using services provided by SaaS and PaaS platforms. to

In particular embodiments, cloud infrastructure system 1302 may also include infrastructure resources 1330 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources 1330 may include a pre-integrated and optimized combination of hardware (such as servers, storage and networking resources) for running the PaaS platform and services provided by the SaaS platform.

In some embodiments, resources within the cloud infrastructure system 1302 can be shared by multiple users and dynamically reallocated on a per demand basis. Additionally, resources can be allocated to users in different time zones. For example, cloud infrastructure system 1302 allows a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a certain amount of time and then It may allow reassignment of the same resource to different sets of users who want to maximize resource utilization.

In certain embodiments, multiple internal shared services 1332 are provided that are shared by various components or modules of the cloud infrastructure system 1302 and shared by services provided by the cloud infrastructure system 1302. . These internal shared services are security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services to enable cloud support, email It may include, but is not limited to, services, notification services, file transfer services, and the like.

In particular embodiments, cloud infrastructure system 1302 may provide comprehensive management of cloud services (eg, SaaS, PaaS, and IaaS services) in cloud infrastructure systems. In one embodiment, cloud management functions may include functions such as provisioning, managing, and tracking customer subscriptions received by cloud infrastructure system 1302 .

In one embodiment, as shown, the cloud management function includes one or more modules such as an order management module 1320, an order orchestration module 1322, an order provisioning module 1324, an order management and monitoring module 1326, and an identity management module 1328. can be provided by a module. These modules may include or be provided with one or more computers and/or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or other Any suitable arrangement and/or combination may be used.

In example operation 1334 , a customer requests one or more services provided by cloud infrastructure system 1302 by placing an order for a subscription to one or more services provided by cloud infrastructure system 1302 . , client devices 1304 , 1306 or 1308 may be used to interact with cloud infrastructure system 1302 . In certain embodiments, a customer may access cloud user interfaces (UIs), namely cloud UI 1312, cloud UI 1314 and/or cloud UI 1316, and place subscription orders through these UIs. The order information received by cloud infrastructure system 1302 in response to the customer placing an order identifies the customer and one or more services provided by cloud infrastructure system 1302 to which the customer wishes to subscribe. It may contain identifying information.

After the order is placed by the customer, the order information is received via cloud UI 1312, 1314 and/or 1316.

At operation 1336 , the order is saved in order database 1318 . Order database 1318 may be one of several databases operated by cloud infrastructure system 1302 and operated in conjunction with other system elements.

At operation 1338 the order information is transferred to order management module 1320 . In some examples, the order management module 1320 is configurable to perform order-related billing and accounting functions, such as validating an order and reserving the order upon validation.

At operation 1340 information about the order is communicated to order orchestration module 1322 . Order orchestration module 1322 may utilize order information to orchestrate the provisioning of services and resources to orders placed by customers. In some examples, order orchestration module 1322 may use the services of order provisioning module 1324 to orchestrate provisioning of resources to support subscribed services.

In particular embodiments, order orchestration module 1322 enables management of business processes associated with each order and applies business logic to determine whether an order should proceed to provisioning. At operation 1342, upon receiving an order for a new subscription, the order orchestration module 1322 directs the order provisioning module 1324 to allocate resources and configure those resources needed to fulfill the subscription order. Send a request to The order provisioning module 1324 enables allocation of resources for services ordered by customers. Order provisioning module 1324 provides a level of abstraction between the cloud services provided by cloud infrastructure system 1302 and the physical implementation layer used to provision the resources to provide the requested service. . This allows the order orchestration module 1322 to be decoupled from implementation details such as whether services and resources are actually provisioned on-the-fly, or whether services and resources are pre-provisioned and only allocated/allocated on demand. .

At operation 1344 , once the services and resources are provisioned, a notification of the services provided may be sent by the order provisioning module 1324 of the cloud infrastructure system 1302 to the customer on the client device 1304 , 1306 and/or 1308 . At operation 1346 , the customer's subscription orders may be managed and tracked by order management and monitoring module 1326 . In some examples, the order management and monitoring module 1326 monitors the service availability in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime. Configurable to collect usage statistics.

In particular embodiments, cloud infrastructure system 1302 may include identity management module 1328 . Identity management module 1328 is configurable to provide identity services such as access management and authorization services in cloud infrastructure system 1302 . In some embodiments, identity management module 1328 may control information about customers who desire to use services provided by cloud infrastructure system 1302 . Such information includes information that authenticates the identities of such customers and what actions those customers perform on various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). may contain information describing what is authorized. Identity management module 1328 may also include management of descriptive information about each customer and how and by whom that descriptive information can be accessed and modified.

Although specific embodiments of the disclosure have been described, various modifications, alterations, alternative constructions and equivalents are also encompassed within the scope of the disclosure. Embodiments of the present disclosure are not limited to operation within any particular specific data processing environment, but are free to operate within multiple data processing environments. Furthermore, while embodiments of the present disclosure have been described using a particular series of transactions and steps, it will be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. should be. Various features and aspects of the above-described embodiments may be used individually or together.

Furthermore, although embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. is. Embodiments of the present disclosure may be implemented in hardware only, may be implemented in software only, or may be implemented using a combination thereof. The various processes described herein may be implemented on the same processor or may be implemented on different processors in any combination. Thus, although a component or module is described as being configured to perform a particular operation, such configuration may be accomplished by designing electronic circuitry to perform the operation, for example. It can be accomplished by programming a programmable electronic circuit (such as a microprocessor) to do so, or by any combination thereof. Processes can communicate using a variety of techniques including, but not limited to, conventional techniques for interprocess communication, and different process pairs may use different techniques, or the same process pair may communicate using different techniques. Different techniques may be used for timing.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions and other variations and modifications may be made without departing from the broader spirit and scope of the claims. Accordingly, while specific embodiments of the disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims. These variations include any relevant combination of the disclosed features.

A number of illustrative items of this disclosure are described below.
Item 1: A method comprising:
at least one of the plurality of computer processors receiving a safety plan including a list of resources and respective actions based at least in part on the deployment configuration file;
Upon receipt of instructions for approval of the safety plan,
preparing at least one of the plurality of computer processors to perform operations corresponding to at least one of the list of resources according to the deployment configuration file;
comparing the operation to a safety plan;
at least one of the plurality of computer processors performing an action according to the determination that the action is part of the safety plan;
Subject to the determination that the action is not part of the safety plan,
stopping the deployment on at least one of the plurality of computer processors;
at least one of a plurality of computer processors sending a notification that the deployment is not in compliance with the safety plan.

Item two. The method of item 1, wherein multiple processors are associated with the execution target.

Item 3. 3. The method of item 2, wherein the execution targets include geographic regions.
Item 4. The method of item 1, wherein the deployment configuration file is received from a central cloud infrastructure orchestration service.

Item 5. 5. The method of item 4, wherein the deployment configuration file is generated by a user of a central cloud infrastructure orchestration service.

Item 6. each operation comprises at least one of a create operation, an update operation, or a delete operation performed on or associated with at least one resource of the list of resources; The method of item 1.

Item 7. The method of claim 1, further comprising at least one of the plurality of computer processors halting deployment upon receipt of safety plan disapproval or non-receipt of safety plan approval.

Item 8. At least one of the plurality of computer processors further comprising generating a local plan having local actions according to the deployment configuration file, wherein comparing the actions to the safety plan compares one of the local actions to the safety plan. The method of item 1, comprising comparing.

Item 9. A computer-readable storage medium having instructions written thereon that, when executed by a computer processor, cause the computer processor to perform an action, the action comprising:
receiving a safety plan including a list of resources and their respective actions based at least in part on a deployment configuration file;
Upon receipt of instructions for approval of the safety plan,
preparing to perform an action corresponding to at least one of the list of resources according to the deployment configuration file;
comparing the action to a safety plan; and
performing the action according to the determination that the action is part of the safety plan;
stop the deployment following a determination that the operation is not part of the safety plan;
sending a notification that the deployment is not in compliance with the safety plan.

Item ten. 10. The computer-readable storage medium of item 9, wherein the deployment configuration file is generated by a central cloud infrastructure orchestration service.

Item eleven. 11. The computer of item 10, wherein the central cloud infrastructure orchestration service is configured to generate a list of safety plans, each safety plan in the list of safety plans corresponding to a particular execution target or a particular deployment phase. readable storage medium.

Item 12. 12. The computer-readable storage medium of item 11, wherein the central cloud infrastructure orchestration service is further configured to concurrently generate the list of safety plans prior to receiving approval or disapproval of the list of safety plans.

Item thirteen. the central cloud infrastructure orchestration service is configured to generate a plurality of deployment configuration files, each deployment configuration file of the plurality of deployment configuration files being interpreted for each execution target on the list of safety plans; 13. The computer-readable storage medium of item 12.

Item 14. 11. The computer-readable storage medium of item 10, the action further comprising sending the safety plan to a central cloud infrastructure orchestration service.

Item 15. A central cloud infrastructure orchestration service
Rendering the safety plan on the user computer user interface,
15. The computer readable storage medium of item 14, configured to receive approval or disapproval of the safety plan.

Item 16. a system,
a processor;
a memory storing instructions which, when executed by the processor, cause the system to:
receiving a safety plan including a list of resources and their respective actions based at least in part on a deployment configuration file;
Upon receipt of instructions for approval of the safety plan,
preparing to perform an action corresponding to at least one of the list of resources according to the deployment configuration file;
compare the operation to the safety plan,
perform the action according to the determination that the action is part of the safety plan;
Subject to the determination that the action is not part of the safety plan,
stop the deployment,
A system that is configured to send notifications that a deployment is out of compliance with the safety plan.

Item 17. The action is one of a plurality of actions corresponding to at least one of the list of resources according to the deployment configuration file, each action of the plurality of actions being performed at least until the deployment is complete or until a stoppage of the deployment occurs. , is compared with the safety plan.

Item 18. 17. The system of item 16, wherein the action is not part of a safety plan based at least in part on a change in action that occurred in one of the resources before the action was performed.

Item 19. 17. The system of item 16, wherein the deployment configuration files are generated by a central cloud infrastructure orchestration service.

Item 20. 20. The system of item 19, wherein notifications are sent to users of a central cloud infrastructure orchestration service.

Item 21. Apparatus comprising means for the steps according to any one of items 1-8.
Item 22. a method,
at least one of the plurality of computer processors receiving a configuration file for deployment to the first execution target and the second execution target;
at least one of the plurality of computer processors generating a first safety plan for the first execution target, the first safety plan being based at least in part on the configuration file for the first execution target. including a first list of resources and respective operations associated with the deployment in the method, the method further comprising:
at least one of the plurality of computer processors receiving approval of the first safety plan;
at least one of the plurality of computer processors generating a second safety plan for a second execution target, the second safety plan based at least in part on the configuration file for the second execution target. including a second list of resources and respective actions associated with the deployment in the method, the method further comprising:
at least one of the plurality of computer processors determining whether the second safety plan is a subset of the first safety plan;
According to a determination that the second safety plan is a subset of the first safety plan,
at least one of the plurality of computer processors automatically approving a second safety plan based at least in part on approval of the first safety plan;
at least one of the plurality of computer processors sending the automatically approved second safety plan to the second execution target.

Item 23. Following a determination that the second safety plan is not a subset of the first safety plan,
a notification indicating that the second safety plan is not a subset of the first safety plan;
23. The method of clause 22, further comprising providing a user interface for presenting a second list of resources and respective actions associated with the second safety plan.

Item 24. further comprising determining at least one difference between the second list of resources and respective actions of the second safety plan and the first list of resources and respective actions of the first safety plan; 24. The method of item 23.

Item 25. Item 24, further comprising providing a user interface for presenting at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan. The method described in .

Item 26. Determining whether the second safety plan is a subset of the first safety plan includes determining whether at least one of the plurality of computer processors performs a second safety plan on the resources of the second safety plan and the respective operations. 23. The method of item 22, comprising determining whether each resource and respective operation of the list is listed in the first list of resources and respective operations of the first safety plan.

Item 27. 23. The method of item 22, wherein the first execution target is a connectivity region of a cloud infrastructure orchestration service.

Item 28. Item 29. The method of item 27, wherein the second execution target is a disconnected region of the cloud infrastructure orchestration service. 29. The method of clause 28, wherein the cutting zone includes an environment configured to receive instructions to deploy to the cutting zone, and wherein the cutting zone is further configured not to transmit any data outside the cutting zone. .

Item 30. 29. The method of item 28, wherein the second secure plan is for deployment on the second execution target.

Item 31. 31. The method of item 30, wherein the second safety plan is automatically approved further pursuant to a determination that deployment at the first execution target based at least in part on the first safety plan was successful.

Item 32. A computer-readable storage medium having instructions written thereon which, when executed by a computer processor, cause the computer processor to execute instructions, the instructions comprising:
receiving a configuration file for deployment to the first execution target and the second execution target;
generating a first safety plan for the first execution target, the first safety plan including resources and respective behaviors associated with deployment in the first execution target based at least in part on the configuration file; The instruction further includes a first list of
receiving approval of the first safety plan;
and generating a second safety plan for the second execution target, the second safety plan based at least in part on the configuration file with resources and respective behaviors associated with deployment in the second execution target. The instruction further includes a second list of
determining whether the second safety plan is a subset of the first safety plan;
According to a determination that the second safety plan is a subset of the first safety plan,
automatically approving a second safety plan based at least in part on approval of the first safety plan;
sending the automatically approved second safety plan to the second execution target.

Item 33. The instructions further follow a determination that the second safety plan is not a subset of the first safety plan,
a notification indicating that the second safety plan is not a subset of the first safety plan;
33. The computer-readable storage medium of item 32, including providing a user interface for presenting a second list of resources and respective actions associated with the second safety plan.

Item 34. The instructions further determine at least one difference between the second list of resources and respective actions of the second safety plan and the first list of resources and respective actions of the first safety plan. 34. The computer-readable storage medium of item 33, comprising:

Item 35. The instructions further include providing a user interface for presenting at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan. 35. The computer-readable storage medium of claim 34, item 34.

Item 36. The second execution target is a disconnection region of the cloud infrastructure orchestration service, the disconnection region including an environment configured to receive instructions to deploy to the disconnection region, the disconnection region further outside the disconnection region 33. The computer-readable storage medium of item 32, configured not to transmit any data at.

Item 37. The second safety plan is for deployment at the second execution target, the second safety plan being based at least in part on the first safety plan for successful deployment at the first execution target. 37. The computer-readable storage medium of item 36, which is automatically approved further according to the determination.

Item 38. a system,
a processor;
a memory storing instructions, the instructions being executed by the processor to:
receiving a configuration file for deployment to the first execution target and the second execution target;
Configuring the system to generate a first safety plan for the first execution target, the first safety plan including resources associated with deployment at the first execution target based at least in part on the configuration file and respective The instruction further includes a first list of actions and
receiving approval of the first safety plan;
Configuring the system to generate a second safety plan for the second execution target, the second safety plan including resources associated with deployment at the second execution target based at least in part on the configuration file and respective including a second list of actions, the instruction further comprising:
determining if the second safety plan is a subset of the first safety plan;
According to a determination that the second safety plan is a subset of the first safety plan,
automatically approving a second safety plan based at least in part on approval of the first safety plan;
A system that configures the system to send the automatically approved second safety plan to a second execution target.

Item 39. The system follows a determination that the second safety plan is not a subset of the first safety plan,
presenting a notice indicating that the second safety plan is not a subset of the first safety plan;
39. The system of item 38, configured to provide a user interface for presenting a second list of resources and respective actions associated with the second safety plan.

Item 40. The system further
determining at least one difference between a second list of resources and respective actions of the second safety plan and a first list of resources and respective actions of the first safety plan;
configured to provide a user interface for presenting at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan; 40. The system of item 39.

Item 41. The second execution target is a disconnection region of the cloud infrastructure orchestration service, the disconnection region including an environment configured to receive instructions to deploy to the disconnection region, the disconnection region further outside the disconnection region and the second safety plan is for deployment at the second execution target, the second safety plan being based at least in part on the first safety plan 39. The system of item 38, wherein the system is automatically approved further pursuant to the determination that the deployment at the first execution target was successful.

Item 42. Apparatus comprising means for the steps according to any one of items 22-31.

Claims (21)

a method,
at least one of the plurality of computer processors receiving a configuration file for deployment to the first execution target and the second execution target;
at least one of the plurality of computer processors generating a first safety plan for the first execution target, the first safety plan being based at least in part on the configuration file; including a first list of resources and respective operations associated with deployment on the first execution target, the method further comprising:
at least one of the plurality of computer processors receiving approval of the first safety plan;
at least one of the plurality of computer processors generating a second safety plan for the second execution target, the second safety plan being based at least in part on the configuration file. including a second list of resources and respective operations associated with deployment on the second execution target, the method further comprising:
at least one of the plurality of computer processors determining whether the second safety plan is a subset of the first safety plan;
Following a determination that the second safety plan is a subset of the first safety plan,
at least one of the plurality of computer processors automatically approving the second safety plan based at least in part on approval of the first safety plan;
at least one of the plurality of computer processors transmitting the automatically approved second safety plan to the second execution target. Following a determination that the second safety plan is not a subset of the first safety plan,
a notification indicating that the second safety plan is not a subset of the first safety plan;
2. The method of claim 1, further comprising providing a user interface for presenting the second list of resources and respective actions associated with the second safety plan. determining at least one difference between the second list of resources and respective actions of the second safety plan and the first list of resources and respective actions of the first safety plan; 3. The method of claim 2, further comprising: Further providing the user interface for presenting the at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan. 4. The method of claim 3, comprising: Determining whether the second safety plan is a subset of the first safety plan includes: determining whether at least one of the plurality of computer processors uses the resources of the second safety plan and their respective operations; determining whether each resource and respective action of the second list of is listed in the first list of resources and respective actions of the first safety plan. A method according to any one of the preceding claims. 4. A method according to any one of the preceding claims, wherein said first execution target is a connectivity region of a cloud infrastructure orchestration service. 7. The method of claim 6, wherein the second execution target is a disconnected region of the cloud infrastructure orchestration service. 12. The disconnection zone comprises an environment configured to receive instructions to deploy in the disconnection zone, the disconnection zone further configured not to transmit any data outside of the disconnection zone. 7. The method according to 7. 9. The method of claim 7 or 8, wherein said second secure plan is for deployment on said second execution target. 10. The second safety plan of claim 9, wherein the second safety plan is automatically approved further following a determination that deployment at the first execution target based at least in part on the first safety plan was successful. Method. A computer-readable storage medium having instructions written thereon that, when executed by a computer processor, cause the computer processor to execute instructions, the instructions comprising:
receiving a configuration file for deployment to the first execution target and the second execution target;
and generating a first safety plan for the first execution target, the first safety plan based at least in part on the configuration file with resources associated with deployment in the first execution target. a first list with respective actions, the instructions further comprising:
receiving approval of the first safety plan;
and generating a second safety plan for the second execution target, the second safety plan based at least in part on the configuration file with resources associated with deployment in the second execution target. a second list with respective actions, the instructions further comprising:
determining whether the second safety plan is a subset of the first safety plan;
Following a determination that the second safety plan is a subset of the first safety plan,
automatically approving the second safety plan based at least in part on approval of the first safety plan;
and sending the automatically approved second safety plan to the second execution target. The instructions further follow a determination that the second safety plan is not a subset of the first safety plan.
a notification indicating that the second safety plan is not a subset of the first safety plan;
12. The computer-readable storage medium of claim 11, comprising providing a user interface for presenting the second list of resources and respective actions associated with the second safety plan. The instructions further comprise at least one of the second list of the second safety plan resources and respective actions and the first list of the first safety plan resources and respective actions. 13. The computer-readable storage medium of claim 12, comprising determining a difference. The instructions further display the user interface for presenting the at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan. 14. The computer-readable storage medium of claim 13, comprising preparing. The second execution target is a disconnected region of the cloud infrastructure orchestration service, the disconnected region includes an environment configured to receive instructions to deploy to the disconnected region, and the disconnected region further comprises: , is configured not to transmit any data outside the cutting zone. the second safety plan is for the deployment at the second execution target, the second safety plan being based at least in part on the first safety plan at the first execution target 16. The computer-readable storage medium of claim 15, wherein the computer-readable storage medium of claim 15 is automatically approved further according to a determination that the deployment in has been successful. a system,
a processor;
a memory storing instructions, the instructions being executed by the processor to:
receiving a configuration file for deployment to the first execution target and the second execution target;
configuring the system to generate a first safety plan for the first execution target, the first safety plan relating to deployment in the first execution target based at least in part on the configuration file; a first list of resources and respective operations to be performed, the instructions further comprising:
receiving approval of the first safety plan;
configuring the system to generate a second safety plan for the second execution target, the second safety plan relating to deployment in the second execution target based at least in part on the configuration file; including a second list of resources and respective operations to perform, the instructions further comprising:
determining whether the second safety plan is a subset of the first safety plan;
Following a determination that the second safety plan is a subset of the first safety plan,
automatically approving the second safety plan based at least in part on approval of the first safety plan;
and configuring the system to transmit the automatically approved second safety plan to the second execution target. The system further, according to a determination that the second safety plan is not a subset of the first safety plan,
presenting a notification indicating that the second safety plan is not a subset of the first safety plan;
18. The system of claim 17, configured to provide a user interface for presenting the second list of resources and respective actions associated with the second safety plan. The system further includes:
determining at least one difference between the second list of resources and respective actions of the second safety plan and the first list of resources and respective actions of the first safety plan;
configured to provide the user interface for presenting the at least one difference above all other visual representations of the second list of resources and respective actions of the second safety plan; 19. The system of claim 18, wherein: The second execution target is a disconnected region of the cloud infrastructure orchestration service, the disconnected region includes an environment configured to receive instructions to deploy to the disconnected region, and the disconnected region further comprises: , wherein the second safety plan is for deployment at the second execution target, and the second safety plan is configured to not transmit any data outside the disconnection zone; 20. The system of any one of claims 17-19, automatically approved further pursuant to a determination that deployment at the first execution target based at least in part on one safety plan was successful. Apparatus comprising means for the steps of any one of claims 1-10.

Images