Tanked Server Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Infrastructure: Container ======

===== Introduction =====

General use of docker (see the [project page [[https://www.docker.com/|https://www.docker.com/]]])

  - define and build an **image**
  - launch individual **containers **based off that image - there could be several containers running off one image.

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/|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.

===== Infrastructure =====

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.

===== Examples =====

See [[https://trac.x0blr.com/hal/wiki/Pulled/Built|Pulled/Built?]] Images
<code>

''docker images''

</code>

See running containers

<code>
''docker ps''

</code>

See running and stopped containers

<code>
docker ps -a

</code>

See logging from container

<code>
docker log <container>

</code>

Tail logs from container

<code>
docker log –follow <container>

</code>

See the full detail of a container

<code>
docker inspect <container>

</code>

List docker networks

<code>
docker network ls

</code>

Inspect a network

<code>
docker network inspect <network name>

</code>

See the systemd file we use to launch the container

<code>
systemctl cat <name>.service

</code>

Enter an image (similar i guess to chroot) except all changes are lost

<code>
docker exec -it <container> <shell executable>

</code>

Run a command (e.g.: "apt-get install unrar") in the container (tombstones):

<code>
docker exec tombstones apt-get install unrar

</code>

<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>

===== Composer =====

We are currently using systemd to launch and manage docker container, composer is generally the recommended approach and needs to be reviewed.

===== Firewall =====

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

===== References =====

  * [[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/index|https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/index]]
  * [[https://docs.docker.com/engine/reference/commandline/network_create/|https://docs.docker.com/engine/reference/commandline/network_create/]]
  * [[https://youtu.be/rfjmeakbeH8?t=428|https://youtu.be/rfjmeakbeH8?t=428]]

===== FAQ =====

  * //Q: does HAL run a VM (TUPPER) that is has docker installed that houses the (running) container?//
Yes TUPPER is VM running on HAL, Docker is installed and running TUPPER. Docker then runs containers from images.

  * //Q: How does someone connect to TUPPER?//
The standard way you connect to any VM on HAL. ssh user on the applicable port.

  * //Q: how often is the container restarted/rebuilt?//
On demand

  * //Q: Is the ephemeral aspect to discourage long-term changes within the container but do them to the image instead?//
You do not make changes within a container unless you want them to be lost. Containers are //runtime//  objects

  * //Q: is this the only use of tags? Are they simply a label for identification, or do they serve any functional purpose?//
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.

  * //Containers should log to stdout. //Q: how? why? Does this mean code running within the docker can't log to its own logfiles?
      * This needed 3 Qs.
        * How? - depends on the app.
        * Why? - containers are temporary runtime space
        * Does this mean? - Docker can do anything a linux system can, some practices will be a wasted effort. see answer to Why?.