Oracle Cloud Infrastructure for Solutions Architects E-Book

Prasenjit Sarkar

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 288

Veröffentlichungsjahr: 2021

Beschreibung

Oracle Cloud Infrastructure (OCI) is a set of complementary cloud services that enables you to build and run a wide range of applications and services in a highly available hosted environment. This book is a fast-paced practical guide that will help you develop the capabilities to leverage OCI services and effectively manage your cloud infrastructure.
Oracle Cloud Infrastructure for Solutions Architects begins by helping you get to grips with the fundamentals of Oracle Cloud Infrastructure, and moves on to cover the building blocks of the layers of Infrastructure as a Service (IaaS), such as Identity and Access Management (IAM), compute, storage, network, and database. As you advance, you’ll delve into the development aspects of OCI, where you’ll learn to build cloud-native applications and perform operations on OCI resources as well as use the CLI, API, and SDK. Finally, you’ll explore the capabilities of building an Oracle hybrid cloud infrastructure.
By the end of this book, you’ll have learned how to leverage the OCI and gained a solid understanding of the persona of an architect as well as a developer’s perspective.

Leseprobe

Oracle Cloud Infrastructure for Solutions Architects

A practical guide to effectively designing enterprise-grade solutions with OCI services

Prasenjit Sarkar

BIRMINGHAM—MUMBAI

Oracle Cloud Infrastructure for Solutions Architects

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Vijin Boricha

Publishing Product Manager: Vijin Boricha

Senior Editor: Arun Nadar

Content Development Editor: Romy Dias

Technical Editor: Sarvesh Jaywant

Copy Editor: Safis Editing

Project Coordinator: Ajesh Devavaram

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Nilesh Mohite

First published: August 2021

Production reference: 1170821

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-646-0

www.packt.com

Foreword

Cloud computing and related technologies such as Kubernetes, serverless, and microservices have changed the way we communicate and live. Today, we are immersed in a software-defined world, where every company (no matter what their size is) needs to have a well-defined software strategy if they want to survive in a competitive landscape with more agile and adaptive competitors.

With the cloud, we've seen a shift in the business model, where companies have more flexibility and unlimited opportunities to grow their business at scale. Not having to invest in infrastructure – you can consume resources in a pay-as-you-go or subscription-based model – allows you to invest in other areas that help fast time to market at an affordable cost. You can always get into the entrepreneur mindset and build your own start-up with a few bucks. Today, it's much easier than 10 years back. I took that journey a few years ago and built my own start-up with a couple of good friends. We were all passionate about building and fixing things. Today, it's a $2M start-up and growing.

As you can see, the cloud has democratized the industry and has created huge opportunities for businesses across multiple industries. However, we are still at the beginning of this digital revolution. Think of Oracle as an example. For many years, we've been a database company and we are currently in the transition of becoming a platform/service company. We've rebuilt our entire product line to run in the cloud, and that's just the beginning. The future is moving toward cognitive services, and that's where we want to be. I must admit that it's exciting redefining 43 years of history and seeing how progress is coming faster than expected.

Over the last few years, I've spent more time than I recall answering the questions What is Oracle Cloud Infrastructure (OCI) and why should I care about it? Until now, we have shared our own experience, the lessons learned, presentations, podcasts, whitepapers, and blogs that provide an overall view of OCI. There is no doubt that with every new technology, there are challenges. That is why books such as this one are so valuable. Prasenjit has charted a course to the cloud-native world in an easy way.

This book is extremely approachable for anyone interested in cloud computing, including undergraduate and graduate students, IT engineers, managers, and curious learners. You will begin with the fundamentals of OCI and as you dive into the chapters, you will advance through more sophisticated cloud-native features. You will discover all the components that are part of developing, deploying, and managing highly secure applications using modern DevOps approaches. With this book, you now have a comprehensive resource on OCI that will help you build and deploy applications in the cloud…and who knows, maybe you'll end up being the next unicorn in the industry.

But let's stop talking and get hands-on…it's time to learn!

