Oracle Cloud Application Container Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Other Services

1. Introduction

Important status note (read first): In Oracle’s product history, the name Application Container most commonly refers to Oracle Application Container Cloud Service—a managed PaaS offering from Oracle Cloud (Classic) used to run containerized applications. Oracle Cloud has since shifted its strategic container runtime offerings to Oracle Cloud Infrastructure (OCI) services such as OCI Container Instances, OCI Container Engine for Kubernetes (OKE), and OCI Functions. Availability, onboarding, and pricing for the legacy service can vary by account and may no longer be offered for new customers. Verify current availability in official Oracle documentation and your Oracle Cloud account.

What this service is

Application Container is (historically) Oracle Cloud’s managed application runtime for deploying and running container-packaged applications without provisioning and managing servers directly.

Simple explanation (one paragraph)

You package your application as a container image (or deploy it using supported runtime packaging), upload it to Oracle Cloud, and Oracle runs it for you—handling the underlying compute, basic scaling patterns, and runtime operations so you can focus on code and releases.

Technical explanation (one paragraph)

Application Container (as Oracle Application Container Cloud Service in Oracle Cloud Classic) provided a managed container execution environment with deployment descriptors (for configuration), integration points to other Oracle Cloud services, and operational controls such as instance sizing, scaling settings, and logging/monitoring hooks. In modern OCI, similar outcomes are achieved using OCI Container Instances (serverless-style container runtime), OKE (managed Kubernetes), and supporting services like OCI Registry (OCIR), IAM, VCN, Logging, and Monitoring.

What problem it solves

Teams want to run containerized web APIs, background workers, and microservices without: – managing VMs, OS patching, and host-level Docker operations – maintaining a full Kubernetes control plane for small-to-medium workloads – building a bespoke deployment platform

Application Container aimed to provide a “deploy containers, get an endpoint, operate safely” experience in Oracle Cloud.

2. What is Application Container?

Official purpose

Historically, Application Container (Oracle Application Container Cloud Service) was designed to deploy and run applications packaged in containers in Oracle Cloud, supporting typical web/service workloads with managed infrastructure.

Because Oracle has evolved its cloud platform, the official purpose you should validate today is: – Whether Oracle Application Container Cloud Service is still available to your tenancy (legacy/Classic), and – Which OCI-native services Oracle recommends for new deployments (typically OCI Container Instances, OKE, or Functions).

Verify in official docs: – Oracle Cloud Infrastructure documentation: https://docs.oracle.com/en-us/iaas/ – Oracle Cloud pricing entry points: https://www.oracle.com/cloud/pricing/ and https://www.oracle.com/cloud/costestimator.html

Core capabilities (conceptually)

Depending on the generation of the service (Classic vs OCI-native alternatives), “Application Container” style capabilities typically include: – Running container images as managed workloads – Configuring environment variables and application settings – Exposing HTTP(S) endpoints – Integrating with identity, networking, logs, and metrics – Supporting CI/CD-driven deployments

Major components (how to think about it)

Even if the legacy service is not available, the functional components you’ll use in Oracle Cloud to implement “Application Container” outcomes are:

Component	What it does in Oracle Cloud	Typical OCI service(s)
Container image repository	Stores versioned container images	OCI Registry (OCIR)
Runtime to execute containers	Runs containers without managing servers	OCI Container Instances (or OKE)
Networking	Private networks, ingress, routing, security rules	VCN, subnets, security lists/NSGs, Load Balancer
Identity and permissions	Who can push/pull images and deploy runtimes	OCI IAM (policies, dynamic groups, auth tokens)
Secrets	Store credentials securely	OCI Vault
Logs and metrics	Centralize and search logs; view metrics/alarms	OCI Logging, OCI Monitoring, Alarms, Events
Build/Deploy automation	CI/CD pipelines and artifacts	OCI DevOps (verify), or external tools (GitHub Actions/Jenkins)

Service type

Legacy Application Container (Classic): PaaS (platform-managed runtime)
OCI-native replacement pattern: Managed container runtime (Container Instances) or Managed Kubernetes (OKE)

Regional/global/zonal scope

OCI services used for the “Application Container” pattern are generally regional resources (for example, VCN is regional; subnets may be regional in OCI; verify specifics per service).
Identity (IAM) is tenancy-wide, with policies scoped via compartments.

How it fits into the Oracle Cloud ecosystem

Think of Application Container as a runtime layer: – Above: your app code, CI/CD, and deployment process – Beside: databases (Autonomous Database, MySQL), messaging/streaming, API Gateway, Load Balancer – Below: VCN networking, IAM, logging/monitoring, registry

In OCI, a common modern mapping is: – OCIR (images) → Container Instances (runtime) → Load Balancer (ingress) → DB/Object Storage/Streaming (dependencies), all governed by IAM and observed with Logging/Monitoring.

3. Why use Application Container?

Business reasons

Faster time-to-market: deploy containerized apps without waiting for platform teams to provision and harden VM stacks.
Standardization: consistent deployment unit (container image) across dev/test/prod.
Reduced operational overhead: fewer moving parts than self-managed container hosts or bespoke platforms.

Technical reasons

Immutable deployments: image-based releases improve repeatability and rollback strategies.
Portability: containers can move between environments (local Docker, CI, OCI runtime).
Dependency encapsulation: packages libraries and runtime dependencies consistently.

Operational reasons

Simplified patching model: fewer host OS concerns (especially with managed runtimes).
Observability alignment: central logs/metrics and alarms are easier to standardize.
Scalable patterns: scale out horizontally with multiple instances behind a load balancer (exact mechanics depend on the runtime service—verify).

Security/compliance reasons

Identity-driven access: IAM policies can restrict who can deploy, pull images, or view logs.
Network segmentation: run workloads in private subnets, use controlled ingress, and reduce public exposure.
Auditability: OCI Audit can record control plane actions (verify coverage for each service).

Scalability/performance reasons

Right-size quickly: choose CPU/memory profiles appropriate for your service.
Elasticity patterns: add replicas/instances and distribute traffic.

When teams should choose it

Choose an “Application Container” approach in Oracle Cloud when you need: – A managed runtime for HTTP APIs, microservices, internal tools, and background workers – A container-based delivery model with minimal platform overhead – Clear separation of duties: developers ship images; ops govern IAM/networking/observability

When teams should not choose it

Avoid this approach (or choose a different OCI service) when: – You need full Kubernetes control (custom controllers, service mesh, complex scheduling) → consider OKE – You need event-driven/serverless functions with per-request billing → consider OCI Functions – You require very specialized networking/kernel capabilities or privileged containers → consider Compute or Kubernetes with careful governance – You are depending on Oracle Cloud Classic legacy services—prefer OCI-native services for new builds (verify availability and support timelines)

