Container · Docker
Container / Docker
What is a container?
- Packages the program and its environment together
- Runs the same everywhere
- Docker is the best-known tool
The first thing that changes when you start using containers is that your server setup document becomes code. Before, teams kept install guides on a wiki ("install Java 11, set the environment variables like this, use these library versions") and people followed them by hand. With containers, that procedure goes into a single file called a Dockerfile, and that file is what actually runs. The real change: there is no room left for human memory or personal habits to creep in.
It is easy to confuse containers with virtual machines (VMs), but they work at different layers. A VM boots an entire extra operating system, so images typically run to several GB and startup takes minutes. A container shares the host’s kernel, so it weighs tens to hundreds of MB and usually starts in seconds. The terms need to be kept apart, too. The blueprint is the image, a running instance of that image is the container, and the warehouse that stores and distributes images is the registry. Once containers multiply into the dozens and you need to automate placement and recovery, the conductor for that job is Kubernetes.
Not every organization needs it right away. If you run one service on one server and update it once a quarter, the cost of adopting it outweighs the benefit. It pays off clearly when you deploy often, install the same product in many customer environments, or keep repeating environment setup as your developer team grows. The deciding factor is not tech preference but "how many places do I need to run the same thing, identically?"
The most common failure point is simply leaving data inside the container. A container loses its internal changes when it is stopped and restarted, so if you keep a database or uploaded files inside without attaching a volume, a single redeployment wipes them out entirely. The habit of using only the 'latest' image tag is risky too. The latest you pulled yesterday and the latest you pull today can be different things, so you throw away the 'runs the same everywhere' advantage yourself. If you don't pin versions to specific numbers, you can't trace which code was running even when an outage hits.
Seungtae ParkA hands-on AX instructor who teaches AI business development and marketing automation by building them in practice
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, helping non-specialists put AI to work right away| Category | Container | Virtual machine (VM) |
|---|---|---|
| Weight | Light (shares the OS) | Heavy (entire OS) |
| Speed | Fast startup | Slow boot |
| Isolation | Process-level | Full isolation |
The container concept had existed in Linux for a long time, but Docker (Solomon Hykes), which appeared in 2013, made it easy to use and brought it into the mainstream, making it the standard technology for modern deployment.
Let’s look at a hypothetical case. Company A, a logistics software company with 90 employees, had been delivering the same system as an on-premises installation to 12 shipper clients. Each client had a different server OS and library versions, so installation took 5 days on average, and environment-related incidents alone generated 11 support tickets a month. When a new developer joined, just matching the development environment took three days.
- Kim, a manager on the development team, moved a 14-page installation guide into a single Dockerfile, proposing, "Let's have a machine read this document instead of a person." The first image came to 1.8GB.
- Park, the infrastructure manager, switched to a lightweight base image and split the build into two stages, cutting the image to 380MB. Download time over a customer's network dropped from 40 minutes to 7.
- The team set up an internal registry and pushed images with fixed tags such as v2.4.1. When a customer asks, "Which version are we on?", they can now answer immediately just by checking the tag.
- The database and uploaded files were moved out to volumes outside the container. The team made this a firm rule after an internal test in which a single redeployment wiped two days of shipping records.
- Four months later, customer installation time dropped from an average of 5 days to half a day, and support tickets caused by environment differences fell from 11 a month to 1. Setting up a new developer's environment went from three days to 2 hours.