Guillermo Ruiz

Head of DevRel, Oracle

P.S. I've known Prasenjit for more than half a decade, and even before knowing him, I was already using some of the technologies he patented. If you come from the early days when VMware became the default technology in data centers, I'm sure you have used vSAN. That's one of the 12 patents that Prasenjit has co-authored.

It was no surprise when he told me he was writing a book about Oracle Cloud, but it really was a surprise when he asked me to write the Foreword. I hope you find the book useful.


To the doctors, nurses, public health officials, and first responders who are protecting us from COVID-19.

Contributors

About the author

Prasenjit Sarkar is a Director of Product Management at Cisco for their Emerging Technologies and Incubation venture. His primary focus is on cloud-native application networking and security. He is a seasoned product leader in the cloud-native space. He has vast knowledge of Kubernetes, containers, container and Kubernetes networking, Service Mesh, API management, and serverless computing, among other things.

He is also an author of the virtualization blog Kube-Mesh and has authored six industry-leading books on virtualization, SDN, physical compute, and the cloud, among other topics.

He has 12 granted patents in the US and has authored numerous research articles.

I want to thank my wonderful wife, Debarati, and my super supportive son, Reyan, for giving me the space and support I've needed to write this book. I'd also like to thank the entire Oracle team for encouraging me and giving me the time to complete this journey. The whole Packt editing team has helped this journey immensely, but I'd like to give special thanks to Romy Dias, who edited most of my work, and Vaidehi, for always being on top of the schedule.

About the reviewer

Neetika Jain is a cloud enthusiast with 11 years of experience with various cloud and integration technologies. She is passionate about building useful impactful products. She is an Oracle Cloud certified professional and is currently working as a Principal Product Manager – SaaS Integrations at Oracle-NetSuite. Prior to her current role, she worked as a cloud architect and consultant at various IT firms, including Oracle, IBM, and Wipro. You can reach out to her at LinkedIn.

I would like to thank my family and friends for always supporting me and helping me to achieve my dreams; you are all my motivation.

Table of Contents

Preface

Section 1: Core Concepts of Oracle Cloud Infrastructure

Chapter 1: Introduction to Oracle Cloud Infrastructure

Regions and ADs

Managing regions from the OCI console

Logical view of Oracle Cloud Infrastructure components

Tenancies

Bootstrapping

Compartments

Oracle Cloud Identifiers (OCIDs)

Off-box virtualization

The security benefits of off-box virtualization

Fault domains

Summary

Chapter 2: Understanding Identity and Access Management

Principals

The root user

IAM users/groups

Instance principals

Authorization

Organizing resources using compartments

Design considerations

Reference model of compartments

Compartment Explorer

Accessing resources from compartments using a policy

Verbs

Policy inheritance

Policy attachment

Using instance principals to make a call to the OCI API

Creating an instance principal

Federating OCI access using a third-party IdP

Configuring a federation

Summary

Chapter 3: Designing a Network on Oracle Cloud Infrastructure

High level architecture of VCNs

VCN components

Subnets

VNIC

Private IP address

Public IP address

Internet gateway

Route table

Dynamic routing gateway

NAT gateway

Service gateway

Local peering (within region)

Remote peering (across region)

Security list

Network security group

Stateful and stateless security rules

Default VCN components

Reviewing the VCN components

Connection choices

Connecting through the public internet

Connecting through a VPN

Connecting through FastConnect

Load balancer

Public load balancer

Private load balancer

Load balancing policies

Health check

SSL handling

Session persistence

Request routing – virtual hostnames and path routing

VCN flow logs

Configuring VCN flow logs

Summary

Chapter 4: Compute Choices on Oracle Cloud Infrastructure

Introducing the different OCI compute instance types

Understanding instance shapes

Storage for compute instances

Instance boot volume

Understanding instance operating system images

Custom images

Image export and import

Bring Your Own Image (BYOI)

Bring Your Own Hypervisor (BYOH)

Creating similar instances using instance configuration and instance pools

