Customizing local deployment

ASKCOS is highly modularized. The frontend and the backend are fully separated, and so are the API gateway and the prediction services within the backend. It's super easy to deploy only part of ASKCOS, e.g., only the backend as an API server, or minimalist/standalone deployment of individual functionality to reduce memory requirement.

Note for MLPDS members: please refer to askcos2_deploy for more streamlined deployment with docker compose or helm.

Full deployment (the default)

We will start with the full deployment, which we have seen from 01 Introduction.

$ mkdir ASKCOSv2
$ cd ASKCOSv2
$ git clone git@gitlab.com:mlpds_mit/askcosv2/askcos2_core.git
$ cd askcos2_core
$ make deploy

This will run the setup phase automatically, e.g., cloning the repos for backend modules, building docker images, seeding databases. After the setup, the web app will be started with the Graphical User Interface accessible at the host ip address, e.g., 0.0.0.0. Simply type this address in your browser, and you will see the welcome page.

Partial deployment

Behind the scene, the deployment engine makes use of a centralized module config file (askcos2_core/configs/module_config_full.py by default) with the following format:

module_config = {
    "modules_to_start": {
        "atom_map_indigo": True,
        "atom_map_rxnmapper": True,
        "atom_map_wln": True,
        "cluster": True,
        "context_recommender": True,
        ...
    "global": {
        "require_frontend": True,
        "container_runtime": "docker",
        ...
    # config dicts for individual modules
    ...

When we call make deploy, we are invoking relevant sections in deploy.sh which subcalls scripts/pre_deploy.py and enumerate module_config["module_to_start"] to clone/build/start only the needed services. So the idea for partial deployment is straightforward; simply copy module_config_full.py (e.g., as my_module_config.py), set the non-required modules to False, and change the config file in .env:

...
# Module config path (change this to customize deployment)
MODULE_CONFIG_PATH=configs/my_module_config.py
...

Then update the deployment while under askcos2_core

$ make stop
$ make update

Similarly, module_config["global"]["require_frontend"] determines whether the frontend will be started. We have provided a backend-only config too. Set MODULE_CONFIG_PATH to configs/module_config_backend_full.py to use it, and then update the deployment.

Pre-configured partial deployment

We have provided a few pre-configured module config files for typical use cases.

Full deployment with all modules

• With frontend (default): askcos2_core/configs/module_config_full.py
• Without frontend: askcos2_core/configs/module_config_backend_full.py

Partial deployment with all modules needed for retrosynthesis only

• With frontend: askcos2_core/configs/module_config_retro.py
• Without frontend: askcos2_core/configs/module_config_backend_retro.py

Partial deployment with minimal modules for retrosynthesis (only with the template-relevance model)

• With frontend: askcos2_core/configs/module_config_retro_minimal.py
• Without frontend: askcos2_core/configs/module_config_backend_retro_minimal.py

As mentioned above, change the config file in .env:

...
# Module config path (change this to customize deployment)
MODULE_CONFIG_PATH=configs/partial_config_xxx.py
...

Then update the deployment while under askcos2_core

$ make stop
$ make update

In general, the frontend will be less robust under partial deployment settings (e.g., broken buttons/pages here and there). If you get stuck while trying to interact with inactive elements, try a refresh and if it's not working, an (easy) restart from askcos2_core.

$ make restart