|
|
@ -12,7 +12,7 @@ manual installation of all components which should work on most of the Linux
|
|
|
|
distributions.
|
|
|
|
distributions.
|
|
|
|
|
|
|
|
|
|
|
|
The distribution of our choice is CentOS, currently in version 7. It is a well
|
|
|
|
The distribution of our choice is CentOS, currently in version 7. It is a well
|
|
|
|
known server distribution, derived from enterprise distrubution from Red Hat, so
|
|
|
|
known server distribution, derived from enterprise distribution from Red Hat, so
|
|
|
|
it is very stable and widely used system with long term support. There are
|
|
|
|
it is very stable and widely used system with long term support. There are
|
|
|
|
[EPEL](https://fedoraproject.org/wiki/EPEL) additional repositories from Fedora
|
|
|
|
[EPEL](https://fedoraproject.org/wiki/EPEL) additional repositories from Fedora
|
|
|
|
project, which adds newer versions of some packages into CentOS, which allows us
|
|
|
|
project, which adds newer versions of some packages into CentOS, which allows us
|
|
|
@ -37,7 +37,7 @@ require small tweaks to work properly.
|
|
|
|
|
|
|
|
|
|
|
|
For automatic installation is used a set of Ansible scripts. Ansible is one of
|
|
|
|
For automatic installation is used a set of Ansible scripts. Ansible is one of
|
|
|
|
the best known and used tools for automatic server management. It is required
|
|
|
|
the best known and used tools for automatic server management. It is required
|
|
|
|
only to have SSH access to the server and ansible installed on the client
|
|
|
|
only to have SSH access to the server and Ansible installed on the client
|
|
|
|
machine. For further reading is supposed basic Ansible knowledge. For more info
|
|
|
|
machine. For further reading is supposed basic Ansible knowledge. For more info
|
|
|
|
check their [documentation](http://docs.ansible.com/ansible/intro.html).
|
|
|
|
check their [documentation](http://docs.ansible.com/ansible/intro.html).
|
|
|
|
|
|
|
|
|
|
|
@ -49,7 +49,7 @@ edit two files -- set addresses of hosts and values of some variables.
|
|
|
|
|
|
|
|
|
|
|
|
### Hosts configuration
|
|
|
|
### Hosts configuration
|
|
|
|
|
|
|
|
|
|
|
|
First, it is needed to set IP addresses of your computers. Common practise is to
|
|
|
|
First, it is needed to set IP addresses of your computers. Common practice is to
|
|
|
|
have multiple files with definitions, one for development, another for
|
|
|
|
have multiple files with definitions, one for development, another for
|
|
|
|
production for example. Example configuration is in _development_ file. Each
|
|
|
|
production for example. Example configuration is in _development_ file. Each
|
|
|
|
component of ReCodEx project can be installed on different server. Hosts can be
|
|
|
|
component of ReCodEx project can be installed on different server. Hosts can be
|
|
|
@ -113,8 +113,8 @@ key-value pair per line, separated by colon. Values with brief description:
|
|
|
|
- _broker_notifier_port_ -- Port to above, should be the same as for API itself
|
|
|
|
- _broker_notifier_port_ -- Port to above, should be the same as for API itself
|
|
|
|
(_webapi_public_port_)
|
|
|
|
(_webapi_public_port_)
|
|
|
|
- _broker_notifier_username_ -- Username for HTTP Authentication for reports
|
|
|
|
- _broker_notifier_username_ -- Username for HTTP Authentication for reports
|
|
|
|
- _broker_notifier_password_ -- Password for HTTP Authentication for reporst
|
|
|
|
- _broker_notifier_password_ -- Password for HTTP Authentication for reports
|
|
|
|
- _monitor_websocket_addr_ -- Address, where websocket connection from monitor
|
|
|
|
- _monitor_websocket_addr_ -- Address, where WebSocket connection from monitor
|
|
|
|
will be available
|
|
|
|
will be available
|
|
|
|
- _monitor_websocket_port_ -- Port to above.
|
|
|
|
- _monitor_websocket_port_ -- Port to above.
|
|
|
|
- _monitor_firewall_websocket_ -- Open above port in firewall, "yes" or "no".
|
|
|
|
- _monitor_firewall_websocket_ -- Open above port in firewall, "yes" or "no".
|
|
|
@ -216,7 +216,7 @@ $ git submodule update --init
|
|
|
|
|
|
|
|
|
|
|
|
#### Install worker on Linux
|
|
|
|
#### Install worker on Linux
|
|
|
|
|
|
|
|
|
|
|
|
It is supposed that your current working directory is that one with clonned
|
|
|
|
It is supposed that your current working directory is that one with cloned
|
|
|
|
worker source codes.
|
|
|
|
worker source codes.
|
|
|
|
|
|
|
|
|
|
|
|
- Prepare environment running `mkdir build && cd build`
|
|
|
|
- Prepare environment running `mkdir build && cd build`
|
|
|
@ -293,7 +293,7 @@ picture.
|
|
|
|
A systemd unit file is distributed with the worker to simplify its launch. It
|
|
|
|
A systemd unit file is distributed with the worker to simplify its launch. It
|
|
|
|
integrates worker nicely into your Linux system and allows you to run it
|
|
|
|
integrates worker nicely into your Linux system and allows you to run it
|
|
|
|
automatically on system startup. It is possible to have more than one worker on
|
|
|
|
automatically on system startup. It is possible to have more than one worker on
|
|
|
|
every server, so the provided unit file is templated. Each instance of the
|
|
|
|
every server, so the provided unit file is a template. Each instance of the
|
|
|
|
worker unit has a unique string identifier, which is used for managing that
|
|
|
|
worker unit has a unique string identifier, which is used for managing that
|
|
|
|
instance through systemd. By default, only one worker instance is ready to use
|
|
|
|
instance through systemd. By default, only one worker instance is ready to use
|
|
|
|
after installation and its ID is "1".
|
|
|
|
after installation and its ID is "1".
|
|
|
@ -308,7 +308,7 @@ Check with
|
|
|
|
```
|
|
|
|
```
|
|
|
|
if the worker is running. You should see "active (running)" message.
|
|
|
|
if the worker is running. You should see "active (running)" message.
|
|
|
|
|
|
|
|
|
|
|
|
- Worker can be stopped or restarted accordigly using `systemctl stop` and
|
|
|
|
- Worker can be stopped or restarted accordingly using `systemctl stop` and
|
|
|
|
`systemctl restart` commands.
|
|
|
|
`systemctl restart` commands.
|
|
|
|
- If you want to run worker after system startup, run:
|
|
|
|
- If you want to run worker after system startup, run:
|
|
|
|
```
|
|
|
|
```
|
|
|
@ -394,7 +394,7 @@ Check with
|
|
|
|
```
|
|
|
|
```
|
|
|
|
if the broker is running. You should see "active (running)" message.
|
|
|
|
if the broker is running. You should see "active (running)" message.
|
|
|
|
|
|
|
|
|
|
|
|
- Broker can be stopped or restarted accordigly using `systemctl stop` and
|
|
|
|
- Broker can be stopped or restarted accordingly using `systemctl stop` and
|
|
|
|
`systemctl restart` commands.
|
|
|
|
`systemctl restart` commands.
|
|
|
|
- If you want to run broker after system startup, run:
|
|
|
|
- If you want to run broker after system startup, run:
|
|
|
|
```
|
|
|
|
```
|
|
|
@ -614,9 +614,9 @@ $ python setup.py install --install-scripts /usr/bin
|
|
|
|
|
|
|
|
|
|
|
|
#### Usage
|
|
|
|
#### Usage
|
|
|
|
|
|
|
|
|
|
|
|
As stated before cleaner should be cronned, on linux systems this can be done by
|
|
|
|
As stated before cleaner should be croned, on linux systems this can be done by
|
|
|
|
built in `cron` service or if there is `systemd` present cleaner itself provides
|
|
|
|
built in `cron` service or if there is `systemd` present cleaner itself provides
|
|
|
|
`*.timer` file which can be used for cronning from `systemd`. On Windows systems
|
|
|
|
`*.timer` file which can be used for croning from `systemd`. On Windows systems
|
|
|
|
internal scheduler should be used.
|
|
|
|
internal scheduler should be used.
|
|
|
|
|
|
|
|
|
|
|
|
- Running cleaner from command line is fairly simple:
|
|
|
|
- Running cleaner from command line is fairly simple:
|
|
|
@ -631,7 +631,7 @@ $ systemctl start recodex-cleaner.timer
|
|
|
|
```
|
|
|
|
```
|
|
|
|
0 0 * * * /usr/bin/recodex-cleaner -c /etc/recodex/cleaner/config.yml
|
|
|
|
0 0 * * * /usr/bin/recodex-cleaner -c /etc/recodex/cleaner/config.yml
|
|
|
|
```
|
|
|
|
```
|
|
|
|
- Add cleaner to Windows cheduler service with following command:
|
|
|
|
- Add cleaner to Windows scheduler service with following command:
|
|
|
|
```
|
|
|
|
```
|
|
|
|
> schtasks /create /sc daily /tn "ReCodEx Cleaner" /tr \
|
|
|
|
> schtasks /create /sc daily /tn "ReCodEx Cleaner" /tr \
|
|
|
|
"\"C:\Program Files\ReCodEx\cleaner\recodex-cleaner.exe\" \
|
|
|
|
"\"C:\Program Files\ReCodEx\cleaner\recodex-cleaner.exe\" \
|
|
|
@ -738,7 +738,7 @@ $ npm install
|
|
|
|
For easy production usage there is an additional package for managing NodeJS
|
|
|
|
For easy production usage there is an additional package for managing NodeJS
|
|
|
|
processes, `pm2`. This tool can run your application as a daemon, monitor
|
|
|
|
processes, `pm2`. This tool can run your application as a daemon, monitor
|
|
|
|
occupied resources, gather logs and provide simple console interface for
|
|
|
|
occupied resources, gather logs and provide simple console interface for
|
|
|
|
managing app's state. To install it globally into your system run:
|
|
|
|
managing state of the app. To install it globally into your system run:
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
```
|
|
|
|
# npm install pm2 -g
|
|
|
|
# npm install pm2 -g
|
|
|
@ -771,7 +771,7 @@ Both modes can be configured to use different ports or set base address of used
|
|
|
|
API server. This can be configured in `.env` file in root of the repository.
|
|
|
|
API server. This can be configured in `.env` file in root of the repository.
|
|
|
|
There is `.env-sample` file which can be just copied and altered.
|
|
|
|
There is `.env-sample` file which can be just copied and altered.
|
|
|
|
|
|
|
|
|
|
|
|
The production mode can be run also as a demon controled by `pm2` tool. First
|
|
|
|
The production mode can be run also as a demon controlled by `pm2` tool. First
|
|
|
|
the web application has to be built and then the server javascript file can run
|
|
|
|
the web application has to be built and then the server javascript file can run
|
|
|
|
as a daemon.
|
|
|
|
as a daemon.
|
|
|
|
|
|
|
|
|
|
|
|