4. Where is Application Container used?

Industries

SaaS and software companies shipping microservices
Finance and insurance for internal APIs and integration services
Retail and e-commerce for web backends and campaign services
Telecommunications for service mediation and API layers
Healthcare for integration workloads (with strict security controls)

Team types

Platform engineering teams offering a container runtime to application squads
DevOps/SRE teams standardizing CI/CD and runtime operations
Development teams who want containers but not Kubernetes complexity
Security teams enforcing least privilege, private networking, and audit logging

Workloads

REST/gRPC APIs
Web applications (frontend + backend)
Background workers (queues, schedulers)
ETL/data ingestion microservices
Integration adapters (calling ERP/CRM systems)

Architectures

Microservices behind a load balancer
Three-tier app: web → API → database
Event-driven pipelines (with streaming/queues)
Hybrid integration: on-prem systems connecting to OCI apps

Real-world deployment contexts

Production services with rolling releases, load balancing, and alarms
Dev/test sandboxes for feature branches
Multi-environment setups (dev/stage/prod) using compartments and tagging

Production vs dev/test usage

Dev/test: smaller CPU/memory, relaxed scaling, shorter retention for logs, frequent redeploys
Production: private subnets, WAF/load balancer, strict IAM, alarms, on-call runbooks, and controlled outbound access

5. Top Use Cases and Scenarios

Below are realistic “Application Container” style scenarios in Oracle Cloud. Where the legacy service is unavailable, implement them with OCI Container Instances or OKE.

1) Containerized REST API for a mobile app

Problem: You need a stable API backend with repeatable deployments.
Why this service fits: Container image release process is consistent; managed runtime reduces ops burden.
Scenario: A Node/Java/Python API is deployed as an image, fronted by an OCI Load Balancer and connected to Autonomous Database.

2) Internal admin portal

Problem: Internal tools need secure access and rapid iteration.
Why it fits: Easy deployments; tight IAM and network controls.
Scenario: Admin UI runs in a private subnet; access is via VPN/FastConnect and internal DNS.

3) Background worker processing queue messages

Problem: Offload async tasks from the web tier.
Why it fits: Long-running container processes; scale workers by replicas.
Scenario: Workers pull jobs from a queue/streaming service and write results to Object Storage.

4) Webhook receiver for third-party integrations

Problem: You must receive inbound webhooks reliably and securely.
Why it fits: Expose a single endpoint; validate signatures; forward events internally.
Scenario: A small API service receives Stripe/Git provider webhooks and publishes to a streaming topic.

5) Multi-tenant SaaS microservice

Problem: Tenant isolation and repeatable scaling are required.
Why it fits: Containers support consistent deployment; compartments/tags support governance.
Scenario: Each environment runs multiple services; service-level alarms and dashboards track SLIs.

6) Blue/green or canary releases for a service

Problem: Reduce risk during releases.
Why it fits: Run two versions of the container and shift traffic gradually (often via Load Balancer).
Scenario: Deploy v2 alongside v1 and adjust LB routing (method depends on LB features—verify).

7) Batch ingestion microservice

Problem: Periodically ingest data from external sources.
Why it fits: Containerized job can run on schedule via external scheduler or OCI Events/Functions (verify).
Scenario: A container pulls CSV files from SFTP, transforms them, stores results in Object Storage.

8) API facade in front of legacy systems

Problem: You need a modern API while backends are legacy.
Why it fits: Lightweight stateless API container; network connectivity to on-prem via FastConnect/VPN.
Scenario: API validates JWT, maps requests to SOAP/DB calls, returns normalized JSON.

9) ML model inference microservice (lightweight)

Problem: Serve a small model with predictable latency.
Why it fits: Container packaging of runtime dependencies; can scale out.
Scenario: A FastAPI inference service runs in a container; autoscaling handled by platform patterns (verify).

10) Security scanner / policy agent sidecar pattern (platform-dependent)

Problem: Enforce policies at runtime.
Why it fits: Container platform can host policy agents; logs centralized.
Scenario: A policy service validates requests and emits audit logs (implementation depends on chosen runtime—verify).

6. Core Features

Because Application Container is widely associated with a legacy Oracle Cloud Classic service, the safest way to describe features is:

Legacy features (what the Classic service typically provided)
OCI-native equivalents (how to achieve it today)

If your account still uses the legacy service, verify exact capabilities in the Classic documentation available to you.

Feature 1: Containerized deployment unit

What it does: Uses a container image (or container-like packaging) as the deployable artifact.
Why it matters: Strong release consistency across environments.
Practical benefit: “Works on my machine” issues are reduced.
Limitations/caveats: You must maintain image security (base image updates, CVE scanning).

Feature 2: Managed runtime (no server management)

What it does: Runs containers without you managing host OS and Docker daemon operations.
Why it matters: Reduces ops overhead and hardening tasks.
Practical benefit: Faster deployments and fewer infrastructure tickets.
Limitations/caveats: Less low-level control; some workloads requiring privileged access may not work.

Feature 3: Configuration injection (env vars / deployment descriptors)

What it does: Allows configuration outside the image (environment variables, settings).
Why it matters: Promotes 12-factor app practices.
Practical benefit: Same image can be reused across dev/stage/prod.
Limitations/caveats: Don’t store secrets in plaintext env vars; use Vault/secrets patterns.

Feature 4: Service exposure (HTTP endpoint)

What it does: Exposes an application endpoint, often via a load balancer or platform routing.
Why it matters: Standard way to publish APIs.
Practical benefit: Predictable DNS and TLS termination patterns.
Limitations/caveats: Network design matters; avoid direct public exposure when not required.

Feature 5: Horizontal scaling patterns

What it does: Supports running multiple instances/replicas.
Why it matters: Enables higher availability and throughput.
Practical benefit: Scale-out handles spikes better than vertical-only scaling.
Limitations/caveats: Your app must be stateless (or externalize state to DB/cache).

Feature 6: Rolling deployments / versioning (pattern)

What it does: Enables replacing instances gradually (or running parallel versions).
Why it matters: Reduces downtime and release risk.
Practical benefit: Safer deploys with rollback options.
Limitations/caveats: Exact deployment controls differ by runtime; verify.

Feature 7: Logging integration

What it does: Emits container logs to a centralized service.
Why it matters: Operational debugging and auditability.
Practical benefit: Faster incident resolution.
Limitations/caveats: Log volume can become a cost driver; set retention.

Feature 8: Metrics and alarms integration