Compute instance metrics

Autoscaling configurations

Connecting to instances using an instance console connection

Connecting to the serial console from macOS or Linux OS

Summary

Chapter 5: Understanding Oracle Cloud Infrastructure Storage Options

OCI Block Volume

Creating a block volume

Resizing a block volume

Attaching a block volume to an instance

Backing up and restoring a block volume

Cloning a block volume

Volume groups

Block Volume operations – shared multi-attach

OCI File Storage Service

Creating a filesystem

Filesystem security

OCI Object Storage

Pre-authenticated requests

Cross-region copy

Multipart upload

Summary

Section 2: Understanding the Additional Layers of Oracle Cloud Infrastructure

Chapter 6: Understanding Database Choices on Oracle Cloud Infrastructure

Discussing OCI database choices

VM database systems

Bare-metal database systems

Exadata database systems

Managing Oracle's Autonomous Database service

Summary

Chapter 7: Building a Cloud-Native Application on Oracle Cloud Infrastructure

Evolution of cloud native applications

Storing application images on the OCI registry

Preparing for pushing and pulling images from the registry

Creating a repository

Creating a Docker container image

Pushing and pulling a Docker container image

Deploying microservices on OKE

Getting started with Kubernetes

Getting started with Oracle Container Engine for Kubernetes

Creating an OKE cluster

Accessing an OKE cluster

Deploying a sample web application on an OKE cluster

Upgrading the Kubernetes version of an OKE cluster

Exposing microservices using the OCI API gateway

API gateway within a cloud environment

API gateway in a cloud to on-premises model

API gateway in a hybrid model

API gateway in a private cloud model

API gateway concepts

Creating an API gateway

Creating an API gateway deployment

Accessing the API endpoint through an API gateway

Summary

Chapter 8: Running a Serverless Application on Oracle Cloud Infrastructure

Understanding the notion of serverless computing

Understanding the importance of Oracle Function

Understanding the use cases of Oracle Function

Creating and using Oracle functions

Deep diving into Oracle functions

Understanding event-based usage of Oracle functions

Summary

Chapter 9: Managing Infrastructure as Code on Oracle Cloud Infrastructure

Understanding the need for IaC

Understanding the use cases of ORM

ORM components

Learning to generate IaC from an existing setup

Learning to integrate ORM with SCM

Summary

Chapter 10: Interacting with Oracle Cloud Infrastructure Using the CLI/API/SDK

Using the OCI CLI to interact with OCI resources

Using OCI SDKs to automate OCI operations

Using the OCI API to send REST calls for managing OCI

Summary

Chapter 11: Building a Hybrid Cloud on Oracle Cloud Infrastructure using Oracle Cloud VMware Solution

Understanding the solution overview of the OCVS solution

Virtual cloud network (VCN)

Compute – VMware vSphere (ESXi)

Networking – VMware NSX-T

Storage – VMware vSAN

Deploying OCVS

Deploying an OCVS cluster

Accessing an OCVS cluster

Connecting an OCVS cluster to the internet

Summary

Other Books You May Enjoy

Section 1: Core Concepts of Oracle Cloud Infrastructure

In the first part of this book, you will understand the core architectural components with which Oracle Cloud Infrastructure (OCI) Generation 2 is built, including IAM, compute, network, and storage. These are the building blocks of OCI.

The following chapters are in this section:

Chapter 1, Introduction to Oracle Cloud InfrastructureChapter 2, Understanding Identity and Access ManagementChapter 3, Designing a Network on Oracle Cloud InfrastructureChapter 4, Compute Choices in Oracle Cloud InfrastructureChapter 5, Understanding the Oracle Cloud Infrastructure Storage Options

Chapter 1: Introduction to Oracle Cloud Infrastructure

Oracle Cloud Infrastructure (OCI) is an Infrastructure-as-a-Service (IaaS) cloud platform that allows consumers to create resources, such as compute instances, databases, networks, containers, functions, and storage, in order to run their applications and workloads. A number of different parties can interact with the OCI cloud. Some of these are actual users, while others are external systems that OCI services communicate with.

