Streamline the management of your containerized applications using OCI Container Instances
Running containerized applications can require considerable overhead, including instantiating virtual machines, installing components to run container images, and all the dependencies to support it, including software and operating system updates, and monitoring applications while they run to ensure they are running optimally, are available, and have not been compromised.
Container Instances is a fully managed Oracle Cloud Infrastructure (OCI) compute service that allows customers to run containerized applications without managing servers. This provides a serverless experience that lets customers focus on adding value to their applications instead of deploying and managing infrastructure.
Alternatively, to run a containerized application without Container Instances, customers need to instantiate a virtual machine and install all the components to run a container image. This includes the container runtime, such as Docker or Podman, and all the dependencies to support it. In addition, customers need to secure the virtual machine by installing the latest security patches and applying the correct security settings. As new updates for software and operating systems are introduced, updates and patches need to be applied consistently. When the application is running, monitoring needs to be in place to make sure the application is running optimally, available, and has not been compromised.
With Container Instances, customers only need to create the application's container images and store them in a container registry. The containerized application can then be deployed using Container Instance with CLI commands or a guided GUI wizard in the OCI console with the following steps.
- Define Container Instance parameters: The customer defines the OCI region to run the Container Instance and, optionally, the availability domain and fault domain. Next, the customer selects the compute shape for the Container Instance. For each instance, you can allocate up to the CPU and memory of the selected compute shape. For example, if you have chosen an AMD E3/E4 shape, you can have 64 OCPU (128 vCPU) and 1024 GB memory in a container instance. Next, you would add the network settings, such as whether the Container Instance requires a public IP address and the subnet for the Container Instance along with optional advanced network configurations. In this step you also have the option to specify a private DNS record and hostname, which would generate a fully qualified domain name for the Container Instance. There is also an optional advanced option to set the container restart policy.
- Specify the launch configuration for the application: In this step, the location of the container image to run is specified, along with any required environment variables for the container image. The image can be in Oracle Cloud Infrastructure Registry or any public or private Open Container Initiative compliant registry where the Container Instance has IP connectivity. For private registries, you must provide credentials to access the container image.
- Review and create: The last step is to review all the configurations and, if everything is accurate, you can proceed with the creation, and a container instance will be launched in seconds.
Customers are charged only for the CPU and memory resources allocated to their instances at the same rate as regular Oracle Cloud Infrastructure Compute. With a simple experience, seamless operations, and no extra charge for the serverless experience, Container Instances offers the best value for running containers in the cloud. Customers may also integrated Container Instances with other OCI services, such as MySQL service and Oracle Autonomous Database, using standard database connection mechanisms, which makes it easy to leverage other OCI services for containerized applications.
Architecture
This architecture deploys a containerized WordPress application with an integrated MySQL database using Container Instances. The Container Instance will be deployed in a public subnet with a public IP address that is accessible from the internet.
Container Instances are designed for standalone applications that do not require container orchestration. These include APIs, web apps, CI/CD jobs, automation tasks, data and media processing, development and test environments, and more. For containerized applications requiring orchestration, OCI provides Oracle Container Engine for Kubernetes (OKE), a managed Kubernetes service with a serverless option with Virtual Nodes.
Each Container Instance can run multiple containers. All containers in a Container Instance share the same lifecycle, resources, network, and storage. Containers in a Container Instance have the same concept as a pod in Kubernetes with the main application container and supporting sidecar containers. The sidecar containers are there to enhance or extend the functionalities of the main application container. An example is a Container Instance with the main web application and a sidecar container that exports the web application logs to a logging server.
Note:
Running a database container along with an application container is suitable only for development and testing. Considering using Oracle MySQL Database Service for production deployments.We will deploy WordPress with an integrated database with Container Instances in this reference architecture. The following video steps through the process.
The following diagram illustrates this reference architecture.
oci-container-instance-wordpress-oracle.zip
The architecture has the following components:
- Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
- 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).
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure 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.
- Availability domain
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 domain
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.
- 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.
- 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.
- Network address translation (NAT) gateway
A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- 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.
- Container registry
Oracle-managed registry that enables you to simplify your development to production workflow.
Recommendations
- 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.
- Security
Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
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.
- 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, you might want to detect Object Storage buckets that 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.
- Network security groups (NSGs)
You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application.
- Load balancer bandwidth
While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.