t-rex phaco: enabling paas application using twelve-factor app1252942/fulltext01.pdf · to run in a...

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2018

T-REX PHACO: enabling PaaS application using Twelve-Factor App

LIDIA FERNÁNDEZ GARCÉS

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

TRITA TRITA-EECS-EX-2018:548

www.kth.se

T-REX PHACO: enabling PaaSapplication usingTwelve-Factor App

LIDIA FERNÁNDEZ GARCÉS

Master ICT Innovation (Joint EIT Programme)Date: August 31, 2018Supervisor: Anne HåkanssonExaminer: Mihhail MatskinSchool of Electrical Engineering and Computer ScienceSwedish title: T-REX PHACO: möjliggör PaaS-applikation medTwelve-Factor App

ii

AbstractIn order to take advantage of the full-range of benefits of cloud computing, traditionalapplications should be adapted to conform with the cloud-native principles. In this work,a traditional Java enterprise application is transformed in a cloud-native application ableto run in a Platform as a Service using cloud-related technologies (Docker, Kubernetes,OpenShift) and an automation server (Jenkins). The resulting application follows Twelve-Factor App methodology and cloud-native principles.

iii

SammanfattningFör att dra nytta av det omfattande utbudet av cloud computing, bör traditionella applika-tioner anpassas för att överensstämma med de molnbaserade principerna. I det här arbetetomvandlas en traditionell Java-företagsansökan till en cloud-native applikation som kanköras i en plattform som en tjänst med hjälp av molnrelaterade teknologier (Docker, Ku-bernetes, Openshift) och en automationsserver (Jenkins). Den resulterande tillämpningenföljer Twelve-Factor App metodiken och cloud-native principer.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Purpose and Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Ethics and Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theoretic Background 52.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Integration, Production, Development . . . . . . . . . . . . . . . 62.1.3 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.4 SaaS and Cloud-Native Applications . . . . . . . . . . . . . . . . 82.1.5 Cloud Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.6 Continuous Deployment . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Architecture of Candidate Application 183.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Codebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 Development Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.6 Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Analysis of Candidate Application 234.1 Twelve-Factor App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Cloud-native Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Presentation of Cloud Strategy 265.1 Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Development Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.2 Integration/Production . . . . . . . . . . . . . . . . . . . . . . . 27

iv

CONTENTS v

5.3 Twelve-Factor App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3.1 Codebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.3 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.4 Backing services . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.5 Build, Release, Run . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.6 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.7 Port Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3.8 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3.9 Disposability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3.10 Dev/prod parity . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3.11 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3.12 Admin Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Implementation of Cloud Strategy 316.1 Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1.2 OpenShift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Development Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.1 Development Workflow Components . . . . . . . . . . . . . . . 37

6.3 Automation Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.3.1 Pipeline as Code . . . . . . . . . . . . . . . . . . . . . . . . . . 396.3.2 Dev/int/prod Workflow . . . . . . . . . . . . . . . . . . . . . . . 40

7 Evaluation and Results 437.1 Twelve-Factor App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.1.1 Codebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.1.3 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.1.4 Backing Services . . . . . . . . . . . . . . . . . . . . . . . . . . 447.1.5 Build, Release, Run . . . . . . . . . . . . . . . . . . . . . . . . . 457.1.6 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.7 Port Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.8 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.9 Disposability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.10 Dev/prod Parity . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1.11 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.1.12 Admin Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2 Cloud Native Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8 Conclusions 508.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Bibliography 52

A Dockerfile 56

CONTENTS vi

B Openshift template: trex-template.yaml 57

C Jenkins: Jenkinsfile, Jenkinstemplate. groovy and .env 59C.1 Jenkinsfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.2 Jenkinstemplate.groovy . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.3 .env . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

D Jenkins execution environment: Dockerfile 63

Chapter 1

Introduction

Cloud computing, as defined by the NIST1, is "a model for enabling ubiquitous, conve-nient, on-demand network access to a shared pool of configurable computing resources(e.g., networks, servers, storage, applications, and services) that can be rapidly provisionedand released with minimal management e�ort or service provider interaction"[1].

Applications can be delivered over the Internet using cloud computing[2]. However,they di�er from traditional applications deployed in traditional data centers. They shouldhave particular characteristics in order to take advantage of the full range of benefits of thismodel, such as being operated on automation platforms, use softwarization of infrastruc-ture and network, and migration and interoperability across di�erent cloud infrastructuresand platforms in mind. This kind of applications are known as cloud-native applications.

1.1 BackgroundIn order to take advantage of the cloud, traditional applications should be adapted to con-form with the cloud-native principles. This migration is not straightforward; it depends onthe particular characteristics of each application. However, some strategies are repeated,mainly when using the most popular technologies. One of the most popular languageswhen it comes to traditional enterprise applications is Java EE.

According to the TIOBE Index2, Java3 has been the most popular programming lan-guage since 2002. There are four editions of Java targeting di�erent application environ-ments. Java EE is the one targeting large distributed enterprise and Internet environments.

Several practices are repeated in Java EE applications: they have a similar code orga-nization, they use build systems, they communicate with external systems in similar ways,they use JavaScript frameworks for front-end, they deploy using binaries, etc[3]. Severalconventions are followed in this type of applications. Consequently, they will all followsimilar strategies when migrating to the cloud.

1NIST (National Institute of Standards and Technology), U.S. Department of Commerce -https://www.nist.gov/

2TIOBE Index - https://www.tiobe.com/tiobe-index/3Java - https://www.java.com

1

CHAPTER 1. INTRODUCTION 2

1.2 Problem DescriptionJava applications in general, and Java EE applications, in particular, are a standard in theIT industry. With the emergence of cloud computing, these applications should be adaptedto take advantage of the multiple benefits o�ered by this model.

However, how should Java enterprise applications be migrated to the cloud? The an-swer is not straightforward, as every application is di�erent and the strategy to migrateto the cloud should be adapted to each of them. Nevertheless, enterprise applicationstend to follow a set of conventions. Consequently, a set of strategies can be defined formigrating this type of applications to the cloud that can be repeated in a similar project.Twelve-Factor App[4] is the most well-know methodology documenting best practices forbuilding PaaS applications, and cloud-native principles[5] must be followed by any cloudapplication to take advantage of the full range of benefits of cloud computing.

In this project, we will transform a traditional Java enterprise application intoa cloud-native application following cloud-native principles and Twelve-Factor Appmethodology.

This thesis will use recommended strategies for creating cloud-native applications toa non-cloud Java enterprise application. It will show the process followed, the problemsfound and the solution chosen for solving them.

1.3 Purpose and GoalThe purpose of this thesis is to present a practical case of migrating an enterprise applica-tion to the cloud. I will apply the theory (Twelve-Factor App methodology) to a particularapplication in order to make it compliant with cloud-native principles.

I expect that this project will give developers a clear idea on how some strategies canbe applied to migrating Java EE applications to the cloud. By showing a practical case, Iwill provide an insight into the di�culties found and how I solved it, providing developerswith useful information for adapting their own enterprise applications to the cloud.

Consequently, three goals are pursued:

1. Analyze the targeted application, identifying which cloud-native principles are notfollowed.

2. Develop a strategy for making the application follow Twelve-Factor App methodol-ogy.

3. Perform the implementation of this strategy.

1.4 MethodThe method used in this project will be applied research, as defined by Hakansson[6].This method involves answering specific questions or solving known and practical prob-lems. The method examines a set of circumstances, and the results are related to a par-ticular situation. It often builds on existing research and uses data directly from the real


work and applies it to solve problems and develop practical applications, technologies, andinterventions. Applied research is used for all kinds of research or investigations, whichis often based on basic research and with a particular application in mind.

In this, I will be solving the practical problem of transforming a traditional applicationinto a cloud-native application. The characteristics of the traditional application will beexamined and how the resulting application fulfills the cloud-native principles. The projectwill use previous experience from developers for this purpose from literature. Particularly,a well-known methodology for building cloud-native application will be used: the Twelve-Factor App.

This thesis will follow an abductive approach[6]. This reasoning uses both deductiveand inductive approaches to establish conclusions. In the method, the hypothesis, whichbest explain the relevant evidence, is chosen. The approach starts with an incomplete set ofdata or observations and uses preconditions to infer or explain conclusions. The outcomeis a likely or possible explanation and is, hence, useful as heuristics.

This project starts with an original application that does not fulfill all the cloud-nativeprinciples. Twelve-Factor App methodology by Wiggins [4] and cloud-native principlesby Kratzke and Quint [5] are used as ground truth for requirements for a PaaS application,and changes will be made in the application in order to be compliant with them.

We will use an action research strategy. Action research is performed by actionsto contribute to practical concerns in a problematic situation[6]. This strategy seeks toimprove the way people solve problems using di�erent strategies, practices, and knowledgeof the environment. Action research studies setting with defined boundaries and, hence,qualitative methods are most suitable.

We will present action research in which we carry out a real-life example of the trans-formation of a traditional application to a cloud-native application. We will use severaldi�erent strategies in order to adapt the legacy application to the cloud.

We will evaluate our work using the Twelve-Factor App methodology[4]. This is aqualitative method by which we analyze if the final application fulfills each one of theprinciples of the methodology. Additionally, we will evaluate if our final application fol-lows cloud-native principles[5].

1.5 Ethics and SustainabilityEthics play a part in this project as it should be secure. Sensitive information, such as cre-dentials, is used. This information should be manipulated with appropriate security. Thetechnologies used in this project provide several mechanisms for this purpose. Besides,security recommendations for each of the technologies should be followed, such as usingnon-root users in Docker containers or not publishing credentials into the code and artifactrepositories.

Sustainability is a potential e�ect of this project. Cloud computing enables better use ofresources. Cloud applications allow dynamical changes in its assigned resources, adaptingthem to the demand. Consequently, fewer resources are idle, saving energy in data centers.Although this project does not focus on this branch of cloud computing, it takes the firststep to enable this kind of practices.


1.6 StakeholdersAmadeus[7] is a major IT provider for the global travel and tourism industry. Amadeusprovides search, pricing, booking, ticketing and other processing services in real-time totravel providers and travel agencies. It also o�ers travel companies software systems whichautomate processes such as reservations, inventory management, and departure control.As an IT provider, Amadeus is engaged with technological evolutions, mainly around fourpillars: cloud, data intelligence, security and open API.

Cloud computing has rapidly changed in the last decade, realizing computing as autility[8]. In order to take advantage of this innovation, Amadeus is moving in recent yearstowards cloud-based technology and distributed deployment of services[9]. Following thisstrategy, the FOR division within Amadeus is migrating towards cloud solutions, adaptingtheir internal tools to this new technology stack. They expect that these technologies willhelp them scale their applications and open to a wide variety of benefits, such as A/Btesting or multi-datacenter deployment.

This project will be developed in Amadeus as a proof-of-concept for migrating to thecloud. The candidate application will be one of their internal tools. The technologies usedin this project will be provided by the company and will be based on open source solutions.

1.7 DelimitationIn this project, we will not make changes to the original code provided by Amadeus.Legacy applications usually need changes in their architecture, such as breaking downmonoliths into microservices [8]. These modifications are out of the scope of this project,in which the candidate application for migration already has an adequate structure for thecloud. This project will also be limited by choice of technologies. Amadeus provides theirown cloud technologies that should be used. However, all of the Amadeus technologiesused in this project are enterprise layers on top of open source technology, so it is expectedthat the results can be replicated with the open-source versions. We will deploy the finalapplication in Amadeus private cloud. Nevertheless, our final application will be imple-mented in a way that can be easily deployed also in a public cloud, or any other privatecloud.

1.8 OutlineIn Chapter 2, we will provide the background necessary to understand the concepts pre-sented in this work. In Chapter 3, we will present the candidate application for cloudmigration, presenting its software architecture and development workflow. In Chapter 4,we will analyze the candidate application, describing which cloud-native principles andTwelve-Factor App principles does it fulfill, and which ones it does not and, consequently,need to be adapted. In Chapter 5, we will decide on a strategy for adapting the applica-tion to be cloud-native. In Chapter 6, we will describe the implementation process of thestrategy described in Chapter 4. In Chapter 7, we will evaluate our project from the pointof view of Twelve-Factor App and cloud-native principles. In Chapter 8, we will presentthe results and conclusions of our work.

Chapter 2

Theoretic Background

2.1 BackgroundIn this section, all the necessary background to understand this thesis is provided.

For understanding the application target of the migration, knowledge of Java EE, usu-ally referred as Java enterprise, is needed, as well as the frameworks used in the project.Knowledge about software development, such as environments, is also needed.

Cloud computing basics are also provided, as well as the motivation for using it insteadof traditional computing. Then, we introduce the concept of SaaS and cloud-native appli-cations followed by Twelve-Factor app, the methodology that will be used in this project.

2.1.1 Java EEJava is a general-purpose computer programming language that is concurrent, class-basedand object-oriented[10]. Java is one of the most popular programming languages in use[11][12].Java has several editions, being Java Platform, Standard edition the most well known. Forlarge distributed enterprise or Internet environments, the recommended edition is JavaPlatform, Enterprise Edition (Java EE).

Java allows application developers "write once, run anywhere" (WORA)[13]. Com-piled Java code run on all platforms that support Java without the need for recompilationthanks to the Java Virtual Machine. Java Virtual Machine (JVM)[14] is a virtual machinethat allows running Java programs compiled to Java bytecode, either written in Java or anyother language.

Java EE code is compiled to portable bytecode and packaged as a Web ApplicationArchive (WAR) Java Archive (JAR)1. WAR or EAR files comprise all classes and filesrequired to ship an application[3].

In enterprise projects the deployment of artifacts, the WAR or JAR file, should be de-ployed to an application container, such as Tomcat2 or WildFly3. The application containerintegrate additional concerns such as application life cycle or communication in variousforms. For example, communication over HTTP[15] or JDBC4.

1Open Source Java EE Reference Implementation - https://javaee.github.io/tutorial/packaging001.html

2Tomcat - http://tomcat.apache.org3WildFly - http://wildfly.org4Oracle Technology Network: JDBC - http://www.oracle.com/technetwork/java/

5

CHAPTER 2. THEORETIC BACKGROUND 6

Several Java frameworks provide an abstraction to build and deploy applications. Spring5

is one of them. The Spring Framework provides "a comprehensive programming and con-figuration model for modern Java-based enterprise applications on any deployment plat-form"[16]. A particular Spring’s convention-over-configuration[17], Spring Boot6, will beused. Spring Boot is Spring’s convention-over-configuration solution for creating stand-alone, production-grade Spring-based applications that the developer can "just run"[18].

2.1.2 Integration, Production, DevelopmentIn software development, di�erent environments are typically used[19].

• Development Working environment for developers. In it, radical changes to thecode can be performed without a�ecting the other environments.

• Integration Common environment where all developers commit code changes. Itis used to validate the work of all developers before promoting it to the stagingenvironment. It contains a limit subset of data useful for testing the application.