So, what do you need from the cloud? Well, an enterprise always looks for scalable, available, and on-demand solutions when they want to move their workload to the cloud. However, for critical enterprise applications, you need no-compromise security and performance guarantees. Remember, you want to offer the same, or better, Service-Level Agreements (SLAs) for your business.

In this chapter, we will cover the following topics:

Regions and Availability Domains (ADs)Off-box virtualizationFault domains

Regions and ADs

OCI has been built using the concept of regions. A region is simply a physical location in the world where OCI hosts data centers. In a nutshell, a region is a localized geographic area. Within a region, OCI hosts one or more physical data centers and calls this an Availability Domain (AD).

In this section, we will look at the main concepts of OCI in more detail, such as regions, ADs, and fault domains. Additionally, we will learn how to subscribe to other regions.

A lot of OCI services are regional; for example, Virtual Cloud Networks (VCNs). If you create a VCN, it will span across the AD. Other services are AD-specific, such as compute resources. You can create a compute instance that has access to a specific AD. Additionally, there is a very strong interconnectivity between the ADs within a region and across regions. Within an AD, interconnected traffic is encrypted as well.

As of August 2020, there are 26 regions and 6 interconnected Azure regions that are live. The following map shows the different regions that are currently live across the globe:

Figure 1.1 – OCI regions

Oracle's strategy is to add new regions around the world in order to give customers local access to its cloud resources. To speed up the process and still provide high availability, OCI has launched one AD region that has three fault domains inside the physical AD. We will discuss fault domains in more detail later in this chapter.

OCI regions are dispersed via vast distances across countries and even continents. When a customer deploys their application, they typically put that application in the region where it is most heavily used. However, there are multiple reasons why someone might choose to put their applications in different regions, such as the following:

A natural calamity could affect a whole country or continent.Data jurisdiction drives data locality requirements.

The following table identifies a region, its identifiers, location, region key, realm key, and the number of ADs within it:

Important note

The data in the table is accurate as of August 2020. However, it may not remain accurate as Oracle is rapidly adding new regions and interconnected Azure regions. You can refer to Oracle's public documentation to find the latest information on the available regions at https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm?.

Managing regions from the OCI console

You can subscribe to any of the commercially available regions from the OCI console. However, doing so requires administrative privileges.

During the sign-up process, OCI will create a tenancy and assign a region to you. This is called the home region. You cannot change this home region later. However, you can subscribe to other available regions. By doing so, OCI will replicate your identity resources to the new region.

To view the subscribed regions, follow these steps:

Log in to the OCI console.Open the Regions menu.View the subscribed region(s). Please note that all the region names that appear in the Regions menu are the regions that you are subscribed to already.

To subscribe to other regions, perform these steps:

Log in to the OCI console.Open the Regions menu, and then click on Manage Regions, as highlighted in the following screenshot:

Figure 1.2 – The list of subscribed regions

Check which region you want to subscribe to, and then click on Subscribe, as shown in the following screenshot:

Figure 1.3 – The Infrastructure Regions subscription page

So, you can see how simple it is to subscribe to regions where you want to consume cloud resources.

Logical view of Oracle Cloud Infrastructure components

OCI regions are part of a realm. A realm is a logical collection of regions. Realms do not share any data. While regions within a realm can share data via replication, regions in separate realms are completely isolated from each other.

Tenancies

OCI users live in a tenancy, which is a logical grouping for a business customer that contains users, groups, and compartments. A tenancy is based in a home region but can be subscribed to other regions. When a tenancy is subscribed to another region, tenancy data created in the home region is automatically replicated to the subscribed region. Replication of this data is required to call services in that region. Identity data can only be modified in the tenant's home region.

Bootstrapping

A tenancy is created when the accounts service receives a request to create an account entitlement. The account service coordinates with the Identity and Access Management (IAM) service to generate several resources, such as the tenancy (root compartment), a default access policy, a user account, and an administrators group to which the user is added.

