Piling up containers

Modern systems are usually built as stacks made up of multiple components that are distributed over networks, such as application servers, caches, databases, and message queues. Each individual component is also a self-contained system with many sub-components. What's more, the rising trend of microservices introduces additional degrees of complexity into these entangled relationships between systems. Because of this, even though container technology gives us a certain degree of relief regarding deployment tasks, coordinating components in a system is still difficult.

Let's say we have a simple application called kiosk, which connects to a redis to manage how many tickets we currently have. Once a ticket is sold, it publishes an event through a redis channel. The recorder subscribes the redis channel and writes a timestamp log into a MySQL database upon receiving any event.

For the kiosk and the recorder, you can find the code as well as their Dockerfiles here: https://github.com/PacktPublishing/DevOps-with-Kubernetes-Second-Edition/tree/master/chapter2. The architecture is as follows:

We know how to start those containers separately and connect them with each other. Based on what we've discussed before, we would first create a bridge network and run the containers inside:

$ docker network create kiosk
$ docker run -d --network-alias lcredis --network=kiosk redis
$ docker run -d --network-alias lmysql -e MYSQL_ROOT_PASSWORD=$MYPS \
                --network=kiosk mysql:5.7
$ docker run -d -p 5000:5000 \
                -e REDIS_HOST=lcredis --network=kiosk kiosk-example
$ docker run -d -e REDIS_HOST=lcredis -e MYSQL_HOST=lmysql      \
                -e MYSQL_ROOT_PASSWORD=$MYPS -e MYSQL_USER=root \
                --network=kiosk recorder-example

Because our kiosk and recorder are much lighter than the database, our applications are very likely to start up earlier than the database's. In this case, our kiosk might fail if any incoming connection requests changes to the databases or to Redis. In other words, we have to consider the startup order in our startup scripts. We also have to deal with problems such as how to deal with random components crashing, how to manage variables, how to scale out certain components, and how to manage the states of every moving part.