Simple Docker Example

This is a continuation of the Ultra minimal docker Node.JS example.

The code can be downloaded from GitLab.com

This is a very simple example of Docker running a simple NodeJS app.

Things to know. Containers are not VMs, they are more like a root jail. They use the host OS kernel and processes running in the container are visible to the host OS. Docker is just one of many ways to use containers. Proxmox is another, and it can also run VMs.

This example requires a Linux system with Docker installed. Installing Docker for Debian Installing Docker for CentOS

For more information see this cheat sheet.

Almost all of these steps require permission to execute privileged commands. In a production environment, a special group would be created with permissions to run these commands. If you are new to Linux the sudo command is commonly used to run commands as the root administrator, just prefix the commands with sudo. It is recommended that you practice this on a test system.

Image Files

Image files are a collection of Linux OS files needed to run in a container. They contain a directory tree like /bin/, /lib/, /usr/, /var/ and others, everything needed to run the required programs.

One popular image is BusyBox were hundreds of Linux programs such as ls, grep, find, cat are all just one binary program. This makes the image very small.

This sample project uses alpine-node, a small image with a functional NodeJS.

Building A Simple Project

Three files are included with this project.

service.js

This is a simple JavaScript to be run by NodeJS

package.json

This file tells NodeJS about the code to run.

It tells NodeJS:

• the name of the script to start
• dependencies that are needed
• how to start the script

Dockerfile

This tells Docker how to build an image that contains your project.

It tells Docker

• what image to source the build from, this one uses mhart/alpine-node
• where to install code files

The source image mhart/alpine-node is a very small Linux that includes a NodeJS service.

Building Images

On a Linux system where you have a running Docker, change to the working code directory where the Dockerfile is, then build a new image.

docker build -t <new image title> .

This will copy the mhart/alpine-node image and add the project code to it as instructed by the contents of the Dockerfile.

If your docker does not have the mhart/alpine-node image yet, the build will automatically download it. This may take extra time but after it has been downloaded, future builds will be much faster.

Running Containers

Once the image is built, it is just an image. It is not yet an instance of a container, for that it needs to be run. The container is created and initialized when it is first run.

Then run a container with this new image, this will create a new container.

docker run -d -p 3000:3000 <new image title>

The -p 3000:3000 will publish the service at port 3000 inside the container on the host OS.

The -d sets the container to run detached so it will fork to the background.

Monitoring

At this point, the docker service is running and should respond to web requests.

Open a browser to the IP address of the Linux host OS at port 3000

http://<linux>:3000

The node process can be seen running in the host OS.

From your host Linux system, run these commands.

ps -ef | grep node

netstat -naptu |grep 3000.*LISTEN

List the status of running containers

docker ps 
docker container ls

List the status of all containers.

docker ps -a
docker container ls -a

Status

Get a top like status of the running containers.

docker stats

To just get a one time report of stats.

docker stats --no-stream

Stopping Containers

Containers must be stopped before they can be deleted.

docker stop <container ID>

Re-Starting Containers

Once a container has been ran, it has been initialized and can be restarted.

docker start <container ID>

Deleting Containers

List the containers, use -a all to see the ones that are not running.

docker container ls -a

Containers must be deleted before the associated image can be deleted.

docker rm <container ID>

Deleting Images

First, list the images.

docker image ls

Then use the image name or ID to delete it.

docker rmi <image name or ID>

Get your data together!

Analyzing logs is fun, kind of like how going to the dentists is fun. You stair at lon-n-n-n-g pages of data and your brain goes numb from the overwhelming amount of information.

GBT is a Perl script that can condense and extract meaningful information from time-indexed logs and numbers. GBT is Group-By-Time and rather than have sporadic bursts of data separated by black holes of emptiness, GBT produces a consistent flow of data that is easily graphable 

GBT by default will condense data into ten minute blocks of maximum values for each column given. The size of the time block can be changed using the -t argument. The output data format can be changed to provide min, max, mean, sum, delta or count. 

The main use for GBT is to pipe data into GNU Plot to produce graphs.

GBT hosted on GitLab.com

Here is the gnuplot PNG created from the sample data.

Ooooh that shell, Can't you shell that shell

Staying up late to work on a fun project. Building a custom PXE boot image that will be used to pre-load our servers and get them ready for Puppet management. It has been about eight years since I had built a custom boot image. At that time busybox was my goto for small, powerful environments that needed to run from very small RAM mounted file systems.

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

When most distros offer boot images that do little more than boot, or fail to boot; for my systems I used busybox to create a very compact environment that would allow you to perform diagnostics and fix any problems.

As great as busybox was at the time, I found it lacked a lot of compatibilities with even old POSIX systems and scripts. Arguments that you rely on for find, grep and even ls, just were not there. Things have changed; somewhat. Busybox has grown up and is full of new abilities.

Screenshot of "make menuconf" providing the ability
to choose the features to build into the binary.

The ancestry of a process

When it comes to viewing the heritage of a process, the go-to command is pstree. By itself, pstree will show the descendant processes. Using the -s argument it will show ancestor processes. A good trick to remember is slap, pstree -slap <PID>.

I personally like the format of ps and being the kind of person that likes to come up with one line tools, I created this little snippet.

