Docker on Deb Cheatsheet

getting help
$ docker --help

what images are running right now. related to docker run
$ docker stats

what containers are running. related to docker start
$ docker ps

Clean up exited containers

$ docker rm -v $(docker ps -a -q -f status=exited)

All

$ docker stop $(docker ps -a -q);docker rm $(docker ps -a -q)

make sure docker service starts (two ways to do it, or use a daemon)
$ sudo service docker start
$ sudo chkconfig docker on

what images can I start right now
$ docker images

Repo of <none> is an intermediate image that can optionally be discarded with a runtime flag.

is the last run container still up
docker inspect --format '{{.State.Running}}' $(docker ps -lq)

Clean up images
$ docker rmi  651505724f29

Start a container from an image
docker start <image>

start an instance of a container by name instead of guid
this will immediately terminate if there is not a foreground process running
this will keep a terminal running

$ docker run <REPO>:<TAG>

start an instance of a container as a daemon and keep a running fg process
the tail of dev null keeps docker alive
docker run -d 09c51b079466 tail -f /dev/null

start an instance of a container with a term running for commands
docker run -t 09c51b079466 bash

using tail -f /dev/null with the daemon option is a work around if you do not have a script  initializing your application as your initial starting point that runs its own  make your container continuously running is point to a shell file in docker which will keep your application running. You can try with a start.sh file

Eg: docker run -d centos sh /yourlocation/start.sh

This start.sh should point to a never ending application.
In case if you dont want any application to be running,
you can install monit which will keep your docker container running.


Access a running container
this uses the cute name. you can also trap the container id at run 
docker exec infallible_newton ls -l|grep u*

this uses the id from variable
docker exec $RABCID ls -l|grep u*


details on a container
$ docker inspect 09c51b079466

find your ip
$ CIP=$(docker inspect 09c51b079466 | grep IPAddress| grep 172| head -1)
$ $CIP

Capture your container id as a variable
RABCID=$(docker run -d rabbitmq:3-management); docker inspect $RABCID  | grep IPAddress| grep 172| head -1


networking
docker network ls ; ifconfig
docker inpsect rtinet

Below shows two ways to join a network. First adds the network at run
#!/usr/bin/env bash
docker rm rti-rabbit -f
docker network create rtinet
docker run -d --network rtinet --hostname rabbit1 --name rti-rabbit -p 15672:15672 -p 4369:4369 -p 5671:5671 -p 5672:5672 rabbitmq:3-management

Second connects after run
DMDCID=$(docker run -d dynamicmessagediscovery:0.1-SNAPSHOT tail -f /dev/null);
DMDIP=$(docker inspect $DMDCID  | grep IPAddress| grep 172| head -1)
docker network connect rtinet $DMDCID


view logs
$ docker logs f69d53c188af

Is an instance of my container running
$ docker ps -a | grep -i 09c51b079466

Sample Startup Script
docker stop $(docker ps -a -q) 
docker rm rti-rabbit -f
docker rm dmdhost -f
docker rm pghost -f
docker network rm rtinet
docker network create rtinet
RABCID=$(docker run -d --network rtinet --hostname rabbit1 --name rti-rabbit -p 15672:15672 -p 4369:4369 -p 5671:5671 -p 5672:5672 rabbitmq:3-management)
DMDCID=$(docker run -d --network rtinet --hostname dmdhost --name dmdhost -p 15200:15672 -p 15201:4369 -p 15202:5671 -p 15203:5672 dynamicmessagediscovery:0.1-SNAPSHOT tail -f /dev/null);
PGCID=$(docker run -d --network rtinet --hostname pghost --name pghost -p 5432:5432 postgres)

DMDIP=$(docker inspect $DMDCID | grep IPAddress| grep 172| head -1)
RABIP=$(docker inspect $RABCID | grep IPAddress| grep 172| head -1)
PGIP=$(docker inspect  $PGCID  | grep IPAddress| grep 172| head -1)

firefox -new-tab "http://$RABIP:15672/#/queues/"


sbt test stage deploy and start
$ sbt test stage docker:publishLocal; CID=$(docker run -d dynamicmessagediscovery:0.1-SNAPSHOT tail -f /dev/null);docker inspect $CID | grep IPAddress | grep 127|head -1

<> run runs an image
<> start starts a container.
<> exec accesses a running container

To make a daemon (bg process)
/usr/local/bin/confd -interval=30 -backend etcd -node $CONFIG_CENTER &

1. A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. The word daemon for denoting a background program is from the Unix culture; it is not universal.
2. A server is a program which responds to requests from other programs over some inter-process communication mechanism (usually over a network). A service is what a server provides. For example, the NFS port mapping service is provided as a separate portmap server, which is implemented as the portmapd daemon.
   A server doesn't have to be a daemon, but usually is. A user application with a GUI could have a server built into it: for instance, a file-sharing application. Another example is the X Window server, which is anything but in the background: it takes over your screen, keyboard and pointing device. It is a server because it responds to requests from applications (to create and manipulate windows, et cetera), which can even be elsewhere on the network. But the X server also responds to your every keystroke and mouse movement.
3. A process is one or more threads of execution together with their shared set of resources, the most important of which are the address space and open file descriptors. A process creates an environment for these threads of execution which looks like they have an entire machine all to themselves: it is a virtual machine.
   Inside a process, the resources of other processes, and of the kernel, are invisible and not directly accessible (at least not to a thread which is executing user-space code). For example, there is no way to refer to the open files of another process, or their memory space; it is as if those things do not even exist.
   The process, and its relation to the kernel and other processes, perhaps constitutes the most important abstraction in Unix-like operating systems. The resources of the system are compartmentalized into processes, and nearly everything is understood as happening inside one process or another.

https://github.com/wsargent/docker-cheat-sheet