2. Installation

2.1. Entwicklungsumgebung

Die beste Python IDE ist PyCharm von Jetbrains. Mit der professional Edition ist Remote Development (debuggen im Container) möglich - das Killerfeature schlechthin.

2.2. Auschecken der Repositories

Derzeit wird die app im Branch bulma entwickelt.

mkdir hr3
cd hr3
git clone -b bulma git@bitbucket.org:sumpfgottheit/hr3-app.git app
git clone git@bitbucket.org:sumpfgottheit/hr3-docker-images.git images
git clone git@bitbucket.org:sumpfgottheit/hr3-compose.git compose

2.3. Erstellen der Container Images

Ein rebuild erzeugt alle Images neu:

cd images
./rebuild

Mit push werden sie - als sumpfgottheit - auf den Dockerhub gespielt und können mit docker pull geholt werden.

Alle Images für die Hochrechnung haben -hr3 im Namen:

saf@tuxedo-arch:/home/saf/devel/hr3
# docker images |grep hr3
sumpfgottheit/hr3-rq                      latest              44d3ce78434c        46 hours ago        839 MB
sumpfgottheit/hr3-gunicorn                latest              f79f34e27777        46 hours ago        835 MB
sumpfgottheit/hr3-devel                   latest              ea83e3c1018c        46 hours ago        845 MB
sumpfgottheit/hr3-entrypoint              latest              321ee5a03baf        46 hours ago        835 MB
sumpfgottheit/alpine-python36-numpy-hr3   latest              481890c4a9f1        46 hours ago        809 MB
sumpfgottheit/hr3-redis3                  latest              c8ef6b871de9        47 hours ago        69.4 MB
sumpfgottheit/hr3-postgres95              latest              718ef97df9ee        47 hours ago        84 MB
sumpfgottheit/hr3-nginx                   latest              7f45d469189c        47 hours ago        102 MB

Das folgende Bild zeigt, welche Container worauf basieren. Wo möglich verwende ich Alpine Linux als Basis für meine Images. Alpine Linux benötigt wenig Platz und es war deutlich einfacher die benötigten Versionen zu installiern. Mittlerweile basieren viele Docker Images von offiziellen Projekten auf Alpine Linux.

_images/container_overview.png

Der container hr3-devel startet einen SSHD. Dieser Container wird während der Entwicklung sowie am Wahltag für das Einspielen, die Loops etc etc verwendet. Während die Produktion von Nginx->Gunicorn serviciert wird, wird während der Entwicklung der Flask-Development Server mit der Webapp im Development Container gestartet und man greift wie Nginx->FlaskDevelServer auf den Development Stand zu.

Alle Container erhalten den Benutzer saf mit der UID 1808. Im Verzeichnis artifacts/ wird dieser User in alpine_create_saf_environment.sh angelegt.

Der Benutzer saf ist überall angelegt und hat mein persönliches environment. Ihr habt folgende Möglichkeiten:

* Mit dem user **saf** arbeiten. Dann solltet ihr eure public ssh-keys in ``images/artifacts/alpine_create_saf_environment.sh``
  hinzufügen und das Repository, via pull-request updaten
* Ihr legt euch einen eigenen Devel-Container nach dieser Vorlage an, zb ``hr3-him-devel``
* Wir nehmen einen gemeinsamen User
* Ihr gebt username, userid und publickey in ``compose/user.config`` an und hängt das File als ``/user.config``
  in den Container (nicht getestet, aber sollte gehen)

Alle Container, die von hr3-entrypoint ableiten, lesen während der Starts das Verzeichnis /docker-entrypoint.d/ und führen alles *.sh Scripts aus. (Siehe artifacts/entrypoint.sh). Die anderen Container haben meist ähnliche Mechanismen - siehe die Dockerfiles der Base-Images. Das Verzeichnis /docker-entrypoint.d/ kann als Volume gemountet werden um Startup Scripts

Mit dem Entrypoint können also user auch beim Containerstart hinzugefügt werden

2.4. Backend

Der Container devel hat einen SSHD am Port 2222 laufen. Damit wechseln wir quasi ins Development Environment. Für die Produktion wir durch den Gunicorn-Applicationserver die Applikation gestartet.

Zuerst wird der Letztstand der DB eingespielt. Dabei werden gleichzeitig die Tables angelegt. Ohne weiteren Parameter wird der letzte PostgresqlDump von /opt/hr/pg_dumps/latest.dump eingespielt:

ssh saf@localhost -p 2222
saf@devel:/opt/hr [venv:virtualenv_hr git:bulma]
 # hrcli db restore
2017-03-17 17:35:29,274 - wsgi.config - DEBUG - config.py - <module> - 194 - Used LOGGING_CONFIG: /opt/hr/configs/logging.devel.yaml
Dropping user_roles
Dropping roles
Dropping users
..
..
COPY 33
COPY 60
 setval
-------
      1
(1 row)

2.4.1. Userpassword setzen

hrcli user --help

2.4.2. Backend starten

Mit hrcli run wird der Development Server mit der app in /opt/hr/wsgi/__init__.py/ gestartet:

# hrcli run
2017-03-17 17:40:04,901 - wsgi.config - DEBUG - config.py - <module> - 194 - Used LOGGING_CONFIG: /opt/hr/configs/logging.devel.yaml
2017-03-17 17:40:05,873 - werkzeug - INFO - _internal.py - _log - 87 -  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
2017-03-17 17:40:05,898 - werkzeug - INFO - _internal.py - _log - 87 -  * Restarting with inotify reloader
2017-03-17 17:40:06,432 - wsgi.config - DEBUG - config.py - <module> - 194 - Used LOGGING_CONFIG: /opt/hr/configs/logging.devel.yaml
2017-03-17 17:40:07,344 - werkzeug - WARNING - _internal.py - _log - 87 -  * Debugger is active!
2017-03-17 17:40:07,348 - werkzeug - INFO - _internal.py - _log - 87 -  * Debugger PIN: 512-996-644

2.5. Frontend

Das neue Frontend verwendet Vue.js , das Bulma CSS Framework und Lavarel Mix für den Umgang mit webpack.

2.5.1. Install node Modules

cd /opt/hr/frontend
npm i

2.5.2. Browsersync

Um bei der reinen Javascript Entwicklung nicht immer einen Reload des Files mache müssen - auch wenn es durch Flask ausgeliefert wurde - wurde Browsersync installiert. Beim Aufruf von npm run watch wird ein Proxy gestartet, der auf dem Port 3000 lauscht.

Das Frontend ist via http://localhost:3000 erreichbar.

2.5.3. SWAGGER UI

Die API Definition erfolgt mittels Swagger. Das Swagger-Gui ist unter http://localhost:5000/api/ui erreichbar. Die API wird durch das Backend bei Request und Response enforced.