What it does: Publishes runtime metrics (CPU/memory, request rates if instrumented).
Why it matters: Alerts before outages.
Practical benefit: SRE-grade visibility when combined with SLIs/SLOs.
Limitations/caveats: App-level metrics require instrumentation (Prometheus/OpenTelemetry patterns—verify supported integrations).

Feature 9: IAM-controlled access to images and deployment

What it does: Restricts who can push images, deploy runtimes, and view logs.
Why it matters: Prevents unauthorized releases and supply-chain issues.
Practical benefit: Enforce least privilege and separation of duties.
Limitations/caveats: Misconfigured policies are a common failure mode.

Feature 10: Network isolation and private connectivity (with OCI patterns)

What it does: Runs workloads inside a VCN with private subnets and controlled ingress/egress.
Why it matters: Supports compliance and reduces attack surface.
Practical benefit: Private services can still be reachable via API Gateway/LB.
Limitations/caveats: Requires careful subnet, route table, and security list/NSG configuration.

7. Architecture and How It Works

High-level architecture

An “Application Container” architecture in Oracle Cloud typically looks like:

Developers build a container image.
The image is pushed to OCI Registry (OCIR).
A managed runtime (legacy Application Container service or modern OCI Container Instances/OKE) pulls the image.
Networking controls expose the app: – private-only service, or – public endpoint via OCI Load Balancer (optionally with WAF/API Gateway—verify).
Observability services collect logs/metrics; IAM and Audit govern changes.

Request / data / control flow

Control plane flow: Console/CLI/API → IAM auth → runtime service creates/updates deployments → pulls image from registry.
Data plane flow: Client → DNS → Load Balancer → container runtime → downstream dependencies (DB/Object Storage/Streaming).
Telemetry flow: Container stdout/stderr → Logging; system/app metrics → Monitoring → Alarms/Notifications.

Integrations with related services (common)

OCI Registry (OCIR): container images
VCN: network segmentation
Load Balancer: stable ingress, TLS termination
API Gateway (optional): API management, auth offload (verify)
Vault: secrets management
Logging / Monitoring / Alarms: ops
Notifications: send alarm notifications
Audit: track administrative actions
Autonomous Database / MySQL / Object Storage: data dependencies

Dependency services

At minimum for OCI-native runtime patterns: – OCI IAM – VCN + subnet + security rules – OCIR (or a public registry) – Logging/Monitoring (recommended)

Security/authentication model

Users and groups are managed in OCI IAM.
Access is controlled via policies scoped to compartments.
Pushing images to OCIR commonly uses auth tokens (for Docker login) tied to a user, or automation-friendly credentials (verify best practice for your org).
Runtime pulling from OCIR must have permission; depending on the runtime, this can be via service principals/dynamic groups or configuration (verify).

Networking model

Runtime resources attach to a subnet in a VCN.
Ingress is allowed via security list/NSG rules (ports like 80/443/8080).
For production:
prefer private subnets for workloads
terminate TLS at a Load Balancer
use controlled egress (NAT Gateway) for outbound internet access if required

Monitoring/logging/governance considerations

Use compartments for environment separation (dev/stage/prod).
Apply tags (cost center, app name, owner, environment).
Enable Logging for container logs (verify per service).
Create alarms for:
runtime health/availability
high CPU/memory
high 5xx from LB
Track deployments via Audit and CI/CD.

Simple architecture diagram (conceptual)

flowchart LR
  Dev[Developer Laptop / CI] -->|docker build| Img[Container Image]
  Img -->|push| OCIR[(OCI Registry - OCIR)]
  OCIR -->|pull| Runtime[Application Container Runtime]
  User[Client] -->|HTTPS| LB[Load Balancer]
  LB --> Runtime
  Runtime --> DB[(Database)]
  Runtime --> Logs[Logging/Monitoring]

Production-style architecture diagram (OCI-native implementation)

flowchart TB
  subgraph "OCI Tenancy"
    subgraph "Compartment: prod"
      OCIR[(OCIR Repo)]
      Vault[(OCI Vault)]
      Log[(OCI Logging)]
      Mon[(OCI Monitoring/Alarms)]
      Audit[(OCI Audit)]

      subgraph "VCN"
        subgraph "Public Subnet"
          LB[OCI Load Balancer\nTLS Termination]
          WAF[WAF / API Gateway (optional)\nVerify in docs]
        end
        subgraph "Private Subnet"
          RT[Container Runtime\n(OCI Container Instances or OKE)]
          NAT[NAT Gateway (optional)]
        end
        DB[(Autonomous DB / DB System)]
      end
    end
  end

  Internet[Internet Clients] --> WAF --> LB --> RT
  RT --> DB
  RT --> Vault
  RT --> Log
  RT --> Mon
  Console[OCI Console/CI-CD] -->|Deploy/Update| RT
  Console --> OCIR
  Audit <-- Console

8. Prerequisites

Because of the legacy vs OCI-native split, prerequisites are listed in two parts.

A) If you are using legacy Oracle Cloud Classic “Application Container”

An Oracle Cloud Classic account/identity domain with the service enabled
Permissions to deploy applications and view logs
Access to the Classic console and documentation available to your account
Verify in official docs for Classic service onboarding (availability varies)

B) For the executable lab in this tutorial (OCI-native “Application Container” pattern)

You’ll implement “Application Container” outcomes using OCI Container Instances + OCIR.

Account/tenancy requirements

An Oracle Cloud (OCI) tenancy with access to:
OCI Registry (OCIR)
Container runtime service (commonly OCI Container Instances; verify region availability)
Networking (VCN)
Logging/Monitoring

Permissions / IAM

You need permissions to: – create and manage repositories in OCIR – create and manage networking (VCN/subnets/security rules) – create and manage container instances (or equivalent runtime resources) – view logs

If you are not an admin, ask for a compartment-level policy set that allows those actions. Exact policy statements depend on your org model and the chosen runtime—verify with OCI IAM docs.

OCI IAM docs: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

Billing requirements

A paid tenancy or trial with billing enabled may be required.
OCI has an Always Free program, but not every service is Always Free in every region. Verify current eligibility:
https://www.oracle.com/cloud/free/

CLI/SDK/tools

Docker (or compatible container engine) locally
Optional: OCI CLI (useful for automation, not required for the lab)
OCI CLI docs: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
A code editor

Region availability

Choose an OCI region where OCIR and the selected container runtime service are available.
If “Container Instances” is not available in your region/tenancy, use OKE or Compute + Docker as an alternative (not identical, but executable).

Quotas/limits

