4.1 Containerization, Microservices & OCI Container Instances
Key Takeaways
OCI Container Instances is a serverless compute service that runs containers without managing servers, with the same isolation as virtual machines.
A single container instance can run up to 60 containers, which share the instance's flexible-shape OCPUs and memory.
The container restart policy can be Always (the default), Never, or On failure; if all containers exit and none restart, the container instance shuts down.
Container Instances supports File Storage volumes, empty-directory volumes backed by memory or ephemeral storage, and configuration-file volumes.
Stopping a container instance pauses billing; Creating, Failed, and Inactive states are not billed, while Active and Updating are billed.
From Monoliths to Microservices
A microservice architecture splits an application into small, independently deployable services, each owning its own data and exposing a well-defined API. Containers are the natural packaging unit: an image bundles the code, runtime, and libraries so the same artifact runs in development, test, and production. On OCI, a typical cloud-native flow looks like this:
- Developers commit code to a repository.
- An OCI DevOps build pipeline builds a container image and pushes it to OCI Container Registry (OCIR).
- A deployment pipeline releases the image to a runtime: Container Instances, OKE, or OCI Functions.
- API Gateway, Streaming, Queue, and Events connect the services, and Monitoring and Logging observe them.
Key design principles that exam scenarios test:
- Statelessness: keep session state out of the container (in a database, OCI Cache, or Object Storage) so instances can be replaced or scaled freely.
- Loose coupling: communicate through APIs, queues, or event streams rather than shared databases.
- Independent deployment: each service has its own pipeline and versioned image.
- Observability by design: every service writes logs and metrics in a consistent format.
Choosing a Container Runtime
| Requirement | Best fit | Why |
|---|---|---|
| Run one or a few containers with no orchestration | Container Instances | Serverless; specify images, shape, and networking only |
| Many services, service discovery, rolling updates, autoscaling of pods | OKE | Full Kubernetes control plane managed by Oracle |
| Short, event-driven code with automatic scale-to-zero | OCI Functions | Pay per invocation; synchronous calls up to 300 seconds |
| Batch job that runs for hours | Container Instances or OKE jobs | No function time limit; billed only while running |
OCI Container Instances
Oracle describes Container Instances as a serverless compute service that runs containers without managing any servers, on compute optimized for containers, with the same isolation as virtual machines. It suits APIs, web applications, CI/CD build and deployment jobs, automation tasks, data and media processing jobs, and development or test environments that do not need Kubernetes.
Shapes and Resource Allocation
A container instance uses a flexible shape, such as CI.Standard.E4.Flex, where you choose the number of OCPUs and the amount of memory. Network bandwidth and the number of VNICs scale with the OCPU count. You can give the containers all of the CPU and memory of the shape, or set per-container limits so one container cannot starve another. For example, a WordPress container and a MySQL container can each be limited to half of the instance's resources.
Multiple Containers per Instance
One container instance can run up to 60 containers. Containers in the same instance share its CPU, memory, and network namespace, so one container can reach another over localhost (Oracle's tutorial connects a WordPress container to a MySQL container at 127.0.0.1). They can also share volumes, which makes it easy to run an application with a sidecar, such as a log forwarder. Oracle recommends a managed database service rather than a database container for production.
Restart Policy and Graceful Shutdown
The container restart policy applies when a container exits:
| Policy | Behavior | Typical use |
|---|---|---|
| Always (default) | Restarts containers even when they exit successfully | Web servers and long-running services |
| Never | Never restarts containers | One-off tasks where a restart would repeat work |
| On failure | Restarts only when a container exits with an error | Jobs that must complete successfully |
If all containers exit and none restart, the container instance shuts down. A graceful shutdown timeout (default 0 seconds) controls how long the instance waits for the operating system to shut down before powering off.
Storage Volumes
| Volume type | Purpose |
|---|---|
| File storage | Persistent storage backed by OCI File Storage; the mount target must be reachable from the instance subnet |
| Empty directory | A shared scratch directory for the containers, backed by memory (tmpfs) or ephemeral storage |
| Configuration file | A Kubernetes-style volume containing one or more supplied files, such as configuration templates |
Images and Registry Credentials
The registry that holds an image must be reachable from the instance's subnet:
- For OCIR, use a subnet in a VCN with a service gateway.
- For a public registry on the internet, use a public subnet with an internet gateway or a private subnet with a NAT gateway.
For private registries, registry credentials can be None, Basic (username and password), or an OCI Vault secret, which keeps the password out of the instance definition.
Container Security Settings
Each container can be hardened with a read-only root file system, run as non-root user, an explicit user ID and group ID, and Linux capabilities that you drop or add (for example, drop ALL and add only CAP_NET_BIND_SERVICE).
Networking
A container instance gets a VNIC in the subnet you choose. Private subnets are recommended; a public IPv4 address can be assigned only in a public subnet. Network security groups control traffic to the instance, and a private DNS record can give it a stable hostname.
Lifecycle States and Billing
| State | Meaning | Billed? |
|---|---|---|
| Creating | Being created | No |
| Active | Running, or pulling images | Yes |
| Updating | Configuration change, restart, start, or stop in progress | Yes |
| Failed | Cannot be recovered, for example because an image could not be pulled | No |
| Inactive | Stopped by you, or all containers exited with restarts disabled | No |
Stopping a container instance pauses billing. Stopped and failed instances still count toward service limits. Container Instances also emits events (create, start, stop, restart, update, delete, maintenance) that you can route with Events rules.
A team needs to run a nightly media-processing job packaged as two containers: the processor and a log-shipping sidecar. The job runs for about two hours and must not be restarted after it finishes successfully, but should restart if it crashes. The team does not want to manage Kubernetes. Which configuration fits best?
An OKE basic cluster with a managed node pool that runs a Kubernetes CronJob
An OCI Function invoked synchronously by a scheduled Events rule every night
A container instance with both containers and the restart policy set to Always
A container instance with both containers and the restart policy On failure
A container instance in a private subnet fails to start because it cannot pull its image from OCI Container Registry. The subnet's route table has no route rules, and security policy forbids any internet access from this subnet. What is the recommended fix?
Assign a public IPv4 address to the container instance's VNIC
Attach a service gateway and add a route for all OCI services in the region
Add a NAT gateway and a default route so the subnet can reach the registry endpoint
Increase the graceful shutdown timeout so the image pull has more time
Sections you finish are checked off in the contents.