Cloud Native Services on Oracle Cloud Infrastructure
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Cloud Native Computing Foundation, a part of the nonprofit Linux Foundation, is the premier body whose charter is to foster the development of open-source and vendor-neutral cloud native projects. According to the Cloud Native Computing Foundation (CNCF):
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
Cloud native applications are defined by their resilient design, capability to elastically scale using cloud platforms, and capacity to implement efficient lifecycle management that leverages observability and automation. The technology platforms and tools that enable developers to build cloud native applications are generally termed cloud native technologies. The fundamental outcome and goal of the cloud native paradigm is to dramatically improve software development velocity, thereby creating innovation that disrupts traditional business models.
Several turnkey technologies and patterns characterize modern cloud native applications, including container orchestration with Kubernetes, the use of service meshes and observability, and stream- and event-based service architecture. This chapter introduces the various services in Oracle Cloud Infrastructure (OCI) that developers can use as their fundamental building blocks when building cloud native applications. The chapter covers the role each of these services plays within the cloud native paradigm so that you get a panoramic view of the cloud native ecosystem that OCI offers. OCI’s fundamental focus on openness also means that these services are compliant with open standards or are built on top of industry-standard open-source platforms and are interoperable with them.
Oracle Container Image Registry
Containers are a fundamental turnkey technology that enables the creation of cloud native applications. Containers provide the capability to bundle applications and their dependencies into packages called container images. Container images contain the application code and its required dependencies, runtime, system settings, tools, and libraries. This packaging format makes it easy to quickly transmit application containers and run them in dynamic environments while providing a consistent execution environment for the application. Docker originally developed the container image specification and runtime. For this reason, containers and Docker are synonymous for most users. Docker donated the container image specification and the runtime to the Open Container Initiative1 to help establish open standards as the container ecosystem evolves.
At its core, a container image is a directory of files with associated metadata. The container image format2 defines the layers in a specific order that make up this directory. These layers are combined with union mounting, a way to combine the contents of various directories, to create a directory that seems like it contains the combined contents. The order of the layers is important because the layers are overlaid on top of each other. When the same files are present on multiple layers, the file on the upper layer overwrites (or deletes) the same files on the lower layer. When creating the image, each layer that makes up the image is archived into a tar ball and compressed with GZIP. A container image manifest describes the various layers of the image (in their respective order) and additional metadata such as the OS and architecture. A container runtime can take this package, the container image, and create an isolated execution environment for the application contained in the container image. The container image provides all the information for a container runtime, such as the manifests to identify the file system layers, an index that provides a list of manifests for various platforms, configuration documents that describe image ordering, and more. Using this information in the container image, a container runtime can obtain all layers and configure a running container. Figure 3-1 shows this model, with an image made up of several layers of files and described by manifests and configuration documents, while a container runtime uses the information in an image to create a running container.
)
FIGURE 3-1 Container/Container Image Model
Container images need to be stored in a repository, where they can be requested, or “pulled.” Registries provide an address for a container image—a URL that uniquely identifies a container image, called a container reference. Oracle Cloud Infrastructure Registry (OCIR, or Container Registry) is a managed service that provides a container image registry to store, serve, and manage container images. OCIR supports multiple image formats or specifications, including Docker V2 and the Open Container Initiative image spec. This allows OCIR to work with several container image specs and container runtimes that support these image specifications. This means that, when using OCIR, you can work with all standard container tools, such as Docker, Podman, cri-o, and containerd. Additionally, the service supports manifest lists, also known as image indexes in the Open Container Initiative specification. Manifest lists allow a single container reference to represent multiple forms of an image (multiple manifests). Each of these manifests is typically associated with a specific OS or architecture so that a container runtime can pick the manifest based on the platform that it’s running on. This is crucial when working with images that are built for different CPU architectures, such as amd64 (x86) and arm64 (ARM).
A typical image reference on OCIR looks like this:
iad.ocir.io/idi2cuxxbkto/demo-site:1.0.1
Breaking this image reference into its parts, you can see the following:
The registry URL: iad.ocir.io.
The namespace: idi2cuxxbkto. OCI provides every tenancy with a namespace, and this is shown when you create a repository.
The repository: demo-site.
The tag: 1.0.1. Tags point to the digest of the image manifest. A tag is a more human-readable pointer to an actual digest.
The Container Registry provides a manifest (or a manifest list) at this location for container runtimes to pull the image (its layers and its metadata). You can also use the docker manifest command to inspect the manifest (or manifest list) available at a container reference:
$ docker manifest inspect iad.ocir.io/idi2cuxxbkto/demo-site:1.0.1
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 9439,
"digest": "sha256:8bdcd2821a78c7bf91dffe1d3f0380cd6c977efe0214c0bc6962
7611e7205881"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 208,
"digest": "sha256:b1c13aac26c6d0816d720f6afed6292bde309137d4894819d3
c6e49265490c8c"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 2009946,
"digest": "sha256:c3c2acf3bfb91ca8a0220d3d411f8f91f92bc3725fd617b5f7
d962c5d06beb91"
}
]
}