Corredor is an automation script runner and bundler. It loads and processes scripts it has access and offers them to Corteza backend server on request.
It starts a gRPC server with 2 services: - Server scripts with list and exec procedures - Client scripts with list and bundle procedures
See protobuf service definition for details.
Corredor loads and monitors user scripts in the configured locations.
-
Watch and (re)load script dependencies (defined in standard package.json file)
-
Watch and bundle client scripts with webpack
-
Watch and reload server scripts
-
Listen for gRPC requests, provide list of client and server scripts, serve client script bundles and execute server side scripts
-
pull git repositories (with scripts)
-
automatically run unit tests for scripts
-
secret and configuration management (key-value store)
These scripts are executed by Corredor directly or indirectly by the Corteza backend server. Scripts are not jailed or virtualized and run in the same context as the main Corredor app. This will probably be changed in the future to prevent scripts doing destructive actions such as stopping the Corredor server or similar.
Make sure your scripts are audited and accessing only limited data and making only changes they should. Last line of defense is (Docker) container, where the Corredor application is running.
Client scripts are bundled with all their dependencies and 'Corteza webapp boot loader' with Webpack.
This bundles (each Corteza frontend app has one bundle) is loaded alongside the Corteza web application by the user’s browser.
Boot loader makes sure that all client scripts are properly registered in the event bus and executed in right order and in the right context
Make sure your scripts are audited and accessing only limited data and making only changes they should.
docker run --rm -it \
cortezaproject/corteza-server-corredor:latest
docker run --rm -it \
--volume $(pwd)./custom-scripts:/corredor/usr:ro \
cortezaproject/corteza-server-corredor:latest
Corredor uses YARN for package management.
If you insist on using npm, make sure correct package versions are installed (yarn uses yarn.lock
to keep track of exact versions used).
-
yarn
to install dependencies -
yarn serve:dev
to start the development server (restarts when files change) -
yarn test:unit
to run all unit tests (add--watch
watch files for changes and restart)
package.json
You’ll see majority of development dependencies under dependencies key. This is intentional as we want to access certain packages in non-dev mode as well (bundling client scripts with webpack, Typescript compiling, running unit tests)
We’re running corredor server with ts-node, source code is not transpiled with tsc nor bundled with rollup or webpack.
Reasons for these decisions:
-
We need to support server-side scripts These scripts are imported and executed in the same runtime as Corredor Scripts can import other libs and modules
-
This behaviour (importing, executing, loading external modules) should be same in production and development
-
scripts can have (multiple) package.json with defined dependencies that need to be loaded and included
-
one of the possible approaches is to bundle server-side scripts with tools like webpack or rollup. To date, we were not able to construct a feasible solution.
-
webpack issues: foliojs/fontkit#67.
-
rollup issues: issues with inclusion of external dependencies.
-
Corredor read .env
file if exists and merges that with environmental variables.
See dotenv package for details.
All possible configuration is covered in src/config.ts
where all environmental variables are read and processed.
|
|
Description |
|
||
|
|
This setting is used by both, Corredor and API Server. For Corredor server: address where it’s gRPC server is listening on For API server: where can Corredor server be accessed. Note on default value and environment: By default (as configured in the source code), Corredor and API listen/connect-to |
|
||
|
|
This setting is used by both, Corredor and API Server. For Corredor service: where is service listening on (gRPC) For API server: where can Corredor service be accessed. |
|
||
|
|
Defaults to |
|
||
|
|
Are events logged in one-line JSON or formatted to ease development? |
|
||
|
|
Set environment we’re running in. This influences on other settings (see descriptions of other environmental variables). If Recognised values are In production:
- server certificates are enabled (when not explicitly disabled by |
|
||
|
|
Corredor server is shipped with protobuffer definitions inside node_modules dir. You can change that if you need to test/alter proto buffers for development. |
|
||
|
|
Should Corredor gRPC require valid TLS certificates |
|
||
|
|
Path to Corredor server certificates |
|
||
|
|
File name for the crtificate authority |
|
||
|
|
File name for the private key |
|
||
|
|
File name for the public certificate |
|
||
|
|
Should corredor auto update dependencies every time scripts are refreshed? |
|
||
|
|
List of paths (colon delimited) where Corredor should search for scripts |
|
||
|
|
Enable server scripts |
|
||
|
|
Watch server scripts for changes and reload |
|
||
|
|
Enable client scripts |
|
||
|
|
Watch client scripts for changes and reload |
|
||
|
|
Where should Corredor connect to (on behalf of client scripts it is running)? This is used in combination with When starting up Corredor, you can see how Base URLs are set for each service. |
|
||
|
Template to assemble base url for system, compose and messaging REST API ( Default value assumes corredor is running in monolith setup.
If you are running subsystems in separated services, you can set this to When starting up Corredor, you can see how Base URLs are set for each service. |
|
|
||
|
|
Set to a custom Base URL if you want to override value generated with |
|
||
|
|
Set to a custom Base URL if you want to override value generated with |
|
||
|
|
Set to a custom Base URL if you want to override value generated with |
|
||
|
|
Provide frontend base URL info for scripts (accessible through context). |
|
||
|
|
This is a setting for API server, will Corredor be used for server automation? |
|
||
|
|
Connection timeout (from API server to Corredor) CORREDOR_DEFAULT_EXEC_TIMEOUT |
|
|
Timeout for server script execution CORREDOR_LIST_REFRESH |
|
|
Script list refresh frequency CORREDOR_LIST_TIMEOUT |
|
|
Timeout when fetching list of client or server scripts CORREDOR_RUN_AS_ENABLED |
|
|
Allow running server scripts as another user |
|
||
|
|
Should Corredor gRPC client connect with valid TLS certificates |
|
||
|
|
Path to Corredor client certificates |
|
||
|
|
File name for the crtificate authority |
|
||
|
|
File name for the private key |
|
||
|
|
File name for the public certificate |
|
||
|
Server name to use on connection |
RPC server can be manually tested with any gRPC client. If you do not have your favorite, we recommend BloomRPC.
Testing with BloomRPC client & secure server:
-
Click on TSL button on top
-
Add root certificate (ca.crt)
-
Private Key (private.key)
-
Cert Chain (public.crt)
-
Bundling and serving Vue.js components
-
Bundling and serving SCSS and binary content
-
Updating files via gRPC service
-
Support for remote (git repository) location for user scripts
-
Support for basic git operations
-
Automatically running user script unit tests before loading scripts
-
Support TypeScript for user scripts