1. Deploy an autonomous database with a Flask web server
  2. Deploy an Autonomous Database with a Flask Web Server

Deploy an Autonomous Database with a Flask Web Server

Enable private access to a fully managed, autonomous database in Oracle Cloud Infrastructure in a private subnet. This will assign a private IP to the autonomous database for access.

Architecture

This architecture shows a public-facing Flask web server connected to an autonomous database with a private endpoint provisioned in Oracle Cloud Infrastructure.

Description of autonomous-db-private-endpoint.png follows
Description of the illustration autonomous-db-private-endpoint.png

autonomous-db-private-endpoint-oracle.zip

The architecture has the following components:

  • Autonomous database, with a private endpoint

    This architecture uses an autonomous database (which can be an Oracle Autonomous Transaction Processing database or an Oracle Autonomous Data Warehouse) provisioned in a private subnet; that is with a private endpoint.

  • 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).

  • 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.

  • Virtual cloud network (VCN) and subnets

    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.

    In this architecture, the web server is attached to a public subnet, and the autonomous database is in a private subnet.

Recommendations

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

  • Compute shapes

    This architecture uses an Oracle Linux 7.7 compute instance with a VM.Standard2.1 shape for the Flask-based server. If the application needs more processing power, memory, or network bandwidth, then choose a larger shape.

  • 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.

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

  • Autonomous database

    In this architecture, the application stores relational data in an autonomous database. We recommend using the latest version of Oracle Database.

Considerations

  • Web-server scalability

    You can scale your Flask application by using the compute instance pool and autoscaling features.

    Instance pools let you provision and create multiple compute instances based on the same configuration, within the same region.

    Autoscaling lets you automatically adjust the number of compute instances in an instance pool based on performance metrics, such as CPU utilization. Autoscaling helps you provide consistent performance for users during periods of high demand and helps you reduce cost during periods of low demand.

  • Autonomous database scalability

    You can manually scale the database's base number of CPU cores up or down at any time. The autoscaling feature allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, autoscaling automatically increases the number of cores in use. You can scale the storage capacity of the database at any time without affecting availability or performance.

  • Application availability

    Fault domains provide the best resiliency within an availability domain. If you need higher availability, consider using multiple availability domains or multiple regions.

  • Autonomous database backups

    Your autonomous database is backed up automatically, and the backups are retained for 60 days. You can restore and recover the database to any point-in-time during the retention period.

    You can also create manual backups to supplement the automatic backups. Manual backups are stored in a bucket that you create in Oracle Cloud Infrastructure Object Storage, and the backups are retained for 60 days.

  • Compute backups

    The Oracle Cloud Infrastructure Block Volumesservice lets you make point-in-time backups of data on a block volume. You can then restore the backups to new volumes either immediately or later.

    You can also use the service to make a point-in-time, crash-consistent backup of a boot volume without application interruption or downtime. Boot volume backup capabilities are the same as block volume backup capabilities.

  • Security
    • Policies

      Use policies to restrict who can access your Oracle Cloud Infrastructure resources and what operations they can perform.

    • Network security

      The networking service offers two virtual firewall features that use security rules to control traffic at the packet level: security lists and network security groups (NSG).

      An NSG consists of a set of ingress and egress security rules that apply to only a set of VNICs of your choice within a VCN. For example, an NSG can include the VNICs of all the compute instances in the web tier of a multitier application.

      NSG security rules function the same as security list rules. However, for an NSG security rule's source or destination, you can specify an NSG instead of a CIDR block. So, you can easily write security rules to control traffic between two NSGs in the same VCN or traffic within a single NSG.

      When you provision the autonomous database in Oracle Cloud Infrastructure, you can specify one or more NSGs. You can also update an existing database to use one or more NSGs.

Deploy

The Terraform code for this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, you can download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      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 by using the Terraform CLI:
    1. Go to GitHub.
    2. Download or clone the code to your local computer.
    3. Follow the instructions in the README.

Explore More

Change Log

This log lists only the significant changes: