Image vs. container — understand this first

 1. Image vs. container — understand this first

Image	Container
A blueprint/template	A running instance of an image
Read-only	Read-write while running
Created using a Dockerfile	Created from an image
Does not execute by itself	Actually runs your application
Can be shared via registries (Docker Hub, ECR, etc.)	Exists on a host machine while running/stopped

Simple analogy

Think of it like a Java application:

• Image = the compiled JAR file (myapp.jar)
• Container = the running Java process (java -jar myapp.jar)

Or:

• Image = class definition
• Container = object instance

Example

# Build image

docker build -t myapp .

# Create and run container from image

docker run -d --name myapp-container myapp

After running:

• myapp → Docker image
• myapp-container → Docker container

Relationship

One image can create many containers:

After running:

• myapp → Docker image
• myapp-container → Docker container

Relationship

One image can create many containers:

Image: nginx:latest

       |

       +--> Container A

       +--> Container B

       +--> Container C

Imagine you have developed a Java Spring Boot application.

Container image

A packaged template containing your application and the dependencies it needs.

Example: payment-app:v1

Container

A running instance created from the image.

You can start several containers from the same image, and each can have its own writable state.

Think of a container image as a recipe and a running container as the meal prepared from it. The recipe stays unchanged when you prepare multiple meals.

2. What is Docker?

Docker is a technology used to build, package, and run containerized applications.

For example, you can use Docker to package your Spring Boot application into an image and run it on your laptop.

Docker and Kubernetes have different responsibilities:

Technology	Main responsibility
Docker	Build images and run containers
Google Cloud Build	Automatically build software and container images
Google Artifact Registry	Store container images
Kubernetes	Manage and orchestrate containers across a cluster
Google Kubernetes Engine (GKE)	Google's managed Kubernetes service

Remember: Docker helps you build and run containers; Kubernetes manages containers at scale.

In this course, Google Cloud Build will be used to build Docker-formatted images.

3. How do containers work inside Linux?

The video explains that containers are not a completely separate feature of Linux. Their isolation comes from combining several Linux technologies.

There are three important concepts to learn.

A. Namespaces — what a container can see

Namespaces isolate the view of system resources available to a process.

For example, one container can have its own view of process IDs, network interfaces, and filesystem mounts.

Easy memory trick: Namespaces control what an application can see.

B. cgroups — what a container can use

Control and account for resources such as CPU and memory, and in supported configurations, I/O.

For example, you can limit a container so it cannot consume unlimited memory.

Easy memory trick: cgroups control what resources an application can use.

C. Union/overlay filesystems — how image layers work together

Combine filesystem layers efficiently, allowing images to reuse common files instead of duplicating everything.

Easy memory trick: Filesystem layers help package and reuse application files efficiently.

One important exam point: Linux namespaces and Kubernetes namespaces are different things. Linux namespaces provide process-level isolation; Kubernetes namespaces organize resources such as Pods and Services within a cluster.

4. What is a Dockerfile?

A Dockerfile is a text file containing instructions for building a container image.

Imagine your Spring Boot project has a compiled file named app.jar. A simplified Dockerfile could look like this:

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY app.jar app.jar
CMD ["java", "-jar", "app.jar"]

Let's understand each instruction.

Instruction	Meaning
FROM	Selects a base image, here a Java 17 runtime image
WORKDIR	Sets the working directory inside the image
COPY	Copies the JAR into the image
CMD	Specifies the default command when the container starts

For example, when the container starts, it runs:

java -jar app.jar

This example assumes that app.jar already exists in the build context. It packages and runs the application; it does not compile the Java source code.

5. What are image layers?

Every instruction that changes the image filesystem can contribute to a new image layer. Some Dockerfile instructions, such as CMD, configure image metadata rather than creating filesystem layers.

Consider this simplified image:

Layer 3: Application files

app.jar

Layer 2: Application setup

Working files and configuration

Layer 1: Base image

Java runtime and base filesystem

Conceptual view of a layered image, from top to bottom.

Why is this useful?

Suppose your base image is 200 MB, and you change only your application JAR. The new image can reuse unchanged layers and store only the changed content in new layers.

This helps reduce repeated downloads and speeds up image distribution, although the actual savings depend on which files change.

Dockerfile best practice: Put instructions that change less frequently earlier in the build, and frequently changing application files later. This can improve build-cache reuse.

6. What is a multi-stage build?

production applications usually don't need compilers and build tools at runtime.

A multi-stage build uses one stage to build the application and another stage to create a smaller runtime image.

Stage 1: Build

Source code + Maven + JDK → compiled JAR

Copy only the required output

Stage 2: Runtime

Java runtime + application JAR

Benefits include:

• Smaller production images.

• Fewer unnecessary tools in the deployed image.

• Potentially reduced attack surface.

• Cleaner separation between development/building and running.

The final runtime image still needs everything required to execute the application.

7. What is the writable container layer?

This is one of the most important concepts in the lesson.

When you create a container from an image, the container runtime adds a thin, writable layer on top of the image's read-only layers.

For example, imagine you run two containers from the same image:

Shared image

Application + Java runtime

Container A

Writable layer

File A

Container B

Writable layer

File B

Both containers reuse the image but have separate writable layers.

Container A can create a file called payment.txt, while Container B can create transaction.txt. These changes do not modify the shared image or automatically appear in the other container.

What happens when a container is deleted?

The container's writable layer is normally deleted with it. Any data stored only there is lost.

For a banking application, imagine storing important transaction records only inside the container's writable layer. If the container is deleted and replaced, those records could disappear.

The solution is to store permanent data outside the container's ephemeral writable layer.

Common options include:

• Persistent volumes for files that must survive container replacement.

• Cloud SQL or another database for application records.

• Google Cloud Storage for durable object storage.

Remember: Containers are replaceable; important application data must be stored durably elsewhere.

8. Where do you store container images?

Google Cloud provides Artifact Registry, a service for storing and managing container images and other software packages.

Docker Hub

A widely used public registry for container images.

Google Artifact Registry

Stores images and packages for use in Google Cloud workflows.

Artifact Registry integrates with other Google Cloud services:

Service	Purpose
IAM	Controls who can access images
Cloud KMS	Manages encryption keys when configured
Cloud Build	Builds images and can publish them to the registry
Container Analysis	Provides vulnerability and other image metadata analysis

For example, your team can publish a Spring Boot image to Artifact Registry and then configure GKE to pull that image when deploying the application.

9. What is Google Cloud Build?

Cloud Build is a managed service that automates the software build process.

Suppose you have Java source code stored in Bitbucket.

The process can look like this:

1

Source code

Your Java application in Bitbucket

2

Cloud Build

Runs configured build steps

3

Tests and compilation

Runs Maven or Gradle commands and tests

4

Artifact Registry

Stores the built container image

5

GKE

Deploys and manages the application containers

Each Cloud Build step runs in a container. A configured pipeline can fetch dependencies, compile code, run tests, build a Docker-compatible image, and push it to a registry.

Cloud Build is managed by Google, so you don't have to maintain your own dedicated build server. You still need to configure appropriate permissions, build steps, and security controls.

10. Final revision notes

Term	Easy definition
Image	Packaged template of an application and its dependencies
Container	Running instance of an image
Dockerfile	Instructions for building an image
Docker	Technology for building and running containers
Namespace	Controls what a process can see
cgroups	Controls and accounts for resource usage
Image layers	Reusable filesystem changes that form an image
Writable layer	Temporary changes made by a running container
Multi-stage build	Separates building the app from packaging its runtime
Artifact Registry	Stores container images and software packages
Cloud Build	Automates software and image builds
Kubernetes	Orchestrates containers at scale
GKE	Google's managed Kubernetes service