Create a micro-services architecture to provide basic system information in a web frontend.


  • A script or config file (e.g. docker-compose, kubernetes yml, bash script) to spin up a set of microservices (i.e. containers) providing the following:

    • an application

    • a database

    • a reverse proxy

  • Each container should be configured using a Dockerfile and any secondary configuration/provisioning scripts as required.

  • Application container:

    • Host either a Django or Rails application

    • The application should have a single page as its index page that outputs the following:

      • Results of running the shell commands `screenfetch` and `date`.

      • A table listing the last 10 times the page was loaded.

    • Every time the page is reloaded, create a new entry in the DB logging the time of the request.

    • The application may be copied into its container as part of the container build process OR mounted as a volume.

    • Use the native auth system (i.e. the basic one that comes with Rails or Django) to secure the page.

  • Database container:

    • Have a DB with a table that tracks (1) id; and (2) time of request.

    • Any database software may be used but it must reside in this separate container (i.e. you may not use a SQLite DB in the application container)

  • Reverse proxy container:

    • Reverse proxy the application in the application container to localhost:80

    • Reverse proxy the database to the appropriate port on the host for the DBS chosen. E.g. for mysql, map to localhost:3389; for postgres, map to localhost:5432, etc.


  • Use username:password for any credentials (e.g. for the dbs)

  • All containers should be linux based. The particular distro is not important.

  • You may install screenfetch from source or as a binary from your distro's repos. If screenfetch is unavailable for your distro, ufetch is an acceptable alternative.

  • For the application, you may use any additional frameworks or libraries as you deem necessary.

  • In configuring your containers, you may install any dependencies as you see fit.

  • You may reuse your own code from prior work

  • You may use code snippets from other authors but they must be annotated in comments, and they must not constitute wholesale copying (to be arbitrated by Geosite engineers)

Evaluation criteria:

  • Functionality: Does the submission meet all the functional requirements?

  • Idiomatics: Are your code and configuration files idiomatic i.e. do they follow standard conventions for the software/framework/language chosen? E.g. if using Django, do you make use of viewsets, and is your code Pythonic?

  • Discussion: Be prepared to discuss your submission during the interview process

Please save your work as a public git repo and submit the link with your cover letter.