This repository contains the OpenTelemetry Astronomy Shop, a microservice-based distributed system intended to illustrate the implementation of OpenTelemetry in a near real-world environment.
FOR THE ORIGINAL README CLICK HERE.
The purpose of this fork is to extend the Astronomy Shop in three ways:
- Add a database to showcase that a persistence layer can also be part of the architecture without causing any problems.
- Create a deployment model to deploy the shop using Ansible and Terraform besides the given Docker-Compose and Kubernetes.
- Add translated EDMM models for Kubernetes, Ansible and Terraform to showcase the transformation result of those three DeMAF plugins in EDMM.
The database integration ensures that also a persistence layer is used in the provided demo-application, making the architecture more comprehensive.
Therefore, a MongoDB is added, which adds the products of the shop into the database as JSON entries. In the default variant of the astronomy shop, only a plain file is used to provide the products.
Thus, the logic of the productcatalogservice is adapted, to initialize and use the additionally provided MongoDB.
The changes of the productcatalogservice and the addition of the MongoDB is integrated into all deployment variants in this fork.
To verify the Ansible MPS Plugin the Astronomy Shop is available as Ansible installation. It is based on the Docker-Compose and installs all components of the shop as docker containers on the local Docker runtime. For each component there is a dedicated Ansible Role representing the loose coupling of the components.
A usage guide can be found in the dedicated README in /ansible.
To verify the Terraform MPS Plugin the Astronomy Shop is available as Terraform installation. It is based on the Docker-Compose and installs all components of the shop as docker containers on the local Docker runtime.
A usage guide can be found in the dedicated README in /terraform.
For all three evaluated technologies (Ansible, Terraform, Kubernetes) there is a transformed target model available.
The target EDMM models can be found in the /edmm directory
In each model the goal is to retrieve a component for each deployed Astronomy Shop component and as many connects-to and hosted_on relations as possible.
This in common, there are also differences in the target models.
Due to the imperative character of Ansible, in the Ansible target model, each component has operations representing the installation of the Docker containers.
In the Terraform target model, there are common component types for all docker_containers, as they all use the same terraform ressource type. This is different in the other two evaluated technologies, where each component has a dedicated type.
For the Kubernetes model there are two variants. The first is the actual result of the translation, lacking hosted_on relations. That is, as the Kubernetes plugin only creates hosted_on relations when a component named container_runtime with a matching type is present in the TADM. Therefore, there is a second target model where this container_runtime has been manually added, before creating the relations. Thus, all components obtain a hosted_on relation.