{"id":13624325,"url":"https://github.com/docker-production-aws/microtrader","last_synced_at":"2025-10-07T12:03:32.403Z","repository":{"id":176593212,"uuid":"73174255","full_name":"docker-production-aws/microtrader","owner":"docker-production-aws","description":"A fictitious stock trading microtrader application","archived":false,"fork":false,"pushed_at":"2019-09-18T11:19:53.000Z","size":282,"stargazers_count":66,"open_issues_count":2,"forks_count":512,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-05-26T00:06:23.343Z","etag":null,"topics":["aws","docker","docker-compose","java","microservices","pluralsight","service-discovery","vertx","workflow"],"latest_commit_sha":null,"homepage":null,"language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/docker-production-aws.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2016-11-08T10:16:52.000Z","updated_at":"2024-10-06T04:26:30.000Z","dependencies_parsed_at":null,"dependency_job_id":"5868c7a8-17e0-4c3c-aaf2-dfabfe2a60f0","html_url":"https://github.com/docker-production-aws/microtrader","commit_stats":null,"previous_names":["docker-production-aws/microtrader"],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/docker-production-aws/microtrader","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-production-aws%2Fmicrotrader","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-production-aws%2Fmicrotrader/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-production-aws%2Fmicrotrader/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-production-aws%2Fmicrotrader/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/docker-production-aws","download_url":"https://codeload.github.com/docker-production-aws/microtrader/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-production-aws%2Fmicrotrader/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":278770726,"owners_count":26042828,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-07T02:00:06.786Z","response_time":59,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","docker","docker-compose","java","microservices","pluralsight","service-discovery","vertx","workflow"],"created_at":"2024-08-01T21:01:41.357Z","updated_at":"2025-10-07T12:03:32.371Z","avatar_url":"https://github.com/docker-production-aws.png","language":"Java","funding_links":[],"categories":["Java"],"sub_categories":[],"readme":"# Docker in Production using AWS - Microtrader Application\n\nThis is the sample application for the Pluralsight course Docker in Production using AWS.\n\nThe application is based upon the excellent [Vert.x Microservices Workshop](https://github.com/cescoffier/vertx-microservices-workshop), although a number of modifications have been made as outlined below:\n\n- Full continuous delivery workflow using Docker (based upon my course [Continuous Delivery using Docker and Ansible](https://www.pluralsight.com/courses/docker-ansible-continuous-delivery))\n- Use of Gradle as the multi-project build tool.\n- Use of the [Typesafe config library](https://github.com/typesafehub/config) for friendlier 12-factor environment variable based configuration support.\n- Use of [Flyway](https://flywaydb.org) for lightweight database migrations\n- Some of the individual microservices have been refactored to be more resilient to failure\n- Addition of unit/integration tests and acceptance tests\n\n## Contents\n\n- [Application Architecture](#application-architecture)\n- [Quick Start](#quick-start)\n- [Docker Workflow](#docker-workflow)\n- [Environment Configuration Settings](#environment-configuration-settings)\n- [Branches](#branches)\n- [Repository Timeline](#repository-timeline)\n- [Errata](#errata)\n\n## Application Architecture\n\nThe application consists of four Microservices that collectively comprise a simple fictitious stock trading application:\n\n- [Quote Generator](./microtrader-quote) - periodically generates stock market quotes for three fictitious companies\n- [Portfolio Service](./microtrader-portfolio) - trades stocks starting from an initial portfolio of $10000 cash on hand. The trading logic is completely random and non-sensical.\n- [Audit Service](./microtrader-audit) - audits all stock trading activity, persisting each stock trade to a database\n- [Trader Dashboard](./microtrader-dashboard) - provides a web dashboard displaying stock market quote activity, recent stock trades and the current state of the portfolio. The dashboard also provides an operational view of the status and service discovery inforamtion for each service.\n\nThe application demonstrates several key features of a Microservices architecture and the underlying [Vert.x](http://vertx.io) toolkit that powers the application:\n\n- [Distributed event bus](http://vertx.io/docs/vertx-core/java/#event_bus) - Vert.x supports an asynchronous message driven architecture, with support for common patterns including publish/subscribe, point-to-point, request-response and service proxy RPC messaging.\n- [SockJS event bus bridge](http://vertx.io/docs/vertx-web/java/#_sockjs_event_bus_bridge) - this feature allows the event bus to be extended in a secure and controlled fashion to web clients via websockets using the SockJS JavaScript client library. This provides the ability to create real-time web applications and message client endpoints directly if appropriate.\n- [Service discovery](http://vertx.io/docs/vertx-service-discovery/java/) - allows Microservices to discover, locate and interact with other services. Vert.x includes a simple distributed map structure to store service discovery, however this can be replaced with several popular backends such as Consul and Kubernetes.\n- [Circuit breaker pattern](http://vertx.io/docs/vertx-circuit-breaker/java/) - this is a core pattern for larger Microservices architectures that helps prevent cascading failures and handle failures gracefully.\n- [Multi reactor pattern](http://vertx.io/docs/vertx-core/java/#_reactor_and_multi_reactor) - Vert.x provides a lightweight and highly performant event loop based scheduling algorithm allowing applications written in an asynchronous, non-blocking manner to scale considerably greater than traditional application architectures. The Vert.x programming model provides the simplicity of single threaded development for each deployable unit of code, but schedules each deployable unit of code across all available processor cores for maximum concurrency.\n\n## Quick Start\n\n### Building the Application Locally\n\nBefore building and running the application locally, your system must have the following prerequisites installed:\n\n- Java JDK 8\n- NodeJS 4.x or higher (to install the `npm` package manager)\n- Bower (`npm install -g bower`)\n\nYou first need to build \"fat\" jars for each Microservice, using the Gradle shadowJar plugin as shown below:\n\n```\n$ ./gradlew clean test shadowJar\n...\n...\n:clean\n:microtrader-audit:clean\n:microtrader-common:clean\n:microtrader-dashboard:clean\n:microtrader-portfolio:clean\n:microtrader-quote:clean\n...\n...\ncom.pluralsight.dockerproductionaws.audit.AuditVerticleTest \u003e testStockTradesPersisted PASSED\ncom.pluralsight.dockerproductionaws.audit.AuditVerticleTest \u003e testStockTradesAudited PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceBuyTest \u003e testBuy PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceBuyTest \u003e testBuyNotEnoughCash PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceBuyTest \u003e testBuyNegativeStocks PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceBuyTest \u003e testBuyNotEnoughStocks PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceSellTest \u003e testSellNotEnoughStocks PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceSellTest \u003e testSell PASSED\ncom.pluralsight.dockerproductionaws.portfolio.PortfolioServiceSellTest \u003e testSellNegativeStocks PASSED\ncom.pluralsight.dockerproductionaws.traderdashboard.DashboardVerticleTest \u003e testQuoteEvent PASSED\ncom.pluralsight.dockerproductionaws.quotegenerator.MarketDataVerticleTest \u003e testComputation PASSED\ncom.pluralsight.dockerproductionaws.quotegenerator.MarketDataVerticleTest \u003e testMarketData PASSED\n...\n...\n:shadowJar\n:microtrader-audit:shadowJar\n:microtrader-common:shadowJar\n:microtrader-dashboard:shadowJar\n:microtrader-portfolio:shadowJar\n:microtrader-quote:shadowJar\n\nBUILD SUCCESSFUL\n```\n\nThis will output \"fat\" jars to the `build/jars/` folder as demonstrated below:\n\n```\n$ ls build/jars/\n\n18 Oct 19:59 microtrader-audit-20161018004318.d4ce05e-fat.jar\n18 Oct 19:59 microtrader-dashboard-20161018004318.d4ce05e-fat.jar\n18 Oct 19:59 microtrader-portfolio-20161018004318.d4ce05e-fat.jar\n18 Oct 20:00 microtrader-quote-20161018004318.d4ce05e-fat.jar\n```\n\n### Application Versioning\n\nThe application uses a simple versioning scheme for all components:\n\n `\u003cgit-commit-timestamp\u003e.\u003cgit-commit-short-hash\u003e`\n\nYou can use the `make version` command to view the current version. The versioning scheme also appends a build identifier if the `BUILD_ID` environment variable is set:\n\n```\n$ make version\n20161018004318.d4ce05e\n\n$ export BUILD_ID=1234\n$ make version\n20161018004318.d4ce05e.1234\n```\n\n### Running the Application Locally\n\nTo run the application locally, first execute audit database migrations as demonstrated below to create the initial DB schema. \n\nLocally this will use HSQL and write to audit-db.* files in the project root:\n\n```\n$ java -cp build/jars/microtrader-audit-20161018004318.d4ce05e-fat.jar com.pluralsight.dockerproductionaws.admin.Migrate\nOct 18, 2016 8:18:54 PM org.flywaydb.core.internal.util.VersionPrinter printVersion\nINFO: Flyway 4.0.3 by Boxfuse\n$ ls -l\ntotal 176\n-rw-r--r-- 1 jmenga staff 7981 8 Nov 23:20 Makefile\n-rw-r--r-- 1 jmenga staff 3956 8 Nov 23:09 Makefile.settings\n-rw-r--r-- 1 jmenga staff 30452 8 Nov 23:18 README.md\n-rw-r--r-- 1 jmenga staff 9772 9 Nov 06:02 audit-db.log\n-rw-r--r-- 1 jmenga staff 101 9 Nov 06:01 audit-db.properties\n-rw-r--r-- 1 jmenga staff 4849 9 Nov 06:01 audit-db.script\ndrwxr-xr-x 2 jmenga staff 68 9 Nov 06:00 audit-db.tmp\n...\n...\n```\n\nNext start the audit service, ensuring the `-cluster` flag is set:\n\n```\n$ java -jar build/jars/microtrader-audit-20161018004318.d4ce05e-fat.jar -cluster\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\nINFO: Starting clustering...\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\n...\n...\nINFO: [127.0.0.1]:5701 [dev] [3.6.5]\n\n\nMembers [1] {\n Member [127.0.0.1]:5701 this\n}\n...\n...\nAudit (Rest endpoint) service published : true\nOct 18, 2016 8:19:46 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer\nINFO: Succeeded in deploying verticle\n```\n\nIn a new console window, start the portfolio service, ensuring the `-cluster` flag is set. You should see the cluster members increase to 2 in both console windows.\n\n```\n$ java -jar build/jars/microtrader-portfolio-20161018004318.d4ce05e-fat.jar -cluster\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\nINFO: Starting clustering...\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\n...\n...\nINFO: [127.0.0.1]:5701 [dev] [3.6.5]\n\nMembers [2] {\n Member [127.0.0.1]:5701\n Member [127.0.0.1]:5702 this\n}\n\n...\n...\nPortfolio service published : true\nOct 18, 2016 8:21:41 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer\nINFO: Succeeded in deploying verticle\nPortfolio Events service published : true\n```\n\nIn another console window, start the quote generator service, once again ensuring the `-cluster` flag is set. You should see the cluster members increase to 3 in all console windows.\n\n```\n$ java -jar build/jars/microtrader-quote-20161018004318.d4ce05e-fat.jar -cluster\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\nINFO: Starting clustering...\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\n...\n...\nINFO: [127.0.0.1]:5701 [dev] [3.6.5]\n\nMembers [3] {\n Member [127.0.0.1]:5701\n Member [127.0.0.1]:5702\n Member [127.0.0.1]:5703 this\n}\n\nOct 18, 2016 8:24:23 PM com.hazelcast.core.LifecycleService\nINFO: [127.0.0.1]:5703 [dev] [3.6.5] Address[127.0.0.1]:5703 is STARTED\nMarket data service published : true\nOct 18, 2016 8:24:26 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer\nINFO: Succeeded in deploying verticle\nQuotes (Rest endpoint) service published : true\nServer started\n```\n\nAfter the quote generator service has started, you should start to see trading activity in the portfolio service console output:\n\n```\n...\n...\nBought 1 of Black Coat !\nBought 6 of Divinator !\nBought 2 of Divinator !\nBought 1 of Black Coat !\nBought 2 of Divinator !\n...\n...\n```\n\nFinally, in a new console window, start the trader dashboard service, ensuring the `-cluster` flag is set. You should see the custer members increase to 4 in all console windows.\n\n```\n$ java -jar build/jars/microtrader-dashboard-20161018004318.d4ce05e-fat.jar -cluster\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\nINFO: Starting clustering...\nOct 18, 2016 8:19:41 PM io.vertx.core.impl.launcher.commands.RunCommand\n...\n...\nINFO: [127.0.0.1]:5701 [dev] [3.6.5]\n\nMembers [4] {\n Member [127.0.0.1]:5701\n Member [127.0.0.1]:5702\n Member [127.0.0.1]:5703\n Member [127.0.0.1]:5704 this\n}\n\nOct 18, 2016 8:28:03 PM com.hazelcast.core.LifecycleService\nINFO: [127.0.0.1]:5704 [dev] [3.6.5] Address[127.0.0.1]:5704 is STARTED\nOct 18, 2016 8:28:05 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer\nINFO: Succeeded in deploying verticle\n```\n\nAt this point, you should be able to browse to [http://localhost:8000](http://localhost:8000). \n\nThe following screenshot demonstrates a fully functional Microtrader application:\n\n![alt Microtrader Dashboard](https://cloud.githubusercontent.com/assets/3351083/19468489/16fc6140-9573-11e6-917f-5717e7564d57.png)\n\n### Testing the Application Locally\n\nYou can run unit tests using standard gradle tasks:\n\n```\n$ ./gradlew clean test\n...\n...\n$ ./gradlew :microtrader-audit:clean :microtrader-audit:test\n...\n...\n```\n\nIf you have the application running locally, you can run acceptance tests, which are defined in the [`microtrader-specs`](./microtrader-specs) folder.\n\nThese tests are written in JavaScript using [Mocha](https://mochajs.org) and test browser-like interactions with the dashboard service and other REST endpoints, as well as the SockJS Event Bus bridge provided by the dashboard service:\n\n\u003e You only need to run the `npm install` commands once\n\n```\nmicrotrader$ cd microtrader-specs\nmicrotrader-specs$ npm install -g mocha\n...\n...\nmicrotrader-specs$ npm install \n...\n...\nmicrotrader-specs$ mocha --exit\n\n Trader Dashboard Frontend\n ✓ should return a 200 OK response\n\n Quote Service REST Endpoint\n ✓ should return a 200 OK response\n ✓ should return a MacroHard quote\n ✓ should return a Black Coat quote\n ✓ should return a Divinator quote\n\n Audit Service REST Endpoint\n ✓ should return a 200 OK response (41ms)\n ✓ should return an array of stock trades\n\n Operations Endpoint\n ✓ should return a 200 OK response (43ms)\n ✓ should return an array of stock trades\n\n Discovery Endpoint\n ✓ should return a 200 OK response (44ms)\n ✓ should return an array of service location records\n ✓ should list all services having a status of UP\n\n Market Events\n ✓ should receive market data (4018ms)\n\n Portfolio Events\n ✓ should receive portfolio trading events (3010ms)\n ✓ should retrieve portfolio service data\n\n 15 passing (7s)\n```\n\n## Docker Workflow\n\nThe repository includes a Docker-based continuous delivery workflow that creates two environments:\n\n- Test Environment\n- Release Environment\n\n### Test Environment\n\nThe test environment is expressed via a [`docker-compose.yml`](./docker/test/docker-compose.yml) file in the [docker/test](./docker/test) folder. \n\nThe environment defines a single service `test` which creates a Docker development image (defined in [docker/test/Dockerfile](./docker/test/Dockerfile)), which tests and builds the application \"fat\" jar artefacts. \n\nAll artefacts and test reports are copied to the local `build` folder, so that running tests and builds locally is no different from running the Docker workflow. \n\nThe various actions required to run the tests and build are defined in the `test` task of the local [`Makefile`](./Makefile).\n\n### Release Environment\n\nThe release environment is expressed via a [`docker-compose.yml`](./docker/release/docker-compose.yml) file in the [docker/release](./docker/release) folder. \n\nThe release environment defines multiple services:\n\n- Application services - the various application services are built into \"release\" images as defined in `Dockerfile.\u003cservice\u003e` files in the [docker/release](./docker/release) folder. These images represent the final artifact that will run in production, assuming all future tests and quality checks pass. Each application service release image is based from the [`microtrader-base`](https://github.com/docker-production-aws/microtrader-base) image.\n- Database service - this creates a MySQL database container, which is the database engine used in production\n- Helper services - these help orchestrate the correct initialisation and startup of the environment\n- Specs service - this runs the acceptance tests defined in the [`microtrader-specs`](./microtrader-specs) folder.\n\n### Running the Workflow\n\nTo run the workflow your system must meet the following requirements:\n\n- Docker 1.12 or higher client installed and pointed to a local or remote Docker Engine\n- Docker Compose 1.7 or higher\n- GNU Make\n\nThe workflow consists of the following tasks:\n\n- Test stage - Run unit tests and build artefacts\n- Release stage - Build release images and run acceptance tests\n- Publish stage - Tag and publish release images to Docker registry\n\nTo run the test stage, use the `make test` command:\n\n```\n$ make test\n=\u003e Checking networking...\n=\u003e Building images...\nBuilding test\nStep 1 : FROM openjdk:8-jdk-alpine\n...\n...\nStep 22 : COPY microtrader-dashboard /app/microtrader-dashboard\n ---\u003e fb00a7fb8df4\nRemoving intermediate container 6f231cf4bc93\nSuccessfully built fb00a7fb8df4\n=\u003e Running tests...\nCreating microtradertest_test_1\nAttaching to microtradertest_test_1\ntest_1 | Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details\ntest_1 | :clean UP-TO-DATE\ntest_1 | :microtrader-audit:clean UP-TO-DATE\n...\n...\ntest_1 | com.pluralsight.dockerproductionaws.quotegenerator.MarketDataVerticleTest \u003e testMarketData PASSED\ntest_1 | :testReport\ntest_1 | :test UP-TO-DATE\ntest_1 | :shadowJar\ntest_1 | :microtrader-audit:shadowJar\ntest_1 | :microtrader-common:shadowJar\ntest_1 | :microtrader-dashboard:shadowJar\ntest_1 | :microtrader-portfolio:shadowJar\ntest_1 | :microtrader-quote:shadowJar\ntest_1 |\ntest_1 | BUILD SUCCESSFUL\ntest_1 |\ntest_1 | Total time: 39.164 secs\nmicrotradertest_test_1 exited with code 0\n=\u003e Removing existing artefacts...\n=\u003e Copying build artefacts...\n=\u003e Test complete\n```\n\nAfter the test stage, application artefacts and test reports will be available in the local `build/jars` and `build/test-reports` folders respectively.\n\nTo run the release stage, use the `make release` command:\n\n```\n$ make release\n=\u003e Checking networking...\n=\u003e Pulling latest images...\nPulling db (mysql:5.7)...\n...\n...\n=\u003e Building images...\nBuilding microtrader-portfolio\nStep 1 : FROM dockerproductionaws/microtrader-base\n...\n...\n=\u003e Starting audit database...\nCreating microtrader_db_1\n...\n...\n=\u003e Running audit migrations...\n...\n...\n=\u003e Starting audit service...\n...\n...\n=\u003e Starting portfolio service...\nCreating microtrader_microtrader-portfolio_1\n=\u003e Starting quote generator...\n...\n...\n=\u003e Starting trader dashboard...\n...\n...\n=\u003e Release environment created\n=\u003e Running acceptance tests...\nCreating microtrader_specs_1\nAttaching to microtrader_specs_1\nspecs_1 |\nspecs_1 |\nspecs_1 |\nspecs_1 | Suite duration: 0.006 s, Tests: 0\nspecs_1 |\nspecs_1 | Trader Dashboard Frontend\nspecs_1 | ․ should return a 200 OK response: 107ms\n...\n...\nspecs_1 | Portfolio Events\nspecs_1 | ․ should receive portfolio trading events: 6010ms\nspecs_1 | ․ should retrieve portfolio service data: 20ms\nspecs_1 |\nspecs_1 | Suite duration: 6.045 s, Tests: 2\nspecs_1 |\nspecs_1 | 15 passing (13s)\nspecs_1 |\nmicrotrader_specs_1 exited with code 0\n=\u003e Acceptance testing complete\n=\u003e Quote REST endpoint is running at http://172.16.154.128:33165/quote/\n=\u003e Audit REST endpoint is running at http://172.16.154.128:33163/audit/\n=\u003e Trader dashboard is running at http://172.16.154.128:33166\n```\n\nAt this point, the release environment is operational and you can actually interact with the application using the URLs shown.\n\n### Publishing Release Images\n\nThe final stage is to publish the release images.\n\nTo be able to publish your release images, you will need to reconfigure this project to point to a parent repository and Docker registry that you have write access to.\n\nThis can be achieved by editing the [`Makefile`](./Makefile) and configuring the `ORG_NAME` and `DOCKER_REGISTRY` settings:\n\n```\n...\n...\n# Project variables\nPROJECT_NAME ?= microtrader\nORG_NAME ?= \u003cyour-organization\u003e\nREPO_NAME ?= microtrader\nTEST_REPO_NAME ?= microtrader-dev\nDOCKER_REGISTRY ?= \u003cyour-registry-url\u003e\n...\n...\n```\n\nAfter specifying the correct Docker registry and organization name, you next need to ensure you are logged into the Docker registry:\n\n```\n$ docker login myregistry.org\nUsername: justin\nPassword: **\nLogin Succeeded\n```\n\nOnce logged in, you can tag and publish the release images by running `make tag` and `make publish`:\n\n\u003e The workflow includes a `make tag:default` task which tags the image with the current version (i.e. `make version`), short commit hash, any annotated tags that are present on the current commit, and the 'latest' tag\n\n```\n$ make tag $(make version) latest\n=\u003e Tagging development image with tags 20161018004318.d4ce05e latest...\n=\u003e Tagging release images with tags 20161018004318.d4ce05e latest...\n=\u003e Tagging complete\n\n$ make publish\n=\u003e Publishing development image sha256:fb00a7fb8df435b8189604f761c3e30efceece6f58e67acc5779ee117dd1c623 to docker.io/dockerproductionaws/microtrader-dev...\nThe push refers to a repository [docker.io/dockerproductionaws/microtrader-dev]\n37fc39364752: Pushing 3.429 MB\n321ffde7a0f3: Pushing 170.5 kB\ne75559b931ad: Layer already exists\n75ddd18ec36a: Layer already exists\naf70c2411550: Layer already exists\n6a6695567041: Layer already exists\n1ef8bb56757c: Layer already exists\n...\n...\n=\u003e Publishing release images to docker.io/dockerproductionaws...\nThe push refers to a repository [docker.io/dockerproductionaws/microtrader-quote]\n...\n...\n```\n\n### Cleaning Up\n\nTo clean up the Docker environments, run the `make clean` task:\n\n```\n$ make clean\n=\u003e Destroying test environment...\nRemoving microtradertest_test_1 ... done\nNetwork docker_workflow is external, skipping\n=\u003e Destroying release environment...\nStopping microtrader_microtrader-dashboard_1 ... done\nStopping microtrader_microtrader-quote_1 ... done\nStopping microtrader_microtrader-portfolio_1 ... done\nStopping microtrader_microtrader-audit_1 ... done\nStopping microtrader_db_1 ... done\nRemoving microtrader_specs_1 ... done\nRemoving microtrader_trader-agent_run_1 ... done\nRemoving microtrader_microtrader-dashboard_1 ... done\nRemoving microtrader_quote-agent_run_1 ... done\nRemoving microtrader_microtrader-quote_1 ... done\nRemoving microtrader_microtrader-portfolio_1 ... done\nRemoving microtrader_audit-agent_run_1 ... done\nRemoving microtrader_microtrader-audit_1 ... done\nRemoving microtrader_microtrader-audit_run_1 ... done\nRemoving microtrader_audit-db-agent_run_1 ... done\nRemoving microtrader_db_1 ... done\nNetwork docker_workflow is external, skipping\n=\u003e Removing dangling images...\n=\u003e Clean complete\n```\n\n### Running an End-to-end Workflow\n\nThe workflow includes a convenient `make all` task, which automatically runs the following tasks:\n\n- `make clean`\n- `make test`\n- `make release`\n- `make tag:default` - tags the current version (i.e. `make version`), short commit hash, any annotated tags that are present on the current commit and the 'latest' tag\n- `make publish`\n- `make clean` \n\n## Environment Configuration Settings\n\nEach application service Docker release image supports a variety of configuration parameters expressed in the form of environment variables.\n\nThese settings are based upon two categories:\n\n- Application settings - used to configure the application services.\n- Clustering settings - used to control the Hazelcast autodiscovery mechanism used to form clusters.\n\nThe following table lists environment variables that configure application settings:\n\n| Scope | Environment Variable | Default Value | Notes |\n|-----------------|------------------------|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| All | HTTP_HOST | localhost | Defines the hostname of the application service endpoint. This should be set to the public DNS service name you want other components to reach the service at (e.g. a load balancer endpoint). This value is published in service discovery records. |\n| All | HTTP_PORT | | Defines the local HTTP port the HTTP service runs on, if an HTTP service is defined for the application service. |\n| All | HTTP_PUBLIC_PORT | ${HTTP_PORT} | Defines the public HTTP port the HTTP service is published to. For example, this should be set to the public listener configured on a front-end load balancer endpoint. This value is published in service discovery records. |\n| All | HTTP_ROOT | | Defines the root path the HTTP service is served from. This setting is useful if you perform content-based routing based upon URL path on a front-end load balancer. This value is published in service discovery records. |\n| All | MARKET_DATA_ADDRESS | market | The Event Bus address to publish/receive stock market quotes to/from |\n| All | PORTFOLIO_ADDRESS | portfolio | The Event Bus address to publish/receive stock trade events to/from |\n| Quote Generator | MARKET_PERIOD | 3000 | The frequency in milliseconds that each stock quote is generated |\n| Audit Service | JDBC_URL | jdbc:hqldb:file:audit-db | The JDBC URL of the audit database |\n| Audit Service | JDBC_USER | audit | The JDBC user of the audit database |\n| Audit Service | JDBC_PASSWORD | password | The JDBC password of the audit database |\n| Audit Service | JDBC_DRIVERCLASS | org.hsqldb.jdbcDriver | The JDBC driver class for the audit database engine |\n| Audit Service | DB_MIGRATIONS_LOCATION | db/hsqldb | The resources root relative path to the appropriate database migrations for the configured database engine. |\n\nThe following table lists environment variables that configure clustering settings:\n\n| Environment Variable | Default Value | Notes |\n|------------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| CLUSTER_GROUP_NAME | microtrader | Sets the Hazelcast cluster group name. Use to separate multiple Hazelcast clusters running on the same subnet. |\n| CLUSTER_GROUP_PASSWORD | | Sets the Hazelcast cluster group password. Use to prevent unauthorised hosts attempting to join the cluster. |\n| CLUSTER_AWS_ENABLED | False | When set to \"true\", enables discovery of other cluster members in an AWS environment. |\n| CLUSTER_AWS_REGION | | Specifies the AWS region when using AWS discovery mechanism |\n| CLUSTER_AWS_IAM_ROLE | DEFAULT | Specifies an IAM role with appropriate privileges to query the EC2 API and find other cluster instances based upon the CLUSTER_AWS_TAG_KEY and CLUSTER_AWS_TAG_VALUE configuration. The default value of \"DEFAULT\" specifies to use the EC2 IAM Instance Profile and associated IAM role. |\n| CLUSTER_AWS_TAG_KEY | hazelcast:group | The value of the tag key to search for when querying the EC2 API for other cluster members |\n| CLUSTER_AWS_TAG_VALUE | microtrader | The value of the tag value to search for when querying the EC2 API for other cluster members |\n\n## Branches\n\nThis repository contains two branches:\n\n- [`master`](https://github.com/docker-production-aws/microtrader/tree/master) - represents the initial starting state of the repository as viewed in the course.\n\n- [`final`](https://github.com/docker-production-aws/microtrader/tree/final) - represents the final state of the repository after completing all configuration tasks as described in the course material.\n\n\u003e The `final` branch is provided as a convenience in the case you get stuck, or want to avoid manually typing out large configuration files. In most cases however, you should attempt to configure this repository by following the course material.\n\nTo clone this repository and checkout a branch you can simply use the following commands:\n\n```\n$ git clone https://github.com/docker-production-aws/packer-ecs.git\n...\n...\n$ git checkout final\nSwitched to branch 'final'\n$ git checkout master\nSwitched to branch 'master'\n```\n\n## Repository Timeline\n\nThe following provides links to commits in this repository that represent important milestones in the course material:\n\n- [Running Docker Applications Using the EC2 Container Service](https://github.com/docker-production-aws/microtrader/tree/running-docker-applications-using-ecs) - this commit represents the state of the repository once you have completed the **Running Docker Applications Using the EC2 Container Service** module.\n\n- [Continuous Delivery Using CodePipeline](https://github.com/docker-production-aws/microtrader/tree/continuous-delivery-codepipeline) - this commit represents the state of the repository once you have completed the **Continuous Delivery Using CodePipeline** module.\n\n## Errata\n\nSee [issues](https://github.com/docker-production-aws/microtrader/issues?utf8=✓\u0026q=is%3Aissue)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdocker-production-aws%2Fmicrotrader","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdocker-production-aws%2Fmicrotrader","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdocker-production-aws%2Fmicrotrader/lists"}