Skip to content

Latest commit

 

History

History
executable file
·
61 lines (46 loc) · 3.33 KB

README.md

File metadata and controls

executable file
·
61 lines (46 loc) · 3.33 KB

Microservices Exercises // IOT Device Manager


IoT Device Manager

Today we build a small 3-tier application with the play framework. It should manage your IoT device information. With sbt we'll build a customaziable docker instance with environment variables for the database. The schema will be created by flyway on startup and the data model is automatically generated by slick. So you can focus just on the http service. In another lesson we'll add another service which consumes the iot sensor data with akka persistence and event sourcing.


Exercise 1 - Startup Tooling (30m)

  1. Open and Change the run_test.sh. If you use powershell add your own powershell script.
  2. Run a postgres instance on docker and set the env variables for user, db and password. Also use a meaningfull name and export the port, so you can use it later.
  3. Write a shell script which wait's on the running postgres instance. Hint: You can do this with a subshell which will exit with 0 if netcat can open the connection or after 100 seconds with 1.
  4. Inspect the given build.sbt file and look if there is a command alias for running all your tests with code coverage check.
  5. add the command to your shell script sbt [THECOMMAND]
  6. stop the postgres docker instance
  7. delete the postgres docker instance
  8. run your test script. It shows the code coverage. What is the Statement coverage?

Exercise 2 - Build Play App (1h)

The given app has just a rest controller / model for Contacts. You can show, add, delete them via REST Endpoints and the database access is fully managed by slick and flyway (don't change these modules).

  1. Start a docker postgres instance with env vars db: test, user: user and password: password on port 5432
  2. Start the application with sbt runDev
  3. Try to reach the swagger.json under http://localhost:9000/v1/swagger.json and load in into a swagger ui instance
  4. Contact is not the right name for the table. It should be called the Owner table. Instead of an email you should save the company name, because a iot device will belong to a company. Refactor the code and the tests. REMEMBER: The database schema / table will be regenerated on compile
  5. Now we also need a second table for your IOT Devices the table needs the following information:
    • id: bigserial
    • owner: bigserial (fk to Owner)
    • created_date: TIMESTAMP
    • changed_date: TIMESTAMP
    • name: VARCHAR
    • device: VARCHAR
    • device_serial_number: VARCHAR
    • location_lat: Double
    • location_lon: Double
    • deleted: boolean
  6. Write tests for the new controller / model and reach a coverage higher than 80%

Excercise 3 - Dockerize (30m)

Dockerize your application and try to get it up as a docker compose.

  1. look at run_build.sh and complete it from your run_tests script.
  2. run your docker build script and check if the image is there. (docker images)
REPOSITORY                               TAG                 IMAGE ID            CREATED             SIZE
innfactory/iot-manager                   1.0                 ab8cad00e474        5 seconds ago       156MB
  1. Now create a docker compose file which starts your image after a postgres database is created and health check is completed. You have to set all the env variables to get it all up!

Credits

This exercise is a part of the innFactory Play2 Contact Manager Template from Patrick.