When the user account is created, a one-time password (OTP) is generated. With this password, the user can sign in to the web console and upload the public part of the key pair they generated. Once this is done, the user can start making signed calls to the OCI APIs using command-line interface (CLI) tools.

Compartments

Compartments are the logical containers of resources. Compartments typically have a policy attached to them to control access to the resources inside. Compartments can be nested as well. They can span regions, which makes it possible to add, for example, compute instances from different regions to the same compartment and have them guarded by the same policy.

Oracle Cloud Identifiers (OCIDs)

Resources in OCI are identified by unique Oracle Cloud Identifiers (OCIDs). An OCID consists of different parts separated by dots:

ocid1.<resource type>.<realm>.[region][.future use].<unique ID>

Let's take a look at the various parts that make up the OCID:

ocid1: This indicates the version of the OCID.resource type: This is the type of resource. For example, a resource can be an instance, a volume, a VCN, a tenancy, a user, or a group.realm: This indicates which realm the resource is in. For example, all production regions use oc1.region: This indicates where this resource is located.future use: This is reserved for future use; therefore, you are likely to see a blank space here.unique ID: This section is the unique portion of the ID. You might notice a different format depending on the type of resource or service.

Here are a couple of examples:

ocid1.tenancy.oc1..aaaaaaaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdsq

ocid1.instance.oc1.phx.abuw4ljrlsfiqw6vzzxb43vyypt4pkodawglp3wqxjqofakrwvou52gb6s5a

OCI's regions are physically divided into ADs, which are named by numbering them (for example, phx-ad-1, phx-ad-2, and phx-ad-3). It is a human tendency to pick the first AD from a given list when it comes to creating a compute instance in an AD. In order to stop you from doing this, OCI gives each tenancy a random set of logical ADs. This is called AD obfuscation. Logical AD names look like SQPR:PHX-AD-1, and physical AD names look like phx-ad-1.

AD, which is nothing but physical data centers, are far away enough that they are completely independent, from a failure perspective, but are close enough to have very low-latency connectivity. Customers get to choose what AD they create resources in, such as compute instances, databases, and more. This selection, however, is randomly mapped to a physical AD to prevent the uneven usage of ADs. In the following screenshot, you can see a logical view of the mapping of ADs in a region and how that maps to a fault domain inside it:

Figure 1.4 – An OCI AD

Inside an AD, OCI runs a highly scalable and high-performance network, which is not oversubscribed. Due to this design of non-oversubscription, there is no noisy neighbor problem. In terms of scalability, this AD can scale up to approximately 1 million ports. Additionally, because of the no noisy neighbors and non-oversubscription network, this AD has predictable low latency and high-speed interconnectivity between hosts that don't traverse more than two hops. In the following logical diagram, you can see a mapping of how the physical network infrastructure connects to the regions:

Figure 1.5 – The layout of OCI's physical infrastructure

OCI's first four regions (Phoenix, Ashburn, London, and Frankfurt) consist of three ADs. Each AD is in a physically separate data center.

In these initial regions, Oracle built many foundational services that were specifically tied to a single AD. This is so that there would be no dependencies outside of a single AD. A compute service is the most prominent example of this.

After the first four regions, Oracle shifted their strategy. The majority of customer workloads do not take advantage of ADs for high availability, and, instead, they rely on high availability within an AD and use multiple regions to support disaster recovery. Therefore, OCI adapted to this by launching a larger number of single-AD regions.

Off-box virtualization

If you look at any traditional cloud provider, they are all made up of Virtual Machines (VMs) running on top of a hypervisor. A hypervisor's job is to isolate these VMs by sharing the same CPUs, and then capture I/O from each VM to ensure that they are abstracted from the hardware. The VM is, therefore, secure and portable, as it sees only a software-defined network interface card. The hypervisor can inspect all of the packets between the VMs and enable features such as IP whitelists and access control lists. This is depicted in the following diagram:

Figure 1.6 – In-kernel network virtualization

