Today I've started my path into the Docker / Kubernetes world. Till now I've been managing Linux Distros
the-old-way™. During the next few week I'll see if this is really as awesome as I've been told a thousand times. This is also the first post I'm writting in English in this blog 🙂
The Internet's crazy about Docker and Kubernetes. That's one of the reasons why it took me so long to start learning this brighter side of the DevOps world. There are thousands of tutorials around, and I finally had to choose one:
- Learn how YOU can get started with Docker and Kubernetes - DEV Community 👩💻👨💻
- Learn Docker - from the beginning, part I images and containers - DEV Community 👩💻👨💻
Promoted by Azure, I know, but there are really good. And given the fact of Docker being a private company, well,
In for a dime, in for a dollar.
All hands on deck. The
Dockerfile is a text file containing a set of sequential instructions that allows setting a full environment up and running.
Dockerfile sets a node environment up and running:
FROM node:latest WORKDIR /app COPY . . ENV PORT=3000 RUN npm install EXPOSE $PORT ENTRYPOINT ["node", "app.js"]
Dockerto download the lastest (in this case)
ubuntu-basednode distribution available in DockerHub. DockerHub is a propietary service that provides images of almost every operative system in the world so they can be used in containers by users like you and me.
Dockerwhere the application files should be placed once the container's powered on.
COPY . .asks for copying the content in
WORKDIRthat we just setup.
ENV PORT=3000defines a system environment variable called
POSTand initialises it with the value
RUN npm installthis asks the container to install the dependencies we require for our node setup.
EXPOSE $PORTmakes the variable we just setup available to our application
- Thanks to this, in our app we can do
const port = process.env.PORT;to get the port we defined in an isolated environment!
ENTRYPOINT ["node", "app.js"]tells
Dockerhow the app should start. Short way to do:
Run boy run
There are two main ways to run a
Docker instance from your console: using a daemon or not using it.
- Without a daemon:
docker run -p 8000:3000 chrisnoring/node
- In daemon mode:
docker run -d -p 8000:3000 chrisnoring/node
The difference is that
If we want to have information about the containers we have running, we need this command:
That will list all the containers we have running at that moment, including the container id. WIth the container id we can kill, stop or access the container files.
Containers are not virtual machines, they are, apparently, better. There's a way to access the 'machine' data. That's called the interactive mode, and can be accessed with:
docker exec -it 268 bash being
268 the three first digits of the container id we wanna explore.
Killing or Stopping
There're two ways to stop a Docker container: stoppping or killing it. For both we need the container's id three first digits, and to get that:
docker stop <containerId>is a graceful way to stop a container: it allows it to save it's state and properly shutdown. It's like
shutdown -h nowon Ubuntu. Right after executing the command, the
SIGTERMsignal is sent to the container, and after a period of grace,
docker kill <containerId>is the way to force a shutdown of the container. Using
killwe don't get any guarantees that the container's state's gonna be properly saved. Here,
SIGKILLis executed right after executing it.
Summary: In general,
kill when in development, and
stop when running a production container.