This document provides an overview and demo of a Docker voting application composed of multiple microservices including an API, worker, queue, and database. The application is deployed using Docker Compose and demonstrates running tests and the application locally. It also shows deploying the application to AWS ECS using Fargate and calling the voting APIs through the ECS load balancer. The presentation introduces cloud native patterns and orchestration that could be explored further with the application.

1. 1
Docker Voting App
Orientation
March 15, 2018
Tony Pujals
tpujals@gmail.com
@tonypujals

2. Overview and quick demo
Overview of the Voting App architecture
Orientation to the repo
Running tests
Running the app
Showcase cloud deployment to ECS with Fargate
2

3. ● Based on the original Docker Voting App
○ This version is all Node.js
○ Foundation for a Docker Course being prepared for UC Davis / Coursera
● Represents a typical application with a number of services
○ API
○ Worker
○ Queue
○ Database
● Will evolve to showcase emerging Cloud Native patterns
3

4. 4

5. 5

6. 6

7. 7

8. 1. Clone the repo
$ git clone git@github.com:subfuzion/docker-voting-app-nodejs
2. Start the app
$ docker-compose up
3. Run vote client commands
$ docker run -it --rm --network=host subfuzion/voter vote
$ docker run -it --rm --network=host subfuzion/voter results
8

9. 9

10. 10
Services
Vote Client
Database
Vote API
Queue Worker

11. 11
Client
Cast votes and query voting results
API
Serves REST API, pushes votes to queue, queries database
Worker
Pops votes from queue for processing
Queue
In-memory message queue (Redis)
Database
Queries and persistent storage

12. 12

13. 13
Node library package for
storing votes and querying
vote results from MongoDB

14. 14
Node library package for
pushing and popping votes
from a Redis queue

15. 15
Node application that processes
votes.
It uses the queue package to pull
votes from Redis.
It uses the database package to
store votes in MongoDB.

16. 16
Node application that serves the
REST API for the Voting App.
It uses the queue package to
push votes to Redis.
It uses the database package to
query voting results.

17. 17
Node application that provides a
command-line interface (CLI) for
vote commands.
It communicates with the Voting
App (vote) over the REST API.

18. 18
Both the database and the queue packages
assume default values for connecting to
MongoDB and Redis, respectively.

19. 19
And the database and queue packages both provide
helper methods that will create a configuration that
can be overridden using environment variables for the
uri or host and port values.

20. 20
Here you can see the vote api application using the
database and queue package helper methods to get the
current configuration.

21. 21
The database and queue configuration objects are then
used to create new Database and Queue instances
properly configured to connect to MongoDB and Redis,
respectively.

22. 22
Both the database and queue packages use an exponential backoff with random
jitter for connection retries.
This improves reliability and can help improve the performance of your container
orchestration environment by not exiting with an unhealthy status too soon while
service dependencies are starting.

23. 23

24. 24
The worker test (1) pushes votes to the queue, (2) gives the worker some
time to process, and (3) verifies the database returns expected results.
1
2
3

25. 25
This docker-compose file sets
up the environment and runs
our test.
Note that the test (sut) and the
worker leverage the same
image, but run in their own
containers.

26. 26

27. 27

28. 28
The vote test is similar to the
worker test, except now we
invoke the API to (1) post votes
and (2) query results.
1
2

29. 29
This docker-compose file is
similar to the one for worker,
except now (1) we add the vote
service and indicate that it
depends on worker.
Then we update the test (sut) to
depend on vote.
1
2

30. 30

31. 31

32. 32

33. 33

34. 34

35. 35
The CLI defaults to localhost:3000.

36. 36

37. 37
We were able to test at localhost:3000
because we published the container
port to the host.
We can use host port 3000 to access
the process bound to port 3000 inside
the container.
HOST:CONTAINER

38. 38
Voted for cats...

39. 39
And we can get the results.

40. 40
You can view the logs for a subset of all the services.

41. 41
And you can follow (tail) the logs.

42. 42

43. 43

44. 44
Or yarn?
Or the right versions?

45. 45
For our final build stage, we use a
lightweight base image.

46. 46

47. 47
network is set to host so that we have access to
port 3000 on it.

48. 48

49. 49
We can attach to the network used by
the API so that we can connect to it by
name.

50. 50
We need the names that docker-compose created
for (1) the network and the (2) vote container
1
2

51. 51
$ docker run -it --network={network} VOTE_API_HOST={ctr} voter vote

52. 52

53. 53

54. 54

55. 55
$ aws ecr get-login --no-include-email --region us-east-1
Copy and paste the login command that the aws ecs command prints so
Docker can push to the ECR registry.
As the article points out, this is not really the recommended practice. It is
expedient for the demo, however.

56. 56
Once you’ve deployed the application using the
instructions from the article, you can obtain the
public URL for the CloudFormation voteapp
stack.

57. 57
# save the external URL obtained in the previous step
$ VOTEAPI=http://{vote-app-external-url}.us-east-1.elb.amazonaws.com
# make it easy to run the voter app
$ alias voter=”docker run -it --rm -e VOTE_API_URI=$VOTEAPI
subfuzion/voter
# run the vote and results commands in ECS!
$ voter vote

58. ● Health checks
● Orchestration (Swarm, Kubernetes)
● Observability
● Networking
● Rolling updates, canary deployments
● Evolve to microservices / serverless / service mesh
● More recipes (EKS, etc)
58

59. 59
Questions?
https://github.com/subfuzion/docker-voting-app-nodejs
March 15, 2018
Tony Pujals
tpujals@gmail.com
@tonypujals (open to direct messages, but appreciate the follow!)