• Staging Environment as similar to the production environment as possible. Thepurpose of staging is to simulate as much of the Production environment as possible.Hardware and software configuration must be comparable to the production system.

• Production Environment from which the application is served for final use.

Although this is usual practice, it is not always followed in the same way. Dependingon the project, one of the environment might not be necessary. A common modificationis to perform staging in the integration environment.

2.1.3 Cloud ComputingCloud Computing, as defined by the National Institute of Standards and Technology (NIST)7,is "a model for enabling ubiquitous, convenient, on-demand network access to a sharedpool of configurable computing resources (e.g., networks, servers, storage, applications,and services) that can be rapidly provisioned and released with minimal management ef-fort or service provider interaction"[1].

A more high-level definition can be found in Armbrust et al. [2], for who cloud comput-ing refers to "both the applications delivered as services over the Internet and the hardwareand systems software in the data centers that provide those services".

Cloud model is composed of three service models, as defined by NIST [1]:

Infrastructure as a Service (IaaS) The capability provided to the consumer isto provision processing, storage, networks, and other fundamental computingresources where the consumer is able to deploy and run arbitrary software,which can include operating systems and applications. The consumer doesnot manage or control the underlying cloud infrastructure but has control over

javase/jdbc/index.html5Spring Framework - https://spring.io6Spring Boot - https://spring.io/projects/spring-boot7NIST (National Institute of Standards and Technology), U.S. Department of Commerce -

https://www.nist.gov/


operating systems, storage, and deployed applications; and possibly limitedcontrol of select networking components (e.g., host firewalls).

Platform as a Service (PaaS) The capability provided to the consumer is todeploy onto the cloud languages, libraries, services, and tools supported bythe provider. The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, or storage, buthas control over the deployed applications and possibly configuration settingsfor the application-hosting environment.

Software as a Service (SaaS) The capability provided to the consumer is touse the provider’s applications running on a cloud infrastructure. The appli-cations are accessible from various client devices through either a thin clientinterface, such as a web browser (e.g., web-based email), or a program in-terface. The consumer does not manage or control the underlying cloud in-frastructure including network, servers, operating systems, storage, or evenindividual application capabilities, with the possible exception of limited user-specific application configuration settings.

Cloud Computing present several advantages. Armbrust et al. [2] identify the followingones:

• Appearance of infinite computing resources on demand Traditionally, companiesneeded to plan far ahead for provisioning resources. With Cloud Computing, morecomputing resources are available on demand, quickly enough to follow load surges.

• Elimination of an up-front commitment by Cloud users Small companies canstart small and increase hardware resources when there is an increase in their needs,

• Ability to pay for the use of computing resources on a short-term basis as neededReal world estimates of average server utilization in data centers range from 5% to20%[20][21]. Since few users deliberately provision for less than the expected peak,resources are idle at non-peak times. The more pronounced the variation, the morethe waste. With cloud computing, resources can be paid as-you-go. If one serviceneeds only 100 servers at midnight, but 500 servers at noon, it will only be paid theservers that are used in each moment.

• Economies of scale due to very large data centers The construction and operationof large-scale commodity-computer data centers at low-cost location is the mainenabler of cloud computing, decreasing the cost of electricity, network bandwidth,operations, software, and hardware available.

• Higher utilization by multiplexing of workloads from di�erent organizationsWhen using Cloud Computing, resources are shared among organizations. Thisallows multiplexing the workload across the servers and resources. For example, ifone application uses maximum 30% of a server, while other needs maximum 40% ofa server, both can be allocated in the same server. By using statistical multiplexing,even more applications could be allocated in the same server. For example, twoapplications that require 60% utilization of the server, but rarely at the same time.Statistical multiplexing techniques can be used when both of them reach their peaksat the same time with some trade-o�s in performance, while the rest of the time both


will be able to access enough resources.

• Simplify operation and increase utilization via resource virtualization The sta-tistical multiplexing necessary requires automatic allocation and management. Forthis purpose, virtualization techniques are used. For IaaS, virtual servers are used.They might be o�ered as a single server, but one physical server in the data centermay contain several virtual ones. For PaaS, RAM and CPU are o�ered using virtu-alization, or even a running platform assigning automatically the resources needed,abstracting the management of resources from the user.

This new paradigm has great potential. For example, Slominski, Muthusamy, andKhalaf [22] uses cloud computing for enabling adaptive applications, where there couldbe application-specific flexibility in the computation that may be desired. The applica-tion adapts its resources depending on the needs of the application in each moment. Inthis way, the authors maximize the application QoS, while meeting both a time constraintand a resource budget limit. Another example is the work of Slominski, Muthusamy, andKhalaf [22] in which the use the resources of cloud computing to provide a multi-tenantapplication. They achieve tenant isolation by deploying each tenant’s application by us-ing a particular virtualization technique: containers. These containers are running in thesame resources thanks to cloud computing techniques, but they are isolated between them,containing the application of a single tenant.

2.1.4 SaaS and Cloud-Native ApplicationsAs just explained, cloud computing presents several advantages. However, to take advan-tage of the full range of benefits of cloud computing, applications need to be built consid-ering specific requirements, such as scalability, maintainability, and portability[23]. Thiskind of applications is known as cloud-native applications.

Kratzke and Quint [5] defines cloud-native application (CNA) as "a a distributed, elas-tic and horizontal scalable system composed of (micro)services which isolate state in aminimum of stateful components. The application and each self-contained deploymentunit of that application is designed according to cloud-focused design patterns and oper-ated on a self-service elastic platform".

Based on this definition, and analyzing cloud computing literature, Kratzke and Quint[5] states that cloud-native applications fulfill a set of principles:

• Being operated on automation platforms Automation platforms, also referred toas elastic platform, are platforms that can adapt to workload changes by provisioningand de-provisioning resources automatically.

• Using softwarization of infrastructure and network By using techniques such asInfrastructure ad Code or Pipeline as Code, the infrastructure an network can bedefined using code.

• Providing migration and interoperability across di�erent cloud infrastructuresand platforms As several cloud providers are o�ered, a need for being able to mi-grate and communicate easily from one to the other arose.

Sometimes is possible to read about CNA referred to as SaaS. CNA and SaaS are


closely related term but are not necessarily synonyms. CNA refers to the application,while SaaS refers to the method for providing the application to the client. Cloud-nativeapplications are designed to run in a PaaS o�ering with all their benefits and challenges,including elastic scalability and typically container technology. SaaS refers to applicationsthat are running in a cloud infrastructure, either CNA or monoliths delivered using a cloudinfrastructure.

The Twelve-Factor App[4] emerged as a methodology that documents best practicesfor e�ciently building SaaS. This methodology is getting widely adopted in industry[23].It provides best practices to achieve the properties for cloud-based deployments. The ap-plications built using Twelve-Factor App methodology, as defined by Wiggins [4]:

• Use declarative formats for setup automation, to minimize time and cost for newdevelopers joining the project;

• Have a clean contract with the underlying operating system, o�ering maximumportability between execution environments;

• Are suitable for deployment on modern cloud platforms, obviating the need forservers and systems administration;

• Minimize divergence between development and production, enabling continuous de-ployment for maximum agility;

• And can scale up without significant changes to tooling, architecture, or develop-ment practices.

The Twelve-factor App methodology defined the following factors. They are describedusing the o�cial documentation[4] complemented with Daschner [3] interpretation forJava enterprise projects:

1. Codebase The codebase of a single application is tracked in a single repository,containing all specifications for potentially di�erent environments. This factor lever-age developer productivity since all information is found under one repository. Therepository should contain all source files that are required to build and run the ap-plication, including Java sources, configuration files, and infrastructure as code.

2. Dependencies Explicitly declare and isolate dependencies required in order to runthe application. Explicitly specifying the version leads to far fewer compatibilityissues in production. Java applications specify their dependencies using build sys-tems. Container technologies simplify this principle by explicitly specifying all soft-ware installation steps. The resulting software artifacts should be accessible fromcentral repositories, such as artifact repositories.

3. Config Configuration varies substantially across environments, while code doesnot. Application configuration, which di�ers for separate environments, such asdatabases, external systems, or credentials, should be dynamically modified fromoutside of the application. This implies that configuration is retrieved via files, en-vironment variables or other external concerns.

4. Backing Services Backing services are those databases and external systems thatare accessed by the application. The resources must communicate with the applica-


tion in a loosely coupled way. In this fashion, they can be replaced by new instanceswithout a�ecting the application. Communication over HTTP or JDBC, for exam-ple, abstracts the implementations and enables systems to be replaced by others.

5. Build, Release, Run Application binaries are built, deployed, and run in separatesteps. This is a best practice for Java enterprise developers. Software and configura-tion changes happen in the source code or in the deployment step. The deploymentstep brings application binaries and potential configuration together. It is a commonpractice to separate these steps and orchestrate stages in a Continuous Integrationserver.

6. Processes Application should run as stateless processes. Potential state must bestored in an external database or discarded.

7. Port Binding Services are exposed via port binding. applications should be self-su�cient that expose their functionality via network ports. Java EE applicationssupport this approach, exporting a port which is used to communicate with the ap-plication.

8. Concurrency Cloud applications should be able to scale the workload increases. Inthis fashion, resources can be used in a savvy manner, only requesting those neces-sary for the workload at a particular moment. Ideally, the application should be ableto scale both horizontally and vertically.

9. Disposability: Applications are discarded and restarted often in the cloud, so theyshould be prepared to be correctly disposed. They should maximize robustness withfast startup and graceful shutdown, finishing in-flight requests and properly closingopen connection and resources. Java EE supports both fast startups and gracefulshutdowns, closing resources properly at JVM shutdown.

10. Dev/prod Parity Di�erences between environment should be minimal. Enterpriseapplications tend to have di�erences between the environments of the developmentprocess. The use of di�erent tools, technology, external services, and configura-tion introduce the risk that these di�erences may lead to errors. Maintaining de-velopment, staging, and production as similar as possible reduce these errors to aminimum.

11. Logs Enterprise applications traditionally write logs files on disk. This strategypresents several shortcomings[3]: lots verbose string objects that need to be stored,high use of CPU and memory, several layers of bu�ering, use of additional tech-nologies for logging that increase overhead, etc. In general, experience shows thatlogging has the biggest impact on an application’s performance. In contrast, cloudapplications argue that logging should be treated as a stream of logs events. Monitor-ing, journaling, or tracing solutions should be used instead of logs. The informationthat it is still left can be logged simply to the standard output, such a Java errors.Therefor logs should only indicate fatal problems that requires engineering action.

12. Admin Processes This factor describes principle describes that administrative ormanagement tasks should be executed as separate short-lived processes. In Java EEapplications, the number of required administration and management tasks are lim-ited. Administrative tasks are usually required for debugging and troubleshooting.


2.1.5 Cloud TechnologiesIn order to enable the development of a cloud-native application, a broad range of tech-nologies have emerged. In this project, the technologies are chosen in order to followcloud-native principles. Docker will be used to provide easy migration and interoperabil-ity. OpenShift will be used as elastic platform, based on Kubernetes, allowing to provisionand de-provision resources. Both Docker and OpenShift will be used for softwarizationof infrastructure and network.

Containers: Docker

Cloud Computing definition implies that computing resources are shared. Virtualizationis used for this purpose, mainly using two particular techniques: virtual machines andcontainers[24].

In a simplified explanation, virtual machines are based in a software called hypervisorthat sits on top of the physical hardware and abstract the host machines resources. Thistechnology allows creating multiple simulated environments of dedicated resources from asingle, physical hardware system. This simulated environment is called a virtual machineand it is used extensively in cloud computing, particularly for IaaS[25]. However, thistechnology has some drawbacks. Each virtual machines includes a separate operatingsystem image, which adds overhead in memory and storage footprint. This results in slowstart-up time and some loses in performance[25].

In order to overcome the drawbacks of virtual machines, a new virtualization technol-ogy was developed: containers[26]. Containers refer to an implementation of operatingsystem-level without a dedicated kernel. Unlike virtual machines, container virtualizationdoes not mimic a physical server with its own OS and resources. This type of virtualizationenables applications to execute in a common OS kernel. There is no need for a dedicatedkernel for each application, and thus impose a lower overhead compared to virtual ma-chines. Containers provide faster deployment and elasticity than virtual machines, as wellas better performance[25].

There are di�erent container solutions. The first standard distribution was LXC8, laterexpanded with LXD9. Another alternative is CoreOS rkt10. However, the most popularand de facto containers solution is Docker. Docker11 is an open source project that pro-vides a systematic way to automate applications inside portable containers. Packagingexisting apps into containers immediately improve security, reduce costs, and gain cloudportability.

Docker containers are created using base images12. A container image, or simply im-age, is "a lightweight, stand-alone, executable package of a piece of software that includeseverything needed to run it: code, runtime, system tools, system libraries, settings" 13. Im-ages can be created manually, but typically they are built using Dockerfiles. A Dockerfileis a script that defines a set of steps for building the image, such as commands or argument.

8LXC - https://linuxcontainers.org/lxd/introduction/9LXD - https://linuxcontainers.org/lxd/introduction/

10rkt - https://coreos.com/rkt/11Docker - https://www.docker.com/12Docker: about images, containers and storage drivers - https://docs.docker.com/v17.09/

engine/userguide/storagedriver/imagesandcontainers/13Docker: what is a container - https://www.docker.com/resources/what-container


Each of these steps taken for creating an image adds a new layer on top of the previousone.

Orchestrators: Kubernetes

In order to manage containers, we used orchestrators. Orchestrators are in charge of auto-matic deployment, scaling, and general management of containers.

There are di�erent technologies (Mesos, Marathon). Kubernetes is one of the mostpopular solutions for orchestrating Docker containers in production environments.

The main objects provided by Kubernetes are 14:

• Pod A Pod is the basic building block of Kubernetes. It represents a running process.A Pod encapsulates an application container, storage resources, a unique network IP,and options that govern how the container should run. A Pod represents a unit ofdeployment: a single instance of an application in Kubernetes, which might consistof either a single container or a small number of containers that are tightly coupledand that share resources.

• Service A Service is an abstraction which defines a logical set of Pods and a policyby which to access them. Pods are mortal. They are born, and when they die, theyare not resurrected. Replication Controllers, in particular, create and destroy Podsdynamically (e.g., when scaling up or down or when doing rolling updates). Whileeach Pod gets its own IP address, even those IP addresses cannot be relied upon tobe stable over time. Service solves this problem by providing a permanent mean toaccess a set of Pods.

• Volume A Volume is a directory, possibly with some data in it, which is accessibleto the containers in a pod. On-disk files in a container are ephemeral, so everythingthat needs to be persisted during the lifetime of a Pod needs to be stored in a volume.

In addition, Kubernetes contains a number of higher-level abstractions called Con-trollers. Controllers build upon the basic objects and provide additional functionality andconvenience features. They include:

• Replication Controller A Replication Controller ensures that a specified number ofpod replicas are running at any one time. In other words, a Replication Controllermakes sure that a pod or a homogeneous set of pods is always up and available.If there are too many pods, the Replication Controller terminates the extra pods.If there are too few, the Replication Controller starts more pods. Unlike manuallycreated pods, the pods maintained by a Replication Controller are automatically re-placed if they fail, are deleted, or are terminated.

• Deployments A Deployment controller provides declarative updates for Pods andReplication Controllers. The desired state is described in the Deployment object,and the Deployment controller changes the actual state to the desired state at a con-trolled rate. Deployments create new Replication Controller, or remove existingDeployments and adopt all their resources with new Deployments.

14Kubernetes: concepts - https://v1-7.docs.kubernetes.io/docs/concepts/


PaaS: OpenShift

Containers and orchestration tool should be hosted and managed by a platform, typi-cally a Platform as a Service (PaaS). There are several alternatives such as AWS ElasticBeanStalk15, Google App Engine16, or Cloud Foundry17. Red Hat o�ers a solution partic-ularly suitable for containers and based in Kubernetes: OpenShift.

OpenShift18 is "an open source container application platform by Red Hat based ontop of Docker containers and the Kubernetes container cluster manager for enterprise appdevelopment and deployment"[27]. It provides hosting for containers as well as extendsKubernetes features. For example, OpenShift provides an integrated software-defined net-working and load-balancer (e.g., HAProxy, F5, etc.) for managing Kubernetes services.It also provides handling of routes for exposing services to the outside world, as well as atemplating and a service catalog.

The minimum deployment unit in OpenShift is a Pod. Containers are contained insidea Pod.

A Kubernetes Pod defines:

• Container Same concept as Docker container, explained in 2.1.5.

• Volumes Same concept as Kubernetes Volume, explained in 2.1.5.

Pods are managed by controllers. For pods that are not expected to terminate, such asweb servers, a Replication Controller should be used. Kubernetes ReplicationController19

object ensures that a specified number of pod replicas are running at any one time, makingsure that a pod or a homogeneous set of pods is always up and available.

A Kubernetes ReplicationController object defines the following settings:

• The number of replicas desired (which can be adjusted at runtime).

• A pod definition to use when creating a replicated pod.

Openshift expands the ReplicationController with the concept of deployment, addingexpanded support for the software development and deployment life-cycle. Deploymentare defined using the OpenShift DeploymentConfig20 object. They are created manuallyor in response to triggered events.

The OpenShift DeploymentConfig object defines the following details of a deployment:

• The elements of a Replication Controller definition.

• The strategy for transitioning between deployments.

• Triggers for creating a new deployment automatically.15AWS Elastic BeanStalk - https://aws.amazon.com/elasticbeanstalk/16Google App Engine - https://cloud.google.com/appengine/17CloudFoundry - https://www.cloudfoundry.org/18Openshift - https://www.openshift.com19ReplicationController - https://kubernetes.io/docs/concepts/workloads/

controllers/replicationcontroller/20OpenShift: Deployments and deployment configuration - https://docs.openshift.com/

container-platform/3.7/architecture/core_concepts/deployments.html#deployments-and-deployment-configurations


All Kubernetes objects are present in OpenShift, but not all OpenShift objects arepresent in Kubernetes. It is accurate to refer as OpenShift objects to those objects that arepresent in OpenShift but not in Kubernetes, and as Kubernetes objects those only presentin Kubernetes. However, for the sake of simplicity, in this thesis sometimes Kubernetesnative objects will also be called OpenShift objects.

2.1.6 Continuous DeploymentSeveral recommendations from Twelve-factor App are achieved not through the code, butwith development workflows. Development workflows are about defining the process fromthe writing of the source code until the running of the application in production. Forcloud applications, development workflows should run automated and reliably with aslittle human intervention as possible [3].

Development workflows can have di�erent levels of complexity. Build systems area basic start, automating compiling, resolving dependencies, and packaging of softwareprojects. Continuous Integration takes one step further, orchestrating the whole develop-ment workflows from building artifacts to automated testing and deployments. ContinuousDelivery builds over Continuous Integration, automating the shipping of built software tospecific environments on each build. Continuous Deployment expands the concept ofContinuous Integration by automatically deploying each committed software version toproduction.

The main building block of the Continuous Delivery process is the automation pipeline.This automation pipeline will include several steps, such as retrieving the code from therepository, publishing the artifacts or deploying the app. In each of this steps other tech-niques are used: code repository, artifacts repository, testing tools, or deployments plat-forms.

In this thesis, testing phases will not be included due to our application not containingany test. This is not a recommended practice: tests should be added to the application.However, this task is outside of the scope of the presented work.

Several techniques can be used in automation pipelines. In this project’s pipeline, two

Figure 2.1: High-level overview of Continuous Delivery pipeline. Obtained fromDaschner [3]

.


techniques are used: IaS and PaC.

• Infrastructure as Code (IaC) The idea behind IaC is that all required steps, con-figuration, and versions are explicitly defined as code. These code definitions aredirectly used to configure the infrastructure. This can be done in di�erent ways,from shell scripts to declarative way using additional tools. IaC will be used whenusing containers and PaaS. The former will enable the building of containers auto-matically with the automation pipeline. The latter will enable describing the PaaSinfrastructure using code to be automatically deployed.

• Pipeline as Code (PaC) Pipeline as code definitions specify the Continuous De-livery pipeline as part of the software project. In this project, PaC will be used toconfigure the automation pipeline using code.

Automation Pipeline: Jenkins

Continuous Delivery pipelines consist of several pipeline build steps that are executed aspart of a single build. Builds are usually triggered by committing or pushing code changesinto version control.

There are several automation pipeline tools, such a Travis CD, Codeship or Jenk-ins. For this project, Jenkins will be used. Jenkins21 is the leading open source automa-tion server. It provides tools for Continuous Integration and Continuous Delivery usingpipeline as a code. In Jenkins, pipeline as a code is defined in a Jenkins file, which isdenied using Groovy DSL. Groovy is an optionally typed, dynamic JVM language, thatsuits well for DSL and scripts.

Jenkins architecture is Master+Agent22. The master is designed to do coordination andprovide the GUI and API endpoints, and the Agents are designed to perform the work. Aserver that runs an agent is often referred to as Node.

Version Control System (VCS) and Code Repository: git and Bitbucket

Twelve-factor App methodology recommends that the application is always tracked in aversion control system. A code repository is a copy of the revision tracking database. It isoften shortened to code repo or just repo. The motivation behind this practice is to keepall code needed to build the application in one central place. The first step of a ContinuousDeployment pipeline is the retrieval of code from the code repository.

Several version control systems are o�ered, such as git23 or SVN24. The former onewill be used in this project. Several solutions can be found to store the code based on git,such as GitHub25, GitLab26 or Bitbucket27. The latter will be used in this project.

Several git related concepts will be used in this project:21Jenkins - https://jenkins.io/22Jenkins: Distributed Builds - https://wiki.jenkins.io/display/JENKINS/

Distributed+builds23Git - https://git-scm.com24Apache Subversion (SVN) - https://subversion.apache.org25GitHub - https://github.com26GitLab - https://gitlab.com27Bitbucket - https://bitbucket.org


• Commit Record changes in the repository.

• Release Git o�er the feature to add tags to specific points in history as being impor-tant. This functionality is typically used to mark release points.

• Branch Git object data for multiple commits. A branch in Git is a movable pointer toone commit. The default branch name in Git is master. When the developer initiallymakes commits, she is given a master branch that points to the last commit made. Ifshe creates a new branch, a new pointer is created for that branch.

Build Artifact: Maven

The build process is the step in which Java code is compiled into bytecode. This stepis repeated every time changes are made in the project. In the enterprise world, severaldi�erent frameworks and libraries are used in the same project. Consequently, it is essen-tial to organize and define all dependencies on APIs and implementations [3]. Packagingthe compiled classes and their dependencies into deployment artifacts is also part of thebuild process. Build systems are integrated and launched fro the Continuous Deploymentpipeline.

Apache Maven28, also referred as Maven, and Gradle29 are two popular build tools forJava. In this project, Apache Maven will be used. Maven addresses two aspects of buildingsoftware: first, it describes how software is built, and second, it describes its dependencies.An XML file describes the software project being built, its dependencies on other externalmodules and components, the build order, directories, and required plug-ins. It comeswith pre-defined targets for performing certain well-defined tasks such as compilation ofcode and its packaging.

Build Container: Docker

Docker was already introduced in 2.1.5. One step of the Continuous Deployment is tobuild the Docker image, containing all software necessary for the application to work.

Docker Registry: JFrog Artifactory

Twelve-factors App methodology does not only recommend to track the code in a versioncontrol system but all artifacts. The motivation behind this practice is to keep all theartifacts needed to ship the application in one central place. Artifacts repositories save thebuilt artifact version for later retrieval. This is important for SaaS applications since it isneeded to access the previous version of the application, for example, for rollback, or fordeploying a di�erent version to integration and production.

There are several solutions, most of them depending on the kind of artifacts that needto be stored. Since our artifacts will consist of Docker images, it is needed a solutionproviding version controls for them. Some technologies are Sonatype Nexus or JFrogArtifactory. We use JFrog Artifactory.

28Apache Maven - https://maven.apache.org/29Gradle - https://gradle.org/


2.2 Related WorkSimilar work can be found in research literature. Balalaie et al. [28][29] present theirexperiences in migrating a Java application to the cloud. The work presents the originalarchitecture before migration to the cloud, the target architecture, and the migration steps.Instead of migrating a single service as presented in this master thesis, it presents the mi-gration of several microservices. Development workflows are also implemented, allowingContinuous Deployment. They use similar technologies: Docker, Kubernetes, Jenkins.Instead of deploying to OpenShift they deploy to a CoreOS cluster, and they use GitLabinstead of BitBucket as code repository, both using git as version control technology. Theyprovide a high-level view of their migration process. In contrast, this master thesis willprovide further details of each step and its configuration.

Certain parts of the project resemble other people work. A part of Slominski, Muthusamy,and Khalaf [22] work is similar to our project. In their project, the migration to the cloudis the first step toward reaching a multi-tenant cloud service. Truyen et al. [30] proposean architecture, in a similar way as our Chapter 5. A SWOT analysis of pros and consis made, but an implementation is not presented. Pahl [31] focus on the containerizationof application, discussing the requirements, for later deployment to PaaS. Wurster et al.[23] uses Twelve-Factor App methodology to build scalable, maintainable, and portableapplications.

Chapter 3

Architecture of Candidate Application

The candidate application for migration to PaaS is T-REX Original, an Amadeus internaltool. From now on, when referring to T-REX Original as the application previous to themigration, it will be called as T-REX Original Original.

In this chapter, T-REX Original software architecture, technologies used, deploymentand development workflow is presented.

3.1 Software ArchitectureT-REX Original is a web application that works as a Jenkins templater. It is a User Interface(UI) to create and launch automated test campaigns for Amadeus internal tools. That waythe developer can already have a preliminary assessment of the quality of her tests, beforetrying to merge the changes in the codebase or deliver it to the client.

Figure 3.1: T-REX Original User Interface

T-REX Original follows a traditional client-server architecture, formed by a front-endand a back-end. The front-end allows selecting the configurable options for the automatedtest. The back-end is in charge of creating and launching this test in Jenkins.

18

CHAPTER 3. ARCHITECTURE OF CANDIDATE APPLICATION 19

The application is served with a Tomcat server. This server is shared with another twoapplications, both Amadeus internal tools: Slam and Cops.

The applications make use of two databases: T-REX database and Spin database. Theconnection with these databases is made using JDBC.

Communication with external dependencies (LDAP, Carto Service, and Jenkins in-stance) is done through HTTP. In addition, the authentication is done through AmadeusLDAP1. The tests are created in a Jenkins instance.

Figure 3.2: T-REX Original Software Architecture

3.2 TechnologiesT-REX Original back-end is developed with Java EE. In order to facilitate the back-enddevelopment, the Spring Framework is used, with Spring’s convention-over-configuration,Spring Boot.

T-REX Original front-end is developed with AngularJS2. Angular JS is a JavaScriptfront-end web application framework[32]. It works combined with HTML3 and CSS4.

T-REX Original development workflow is composed by a codebase repository, an au-tomation server to perform Continuous Build, and the server in which the application run.Bitbucket5is used for the codebase repository, Jenkins6 as automation server for Continu-ous Build and Apache Maven7 as Java build tool.

1Lightweight Directory Access Protocol - https://msdn.microsoft.com/en-us/library/aa367008(v=vs.85).aspx

2AngularJS - https://angularjs.org/3HTML - https://www.w3.org/html/4https://www.w3.org/Style/CSS/5Bitbucket - https://bitbucket.org/6Jenkins - https://jenkins.io/7Apache Maven - https://maven.apache.org/


3.3 CodebaseT-REX Original codebase is stored in Amadeus Bitbucket. It has two main branches:’master’ and ’next’. The ’master’ branch contains the production code. The ’next’ branchcontains development and integration code.

For development, ’next’ branch is used. The developer should launch with Maven usingthe ’development’ profile. For integration, ’next’ branch is used, and a file ROOT.xml withDataSource configuration is present in the integration server. For production, ’master’should be used, and a file ROOT.xml with DataSource is present in the production server.

3.4 DeploymentIn a traditional structured process for software development, there are four tiers: develop-ment, integration, staging, and production, as introduced in 2.1.2.

In T-REX Original, development, integration and production tiers are used. Stagingwas not found necessary by the creators of the application.

Spring Boot provides a mechanism for enabling di�erent configurations for di�erentenvironments: Spring Boot profiles. By using profiles, a di�erent configuration is set upfor development, integration, and production.

Each of the environments is set up as follows:

• Development The application run on the developer’s workstation. T-REX Originalis served by an embedded Tomcat server provided natively by Spring Boot. Devel-opment versions of T-REX database and Spin database should be running in a localserver in the developer workstation. The application is started with Maven. For thistier, the ’development’ Spring Boot profile is used.

• Integration T-REX Original is deployed in a Tomcat server reserved for integration.This server has access to the LDAP, the databases, and the Jenkins instance. Thisversion connects to an integration version of T-REX Original DB and Spin DB.For this tier, the ’integration’ Spring Boot profile is used. Tomcat server shouldbe manually preconfigured to serve this application. Every time the application isupdated, the developer stops the Tomcat server, substitute the old binaries with thenew binaries and restart the server.

• Production T-REX Original is deployed in a Tomcat server reserved for production.This server has access to the LDAP, the databases, and the Jenkins instance. Thisversion connects to the production version of T-REX Original DB and Spin DB.For this tier, the ’production’ Spring Boot profile is used. Tomcat server shouldbe manually preconfigured to serve this application. Every time the application isupdated, the developer stops the Tomcat server, substitute the old binaries with thenew binaries and restart the server.

In order to connect to the T-REX Original and Spin databases, JDBC is used. Javauses DataSource8 interface to connect through JDBC. Since each software developmenttiers connect to a di�erent version of the database, di�erent DataSources should be pro-