In in-kernel virtualization, whenever there is a need to inspect packets to and from a VM, you can put pressure on the host hypervisor by taking away its CPU cycles. This is mainly because this type of hypervisor performs packet switching, encapsulation, and enforces stateful firewall rules. However, this is not the only risk. There is another risk of having noisy neighbors. A noisy neighbor VM monopolizes bandwidth, disk I/O, and CPUs at the expense of its neighbors.

The fundamental purpose of off-box virtualization is that it no longer commits I/O virtualization into the hypervisor but to the network outside of the physical box. You can't reach the control plane that runs the virtual network from the public internet. However, you can create an explicit tunnel to reach the virtual network, which can be monitored, audited, and, in the case of an emergency, switched off as well. This is shown in the following diagram, where you can clearly see that the network I/O virtualization is not being done at the host hypervisor level:

Figure 1.7 – Off-box network virtualization

When you move network virtualization from in-kernel virtualization to off-box virtualization, it results in a dramatic change in performance and improved security posture. This is because you are no longer getting any performance overhead associated with the hypervisor. Another benefit of off-box virtualization is that you retain the flexibility to plug anything into the virtual network. You can perhaps add another bare metal host, an Non-Volatile Memory Express (NVMe) storage system, a VM, a container, or even an engineered system, such as Exadata. All of them can run on this virtual network and reach each other within two hops. Take a look at the following diagram:

Figure 1.8 – OCI's holistic architecture

OCI's unique offering of bare metal servers doesn't come with a pre-installed operating system or any software. This increases the level of security over traditional virtualization. You can choose any hypervisor that you want to install on top of the OCI bare metal instance and then deploy VMs and install applications on top of that. OCI doesn't offer any access to the memory space of these bare metal instances, allowing complete physical isolation.

As you can see, these bare metal instances are running without any adjacent co-tenants; therefore, they boost both IOPS and bandwidth.

The security benefits of off-box virtualization

Traditional server virtualization comes with an abstraction layer. This layer abstracts the application that is running on the virtualized server from compute resources, storage, and networking hardware. You can deploy this virtual infrastructure without any disruption as it has nothing to do with user experience. You have to virtualize the CPU, main memory, network access, and I/O if you want to take advantage of partitioning, isolation, and hardware independence, which all result from the virtualization process.

Traditional server virtualization in first-generation public cloud infrastructures might come at a cost to the performance overhead and lead to weaker security. The performance overhead is mainly because the hypervisor needs to manage network traffic and I/O for all of the VMs that are running on a host, causing noisy neighbor problems. Additionally, the level of security is inherently weaker because, in traditional virtualization architectures, the hypervisor has complete trust and makes access decisions on behalf of the VM. This means a hostile actor that compromises the hypervisor can easily spread beyond the single hypervisor to other systems in the same cloud. More specifically, the traditional model implies that the attacker of a compromised host/hypervisor can access any VCN because the host/hypervisor is trusted to do so. You can see an example of in-kernel network virtualization in the following diagram:

Figure 1.9 – In-kernel virtualization

The security isolation between one customer's compute resources from other customers' compute resources is critical. Fundamentally, OCI designed its security architecture with the assumption that customer-controlled compute resources can be hostile. It has a multi-pronged defense in-depth security architecture, which has been designed to minimize the security risks of traditional virtualization.

Oracle's Gen 2 Cloud infrastructure uses a unique approach that eliminates some of the disadvantages of traditional server virtualization. OCI uses off-box network virtualization, which takes network virtualization out of the software stack (hypervisor) and places it in the infrastructure. Oracle uses off-box network virtualization technology in both bare metal instances (for example, physical servers dedicated to a single customer) and VM instances.

Isolated network virtualization limits the attacker surface to only a VCN connected to the hypervisor by the control plane. OCI moves the trust from the hypervisor to the isolated network virtualization, which is implemented outside of the hypervisor. In the following diagram, you can see how this is done:

Figure 1.10 – Off-box network virtualization