Deploy ASP.Net Applications On Oracle Cloud Infrastructure

ASP.Net is an open source web framework, created by Microsoft, for building modern web apps and services with .Net. You can use this framework to quickly set up an automated deployment pipeline for ASP.Net applications on Oracle Cloud Infrastructure. This Reference Architecture showcases a simple ASP.Net application and provides the scaffolding to set it up.

Architecture

In this architecture, we are deploying an ASP.Net application across multiple Fault Domains. The architecture uses a virtual cloud network (VCN) with a public subnet for the application instances and a private subnet for the database tier. A load balancer placed in the public subnet distributes traffic across the nodes.

You can take advantage of Oracle Cloud Infrastructure's flexible load balancer, choose a custom minimum bandwidth and an optional maximum bandwidth; both must be between 10 Mbps and 8,000 Mbps. The minimum bandwidth is always available and provides instant readiness for your workloads. Based on incoming traffic patterns, available bandwidth will scale up from the minimum as traffic increases.

For applications that are deployed on virtual machines, customers can take advantage of flexible VM instances. Flexible VMs can increase or decrease capacity in minutes by adding CPUs and memory. A Flexible VM can be configured with 1 to 64 cores, and between 1 and 64 GB memory per core, up to a maximum of 1024 GB per instance.

The Microsoft SQL database is deployed with a Primary and Standby database spread across two fault domains to provide high availability.

The following diagram illustrates this reference architecture.

Description of ha-aspnet-oci-arch.png follows
Description of the illustration ha-aspnet-oci-arch.png

This architecture has the following components:
  • 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.

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

  • Compartment

    Compartments are cross-region logical partitions within an OCI tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform. 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.

  • Security lists

    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.

  • Load balancers

    The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end. Internet gateway The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Block volume

    With block storage volumes, you can create, attach, connect, and move storage volumes, and change volume performance to meet your storage, performance, and application requirements. After you attach and connect a volume to an instance, you can use the volume like a regular hard drive. You can also disconnect a volume and attach it to another instance without losing data.

  • Webserver - IIS

    Internet Information Services (IIS) for Windows® Server is a Web server for hosting .Net applications.

  • Github Actions and Runners

    GitHub Actions is used to automate the build and deployment of the ASP.NET application to the Windows servers. GitHub Actions help to automate tasks within a software development lifecycle, and a runner is the machine on which a GitHub Actions job runs. A runner listens for available jobs, runs one at a time, and reports the progress, logs, and results to GitHub.

    Runners are offered as a managed service by GitHub, or they can be self-managed if you need more flexibility and control of your environment; for example as a proprietary image or container, a more powerful machine, or to support multiple architectures like Arm. The same processes or commands can be executed from any build and deployment system to get similar results. In this example, the build is triggered by a commit to the repository or a pull request. When the workflow is triggered the application is build. The built binaries are packaged and terraform is started to update the infrastructure and deploy the application. The Oracle Cloud Infrastructure API key is managed by GitHub secrets.

Recommendations

Use the following recommendations as a starting point. Note that your requirements might differ from the architecture described here.
  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, an Object Storage bucket can have visibility set to public.

    Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

  • Security Zones

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

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

    Use regional subnets.

  • Security lists

    Use security lists to define ingress and egress rules that apply to the entire subnet.

Considerations

Consider the following points when deploying this reference architecture.

  • Security

    Consider adding Web Application Firewall to secure the application against malicious attacks.

  • Application availability

    Fault domains provide the best resilience within a single availability domain. In addition, deploying compute instances that perform the same tasks across multiple fault domains provides redundancy and prevents a single point of failure.

  • Cost

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

  • CI/CD

    You can deploy self-hosted Github Action runners on OCI and add them to your Github repository, organization, or enterprise. For more details on GitHub Actions self-hosted runners and supported platforms and architectures, see "Hosting your own runners" in the GitHub documentation (see the Explore More topic for a link to this document).

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. ClickDeploy to Oracle Cloud

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

    2. Select the region where you want to deploy the stack.
    3. Follow the on-screen prompts and instructions to create the stack.
    4. After creating the stack, click Terraform Actions, and select Plan.
    5. 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.

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