{ TPID=$$; while [[ $TPID -ne 1 ]]; do ps -f $TPID | tail -n1; TPID=$(ps h -o ppid -p $TPID); done; ps -f $TPID|tac; } | tac

Saving it to use later we get this.

#!/bin/bash

{ 
        TPID=${1:-$$}; 
        while [[ $TPID -ne 1 ]]; do 
                ps -f $TPID | tail -n1; 
                TPID=$(ps h -o ppid -p $TPID); 
        done; 
        ps -f $TPID | tac; 
} | tac

This is what the two commands output.

Jget, a simple CLI web client for testing

“Knock, knock.”
“Who’s there?”
very long pause….
“Java.”

I made this to test the way Java makes web requests. It is both simple and inefficient at being a web client.

/*  Compile
 *  javac Jget.java
 *
 *  Testing
 *  java Jget http://google.com
 */

import java.io.*; 
import java.net.*;  

public class Jget {  
 public static String getHTML(String urlToRead) throws Exception { 
  StringBuilder result = new StringBuilder(); 
  URL url = new URL(urlToRead); 
  HttpURLConnection conn = (HttpURLConnection) url.openConnection(); 
  conn.setRequestMethod("GET"); 
  BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream())); 
  String line; 
  while ((line = rd.readLine()) != null) { 
   result.append(line); 
  } 
  rd.close(); 
  return result.toString(); 
 }  

 public static void main(String[] args) throws Exception { 
  System.out.println(getHTML(args[0])); 
 } 
}

Expandable Disk Server

In my SOHO I have tried many types of storage solutions. Currently the system is a Qnap, four bay system. It's turn key, user friendly approach does make it easy to setup and use, but it's highly limited with not having a fifth drive bay. Four bays allows for two disks in RAID-1 or one big disk in RAID-10, not having a fifth bay prevents upgrading to larger disks, without fronting the cash to buy an entire new system and disks all at once.

It's time for a storage solution that can grow over time, not only to replace smaller disk but to allow for the system to start with just one disk and add to the cluster over the next few month.

Looking at using FreeNAS to manage a NAS server built from a Linux box. This will not be a dedicated box, so I will be building a Proxmox and hosting the FreeNAS as a VM inside the Proxmox. The FreeNAS needs to grow as new disks are added so it will be using the disks as an NFS share from Proxmox.

The plan is to use Wester Digital 12TB disks, as these disks are almost $700 each, only one disk will be added to the system every two weeks over the next two months.

Building the disk array will use Linux software RAID-1, LVM, and XFS.

RAID-1
This level of RAID is for redundancy, all disks in the RAID are kept identical. When one disk fails the file system continues to work.

LVM
LVM visualises the block layer of block devices. This is a powerful tool for manipulating block devices on a running system. LVM does have builtin support for mirroring and RAID, including RAID-1 and RAID-10, but happens at the logical volume layer and using these would prevent the migration to larger disks.

XFS
This file system allows for growing live without the need to format or reboot the system.

To test this plan, and demonstrate how this will work, VMware running Fedora 27 was used. The images used a 8GB SCSI for the root file system. The disks in the cluster are SATA and are marked a through f.

In this example the commands used create Physical Volumes with names that match the RAID-1 device, while the images show the Physical Volumes with PV names.

Step 1 Create a new RAID-1
mdadm --create /dev/md0 --run --level=1 --raid-devices=2 /dev/sda missing

Step 2 Create a new physical volume
pvcreate /dev/md0

Step 3 Create a new volume group
vgcreate vg0 /dev/md0

Step 4 Create a new logical volume
lvcreate -l 100%VG -n lv0 vg0

Step 5 Create the XFS
mkfs.xfs /dev/vg0/lv0
mkdir /xfs0
mount /dev/vg0/lv0 /xfs0/

Step 6 Add another disk to the RAID
mdadm --add /dev/md0 /dev/sdb

Step 7 Create a new RAID-1
mdadm --create /dev/md1 --run --level=1 --raid-devices=2 /dev/sdc missing

Step 8 Create a new physical volume
pvcreate /dev/md1

Step 9 Grow the existing volume group
vgextend vg0 /dev/md1

Step 10 Grow the existing logical volume
lvextend -l 100%VG vg0/lv0

Step 11 Grow the existing XFS live
xfs_growfs /xfs0/

Add the last disk the same way as Step 6.



Expand the disk cluster by adding new PVs and migrating

Step 12 Create the new RAID and PV
mdadm --create /dev/md2 --run --level=1 --raid-devices=2 /dev/sd/ missing
pvcreate /dev/md2

Step 13 Extend the volume group to include the new PV
vgextend vg0 /dev/md2

Step 14 Move all blocks from the old PV to the new PV.
pvmove /dev/md0 /dev/md2

Step 15 Remove the first PV.
vgreduce vg0 /dev/md0

Step 16 Grow the logial volume again
lvextend -l 100%VG vg0/lv0

Step 17 Re-grow the existing XFS live
xfs_growfs /xfs0/

Now on GitLab.com

You can now download all the code from GitLab.com

git clone git@gitlab.com:SiliconTao-open-source/linux-code-snippets.git

Host your projects on GitLab.com