.. _install: Installation ============ Entwicklungsumgebung -------------------- Die beste Python IDE ist `PyCharm `_ von Jetbrains. Mit der professional Edition ist `Remote Development (debuggen im Container) `_ möglich - das Killerfeature schlechthin. 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 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. .. image:: _static/container_overview.png :width: 400px 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 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 - - 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) Userpassword setzen +++++++++++++++++++ ``hrcli user --help`` 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 - - 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 - - 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 Frontend -------- Das neue Frontend verwendet `Vue.js `_ , das `Bulma `_ CSS Framework und `Lavarel Mix `_ für den Umgang mit webpack. Install node Modules ++++++++++++++++++++ :: cd /opt/hr/frontend npm i 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. 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.