{"id":860,"date":"2020-03-09T22:52:52","date_gmt":"2020-03-10T03:52:52","guid":{"rendered":"http:\/\/zewwy.ca\/?p=860"},"modified":"2020-03-16T19:31:33","modified_gmt":"2020-03-17T00:31:33","slug":"belk-stack-on-docker-part-1-docker","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2020\/03\/09\/belk-stack-on-docker-part-1-docker\/","title":{"rendered":"BELK Stack on Docker <\/br>(Part 1 \u2013 Docker)"},"content":{"rendered":"

<\/h1>\n

<\/span>The Story<\/strong><\/span><\/h1>\n

This time our goal to setup a SEIM (Security Event & Information Monitoring) which will gather data via the BELK Stak (Beat, Elasticsearch, Logstash and Kibana). This is going to take (I’m assuming, as I’ve just started) about 4-5 separate blog posts to get this off the ground.<\/p>\n

It has taken me a couple weeks of smashing my head into a wall simply due to my own ignorance, so in this blog series I’m going to cover more step-by-step exactly what needs to be done for my particular setup. There are many ways you can configure services these days, which still includes bare metal. If I so chose I could run Docker on a bare metal Ubuntu server, or even a bare metal windows server, but in this case I’m going to install docker on a Ubuntu server which will happen to be itself a VM (Virtual Machine).<\/p>\n

Now with that in mind, here’s some basic reading you<\/a> probably should do before<\/a> continuing on. Now before we go on let’s be clear on one thing, docker itself doesn’t run on magic, or fluffly rainbow clouds, as I mentioned in the paragraph above it runs on some system, whether that’s again bare metal or some VM of some kind [Think IaaS (Infrastructure as a Service)], in this blog it will be a Ubuntu VM. The specs of this machine should suffice for the application and workloads that are going to be created on it.<\/p>\n

<\/span>Dockerfile Commands<\/span><\/h2>\n

Below, are the commands that will be used 90% of the time when you\u2019re writing Dockerfiles, and what they mean.<\/p>\n

FROM \u2014 this initializes a new build stage and sets the Base Image for subsequent instructions. As such, a valid Dockerfile must start with a FROM instruction.<\/p>\n

RUN \u2014 will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile.<\/p>\n

ENV \u2014 sets the environment variable <key> to the value <value>. This value will be in the environment for all subsequent instructions in the build stage and can be replaced inline in many as well.<\/p>\n

EXPOSE \u2014 informs Docker that the container listens on the specified network ports at runtime. You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified. This makes it possible for the host and the outside world to access the isolated Docker Container<\/p>\n

VOLUME \u2014 creates a mount point with the specified name and marks it as holding externally mounted volumes from the native host or other containers.<\/p>\n

You do not have to use every command. In fact, I am going to demonstrate a Dockerfile using only FROM, MAINTAINER, and RUN.<\/p>\n

<\/span>Images vs. Containers<\/span><\/h2>\n

The terms Docker image and Docker container are sometimes used interchangeably, but they shouldn\u2019t be, they mean two different things.
\nDocker images are executable packages that include everything needed to run an application \u2014 the code, a runtime, libraries, environment variables, and configuration files.
\nDocker containers are a runtime instance of an image \u2014 what the image becomes in memory when executed (that is, an image with state, or a user process).<\/p>\n

<\/p>\n

Examples of Docker containers. Each one comes from a specific Docker image.
\nIn short, Docker images hold the snapshot of the Dockerfile, and the Docker container is a running implementation of a Docker image based on the instructions contained within that image.<\/p>\n

This is true, however this image is a bit misleading as it’s missing the versioning which will become apparent a bit later on in this blog post.<\/p>\n

<\/span>Docker Engine Commands<\/span><\/h2>\n

Once the Dockerfile has been written the Docker image can be built and the Docker container can be run. All of this is taken care of by the Docker Engine that I covered briefly earlier.<\/p>\n

A user can interact with the Docker Engine through the Docker CLI, which talks to the Docker REST API, which talks to the long-running Docker daemon process (the heart of the Docker Engine). Here\u2019s an illustration below.<\/p>\n

\n
\n
\n
<\/div>\n<\/div>\n<\/div>
The CLI uses the Docker REST API to control or interact with the Docker daemon through scripting or direct CLI commands. Many other Docker applications use the underlying API and CLI as well.<\/figcaption><\/figure>\n

Here are the commands you\u2019ll be running from the command line the vast majority of the time you\u2019re using individual Dockerfiles.<\/p>\n