Service limits may restrict number of container instances, VCNs, or load balancers.
Check: OCI Console → Governance → Limits, Quotas (naming may vary—verify).

Prerequisite services

VCN with subnet(s)
OCIR repository (or a public registry image)
Logging (recommended)

9. Pricing / Cost

Current pricing model (how to think about it)

Because Application Container is widely associated with a legacy Oracle Cloud Classic service, pricing can be confusing:

Legacy (Classic) Application Container pricing: historically offered in metered/non-metered models. Do not assume those SKUs are still purchasable or publicly listed. Verify in your Oracle contract and Classic pricing references available to your account.
OCI-native approach pricing: you pay for the OCI services you use:
Container runtime (CPU/memory time)
Networking (Load Balancer, outbound data transfer)
Registry storage and requests
Logging ingestion and retention (depending on configuration)
Any dependent data services (DB, Object Storage, Streaming)

Official pricing sources (start here)

Oracle Cloud Pricing: https://www.oracle.com/cloud/pricing/
Oracle Cloud Cost Estimator: https://www.oracle.com/cloud/costestimator.html
OCI Price List (often linked from pricing pages): https://www.oracle.com/cloud/price-list/

Pricing dimensions (OCI-native “Application Container” pattern)

The exact dimensions vary by service and region, but commonly include:

Compute for container runtime – Billed by allocated CPU (OCPU/vCPU) and memory per time unit – Some runtimes may bill for provisioned capacity even when idle (verify)
Load Balancer – Hourly LB cost + bandwidth/LCU-style usage (model varies—verify in OCI LB pricing)
Container registry (OCIR) – Storage used by images – Data transfer when pulling/pushing images (especially cross-region) – Requests/operations may be priced (verify)
Logging and Monitoring – Log ingestion volume and retention can cost money depending on SKU/config – Metrics/alarm features may have free quotas; verify
Network egress – Outbound data transfer to the internet is often a meaningful cost driver – Cross-region data transfer can also cost money

Free tier considerations

OCI Free Tier: https://www.oracle.com/cloud/free/
Free eligibility varies by region and service. Confirm whether Container Instances and Load Balancer usage is included or discounted.

Key cost drivers

Always-on workloads with high CPU/memory allocation
Public-facing services with high outbound bandwidth
Frequent deployments pulling large images repeatedly
High-volume logs (debug logging in production)

Hidden or indirect costs

CI/CD runners (if self-hosted) and build minutes (if using external platforms)
Image storage growth from unpruned tags
Vulnerability scanning tooling (if not included) and operational overhead
Data services (DB, cache) often dominate runtime costs

Network/data transfer implications

Keep container runtime and database in the same region to avoid cross-region data charges and latency.
Consider private endpoints and avoid routing internal traffic over the public internet.

How to optimize cost

Right-size CPU/memory; measure before scaling up.
Use autoscaling only where it truly reduces cost (some models scale capacity up but do not reduce to zero—verify).
Keep images small (multi-stage builds, slim base images).
Reduce log verbosity; set retention policies.
Use private networking to avoid unnecessary egress.

Example low-cost starter estimate (no fabricated numbers)

A minimal starter setup typically includes: – 1 small container runtime instance (low CPU/memory) – No load balancer (direct test endpoint) or a single small LB (if required) – Small OCIR repository with one image – Basic logging

Because prices vary by region and service SKU, use: – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html
Select your region, then add: – Container runtime service (Container Instances or OKE worker nodes) – Load Balancer (if used) – OCIR storage estimate (e.g., a few GB) – Expected outbound bandwidth (GB/month)

Example production cost considerations

In production, cost is usually dominated by: – multiple replicas for availability – a load balancer (often required) – outbound data transfer – database tier and storage/IO – logging volume and retention – non-prod environments that are left running 24/7

A practical governance approach: – Tag all resources with environment, application, owner, cost-center – Use budgets and alerts (OCI Budgets—verify service availability)

10. Step-by-Step Hands-On Tutorial

This lab shows a modern, executable “Application Container” deployment pattern on Oracle Cloud (OCI) using: – OCI Registry (OCIR) to store your image – OCI Container Instances to run the container (or the closest equivalent available in your tenancy)

If OCI Container Instances is not available in your region/tenancy, use OKE (more complex) or Compute + Docker (more manual). The image build/push steps still apply.

Objective

Build and deploy a small containerized web API (“hello”) to Oracle Cloud so it runs as a managed container workload and is reachable over HTTP for validation.

Lab Overview

You will: 1. Create (or choose) an OCI compartment and network (VCN + subnet). 2. Create an OCIR repository and push a container image. 3. Deploy the image to a managed container runtime (OCI Container Instances). 4. Validate the service endpoint and view logs. 5. Clean up resources to avoid ongoing charges.

Step 1: Prepare your OCI compartment and region

Sign in to the OCI Console.
Choose the region you will use (top-right region selector).
Create or select a compartment for the lab, for example: lab-application-container.

Expected outcome: You have a compartment to isolate resources and costs.

Verification: – You can see the compartment in the compartment selector. – You have permission to create networking and registry resources in it.

Step 2: Create a VCN and a public subnet (for a simple demo)

For a beginner-friendly demo, use a VCN with a public subnet so you can test from your laptop. For production, prefer a private subnet + load balancer.

In OCI Console, go to Networking → Virtual Cloud Networks.
Create VCN.
Choose VCN with Internet Connectivity (wizard naming may vary; verify).
Ensure you get: – a VCN – an Internet Gateway – a public subnet – a route table that routes 0.0.0.0/0 to the Internet Gateway

Expected outcome: A VCN exists with a public subnet capable of inbound/outbound internet connectivity.

Verification: – Subnet is marked public (or has route via Internet Gateway). – Route table includes 0.0.0.0/0 -> Internet Gateway.

Security rule setup (important): – Add an ingress rule (Security List or NSG depending on your design) to allow TCP 8080 from your IP for the lab: – Source: your-public-ip/32 (recommended)
– Destination port: 8080 – Protocol: TCP

If you cannot restrict to your IP, use 0.0.0.0/0 temporarily only for this lab, then remove it.

Expected outcome: Network rules allow inbound access to port 8080.

Step 3: Create an OCIR repository

In OCI Console, navigate to Developer Services → Container Registry (OCIR) (menu names vary; you can also search for “Registry”).
Create a new repository, for example: – Repository name: hello-application-container – Visibility: Private (recommended)

Expected outcome: A private OCIR repository exists.

Verification: – Repository shows up in OCIR with an empty tag list initially.

Step 4: Create an Auth Token for OCIR (for Docker login)

OCIR commonly uses an Auth Token for Docker CLI authentication.

