Information Classification: External Restricted.
See https://www.chili-publish.com/security

Architecture

With the End of Life of CHILI publisher (On Premise) this information is obsolete, and only kept as reference.

CHILI publisher now lives on as GraFx Publisher in the platform of CHILI GraFx

Introduction

CHILI Publisher needs to be installed on the hardware of customers. A lot of customers ask us what the best configuration would be.
There is no perfect setup, since every setup will be different depending on several influencers:

CHILI Publisher will (almost) never run stand-alone. The product is made to be integrated, so the application offered to end-users also has an impact on the choices you will make.

Things to consider

  • Speed

  • Scalability

  • Traffic

  • Security

In e.g. a development environment, most of the factors will have less importance than in a production environment.

CHILI Publisher consists our of 3 parts:

  • CHILI Server (composition engine)

  • CHILI Webapp

  • CHILI Data

These parts can be setup on 1 machine, or separated over several machines.

Basic setup

To start, you can setup a server with all elements on 1 server.


The data for CHILI Publisher is 1 folder (CHILI Data). In the setup you can define where the data resides (e.g. D:\CHILIData)
The webserver (CHILI WebApp) and the windows service (CHILI Server) are also installed on the same machine.

This will work for most cases.

From there on, you can split all elements according to your architecture / wishes / requirements for the application.

Separate the data

You could seperate the storage of the data.
Reason: scalability, speed, security, ... (your choice)
This could be done through any protocol you choose.
Important: Speed of Access to the data is very important.
CHILI Publisher doesn't use a database, and relies on file operations
The faster the storage, the faster CHILI Publisher will work.
Som NAS solutions offer good scalability, but lack speed.
Mostly SAN solutions (more expensive) have both scalability and speed.

Separate the Web Application and Service

Once your data is stored on the network, you can add or separate the CHILI Service from the web application
Then it's a matter of configuration, because the CHILI Service will 'look' at the queue (in the data folder) for tasks.
If tasks appear, the server will pick them up, and process.
This also means you can add more CHILI Services to process more data simultaniously.
You can try multiple setups with this application and what effect editing, saving, uploading  ... will have on your setup and where potential bottlenecks can arise.

https://www.chili-publish.com/ServerInfrastructure2/ServerInfrastructure.html

Add more webservers

If you application has to take a lot of traffic, you can add more webservers in front of the application.
You could even add a load balancer to spread the load. (no different than other web solutions would handle this)

Network

From a network and security point of view, there are several options. The webserver has to be reachable for the end-users.
The other machines can be placed in a trusted zone, but you could also choose to place them all inside the DMZ.
Please consult your IT / Security / Network administrator what would be the best option in your case. 

The servers behind (CHILI Data and CHILI Server) could be in a trusted zone, but the servers will need to be able to talk to each other.

The CHILI Editor (runs in the client) will talk to the server through our Werservice API (port 80)

Conclusion

If you start, you can start with everything on 1 machine.
Moving elements is a matter of time.
Installing an extra server can be done live, and will add speed right away.
Moving data to another server will only take the time of copying the data, and reconfiguring the setup. (most of the time is needed for the data transfer itself)

All information on this page must be treated as External Restricted, or more strict. https://www.chili-publish.com/security