Top Menu

Jump to content
  • OpenWMS
    • View all projects
Home
    • Projects
    • Work packages
    • News
    • Getting started
    • Introduction video

      Welcome to OpenProject

      Get an overview

      Get a quick overview of project management and team collaboration with OpenProject.
      You can restart this video from the help menu
    • Help and support
    • Upgrade to Enterprise Edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support
    • Additional resources
    • Data privacy and security policy
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Create a new account
      Forgot your password?

Side Menu

  • Overview
  • Work packages
  • Backlogs
  • News
  • Main Page
    • Table of contents
      • Expanded. Click to collapseCollapsed. Click to showMain Page
        • Hierarchy leafBusiness View
        • Hierarchy leafGetting Started
        • Hierarchy leafInstallation Notes
You are here:
  • Main Page
  • Installation Notes

Content

Installation Notes

  • More
    • Table of contents

Deployment

The application consists of multiple microservices that can be deployed as Docker containers or standalone Java applications. The latter is handy during development to have all required services running in the IDE on the local machine. Even at some warehouse installations customers decided to install the services as *nix daemons directly on the OS, because scaleability is not demanded.

A couple of possible deployment scenarios:

  • Installed as *nix daemons, the services start with the server.
  • Installed as Docker containers on on-premise Kubernetes, or any Kubernetes installation in the cloud, like Microsoft Azure AKS or Amazon EKS.
  • Runnable as web apps on Heroku
  • Runnable as Cloud Native Java applications on CloudFoundry (tested on PCF and Bluemix)

So the actual deployment scenario depends on the individual customer project and the non-functional requirements like scalability, reliability, maintainability etc.

Communication

Nowadays an asynchronous messaging infrastructure is absolutely a must have to run all the microservices and let them properly communicate between each other. Currently RabbitMQ is used as messaging middleware, but also Apache Kafka could be simply used in the middle, so just the connectors need to be replaced.

All queues and exchanges are created by the services at startup, so no scripts are required for this installation.

On a development machine a standard RabbitMQ installation with the default parameters is sufficient to use. In production the server name, vHost and username and password may differ and needs to be overridden.

Persistency

The system is designed that each service has its own relational database system and owns a set of tables. Each service has its own database connection settings, but it is for sure possible and often done, that all services share the same database and the same schema. It is absolutely not enforced that each service must have its own database server installation. For instance at development time you could run one instance of PostgreSQL and point all the services to that installation.

Loading...