Go to Profile → User settings (top-right user menu).
Find Auth Tokens.
Generate a new token (save it securely; you typically can’t view it again).

Expected outcome: You have an auth token string.

Verification: – Token appears in your Auth Tokens list.

Security note: Treat auth tokens like passwords. Prefer short-lived tokens and least privilege.

Step 5: Build a tiny web app and container image locally

Create a folder hello-app with two files.

`app.py`

from flask import Flask
import os

app = Flask(__name__)

@app.get("/")
def hello():
    name = os.getenv("NAME", "Oracle Cloud")
    return {"message": f"Hello from Application Container pattern on {name}!"}

if __name__ == "__main__":
    # Container Instances typically expects you to bind to 0.0.0.0
    app.run(host="0.0.0.0", port=8080)

`requirements.txt`

flask==3.0.3

`Dockerfile`

FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

ENV PORT=8080
EXPOSE 8080

CMD ["python", "app.py"]

Build the image:

cd hello-app
docker build -t hello-application-container:1.0 .

Run locally to confirm:

docker run --rm -p 8080:8080 -e NAME="Oracle Cloud" hello-application-container:1.0

Test:

curl http://localhost:8080/

Expected outcome: – You receive a JSON response like: – {"message":"Hello from Application Container pattern on Oracle Cloud!"}

Verification: – The container logs show Flask listening on 0.0.0.0:8080.

Step 6: Log in to OCIR and push the image

OCIR registry endpoints are region-specific and tenancy-specific. The exact registry URL format can vary (for example, includes a region key and tenancy namespace). Use the OCIR console “View Login Instructions” (or similar) to get the exact commands for your region.

Typical flow:

Get your OCIR namespace (shown in the OCIR console).
Identify the OCIR registry endpoint for your region (shown in login instructions).
Docker login using: – Username: often in the form tenancy-namespace/oracleidentitycloudservice/your.user@company.com (format varies—verify) – Password: the auth token you created

Example pattern (VERIFY and replace with your values):

docker login <region-key>.ocir.io

Tag your image for OCIR (VERIFY registry/namespace/repo):

docker tag hello-application-container:1.0 <region-key>.ocir.io/<ocir-namespace>/hello-application-container:1.0

Push:

docker push <region-key>.ocir.io/<ocir-namespace>/hello-application-container:1.0

Expected outcome: The image is uploaded and visible in OCIR with tag 1.0.

Verification: – In OCIR console, open the repository and confirm the tag is present. – The image size and digest are shown.

Step 7: Deploy the image to OCI Container Instances (runtime)

Console navigation varies; use the search bar for “Container Instances”.

Go to Container Instances.
Create a new container instance with: – Compartment: lab-application-container – Name: hello-ci-1 – VCN/subnet: select your public subnet created earlier – Image source: OCIR and select your repository/tag – Container port: 8080 – Environment variables:
- NAME=Oracle Cloud
- Public IP:
- Enable if you want direct public testing (lab only)

Expected outcome: A container instance is created and transitions to a running/active state.

Verification: – Container instance lifecycle state is “Running” (wording may differ). – It shows an assigned private IP and (if enabled) a public IP.

Step 8: Test the deployed service

If you enabled a public IP, test it:

curl http://<PUBLIC_IP>:8080/

Expected outcome: You receive the same JSON message from Oracle Cloud.

Verification checklist: – HTTP 200 response – Correct JSON payload – Container instance metrics/logs show activity (if enabled)

Step 9: View logs (and confirm operational visibility)

Depending on your setup, you may: – view logs in the container instance details page, or – configure OCI Logging to collect container logs

Check: – OCI Console → Logging → Log Explorer (if configured) – Container instance details → Logs (if present)

Expected outcome: You can see request logs and application startup logs.

Validation

You have successfully implemented an “Application Container” runtime pattern on Oracle Cloud if: – The container image exists in OCIR – The container runtime is running the image – You can curl the endpoint and receive a valid response – You can access logs for basic troubleshooting

Troubleshooting

Issue: `docker login` fails (401 Unauthorized)

Common causes – Using your OCI console password instead of an Auth Token – Wrong OCIR endpoint/region key – Wrong username format

Fix – Re-check OCIR “login instructions” in the console – Create a new Auth Token and retry – Confirm your user has permissions to access OCIR in the compartment/tenancy

Issue: Push succeeds, but runtime can’t pull image

Common causes – Repository is private and runtime lacks permission – Incorrect image tag specified – Network egress blocked

Fix – Verify repository visibility and IAM permissions – Confirm the exact image reference – Ensure the runtime subnet has required routing (and NAT/IGW if needed)

Issue: `curl` times out

Common causes – Ingress rule missing for port 8080 – Public IP not enabled – App bound to 127.0.0.1 instead of 0.0.0.0

Fix – Add/verify security list or NSG rule for TCP 8080 – Confirm the runtime has a public IP for direct testing – Ensure app listens on 0.0.0.0 (as in this lab)

Issue: Container starts then stops

Common causes – App crashes due to missing dependencies – Wrong command/port – Not enough memory

Fix – Review container logs – Run the same container locally – Increase memory allocation (and then optimize later)

Cleanup

To avoid charges, delete resources created in this lab:

Delete the container instance.
Delete the OCIR repository (and images).
Delete the VCN (wizard-created VCN deletion typically removes sub-resources; verify dependencies).
Delete any log groups/logs created specifically for the lab.

Expected outcome: No billable resources remain for the tutorial.

11. Best Practices

Architecture best practices

Prefer stateless services; store state in managed services (DB, Object Storage).
Put production workloads in private subnets; use a Load Balancer for ingress.
Design for multi-AZ/AD patterns where applicable (OCI constructs vary; verify per region/service).
Use health checks and graceful shutdown in your app.

IAM/security best practices

Use least-privilege IAM policies scoped to compartments.
Separate duties:
developers can push images to specific repos
platform team controls runtime creation and networking
Rotate auth tokens and credentials regularly.
Use dynamic groups and instance principals/service principals where possible (verify support for your runtime service).

Cost best practices

Right-size CPU/memory; start small and measure.
Remove unused images/tags in OCIR (lifecycle policies if available—verify).
Use budgets/alerts and tags for chargeback.
Avoid excessive logging; set retention.

Performance best practices

Use small images; multi-stage builds.
Cache dependencies at build time.
Add app-level metrics (OpenTelemetry/Prometheus patterns) and track latency/throughput.
Use connection pooling for DB access.

Reliability best practices

