Kickstart Application Deployments on Oracle Cloud Infrastructure (OCI)
Introduction
With a new generation of cloud infrastructure, hyperscale offerings have taken a leap and become managed infrastructure platforms for enterprise workloads. Oracle Cloud Infrastructure (OCI) addresses the need for advanced control with dedicated resources and isolated networks. A progammable controller enables operators to increase operational efficiency with "Infrastructure as Code" (IaC) and the framework enables them to contain investment risks for the development of new services with continous architecture practices. While launching a public cloud server has become a matter of pressing a button, a hosting platform for intra- and extranet services needs to address advanced security and compliance requirements of a private infrastructure stack. Traditionally requirements engineers translate operational benefits into reduced cost, decreased time-to-market and increased revenue for the business. In cloud implementations agile methods keep the service delivery aligned with the evolving needs of the business. This framework provides a middleground. The separation of service configurations and service assets facilitates modern CI/CD pipilines and the modular approach allows to adopt with itterative implementation steps even for hardware resources. But the construct of a service residents allows to merge company specific operator controls into the provisioning process and reflects the need for "multi-tenant" operations in a single teanancy. It also enables IT departments to preserve separate administration domains for shared services. Executing automation scripts with the Oracle’s Resource Manager (ORM) protects state information, provides a graphical user interfaces and a REST-API to build self-service portals for service owners.
Architecture
The architecture of a cloud tenancy addresses security, scalability, performance, and resiliency requirements. The framework allows architects to abstract at an appropriate level to make business and technical decisions, and to facilitate the analysis of platform capbilities and to compare design config. It provides the guiding principles for the development of service assets. Meanwhile operations engineers focus on building reusable service assets, and system administrator provide the appropriate service configuration that will be merged into deployment plans. The framework provides a baseline configuration to support ad-hoc deployments, but separates service design and infrastructure automation with provisioning instructions for reusable assets. The framework defines a service resident isolating service assets in a network segment and creates administrator domains to reflect operational responsibilities. An administrator domain combines OCI resources like compartments, groups, policies, identity tags and notifications into a reusable asset that separates system operators from network-, database-, and security operators.
A segment represents various network ressources in OCI. It combines a Virtual Cloud Network (VCN) with a dynamic routing gateway (DRG), a service gateway for the Oracle Service Network, an internet- and a NAT gateway. It contains an adjustable number of subnets, defined using Terraform’s cidrsubnet() function and secures IP spaces through firewalls. A firewall represents port filter, implemented using security lists. In the default configuration egress traffic is unconstrained, ingress traffic is limited to a minimum set of application profiles and will need adjustments, launching a service. Routing sections trigger the definition of route rules. The DRG is obligatory and proiveds on-prem connectivity as an edge router. Adding network segments, additional routers can be defined and associated with VCN, naming both equally. Internet and NAT gateways are activated per default, but can be deactivated in the resource manager interface.
Recommendations
Continous architecture principles help operation engineers to develop a secure, resilient delivery platform for enterprise cloud services that is operated efficiently. Working in incremental, evolving steps towards a service design supports agile and DevOps methods that improve the quality and keep cost and complexity under control.
-
Architect services, not solutions A service delivers business value by facilitating the desired outcome without transfering the ownership for operational costs and risks to the user. Initially services are assembled using monitored and managed infrastructure components with PaaS and SaaS attachments. When functional requirements evolve, operators consider self-managed modules as replacement for public cloud services.
-
Facilitate context-aware deployments The way teams are organized drives the architecture and design of the systems they are working on. The commercial and the operational context for a service changes over time. Leveraging the “power of SMALL” allows to move fast. In order to support a continuous delivery, tenancies are classified commercially and the lifecycle status is captured in the service configuration.
-
Innovate without disruption Cloud services are usually designed as blueprints that represent the entire footprint in a single automation script. Operational models for IT departments have incorporated shared infrastructure services in some shape or form. E.g. operational responsibilities for database or network infrastructure is reflected in a separation of duties. Extracting configuration parameters from the deployment code, the framework provides an automated provisioning process that collects input from existing competence center.
-
Build services on a common foundation Platforms evolve, there is no point in launching resources that may never be used. Modern CI/CD pipelines are developed around the capabilites of highly abstracted infrastrucure components. Reducing cost with agile development confilcts with optimizing cost for operated infrastructure. Dedicated resources have to be launched prior to supporting an on-demand model. With this framework, provisioning scripts for service assets ensure secure and compliant application deployments without prebuild resources. IaC libraries can be invoked to launch dedicated infrastructure together with a deployment script.
-
Leverage network segmentation for hybrid services Terms, like "cloud native" or "enterprise applications" describe the fact that different application designs rely on different orchestration capabilites, implemented on the resource layer. Different system requirements and communication pattern for host-, node- or container based services require a separation on network level. Rather than building hybrid clouds, the framework allows to build hybrid services that launch orchestrators in subnets of the network domain and eases the modernization of existing applications.
Provisioning templates extract configuration parameter from the deployment code for service assets and trigger provisioning processes rather than launching infrastructure resources prior to adopting a CI/CD practice. . This enables operators to start with a recommendet set of resources and refine the configuration in incremental steps. The state-aware provisioning suggests an iterative approach. A SCRUM team is made up of system administrators with expertise in application management, network-, database- and security operations. They can adjust settings without learning HCL or Terraform. Service configurations are captured in JSON files and can be edited without touching the deployment code.
Considerations
Storing the code in a git repository and connecting the Resource Manager (ORM) with the source allows administrators to implement a continuous delivery process. Operation engineers "borrow" tools and workflows, invented for software developer. But instead of using these tools for application code, operators leverage them for infrastructure automation. Git becomes the single source of truth for both, application and infrastructure code. A service template describes the desired state for the assets and is versioned in the repository. Operators introduce self-service following in steps in the service design phase:
Use the template with default settings
Default settings enable initial deployments for a new services. Operators evaluate the infrastructure platform, delivering a first service. System administrators and service owners explore service config that help to bootstrap operational tasks. Oracle’s Resource Manager (ORM) exposes assets through proteced user- and application interfaces, keeping service owners in charge to determine when and where a service will be launched. A schema file extends the console and facilitates variable entries in the Create Stack page. The default schema offers the following of config:
-
Tenancy Classification: The class parameter helps to constraint resource deployments according to the service limits associated with contract for a tenancy.
-
Resident Configuration: In the second section meta data assciated with a resident is collected. Names should be unique for a tenancy to avoid conflicts for resources, defined on root level. The lifecycle stage helps engineers to avoid over provisioning of resources that take a long time to be destroyed.
-
Topology Options: Executing the default deployment plan, the resource manager offers a choice of topologies that enable common use cases like enterprise applications, big-data and cloud-native services. These config can also be combined to build hybrid services. The opology selection triggers the subnet topology for a segment.
-
Network Settings: Generic network parameter trigger the level of exposure to the public internet. Activating the internet gateway will expose a frontend, and/or load balancer network to the public internet.
-
Domain Protection: The default protection setting is triggered by the lifecycle setting, however can be changed, should that be required.
Configure an own service template
Default settings are stored in configuration files, containing parameters as lists of objects. Combining mulitple resources into assets, the number of resource arguments is significantly reduced. Dependencies are modelled referencing resource names. Subject matter experts refine these parameter to add, change or delete resources from a template. JSON files represent the design, scale and scope of a service. In the refinement phase teams collect input from practitioners to adjust the default parameter that allow operators to controll demand and optimize capacity utilization.
Settings
-
Tenant Classification : The classification schema allows to restrict deployment templates to the resources available under the service limits of a particular contract. This setting should only be mofied by an experienced user.
-
Lifecycle Stages : Different lifecycle trigger a corresponding selection of resources. E.g., using stages allows to increase security measures within a deployment template, without rewriting a blueprint.
-
Standard Application Profiles (RFC 6335) : The RFC library reflects standard application profiles according to IANA assignments for public internet traffic.
Resident
-
Administrator Domains : Domains organize the stewardship for service assets like network, storage or compute. Domain names must be unique for a service resident.
-
Administrator Roles : Roles reflect a series of policies to ensure a seprartion of duties between operators. Each role allows to manage administrator priviledges and policies independently.
-
Operator Controls : Controls enable operators to constrain resource access and retrieve alarms or notifications in case of an event. Controls can also trigger scripts to apply predefined measures.
-
Resource Tags : Resource tags identify groups of resources, enable cost tracking and allow to define cross-domain policies.
-
Notification Channels : Channels utilize the messaging services for notifications generated by an event or an operator control like budget or service limits.
-
Budgets : Budgets enables operator to assign UCC to a service owner and monitor the consumption. If defined threshhold is reached, an alert will be send to the selected admin channel.
-
Administrator Alerts : Alerts define threshholds for monitoring events. Currently the functionlaity is limited to cost tracking.
-
Monitoring Periods : Periosd are the foundation for alerts and define the sequence when threshholds will be reset.
Encryption
-
Passwords : Passwords can either be random strings or secrets that are stored in vault and are managed using the Key Management Service (KMS)
-
Signatures : Signatures are always stored in vault and can be retrieved for the respecitve resources.
-
Wallets : A wallet combines a vault with an encryption key. The wallet data set trigger the creation and deprovisioning of a vault.
Network
-
Network Segments : Segments provide private IP networks for a resident. OCI provides a native layer three network, tenancies can be considered as isolated, virtual data centers.
-
Subnets : Subnets divide network segments into smaller parts. The purpose is to improve security and avoid address conflicts, when deploying autoscaling workloads.
-
Edge Router : Router are located at the cloud network boundary, the edge router represents an DRG that connects network segments in the cloud with on-prem networks, allows for transit routing and for the implementation of a Hub-and-Spoke topology with multiple VCN.
-
Routing Destinations : Destinations translate the name of network zones into cidr ranges that can be reached using gateways. The route is defined as a pair between a destination and a gateway.
-
Firewalls : Firewalls represent port filter that either allow or block network packets based on their port number. The port.json files contains a list of predefined ports according to RFC6335 but can be extended with individual profiles.
-
Security Zones : Security zones describe portions of a network with a security requirements set. Each zone consists of a single interface, to which a security policy is applied. Subnets and routing destinations are predfined zones, additional can be defined as sections.
-
Application Profiles : Application Port Profiles include a combination of a protocol and a port, or a group of ports, that is used for firewalls and NAT gateways.
-
Traffic Sources : Sources are network zones where incoming traffic can orgin. Network sources are used to define firewall rules on subnet level.
Database
-
Autonomous Database : The database file defines the various deployment options for databases in OCI. Currently only autonomous databases are supported.
-
T-Shirt Sizes : In the sizes file database administrators can define standard deplyment sizes for self-service deployments. When moving to production, often standard sizes are replaced with speciffic sizing options.
Create own service components
The objective of every adoption project is the deployment of a service. Beside refining the topology, servers need to be configured and applications need to be installed. Configuration scripts are are triggerdd from a host configuration, and services hosted in the Oracle Service Network can be attached to a network segment. Cloud solutions are assembled using service assets. The framework provides predefined components that abstract provider specific APIs. Using ORM, services are deployed into existing residents. Predefined modules can be invoked referring to OCI modules in the terraform registry or to a git repository, containing infrastructure code. A great starting point are the cloudbricks components. Depending on the level of standardization, service components are introduced using the following methods:
-
Service Assets - Service assets are reusable definitions of infrastructure resoources. These assets are invoked as Terraform modules in the main.tf file. This allows to complement the predefined set of resources with custom components, e.g. commercial hypervisor, container orchstrator or load balancer. A growing number of Terraform provider suggests to define custom assets in HCL. The asset template get’s engineers to started on a new repository and the core development repository helps to develop deployment templates offline.
-
Service Attachments - The Oracle Service Network offers a variety of public cloud services that can be attached to a private service through the service gateway. Attachments don’t need customization, resource blocks can be added to the main.tf file.
-
Service Modules - Service Modules represent resource manager stacks with an own schema file. This allows to use the same modules accross multiple residents. Examples are application and database hosts or container cluster.
Deployment
The resources manager comes with a number of service provider preinstalled, additional can be pulled form the Terraform registry, using the provider block. The configuration module is the first out of three obligatory modules. It translates generic input paramerts into a baseline configuration. Operators adjust the service configuration when requirements evolve. For one-time deployments, the Deploy to the Oracle Cloud button creates a zip archive that is pushed to the resource manager directly, to enable continuous changes the code should be cloned into a private repository and be connected as a source provider.
An optional operator node is employed to execute cron jobs and runbooks that help to manage service availability, schedule resource consumption and fix problems for container workloads and functions. In addition service configurations enable service manager to adopt Oracle Cloud Services as alternative to shared intranet services and to benefit from blueprints for services like utility computing, web- and mobile backbone services.
Prerequisites
Code is written in HashiCorp Configuration Language (HCL), includes data stored in JSON format and cloud init scripts. The OCI Resource Manager executes Terraform and deploys Service Assets into a tenancy. Engineers should familerize themselfes with the following topics:
Notes/Issues
-
Destroying compartments and tag namespaces can take some time and will fail in some cases. Repeat the destroy command will continue the process.
URLs
This repository is intended to be used with the Oracle Resource Manager. Using the "Deploy to Oracle Cloud" button requires users to sign in.
Contributing
This project is a community project the code is open source. Please submit your contributions by forking this repository and submitting a pull request! Oracle appreciates any contributions that are made by the open source community.
License
Copyright (c) 2021 Oracle and/or its affiliates.
Licensed under the Universal Permissive License (UPL), Version 1.0.
See LICENSE for more details.
ORACLE AND ITS AFFILIATES DO NOT PROVIDE ANY WARRANTY WHATSOEVER, EXPRESS OR IMPLIED, FOR ANY SOFTWARE, MATERIAL OR CONTENT OF ANY KIND CONTAINED OR PRODUCED WITHIN THIS REPOSITORY, AND IN PARTICULAR SPECIFICALLY DISCLAIM ANY AND ALL IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE. FURTHERMORE, ORACLE AND ITS AFFILIATES DO NOT REPRESENT THAT ANY CUSTOMARY SECURITY REVIEW HAS BEEN PERFORMED WITH RESPECT TO ANY SOFTWARE, MATERIAL OR CONTENT CONTAINED OR PRODUCED WITHIN THIS REPOSITORY. IN ADDITION, AND WITHOUT LIMITING THE FOREGOING, THIRD PARTIES MAY HAVE POSTED SOFTWARE, MATERIAL OR CONTENT TO THIS REPOSITORY WITHOUT ANY REVIEW. USE AT YOUR OWN RISK.