Deploy Cloud Native Apps that use MySQL to Oracle Cloud Infrastructure

You can use Oracle Container Engine for Kubernetes (OKE), Oracle Cloud Infrastructure Registry, and Oracle MySQL Database Service (MDS) to develop and deploy cloud native applications and to migrate legacy applications to the cloud.

OKE is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. Use OKE when your development team wants to reliably build, deploy, and manage cloud native applications.

You can use Oracle Cloud Infrastructure Registry as a private Docker registry for internal use, pushing and pulling Docker images to and from the registry using the Docker V2 API and the standard Docker command line interface (CLI).

MDS is a fully managed Oracle Cloud Infrastructure native service, which automates tasks such as backup and recovery, as well as database and operating system patching.

Using MDS on Oracle Cloud Infrastructure Compute has the following advantages:

• Deploy MySQL in minutes.
• Benefit from a fully managed OCI service.
• Focus on development, not infrastructure administration.
• Use tools and latest features for modern apps.
• Scale according to your needs.
• Avoid shadow IT.

Architecture

This reference architecture contains a highly available database tier, built with MDS, and an OKE cluster.

The following diagram illustrates this reference architecture.

Description of the illustration architecture-kubernetes-mysql-oci.png

architecture-kubernetes-mysql-oci-oracle.zip

When deploying MDS in an Active Domain subnet, MDS will deploy a cluster of MySQL instances, with one instance in each Fault Domain to provide the redundancy. One instance is the primary and the other two instances are the secondaries. The primary includes a single endpoint that enables reads and writes to the database, while the secondaries receive replicated data from the primary. Direct access to the secondaries is not allowed.

In case of failure or manual switchover, one of the secondaries becomes the new primary and the endpoint is redirected to it. This means that the endpoint IP address never changes and there is no need to update the application. OCI manages the high availability aspects of the database.

The architecture includes an OKE cluster, which works with Oracle Cloud Infrastructure Registry to accommodate developed and deployable cloud native apps.

The architecture has the following components:

• Bastion host

  The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

• Container Engine for Kubernetes

  Oracle Cloud Infrastructure Container Engine for Kubernetes is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. You specify the compute resources that your applications require, and Container Engine for Kubernetes provisions them on Oracle Cloud Infrastructure in an existing tenancy. Container Engine for Kubernetes uses Kubernetes to automate the deployment, scaling, and management of containerized applications across clusters of hosts.

• Oracle MySQL Database Service

  Oracle MySQL Database Service is a fully managed Oracle Cloud Infrastructure (OCI) database service that lets developers quickly develop and deploy secure, cloud native applications. Optimized for and exclusively available in OCI, Oracle MySQL Database Service is 100% built, managed, and supported by the OCI and MySQL engineering teams.

  Oracle MySQL Database Service has an integrated, high-performance analytics engine (HeatWave) to run sophisticated real-time analytics directly against an operational MySQL database.

• Registry

  Oracle Cloud Infrastructure Registry is an Oracle-managed registry that enables you to simplify your development-to-production workflow. Registry makes it easy for you to store, share, and manage development artifacts, like Docker images. The highly available and scalable architecture of Oracle Cloud Infrastructure ensures that you can deploy and manage your applications reliably.

• Region

  An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

• Virtual cloud network (VCN) and subnet

  A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

• Availability domains

  Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

• Fault domains

  A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

• Dynamic routing gateway (DRG)

  The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

• Service gateway

  The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

• Internet gateway

  The internet gateway allows traffic between the public subnets in a VCN and the public internet.

• Security list

  For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

• Route table

  Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

• Bastion host

  Use the VM.Standard.E4.Flex shape with one CPU and 1 GB of memory, and the latest Oracle Linux Operating System.

• OKE cluster

  Use the Custom Create option from the Console so that you can specify a VCN and subnet for deployment. Create a three-node cluster, and choose VM.Standard.E4.Flex as your initial shape. For larger deployments, you can use a larger cluster size with a higher compute shape.

• DB System Shape

  This architecture uses High Availability in MDS to provide three MySQL servers spread across the fault domains. For a light workload, we recommend to using MySQL.VM.Standard.E3.1.8GB.HA. You can use larger shapes for more demanding workloads.

• Connecting to MDS

  You can access MDS directly with the MySQL client or a MySQL shell installed on application VMs or containers.

• MDS Database Storage

  MDS Database Storage performance scales with the storage size selected for the DB system. You cannot limit or edit the MDS storage IOPS. You must provision the storage size based on your data size and performance requirements. MDS uses the Block Volume service Higher Performance option over iSCSI. The final performance results may vary for different shapes and scenarios.

• Container Registry

  Oracle manages the registry, so you don’t have to choose size or any other options. We recommend creating a private registry for security best practices.

• VCN

  When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

  Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

  After you create a VCN, you can change, add, and remove its CIDR blocks.

  When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

Considerations

• Scalability

  You can vertically scale MySQL by changing the VM shape of each Compute node. Using a shape with a higher core count increases the memory and network bandwidth allocated to the Compute instance.

• Application availability

  This architecture uses High Availability in MDS to distribute compute instances across multiple fault domains, which removes single points of failure and provides redundancy.

• Cost

  Select the VM shape based on the cores, memory, and network bandwidth that you need for your database. You can start with a one-core shape. If you need more performance, memory, or network bandwidth for the application or database node, you can change the VM shape later.

Deploy

The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.

• Deploy using the sample stack in Oracle Cloud Infrastructure Resource Manager:
  1. Click

     If you aren't already signed in, enter the tenancy and user credentials.

  2. Review and accept the terms and conditions.
  3. Select the region where you want to deploy the stack.
  4. Follow the on-screen prompts and instructions to create the stack.
  5. After creating the stack, click Terraform Actions, and select Plan.
  6. Wait for the job to be completed, and review the plan.

     To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

  7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
• Deploy using the Terraform code in GitHub:
  1. Go to GitHub.
  2. Clone or download the repository to your local computer.
  3. Follow the instructions in the README document.

Explore More

For more information about high availability and MDS, see the following resources:

• Building Highly Available Applications in a Region with One Availability Domain
• Learn about architecting a highly available cloud topology
• Getting Started with MySQL Database Service
• Learn about deploying MySQL Database Service in Oracle Cloud
• Overview of Container Engine for Kubernetes
• Deploy a highly available MySQL Database System in a Container Engine for Kubernetes cluster
• Overview of Registry

Change Log

This log lists significant changes:

May 6, 2022

Updated the architecture to use MDS in place of MySQL. Removed references to InnoDB, which is not compatible with MDS. Added the option to download editable versions (.SVG and .DRAWIO) of the architecture diagram.