General use of docker (see the [project page https://www.docker.com/])
Containers are a runtime version of the image and are intended to be ephemeral.
Docker also implements tags which can be used to identify the type and/or version of images. This can be useful for testing changes to an image before launching an active container for production use.
We [tombstones] generally launch containers as a 1:1 relationship (each image having only one running container) but this is not mandatory. If you wanted to test changes you can "build and tag" the image
Containers should log to stdout (see the [project page https://www.docker.com/]). stdout pushes to docker logs, containers are intended to be ephemeral therefore any containers using internal logging can be thought as them logging into /tmp (lost on reboot)
Containers should not fork their process or the container will die.
You can mount in a hosts' file(s) (e.g. ssl certs) or persistent storage (e.g. /var/lib/data) in either :ro or :rw modes to ensure data isn't lost between containers launches/updates. This means that files from the machine hosting docker are accessible within the containers running on docker, it is one way to share and/or store data.
Environment variables can be set and passed to the container to modify its behaviour to suit the deployment providing the image was built to support such things. Environment variables are set using the -e switch with docker run or through an environment file.
Docker is run on TUPPER.
Nothing on the host VM is available to the container unless its explicitly passed through. Be cautious of what is passed through as exploits within a container can chain back up to the host.
Containers run as root by default then switch to a named user as part of the docker environment definition.
Volumes are used for data persistence, so transient content created/manipulated within the container won't be lost when the container is destroyed.
See Pulled/Built? Images
''docker images''
See running containers
''docker ps''
See running and stopped containers
docker ps -a
See logging from container
docker log <container>
Tail logs from container
docker log –follow <container>
See the full detail of a container
docker inspect <container>
List docker networks
docker network ls
Inspect a network
docker network inspect <network name>
See the systemd file we use to launch the container
systemctl cat <name>.service
Enter an image (similar i guess to chroot) except all changes are lost
docker exec -it <container> <shell executable>
Run a command (e.g.: "apt-get install unrar") in the container (tombstones):
docker exec tombstones apt-get install unrar
<blockquote>
Note: this change won't survive the container being destroyed, so the change needs to be built into the image for it to be persistent (create in the container will be runtime-only; configure it in the image makes it permanent)
</blockquote>
We are currently using systemd to launch and manage docker container, composer is generally the recommended approach and needs to be reviewed.
By default Docker injects its own chains into the netfilter tables and allows access to all its services providing a port mapping is passed at container launch
If you want to restrict or manipulate traffic this is done in the DOCKER-USER chain
Yes TUPPER is VM running on HAL, Docker is installed and running TUPPER. Docker then runs containers from images.
The standard way you connect to any VM on HAL. ssh user on the applicable port.
On demand
You do not make changes within a container unless you want them to be lost. Containers are runtime objects
They are for identification/revision control purposes only. e.g. if you want to test changes to an image, build and tag the image then launch containers from the test image.