![](bg5.png)
rows of the Table.
From this analysis, many similarities emerged be-
tween the three platforms. All of them allow to spec-
ify the desired application using a tree-like data model
within portable formats, such as JSON and YAML.
Furthermore, all the orchestrators map resources in
similar ways for deployment units, containers, and
clusters, where the main difference is given by the
naming conventions.
With regard to volume and networking manage-
ment, different platforms implement different strate-
gies. However, all the volume management ap-
proaches share the possibility to delegate the provi-
sioning of volumes to the platform, taking for granted
that volume properties are indicated in the application
specification. As for networking, each of the software
grants accessibility to deployment units and contain-
ers, both within and outside the cluster, although they
manage it in different ways. Finally, all the platforms
allow to execute configuration commands on the de-
ployed instances, by accessing them directly.
The analysis of container cluster interoperability
laid the groundwork for a unified approach. This is
further explored in the next section, where the com-
mon specification format and the interfaces to the dif-
ferent cluster orchestrators are discussed.
4.2 Application Description
One of the key aspects of this work is the development
of a standard-based approach for the topology de-
scription of containerised applications, which lever-
ages the TOSCA standard.
As discussed in Section 2.2, TOSCA Simple Pro-
file includes several node types for container-based
application topologies. According to the analysis in
Table 1, we mapped TOSCA Container Runtime to
Deployment Unit entities and TOSCA Container Ap-
plication to containers. This allows to easily describe
containerised applications within a cluster in terms
of nodes. However, we found that using the plain
TOSCA Container Application would flatten the node
hierarchy present in the Simple Profile specification,
removing the possibility to assign meaningful roles
to each node in the topology (e.g. Database, Web-
Server).
t o s c a . nod e s . C o n t a i n e r . A p p l i c a t i o n :
d e r i v e d f r o m : t o s c a . nod e s . R oot
r e q u i r e m e n t s :
- h o s t :
c a p a b i l i t y : t o s c a . c a p a b i l i t i e s . Compute
nod e : t o s c a . n ode s . C o n t a i n e r . Ru n t i me
r e l a t i o n s h i p : t o s c a . r e l a t i o n s h i p s . H ost edOn
- s t o r a g e :
c a p a b i l i t y : t o s c a . c a p a b i l i t i e s . S t o r a g e
- n e tw o rk :
c a p a b i l i t y : t o s c a . c a p a b i l i t i e s . E n d p o i n t
Listing 1: TOSCA Container Application node.
For the sake of clarity, Listing 1 shows the
TOSCA Container Application node which represents
a generic container-based application. Other than
hosting, storage and network requirements, no prop-
erties are defined. Besides, it directly derives from the
root node as all other TOSCA base node types do. If,
on the one hand, this allows to have consistent def-
initions for basic requirements, capabilities and life-
cycle interfaces, on the other one, customisation is
only possible by type extension.
t o s c a . nod e s . D a t a b a se :
d e r i v e d f r o m : t o s c a . nod e s . R oot
p r o p e r t i e s :
name:
t y p e : s t r i n g
d e s c r i p t i o n : t h e l o g i c a l name o f t h e d a t a b a s e
p o r t :
t y p e : i n t e g e r
d e s c r i p t i o n : >
t h e p o r t t h e u n d e r l y i n g d a t a b a s e s e r v i c e
w i l l l i s t e n t o f o r d a t a
u s e r :
t y p e : s t r i n g
d e s c r i p t i o n : >
t h e u s e r a c c o u n t name f o r DB a d m i n i s t r a t i o n
r e q u i r e d : f a l s e
p a s sw o r d:
t y p e : s t r i n g
d e s c r i p t i o n : >
t h e p a ssw o rd f o r t h e DB u s e r a c c o u n t
r e q u i r e d : f a l s e
r e q u i r e m e n t s :
- h o s t :
c a p a b i l i t y : t o s c a . c a p a b i l i t i e s . Compute
nod e : t o s c a . n od e s .DBMS
r e l a t i o n s h i p : t o s c a . r e l a t i o n s h i p s . H ost edOn
c a p a b i l i t i e s :
d a t a b a s e e n d p o i n t :
t y p e : t o s c a . c a p a b i l i t i e s . E n d p o in t . D a t a b a s e
Listing 2: TOSCA Database node.
t o s c a . nod e s . C o n t a i n e r . D a t a b a s e :
d e r i v e d f r o m : t o s c a . nod e s . C o n t a i n e r . A p p l i c a t i o n
d e s c r i p t i o n : >
TOSCA C o n t a i n e r f o r D a t a b a s e s whi c h e mp l oy s
t h e same c a p a b i l i t i e s a nd p r o p e r t i e s o f t h e
t o s c a . nod e s . D a t a b a se b u t w h ich e x t e n d s f r om
t h e C o n t a i n e r . A p p l i c a t i o n n o d e t y p e
p r o p e r t i e s :
u s e r :
r e q u i r e d : f a l s e
t y p e : s t r i n g
d e s c r i p t i o n : >
User a c c o u n t name f o r DB a d m i n i s t r a t i o n
p o r t :
r e q u i r e d : f a l s e
t y p e : i n t e g e r
d e s c r i p t i o n : >
The p o r t t h e d a t a b a s e s e r v i c e w i l l u s e
t o l i s t e n f o r in c omi n g d a t a a n d r e q u e s t s .
name:
r e q u i r e d : f a l s e
t y p e : s t r i n g
d e s c r i p t i o n : >
The name o f t h e d a t a b a s e .
p a s sw o r d:
r e q u i r e d : f a l s e
t y p e : s t r i n g
d e s c r i p t i o n : >
The p a ss w o rd f o r t h e DB u s e r a c c o u n t
c a p a b i l i t i e s :
d a t a b a s e e n d p o i n t :
t y p e : t o s c a . c a p a b i l i t i e s . E n d p o in t . D a t a b a s e
Listing 3: TOSCA Container Database node.
As a result, we extended the TOSCA Simple Pro-
file hierarchy for containers, by deriving from the
Enabling Container Cluster Interoperability using a TOSCA Orchestration Framework
131