bbs/sbbs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a12bf01e9a
sbbs/source/_posts/dockerinfo.md
Deon George 6dcdca291e Merged updates from old site
2020-08-15 17:33:49 +10:00

7.5 KiB
Raw Blame History

title date thumbnail comments categories
About Docker 2020-04-01 22:43:01 /images/docker.png false
Docker

Getting started with docker may seem complex, but here is some info that might help you get started. There are some fundamentals that you should understand too - if anything to save any heartache later. :)

What is Docker

Docker is "like" virtualisation in that your application runs in it's own space, and thinks it is the only application running in that space (as if it were on a physical machine).

In reality, Docker is process separation - it is your application running on the same host with other applications, but docker puts each in a jail.

Docker Components (or Terms)

  • Image - represents an application, specifically a version of an application. When an image is built with docker build it has everything it needs for the application to run. All dependencies (libraries, binaries, utilities, etc) are packaged up into the image.

Generally, you use an image to run one or more containers of that image - but you don't "upgrade" the application inside the image, instead you build a new image. So its not uncommon to have images of application:v1, and application:v1.1.

A good way to relate to this, is using a "Live CD-ROM" analogy. A live CD-ROM is an OS, and often with applications, that is burnt to a CD (or DVD). Once the CD is written, it's contents cannot be changed.

However, you can make many copies of that CD, and use it on many physical machines, to have the "same" environment across multiple physical hosts.

A docker image, is like a "Live CD-ROM". From that image, you can start many containers, and each container is exactly the same as any other - the only difference being, is that the containers can all be on the same host, or across multiple hosts.

Also like a "Live CD-ROM" - the containers contents can be changed while it's running (just like you can author a document on a live CD-ROM environment, if it contains a word processor). But when you destroy the container (like powering of the live CD-ROM PC) - all changed data is lost, unless you store it on a specific persistent storage volume.

  • Container - represents a running instance of an image - like a "virtual machine". You can run many containers of the same image, and it would be like running many "instances" of the application on the same computing cluster.

By design, containers are intended to be created and destroyed often. In fact, when you get into using "clustering" (Kubernetes, Docker Swarm, etc) - your containers are often destroyed as they float between physical machines. Your container is also destroyed, when you use an "updated" image (which might represent an updated version of an application).

Because of this, there are important considerations relating to the data inside your container - if you need that data to persist between invocations of a container.

  • Registry - this is an "App Store" of "Docker Images" (where built images can be stored for easily deployment).

Why Docker

Docker is great for many reasons:

  1. Your applications run in a jail, and the only way in the jail is via a network connection. Well, that is not completely true, if you are logged into the host that is running your docker container, then you can "attach" to the console. For the most part however, applications are accessed via a network connection.

Inside the jail, applications can connect to the outside world (assume firewall rules don't restrict this), but they cannot connect to the host's file systems unless the container was given access to those filesystems when it was created.

The beauty of this design is, if the network application you are running is compromised by a hacker - then the hacker is inside the jail as well. The only damage they can do is to the data seen inside the jail, and being a good system admin, you backup daily right?

  1. Your application image and it's corresponding data is portable. You can pick it up and drop it on another host, start the container and it will be none the wiser. (It will be as if you stopped the application and then started it - it has no idea that it was moved to a separate host.)

  2. Application Developers/Vendors will generally create your application image - its like they do the install for you, and when you start your container (based on that image) - you start from "setup". There is NO installation time required once an image is created (creating the image is by definition installing the application). So it is super quick to "spin up" another copy of an application.

Things to know when using containers

  1. Where is "data" stored? Data adds personality to an application, and for it to persist you'll need to make sure that those data files are stored in a specific place. The container builder should provide you with those instructions when you first use the container, or you can make "known" data persistent points by starting your image with -v /path/on/the/host:/path/inside/the/container.

  2. What ports do you need to "join to" to access your container? While a webserver in a container might be listening for requests on TCP port 80, that needs to be mapped to from the host - and it could be port 80 on the host. IE: Host port 80 -> Container port 80. If you have many containers running web applications, then you'll need many mappings from the host - however, the host will need to use unique ports. EG: Host port 80 -> Container A port 80. Host port 81 -> Container B port 80, etc. This is done with -p host_port:container_port.

  3. In some cases, containers use shell variables to help with configuration. Again the container builder should provide you with information on what variables are required or useful. They are passed to the container by -e VAR=value

  4. Starting containers, is easy, the syntax is docker run .... When it starts, it will give you a Container ID. If you don't have the necessary image yet, docker will "pull" it from a registry automatically.

  5. Stopping containers is easy, the syntax is docker stop <CONTAINER ID>.

  6. Deleting containers is docker rm <CONTAINER ID>.

  7. Listing running containers is docker ps. The output looks like this:

deon@p-1-1:~ $ docker ps
CONTAINER ID        IMAGE                                                            COMMAND                  CREATED             STATUS              PORTS                                                                                                  NAMES
459a9fef84c6        debian:deb                                                       "exec/sbbs"              2 days ago          Up 2 days           0.0.0.0:13023->23/tcp                                                                                  amazing_elion
e793d6d33f52        leenooks/mbse:1.0.7.9                                            "/sbin/init /usr/bin…"   2 days ago          Up 2 days           80/tcp, 60177/tcp, 60179/tcp, 0.0.0.0:24554->24554/tcp, 0.0.0.0:11022->22/tcp, 0.0.0.0:11023->23/tcp   bbs_mbse.1.909vch9fbnqlk9iz3owv0qzu5
0f078a15af0b        registry.leenooks.net/leenooks/mysticbbs:1.12a39-armv7l-extras   "/sbin/init start"       2 days ago          Up 2 days           0.0.0.0:10022->22/tcp, 0.0.0.0:10023->23/tcp, 0.0.0.0:24555->24554/tcp                                 bbs_mystic.1.wn6bqs707bx37m40mltbsohyf
97dc2a415f89        nginx:latest                                                     "nginx -g 'daemon of…"   2 days ago          Up 2 days           0.0.0.0:80->80/tcp                                                                                     nginx_web.298qvanxdy7b4xxps4oqrjlue.ndkntwg19ahrszzbqji5bjthy