Member-only story
You Built a Container, Now What?
Understand the difference between Docker, Docker Compose, and Kubernetes
Tired of configuring the same software over and over on different machines? Dealing with the 16 different packages that you need to install and following a wiki document over and over starts to become a hassle. Did you find a tutorial on Medium on how to run your first Docker container? Awesome, now what do you do?
One of the most common questions that people ask when starting to use Docker and containers is what next?
- How do I run my Angular app in a Docker container?
- Should I make a new container for every version of my application?
- How do I connect a database to my application?
- What is a
docker-composefile for? - Should I learn Kubernetes since it uses containers?
If you have a similar question to those above, read on and let me break it down for you.
Running a Container vs. Building a Container
If you’re an application programmer, you’re probably trying to build a container and get it to run using a Dockerfile. If you’re a system administrator, you’re probably trying to run a Docker container and manage the lifecycle of it. Understanding the difference between what you can do at a run time versus build time is important.
Run time
Simply running a single container is no different than starting up an application on your desktop. There’s a preconfigured script configured at build time with ENTRYPOINT that does whatever is needed for startup. The container will run until that script exits with a 0 status. This is extremely important to understand, especially if you’re building a container.
Build time
When using a Dockerfile, the easiest way to think about what needs to be put into a new container is this way: You’re taking some base-level container and adding or overriding stuff in your Dockerfile to ultimately generate a stand-alone container that’s a new image.
So if you’re trying to take a centos:7container and install an application into it and make it…
