# 6.1.2 Platform sourcing

The DGT platform is designed to bolster its network, comprising individual nodes. Each node operates as a full-fledged server solution, replete with numerous services and software components. Even a standalone node presents a complete solution, capable of supporting application solutions and deployable by a single organization. Although the DGT framework can be implemented across various environments compatible with its technology stack, this section simplifies the deployment process by focusing on Ubuntu OS within a Docker virtualization context.

### 6.1.2.1 Directory and Package Structure

DGTs are software that is distributed as source files. Единственная точка распространения представляет собой репозиторий GitHub. Inside the repository, you have to choose the right version for your needs. The versions have individual designations, now the most recent versions are [Matagami](https://github.com/DGT-Network/DGT-Matagami) (stable) and Athabasca. In the case of building from source code using Docker Compose, the installation of the platform version is carried out by cloning to the home (or other selected) directory:

```
git clone https://github.com/DGT-Network/DGT-Matagami
```

Within the directory of the corresponding version, you can find subdirectories corresponding to the individual packages of the system:

<table data-header-hidden><thead><tr><th width="77"></th><th width="131"></th><th width="159"></th><th></th></tr></thead><tbody><tr><td>#</td><td>Folder</td><td>Sub Folder</td><td>Description</td></tr><tr><td>1</td><td>CORE</td><td>..</td><td>A subversion distributed under the APACHE 2.0 license and implying basic functionality. In fact, it is an improved version of Sawtooth</td></tr><tr><td>1.1</td><td> </td><td>bin</td><td>Top-level classes and packages that make the system work as a whole.</td></tr><tr><td>1.2</td><td> </td><td>clusters</td><td>Network configuration files and topology files.</td></tr><tr><td>1.3</td><td> </td><td>consensus</td><td>The code behind the consensus mechanism</td></tr><tr><td>…</td><td> </td><td>…</td><td> </td></tr><tr><td>1.7</td><td> </td><td>families</td><td>Code That Implements a Transaction Processor.</td></tr><tr><td>…</td><td> </td><td>…</td><td> </td></tr><tr><td>1.10</td><td> </td><td>rest-api</td><td>Code that implements the Node API.</td></tr><tr><td>1.11</td><td> </td><td>validator</td><td>The code that keeps the validator running.</td></tr><tr><td>2</td><td>GARANASKA_BETA</td><td>..</td><td>A subversion distributed under the LGPL 3.0 license, containing the Garanaska financial subsystem (tokenization) and other advanced features</td></tr><tr><td>2.1</td><td> </td><td>bin</td><td>Top-level classes and packages that make the system work as a whole.</td></tr><tr><td>2.2</td><td> </td><td>cli</td><td>Support for Console Version Commands</td></tr><tr><td>2.3</td><td> </td><td>clusters</td><td>Network configuration files and topology files.</td></tr><tr><td>2.4</td><td> </td><td>docker</td><td>Docker Configuration</td></tr><tr><td>2.5</td><td> </td><td>notaries</td><td>Code that supports the work of notary nodes</td></tr><tr><td>…</td><td> </td><td> </td><td> </td></tr><tr><td>2.14</td><td> </td><td>sdk</td><td>Library modules that support basic cryptography and networking functions</td></tr><tr><td>2.15</td><td> </td><td>validator</td><td>The code that keeps the validator running</td></tr><tr><td>2.16</td><td> </td><td>Seth</td><td>Smart Contract Processor.</td></tr><tr><td>3</td><td>CLIENTS</td><td>..</td><td>Example of client-side code that works with remote hosts.</td></tr><tr><td>4</td><td>DOCS</td><td>..</td><td>System Documentation.</td></tr></tbody></table>

Thus, the version is represented by two basic branches (packages), which differ in functionality: Garanaska, in addition to the basic functionality of CORE to support general transactions and the test family of transactions bgt, is equipped with additional functionality that works with financial transactions, notary nodes, and support for virtual machines for smart contracts.

### 6.1.2.2 Shell scripts

Since DGT comes as source code, to run and manage the platform, you will need to run a few additional commands that support building, configuring parameters, and running server components. Within the Linux system, you can use the standard Bash shell for standard node manipulations.

[Bash](https://en.wikipedia.org/wiki/Bash_\(Unix_shell\)), short for _Bourne Again SHell_, is a _Unix shell and command language_ written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell. It has been widely adopted as the default command-line interpreter on most Linux distributions, as well as on macOS until Catalina version, and it's available for use on various other operating systems. As a shell, Bash is both a command language and a scripting language. It provides an interface for users to interact with the operating system by typing commands into a console or terminal window. Users can launch programs, manage files and directories, and perform other system tasks by entering commands that Bash executes.

The deployed version of the source code comes with standard Bash scripts responsible for preparing, building, and running the nodes, as well as accessing their commands. There are two versions of such files: single scripts (separate script files, each of which is responsible for one command), and macro (an interpreter of sub-commands), which is responsible for executing different commands.

In the next steps to deploy the nodes and configure them, we'll use commands based on Bash command scripts.

Single Scripts are scripts that are responsible for configuring and using the main functionality, they can be run from the main directory where the DGT code is located (obtained, for example, using the git clone command). The main command scripts are shown in the table below.

<table data-header-hidden><thead><tr><th width="67.33333333333331"></th><th width="239"></th><th></th></tr></thead><tbody><tr><td>#</td><td>Command/Script File</td><td>Propose</td></tr><tr><td>1</td><td>control.sh</td><td>A super-script designed to run internal commands that control platform components replaces and complements the individual scripts listed below. The parameters for this script are below</td></tr><tr><td>2</td><td>upDecCluster.sh</td><td>A generic script that is responsible for building, running a single node, cluster, or entire network. Accepts cluster number and node number as parameters</td></tr><tr><td>3</td><td>upDgtDashboard.sh</td><td>Script responsible for launching DGT Dashboard (web-client)</td></tr><tr><td>4</td><td>upDgtGrafana.sh</td><td>The script responsible for starting the Grafana server, the component that is responsible for collecting statistics inside the solution</td></tr><tr><td>5</td><td>upDgtNotary.sh</td><td>A script that is responsible for running notary nodes (performing off-chain calculations)</td></tr><tr><td>6</td><td>downDGTCluster.sh</td><td>A script that stops a node or cluster takes the coordinates of a node as input</td></tr><tr><td>7</td><td>downDgtDashboard.sh</td><td>Script that stops Dashboard</td></tr><tr><td>8</td><td>downDgtGrafana.sh</td><td>A script that stops the Grafana server</td></tr><tr><td>9</td><td>downDgtNotary.sh</td><td>Script that stops the Notary's node</td></tr></tbody></table>

All scripts are designed to run in a Linux environment and only apply to nodes running within the home operating system (internal or virtual hosts): many virtual nodes and even clusters can be running on one physical host platform.

&#x20;The superscript in the table above does control.sh accept the commands listed below.

<table data-header-hidden><thead><tr><th width="74"></th><th width="112"></th><th></th><th></th></tr></thead><tbody><tr><td>#</td><td>Sub command</td><td>Description</td><td>Example</td></tr><tr><td>1</td><td>show</td><td>Show peer param</td><td><code>bash control.sh c1_2 show</code></td></tr><tr><td>2</td><td>run</td><td>Call run command inside of Node Environment</td><td><code>bash control.sh c1_1 run bgt list</code></td></tr><tr><td>3</td><td>up</td><td>Create and start DGT containers</td><td><code>bash control.sh c1_1 up [-d]</code></td></tr><tr><td>4</td><td>mode</td><td>Change peer mode</td><td><code>bash control.sh c1_1 &#x3C;mode name></code></td></tr><tr><td>5</td><td>ps</td><td>List all run containers</td><td><code>bash control.sh c1_1 ps [-q/--services]</code></td></tr><tr><td>6</td><td>restart</td><td>Restarting DGT services</td><td><code>bash control.sh c1_1 restart</code></td></tr><tr><td>7</td><td>build</td><td>Build or rebuild services</td><td><code>bash control.sh c1_1 build validator-dgt</code></td></tr><tr><td>8</td><td>copy</td><td>Make peer copy</td><td><code>bash control.sh c1_1 copy &#x3C;new peer name></code></td></tr><tr><td>9</td><td>list</td><td>Print DGT peer's params</td><td><code>bash control.sh dgt list [-v]</code></td></tr><tr><td>10</td><td>stop</td><td>Stop DGT services</td><td><code>bash control.sh c1_1 stop</code></td></tr><tr><td>11</td><td>del</td><td>Drop peer declaration</td><td><code>bash control.sh c4_1 del</code></td></tr><tr><td>12</td><td>shell</td><td>Enter into peer shell</td><td><code>bash control.sh c1_1 shell</code></td></tr><tr><td>13</td><td>edit</td><td>Edit DGT peer params</td><td><code>bash control.sh c1_1 edit [&#x3C;param name>]</code></td></tr><tr><td>14</td><td>down</td><td>Stop and remove DGT containers, networks, images, and volumes</td><td><code>bash control.sh c1_1 down</code></td></tr><tr><td>15</td><td>dec</td><td>Run dec commands</td><td><code>bash control.sh c1_1 dec list</code></td></tr><tr><td>16</td><td>start</td><td>Start DGT services</td><td><code>bash control.sh c1_1 start</code></td></tr><tr><td>17</td><td>token</td><td>Generate API access token</td><td><code>bash control.sh c1_1 token</code></td></tr><tr><td>18</td><td>add</td><td>Add new DGT peer</td><td><code>bash control.sh c4_1 add</code></td></tr></tbody></table>

If you use scripts frequently, you can make their invocation smoother (without prefixes and extensions), for example, by configuring the environment through the following steps:

* **Make the file executable**. You have to make sure that the file has execute permissions. This can be done with the _chmod_ command: `chmod +x control.sh`
* **Remove the .sh extension** (if you want to call it without specifying an extension). Simply rename the file: `mv control.sh control`
*   **Add the directory path to the PATH environment variable** (if this directory is not already part of the PATH). Let's say your script is in the /home/username/scripts directory.

    o    Then add this directory to the PATH by editing the _«_`.bashrc`» or «`.profile`» file  in your home directory. Open the «`.bashrc` `file`»  in a text editor: `nano ~/.bashrc`.

    o    Add the following line to the end of the file: `export PATH=$PATH:/home/username/scripts`.

    o    Save the file and close the editor. For the changes to take effect, run the following steps: `source ~/.bashrc`.
* **Specify the interpreter at the beginning of the script**. Make sure the first line of your script points to the interpreter, for example: `source ~/.bashrc`.

Using the scripts described, the following are the step-by-step procedures for configuring and starting DGT nodes.

Using Docker to launch virtual nodes leads to the creation of "servers within a server," or containers, which have their own execution environment. Most node commands will be applied inside such a container. To enter the console within a node, a special command is used. For example, for node c1-1, the command is:

```
docker exec -it shell-dgt-c1-1 bash
```

This command temporarily moves the user into the node's execution shell (the guest system). Exiting this shell and returning to the host system is done with the _exit_ command.

### **6.1.2.3 Deployment Process Overview**

The deployment involves several key steps:  &#x20;

* **Acquisition**: Obtain the relevant version of the DGT repository.
* **Configuration**: Adjust the node’s basic settings.
* **Containerization**: Utilize Docker Compose to build a container.
* **Connection**: Link the node to the network.
* **Health Check**: Run basic commands that allow you to perform a basic check of the functionality of a node or network segment.

Below is a schematic diagram of the process:

<figure><img src="https://3210145376-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSvanFNAf6Jf8kwvqcdRQ%2Fuploads%2FFgiP86Bqr2s5xz9ks9ta%2Fimage.png?alt=media&#x26;token=affed380-7e92-43c3-840c-60618b1f81bc" alt=""><figcaption><p><em>Figure 110 General Steps for Deployment with Docker</em></p></figcaption></figure>

### 6.1.2.4 Deployment Scenarios

The deployment scenarios are broken down into individual nodes, virtual networks, and physical networks. Key preliminary notes include:

* **Integration and Connection**: The deployment and network integration are managed through the "magical" command `up.DgtCluster.sh`. The DGT Network is segmented into node groups (clusters), with each node fulfilling a specific role.
* **Parameter Configuration**: Basic parameters, like certificate settings and transaction processing times, are derived from a standard configuration (found in the "`DGT-Matagami\CORE\etc`_._" directory) for each node image. Post-creation and connection, a node’s main parameters are stored in the “`DGT-Matagami\dgt_clust`” directory.
* **Service Ports**: Nodes consist of multiple services, each requiring configured network access parameters.
* **Cryptographic System**: The entire network adheres to a unified cryptographic framework, detailing signature methods, address systems, and transaction encryption.
* **Transaction Families**: The DGT network accommodates various transaction types, known as "transaction families." Basic network configuration includes:

o   `dgt-set`: Essential for network operation, managing settings, and topology.

o   `xcert`: Necessary for deploying closed/private segments, managing certificates.

o   `bgt`: A test family for token management transactions, testing network functionality.

### **6.1.2.5 System Accessibility**

The functionality can be accessed through multiple avenues:

* **CLI console/command line**. In this case, you log in to the console of the running container and execute the commands directly.
* **Dashboard component/service** (initiated from a client computer browser). In this case, commands are submitted using a web client (chain explorer).
* **API (detailed in Developer Guide section)**. To check this way, you must use tools such as Postman or curl.  Almost all commands in DGT have their counterpart as Rest API endpoints.

These methods facilitate functional assessments.

### **6.1.2.6 Pre-built Configurations**

Depending on solution requirements, you can deploy one of the predefined configurations or devise a custom setup:

* **SMALL**: Features one DGT network node for basic core function verification under hardware constraints, alongside two notary nodes (key keeper and regular notary).
* **MEDIUM**: Comprises 2 DGT clusters (3+2) with two notaries on a single virtual machine, focusing on notary functions and node interactions.
* **HIGH**: Involves the deployment of at least 16 DGT nodes across various cluster configurations, along with 2-4 notaries, primarily utilizing minting functionality.

Additionally, the basic configuration ([DGT CORE](https://airtable.com/appKXbPrpiDaiJq3A/tbleO4qOglHrAPm7z/viw1asxflFPInxT5q/recncNyl3uv5x5Xrl?blocks=hide)) offers essential commands and a test transaction family, while the extended system ([GARANASKA](https://airtable.com/appKXbPrpiDaiJq3A/tbleO4qOglHrAPm7z/viw1asxflFPInxT5q/recF5cauMzCFIAfNu?blocks=hide)) facilitates financial transactions with DEC, notary and certificate management (decentralized identification), arbitrary smart contracts, and Ethereum network interactions.