8Java 8, Interface DataSource - https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html


vided. DataSource for development is provided in ’development’ profile. The DataSourcefor integration and the DataSource for production are not present in the Spring Boot pro-file, but in the Tomcat configuration. They should be set up manually in the integrationTomcat server and the production Tomcat server. This is due to security reasons, and it isa usual practice[3]. Integrations and production versions of the databases require creden-tials, and they should not be publicly visible in the code repository. The DataSource withthe correspondent credentials will be configured manually in the integration server and inthe production server using the context container9.

3.5 Development WorkflowDi�erent development workflows for development, integration, and production.

• Development All steps are performed manually by the developer. The code is clonedfrom Bitbucket into the developer workstation. The code is deployed locally usingMaven. Spring Boot provides an embedded Tomcat server to run the application.The developer workstation should be able to access the databases, the LDAP and theGhost Service.

• Integration Continuous Build, launched automatically, and manual deployment.A Jenkins job performs Continuous Build using the following steps. Every timethere is a new commit in the branch ’next’, Jenkins job checkout T-REX Originalcode from Bitbucket. The Jenkins job uses Maven to build the binaries: a WARfile. Once built, the developer performs the manual deployment. The WAR file isdeployed manually in the integration server. The integration server should be ableto access the databases, the LDAP and the Ghost Service.

• Production Continuous Build, launched manually, and manual deployment. AJenkins job performs Continuous Build using the following steps. Every time anew release is prepared from ’master’ the Jenkins job is manually started. Then, theJenkins job checkout T-REX Original code from Bitbucket. The Jenkins job usesMaven to build the binaries: a WAR file. Once built, the developer performs themanual deployment. The WAR file is deployed manually in the production server.The production server should be able to access the databases, the LDAP and theGhost Service.

3.6 CredentialsT-REX Original uses di�erent types of credentials:

1. T-REX database and Spin DB credentials For development, credentials are pro-vided in the Spring Boot profile. For integration and production, credentials for thedatabases are specified in the context of the Tomcat server, using the ROOT.xml file.For doing so, the developer accesses the server manually and set it up.

9Apache Tomcat: The Context Container - https://tomcat.apache.org/tomcat-8.0-doc/config/context.html


Figure 3.3: T-REX Original Integration/Production Workflow

2. Bitbucket For development, Bitbucket credentials are provided by the developer. Inthe Continuous Build, they are provided in Jenkins using Jenkins Credentials10.

10Jenkins Credentials Binding - https://plugins.jenkins.io/credentials-binding

Chapter 4

Analysis of Candidate Application

In this chapter, T-REX is analyzed to asses its compliance with cloud-native principles.For doing so, we used Twelve-Factor App methodology[4] and the cloud-native principlesdefined by Kratzke and Quint [5] .

4.1 Twelve-Factor AppThe candidate application is not natively prepared to run in PaaS. In this section, Twelve-Factor App methodology is to discover the lacking properties for the application to beserved with the cloud.

1. Codebase As explained in subsection 3.3, T-REX software code is kept under ver-sion control in a single repository, containing all specifications for potentially dif-ferent environments. However, some files are not present in this codebase: thosecontaining credentials. This is a usual security practice. These files are added man-ually to the production server.

2. Dependencies As usually happens in Java applications [3], T-REX dependenciesare declared using a build system: Maven. Besides, software artifacts should beaccessible via well-defined processes. Dependencies need to be distributed from acentral place. For T-REX Original, the primary software artifact is the WAR file.This file is built in Jenkins and store in its internal file system, but it is not publishedto any central artifact repository from which it can be accessed via distinct processes.

3. Store config in environment A part of the configuration is done automaticallythrough Spring Boot profiles, which are selected using environment variables. An-other part is done manually in the Tomcat server by the developer.

4. Backing Services T-REX backing services consist of the databases (T-REX andSpin) and the attached services (LDAP, Jenkins, and Carto). Both databases areconnected using JDBC, and the services are connected using HTTP. Consequently,T-REX backing services fulfill this factor.

5. Build, Release, Run This a popular approach to Java enterprise developers and itis followed in T-REX. However, a big part of this process is manual. T-REX has setup a Continuous Build with Jenkins for integration and production. The release isdone manually by the developer, getting the resulting file of the Continuous Build

23

CHAPTER 4. ANALYSIS OF CANDIDATE APPLICATION 24

1 2 3 4 5 6 7 8 9 10 11 12T-REX Original 3 7 7 3 7 7 3 7 3 7 7 3

Table 4.1: T-REX Original compliance with Twelve-Factor App

and putting it into the Tomcat server. Run is also manual as the developer stop, startand restart the Tomcat server to serve the application.

6. Processes: Although T-REX is mainly a stateless application, it still needs one state-ful process: sticky sessions. Sticky session is a mechanism in which sessions arestored in the local application instance. Consequently, if more than one instance isrunning at the same time, the session will be lost.

7. Port Binding Java EE applications typically expose services via port binding. AsJava EE application, T-REX also exposes its functionality via network port. Itsfunctionality exposes a UI for the user. Consequently, T-REX already fulfills thisfactor.

8. Concurrency T-REX is not able to scale out via the process model. T-REX canscale vertically in the server in which it is deployed. However, scaling verticallyis limited, since resources on the physical server are limited. T-REX is not able toscale horizontally in an easy way. For doing so, it would be needed to set up a loadbalancer that redirects users to the appropriate instance, keep sessions, maintainsconsistency across instances, etc.

9. Disposability As Java EE application, T-REX support fast startup and graceful shut-down, closing resources properly at JVM shutdown. Consequently, T-REX fulfillsthis factor.

10. Dev/prod Parity Development environment di�ers significantly from integrationand production environment. Integration and production have the same structuredeployed in di�erent servers. This also suppose a risk since the servers could havedi�erent configurations.

11. Logs: We can find di�erent logs in T-REX, such as Java logs from the code, Catalinalogs from the Tomcat server. They are written into disk using a log rotation strategy.This is not the recommended way of dealing with logs for cloud applications, as theyshould only write to the standard output instead of keeping them on disk.

12. Admin Processes: the servers in which T-REX is deployed allow to run adminis-trative tasks, so this factor is fulfilled.

4.2 Cloud-native PrinciplesThe candidate application is not prepared to run in the cloud. In this section, its compliancewith cloud-native principles is analyzed.

• Operated on automation platforms T-REX is operated in a traditional server andserved by Tomcat. This is not an automation platform, so this principle is violated.

• Softwarization of infrastructure and network Its infrastructure is configured man-

CHAPTER 4. ANALYSIS OF CANDIDATE APPLICATION 25

ually by the developer or the operation team maintaining the server. It is not definedby software, so this principle is violated.

• Migration and interoperability across di�erent cloud infrastructures and plat-forms T-REX migration is not prepared for easy migration from one cloud infras-tructure to another, and it is even less prepared for interoperability among them.This principle is violated.

Chapter 5

Presentation of Cloud Strategy

In this chapter, it is given an overview of the strategy followed to adapt T-REX Original tobe deployed in PaaS. The version prepared for PaaS will be referred as T-REX PHACO,being PHACO the PaaS instance in which T-REX aims to be deployed.

This chapter presents three sections. In Cloud Architecture, we describe the high-levelarchitecture that will be used for deploying T-REX PHACO in the PaaS. In DevelopmentWorkflow, we will describe the strategy not related to the PaaS, including the ContinuousDeployment pipeline or the code and artifact repositories used. In Twelve-Factor Appsection, we will present how each principle of the methodology will be fulfilled with thisstrategy.

Figure 5.1: Target T-REX Cloud Architecture

26

CHAPTER 5. PRESENTATION OF CLOUD STRATEGY 27

5.1 Cloud ArchitectureT-REX PHACO will be deployed in PHACO, an OpenShift 3.6 instance. This PaaS isbased in Kubernetes 1.6 and Docker 1.12.

A Docker image will be created, T-REX PHACO image, based in a Tomcat image.T-REX PHACO code will be served by the Tomcat server inside this container.

We will deploy this container inside a Pod. A Pod is the smallest compute unit that canbe defined, deployed and managed by OpenShift.

• Each Pod has its own networking and storage, sharing it with its containers. The Podexposes the ports that should be reached from the exterior world using a Service.This Service will be attached to a Route for the application to be accessed.

• The credentials needed inside the applications will be defined by Secrets accessedby the Pod.

• The Pod will assign resource limits to the container (CPU and memory).

In order to deploy a Pod, we need a Deployment Configuration. A Deployment Con-figuration will manage the life cycle of a Pod. Each Pod has a life cycle; they are defined,then they are assigned to run on a node, then they run until the containers exit, or they areremoved.

• It will define the number of Pods that should run concurrently. These concurrentPods are known as Replicas.

• It will define the deployment strategy. This will be used for deploying the Pods forthe first time, but also for redeployment and rolling back.

5.2 Development Workflow

5.2.1 DevelopmentIn the development environment, developers try radical changes to the code[19]. It shouldbe relatively fast to see the changes implemented to facilitate the work of the developer.

The development environment will only consist in the T-REX PHACO container, basedin Tomcat, with T-REX artifacts placed inside. The developer will be able to compile,build and debug inside this container without the need a complete Continuous Deploymentpipeline.

5.2.2 Integration/ProductionOur integration development workflow will be based in a Continuous Deployment pipeline.It will consist in a codebase repository, an automation server, an artifacts repository andOpenShift.

• We will use Jenkins as automation server, particularly Software Workbench, anAmadeus private Jenkins. The purpose of the automation server is to perform thesteps of the Continuous Deployment pipeline.


• We will use Bitbucket as codebase repository, particularly Amadeus private Bit-bucket. The purpose of the codebase repository will be to provide the code andconfiguration for the Continuous Deployment pipeline.

• We will use jFrog Artifactory as artifacts repository, particularly Amadeus privatejFrog Artifactory. The purpose of the artifactory is to store the Docker imagesneeded for our project to run. OpenShift needs a Docker repository from whichto pull the images for deployment.

• We will use OpenShift as our cloud platform, particularly PHACO, an Amadeusprivate OpenShift instance. The purpose of the cloud platform is to deploy ourapplication in the cloud.

The process will consist of three phases: build, publish and deploy.

• Build T-REX PHACO code and configuration will be obtained from the Bitbucketrepository. T-REX PHACO image will be built.

• Publish T-REX PHACO image will be published to jFrog Artifactory, making themavailable for deployment in the cloud.

• Deploy T-REX PHACO image will be deployed in OpenShift.

5.3 Twelve-Factor AppWith the strategy presented, it is expected to fulfill the Twelve-Factor App methodologyin the following way.

5.3.1 CodebaseThe original repository of T-REX will be used, adding the new files required for T-REXPHACO. Files with sensitive information will not be published, following the same strat-egy in T-REX PHACO as in T-REX Original for security reasons. Files with sensitiveinformation will be added manually to the Pod as a Secret.

Figure 5.2: Technologies used in T-REX PHACO development workflow


5.3.2 DependenciesDocker will be used to specify all software installation steps. These steps will includeMaven as build tool, as in T-REX Original, among other steps to build the Docker image.In addition, the resulting T-REX PHACO Docker image will be published to a centralartifact repository, JFrog Artifactory, for easier distribution.

5.3.3 ConfigConfiguration will be done using files, environment variables, and other external concerns.Tools provided by Bitbucket, Jenkins, and OpenShift will be used to store the configurationin the environment.

• In Bitbucket, we will store T-REX code, Jenkins pipeline code, and OpenShift tem-plates.

• In Jenkins, we will set up credentials for getting the code from Bitbucket, and fordeploying to OpenShift.

• In OpenShift, we will store credentials used inside the application.

In addition, configuration will dynamically change using environment variables inDocker and OpenShift.

5.3.4 Backing servicesT-REX PHACO will keep T-REX Original, as it already fulfilled this factor.

5.3.5 Build, Release, RunThis factor was partially met in T-REX Original, but it was not fully automatized. T-REXPHACO makes use of a Jenkins server to automatize the build, publish and deploy stepsin a Continuous Deployment strategy.

5.3.6 ProcessesSticky sessions strategy cannot be changed without making changes in the original codeof T-REX. OpenShift will provide an strategy to maintain sessions,called sticky session1.The router always sends the same user to the same Pod, in which the session is persisted.This is not an ideal solution, and there is room for improvement.

5.3.7 Port BindingT-REX Original already complied with this factor. The challenge consists of, after usingthe new technologies needed for T-REX PHACO, still exposing T-REX functionality viaport binding. This will be done using OpenShift networking, that allows exposing theapplication port to the exterior world.

1OpenShift Routes - https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html


5.3.8 ConcurrencyDocker, Kubernetes, and OpenShift together enable concurrency, being able to scale throughthe process model. Docker containers will be easily disposable and reproducible. Theywill be orchestrated by Kubernetes in an OpenShift instance, providing deployment strate-gies, rollback to the previous version and running several replicas of the same application.OpenShift allows configuring the resources assigned to the application, enabling verti-cal scaling. It also allows to choose the number of replicas, providing an internal routerwhich takes care of sending the same user always to the same replica, keeps sessions andmaintains consistency across instances.

5.3.9 DisposabilityT-REX Original already complied with this factor. T-REX original rarely needed to makeuse of fast startup and graceful shutdown. In contrast, T-REX PHACO will require tomake use of these mechanisms more often. By definition, Docker containers and Pod areoften recreated and therefore are treated as expendable2.

5.3.10 Dev/prod parityDocker containers make easier the work of keeping the same environment. The sameDocker image, T-REX PHACO image, will be used in all environments, with only smallchanges in the configuration. Consequently, the same configuration steps will be followedand the same software version will be used: those defined by T-REX PHACO image.Independently of the workstation or server in which the application will be deployed, it willalways be wrapped in the same container with all software needed to run the application.

5.3.11 LogsT-REX PHACO writes the logs to the standard output and does not persist them on disk,following the Twelve-factor App recommendation. Docker and OpenShift provide mech-anisms for reading the standard output as a stream of events, in which only Java errors willbe shown. These errors will indicate fatal problems that require engineering action.

5.3.12 Admin ProcessesT-REX Original already fulfilled this factor. The challenge will be to maintain this featurein T-REX PHACO, as traditional servers will be substituted with PaaS. Containers en-capsulate Unix processes, which will provide additional functionality to execute a singlecommand or to open a remote shell in a container. By using Docker and OpenShift, it ispossible making use of this feature.

2OpenShift: Pods and Services - https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/pods_and_services.html

Chapter 6

Implementation of Cloud Strategy

In this section, it is the described the implementation of the cloud strategy presented in theprevious chapter. In the two sections forming the chapter, Cloud Architecture and Devel-opment Workflow, it is described how each of them has been implemented respectively.

6.1 Cloud ArchitectureThis section describes the implementation of the targeted architecture. It shows how thedi�erent design decisions have been solved.

