Let's Docker

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 🙂

Sources

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.

The Dockerfile

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.

Example

This 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"]

• FROM node:latest tells Docker to download the lastest (in this case) ubuntu-based node 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.
• WORKDIR /app tells Docker where the application files should be placed once the container's powered on.
• COPY . . asks for copying the content in . to the WORKDIR that we just setup.
• ENV PORT=3000 defines a system environment variable called POST and initialises it with the value 3000.
• RUN npm install this asks the container to install the dependencies we require for our node setup.
• EXPOSE $PORT makes 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 Docker how the app should start. Short way to do:
• cd app
• node app.js

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

Managing containers

If we want to have information about the containers we have running, we need this command:

docker ps
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.

Interactive mode

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 ps.

• 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 now on Ubuntu. Right after executing the command, the SIGTERM signal is sent to the container, and after a period of grace, SIGKILL.
• docker kill <containerId> is the way to force a shutdown of the container. Using kill we don't get any guarantees that the container's state's gonna be properly saved. Here, SIGKILL is executed right after executing it.

Summary: In general, kill when in development, and stop when running a production container.