{"id":868,"date":"2026-04-16T11:54:23","date_gmt":"2026-04-16T11:54:23","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-container-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-16T11:54:23","modified_gmt":"2026-04-16T11:54:23","slug":"oracle-cloud-container-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-container-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"Oracle Cloud Container Instances Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Oracle Cloud <strong>Container Instances<\/strong> is a managed <strong>Compute<\/strong> service that lets you run containerized applications in Oracle Cloud Infrastructure (OCI) without provisioning or managing virtual machines and without operating a Kubernetes cluster.<\/p>\n\n\n\n<p>In simple terms: you provide a container image (for example, from Docker Hub or Oracle Cloud Infrastructure Registry), choose CPU\/memory, networking, and a few runtime settings, and OCI runs your container for you.<\/p>\n\n\n\n<p>Technically, Container Instances is a \u201crun containers on demand\u201d runtime that creates an OCI-managed execution environment for one container workload (and in some configurations, a group of containers that share networking). It integrates with core OCI building blocks such as compartments, IAM policies, VCN networking, logging\/monitoring, and OCI registries.<\/p>\n\n\n\n<p>It solves the common problem of \u201cI want to deploy a container quickly and securely in my VCN, with predictable resource sizing, without the operational overhead of servers or Kubernetes.\u201d It\u2019s especially useful for APIs, background workers, simple web apps, scheduled tasks (with an external scheduler), and event-driven consumers\u2014when you don\u2019t need the full feature set of Kubernetes.<\/p>\n\n\n\n<blockquote>\n<p>Service naming note: As of the latest generally available OCI service lineup, <strong>Container Instances<\/strong> is the current service name under <strong>Compute<\/strong>. If Oracle changes naming or merges capabilities in the future, <strong>verify in official docs<\/strong> under OCI Compute.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Container Instances?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Container Instances in Oracle Cloud is intended to <strong>run container images as managed compute workloads<\/strong>\u2014without requiring you to manage the underlying servers and without requiring Kubernetes (unlike OCI Container Engine for Kubernetes).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it can do)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run a container image with defined CPU and memory resources.<\/li>\n<li>Attach the container runtime to an OCI <strong>VCN subnet<\/strong> (public or private), controlled by <strong>security lists<\/strong> and\/or <strong>network security groups (NSGs)<\/strong>.<\/li>\n<li>Pull images from container registries (commonly <strong>Oracle Cloud Infrastructure Registry (OCIR)<\/strong> or public registries).<\/li>\n<li>Provide operational lifecycle actions (create, start, stop\/terminate, update\/replace\u2014exact lifecycle actions can vary; <strong>verify in official docs<\/strong>).<\/li>\n<li>Integrate with OCI governance and operations primitives: <strong>compartments<\/strong>, <strong>tags<\/strong>, <strong>audit events<\/strong>, and typically <strong>metrics\/logging<\/strong> integration (details may vary by region and configuration; <strong>verify in official docs<\/strong>).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual model)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Container instance<\/strong>: The runtime resource in OCI that hosts your container workload.<\/li>\n<li><strong>Container image<\/strong>: The OCI\/Docker image reference (for example, <code>nginx:stable<\/code> or an OCIR URL).<\/li>\n<li><strong>Shape \/ resources<\/strong>: CPU (OCPUs) and memory (GB) allocated to the container workload.<\/li>\n<li><strong>Networking<\/strong>: A VNIC attached to your chosen VCN subnet; traffic governed by NSGs\/security lists and routing (IGW\/NAT\/Service Gateway).<\/li>\n<li><strong>Identity &amp; permissions<\/strong>: IAM policies controlling who can create\/manage container instances and access related resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed container runtime under <strong>Oracle Cloud Compute<\/strong>.<\/li>\n<li>Not Kubernetes (no cluster control plane to manage).<\/li>\n<li>Not \u201cfunctions\u201d (it\u2019s not a short-lived function runtime; containers can be long-running services).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional vs. others)<\/h3>\n\n\n\n<p>OCI resources generally live within:\n&#8211; A <strong>tenancy<\/strong> (your OCI account boundary)\n&#8211; A <strong>region<\/strong> (where you create the resource)\n&#8211; A <strong>compartment<\/strong> (logical grouping for IAM and billing)<\/p>\n\n\n\n<p>Container Instances is best thought of as a <strong>regional service<\/strong> where the runtime is created in a specific region and attached to networking resources (VCN\/subnets) in that region. Some networking constructs (like subnets) can be <strong>regional<\/strong> or <strong>availability-domain-specific<\/strong> depending on how you created them.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Oracle Cloud ecosystem<\/h3>\n\n\n\n<p>Container Instances sits between:\n&#8211; <strong>Compute instances<\/strong> (full VM control, more ops responsibility)\n&#8211; <strong>OKE (Kubernetes)<\/strong> (more features and orchestration, more platform responsibility)\n&#8211; <strong>OCI Functions<\/strong> (event-driven, short-lived serverless functions)<\/p>\n\n\n\n<p>It pairs naturally with:\n&#8211; <strong>VCN<\/strong> for network isolation and private connectivity\n&#8211; <strong>OCIR<\/strong> for enterprise image management\n&#8211; <strong>Load Balancer<\/strong> for stable ingress and HA patterns\n&#8211; <strong>Vault<\/strong> for secrets (usually consumed by your app at runtime)\n&#8211; <strong>Logging \/ Monitoring \/ Events \/ Notifications<\/strong> for operations (exact integration features: <strong>verify in official docs<\/strong>)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Container Instances?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time to deploy<\/strong>: Launch a container without building VM images or managing clusters.<\/li>\n<li><strong>Lower operational overhead<\/strong>: No patching\/maintenance of VM hosts by your team.<\/li>\n<li><strong>Pay-for-what-you-allocate<\/strong>: Resource-based allocation can be simpler to map to cost centers (pricing depends on region; see pricing section).<\/li>\n<li><strong>Standardization<\/strong>: Teams can ship a container image and run it consistently across dev\/test\/prod with the same workflow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VCN-native networking<\/strong>: Run containers inside your private network with OCI routing and security controls.<\/li>\n<li><strong>Predictable resource sizing<\/strong>: Allocate OCPUs and memory directly to the workload.<\/li>\n<li><strong>Registry-driven deployments<\/strong>: Use OCIR or other registries for controlled image distribution.<\/li>\n<li><strong>Good fit for single-service deployments<\/strong>: Great for microservices that don\u2019t need service mesh, advanced scheduling, or Kubernetes CRDs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Simpler than Kubernetes for small workloads<\/strong>: If you only need a handful of services, Kubernetes may be overkill.<\/li>\n<li><strong>Repeatable deployments<\/strong>: Container image + configuration defines the deployment artifact.<\/li>\n<li><strong>Clean lifecycle<\/strong>: Create\/replace patterns can reduce configuration drift compared to long-lived VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Network isolation<\/strong> with private subnets and NSGs.<\/li>\n<li><strong>IAM governance<\/strong> using compartments, policies, and tagging.<\/li>\n<li><strong>Auditability<\/strong> via OCI Audit for API calls and changes.<\/li>\n<li><strong>Controlled image sources<\/strong> by using OCIR and scanning policies (where available in your environment; <strong>verify in official docs<\/strong> for scanning capabilities and supported integrations).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale-out by creating more container instances<\/strong> behind a load balancer (manual or automated via external tooling).<\/li>\n<li><strong>Scale-up by allocating more OCPUs\/memory<\/strong> to a container instance.<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Note: Container Instances is not a full orchestrator. Autoscaling, rolling deployments, and service discovery typically require additional tooling or OKE.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Container Instances<\/h3>\n\n\n\n<p>Choose it when you need:\n&#8211; A small-to-medium number of containerized services\n&#8211; Deployment into a VCN with OCI-native networking\n&#8211; Less platform overhead than Kubernetes\n&#8211; A straightforward, cost-aware runtime model<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid it when you need:\n&#8211; Advanced orchestration (bin-packing, node pools, daemonsets, operators)\n&#8211; Highly dynamic autoscaling with complex policies (better served by OKE or other orchestrated platforms)\n&#8211; Complex multi-service deployments requiring tight coordination, service mesh, or Kubernetes-native constructs\n&#8211; Deep control over host OS\/kernel or specialized drivers (better served by Compute instances)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Container Instances used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software product companies (APIs, backend services)<\/li>\n<li>Financial services (internal services in private networks)<\/li>\n<li>Retail\/e-commerce (edge services, integration workers)<\/li>\n<li>Media &amp; gaming (stateless services, batch workers)<\/li>\n<li>Healthcare (data processors with strict network controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps and platform teams offering a \u201ccontainer runtime\u201d option<\/li>\n<li>Application teams migrating from VMs to containers<\/li>\n<li>SRE teams wanting simpler operational models for certain services<\/li>\n<li>Integration teams building connectors\/ETL workers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stateless HTTP services (internal or internet-facing behind a load balancer)<\/li>\n<li>Background workers \/ queue consumers<\/li>\n<li>Scheduled jobs (with an external scheduler triggering create\/run\/terminate workflows)<\/li>\n<li>Lightweight data processing services<\/li>\n<li>Internal tooling (webhooks, bots, automation endpoints)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices where each service can run as an independent container instance<\/li>\n<li>Hub-and-spoke VCNs where container instances run in application spokes<\/li>\n<li>Private service architectures with API Gateway\/Load Balancer fronting services<\/li>\n<li>Hybrid connectivity where container instances call on-prem via FastConnect or VPN<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: stable services with controlled rollout patterns (often using immutable deployments\u2014create new, switch traffic, delete old).<\/li>\n<li><strong>Dev\/test<\/strong>: rapid iteration, ephemeral environments, sandbox deployments.<\/li>\n<li><strong>Burst<\/strong>: temporary services for migrations, data backfills, or one-off processing (when cost and cleanup are well-controlled).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic, OCI-aligned scenarios where Container Instances is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Simple internal API in a private subnet<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need an internal REST API reachable only from within your VCN.<\/li>\n<li><strong>Why Container Instances fits<\/strong>: VCN-native private networking + simple container runtime.<\/li>\n<li><strong>Example<\/strong>: A finance team deploys an internal invoice-validation API in a private subnet, accessed by Oracle Integration or internal apps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Internet-facing web service behind OCI Load Balancer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Expose a web app reliably without managing VMs.<\/li>\n<li><strong>Why it fits<\/strong>: Create multiple container instances and register them as backends behind a public load balancer.<\/li>\n<li><strong>Example<\/strong>: A marketing site backend running in 2\u20133 container instances behind an OCI Load Balancer with TLS termination.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Background worker processing messages<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Consume tasks from a queue\/stream and process them continuously.<\/li>\n<li><strong>Why it fits<\/strong>: Long-running worker container with controlled CPU\/memory; private network access to databases.<\/li>\n<li><strong>Example<\/strong>: An order-processing worker reads from a queue and writes to Autonomous Database.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Lightweight ETL\/data transformation service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Transform files and move them between Object Storage buckets.<\/li>\n<li><strong>Why it fits<\/strong>: Containers are great for packaging ETL dependencies; VCN + Service Gateway patterns can keep traffic private.<\/li>\n<li><strong>Example<\/strong>: A nightly CSV-to-Parquet transformer container reading\/writing to OCI Object Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) On-demand \u201ctoolbox\u201d container for operations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Run operational tools in a controlled network zone.<\/li>\n<li><strong>Why it fits<\/strong>: Start a container with tooling, run tasks, then terminate.<\/li>\n<li><strong>Example<\/strong>: A security team runs a container instance to perform controlled vulnerability checks inside a VCN segment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) CI\/CD deployment target for containerized apps (non-Kubernetes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want CI\/CD to deploy containers without Kubernetes complexity.<\/li>\n<li><strong>Why it fits<\/strong>: CI\/CD can update container instances (often by replacing instances with a new image tag).<\/li>\n<li><strong>Example<\/strong>: A team uses OCI DevOps (or another CI tool) to publish images to OCIR and redeploy container instances.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Sidecar-style pairing (only if supported in your region)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want a log shipper\/proxy sidecar near your application container.<\/li>\n<li><strong>Why it fits<\/strong>: Some container-instance models support multiple containers sharing networking (verify support).<\/li>\n<li><strong>Example<\/strong>: App container + lightweight proxy container that forwards to a private upstream.<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p><strong>Verify in official docs<\/strong> whether your region\/service supports multi-container definitions and what networking\/storage semantics apply.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">8) Proof-of-concept for containerizing a VM app<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want to validate containerization without building platform scaffolding.<\/li>\n<li><strong>Why it fits<\/strong>: Run the container directly, validate behavior, then decide whether to move to OKE later.<\/li>\n<li><strong>Example<\/strong>: Containerize a legacy service and run it as a single container instance for performance and connectivity testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Webhook receiver \/ integration endpoint<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Receive webhooks and forward to internal systems.<\/li>\n<li><strong>Why it fits<\/strong>: Low overhead runtime, can be internet-facing with strict network controls.<\/li>\n<li><strong>Example<\/strong>: Git webhooks hit a container instance that validates payloads and triggers internal workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Regional microservice deployed close to OCI databases<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Reduce latency and keep traffic within the region.<\/li>\n<li><strong>Why it fits<\/strong>: Run containers in the same OCI region\/VCN as Autonomous Database or other OCI services.<\/li>\n<li><strong>Example<\/strong>: A service hosted in OCI Ashburn calls an Autonomous Database in the same region over private endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Canary testing environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Safely test a new container image version in production-like networking.<\/li>\n<li><strong>Why it fits<\/strong>: Create a parallel container instance using a new image tag and route a small percentage of traffic.<\/li>\n<li><strong>Example<\/strong>: Two backend sets behind an OCI Load Balancer; weighted routing handled externally (implementation varies).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Batch-like job runner with external scheduler<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Run periodic compute jobs without maintaining servers.<\/li>\n<li><strong>Why it fits<\/strong>: A scheduler can create a container instance, wait for completion, and then terminate it.<\/li>\n<li><strong>Example<\/strong>: A daily reconciliation job container is launched by an automation script and terminated after completion.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability and exact configuration options can vary by region and over time. For any feature you plan to depend on, <strong>verify in official docs<\/strong> for your region.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Managed container runtime (no VM management)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: OCI runs the container workload for you without you managing the host.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces patching, base image maintenance, and infrastructure ops overhead.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster deployments and simpler runbooks.<\/li>\n<li><strong>Caveat<\/strong>: Less low-level control compared to VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Resource sizing with OCPUs and memory<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allocate CPU and memory to the container instance.<\/li>\n<li><strong>Why it matters<\/strong>: Predictable performance and cost.<\/li>\n<li><strong>Practical benefit<\/strong>: Right-size by environment (dev small, prod larger).<\/li>\n<li><strong>Caveat<\/strong>: If your workload needs GPU or special hardware, <strong>verify<\/strong> whether Container Instances supports it (often it does not).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) VCN subnet attachment (private or public)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Places the container instance in your OCI network.<\/li>\n<li><strong>Why it matters<\/strong>: Enterprise network control (routing, segmentation, private connectivity).<\/li>\n<li><strong>Practical benefit<\/strong>: Access private databases and services without exposing them publicly.<\/li>\n<li><strong>Caveat<\/strong>: Misconfigured security lists\/NSGs are a common cause of \u201cit\u2019s not reachable.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Integration with OCI IAM (compartments and policies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls who can create\/manage container instances and related resources.<\/li>\n<li><strong>Why it matters<\/strong>: Least privilege and separation of duties.<\/li>\n<li><strong>Practical benefit<\/strong>: Platform team can manage runtime; app teams can deploy into designated compartments.<\/li>\n<li><strong>Caveat<\/strong>: IAM policy verbs\/resource-types must match current OCI documentation (<strong>verify<\/strong> exact policy syntax).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Container images from registries (OCIR and others)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Runs images from supported registries.<\/li>\n<li><strong>Why it matters<\/strong>: Enables standard container supply chain.<\/li>\n<li><strong>Practical benefit<\/strong>: Use OCIR for private images and governance.<\/li>\n<li><strong>Caveat<\/strong>: Private registry access requires credentials or IAM-based mechanisms; implementation details vary\u2014<strong>verify<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Environment variables and runtime configuration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Configure the container at runtime (env vars, command\/entrypoint overrides depending on options available).<\/li>\n<li><strong>Why it matters<\/strong>: Supports twelve-factor style configuration.<\/li>\n<li><strong>Practical benefit<\/strong>: Same image across environments; environment-specific config via variables.<\/li>\n<li><strong>Caveat<\/strong>: Don\u2019t store secrets in plain environment variables unless you accept that risk; prefer a secrets manager pattern.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Networking controls via NSGs \/ security lists<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Fine-grained ingress\/egress rules.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces attack surface.<\/li>\n<li><strong>Practical benefit<\/strong>: Allow only required ports from known sources.<\/li>\n<li><strong>Caveat<\/strong>: Opening <code>0.0.0.0\/0<\/code> to admin ports is a frequent security mistake.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Operational visibility (status, lifecycle, logs\/metrics)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides container instance state and (in many cases) integrates with OCI observability services.<\/li>\n<li><strong>Why it matters<\/strong>: You need to troubleshoot deployments quickly.<\/li>\n<li><strong>Practical benefit<\/strong>: Identify crash loops, image pull failures, network issues.<\/li>\n<li><strong>Caveat<\/strong>: The exact log collection method (stdout\/stderr capture, OCI Logging integration) should be confirmed in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Tagging and governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports freeform and defined tags (OCI standard).<\/li>\n<li><strong>Why it matters<\/strong>: Cost allocation, ownership, environment classification.<\/li>\n<li><strong>Practical benefit<\/strong>: Enforce \u201cOwner\u201d, \u201cCostCenter\u201d, \u201cEnvironment\u201d tags for all container instances.<\/li>\n<li><strong>Caveat<\/strong>: Governance works only if enforced with policies and processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Suitable for immutable deployment patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Encourages \u201creplace rather than modify in place\u201d deployments.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces drift; easier rollbacks.<\/li>\n<li><strong>Practical benefit<\/strong>: Deploy <code>myapp:1.2.3<\/code>, validate, switch traffic, delete old instances.<\/li>\n<li><strong>Caveat<\/strong>: Requires an external deployment controller (CI\/CD pipeline or scripts) for smooth rollouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Works with OCI Load Balancer (common pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: You can place multiple container instances behind a load balancer.<\/li>\n<li><strong>Why it matters<\/strong>: Stable endpoint, TLS termination, health checks.<\/li>\n<li><strong>Practical benefit<\/strong>: High availability and controlled exposure to the internet.<\/li>\n<li><strong>Caveat<\/strong>: Health check endpoints and backend registration must match your app\u2019s listening port.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Private access to OCI services via Service Gateway (pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows private connectivity patterns from subnets to OCI services (depending on your network setup).<\/li>\n<li><strong>Why it matters<\/strong>: Keep traffic off the public internet.<\/li>\n<li><strong>Practical benefit<\/strong>: Access Object Storage privately from private subnets.<\/li>\n<li><strong>Caveat<\/strong>: Network path must be configured correctly (route tables + gateway + security rules). Service Gateway is VCN-level; support is not \u201cautomatic.\u201d<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>At a high level:\n1. You define a container instance specification: image, resources (OCPU\/memory), and networking.\n2. OCI provisions a managed runtime environment and attaches it to your subnet via a VNIC.\n3. The runtime pulls the image from a registry and starts the container.\n4. Network traffic flows based on your VCN routing and security rules.\n5. Operations signals (lifecycle status, audit events, and optionally logs\/metrics) are available through OCI services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>:<\/li>\n<li>You (or CI\/CD) call OCI APIs (Console\/CLI\/SDK) to create\/update\/terminate.<\/li>\n<li>OCI IAM authorizes the action based on policies in the compartment.<\/li>\n<li>OCI records actions in <strong>Audit<\/strong>.<\/li>\n<li><strong>Data plane<\/strong>:<\/li>\n<li>Inbound traffic reaches the container instance via:<ul>\n<li>A public IP (if used), or<\/li>\n<li>OCI Load Balancer, API Gateway, or internal callers in the VCN.<\/li>\n<\/ul>\n<\/li>\n<li>Outbound traffic leaves via:<ul>\n<li>NAT Gateway (private subnet to internet),<\/li>\n<li>Internet Gateway (public subnet), or<\/li>\n<li>Service Gateway (private access to OCI services), depending on your routing.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related OCI services<\/h3>\n\n\n\n<p>Common integrations\/patterns include:\n&#8211; <strong>VCN<\/strong>: subnet placement, NSGs, routing (IGW\/NAT\/Service Gateway)\n&#8211; <strong>OCIR<\/strong>: private image registry for enterprise supply chain\n&#8211; <strong>Load Balancer<\/strong>: stable ingress, health checks, TLS\n&#8211; <strong>Vault<\/strong>: application secrets fetched at runtime\n&#8211; <strong>Logging \/ Monitoring<\/strong>: operational telemetry (verify exact support and setup)\n&#8211; <strong>Events \/ Notifications<\/strong>: respond to lifecycle changes (verify event types)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Container Instances relies on:\n&#8211; OCI IAM for authorization\n&#8211; OCI networking constructs (VCN, subnet, security rules)\n&#8211; A reachable container registry (OCIR or external registry)\n&#8211; Optional: logging\/monitoring services for deeper operations<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>User\/service identity actions are controlled by <strong>OCI IAM policies<\/strong>.<\/li>\n<li>Image pulls may require registry authentication (for private registries).<\/li>\n<li>Network access is controlled by VCN security lists\/NSGs and routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Container Instances attach to a <strong>subnet<\/strong> and receive an IP address.<\/li>\n<li>Inbound reachability depends on:<\/li>\n<li>public vs private subnet<\/li>\n<li>public IP assignment (if supported\/configured)<\/li>\n<li>security rules allowing inbound ports<\/li>\n<li>route tables and gateways<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>compartments<\/strong> for environment separation (dev\/test\/prod).<\/li>\n<li>Use <strong>tags<\/strong> for cost allocation and ownership.<\/li>\n<li>Use <strong>Audit<\/strong> logs as your baseline change log.<\/li>\n<li>Plan for:<\/li>\n<li>application logs (stdout\/stderr and\/or direct logging to OCI Logging)<\/li>\n<li>metrics (app-level and platform-level)<\/li>\n<li>health checks (especially if behind a load balancer)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Client] --&gt;|HTTP| CI[Container Instances]\n  CI --&gt; VCN[VCN Subnet]\n  CI --&gt;|Pull image| REG[Container Registry\\n(OCIR or Public)]\n  CI --&gt; DB[(Database in VCN)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  Internet((Internet)) --&gt; WAF[OCI WAF\\n(optional)]\n  WAF --&gt; LB[OCI Load Balancer\\nPublic]\n  subgraph VCN[VCN]\n    subgraph Pub[Public Subnet]\n      LB\n    end\n    subgraph Priv[Private Subnet]\n      CI1[Container Instance A]\n      CI2[Container Instance B]\n      DB[(Private Database)]\n      Cache[(Cache\/Queue)]\n    end\n    LB --&gt;|Backends| CI1\n    LB --&gt;|Backends| CI2\n    CI1 --&gt; DB\n    CI2 --&gt; DB\n    CI1 --&gt; Cache\n    CI2 --&gt; Cache\n    CI1 --&gt;|Egress| NAT[NAT Gateway]\n    CI2 --&gt;|Egress| NAT\n    CI1 --&gt;|Private OCI access| SG[Service Gateway]\n    CI2 --&gt;|Private OCI access| SG\n  end\n\n  CI1 --&gt; LOG[OCI Logging]\n  CI2 --&gt; LOG\n  CI1 --&gt; MON[OCI Monitoring]\n  CI2 --&gt; MON\n  CI1 --&gt; VAULT[OCI Vault\\n(secrets at runtime)]\n  CI2 --&gt; VAULT\n  SG --&gt; OBJ[OCI Object Storage]\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/tenancy requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Oracle Cloud<\/strong> tenancy.<\/li>\n<li>Access to a region where <strong>Container Instances<\/strong> is available. Availability can vary by region; <strong>verify in official docs<\/strong> and the OCI Console service list.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM policies<\/h3>\n\n\n\n<p>You need permission to:\n&#8211; Manage container instances in the target compartment\n&#8211; Use networking resources (VCN\/subnets\/NSGs)\n&#8211; (Optional) Use OCIR repositories\/images<\/p>\n\n\n\n<p>OCI IAM policies are explicit and compartment-scoped. Policy syntax changes over time, so use OCI docs to confirm. Typical patterns look like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allow a group to manage container instances:<\/li>\n<li>\n<p><code>Allow group &lt;group-name&gt; to manage container-instances-family in compartment &lt;compartment-name&gt;<\/code><\/p>\n<\/li>\n<li>\n<p>Allow a group to use networking:<\/p>\n<\/li>\n<li><code>Allow group &lt;group-name&gt; to use virtual-network-family in compartment &lt;compartment-name&gt;<\/code><\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p><strong>Verify in official docs<\/strong> the exact resource family names (<code>container-instances-family<\/code>) and whether you need <code>manage<\/code> vs <code>use<\/code> for your tasks.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A paid tenancy or credits. Container Instances is a paid service based on resource usage.<\/li>\n<li>Free Tier applicability can change; <strong>verify on Oracle Cloud Free Tier pages<\/strong> and the Container Instances pricing page.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools (optional but recommended)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI Console access (web UI)<\/li>\n<li>OCI CLI (optional)<\/li>\n<li>Official CLI docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/Concepts\/cliconcepts.htm<\/li>\n<li>Docker (optional, if you build\/push images)<\/li>\n<li><code>curl<\/code> for validation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Container Instances may not be enabled in every OCI region. <strong>Verify in official docs<\/strong> and the OCI Console for your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service limits for:<\/li>\n<li>number of container instances<\/li>\n<li>total OCPU\/memory allocation<\/li>\n<li>networking limits (VNICs, subnets, NSG rules)<\/li>\n<li>Check and request increases in <strong>OCI Console \u2192 Governance &amp; Administration \u2192 Limits, Quotas and Usage<\/strong> (naming may vary).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the hands-on lab:\n&#8211; A <strong>VCN<\/strong> with at least one <strong>public subnet<\/strong>\n&#8211; An <strong>Internet Gateway<\/strong> and route rule (for public access)\n&#8211; Security rules allowing inbound HTTP on a chosen port (80 or 8080)<\/p>\n\n\n\n<p>Optional for production-like setups:\n&#8211; OCI Load Balancer\n&#8211; NAT Gateway + private subnet\n&#8211; OCIR repository\n&#8211; Logging and Monitoring setup\n&#8211; Vault for secrets<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<blockquote>\n<p>Pricing varies by region and may change. Use official sources to confirm current SKUs and rates.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how you\u2019re charged)<\/h3>\n\n\n\n<p>Container Instances pricing is typically based on the resources allocated to the container runtime, most commonly:\n&#8211; <strong>OCPU-hours<\/strong> (or OCPU-seconds\/minutes depending on metering granularity)\n&#8211; <strong>Memory GB-hours<\/strong><\/p>\n\n\n\n<p>Additionally, you may incur charges for:\n&#8211; <strong>Outbound data transfer<\/strong> (internet egress)\n&#8211; <strong>Load Balancer<\/strong> (if used)\n&#8211; <strong>Logging<\/strong> ingestion\/storage (if used)\n&#8211; <strong>Registry storage<\/strong> (OCIR storage and requests)\n&#8211; <strong>Public IP \/ networking services<\/strong> depending on OCI policies and architecture\n&#8211; Any backend services your container uses (databases, Object Storage, streaming, etc.)<\/p>\n\n\n\n<p>Because OCI pricing pages can be updated and are region-specific, do not rely on static numbers in articles. Instead, confirm with:\n&#8211; OCI pricing overview: https:\/\/www.oracle.com\/cloud\/pricing\/\n&#8211; OCI price list: https:\/\/www.oracle.com\/cloud\/price-list\/\n&#8211; OCI cost estimator: https:\/\/www.oracle.com\/cloud\/costestimator.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to track<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Dimension<\/th>\n<th>What it means<\/th>\n<th>Typical driver<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>OCPU allocation<\/td>\n<td>CPU reserved\/allocated for the container instance<\/td>\n<td>Higher concurrency, CPU-heavy workloads<\/td>\n<\/tr>\n<tr>\n<td>Memory allocation<\/td>\n<td>RAM allocated for the workload<\/td>\n<td>JVM apps, caches, in-memory processing<\/td>\n<\/tr>\n<tr>\n<td>Running time<\/td>\n<td>How long instances are running<\/td>\n<td>Always-on services vs. ephemeral jobs<\/td>\n<\/tr>\n<tr>\n<td>Network egress<\/td>\n<td>Data leaving OCI to the internet<\/td>\n<td>APIs serving large responses, file downloads<\/td>\n<\/tr>\n<tr>\n<td>Registry storage\/requests<\/td>\n<td>Image storage and pulls<\/td>\n<td>Many deployments, large image layers<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Logging\/metrics ingestion &amp; retention<\/td>\n<td>High log volume, long retention<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Free Tier considerations<\/h3>\n\n\n\n<p>OCI has a Free Tier program, but inclusion of Container Instances in Free Tier is not guaranteed and can change. <strong>Verify<\/strong>:\n&#8211; Oracle Cloud Free Tier: https:\/\/www.oracle.com\/cloud\/free\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (direct and indirect)<\/h3>\n\n\n\n<p>Direct:\n&#8211; OCPU and memory allocation \u00d7 runtime duration<\/p>\n\n\n\n<p>Indirect:\n&#8211; Bigger image sizes increase pull time and can affect deployment speed (not always billed directly, but impacts operations)\n&#8211; Excessive logging volume\n&#8211; Load balancer cost (often significant vs. small workloads)\n&#8211; Network architecture choices (public subnet vs private + NAT, service gateway usage)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inbound traffic is typically not the primary cost driver.<\/li>\n<li>Outbound internet egress can be material.<\/li>\n<li>Keeping traffic within OCI region\/VCN (private endpoints, service gateway) can reduce egress and improve security.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size CPU\/memory; avoid \u201cjust in case\u201d allocations.<\/li>\n<li>Use smaller base images (distroless\/alpine where appropriate).<\/li>\n<li>Use private subnets + load balancer only when needed; otherwise, keep architecture simple.<\/li>\n<li>Control log verbosity and retention.<\/li>\n<li>Prefer immutable deployments but keep image pull frequency reasonable (pin tags for production).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal lab deployment typically uses:\n&#8211; 1 small container instance (lowest OCPU\/memory offered in your region)\n&#8211; Running for less than an hour\n&#8211; Public subnet access\n&#8211; Public Docker Hub image (no OCIR storage cost)<\/p>\n\n\n\n<p>To estimate:\n1. Find your region\u2019s Container Instances OCPU and memory rates in the OCI price list.\n2. Multiply by the runtime hours for the lab.\n3. Add potential egress (usually negligible for a simple <code>curl<\/code> test).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, costs often come more from the surrounding architecture than the container runtime itself:\n&#8211; Multiple container instances across fault domains (or spread strategy) for HA\n&#8211; OCI Load Balancer (hourly + bandwidth)\n&#8211; Logging ingestion and retention\n&#8211; NAT Gateway traffic (if private subnets need internet egress)\n&#8211; OCIR storage and CI\/CD image pulls<\/p>\n\n\n\n<p>Use the <strong>OCI Cost Estimator<\/strong> to model:\n&#8211; baseline steady-state (normal traffic)\n&#8211; peak (scale-out)\n&#8211; failover (extra capacity)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab deploys a real, minimal web container to <strong>Oracle Cloud Container Instances<\/strong> in a public subnet and validates it with a browser\/curl. It is designed to be low-cost and beginner-friendly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy an NGINX container using <strong>Container Instances<\/strong> in Oracle Cloud, expose it via a public IP, validate HTTP connectivity, and then clean up all resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a compartment (optional) for the lab.\n2. Create a VCN with a public subnet using the VCN wizard.\n3. Configure inbound security for HTTP.\n4. Create a Container Instance using a public container image (<code>nginx:stable<\/code>).\n5. Validate access to the NGINX welcome page.\n6. Troubleshoot common issues.\n7. Clean up resources to stop billing.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create (or choose) a compartment<\/h3>\n\n\n\n<p><strong>Why<\/strong>: Compartments are the primary OCI boundary for IAM and cost tracking.<\/p>\n\n\n\n<p><strong>Console steps<\/strong>\n1. Open the OCI Console: https:\/\/cloud.oracle.com\/\n2. Go to <strong>Identity &amp; Security \u2192 Compartments<\/strong>\n3. Click <strong>Create Compartment<\/strong>\n4. Name: <code>ci-lab<\/code> (or similar)\n5. Description: <code>Container Instances lab<\/code>\n6. Click <strong>Create Compartment<\/strong><\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A compartment exists where you will create all lab resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a VCN with a public subnet (VCN wizard)<\/h3>\n\n\n\n<p><strong>Why<\/strong>: Container Instances must attach to a subnet in a VCN.<\/p>\n\n\n\n<p><strong>Console steps<\/strong>\n1. Go to <strong>Networking \u2192 Virtual Cloud Networks<\/strong>\n2. Ensure the <strong>ci-lab<\/strong> compartment is selected (left-side compartment selector)\n3. Click <strong>Start VCN Wizard<\/strong>\n4. Choose <strong>VCN with Internet Connectivity<\/strong>\n5. Provide a name, for example: <code>ci-lab-vcn<\/code>\n6. Accept defaults unless your org has required CIDR ranges.\n7. Click <strong>Create<\/strong><\/p>\n\n\n\n<p>This wizard typically creates:\n&#8211; 1 VCN\n&#8211; 1 public subnet\n&#8211; 1 internet gateway (IGW)\n&#8211; route table pointing <code>0.0.0.0\/0<\/code> to IGW\n&#8211; security lists with baseline rules (you\u2019ll add HTTP ingress next)<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have a VCN and a public subnet suitable for internet-facing testing.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Open inbound HTTP on the public subnet<\/h3>\n\n\n\n<p><strong>Why<\/strong>: Your NGINX container must be reachable over HTTP.<\/p>\n\n\n\n<p>You can do this with either:\n&#8211; <strong>Security List<\/strong> rules on the subnet, or\n&#8211; <strong>Network Security Group (NSG)<\/strong> attached to the container instance<\/p>\n\n\n\n<p>For a beginner lab, using the subnet <strong>Security List<\/strong> is simplest.<\/p>\n\n\n\n<p><strong>Console steps (Security List approach)<\/strong>\n1. Go to <strong>Networking \u2192 Virtual Cloud Networks \u2192 ci-lab-vcn<\/strong>\n2. Click <strong>Subnets<\/strong>, then click the <strong>public subnet<\/strong> created by the wizard\n3. Find the <strong>Security Lists<\/strong> associated with the subnet and open it\n4. Under <strong>Ingress Rules<\/strong>, click <strong>Add Ingress Rules<\/strong>\n5. Add:\n   &#8211; Source CIDR: <code>0.0.0.0\/0<\/code>\n   &#8211; IP Protocol: TCP\n   &#8211; Destination Port Range: <code>80<\/code>\n   &#8211; Description: <code>Allow HTTP for NGINX lab<\/code>\n6. Save<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; TCP\/80 inbound is allowed to resources in that subnet (subject to other rules and routing).<\/p>\n\n\n\n<p><strong>Security note<\/strong>\nThis rule is intentionally open for a lab. For production, restrict source CIDRs and prefer a load balancer + WAF, and\/or use NSGs for tighter scope.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Container Instance running NGINX<\/h3>\n\n\n\n<p><strong>Why<\/strong>: This is the core deployment.<\/p>\n\n\n\n<p><strong>Console steps<\/strong>\n1. Go to <strong>Compute \u2192 Container Instances<\/strong> (service location may appear under Compute)\n2. Select the <strong>ci-lab<\/strong> compartment\n3. Click <strong>Create container instance<\/strong>\n4. Configure basics:\n   &#8211; Name: <code>nginx-ci-lab<\/code>\n   &#8211; Image: <code>nginx:stable<\/code> (public image from Docker Hub)\n5. Configure shape\/resources:\n   &#8211; Choose the smallest OCPU\/memory that meets the minimum allowed in your region.\n6. Configure networking:\n   &#8211; VCN: <code>ci-lab-vcn<\/code>\n   &#8211; Subnet: the public subnet created earlier\n   &#8211; Public IP: <strong>Assign<\/strong> (wording may vary)\n7. Set the container port behavior:\n   &#8211; NGINX listens on port <code>80<\/code> by default.\n   &#8211; If asked for \u201clistening port\u201d or similar, set it to <code>80<\/code> (if such a setting exists in your console flow).\n8. Create the resource.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The container instance enters a provisioning state.\n&#8211; After a few minutes, it should reach a <strong>Running<\/strong> state (naming may vary).\n&#8211; The details page should show an IP address (private and\/or public).<\/p>\n\n\n\n<blockquote>\n<p>If the console offers optional log settings, keep defaults for the lab. For production, you should intentionally configure log collection and retention.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Validate from your laptop (HTTP test)<\/h3>\n\n\n\n<p><strong>Why<\/strong>: Confirm that networking + container startup is correct.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Copy the <strong>public IP address<\/strong> of the container instance.<\/li>\n<li>From your terminal:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">curl -i http:\/\/&lt;PUBLIC_IP&gt;\/\n<\/code><\/pre>\n\n\n\n<p>Or open in a browser:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>http:\/\/&lt;PUBLIC_IP&gt;\/<\/code><\/li>\n<\/ul>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You receive an HTTP 200 response and the NGINX welcome page HTML.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6 (Optional): Use your own image in OCIR<\/h3>\n\n\n\n<p>This is optional because private registry authentication details can vary by org policy, IAM setup, and OCI feature updates.<\/p>\n\n\n\n<p>High-level flow:\n1. Create an OCIR repository.\n2. Create an auth token for your user (or use an approved automation mechanism).\n3. <code>docker login<\/code> to OCIR.\n4. Build and push the image.\n5. Update the container instance to use the OCIR image (often by replacing\/recreating).<\/p>\n\n\n\n<p>Official entry points to verify current OCIR workflow:\n&#8211; OCIR docs entry (navigate via OCI docs home): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/home.htm (search \u201cContainer Registry OCIR\u201d)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Container Instance state<\/strong>: Running<\/li>\n<li><strong>Public IP present<\/strong>: Yes<\/li>\n<li><strong>VCN routing<\/strong>: Public subnet route table has <code>0.0.0.0\/0 \u2192 Internet Gateway<\/code><\/li>\n<li><strong>Security<\/strong>: Ingress rule allows TCP\/80<\/li>\n<li><strong>App<\/strong>: <code>curl http:\/\/&lt;public-ip&gt;<\/code> returns NGINX page<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: <code>curl<\/code> times out<\/h4>\n\n\n\n<p>Likely causes and fixes:\n1. <strong>Ingress rule missing<\/strong>\n   &#8211; Ensure TCP\/80 is allowed in the subnet\u2019s security list or NSG attached to the container instance.\n2. <strong>No public IP<\/strong>\n   &#8211; Confirm the container instance has a public IP assigned and is in a public subnet.\n3. <strong>Route table not pointing to IGW<\/strong>\n   &#8211; Ensure the subnet route table has <code>0.0.0.0\/0<\/code> to the Internet Gateway.\n4. <strong>Corporate firewall restrictions<\/strong>\n   &#8211; Some networks block outbound HTTP to random IPs. Try from another network.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Container instance stuck in provisioning<\/h4>\n\n\n\n<p>Possible causes:\n&#8211; Quota\/service limit reached (OCPU, container instance count)\n&#8211; Regional capacity constraints\n&#8211; Image pull failure (registry unreachable, image name typo)<\/p>\n\n\n\n<p>Fix:\n&#8211; Check the instance details for error messages.\n&#8211; Check <strong>Limits, Quotas and Usage<\/strong> in OCI governance.\n&#8211; Try a different image tag like <code>nginx:latest<\/code> (not recommended for prod, but useful for troubleshooting).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Container is running but returns connection refused<\/h4>\n\n\n\n<p>Possible causes:\n&#8211; App listens on a different port than you opened\n&#8211; NGINX misconfiguration (unlikely with default image)<\/p>\n\n\n\n<p>Fix:\n&#8211; Confirm the container image and its exposed\/listening port.\n&#8211; Confirm security rule port matches the app port.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete resources in reverse order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Terminate\/Delete the container instance<\/strong>\n   &#8211; Compute \u2192 Container Instances \u2192 <code>nginx-ci-lab<\/code> \u2192 Terminate\/Delete<\/li>\n<li><strong>Remove security list rule<\/strong> (optional if deleting the VCN)<\/li>\n<li><strong>Delete the VCN<\/strong>\n   &#8211; Networking \u2192 VCNs \u2192 <code>ci-lab-vcn<\/code> \u2192 Terminate\/Delete\n   &#8211; The wizard-created resources (IGW, subnet, route table) are deleted as part of VCN deletion in many cases; confirm dependencies in the console.<\/li>\n<li><strong>Delete the compartment<\/strong> (optional)\n   &#8211; Only if you created it solely for the lab and it\u2019s empty.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; No running container instances; networking resources removed; billing stops for those components.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>private subnets<\/strong> for app containers; expose via <strong>Load Balancer<\/strong> (and optionally WAF) rather than giving every container a public IP.<\/li>\n<li>Use <strong>immutable deployments<\/strong>:<\/li>\n<li>Build and tag images (e.g., <code>myapp:1.4.2<\/code>)<\/li>\n<li>Deploy new container instances with the new tag<\/li>\n<li>Switch traffic (LB backend set update)<\/li>\n<li>Remove old instances after validation<\/li>\n<li>Design for statelessness:<\/li>\n<li>Store state in managed services (Autonomous Database, Object Storage, Streaming, etc.)<\/li>\n<li>Avoid writing critical data to local ephemeral storage<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong> policies:<\/li>\n<li>App deployers can manage container instances only in their compartment.<\/li>\n<li>Networking changes restricted to platform\/network team.<\/li>\n<li>Use separate compartments for <strong>dev\/test\/prod<\/strong>.<\/li>\n<li>Enforce tagging via governance practices to capture ownership and environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size CPU\/memory; measure and adjust.<\/li>\n<li>Keep images small to reduce pull time and operational friction.<\/li>\n<li>Avoid always-on public load balancers for tiny dev workloads if not needed (LB cost can dominate).<\/li>\n<li>Control log volume and retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use health endpoints and avoid long cold starts in container entrypoints.<\/li>\n<li>Ensure your container listens on the expected port and binds to <code>0.0.0.0<\/code> (not <code>127.0.0.1<\/code>).<\/li>\n<li>Use connection pooling for DB access (and tune based on OCPU\/memory).<\/li>\n<li>Place services in the same region\/VCN where possible to reduce latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run at least two instances for critical services and place them in a resilient topology (exact placement controls depend on OCI capabilities; <strong>verify<\/strong>).<\/li>\n<li>Use load balancer health checks and graceful shutdown handling.<\/li>\n<li>Implement retries with backoff for downstream calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>image tagging (semantic versions + git SHA)<\/li>\n<li>deployment pipeline stages<\/li>\n<li>logging format (structured logs)<\/li>\n<li>Monitor:<\/li>\n<li>request rate, latency, error rate<\/li>\n<li>container restarts<\/li>\n<li>resource utilization (CPU\/memory)<\/li>\n<li>Create runbooks:<\/li>\n<li>image pull errors<\/li>\n<li>network reachability checks<\/li>\n<li>rollback steps (deploy previous image tag)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming convention example:<\/li>\n<li><code>ci-&lt;app&gt;-&lt;env&gt;-&lt;region&gt;<\/code> \u2192 <code>ci-payments-prod-ashburn<\/code><\/li>\n<li>Tagging:<\/li>\n<li><code>Owner<\/code>, <code>CostCenter<\/code>, <code>Environment<\/code>, <code>DataClassification<\/code><\/li>\n<li>Document and enforce which images are allowed (approved registries and base images).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI IAM controls management operations (create\/update\/terminate).<\/li>\n<li>Use:<\/li>\n<li>compartments to isolate environments and teams<\/li>\n<li>groups and policies for least privilege<\/li>\n<li>Consider separation of duties:<\/li>\n<li>Network team: VCN\/subnet\/NSG management<\/li>\n<li>Platform team: service-level controls and guardrails<\/li>\n<li>App team: deploy\/manage container instances within defined boundaries<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit: use TLS (typically terminated at OCI Load Balancer or within your application).<\/li>\n<li>Data at rest: depends on services used (Object Storage, databases, Vault). Container local storage characteristics and encryption details should be confirmed in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid public IPs for production containers when possible.<\/li>\n<li>Prefer inbound via:<\/li>\n<li>Load Balancer (TLS, health checks)<\/li>\n<li>WAF for internet-facing endpoints<\/li>\n<li>Use NSGs to scope rules to only required sources\/destinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<p>Common secure patterns:\n&#8211; Store secrets in <strong>OCI Vault<\/strong>, fetch at runtime using an authenticated method appropriate to your environment.\n&#8211; Rotate credentials regularly.\n&#8211; Avoid embedding secrets in:\n  &#8211; container image layers\n  &#8211; build logs\n  &#8211; plain environment variables in long-lived configs (unless your risk acceptance allows it)<\/p>\n\n\n\n<blockquote>\n<p>Exact \u201cnative secret injection\u201d capabilities, if any, should be <strong>verified in official docs<\/strong> for Container Instances.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>OCI Audit<\/strong> for change tracking.<\/li>\n<li>Ensure application logs are:<\/li>\n<li>captured<\/li>\n<li>protected from tampering<\/li>\n<li>retained per compliance requirements<\/li>\n<li>Ensure sensitive data is not logged (PII\/PHI).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use compartments, tags, and policies to map workloads to compliance zones.<\/li>\n<li>Keep images scanned and patched (use your org\u2019s image scanning pipeline).<\/li>\n<li>Define allowed registries and base images.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Running containers with public IPs and overly permissive security rules<\/li>\n<li>Allowing <code>0.0.0.0\/0<\/code> to admin endpoints<\/li>\n<li>Storing secrets in images or source control<\/li>\n<li>Using <code>latest<\/code> tags in production (non-reproducible deployments)<\/li>\n<li>Lack of egress controls (containers can exfiltrate data if compromised)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Put containers in private subnets; use LB + WAF for ingress.<\/li>\n<li>Minimize open ports; implement strict NSG rules.<\/li>\n<li>Use immutable image tags and SBOM\/vulnerability scanning in CI.<\/li>\n<li>Use Vault for secrets; rotate and audit access.<\/li>\n<li>Implement application-layer authn\/authz and rate limiting.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>OCI services evolve. Treat this section as a checklist and <strong>verify in official docs<\/strong> for your region and current feature set.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Common limitations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not a full orchestrator<\/strong>: You don\u2019t automatically get Kubernetes-style scheduling, autoscaling, service discovery, or rolling updates.<\/li>\n<li><strong>Scaling is manual or externalized<\/strong>: Typically you scale by creating more container instances (via scripts\/CI\/CD\/automation) and putting them behind a load balancer.<\/li>\n<li><strong>Stateful workloads are harder<\/strong>: Persistent storage patterns may be limited compared to Kubernetes volumes; verify supported mounts\/integrations.<\/li>\n<li><strong>Feature parity varies<\/strong>: Logging\/metrics integrations and container spec options can differ over time and by region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Max number of container instances per compartment\/region<\/li>\n<li>Max OCPU\/memory allocations<\/li>\n<li>VCN limits (NSG rules, subnet sizes, IP availability)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service availability can vary by OCI region.<\/li>\n<li>Some advanced features may roll out gradually.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Load balancer costs can exceed small container runtime costs.<\/li>\n<li>NAT Gateway traffic in private subnet designs can add costs.<\/li>\n<li>Logging ingestion\/retention can grow quickly with verbose apps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Image architecture: ensure your image matches the platform architecture supported (commonly x86_64; ARM support should be verified).<\/li>\n<li>Containers that require privileged access or special kernel modules may not work (verify support boundaries).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Binding to localhost (<code>127.0.0.1<\/code>) makes your app unreachable from the network\u2014bind to <code>0.0.0.0<\/code>.<\/li>\n<li>Security list vs NSG confusion: rules might be applied in a different place than you expect.<\/li>\n<li>Using <code>latest<\/code> tags causes non-repeatable rollouts and painful incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from Kubernetes: you may need to replace Kubernetes features (config maps, secrets, ingress) with OCI-native or application-level equivalents.<\/li>\n<li>Moving from VMs: ensure your app is truly stateless or externalize state.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI\u2019s IAM and compartment model is powerful but strict\u2014policy mistakes can block deployments.<\/li>\n<li>OCI networking defaults (route tables, security lists) can be less \u201cauto-open\u201d than some developers expect.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in Oracle Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Container Engine for Kubernetes (OKE)<\/strong>: full Kubernetes platform for orchestrated container workloads.<\/li>\n<li><strong>Compute Instances<\/strong>: run Docker yourself on VMs; maximum control, more ops.<\/li>\n<li><strong>OCI Functions<\/strong>: serverless functions for event-driven short tasks (limits and runtime model differ).<\/li>\n<li><strong>OCI DevOps<\/strong> (adjacent): CI\/CD pipelines, not a runtime, but commonly used to deploy to Container Instances or OKE.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS ECS on Fargate<\/strong><\/li>\n<li><strong>Azure Container Instances (ACI)<\/strong><\/li>\n<li><strong>Google Cloud Run<\/strong> (serverless containers, different model) and <strong>GKE Autopilot<\/strong> (managed Kubernetes)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source\/self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes on VMs (self-managed)<\/li>\n<li>Nomad on VMs<\/li>\n<li>Docker on VMs with systemd + reverse proxy<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Oracle Cloud Container Instances<\/strong><\/td>\n<td>Simple containerized services without Kubernetes<\/td>\n<td>VCN-native, less ops than VMs, straightforward deployments<\/td>\n<td>Limited orchestration, scaling\/rollouts external<\/td>\n<td>Few to moderate services, simple ops model, OCI-native networking<\/td>\n<\/tr>\n<tr>\n<td><strong>OKE (Oracle Kubernetes Engine)<\/strong><\/td>\n<td>Complex microservices, platform teams<\/td>\n<td>Kubernetes ecosystem, autoscaling, advanced networking patterns<\/td>\n<td>More complexity, cluster operations<\/td>\n<td>You need Kubernetes features and standardization<\/td>\n<\/tr>\n<tr>\n<td><strong>Compute Instances + Docker<\/strong><\/td>\n<td>Full control, special host needs<\/td>\n<td>Maximum flexibility, mature VM ops patterns<\/td>\n<td>You manage patching, scaling, drift<\/td>\n<td>Specialized workloads, strict OS control, custom agents\/drivers<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI Functions<\/strong><\/td>\n<td>Event-driven tasks<\/td>\n<td>Simple event integrations, scale-to-zero patterns<\/td>\n<td>Runtime limits, not for long-running services<\/td>\n<td>Lightweight event processing, sporadic workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Fargate \/ Azure ACI<\/strong><\/td>\n<td>Similar \u201crun containers without servers\u201d model<\/td>\n<td>Mature serverless container runtimes in those ecosystems<\/td>\n<td>Different IAM\/networking models; migration work<\/td>\n<td>Multi-cloud teams, existing investment in those clouds<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Run<\/strong><\/td>\n<td>HTTP services with scale-to-zero<\/td>\n<td>Very simple deployments, managed ingress<\/td>\n<td>Different networking and control model<\/td>\n<td>Primarily stateless HTTP, rapid scaling, minimal infrastructure<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed Kubernetes\/Nomad<\/strong><\/td>\n<td>Maximum control, custom scheduling<\/td>\n<td>Full control and extensibility<\/td>\n<td>High operational burden<\/td>\n<td>Regulated environments needing deep customization<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Internal payments microservice platform (non-Kubernetes tier)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: An enterprise has 15 internal microservices that must run in a private OCI network, integrate with databases, and meet audit requirements\u2014but the team doesn\u2019t want to operate Kubernetes for this tier.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Each microservice runs as a <strong>Container Instance<\/strong> in a private subnet.<\/li>\n<li>An <strong>internal OCI Load Balancer<\/strong> fronts the services (or separate LBs per domain).<\/li>\n<li><strong>OCI API Gateway<\/strong> (optional) provides centralized routing\/auth for internal consumers.<\/li>\n<li><strong>Vault<\/strong> stores DB credentials and API keys (apps retrieve at runtime).<\/li>\n<li><strong>Logging\/Monitoring<\/strong> capture metrics and logs; <strong>Audit<\/strong> for change tracking.<\/li>\n<li><strong>Why Container Instances was chosen<\/strong><\/li>\n<li>Simpler operational model than OKE for a moderate number of stable services<\/li>\n<li>Strong OCI network integration with compartments and IAM governance<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Faster deployment cycles than VM-based approach<\/li>\n<li>Reduced ops workload (no host fleet management)<\/li>\n<li>Improved governance via tagging, compartments, and audit trails<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS webhook receiver and worker<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team needs a webhook receiver (HTTP) and a worker that processes events and writes to a database. They need to ship quickly and keep costs predictable.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Webhook service: 2 container instances behind a small public load balancer (or one instance for early stage)<\/li>\n<li>Worker: 1 container instance in a private subnet<\/li>\n<li>Database: managed DB service in private network<\/li>\n<li>CI\/CD pushes images to OCIR and redeploys by replacing instances<\/li>\n<li><strong>Why Container Instances was chosen<\/strong><\/li>\n<li>Minimal platform overhead<\/li>\n<li>Easy container-based deployments without Kubernetes learning curve<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Quick iteration and production readiness<\/li>\n<li>Ability to grow into OKE later if orchestration needs increase<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Oracle Cloud Container Instances the same as Kubernetes (OKE)?<\/strong><br\/>\nNo. Container Instances runs containers without requiring you to manage a Kubernetes cluster. OKE is managed Kubernetes for orchestrated container platforms.<\/p>\n\n\n\n<p>2) <strong>Do I need to manage servers or VM nodes?<\/strong><br\/>\nTypically no. Container Instances is designed to avoid VM management for container workloads.<\/p>\n\n\n\n<p>3) <strong>Can I run internet-facing services?<\/strong><br\/>\nYes, commonly either by assigning a public IP (lab\/small use) or by placing instances behind an OCI Load Balancer (recommended for production).<\/p>\n\n\n\n<p>4) <strong>Can Container Instances run in a private subnet?<\/strong><br\/>\nYes. This is a common production pattern. You\u2019ll use private routing (NAT\/Service Gateway) as needed for outbound access.<\/p>\n\n\n\n<p>5) <strong>How do I scale Container Instances?<\/strong><br\/>\nMost commonly by creating more instances and placing them behind a load balancer. Autoscaling may require external automation. <strong>Verify<\/strong> whether OCI provides native autoscaling for Container Instances in your region.<\/p>\n\n\n\n<p>6) <strong>Does it support multi-container \u201cpods\u201d?<\/strong><br\/>\nSome container-instance services support multiple containers sharing networking; OCI\u2019s exact support can evolve. <strong>Verify in official docs<\/strong> for your region and the current API.<\/p>\n\n\n\n<p>7) <strong>How do I do rolling updates?<\/strong><br\/>\nA common approach is immutable replacement: deploy new instances with a new image tag, switch traffic at the load balancer, then terminate old instances.<\/p>\n\n\n\n<p>8) <strong>Can I mount persistent storage?<\/strong><br\/>\nPersistent storage support depends on the service\u2019s volume\/mount features. Many teams use external storage services (Object Storage, databases) or network file systems. <strong>Verify<\/strong> supported volume types.<\/p>\n\n\n\n<p>9) <strong>What registries can I use?<\/strong><br\/>\nOCIR is the natural choice for private enterprise images. Public registries like Docker Hub are commonly used for public images. Private registry authentication support should be <strong>verified<\/strong> for your environment.<\/p>\n\n\n\n<p>10) <strong>How do I handle secrets securely?<\/strong><br\/>\nUse OCI Vault to store secrets and fetch them at runtime using a secure pattern. Avoid baking secrets into images or storing them in source control.<\/p>\n\n\n\n<p>11) <strong>Is there a \u201cscale to zero\u201d feature like some serverless platforms?<\/strong><br\/>\nNot typically in the same way as request-driven serverless. Container Instances is usually billed while running based on resources allocated. <strong>Verify<\/strong> current metering behavior.<\/p>\n\n\n\n<p>12) <strong>How do I observe logs and metrics?<\/strong><br\/>\nUse OCI Logging\/Monitoring integrations where available and\/or ship logs from the app to a log endpoint. Confirm the supported log capture configuration in official docs.<\/p>\n\n\n\n<p>13) <strong>What\u2019s the difference between Container Instances and running Docker on a Compute VM?<\/strong><br\/>\nOn a VM, you manage the OS, patching, scaling, and runtime configuration. With Container Instances, OCI manages more of the runtime layer, reducing ops overhead.<\/p>\n\n\n\n<p>14) <strong>Can I restrict network egress?<\/strong><br\/>\nYes, using route tables, NAT\/Service Gateway choices, and NSG\/security list egress rules. Also consider OCI Network Firewall in advanced cases.<\/p>\n\n\n\n<p>15) <strong>Is Container Instances suitable for regulated workloads?<\/strong><br\/>\nIt can be, if you design for compliance: private networking, least privilege IAM, audit logging, encryption, and approved image supply chain. Confirm required certifications and controls in official OCI compliance documentation.<\/p>\n\n\n\n<p>16) <strong>How do I keep costs under control?<\/strong><br\/>\nRight-size resources, avoid unnecessary load balancers for small dev workloads, limit log volume, and terminate unused instances.<\/p>\n\n\n\n<p>17) <strong>When should I move from Container Instances to OKE?<\/strong><br\/>\nWhen you need Kubernetes-native features: autoscaling, advanced deployment strategies, service mesh, operators, or large-scale multi-service orchestration.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Container Instances<\/h2>\n\n\n\n<p>Use official resources first, since features and APIs can evolve.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>OCI Documentation (start here): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/home.htm<\/td>\n<td>Central entry point; navigate to Compute \u2192 Container Instances for the latest docs<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Oracle Cloud Pricing: https:\/\/www.oracle.com\/cloud\/pricing\/<\/td>\n<td>Pricing model overview and links to service pricing<\/td>\n<\/tr>\n<tr>\n<td>Official price list<\/td>\n<td>Oracle Cloud Price List: https:\/\/www.oracle.com\/cloud\/price-list\/<\/td>\n<td>Region\/SKU-level pricing details<\/td>\n<\/tr>\n<tr>\n<td>Official cost calculator<\/td>\n<td>OCI Cost Estimator: https:\/\/www.oracle.com\/cloud\/costestimator.html<\/td>\n<td>Build realistic estimates for dev\/prod scenarios<\/td>\n<\/tr>\n<tr>\n<td>Official CLI docs<\/td>\n<td>OCI CLI Concepts: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/Concepts\/cliconcepts.htm<\/td>\n<td>How to install and use OCI CLI for automation<\/td>\n<\/tr>\n<tr>\n<td>Official IAM docs<\/td>\n<td>OCI IAM docs (via docs home search \u201cIAM policies\u201d): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/home.htm<\/td>\n<td>Correct policy syntax and least-privilege patterns<\/td>\n<\/tr>\n<tr>\n<td>Official networking docs<\/td>\n<td>OCI Networking docs (via docs home): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/home.htm<\/td>\n<td>VCN, subnets, gateways, NSGs\/security lists needed for Container Instances<\/td>\n<\/tr>\n<tr>\n<td>Official architecture center<\/td>\n<td>Oracle Architecture Center: https:\/\/docs.oracle.com\/en\/solutions\/<\/td>\n<td>Reference architectures and best practices (search for container patterns)<\/td>\n<\/tr>\n<tr>\n<td>Official tutorials\/labs<\/td>\n<td>Oracle Cloud Tutorials (landing): https:\/\/docs.oracle.com\/en\/learn\/<\/td>\n<td>Hands-on labs for OCI services; search for container runtime patterns<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Oracle Cloud Infrastructure YouTube: https:\/\/www.youtube.com\/@oraclecloudinfrastructure<\/td>\n<td>Service walkthroughs, architecture talks, and updates (search \u201cContainer Instances OCI\u201d)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following training providers may offer courses related to Oracle Cloud, containers, DevOps, and cloud operations. Confirm current syllabi and delivery modes on their websites.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; Suitable audience: DevOps engineers, SREs, platform teams, developers\n   &#8211; Likely learning focus: DevOps practices, containers, CI\/CD, cloud fundamentals and operations\n   &#8211; Mode: Check website\n   &#8211; Website: https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong>\n   &#8211; Suitable audience: Beginners to intermediate DevOps learners\n   &#8211; Likely learning focus: SCM, CI\/CD, DevOps tooling, practical labs\n   &#8211; Mode: Check website\n   &#8211; Website: https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong>\n   &#8211; Suitable audience: Cloud operations engineers, DevOps engineers\n   &#8211; Likely learning focus: Cloud ops practices, monitoring, automation, reliability concepts\n   &#8211; Mode: Check website\n   &#8211; Website: https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong>\n   &#8211; Suitable audience: SREs, operations teams, platform engineers\n   &#8211; Likely learning focus: SRE principles, observability, incident management, reliability engineering\n   &#8211; Mode: Check website\n   &#8211; Website: https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong>\n   &#8211; Suitable audience: Ops teams exploring AIOps, monitoring\/automation engineers\n   &#8211; Likely learning focus: AIOps concepts, automation, operational analytics\n   &#8211; Mode: Check website\n   &#8211; Website: https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites are listed as training resources\/platforms. Verify current offerings and trainer profiles on the linked pages.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong>\n   &#8211; Likely specialization: DevOps, cloud, automation (verify specific topics on site)\n   &#8211; Suitable audience: Engineers seeking practical mentoring\n   &#8211; Website: https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong>\n   &#8211; Likely specialization: DevOps tools and practices, CI\/CD, containers (verify on site)\n   &#8211; Suitable audience: Beginners to intermediate DevOps learners\n   &#8211; Website: https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong>\n   &#8211; Likely specialization: DevOps consulting\/training resources (verify on site)\n   &#8211; Suitable audience: Teams seeking short-term coaching or project support\n   &#8211; Website: https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong>\n   &#8211; Likely specialization: DevOps support, troubleshooting help, training resources (verify on site)\n   &#8211; Suitable audience: Ops\/DevOps teams needing hands-on support\n   &#8211; Website: https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These organizations may offer consulting services related to DevOps, cloud migrations, containerization, and operations. Confirm exact service offerings directly with the company.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong>\n   &#8211; Likely service area: Cloud\/DevOps consulting, implementation support (verify on site)\n   &#8211; Where they may help: Container adoption, CI\/CD, cloud operations processes\n   &#8211; Consulting use case examples:<\/p>\n<ul>\n<li>Containerizing legacy applications and deploying to OCI<\/li>\n<li>Designing VCN networking for secure container workloads<\/li>\n<li>Website: https:\/\/cotocus.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; Likely service area: DevOps consulting and training (verify on site)\n   &#8211; Where they may help: CI\/CD pipelines, container strategy, platform enablement\n   &#8211; Consulting use case examples:<\/p>\n<ul>\n<li>Building deployment workflows to Container Instances or OKE<\/li>\n<li>Observability and incident response process setup<\/li>\n<li>Website: https:\/\/www.devopsschool.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong>\n   &#8211; Likely service area: DevOps consulting services (verify on site)\n   &#8211; Where they may help: Toolchain selection, automation, cloud migration planning\n   &#8211; Consulting use case examples:<\/p>\n<ul>\n<li>Designing immutable deployment processes for container workloads<\/li>\n<li>Cost optimization reviews for OCI runtime and networking<\/li>\n<li>Website: https:\/\/www.devopsconsulting.in\/<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Container Instances<\/h3>\n\n\n\n<p>Foundations:\n&#8211; Linux basics (processes, networking, DNS, TLS)\n&#8211; Containers:\n  &#8211; Docker fundamentals (images, layers, registries)\n  &#8211; Basic container security (least privilege, image hygiene)\n&#8211; OCI fundamentals:\n  &#8211; Compartments, IAM users\/groups\/policies\n  &#8211; VCNs, subnets, route tables, security lists\/NSGs\n  &#8211; Basic OCI billing and cost concepts<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Container Instances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCIR<\/strong> and enterprise image management practices<\/li>\n<li><strong>OCI Load Balancer<\/strong> design (health checks, TLS, backend sets)<\/li>\n<li><strong>OCI Vault<\/strong> patterns for secrets and key management<\/li>\n<li><strong>Observability<\/strong>:<\/li>\n<li>OCI Logging\/Monitoring (and OpenTelemetry patterns where applicable)<\/li>\n<li><strong>OKE<\/strong> for orchestrated workloads when your platform needs grow<\/li>\n<li><strong>Infrastructure as Code<\/strong>:<\/li>\n<li>Terraform for OCI resource management (recommended for production)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer (OCI)<\/li>\n<li>DevOps engineer<\/li>\n<li>Platform engineer<\/li>\n<li>SRE<\/li>\n<li>Solutions architect<\/li>\n<li>Application engineer deploying containerized services<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Oracle\u2019s certification offerings change over time. A practical approach:\n&#8211; Start with OCI foundation-level certifications\n&#8211; Move to architect\/professional tracks relevant to your role\n&#8211; Add container\/Kubernetes certifications if you plan to move to OKE<\/p>\n\n\n\n<p><strong>Verify current Oracle certifications<\/strong> on Oracle\u2019s official certification site:\n&#8211; https:\/\/education.oracle.com\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Deploy a small API to Container Instances in a private subnet behind an internal load balancer.<\/li>\n<li>Build a CI\/CD pipeline that:\n   &#8211; builds an image\n   &#8211; pushes to OCIR\n   &#8211; deploys by replacing container instances<\/li>\n<li>Implement a blue\/green rollout with two backend sets in OCI Load Balancer.<\/li>\n<li>Add Vault-based secret retrieval to your app (no secrets in images).<\/li>\n<li>Add structured logging and dashboards (request rate, latency, errors).<\/li>\n<li>Create a cost report using tagging (<code>Environment<\/code>, <code>Owner<\/code>, <code>CostCenter<\/code>).<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI (Oracle Cloud Infrastructure)<\/strong>: Oracle Cloud\u2019s infrastructure platform providing compute, networking, storage, and managed services.<\/li>\n<li><strong>Compute<\/strong>: OCI category for compute resources such as VMs and managed runtime services like Container Instances.<\/li>\n<li><strong>Container Instances<\/strong>: OCI service to run containers without managing servers or Kubernetes clusters.<\/li>\n<li><strong>Container image<\/strong>: A packaged application artifact containing filesystem layers and metadata used to run a container.<\/li>\n<li><strong>OCIR<\/strong>: Oracle Cloud Infrastructure Registry, OCI\u2019s container image registry service.<\/li>\n<li><strong>VCN<\/strong>: Virtual Cloud Network\u2014your isolated network in OCI.<\/li>\n<li><strong>Subnet<\/strong>: A segmented IP range within a VCN where resources are placed.<\/li>\n<li><strong>Security List<\/strong>: Subnet-level firewall rules (stateful by default in OCI).<\/li>\n<li><strong>NSG (Network Security Group)<\/strong>: Resource-level virtual firewall rules that can be applied to VNIC-attached resources.<\/li>\n<li><strong>Internet Gateway (IGW)<\/strong>: Enables internet connectivity for public subnets.<\/li>\n<li><strong>NAT Gateway<\/strong>: Allows private subnet resources to initiate outbound connections to the internet without inbound exposure.<\/li>\n<li><strong>Service Gateway<\/strong>: Enables private access from a VCN to selected OCI services.<\/li>\n<li><strong>Compartment<\/strong>: OCI governance boundary for organizing resources, IAM policy scope, and cost tracking.<\/li>\n<li><strong>IAM policy<\/strong>: A statement defining permissions for groups\/dynamic groups to act on resource types in compartments.<\/li>\n<li><strong>Immutable deployment<\/strong>: Deployment method where you replace old instances with new ones instead of modifying in place.<\/li>\n<li><strong>Load Balancer<\/strong>: Service that distributes traffic across multiple backends and provides health checks and TLS termination.<\/li>\n<li><strong>OCPU<\/strong>: Oracle CPU unit used for sizing compute resources in OCI.<\/li>\n<li><strong>Audit<\/strong>: OCI service that records API calls and changes to resources for governance and security.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Oracle Cloud <strong>Container Instances<\/strong> is a <strong>Compute<\/strong> service for running containers without managing VMs or a Kubernetes cluster. It matters because it offers a practical middle path: faster deployments and simpler operations than VM-hosted Docker, with fewer moving parts than Kubernetes for many workloads.<\/p>\n\n\n\n<p>It fits best when you want VCN-native, IAM-governed container workloads\u2014APIs, workers, and simple services\u2014especially when you can keep state in managed OCI services. Cost is primarily driven by allocated OCPUs\/memory and runtime duration, plus surrounding services like load balancers, logging, and network egress. Security depends heavily on correct IAM policies, private networking patterns, and disciplined secrets handling.<\/p>\n\n\n\n<p>Use Container Instances when you need straightforward container runtime in OCI; move to OKE when you need full orchestration and Kubernetes ecosystem features. Next step: build a small CI\/CD pipeline that publishes to OCIR and deploys immutable replacements to Container Instances, then add observability and a load balancer for production readiness.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,62],"tags":[],"class_list":["post-868","post","type-post","status-publish","format-standard","hentry","category-compute","category-oracle-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/868","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=868"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/868\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=868"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=868"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=868"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}