Run multiple replicas behind a load balancer for critical services.
Implement retries with backoff for downstream calls.
Use timeouts and circuit breakers.
Keep deployments reversible (version tags, rollback playbook).

Operations best practices

Centralize logs and standardize log fields (service name, version, request-id).
Set alarms on:
container restarts/crash loops
high latency / 5xx at the edge
CPU/memory saturation
Create runbooks for common failures (image pull errors, network rules, quota limits).

Governance/tagging/naming best practices

Naming:
env-app-component (e.g., prod-payments-api)
Tags:
environment=dev|stage|prod
application=hello
owner=email/team
cost-center=...
Use compartments per environment and per team for clarity and blast-radius control.

12. Security Considerations

Identity and access model

OCI uses IAM policies evaluated against groups, dynamic groups, and resource principals.
Control access to:
OCIR repositories (push/pull)
runtime creation/update
logs and metrics visibility
Prefer automation identities for CI/CD rather than personal user accounts.

IAM docs: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

Encryption

Data at rest encryption is generally provided by OCI for managed services (verify per service).
Data in transit:
Use TLS end-to-end where possible
Terminate TLS at an OCI Load Balancer for simpler cert management (or use mTLS patterns if required—verify)

Network exposure

Avoid public IPs in production.
Use:
private subnets for workloads
Load Balancer/WAF/API Gateway for ingress control
tightly scoped security rules (source IP restrictions)

Secrets handling

Common mistakes: – baking secrets into container images – putting secrets directly into environment variables stored in plaintext configs

Recommendations: – Use OCI Vault for secrets, keys, and certificates. – Inject secrets at runtime using a supported secret delivery method (depends on runtime; verify). – Rotate secrets and audit access.

Vault docs: https://docs.oracle.com/en-us/iaas/Content/KeyManagement/home.htm

Audit/logging

Enable OCI Audit (generally enabled by default for OCI API calls; verify) and review:
who deployed
what changed
when changes occurred

Audit docs: https://docs.oracle.com/en-us/iaas/Content/Audit/home.htm
Logging docs: https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm

Compliance considerations

Ensure data residency requirements are met by choosing the correct region.
Use compartment separation and IAM controls to enforce environment boundaries.
For regulated workloads, document:
encryption controls
access reviews
logging retention
incident response procedures

Secure deployment recommendations

Use signed images or provenance where possible (tooling-dependent; verify OCI support).
Scan images for vulnerabilities in CI (and optionally in registry if supported—verify).
Use minimal base images and pinned versions.
Run as non-root in containers where possible.

13. Limitations and Gotchas

Known limitations (practical)

Legacy ambiguity: “Application Container” often refers to a Classic service that may be retired or unavailable for new accounts.
Feature variance by runtime: OCI Container Instances vs OKE vs Compute+Docker have different capabilities and operational responsibilities.
Ingress design: Direct public IP testing is easy, but production-grade ingress usually needs a Load Balancer and careful security controls.
Stateful workloads: Containers are best for stateless services; persistent disks and state introduce complexity (use DB/Object Storage).

Quotas

Limits can block creation of:
container instances
VCNs/subnets
load balancers
public IPs
Check limits in OCI Console (Governance).

Regional constraints

Not every OCI service is available in every region.
Some features arrive region-by-region. Always verify the region’s service availability.

Pricing surprises

Load balancers and outbound bandwidth can dwarf compute costs.
Logging ingestion/retention can become expensive at scale if not controlled.
Pulling large images repeatedly (especially cross-region) can increase network cost.

Compatibility issues

Containers requiring privileged mode, special kernel modules, or host networking may not run in managed runtimes.
Some runtimes restrict writable filesystem paths; design apps accordingly.

Operational gotchas

Misconfigured security lists/NSGs are the #1 reason endpoints “don’t work”.
Image pull failures often trace back to IAM permissions or wrong OCIR reference.
Large images slow deployments; keep them lean.

Migration challenges

If you’re migrating from Oracle Cloud Classic “Application Container”: – Expect changes in identity model (Classic identity domain vs OCI IAM/compartments). – Networking models differ; plan VCN/subnet and routing carefully. – Rebuild CI/CD pipelines to target OCIR and OCI runtime APIs.

14. Comparison with Alternatives

Options to consider

Within Oracle Cloud (OCI):
OCI Container Instances (closest “run my container” experience)
OCI Container Engine for Kubernetes (OKE)
OCI Functions
OCI Compute + self-managed Docker
Other clouds:
AWS App Runner, ECS/Fargate
Azure Container Apps / AKS
Google Cloud Run / GKE
Open-source/self-managed:
Kubernetes (self-managed)
Nomad
Docker Swarm (less common)

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud – Application Container (Classic legacy)	Existing Classic customers	PaaS-style simplicity (historically)	May be legacy/retired; limited new adoption	Only if your org already uses it and it’s still supported for you
OCI Container Instances	Simple containerized services without Kubernetes	Minimal ops; quick deploy; integrates with OCI IAM/VCN	Less control than Kubernetes; feature set depends on service	Default choice for “run a container” on OCI if available
OCI Container Engine for Kubernetes (OKE)	Platform teams, complex microservices, Kubernetes ecosystem	Kubernetes flexibility; ecosystem tools; advanced scheduling	Operational complexity; cluster management	Choose when you need Kubernetes primitives and integrations
OCI Functions	Event-driven workloads, spiky traffic	Serverless model; per-invocation patterns	Runtime/time limits; not ideal for long-running services	Choose for async/event-based execution
OCI Compute + Docker	Maximum control, specialized workloads	Full OS control; broad compatibility	You manage patching, scaling, host security	Choose when managed runtimes don’t support your needs
AWS App Runner / ECS Fargate	Managed containers on AWS	Mature ecosystem; multiple runtime choices	Vendor differences; networking/IAM changes	Choose if workloads are primarily AWS-based
Azure Container Apps	Managed containers on Azure	Good developer experience; KEDA scaling	Azure-specific operational model	Choose if workloads are primarily Azure-based
Google Cloud Run	Serverless containers	Very simple deploy; scale-to-zero patterns	Platform constraints; Google-specific	Choose for HTTP workloads with bursty traffic
Self-managed Kubernetes	Full control across environments	Portability; no managed-service constraints	Highest ops cost; steep learning curve	Choose when you must control everything and accept ops overhead

15. Real-World Example

Enterprise example: Internal API modernization with controlled network access