6.1.1 DockerT-REX PHACO image contains everything needed for running the application. A Dockerimage is defined using a Dockerfile. A Dockerfile[33] is a text document that contains allthe commands to assemble an image. It is possible to find T-REX PHACO Dockerfile inAppendix A. It contains the following components and configurations:

• Alpine Linux as Operating System

• JRE 8 as runtime environment

• Tomcat as webserver, with correspondent configuration files

• T-REX artifacts, with correspondent configuration files

• Configuration of root permissions

• Configuration of JVM

Docker development best practices [34] recommend creating images as small as possi-ble. Small images are faster to pull over the network and faster to load into memory whenstarting containers or services. T-REX PHACO image uses Alpine Linux as OperatingSystem to keep the image small, following the recommendations[35]. Alpine Linux1 isa GNU/Linux2 distribution which is smaller and more resource e�cient than traditionalLinux distributions.

1Alpine Linux - https://alpinelinux.org/2Linux - https://www.linux.org

31

CHAPTER 6. IMPLEMENTATION OF CLOUD STRATEGY 32

As T-REX is a Java EE application, it needs an appropriate runtime environment. T-REX PHACO image includes Java SE Runtime Environment 8 (JRE 8), 3, build 8u171as runtime environment for our application. This includes the Java Virtual Machine(JVM).

Running the JVM in a Docker container requires additional configuration. The JVMis not able to discover memory usage and limits inside Linux containers[36]. Linux toolsprovides system resource metrics through the proc filsystem[37]. However, most containerspecific metrics are available at the cgroup filesystem[38]. Consequently, Linux contain-ers display metrics from the systems hosting the container and not from the container. Inorder to solve this problem, it is necessary to set up the JVM to read the memory usageand limits from cgroup instead of proc. As for CPU, from JRE 8u131 the JVM does limitthe CPUs in Docker. Since T-REX PHACO using JRE 8u171, CPU is already correctlylimited.

T-REX PHACO image includes T-REX artifacts. They consist of the code packagedas a WAR and Jenkins CLI as library. T-REX is packaged as a WAR to be deployed on aservlet container.

T-REX PHACO image usesTomcat 8.5.31 as servlet container, working as webserverfor the application. In addition to including the Tomcat server, the configuration files toset up the Tomcat server are also included: server.xml and ROOT.xml.

T-REX PHACO image set up the container privileges. Typical servers run severalprocesses as root4. A container is di�erent because almost all typical root tasks are handledby the infrastructure around the container. This means that in most cases, containers donot need root privileges in runtime[39]. Dockerfile best practices[35] recommends that, ifa service can run without privileges, the container user should be a non-root user in orderto improve the security of the container. This does not a�ect regular web apps but reducesthe vectors of attack by malicious users considerably[39].

6.1.2 OpenShiftOpenShift infrastructure is built using OpenShift objects. This objects can be manuallybuilt or provided as Infrastructure as Code using a template. T-REX PHACO uses a tem-plate to describe OpenShift objects: trex-template.yaml. It can be found in Appendix B.T-REX PHACO uses the following OpenShift artifacts.

• Deployment, an OpenShift object that expands the Kubernetes object ReplicationController.

• Service, an OpenShift object based in Kubernetes object Service.

• Route, an OpenShift object.

• Secret, a Kubernetes object.3Java SE Runtime Environment (JRE8) - http://www.oracle.com/technetwork/java/

javase/downloads/jre8-downloads-2133155.html4The Linux Information Project: root definition - http://www.linfo.org/root.html


Deployment Configuration

Figure 6.1: Deployment Structure

This section describes the deployment of T-REX PHACO in Kubernetes. It consistsin a Docker container managed by a Kubernetes Pod. The Kubernetes Pod be managed bya Kubernetes Replication Controller. The Kubernetes Replication Controller is managedby an OpenShift Deployment Configuration.

A Docker container is the smaller object that can be managed. For this project, acontainer is created to run the application. When defining a container inside OpenShift, itshould be provided:

• The image to run inside the container.

• The container port exposed to the outside world.

• The resources request and resource limits of the Pod.

• The Volume Mounts to access Volumes from the container.

• The liveness probe and readiness probe to check the state of our Pod.

In order to be able to refer to an image from a Pod, it should be published in a registry.As indicated in 5.2, T-REX PHACO image is published in Amadeus jFrog Artifactory.The image is retrieved with an URL to access the image in that registry. In addition, animage pull policy5 is defined. When Kubernetes creates containers, it uses the container’s

5Kubernetes: updating images - https://kubernetes.io/docs/concepts/containers/images/#updating-images


image pull policy to determine if the image should be pulled before starting the container.T-REX PHACO uses the ’Always’ image pull policy: every time a container is createdinside a pod, the container image will be pulled. OpenShift does not provide a mechanismto discover changes in remote artifactories, so it is needed to pull the image every time acontainer is started to be sure that the last version is used.

By default, Docker containers can make connections to the outside world, but the out-side world cannot connect to containers6. For a container to accept incoming connections,the container bind to a port which is made available in the pod’s IP7. Our application isserved in port 8080 using TCP protocol, so this port is exposed to be able to be accessedfrom the outside world.

OpenShift template sets up the resource requests and limits. Resource request indicatesthe minimum resources needed to run our application8. This is used by the scheduler tofind a node with an appropriate fit for our container and ensure satisfactory performance.Resource limits are used to control the maximum amount of CPU that the container mayuse independent of contention on the node. If a container attempts to use more than thespecified limit, the system shuts down the container. This allows our container to have aconsistent level of service independent of the number of pods scheduled to the node.

The container can become unhealthy due to transient issues, becoming unavailable.OpenShift uses Kubernetes probes to detect unhealthy containers9. Our container has areadiness probe and a liveness probe. The readiness probe informs when our container hasfinished its start-up. This takes around 30 seconds, which is the Spring Boot start-up timefor our application. The liveness probe checks recurrently if our container is still running.If our container stops for any reason, the liveness probe will fail, and OpenShift will try torestart the container.

The minimum deployment unit in OpenShift is a Pod. When defining a Pod insideOpenShift, it should be provided:

• Containers

• Volumes

Our Pod contains the container just described.In addition to the container, T-REX PHACO uses a Secret Volume. Our application

needs to use a file which contains credentials. Since credentials are sensitive information,they should be treated with an appropriate degree of security. Kubernetes provide the se-cret object for this purpose10. Secrets can be stored in environment variables or in a secretvolume. Environment variables are adequate for password, tokens, or keys, while volumes

6Docker: Bind container ports to the host - https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/

7Pods and Services - https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/pods_and_services.html

8Openshift: Compute Resources - https://docs.openshift.com/enterprise/3.1/dev_guide/compute_resources.html#dev-cpu-requests

9OpenShift: Application Health - https://docs.openshift.com/container-platform/3.7/dev_guide/application_health.html

10Kubernetes: Secrets - https://kubernetes.io/docs/concepts/configuration/secret/


are appropriate for files. In order to keep our sensitive information secured, a Secret Vol-ume is used. It contains the file with the credentials.

Pods are managed by controllers. For pods that are not expected to terminate, suchas web servers, a Replication Controller should be used. Kubernetes Replication Con-troller11 object ensures that a specified number of pod replicas are running at any onetime, making sure that a pod or a homogeneous set of pods is always up and available.

Every Pod needs to be managed by a controller. If the Pod is not expected to terminate(such as web servers), a Replication Controller is used. When defining a ReplicationController inside OpenShift, it should be provided:

• The number of replicas desired (which can be adjusted at runtime).

• A pod definition to use when creating a replicated pod.

Two replicas are set up for our application to obtain a minimum degree of redundancy.In this way, if one of the replicas fail, the application still works with the remaining one.For being able to have several replicas, the application should be prepared. The applica-tion is almost stateless, persisting all necessary data to databases and initiating any otherprocesses in di�erent services. However, the application still needs one stateful compo-nent: the session. T-REX uses sticky sessions; user sessions should be maintained whena user navigates or reload the application, even when running several replicas. OpenShiftprovides a mechanism to maintain sticky sessions. OpenShift sends all tra�c from a user’ssession go to the same pod12. Even if there are several replicas of the application running,the user is always redirected to the pod where its session is maintained.

OpenShift expands the Replication Controller with the concept of deployment, addingexpanded support for the software development and deployment life-cycle. Deploymentare defined using the OpenShift Deployment Config13 object. They are created manuallyor in response to triggered events.

When defining a Deployment inside OpenShift, it should be provided:

• The elements of a Replication Controller definition.

• The strategy for transitioning between deployments.

• Triggers for creating a new deployment automatically.

Every time there is any change in the application, either code or configuration, it shouldbe redeployed. Changes to the application can be made through two di�erent channels:from the CD pipeline or from OpenShift configuration. For the former, a redeploy is trig-gered using CLI command from the CD pipeline. For the latter, a trigger is used whichredeploys the application every time there is a configuration change.

11Replication Controller - https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/

12OpenShift: Routes - https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html

13https://docs.openshift.com/container-platform/3.7/architecture/core_concepts/deployments.html#deployments-and-deployment-configurations


T-REX PHACO uses ’Rolling’ as the deployment strategy. This strategy support zero-downtime deployments allowing to take no downtime during an application update 14. Thisis a desirable feature in modern Java application[3]. A rolling deployment slowly replacesinstances of the previous version of an application with instances of the new version ofthe application. When a new deployment is triggered, new pods are created for the newversion of the application. Pods take some time to be created and started. While thisinitializations process is happening, the old pods keep running. Once the new pods areready and healthy, the old pods stopped receiving new connections and are shut down.

Service and Route

In the Service, a selector is used to indicate that it should be applied to our deployment.The service exposes the port 8080 from the Pod (targetPort) in port 80 (port) to the exterior.In the Route, the host is defined, and it is attached to the Service.

Secrets

T-REX PHACO needs to use credentials in order to access the databases. In order to keepthem secure, OpenShift Secrets15 are used.

For this project, database credentials are given in a Tomcat configuration file, ROOT.xml.Since this file contains sensitive information, it should not be published in the code repos-itory. This file should be added manually to OpenShift and make it available to our appli-cation. This file is put in a Secret Volume16, and this secret volume is mounted in the Pod,as described in 6.1.2.

6.2 Development WorkflowDevelopment workflows are a recommended practice in software development. T-REXOriginal provides a certain degree of automation, performing Continuous Build. However,Continuous Delivery and Continuous Deployment is not provided.

Figure 6.2: Components of Automation Pipeline14OpenShift: Deployment Strategies - https://docs.openshift.com/

container-platform/3.7/dev_guide/deployments/deployment_strategies.html

15OpenShift Secrets - https://docs.openshift.com/container-platform/3.6/dev_guide/secrets.html

16Kubernetes: Secret Volume - https://kubernetes.io/docs/concepts/configuration/secret/


A complete development workflow has been implemented for T-REX PHACO. It in-cludes Continuous Integration, Continuous Delivery, and Continuous Deployment. It usesthe following components:

• Automation Pipeline Automation pipeline that performs Continuous Integration,Continuous Delivery, and Continuous Deployment.

• Code Repository Code repository from which the automation pipeline retrieves thecode and configuration files.

• Image build The pipeline performs Continuous Integration building T-REX PHACOimage, needed for running the application. In this image build, the application is alsobuilt and packaged.

• Image repository Continuous Delivery is performed by publishing T-REX PHACOimage in an image repository, from which it can be deployed.

• PaaS Continuous Deployment is performed by deploying T-REX PHACO in thePlatform-as-a-Service. It provides the desired capabilities of Continuous Deploy-ment such as rollout, rollback, and automatic redeployment. The details of the de-ployment in the PaaS can be found in the previous section, 6.1.2.

6.2.1 Development Workflow ComponentsCode Repository

The first principle of Twelve-Factor App methodology is to keep all files and artifactsneeded to build and run the application in one repository. For this purpose, a code repos-itory has been used for T-REX PHACO.

The following branching strategy is set up:

• Branch next Once changes have been validated in the development environment,they are committed in the branch next. A commit in branch next starts the integrationpipeline.

• Branch master Once changes have been validated in integration environment, thischanges are incorporated to the branch master. When a change or set of changesneed to be deployed in production, a release is launched. Every release starts theproduction pipeline.

Image Build

The development environment should be isolated from the other environment, and the de-veloper should be able to try radical changes to the code. With this purpose in mind, thefollowing strategy has been created:

T-REX application is built using Maven. In order to containerize the whole project,two di�erent containers are used.

T-REX PHACO uses a multi-stage build. This is a practice recommended by Docker[40]in order to reduce the size of the final image. It consists of two stages:


• Build Image This image contains Maven and JDK 8. It pulls the code from the coderepository and packages the application into a WAR using Maven.

• T-REX PHACO Image This image contains Tomcat and JRE 8. It uses the WARcreated in the previous step and configuration files from the code repository to servethe application using Tomcat.

It can be discussed that this method is more cumbersome than the traditional method.A comparison can be made:

• Traditional The developer makes changes in the code and the, she compiles andruns directly with Maven. She does not need to package the application, which is alonger process. She can debug the code directly with an IDE. However, the developerneeds to have Maven and installed in the workstation, and the environment will di�erfrom the integration and production environment.

• Docker The developer makes changes in the code. She builds the Docker image andruns it, packaging the application. For debugging she need to use remote debugginginside the Docker container. However, with this method, the development containeris going to be the same as the integration and production container. Besides, thedeveloper only needs to have Docker installed in its workstation, neither Maven orthe JDK.

Artifacts Repository

Code repositories such as Bitbucket are not the best solution to store Docker images. Theyprovide nice features for changes in code, such as comparing text files, but they do notprovide Docker-specific features. Instead, Docker registries are used. They provide extrafeatures when storing Docker images, such as image naming using tags, image versioningor notifications17. Amadeus jFrog Artifactory is used as Docker registry.

Images need to be published in a registry in order to deploy them in OpenShift. Open-Shift needs to access the image for deploying, redeploying, or creating replicas. Also,OpenShift needs to access the previous version of a Docker image when it performs arollback.

In the Docker registry the following Docker images are stored:

• T-REX integration image Docker image for the integration version

• T-REX production image Docker image for the production version

• Pipeline Execution Environment image Docker image containing the executionenvironment for the automation pipeline.

6.3 Automation PipelineT-REX PHACO automation pipeline puts together all elements from the developmentworkflow (code repository, image build, image repository and PaaS). It is set up usingan automation server, Software Workbench, an Amadeus Jenkins instance.

17Docker: Registry - https://docs.docker.com/registry/introduction/


6.3.1 Pipeline as CodeJenkins provides a user interface that can be used to set up the automation pipeline man-ually. However, it also provides mechanisms for implementing the pipeline using con-figuration files. This practice is know as Pipeline as Code (PaS)18. Jenkins provides anextensible set of tools for modeling simple-to-complex delivery pipelines "as code" viathe Pipeline DSL (Domain Specific Language). This practice facilitates compliance withthe Twelve-factor app methodology, which requires to store the configuration in the envi-ronment.

