The containers in the docker-compose file use a bridge network (named opentosca
).
Dependencies that are accessed over that bridge network are marked with "via docker-compose network".
Because the docker compose file is also used during development on one or more components most dependencies are actually accessed through the public IP of the host computer by default (marked with "via docker host"). This allows starting some containers from the docker compose and some in a local dev setup. However it can also lead to problems if the public IP has changed or a firewall blocks access to the public IP from the containers.
If everything is started via docker-compose on Windows or Mac then it may be possible to use host.docker.internal
as the public IP/domain.
(see also https://docs.docker.com/desktop/windows/networking/#use-cases-and-workarounds or https://docs.docker.com/desktop/mac/networking/#use-cases-and-workarounds)
On windows host.docker.internal
is also known for the windows host.
For mac this is not the case.
A workaround for mac is to add the following entry to the /etc/hosts
file (needs administrator rights!):
# manually added
127.0.0.1 host.docker.internal
Image: opentosca/container:latest
(stable images also available) GitHub
Main orchestrator of the whole OpenTOSCA ecosystem. Provides the application bus (for inter application communication) and the management bus (for management/deployment commands). Hosts a plan generator to generate various BPEL plans (deployment, termination, scale-up, ...) of topologies given via a CSAR. Invokes management and deployment plans, relays messages to implementation artifacts (IAs) hosted on the engine-ia or on components of a topology. Manages metadata, logging, etc. of deployed instances.
Ports:
- 1337: Main API
- 1883: MQTT (used for distributed/federated deployment of multiple container instances)
- 8081-8087: Application Bus and Management Bus
- engine-ia-jdk8 via docker-compose network
Used to deploy and execute implementation artifacts implemented as WebServices and used via the management bus. - engine-plan-bpel via docker-compose network
OR engine-plan-bpmn via docker-compose network
⚠️ engine-plan-bpel
is currently unmaintained but still necessary for executing BPEL plans.
Used to run deployment and management plans. Only one engine is technically necessary, but it must be able to execute all plans (workflows) in the CSAR archives in question. - Optional: container-repository via docker host
Used to enable topology completion, instance freeze, and defrost features.
- Optional dind configured by end user as deployment endpoint
Used as docker engine (in docker) to create docker containers for testing, demonstration and learning purposes. - Optional openstack compatible endpoint, configured by end user as deployment endpoint
Used to provision required VM resources and machines.
Image: opentosca/winery:latest
GitHub
Implementations of research features. Used to fill in missing information of CSARs.
Ports:
- 8091 (internal 8080): Main API
- container via docker host
Image: opentosca/ui:latest
GitHub
OpenTOSCA user interface for the container. Manages the deployment and management processes. Uses the winery to fetch CSARs to be imported into the container. The winery instance that is used as the CSAR repository can be changed in the administration settings of the UI at runtime.
Ports:
- 8088 (internal 8080): User Interface
- container via docker host (configured from browser URL)
- winery via docker host (configured from browser URL)
Used as CSAR repository.
Image: opentosca/ode:latest
GitHub
BPEL workflow execution engine (a dockerized version of Apache ODE) used to execute the deployment or management workflows of a CSAR. Default workflow engine (generator in container outputs BPEL workflows).
Ports:
- 9763: Main API
Image: opentosca/camunda-bpmn:latest
GitHub
Workflow engine based on the Camunda BPMN Engine to execute BPMN2 workflows. Optional if all workflows use BPEL.
Ports:
- 8092 (internal 8080): Main API
Image (JDK 8): opentosca/engine-ia:latest-jdk8
GitHub
Image (JDK 17): opentosca/engine-ia:latest-jdk17
GitHub
Application server (Apache Tomcat) for hosting and executing implementation artifacts (IA).
IAs can be executed in the generic environment of the engine-ia-jdk8
or engine-ia-jdk17
(e.g. IAs that deploy new VMs) or can trigger execution of IAs on deployed containers/VMs.
💡 There are two versions of the engine-ia, one running on an older version of java (JDK 8) for legacy IAs and one running on a newer version (JDK 17) for new IAs. New IAs should always use the JDK 17 version of the engine-ia!
Ports:
- 8090 (internal 8080): Main API (JDK 8)
- 8093 (internal 8080): Main API (JDK 17)
Image: opentosca/winery:latest
GitHub
Modelling UI for TOSCA topologies and repository for CSARs.
Ports:
- 8080: User Interface and API
- container via docker host
Used to generate plans from the current topology. workflow-modeler
via docker host
Part of the Winery containertopology-modeler
via docker host
Part of the Winery container
Image: docker:20.10-dind
Packaged docker in docker to allow OpenTOSCA to create new docker containers. The ports available for these containers can be adjusted in the docker-compose overlay. The provided default overlays expose the port range 9990-9999.
Ports:
- 2222 (internal 2375): docker demon API
- 9990-9999: for created docker containers, can be extended in override
Image: built from local Dockerfile
Proxy calls into the docker-compose network. Optional component.
Ports:
- 80: Proxy port