Problem: A finance enterprise is decomposing a monolith into internal microservices. Services must be reachable only within corporate networks, with strict auditability.
Proposed architecture:
Container images stored in OCIR
Services deployed to OCI Container Instances (or OKE if Kubernetes standards are mandated)
Workloads run in private subnets
Ingress via OCI Load Balancer (internal) and corporate connectivity (VPN/FastConnect)
Secrets in OCI Vault
Logs in OCI Logging, alarms in OCI Monitoring, audit via OCI Audit
Why this service was chosen: The “Application Container” approach standardizes deployment via images while avoiding host management; private networking aligns with security controls.
Expected outcomes:
Faster release cadence with consistent deployments
Reduced attack surface (no public IPs)
Better operational visibility and audit trails

Startup/small-team example: Public SaaS API with minimal platform overhead

Problem: A startup needs to ship a public API quickly with a small team and limited SRE bandwidth.
Proposed architecture:
Build/push images to OCIR
Run API on OCI Container Instances
Public ingress via a single OCI Load Balancer (TLS termination)
Use managed database (Autonomous Database or MySQL—choice depends on app needs)
Basic alarms for uptime and error rates
Why this service was chosen: Containers provide portability and developer speed; managed runtime avoids building Kubernetes expertise early.
Expected outcomes:
Quick deployments, simpler operations
Cost control via right-sizing and image optimization
Clear migration path to OKE if complexity grows

16. FAQ

1) Is “Application Container” an active OCI service today?
“Application Container” is often used to refer to Oracle Application Container Cloud Service (Classic), which may be legacy/retired for new onboarding. For OCI, similar functionality is typically delivered by OCI Container Instances or OKE. Verify in official Oracle docs for your tenancy.

2) What is the closest OCI-native equivalent to Application Container?
Usually OCI Container Instances for “run my container” simplicity, or OKE if you need Kubernetes.

3) Do I need Kubernetes to run containers on Oracle Cloud?
No. You can run containers using managed runtimes (if available) or on Compute instances with Docker. Kubernetes is optional.

4) Where should I store container images in Oracle Cloud?
Use OCI Registry (OCIR) for private images and IAM-governed access.

5) How do I secure my container endpoint?
Prefer private subnets; place an OCI Load Balancer in front; restrict ingress; use TLS; optionally use WAF/API Gateway (verify) and strong IAM.

6) How do I manage secrets for container apps on OCI?
Use OCI Vault. Avoid embedding secrets in images. The injection mechanism depends on your runtime—verify.

7) What networking is required?
At minimum: a VCN, a subnet, and security rules allowing required ports. Production usually uses private subnets + LB + controlled egress.

8) What’s the biggest cause of deployment failure?
Misconfigured IAM permissions for pulling images from OCIR and misconfigured security lists/NSGs for inbound traffic.

9) How do I monitor container health?
Use OCI Monitoring metrics (service-provided) plus application metrics. Add alarms for availability and resource saturation.

10) Is there an Always Free option for this pattern?
OCI Free Tier exists, but eligibility varies by service and region. Verify current free-tier coverage for Container Instances, LB, and Logging.

11) Can I run stateful workloads (databases) in Application Container?
Not recommended. Use managed database services. Containers are best for stateless services.

12) How do I roll back a bad release?
Use immutable tags/versions; redeploy the prior image tag; keep a rollback runbook. Advanced traffic shifting typically requires LB-based patterns.

13) Do I need a load balancer for production?
For most production HTTP services, yes—especially for TLS termination, stable ingress, and multi-instance distribution.

14) How do I reduce container image size?
Use slim base images, multi-stage builds, remove build tools, and pin dependencies.

15) What’s the migration path from legacy Classic Application Container?
Typically: rebuild images → push to OCIR → deploy to OCI Container Instances or OKE → rework IAM/networking/observability to OCI constructs.

17. Top Online Resources to Learn Application Container

The most reliable resources are OCI-native container runtime and registry docs, plus any legacy Classic docs your account still exposes.

Resource Type	Name	Why It Is Useful
Official documentation	OCI Documentation	Entry point for all OCI services, including IAM, networking, logging, and container services: https://docs.oracle.com/en-us/iaas/
Official documentation	OCI Container Engine for Kubernetes (OKE) docs	Managed Kubernetes reference and tutorials: https://docs.oracle.com/en-us/iaas/Content/ContEng/home.htm
Official documentation	OCI Registry (OCIR) docs	How to authenticate, push/pull images, and manage repos: https://docs.oracle.com/en-us/iaas/Content/Registry/home.htm
Official documentation	OCI IAM docs	Policies, compartments, groups, dynamic groups: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm
Official documentation	OCI Networking (VCN) docs	Subnets, security lists/NSGs, gateways, routing: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm
Official documentation	OCI Logging docs	Central logging and search: https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm
Official documentation	OCI Monitoring docs	Metrics, alarms, notifications: https://docs.oracle.com/en-us/iaas/Content/Monitoring/home.htm
Official documentation	OCI Vault / Key Management docs	Secrets, keys, certs: https://docs.oracle.com/en-us/iaas/Content/KeyManagement/home.htm
Official pricing page	Oracle Cloud Pricing	Official pricing entry point: https://www.oracle.com/cloud/pricing/
Official cost tool	Oracle Cloud Cost Estimator	Build region-specific estimates without guessing: https://www.oracle.com/cloud/costestimator.html
Architecture center	Oracle Architecture Center	Reference architectures and best practices: https://www.oracle.com/cloud/architecture/
Official tutorials/labs	Oracle Cloud Free Tier / Getting Started	Account setup and foundational labs: https://www.oracle.com/cloud/free/
Official CLI docs	OCI CLI installation	Automation and scripting reference: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Community learning	Oracle Cloud Infrastructure blogs (official)	Practical patterns and updates (validate accuracy): https://blogs.oracle.com/cloud-infrastructure/

If you specifically need Oracle Application Container Cloud Service (Classic) documentation and your account still provides it, use the documentation links available from within your Classic console. Availability and URLs can differ; verify in your account’s official documentation hub.

18. Training and Certification Providers

The following institutes are provided as training options. Verify course outlines, instructors, and accreditation details on their websites.

1) DevOpsSchool.com – Suitable audience: DevOps engineers, SREs, platform engineers, developers – Likely learning focus: DevOps practices, CI/CD, containers, Kubernetes, cloud fundamentals (including Oracle Cloud topics depending on catalog) – Mode: Online/corporate/self-paced/live (check website) – Website: https://www.devopsschool.com/

2) ScmGalaxy.com – Suitable audience: Beginners to intermediate DevOps practitioners – Likely learning focus: SCM, DevOps tooling, CI/CD pipelines, automation fundamentals – Mode: Online/corporate/self-paced/live (check website) – Website: https://www.scmgalaxy.com/