To use Pipeline as Code, projects must contain a file named Jenkinsfile in the repositoryroot, which contains a "Pipeline script", either using a Declarative or Scripted19 pipeline.Additionally, either a Multibranch Pipeline or Organization folders should be configured.

Organization Folders are used to scan a full Bitbucket team to discover organization’srepositories, automatically creating Managed Multibranch Pipeline for them. Since T-REX PHACO only needs to use a specific repository (following the recommendation fromTwelve-Factor App methodology, Factor 1), a single Multibranch Pipeline is set up. AMultibranch project enables us to implement di�erent Jenkinsfiles for di�erent branchesof the project20. In this fashion, di�erent pipelines are used for the integration branch(next) and production branch (master).

For this project, a Jenkinsfile has been configured with a Scripted Pipeline21 syntax.T-REX PHACO Jenkinsfile can be found in the Appendix C. This Jenkins file makes use ofa custom library, a template for each of the pipeline stages defined and file for environmentvariables that can be set up by the developer. These files can also be found in the AppendixC.

Four main parts can be identified that are performed every time the pipeline is started:

• Node Request Request a Jenkins node in which to run the pipeline.

• Imports Checkout the code from the repository, import code for performing thesteps (Jenkinstemplate.groovy) and environment variables (.env).

• Execution Environment A Docker image is provided to run the pipeline steps.

• Pipeline Steps Steps to perform the Continuous Deployment. They build, publishand deploy the application.

Execution environment and pipeline steps need to be described in detail.

Pipeline Execution Environment

In the Jenkinsfile, the first directive requests a Jenkins node to run the pipeline. As ex-plained in 2.1.6, a node is a server that runs a Jenkins agent. The software and resourcesavailable in this agent are used to perform the work described in the node instruction inT-REX PHACO Jenkinsfile.

18Jenkins: Pipeline as Code - https://jenkins.io/doc/book/pipeline-as-code/19Jenkins: Declarative vs. Scripted Pipeline Syntax20Jenkins: Creating a Multibranch Pipeline - https://jenkins.io/doc/book/pipeline/

multibranch/#creating-a-multibranch-pipeline21Jenkins: Scripted Pipeline - https://jenkins.io/doc/book/pipeline/syntax/

#scripted-pipeline


Installing all the needed software in the node is possible, but not recommended. Anode can be used for several software projects, each requiring di�erent software in itspipeline steps. This result in heavy nodes with too many tools installed. A recommendedpractice22 is to use Docker containers as execution environment. The Docker containerprovides all the software needed to run the pipeline steps.

For this project, T-REX PHACO Builder image is used. The Dockerfile for this imagecan be found in Appendix D. In this Docker image, all software needed for the pipeline isincluded: Docker and OpenShift CLI.

Pipeline Steps

Inside the execution environment just described, the steps of the pipeline are run. Thecode for each step can be found in Jenkinstemplate.groovy, in Appendix C. The followingsteps are described:

• Build The pipeline use Docker to build T-REX PHACO image. The steps are definedin its Dockerfile (Appendix A). The build uses a strategy called multi-stage build.The image is tagged with the target publish path in the Amadeus jFrog Artifactory.

• Publish T-REX PHACO image built in the previous step is published into AmadeusjFrog Artifactory.

• Deploy T-REX PHACO image is deployed to OpenShift. For this purpose, an Open-Shift template is used in which the details of the OpenShift Objects to deploy aredefined. The details are explained in 6.1.2 and the template can be found in Ap-pendix B. The OpenShift CLI installed in the execution environment is used tolaunch the deployment of T-REX PHACO.

6.3.2 Dev/int/prod WorkflowThe automation pipeline behaves di�erently for the development, integration and produc-tion environment.

Development

For the development environment, it is not needed to use the automation pipeline. The de-velopment environment should be isolated from the other environment, and the developershould be able to try radical change to the code. With this purpose in mind, the followingstrategy has been set up:

1. Get code from ’next’ The developer pull the latest code from the ’next’ branch.

2. Make changes The developer makes the desired changes in the code.

3. Docker build The developer performs the multi-stage Docker build in its worksta-tion to run the application with the new changes.

4. Commit changes Once the developer is satisfied with the changes, she commitsthem to the code repository, branch ’next’.

22Jenkins: defining execution environments - https://jenkins.io/doc/pipeline/tour/agents/


Integration

The last step of the development environment starts the integration steps. These stepsmake use of the automation pipeline, and they are the following.

1. Commit changes Once the developer is satisfied with the changes, she commitsthem to the code repository, branch ’next’.

2. Automatic start of integration pipeline Using a webhook, Jenkins can detect thata commit has happened. When new code is committed to the branch ’next’, Jenkinsstarts the integration pipeline.

(a) Build Jenkins builds the integration image, which uses the integration databases.

(b) Publish Jenkins publish the integration image to Amadeus jFrog Artifactory.

(c) Deploy Jenkins deploy the integration image published in Amadeus jFrog Ar-tifactory to Amadeus OpenShift, in the integration namespace.

Production

For launching the production pipeline, the developer needs to start by performing a releasein the code repository:

1. Merge into "master" Once enough changes have been tested out in the integra-tion environment, the developer merges the code changes of the integration branch,"next", into the "master" branch.

2. Publish a release With the new changes already in the master branch, the developercreates a release and publish it.

3. Automatic start of production pipeline Using a webhook, Jenkins can detect thata new release has been published, starting the production pipeline.

(a) Build Jenkins builds the production image, which uses the production databases.

(b) Publish Jenkins publish the production image to Amadeus jFrog Artifactory.

(c) Deploy Jenkins deploy the production image published in Amadeus jFrog Ar-tifactory to Amadeus Openshift, in the production namespace.


Figure 6.3: Components of Automation Pipeline with its defining files

Chapter 7

Evaluation and Results

The objective of this thesis is to transform a traditional application in a cloud-native appli-cation. For doing so, as explained in 2.1.4, the application must fulfill Twelve-Factor Appmethodology and cloud-native principles. In this chapter, it will be showed how the finalT-REX PHACO application complies with these factors and principles in contrast with thetraditional T-REX Original.

7.1 Twelve-Factor AppTo perform the evaluation, T-REX PHACO is going to be analyzed from the point of viewof Twelve-Factor App methodology. Its compliance with each factor will be assessed,describing how it has been reached.

7.1.1 CodebaseThis factor states that the codebase of a single application is tracked in a single repository,containing all specifications for potentially di�erent environments.

This factor was already met in T-REX. Our primary challenge was to introduce allnecessary changes while still keeping version control in a single repository.

For this purpose, we have added all configuration (server.xml) and Infrastructure asCode files (Dockerfile, trex-template, Jenkinsfile) to T-REX repository.

In addition, we set up a webhook on Bitbucket that informs Jenkins of new commitsto the branch, launching the Continuous Deployment strategy.

7.1.2 DependenciesThis factor states that dependencies must be explicitly declared and isolated.

T-REX already used a build system, Maven, to specify the dependencies of the project.Building with Maven results in a WAR file which includes all dependencies needed for theproject to run.

Although this method satisfies this 12-factor, it has room for improvement. In de-velopment, T-REX is built from the development workstation, while in integration andproduction is built using Jenkins. This is a discrepancy between environments, and theyshould be minimized.

43

CHAPTER 7. EVALUATION AND RESULTS 44

1 2 3 4 5 6 7 8 9 10 11 12T-REX Original 3 7 7 3 7 7 3 7 3 7 7 3

T-REX PHACO 3 3 3 3 3 7 3 3 3 3 3 3

Table 7.1: T-REX Original vs. T-REX PHACO compliance with Twelve-Factor App

We improved this method using Docker. We make use of a multistage build 6.2.1. Inthe first stage, we build the project. In the second stage, we copy this war into the T-REXDocker image. In this fashion, we build the WAR following the same exact instruction inall environments, following the Dockerfile.

The resulting WAR from the Maven build was previously stored in Jenkins file systemand retrieved manually by the developer in order to deploy it into the server. The resultingWAR is now copied in the second stage of the multistage build 6.2.1 into the final Dockerimage. This Docker image is published to a central repository, JFrog Artifactory, fromwhich it can be easily accessed by Openshift for deployment.

7.1.3 ConfigThis factor states that application configuration is retrieved via files, environment variablesor other external concerns.

In T-REX Original, the selection of the environment (development, integration, andproduction) is made with an environment variables. All the remaining configuration isperformed manually.

In T-REX PHACO, several configuration files are used and provided in the repository:

• Dockerfile Used for build T-REX PHACO image. This project Dockerfile is pro-vided in the code repository. It configures two environment variables: one to se-lect the development profile by default, and one to provide JVM configuration.server.xml for Tomcat server configuration. It is provided in the code repository.

• OpenShift Template Infrastructure as Code file to deploy T-REX PHACO in Open-shift. The file used for this purpose is trex-template.yaml is provided in the coderepository. It configures two environment variables: one to select integration orproduction profile (depending on the namespace in which the application run, inte-gration or production), and one to provide JVM configuration.

• Jenkinsfile Pipeline as Code file that defines the Continuous Deployment pipeline.It is complemented with Jenkinstemplate.groovy to define the steps and .env to pro-vide environment variables to configure the application. This project Jenkinsfile isprovided in the code repository.

• ROOT.xml Configuration file providing JDBC required information, such as databasehost and credentials. This file is provided in OpenShift configuration as a secret.

7.1.4 Backing ServicesThis factor states that external resources, such as databases, should be attached to theapplication in a loosely coupled way.

This factor was fulfilled in T-REX Original, and it is fulfilled in T-REX PHACO.


Databases are accessed through JDBC and services are accessed through HTTP in bothcases.

7.1.5 Build, Release, RunThis factor states that build, release and run stages should be strictly separated.

T-REX strictly separated build, release and run stages. However, the process is mainlymanual. Continuous Build is implemented using a Jenkins job3.5, but release and run areperformed manually by the developer. Both are repetitive tasks that should be automated.

In T-REX Original, the stages were performed in the following way:

• Build Jenkins job build the Java artifact. This Java artifact is stored in Jenkins filesystem, which is not a central artifacts repository, lacking several features.

• Release Developer manually put the Java artifact inside the Tomcat server.

• Run Developer manually start the Tomcat server to run the application.

The build step is performed by an automation server, Jenkins, but release and run isperformed manually by the developer. As explained stated by Daschner [3], software en-gineers should focus on designing, implementing and discussing business logic and spendas little time as possible in cross-cutting concerns and repetitive tasks.

In T-REX PHACO, Continuous Build has been extended to Continuous Deploy:

• Build Build step in Jenkins pipeline, in which the Java artifacts are built and includedin T-REX Docker image.

• Release Publish step in Jenkins pipeline, in which T-REX Docker image is publishedto jFrog Artifactory. From this central artifacts repository, old versions of the imagescan be easily accessed.

• Run Deploy step in Jenkins pipeline, in which T-REX Docker image is used to runa container in OpenShift, serving the application.

Every step is automatized, reducing the risk of human mistake and reducing the timespent by the developer in repetitive tasks.

Automatizing the build, release, and run steps present additional benefits, such as au-tomatic rollback. Imagine that we release a new version of T-REX and it does not workas expected. The developer would need to rollback to the previous version, repeating eachstep manually.

However, with the new build/release/run strategy, the benefits are twofold. First, itimplements health checks to be sure that the application is running correctly, avoidingrunning a new version if the health checks fail. In case the health checks are passed,but still, there is some problem with the T-REX version, OpenShift provides a rollbackstrategy. We have defined it in 6.1.2 and, if needed, we can launch it from CLI (with asingle command) or UI (just clicking a button).

We have implemented a rolling strategy (6.1.2 ), but other strategies could be imple-mented using OpenShift. OpenShift provides powerful tools for releasing.


7.1.6 ProcessesThis factor states that the application must be executed as one or more stateless processes.

There is only one violation of this principle in T-REX PHACO: sticky sessions. Stickysessions strategy cannot be changed without making changes in the original code of T-REX. As explained in 5.3.6, OpenShift has a native mechanism for supporting sticky ses-sions, so a solution is provided. However, this factor cannot be considered as entirelyfulfilled, and further work should be carried out.

7.1.7 Port BindingThis factor states that services should be exported via port binding.

T-REX Original already complied with this factor, and T-REX PHACO also does. T-REX PHACO functionality is provided in port 8080. This port is configured to be accessi-ble to the exterior world, and not only to the internal OpenShift infrastructure networking.

7.1.8 ConcurrencyThis factor states that the application should be able to scale out via the process model.

T-REX Original was not able to scale via the process model. T-REX PHACO addedthis functionality thanks to Docker, Kubernetes, and OpenShift.

• Vertical Scaling T-REX Original was able to scale vertically by adding more re-sources to the physical server. Consequently, vertical scaling was possible usingphysical methods, but it was not possible to do so from the process model.

• Horizontal Scaling Horizontal scaling was possible but not straightforward. Itwould require adding a load-balancer, a proxy able to keep the sessions. Then, sev-eral servers or several instances inside a server would be needed.

Thanks to OpenShift, Kubernetes and Docker containers scaling becomes much easier.

• Vertical scaling can be done from the Openshift template for the project (trex-template.yaml), as well as OpenShift CLI or UI, changing the resources assignedto the pod.

• Horizontal scaling can be done from the Openshift template for the project (trex-template.yaml), as well as OpenShift CLI or UI, changing the number of pod repli-cas. Openshift provided router1 will take care of concurrency issues. It will directeach user to the same pod replica every time, and it will keep sessions for each podreplica.

7.1.9 DisposabilityThis factor stated that the application must maximize robustness with fast startup andgraceful shutdown.

1OpenShift: Routes - https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html


T-REX Original fulfill this factor, like Java EE, developers do not need to take careof this aspect themselves: it supports natively fast startup and graceful shutdown. T-REXPHACO maintained this feature from Java EE, and it requires to make use of disposabilitymore often. By definition, Docker containers and Pod are often recreated and thereforeare treated as expendable

7.1.10 Dev/prod ParityThis factor states that development, staging, and production environments should be assimilar as possible.

Container technologies and orchestration frameworks highly support this approach.Di�erences in configuration, services, and technologies are minimized or at least explic-itly defined via the environment.

T-REX Original presents the following configuration in each environment:

• Development

– Build in developer workstation. Java 8 and Maven 3 are required

– Run in developer workstation with Maven ’run’. Java 8 and Maven 3 are re-quired.

– Serve with Tomcat embedded server provided by Spring Boot.

– Connect to a local instance of T-REX database.

• Integration/Production

– Build in Jenkins server. Maven 3 plugin is required.

– Run in integration/production server.

– Serve with Tomcat 8.5 server installed in integration/production server.

– Connect to integration/production instance of T-REX database.

