Unicorn Manager

Favoring a message queuing system over a traditional REST API, this unicorn manager is built with RabbitMQ and the amqplib client in Node.js. The application runs on a set of Docker containers that act as separate actors in a private network.

Contents

Prerequisites
Quickstart
Advanced Usage
Helper Scripts

Prerequisites

Docker must be installed on your host machine.

If you are using a Windows 10 machine, Hyper-V must be enabled.

Quickstart

The most common actions necessary to interact with this app are included in helper scripts, to help you get started quickly.

1) Pull and build the Docker images: ./scripts/build.sh

2) Launch the containers: ./scripts/run.sh

The server and consumer process is up and running and the app is now ready to receive messages.

3) Add a Unicorn to the pasture: ./scripts/publisher.sh add Bill pasture

4) See Bill in the pasture: ./scripts/publisher.sh see

5) Use Bill's ID number to move him to the barn: ./scripts/publisher.sh move 1 barn

6) Verify Bill is now safely in the barn: ./scripts/publisher.js see

7) Kill Bill (and the whole application): ./scripts/kill.sh

Advanced Usage

Helper Scripts

There are several bash scripts which help simplify execution of the most common tasks.

build.sh

Uses the docker-compose file to build the Docker images from their corresponding dockerfiles.

Accepts one argument, designating which service's image to build. Builds all of them if no arguments are passed.

Also accepts service names with the "rabbitmq_" prefix removed.

Example:
./scripts/build.sh rabbitmq_publisher

run.sh

Creates (if necessary) and runs the Docker containers for the services specified in the docker-compose.yml file.

Accepts one argument, designating which service's container to run. Runs them all except for the testing container, if no arguments are passed.

Also accepts service names with the "rabbitmq_" prefix removed.

Example:
./scripts/run.sh rabbitmq_publisher

kill.sh

Destroys all of the Docker containers.

Does not accept any arguments

Example:
`./scripts/kill.sh

enter.sh

Launches a shell inside the designated container. The container must already be up and running.

Accepts one required argument, designating which service's container to launch the shell inside of.

Also accepts service names with the "rabbitmq_" prefix removed.

Example:
./scripts/enter.sh rabbitmq_consumer

consumer.sh

Manually starts the consumer container's watch process to monitor the message queues. This process is automatically started anytime the helper scripts are used to start the container. Therefore, this script is mainly used when the consumer process dies.

Accepts one argument which, if any truthy value, will run the consumer process in a detached state. By default, runs the process in the foreground.

Example:
./scripts/consumer.sh -d

publisher.sh

Sends messages to the RabbitMQ server queues, which will eventually get processed by the consumer. Each command designates an action, which is always one of ADD, MOVE, or SEE.

  • ADD inserts a new unicorn into the database, at a specific location.
  • MOVE moves an existing unicorn (designated by ID number) to a different location.
  • SEE returns all information about all the unicorns. This is where you can find a unicorn's ID number, which is necessary for the MOVE action.

Accepts one required argument and up to two optional arguments.

  • First argument (required):
    • Specifies which action is to be performed. Must be one of: SEE, ADD, or MOVE (case-insensitive).
  • Second argument:
    • If the action is ADD, this is the name of the unicorn to be added.
    • If the action is MOVE, this is the ID number of the unicorn to be moved.
  • Third argument:
    • This is the location to ADD or MOVE the unicorn to (case-insensitive).

Examples:
./scripts/publisher.sh add Bill pasture
./scripts/publisher.sh move 13 corral
./scripts/publisher.sh see

mocha.sh

Mocha.js is the name of the testing framework used for this project. This helper script executes all of the tests by launching a temporary container which the testing framework is already configured to run in. If you'd like to keep the container alive to interact with it, use the run.sh helper script, like so: ./scripts/run.sh tester.

Does not accept any arguments.

Example:
./scripts/mocha.sh