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:
a reverse proxy
Each container should be configured using a Dockerfile and any secondary configuration/provisioning scripts as required.
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.
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)
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.