It is possible to identify significant di�erences among development, integration andproduction environments. Each one of them uses a di�erent machine, and di�erent strate-gies for serving the application, and several software requirements should be consistentacross all of them. The three di�erent databases should also be consistent. In addition,using an embedded Tomcat server di�ers from non-embedded. The embedded Tomcatserver version depends on the ones provided by Spring Boot, and the configuration di�ersfrom non-embedded. Several discrepancies may occur and lead to errors.

T-REX PHACO presents the following configuration in each environment:

• Development

– Build T-REX PHACO image in developer workstation. Docker 18 is required.

– Run T-REX PHACO image with Docker 18.


– Connect to integration instance of T-REX database.

• Integration

– Build T-REX PHACO image in Jenkins server. Docker 18 plugin and T-REXBuilder image are required.

– Run T-REX PHACO image in OpenShift 3.6, integration namespace.

– Connect to integration instance of T-REX database.

• Production

– Build T-REX PHACO image in Jenkins server. Docker 18 plugin and T-REXBuilder image are required.

– Run T-REX PHACO image in OpenShift 3.6, production namespace.

– Connect to production instance of T-REX database.

While the development machine (developer workstation), integration machine (Open-Shift integration namespace) and production machine (OpenShift production namespace)di�er, they only need one software to run the application in exactly the same way: Docker18. Using a Docker image, the same installations steps will always be followed for build-ing the application, containing the code as well as the configuration and required software(Java 8 and Maven 3). In addition, all software requirements for building, publishingand running the image in integration and production are provided in T-REX Builder im-age. Consequently, build/run/release is performed inside the same environment. The samesoftware will always be used, and the same steps will always be followed. This strategypresents significantly fewer potential discrepancies.

7.1.11 LogsThis factor states that logs must be treated as event streams.

In T-REX Original, logs were written on disk and used additional strategies, such aslog rotation. T-REX PHACO writes the logs to the standard output and does not persistthem on disk, fulfilling this factor. Docker and OpenShift provide a mechanism for readingthe standard output as a stream of events, in which only Java errors will be shown. Theseerrors will indicate fatal problems that require engineering action.

Docker logs to stdout.

7.1.12 Admin ProcessesThis factor states that admin/management tasks must run as one-o� processes.

T-REX Original already complied with this factor. It was possible to run administrativetasks as a one-o� process in its server. This is still possible in T-REX PHACO as containersencapsulate Unix process. This allows to execute a single command or to open a remoteshell in a container.


7.2 Cloud Native PrinciplesTo perform the evaluation, T-REX PHACO is going to be analyzed from the point of viewof cloud-native principles. Its compliance with each principle will be assessed, describinghow it has been reached.

• Operated on automation platforms T-REX PHACO is operated in OpenShift, anelastic platform that, based on Kubernetes, allows to automatically provision andde-provision resources depending on the performance of the application.

• Softwarization of infrastructure and network Softwarization of infrastructureand network has been done through infrastructure as a service, with Dockerfile forcreating Docker containers, OpenShift templates for describing OpenShift infras-tructure, and Pipeline as Code for softwarization of the Jenkins pipeline.

• Migration and interoperability across di�erent cloud infrastructures and plat-forms By using Docker to containerize the application, migration can be easily donefrom one cloud platform to another. In addition, OpenShift provides a mechanism(such as an API or CLI) to operate with other cloud platforms.

Chapter 8

Conclusions

In this thesis, a traditional Java enterprise application was migrated to the cloud. It wasdone using several cloud technologies (containers, containers orchestration, PaaS) follow-ing the Twelve-Factor App methodology. An analysis of the candidate application waspresented, a strategy for migrating it to the cloud was drafted, and the final implemen-tation was described. We finally evaluated the final result using the Twelve-Factor Appmethodology, analyzing its compliance with each one of the principles.

Despite not changing the original code of this project, new coding work has beenadded. The tangible part of this project consists of a set of files that enables cloud mi-gration: Dockerfile (with .Dockerignore), trex-template.yaml, Jenkinsfile (with Jenkin-stemplate.groovy and .env files). These files can be found in the Appendix.

8.1 DiscussionThis project was carried out without making changes into the original code. The origi-nal application already fulfilled some principles of the Twelve-Factor App, and the mostsignificant part of the migration could be done without altering the original code. Onlyconfiguration files were added, as well as Infrastructure as Code and Pipeline as Code files.

The evaluation shows that, for the resulting application, Twelve-Factor App principleswere met with an exception. Sessions are stored in the application, violating the statelessprinciple of cloud applications. This is a widespread issue when migrating applications,to the extent that OpenShift provides a native solution to deal with sticky sessions. Con-sequently, the factor is partially met, but there is room for improvement.

There are two conclusions about the complexity of this project. On one side, a signif-icant part of the manual task for the developer has been automatized. Software engineersnow will spend less time on repetitive tasks, saving time for designing, implementing, anddiscussing business logic. On the other side, it is noticeable that several technologies havebeen needed for this automation and also in order to migrate the application to the cloud:Docker as container technology, Kubernetes for orchestration, OpenShift as Platform asa Service, and Jenkins as an automation server. The traditional server infrastructure hasbeen substituted with PaaS, but the rest of technologies are not alternatives, but new workis done on top of the original. Cloud computing is more potent than traditional computing,but it requires additional overhead to enable its potential.

50

CHAPTER 8. CONCLUSIONS 51

8.2 Future WorkSome improvements could be made by changing the original code of the application.Sticky sessions can be changed by sessions that persist to an external database, being ableto access session information no matter the replica. For example, Spring Session coupledwith Redis could be used 1. Also, a better mechanism for health check can be added. Forexample, Spring Boot Actuator provide endpoints to check the health of an application2.In this fashion, the health will not only check that the application is up and running, butthat all its attached resources (such as databases) are also healthy.

Another improvement implies creating tailored Docker images for the application. T-REX PHACO Docker image is based in the o�cial Tomcat image, which is based in o�cialOpenJDK, which is based in the o�cial Alpine image and so on. Although these imagesare recommended by Docker, for the production system is less error prone to only reliesupon images in which the developer has full control.

The choice of maximum resources was made following o�cial recommendations forJava 8, Tomcat and Spring Boot. However, since this application is not very heavy orresource dependent, it would be interesting to perform a study to find out its real resourcerequirements.

We chose to keep using Tomcat to serve the project to maintain similarity with theoriginal application, a more lightweight solution can be used, such as an Apache TomEE3.

1Spring Boot: Spring Session - https://docs.spring.io/spring-session/docs/current/reference/html5/guides/boot-redis.html

2Spring Boot Actuator: Endpoints - https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html

3Apache TomEE - http://tomee.apache.org

Bibliography

[1] NIST. NIST Definition of Cloud Computing. 2016. ��: http://www.nist.gov/itl/cloud/.

[2] Michael Armbrust et al. “A View of Cloud Computing”. In: Communications ofthe ACM 53.4 (2010), pp. 50–58. ��: 00010782. ��: 10.1145/1721654.1721672. arXiv: 05218657199780521865715. ��: https://s3.amazonaws.com/academia.edu.documents/34578652/a%7B%5C_%7Dview%7B%5C_%7Dof%7B%5C_%7Dcc.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A%7B%5C&%7DExpires=1527601922%7B%5C&%7DSignature=1JCUVcdoO79SX3FP%7B%5C%%7D2FiWrSMPS56s%7B%5C%%7D3D%7B%5C&%7Dresponse-content-disposition=inline%7B%5C%%7D3B%20filename%7B%5C%%7D3DA%7B%5C_%7DView%7B%5C_%7Dof%7B%5C_%7DCloud%7B%5C_%7DComputing%7B%5C_%7DClear.

[3] Sebastian Daschner. Architecting modern Java EE applications : designing lightweight,business-oriented enterprise applications in the age of cloud, containers, and JavaEE 8. Packt Publishing, 2017, p. 442. ��: 1788393856.

[4] Adam Wiggins. The Twelve-Factor App. 2017. ��: https : / / 12factor .net/ (visited on 08/08/2018).

[5] Nane Kratzke and Peter Christian Quint. “Understanding cloud-native applicationsafter 10 years of cloud computing - A systematic mapping study”. In: Journal ofSystems and Software 126 (2017), pp. 1–16. ��: 01641212. ��: 10.1016/j.jss.2017.01.001.

[6] Anne Håkansson. “Portal of Research Methods and Methodologies for ResearchProjects and Degree Projects”. In: Proceedings of the International Conference onFrontiers in Education: Computer Science and Computer Engineering FECS’13(2013), pp. 67–73. ��: http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-136960.

[7] Amadeus. Amadeus Global Website | Let’s shape the future of travel. 2015. ��:http://www.amadeus.com/web/amadeus/en%7B%5C_ %7D1A-corporate/Amadeus-Home/1319560218660-Page-AMAD%7B%5C_%7DHomePpal (visited on 05/24/2018).

[8] Blesson Varghese and Rajkumar Buyya. “Next Generation Cloud Computing: NewTrends and Research Directions”. In: (2017). ��: 0167739X. ��: 10.1016/j.future.2017.09.020. arXiv: 1707.07452. ��: https://arxiv.org/pdf/1707.07452.pdf%20http://arxiv.org/abs/1707.07452.

52

BIBLIOGRAPHY 53

[9] Amadeus Global Report 2017: a business, financial and sustainability overview.2017. ��: http : / / www . amadeus . com / msite / global - report /2017/en/pdf/amadeus-global-report-2017.pdf.

[10] James Gosling et al. The Java Language Specification. 2005, p. 688. ��: 0-321-24678-0. ��: http://www.amazon.de/exec/obidos/ASIN/0321246780.

[11] Stephen O’Grady and Rachel Stephens. The RedMonk Programming Language Rank-ings: January 2018. 2018. ��: https://redmonk.com/sogrady/2018/03/07/language-rankings-1-18/ (visited on 08/10/2018).

[12] TIOBE Index. 2018. ��: https://www.tiobe.com/tiobe-index//(visited on 08/10/2018).

[13] Computer Weekly. Write once, run anywhere? 2002. ��: https : / / www .computerweekly . com / feature / Write - once - run - anywhere %20http : / / www . computerweekly . com / feature / Write - once -run-anywhere (visited on 08/10/2018).

[14] Tim Lindholm et al. “The Java R�Virtual Machine Specification”. In: The Java Lan-guage Specification, Java SE 8 Edition (2014), pp. 1–626. ��: http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf.

[15] “Hypertext Transfer Protocol”. In: MDN web docs (). ��: https://developer.mozilla.org/en-US/docs/Web/HTTP.

[16] Spring Project Team. Spring Framework. 2014. ��: https://spring.io/projects/spring- framework%20https://projects.spring.io/spring-framework/ (visited on 06/25/2018).

[17] Nicholas Chen. Convention over configuration (2006). 2015. ��: http://softwareengineering.vazexqi.com/files/pattern.html.

[18] Inc. Pivotal Software. Spring Boot. 2015, pp. –3. ��: 978-1-61729-254-5. ��:10.1002/ejoc.201200111. arXiv: arXiv:1011.1669v3. ��: https://spring.io/projects/spring- boot%20http://projects.spring.io/spring-boot/.

[19] Peter Murray. Traditional Development/Integration/Staging/Production Practice forSoftware Development. 2006. ��: http://dltj.org/article/software-development-practice/ (visited on 06/25/2018).

[20] Kash Rangan et al. “The Cloud Wars : 100 + billion at stake”. In: Analyst The May(2008), pp. 1–90. ��: http://web2.sys-con.com/node/604936.

[21] Ludwig Siegele. Let it Rise: A Special Report on Corporate IT. 2008. ��: http:/ / scholar . google . com / scholar ? hl = en % 7B % 5C & %7DbtnG =Search % 7B % 5C & %7Dq = intitle : Let + it + rise : +A + special +report+on+corporate+IT%7B%5C#%7D0.

[22] Aleksander Slominski, Vinod Muthusamy, and Rania Khalaf. “Building a multi-tenant cloud service from legacy code with docker containers”. In: Proceedings- 2015 IEEE International Conference on Cloud Engineering, IC2E 2015. 2015,pp. 394–396. ��: 9781479982189. ��: 10.1109/IC2E.2015.66.

BIBLIOGRAPHY 54

[23] Michael Wurster et al. “Developing, Deploying, and Operating Twelve-Factor Ap-plications with TOSCA”. In: Proceedings of the 19th International Conference onInformation Integration and Web-based Applications & Services. 2017, pp. 519–525. ��: 9781450352994. ��: 10.1145/3151759.3151830.

[24] David Bernstein. “Containers and cloud: From LXC to docker to kubernetes”. In:IEEE Cloud Computing 1.3 (2014), pp. 81–84. ��: 23256095. ��: 10.1109/MCC . 2014 . 51. ��: http : / / www . ce . uniroma2 . it / courses /sdcc1617/articoli/bernstein%7B%5C_%7Dcc2014.pdf.

[25] Wes Felter et al. “An updated performance comparison of virtual machines andLinux containers”. In: ISPASS 2015 - IEEE International Symposium on Perfor-mance Analysis of Systems and Software. 2015, pp. 171–172. ��: 9781479919567.��: 10.1109/ISPASS.2015.7095802.

[26] Stephen Soltesz et al. “Container-based operating system virtualization”. In: ACMSIGOPS Operating Systems Review 41.3 (2007), p. 275. ��: 01635980. ��: 10.1145/1272998.1273025. ��: http://portal.acm.org/citation.cfm?doid=1272998.1273025.

[27] Container application platform - Red Hat OpenShift. ��: https : / / www .redhat.com/en/technologies/cloud- computing/openshift(visited on 08/21/2018).

[28] Armin Balalaie. “Microservices Architecture Enables DevOps : An Experience Re-port on Migration to a Cloud-Native Architecture”. In: IEEE Software 33.3 (2016),pp. 42–52. ��: 07407459. ��: 10.1109/MS.2016.64. arXiv: 1606.04036.��: https : / / spiral . imperial . ac . uk / bitstream / 10044 /1/40557/8/SO%7B%5C_ %7DSWSI- 2015- 10- 0149.R1%7B%5C_%7DBalalaie.pdf%20http://ieeexplore.ieee.org/abstract/document/7436659/.

[29] Armin Balalaie. “Microservices Architecture Enables DevOps : An Experience Re-port on Migration to a Cloud-Native Architecture The Architectural Concerns forMicroservices Migration The Architecture of Backtory Before the Migration”. In:IEEE Software 33.3 (2016), pp. 42–52. ��: 07407459. ��: 10 . 1109 / MS .2016.64. arXiv: 1606.04036. ��: https://spiral.imperial.ac.uk/bitstream/10044/1/40557/8/SO%7B%5C_ %7DSWSI- 2015-10 - 0149 . R1 % 7B % 5C _ %7DBalalaie . pdf % 20https : / / spiral .imperial.ac.uk/bitstream/10044/1/40557/8/SO%7B%5C_%7DSWSI - 2015 - 10 - 0149 . R1 % 7B % 5C _ %7DBalalaie . pdf % 7B %5C%%7D0Ahttp://ieeexplore.ieee.org/abstract/document/7436659/.