3) CLoudOpsNow.in – Suitable audience: Cloud operations and DevOps engineers – Likely learning focus: Cloud operations, monitoring, automation, SRE-aligned practices – Mode: Check website – Website: https://cloudopsnow.in/

4) SreSchool.com – Suitable audience: SREs, operations teams, reliability-focused engineers – Likely learning focus: SRE practices, observability, incident management, SLIs/SLOs, reliability engineering – Mode: Check website – Website: https://sreschool.com/

5) AiOpsSchool.com – Suitable audience: Ops teams adopting AIOps and automation – Likely learning focus: AIOps concepts, monitoring analytics, automation, incident reduction – Mode: Check website – Website: https://aiopsschool.com/

19. Top Trainers

The following sites are provided as trainer/platform directories. Verify trainer profiles and Oracle Cloud coverage on each site.

1) RajeshKumar.xyz – Likely specialization: DevOps/cloud coaching (verify specific Oracle Cloud topics on site) – Suitable audience: Individuals and teams seeking guided training – Website: https://rajeshkumar.xyz/

2) devopstrainer.in – Likely specialization: DevOps tooling, CI/CD, containers, cloud fundamentals – Suitable audience: Beginners to intermediate engineers – Website: https://devopstrainer.in/

3) devopsfreelancer.com – Likely specialization: Freelance DevOps consulting/training engagements (verify offerings) – Suitable audience: Teams needing short-term expertise – Website: https://devopsfreelancer.com/

4) devopssupport.in – Likely specialization: DevOps support and enablement (verify training vs support offerings) – Suitable audience: Ops/DevOps teams needing hands-on guidance – Website: https://devopssupport.in/

20. Top Consulting Companies

The following companies are listed as consulting providers. Verify service scope, references, and statements of work directly with the vendor.

1) cotocus.com – Likely service area: Cloud/DevOps consulting (verify Oracle Cloud specialism on site) – Where they may help: Architecture, migration planning, CI/CD implementation, operations setup – Consulting use case examples: – Container platform selection (Container Instances vs OKE) – OCIR and IAM policy design – VCN and ingress/egress hardening – Website: https://cotocus.com/

2) DevOpsSchool.com – Likely service area: DevOps consulting and training services – Where they may help: CI/CD pipelines, containerization standards, operational readiness – Consulting use case examples: – Container build and deployment pipelines to OCIR – Observability setup (Logging/Monitoring alarms) – Governance/tagging for cost control – Website: https://www.devopsschool.com/

3) DEVOPSCONSULTING.IN – Likely service area: DevOps consulting services (verify Oracle Cloud coverage on site) – Where they may help: Toolchain integration, automation, SRE practices adoption – Consulting use case examples: – Secure runtime deployment patterns in OCI – Environment standardization (dev/stage/prod) – Incident response and runbook development – Website: https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To succeed with an Application Container approach on Oracle Cloud, learn: – Linux and basic networking (DNS, routing, ports, TLS) – Containers: – Dockerfiles, image tagging, registries – container security basics (non-root, minimal images) – OCI fundamentals: – compartments, IAM policies – VCN, subnets, security lists/NSGs – OCIR basics

What to learn after this service

Advanced OCI networking (private endpoints, NAT, service gateways—verify)
Observability:
structured logging
metrics, tracing (OpenTelemetry patterns)
Release engineering:
blue/green and canary patterns
GitOps concepts
Kubernetes (OKE) if your platform needs grow:
Helm/Kustomize
Ingress controllers
service mesh (only if justified)

Job roles that use it

Cloud Engineer (OCI)
DevOps Engineer
Site Reliability Engineer (SRE)
Platform Engineer
Solutions Architect
Backend Developer (cloud-native)

Certification path (if available)

Oracle certification offerings change over time. Start here and verify current paths: – Oracle University: https://education.oracle.com/
– OCI certifications listing (verify current): search Oracle University for “OCI certification”.

Project ideas for practice

Deploy a REST API container with OCIR + runtime + alarms.
Add a database and implement migrations safely.
Add private networking and expose via Load Balancer only.
Implement CI/CD: build → scan → push → deploy.
Add structured logs and a dashboard for latency/error rate.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle’s current-generation cloud platform with IAM, VCN, compute, and managed services.
Oracle Cloud Classic: Earlier generation Oracle Cloud platform (legacy for many services).
Container image: Immutable package containing app code and dependencies.
OCIR (OCI Registry): Oracle’s container registry service for storing container images.
Container runtime: The service that runs container images (e.g., Container Instances or Kubernetes nodes).
VCN (Virtual Cloud Network): A private network in OCI.
Subnet: A segmented IP range within a VCN where resources attach.
Security List / NSG: OCI network access control constructs controlling allowed ingress/egress.
Ingress: Incoming traffic to your service.
Egress: Outgoing traffic from your service.
IAM policy: Rules controlling access to OCI resources.
Compartment: OCI’s logical container for organizing and isolating resources and permissions.
Auth Token: Credential used for certain authentications (commonly Docker login to OCIR).
TLS termination: Decrypting HTTPS at an edge component (like a load balancer).
Observability: The combination of logs, metrics, and traces used to understand system behavior.
SLO/SLI: Reliability targets (SLO) and measurements (SLI) used by SRE practices.
Immutable deployment: Deployment method where a new version is deployed as a new artifact, rather than modifying running systems in place.

23. Summary

Application Container in Oracle Cloud most commonly maps to the legacy Oracle Application Container Cloud Service (Classic), which many teams now replace with OCI-native services. In modern OCI, the practical “Application Container” outcome is typically achieved using OCI Container Instances (or OKE for Kubernetes), backed by OCIR for images and governed by IAM, VCN, and Logging/Monitoring.

Why it matters: – It standardizes application delivery around container images. – It reduces server-management overhead compared to DIY Docker on VMs. – It provides a clear path to production-ready patterns with private networking, controlled ingress, and centralized observability.

Key cost/security points: – Costs are driven by runtime CPU/memory, load balancers, outbound bandwidth, and log volume—use the OCI Cost Estimator rather than guessing. – Security depends on least-privilege IAM, private subnets, TLS, and correct secret handling with OCI Vault.

When to use it: – Use an Application Container approach when you want managed container execution with strong governance and minimal ops burden. – Prefer OCI-native services for new builds; treat Classic-era Application Container as legacy unless your account explicitly supports it.

Next learning step: Deepen OCI fundamentals (IAM + VCN) and then choose your runtime path—Container Instances for simplicity or OKE for Kubernetes-based platforms—using Oracle’s official OCI docs: https://docs.oracle.com/en-us/iaas/

rajeshkumar

Category