github/container.training

Fork 0

mirror of https://github.com/jpetazzo/container.training.git synced 2026-05-13 04:16:34 +00:00

Files

Bridget Kromhout 388d616048 Attributing humor so it doesn't sound negative

2018-02-27 13:46:19 -06:00

7.3 KiB

Raw Blame History

Our sample application

Visit the GitHub repository with all the materials of this workshop:
https://github.com/jpetazzo/container.training
The application is in the dockercoins subdirectory
Let's look at the general layout of the source code:

there is a Compose file docker-compose.yml ...

... and 4 other services, each in its own directory:
- rng = web service generating random bytes
- hasher = web service computing hash of POSTed data
- worker = background process using rng and hasher
- webui = web interface to watch progress

Compose file format version

Particularly relevant if you have used Compose before...

Compose 1.6 introduced support for a new Compose file format (aka "v2")
Services are no longer at the top level, but under a services section
There has to be a version key at the top level, with value "2" (as a string, not an integer)
Containers are placed on a dedicated network, making links unnecessary
There are other minor differences, but upgrade is easy and straightforward

Links, naming, and service discovery

Containers can have network aliases (resolvable through DNS)
Compose file version 2+ makes each container reachable through its service name
Compose file version 1 did require "links" sections
Our code can connect to services using their short name

(instead of e.g. IP address or FQDN)
Network aliases are automatically namespaced

(i.e. you can have multiple apps declaring and using a service named database)

Example in `worker/worker.py`

redis = Redis("`redis`")


def get_random_bytes():
    r = requests.get("http://`rng`/32")
    return r.content


def hash_bytes(data):
    r = requests.post("http://`hasher`/",
                      data=data,
                      headers={"Content-Type": "application/octet-stream"})

(Full source code available here)

What's this application?

It is a DockerCoin miner! .emoji[💰🐳📦🚢]

No, you can't buy coffee with DockerCoins

How DockerCoins works:
- worker asks to rng to generate a few random bytes
- worker feeds these bytes into hasher
- and repeat forever!
- every second, worker updates redis to indicate how many loops were done
- webui queries redis, and computes and exposes "hashing speed" in your browser

Getting the application source code

We will clone the GitHub repository
The repository also contains scripts and tools that we will use through the workshop

Clone the repository on node1:

git clone git://github.com/jpetazzo/container.training

]

(You can also fork the repository on GitHub and clone your fork if you prefer that.)

Running the application

Without further ado, let's start our application.

Go to the dockercoins directory, in the cloned repo:
```
cd ~/container.training/dockercoins
```
Use Compose to build and run all containers:
```
docker-compose up
```

]

Compose tells Docker to build all container images (pulling the corresponding base images), then starts all containers, and displays aggregated logs.

Lots of logs

The application continuously generates logs
We can see the worker service making requests to rng and hasher
Let's put that in the background

Stop the application by hitting ^C

]

^C stops all containers by sending them the TERM signal
Some containers exit immediately, others take longer
(because they don't handle SIGTERM and end up being killed after a 10s timeout)

Restarting in the background

Many flags and commands of Compose are modeled after those of docker

Start the app in the background with the -d option:
```
docker-compose up -d
```
Check that our app is running with the ps command:
```
docker-compose ps
```

]

docker-compose ps also shows the ports exposed by the application.

Viewing logs

The docker-compose logs command works like docker logs

View all logs since container creation and exit when done:
```
docker-compose logs
```
Stream container logs, starting at the last 10 lines for each container:
```
docker-compose logs --tail 10 --follow
```

]

Tip: use ^S and ^Q to pause/resume log output.

Upgrading from Compose 1.6

Up to 1.6
- docker-compose logs is the equivalent of logs --follow
- docker-compose logs must be restarted if containers are added
Since 1.7
- --follow must be specified explicitly
- new containers are automatically picked up by docker-compose logs

Connecting to the web UI

The webui container exposes a web dashboard; let's view it

With a web browser, connect to node1 on port 8000
Remember: the nodeX aliases are valid only on the nodes themselves
In your browser, you need to enter the IP address of your node

]

A drawing area should show up, and after a few seconds, a blue graph will appear.

If the graph doesn't load

If you just see a Page not found error, it might be because your Docker Engine is running on a different machine. This can be the case if:

you are using the Docker Toolbox
you are using a VM (local or remote) created with Docker Machine
you are controlling a remote Docker Engine

When you run DockerCoins in development mode, the web UI static files are mapped to the container using a volume. Alas, volumes can only work on a local environment, or when using Docker4Mac or Docker4Windows.

How to fix this?

Edit dockercoins.yml and comment out the volumes section, and try again.

Why does the speed seem irregular?

It looks like the speed is approximately 4 hashes/second
Or more precisely: 4 hashes/second, with regular dips down to zero
Why?

The app actually has a constant, steady speed: 3.33 hashes/second
(which corresponds to 1 hash every 0.3 seconds, for reasons)
Yes, and?

The reason why this graph is not awesome

The worker doesn't update the counter after every loop, but up to once per second
The speed is computed by the browser, checking the counter about once per second
Between two consecutive updates, the counter will increase either by 4, or by 0
The perceived speed will therefore be 4 - 4 - 4 - 0 - 4 - 4 - 0 etc.
What can we conclude from this?

"I'm clearly incapable of writing good frontend code!"😀 --Jérôme

7.3 KiB Raw Blame History