[30] Eddy Truyen et al. “Towards a container-based architecture for multi-tenant SaaSapplications”. In: Proceedings of the 15th International Workshop on Adaptive andReflective Middleware - ARM 2016. 2016, pp. 1–6. ��: 9781450346627. ��: 10.1145/3008167.3008173. ��: http://dl.acm.org/citation.cfm?doid=3008167.3008173.

BIBLIOGRAPHY 55

[31] Claus Pahl. “Containerization and the PaaS Cloud”. In: IEEE Cloud Computing2.3 (2015), pp. 24–31. ��: 23256095. ��: 10.1109/MCC.2015.51. arXiv:1511.02043.

[32] Google. AngularJS JavaScript MVW Framework. 2015. ��: https://angularjs.org/ (visited on 06/25/2018).

[33] Dockerfile reference. ��: https://docs.docker.com/engine/reference/builder/ (visited on 08/07/2018).

[34] Development Best Practices. ��: https://docs.docker.com/develop/dev-best-practices/ (visited on 08/07/2018).

[35] Development Best Practices. ��: https://docs.docker.com/develop/dev-best-practices/ (visited on 08/07/2018).

[36] Fabio Kung. Memory inside Linux containers | Fabio Kung on WordPress.com.2014. ��: https://fabiokung.com/2014/03/13/memory-inside-linux-containers/ (visited on 07/04/2018).

[37] Linux Filesystem Hierarchy: proc. ��: https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html (visited on 08/07/2018).

[38] Paul Menage. Control Groups. ��: https : / / www . kernel . org / doc /Documentation/cgroup-v1/cgroups.txt (visited on 08/07/2018).

[39] Docker security. ��: https://docs.docker.com/engine/security/security/%7B%5C#%7Dother-kernel-security-features (visitedon 08/07/2018).

[40] Docker Inc. “Best practices for writing Dockerfiles”. In: 3.2 (2015), p. 5. ��:https://docs.docker.com/develop/develop-images/dockerfile%7B%5C_%7Dbest-practices/%20https://docs.docker.com/v1.7/articles/dockerfile%7B%5C_%7Dbest-practices/.

Appendix A

Dockerfile

1 # Base Maven image with 8 Java

2 FROM maven :3.5 - jdk -8 - alpine as BUILD

3 # Add project POM

4 COPY pom . xml pom . xml

5 # Add project files

6 COPY t- rex ./t- rex /

7 COPY core - utils ./ core - utils /

8 # Build package

9 RUN mvn -f pom . xml - Dmaven . test . skip = true package

10

11 # Base Tomcat 8.5 image with Java 8

12 FROM tomcat :8.5 - jre8 - alpine

13 # Set JAVA_OPTS for JVM setup , SpringBoot profile and Jenkis CLI path .

14 ENV JAVA_OPTS =" - XX :+ UnlockExperimentalVMOptions -XX :+

UseCGroupMemoryLimitForHeap -XX: MaxRAMFraction =4 - XshowSettings :vm -

Dspring . profiles . active = dev - Djenkins . cli . path =./ lib / jenkins - cli . jar "

15 # Copy application WAR

16 COPY -- from = BUILD /t- rex / target /trex -1.0.0 - SNAPSHOT . war / usr / local / tomcat /

webapps / ROOT . war

17 # Copy Jenkins CLI jar

18 COPY jenkins - cli . jar / usr / local / tomcat / lib /

19 # Copy Tomcat configuration

20 COPY config / server . xml / usr / local / tomcat / conf /

21 # Delete default ROOT webapp

22 RUN rm -fr / usr / local / tomcat / webapps / ROOT && \

23 # Set permissions and user

24 addgroup -S appuser && adduser -S -G appuser appuser && \

25 chgrp -R appuser / usr / local / tomcat && \

26 chmod -R g=u / usr / local / tomcat

27 USER appuser

56

Appendix B

Openshift template: trex-template.yaml

1 kind : Template

2 apiVersion : v1

3 metadata :

4 name : t- rex

5 annotations :

6 description : This is the configuration for deployment of T- Rex in

Phaco

7 tags : spring , java , phaco

8 objects :

9 - kind : DeploymentConfig

10 apiVersion : v1

11 metadata :

12 name : t-rex - deploy

13 spec :

14 template :

15 metadata :

16 labels :


18 spec :

19 containers :

20 - name : t- rex

21 image : dockerhub . rnd . amadeus . net :5000/ t- rex /t- rex : next_phaco_2

.4.2

22 imagePullPolicy : Always

23 ports :

24 - containerPort : 8080

25 protocol : TCP

26 resources :

27 requests :

28 memory : "64 Mi"

29 cpu : "1"

30 limits :

31 memory : "450 Mi"

32 cpu : "2"

33 env :

34 - name : JAVA_OPTS

35 value : -XX :+ UnlockExperimentalVMOptions -XX :+

57

APPENDIX B. OPENSHIFT TEMPLATE: TREX-TEMPLATE.YAML 58

UseCGroupMemoryLimitForHeap - Dspring . profiles . active = int -

Djenkins . cli . path =./ lib / jenkins - cli . jar

36 volumeMounts :

37 - name : context - volume

38 mountPath : / usr / local / tomcat / conf / Catalina / localhost / ROOT . xml

39 subPath : ROOT . xml

40 livenessProbe :

41 httpGet :

42 path : /

43 port : 8080

44 initialDelaySeconds : 60

45 timeoutSeconds : 10

46 readinessProbe :

47 httpGet :

48 path : /

49 port : 8080

50 initialDelaySeconds : 45

51 timeoutSeconds : 5

52 volumes :

53 - name : context - volume

54 secret :

55 secretName : context - file

56 replicas : 2

57 triggers :

58 - type : " ConfigChange "

59 selector :


61 strategy :

62 type : Rolling

63 - kind : Service

64 apiVersion : v1

65 metadata :

66 name : t-rex - service

67 spec :

68 selector :


70 ports :

71 - protocol : TCP

72 port : 80

73 targetPort : 8080

74 - apiVersion : v1

75 kind : Route

76 metadata :

77 name : t-rex - route

78 spec :

79 to:

80 kind : Service

81 name : t-rex - service

82 tls :

83 termination : edge

84 insecureEdgeTerminationPolicy : Redirect

Appendix C

Jenkins: Jenkinsfile, Jenkinstemplate.groovy and .env

C.1 Jenkinsfile

1 #!/ usr / env groovy

2

3 node {

4 checkout scm

5

6 def config = readProperties file : " config /. env "

7 def template = load (" config / Jenkinstemplate . groovy ")

8

9 docker . image ( config [’ BUILD_IMAGE ’]) . inside (’-- net = host -u root -v / var /

run / docker . sock :/ var / run / docker .sock ’) {

10 template . validate ( config )()

11 template . build ( config )()

12 template . publish ( config )()

13 template . deploy ( config )()

14 }

15 }

C.2 Jenkinstemplate.groovy

1 def phacoLib = library ( identifier : ’pipeline - library@master ’, retriever :

modernSCM (

2 [ $class : ’ GitSCMSource ’,

3 credentialsId : ’PHACO ’,

4 remote : ’https :// app - rndstaphaco : agh25Ym11KMX@rndwww . nce . amadeus . net /

git / scm /~ nflinois / pipeline - library .git ’]) )

5

6 def build ( config ) {

7 return {

8 stage (’ Build ’){

9 def dockerTag = "${ config [’ PUBLICATION_PATH ’]} ${ config [’

JAVA_IMAGE_NAME ’]}: ${ config [’ JAVA_IMAGE_VERSION ’]}"

10 sh "mv config /. dockerignore ."

59

APPENDIX C. JENKINS: JENKINSFILE, JENKINSTEMPLATE. GROOVY AND .ENV60

11 sh " docker build --tag $dockerTag -f config / Dockerfile ${ config [’

JAVA_IMAGE_PATH ’]}"

12 }

13 }

14 }

15

16 def publish ( config ) {

17 return {

18 stage (’ Publish ’) {

19 publishToRegistry ("${ config [’ PUBLICATION_PATH ’]} ${ config [’

JAVA_IMAGE_NAME ’]}: ${ config [’ JAVA_IMAGE_VERSION ’]}")

20 }

21 }

22 }

23

24 def deploy ( config ) {

25 return {

26 stage (’ Deploy ’) {

27 if ( env . GIT_BRANCH !=~ config [’ BRANCHES_TO_PROD_REGEXP ’]) {

28 withCredentials ([ usernamePassword ( credentialsId : ’ACS_TENANT ’,

usernameVariable : ’ACS_LOGIN ’, passwordVariable : ’ ACS_PASSWORD

’) ]) {

29 deployWithOc (" ${ ACS_LOGIN }" , "${ ACS_PASSWORD }" , "${ config [’

ACS_PLATFORM ’]}" , "${ config [’ ACS_PROJECT ’]}" , "${ config [’

ACS_TEMPLATE_PATH ’]}")

30 }

31 }

32 else {

33 withCredentials ([ usernamePassword ( credentialsId : ’ DEVBOX_TENANT ’,

usernameVariable : ’ DEVBOX_LOGIN ’, passwordVariable : ’

DEVBOX_PASSWORD ’) ]) {

34 deployWithOc (" ${ DEVBOX_LOGIN }" , "${ DEVBOX_PASSWORD }" , "${ config

[’ DEVBOX_PLATFORM ’]}" , "${ config [’ DEVBOX_PROJECT ’]}" , "${

config [’ DEVBOX_TEMPLATE_PATH ’]}")

35 }

36 }

37 }

38 }

39 }

40

41

42 return this ;

C.3 .env

1 ##### IMAGES SPECIFIC CONFIG : ALL YOUR STACK - SPECIFIC PARAMETERS

2

3 ##

4 # JAVA_IMAGE_ * are specific to the java application server image

containing the java application

5 ##


6 JAVA_IMAGE_NAME =t- rex

7 JAVA_IMAGE_VERSION = next_phaco_2 .4.2

8 JAVA_IMAGE_PATH =./

9

10 ##

11 # * _TEMPLATE_PATH is the path to Openshift template

12 ##

13 TEMPLATE_PATH =./ config / trex - template . yaml

14

15 ##

16 # CREDENTIALS_ID is the ID of the credential set up in Jenkins in order to

fetch the git repositories

17 ##

18 CREDENTIALS_ID = Bitbucket_User

19

20 # BUILD_IMAGE is a PHACO docker image containing all the tools to build /

publish / deploy : docker , oc etc ...

21 # All the steps ( build / test / publish / deploy ...) will be processed inside

this image

22 ##

23 BUILD_IMAGE ==*****************. net :5000/ t- rex /t-rex - builder :0.0.1

24

25

26 ##### COMMON SETTINGS

27

28 ##

29 # PUBLICATION_PATH target the dockerhub on the Artifactory where to

publish your images ,

30 # and where ACS deployments will fetch images from .

31 ##

32 PUBLICATION_PATH =*****************. net :5000/ t- rex /

33

34 ##

35 # * PROJECT is the Openshift project to use on the ACS platform

36 #

37 ##

38 PROJECT =trex - phaco

39

40 ##

41 # APPLICATION is the name of the application to deploy in Openshift

42 ##

43 APPLICATION =t- rex

44

45 ##

46 # BRANCHES_TO_INT_REGEXP define a regexp to be matched by the branch to

carry out the deployment

47 # e.g.: ^ master$ , ^ release -[0 -9]+$, and so on ...

48 ##

49 BRANCHES_TO_INT_REGEXP =^ next$

50 BRANCHES_TO_PROD_REGEXP =^ master$

51

52 ##


53 # * _PLATFORM to deploy for INTEGRATION environment

54 # e.g.: https ://10.45.52.121:8443

55 ##

56 PLATFORM = https ://=*****************. paas . amadeus . net :8443

57 TENANT = ACS_TENANT

Appendix D

Jenkins execution environment: Dock-erfile

1 FROM openjdk :8 - jdk - alpine

2

3 ENV LANG =C.UTF -8

4

5 # Here we install GNU libc ( aka glibc ) and set C.UTF -8 locale as default .

6

7 RUN ALPINE_GLIBC_BASE_URL =" https :// github . com / sgerrand / alpine -pkg - glibc /

releases / download " && \

8 ALPINE_GLIBC_PACKAGE_VERSION ="2.27 - r0" && \

9 ALPINE_GLIBC_BASE_PACKAGE_FILENAME =" glibc -

$ALPINE_GLIBC_PACKAGE_VERSION . apk " && \

10 ALPINE_GLIBC_BIN_PACKAGE_FILENAME =" glibc -bin -


11 ALPINE_GLIBC_I18N_PACKAGE_FILENAME =" glibc -i18n -


12 apk add --no - cache -- virtual =. build - dependencies wget ca - certificates

&& \

13 wget \

14 " https :// raw . githubusercontent . com / sgerrand / alpine -pkg - glibc /

master / sgerrand . rsa . pub " \

15 -O "/ etc / apk / keys / sgerrand . rsa . pub " && \

16 wget \

17 " $ALPINE_GLIBC_BASE_URL / $ALPINE_GLIBC_PACKAGE_VERSION /

$ALPINE_GLIBC_BASE_PACKAGE_FILENAME " \


$ALPINE_GLIBC_BIN_PACKAGE_FILENAME " \


$ALPINE_GLIBC_I18N_PACKAGE_FILENAME " && \

20 apk add --no - cache \

21 " $ALPINE_GLIBC_BASE_PACKAGE_FILENAME " \

22 " $ALPINE_GLIBC_BIN_PACKAGE_FILENAME " \

23 " $ALPINE_GLIBC_I18N_PACKAGE_FILENAME " && \

24 \

25 rm "/ etc / apk / keys / sgerrand . rsa . pub " && \

26 / usr / glibc - compat / bin / localedef -- force -- inputfile POSIX -- charmap

63

APPENDIX D. JENKINS EXECUTION ENVIRONMENT: DOCKERFILE 64

UTF -8 " $LANG " || true && \

27 echo " export LANG = $LANG " > / etc / profile .d/ locale .sh && \

28 \

29 apk del glibc - i18n && \

30 \

31 rm "/ root /. wget - hsts " && \

32 apk del . build - dependencies && \

33 rm \

34 " $ALPINE_GLIBC_BASE_PACKAGE_FILENAME " \

35 " $ALPINE_GLIBC_BIN_PACKAGE_FILENAME " \

36 " $ALPINE_GLIBC_I18N_PACKAGE_FILENAME "

37

38 # Install oc and docker

39 COPY [" oc", "/ usr / local / bin /oc "]

40 RUN chmod a+x / usr / local / bin /oc \

41 && apk update \

42 && apk add --no - cache curl tar bash \

43 && apk add docker

44

45 RUN mkdir -p / data

46 WORKDIR / data

47

48 RUN apk add -- update ca - certificates

t-rex phaco: enabling paas application using twelve-factor app1252942/fulltext01.pdf · to run in a...

Documents