SaaS mit Spring und Docker - edoc.sub.uni- .Daniel Gehn Thema der Arbeit SaaS mit Spring und Docker

download SaaS mit Spring und Docker - edoc.sub.uni- .Daniel Gehn Thema der Arbeit SaaS mit Spring und Docker

of 91

  • date post

    04-Jun-2018
  • Category

    Documents

  • view

    213
  • download

    0

Embed Size (px)

Transcript of SaaS mit Spring und Docker - edoc.sub.uni- .Daniel Gehn Thema der Arbeit SaaS mit Spring und Docker

  • BachelorarbeitDaniel Gehn

    SaaS mit Spring und Docker

    Fakultt Technik und InformatikStudiendepartment Informatik

    Faculty of Engineering and Computer ScienceDepartment of Computer Science

  • Daniel Gehn

    SaaS mit Spring und Docker

    Bachelorarbeit eingereicht im Rahmen der Bachelorprfung

    im Studiengang Bachelor of Science Angewandte Informatikam Department Informatikder Fakultt Technik und Informatikder Hochschule fr Angewandte Wissenschaften Hamburg

    Betreuender Prfer: Prof. Dr. Stefan SarstedtZweitgutachter: Prof. Dr. Olaf Zukunft

    Eingereicht am: 16. Februar 2017

  • Daniel Gehn

    Thema der ArbeitSaaS mit Spring und Docker

    StichworteSaaS, Spring, Docker, Microservices, OAuth, Containerisierung, REST, HATEOAS, HAL

    KurzzusammenfassungZiel dieser Bachelorarbeit ist die Entwicklung einer Software as a Service Anwendung frModelagenturen. Im Verlauf der Arbeit werden sowohl die Anforderungen als auch das dar-auf aufbauende Konzept behandelt. Auf diesem basierend werden die Umsetzung wichtigerKomponenten und der Betrieb in Docker erlutert, um eine lauhige SaaS Anwendung zuerstellen. Die Arbeit setzt hierbei grundlegende Kenntnis ber die Software Entwicklung undArchitektur voraus.

    Daniel Gehn

    Title of the paperSaaS with Spring and Docker

    KeywordsSaaS, Spring, Docker, Microservices, OAuth, Containerization, REST, HATEOAS, HAL

    AbstractTarget of this bachelor thesis is the development of a Software as a Service application formodel agencies. Throughout this thesis the requirements will be discussed as well as theconcept build upon it. Based on this, the implementation of important components and theoperation with Docker to create a working SaaS application will be explained. The paperrequires basic knowledge of software development and architecture.

  • Inhaltsverzeichnis

    1. Einleitung 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. berblick der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

    2. Grundlagen 32.1. Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Microservices vs. Monolith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3. Containerisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5. Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    3. Fachliche Analyse 103.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    4. Konzeption 124.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3. Zugri auf Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4. Spring als Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5. Ember.js als Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.6. Bentigte Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

    5. Realisierung 215.1. Entitten Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2. Multi Tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3. OAuth2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4. OAuth2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.5. OAuth2 SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.6. Object Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7. Ember.js Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.8. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

    5.8.1. Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 295.8.2. Test- und Produktivsystem . . . . . . . . . . . . . . . . . . . . . . . . 30

    6. Evaluierung 346.1. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

    iv

  • Inhaltsverzeichnis

    A. Anhang 37A.1. Multi Tenancy: AgencyFilteredRepositoryImpl.java . . . . . . . . . . . . . . . 38A.2. Multi Tenancy: AgencyFilteredRepositoryFactoryBean.java . . . . . . . . . . . 42A.3. Auth Service: CustomAuthenticationProvider.java . . . . . . . . . . . . . . . . 44A.4. Auth Service: CustomUserDetailsService.java . . . . . . . . . . . . . . . . . . . 47A.5. Gateway: application.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.6. SSOClient: application.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.7. ObjectStorage.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.8. Microservice: Dockerle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.9. docker-compose.yml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.10. Ember.js: serializers/application.js . . . . . . . . . . . . . . . . . . . . . . . . . 57A.11. Ember.js: adapters/application.js . . . . . . . . . . . . . . . . . . . . . . . . . . 71

    Literaturverzeichnis 76

    Glossar 79

    v

  • 1. Einleitung

    1.1. Motivation

    Die Modelwelt bendet sich stets in Bewegung und die Agenturen mssen sowohl mit ihrenKunden in Kontakt stehen als auch die Models koordinieren. Whrend die Models von einemTermin zum nchsten eilen, arbeiten die Mitarbeiter der Modelagenturen im Hintergrund,um neue Auftrge zu generieren, Unterknfte und Reisen zu buchen und die Abrechnungdurchzufhren.

    An dieser Stelle kann eine entsprechende Software viel Arbeit abnehmen und Fehler ver-meiden. Termine, Kunden, Models und Weiteres kann einfach verwaltet und teilweise au-tomatisiert abgearbeitet werden. Hierfr existieren bereits einige Lsungen auf dem Markt,welche jedoch entweder veraltet sind oder nicht gengend der tglichen Aufgaben abdecken.Dies fhrt zu einem mehr an Arbeit und Stress sowohl bei den Models als auch in der Agentur.

    Im Gesprch mit mehreren deutschen Agenturen wurden die Anforderungen an eine sol-che Software und die Missstnde von aktuellen Lsungen analysiert. Um einen berblick dieserGesprche zu gewhren, werden im Folgenden die Wichtigsten dieser Anforderungen erlutert.

    Als nachgefragtester Punkt stellt sich hierbei die Buchhaltung heraus. Dieser Bereich be-steht in bisherigen Lsungen nur rudimentr oder ist fr die Agenturen vom Umfang her nichtausreichend. Die Buchhaltung in Deutschland stellt sich meist komplexer und genauer dar,als es die Implementationen ermglichen und zulassen. Dies erzeugt in den meisten Flleneine Zettelwirtschaft in Verbindung mit einer doppelten Datenpege in einer zustzlichenBuchhaltungssoftware.

    Nachfolgend stellt die Kommunikation mit den Models eine Baustelle dar, welche nicht aus-reichend gelst ist. Besonders die groen Distanzen und die fehlende Einbindung des Models abgesehen von den Daten des Models in die Software fhrt oft zum Verpassen oder dem

    1

  • 1. Einleitung

    Verspten bei Terminen. Grnde hierfr sind unter anderem fehlende Wegbeschreibungenund nicht kommunizierte Terminnderungen, aber auch nach einem Termin endet die Kom-munikation mit dem Model nicht. Belege fr Taxifahrten und andere Unkosten mssen mitentsprechenden Belegen aufgefhrt werden, da diese sonst nicht mit dem Kunden abgerechnetwerden knnen. Diese Dinge werden meist nur "mal eben" per Telefon kommuniziert oderin einer kurzen E-Mail ausgetauscht. Da dies auerhalb der Systeme geschieht, geht oftmalsunter, welcher Beleg schon vorhanden ist oder ob eine Terminnderung schon mitgeteilt wurde.

    Diese Probleme fhrten zu der Idee eine neue Software zu entwickeln, welche alle Aufga-ben einer Model- oder auch allgemeinen Castingagentur vereinfacht, automatisiert und dieSchwchen der bisherigen Produkte lst. Ein Teil des Entwurfs und der Entwicklung dieserSoftware wird im Rahmen dieser Bachelorarbeit behandelt.

    1.2. berblick der Arbeit

    Die Arbeit wird zu Beginn einige Grundlagen fr die folgenden Kapitel vermitteln, welchebesonders das Konzept und die Implementation betreen. Den Grundlagen folgt eine fachlicheAnalyse einiger Funktionen siehe auch Abschnitt 1.1 (S. 1) , welche im Gesprch mit denAgenturen aufgekommen sind. Auf diesem Wissen aufbauend entsteht dann das Konzept derSoftware, welches sowohl die Architektur als auch die technischen Anforderungen behandelt.Die Realisierung dieses Konzepts wird einige Elemente aus den jeweiligen Teilbereichen undTechnologien der Software enthalten, gefolgt von einer abschlieenden Evaluierung ber denVerlauf des Prozesses inklusive einer Aussicht auf mgliche Erweiterungen des Systems.

    2

  • 2. Grundlagen

    In diesem Kapitel werden die wichtigsten Konzepte und Technologien, welche im Verlauf derArbeit verwendet werden, erlutert. Ziel ist es einen berblick und ein besseres Verstndnisfr die folgenden Kapitel ber Software as a Service (SaaS), Microservices, Containerisie-rung, Docker und Spring zu vermitteln.

    2.1. Soware as a Service

    Das Konzept SaaS, auf welches viele Unternehmen sowohl als Anbieter (vgl. IAO (2010a)) alsauch Nutzer (vgl. Bitkom (2016)) schon seit einigen Jahren setzen und das auch zunehmendumsatzstrker wird (vgl. Gartner (2016), Experton (2016)), stellt einen vllig anderen Ansatz zuklassisch lizenzierter Software dar. Der Unterschied zwischen klassisch lizenzierter Softwareund einem SaaS System beginnt schon beim Betrieb der Software.

    Bisher musste ein Kunde meist eine Lizenz fr die zu verwe