mirror of
https://github.com/fluencelabs/gitbook-docs
synced 2025-04-24 23:42:15 +00:00
GitBook: [2.0.0] 24 pages modified
This commit is contained in:
boneyard93501
gitbook-bot
parent
2da6642faf
commit
2b6f070ec5
@ -11,7 +11,7 @@
|
||||
* [Aqua](knowledge_aquamarine/hll.md)
|
||||
* [Marine](knowledge_aquamarine/marine/README.md)
|
||||
* [Marine CLI](knowledge_aquamarine/marine/marine-cli.md)
|
||||
* [Marine Repl](knowledge_aquamarine/marine/marine-repl.md)
|
||||
* [Marine REPL](knowledge_aquamarine/marine/marine-repl.md)
|
||||
* [Marine Rust SDK](knowledge_aquamarine/marine/marine-rs-sdk.md)
|
||||
* [Tools](knowledge_tools.md)
|
||||
* [Node](node.md)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Marine Repl
|
||||
# Marine REPL
|
||||
|
||||
[`mrepl`](https://crates.io/crates/mrepl) is a command line tool to locally run a Marine instance to inspect, run, and test Wasm modules and service configurations. We can run the Repl either with `mrepl` or `marine repl`
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Marine Rust SDK
|
||||
|
||||
The [marine-rs-sdk](https://github.com/fluencelabs/marine-rs-sdk) empowers developers to write services suitable for peer hosting in peer-to-peer networks using the Marine Virtual Machine by enabling the wasm32-wasi compile target for Marine. For an introduction to writing services with the marine-rs-sdk, see the [Developing Modules And Services]() section.
|
||||
The [marine-rs-sdk](https://github.com/fluencelabs/marine-rs-sdk) empowers developers to write services suitable for peer hosting in peer-to-peer networks using the Marine Virtual Machine by enabling the wasm32-wasi compile target for Marine.
|
||||
|
||||
### API
|
||||
|
||||
@ -364,7 +364,7 @@ mod tests {
|
||||
```
|
||||
|
||||
1. We wrap a basic _greeting_ function with the `[marine`\] macro which results in the greeting.wasm module
|
||||
2. We wrap our tests as usual with `[cfg(test)]` and import the fluence_test crate._ Do **not** import _super_ or the _local crate_.
|
||||
2. We wrap our tests as usual with `[cfg(test)]` and import the fluence _test crate._ Do **not** import _super_ or the _local crate_.
|
||||
3. Instead, we apply the `[marine_test]` to each of the test functions by providing the path to the config file, e.g., Config.toml, and the directory containing the Wasm module we obtained after compiling our project with `marine build`. It is imperative that project compilation proceeds the test runner otherwise there won't be the required Wasm file.
|
||||
4. The target of our tests is the `pub fn greeting` function. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace -- `greeting` in this example case.
|
||||
|
||||
|
||||
@ -155,5 +155,5 @@ This makes decomposition a pain: why decouple services if we need them to know s
|
||||
|
||||
* [Tetraplet implementation in the Aquamarine interpreter](https://github.com/fluencelabs/aquamarine/blob/master/crates/polyplets/src/tetraplet.rs)
|
||||
* [Example of checking tetraplets for authorization in Fluent Pad](https://github.com/fluencelabs/fluent-pad/blob/main/services/history-inmemory/src/service_api.rs#L91)
|
||||
* [Getting tetraplets with Rust SDK](https://github.com/fluencelabs/rust-sdk/blob/master/crates/main/src/call_parameters.rs#L35)
|
||||
* [Getting tetraplets with Rust SDK](https://github.com/fluencelabs/marine-rs-sdk/blob/7c8f65fb64e64ba7e068b124449e745ef28c742d/sdk/src/call_parameters.rs#L35)
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
### Fluence Proto Distributor: FLDIST
|
||||
|
||||
\`\`[`fldist`](https://github.com/fluencelabs/proto-distributor) is a command line interface \(CLI\) to Fluence peers allowing for the lifecycle management of services and offers the fastest and most effective way to service deployment.
|
||||
[`fldist`](https://github.com/fluencelabs/proto-distributor) is a command line interface \(CLI\) to Fluence peers allowing for the lifecycle management of services and offers the fastest and most effective way to service deployment.
|
||||
|
||||
```text
|
||||
mbp16~(:|✔) % fldist --help
|
||||
|
||||
@ -37,7 +37,7 @@ With Docker and VSCode in place:
|
||||
|
||||
* When asked for branch, press enter \(main\)
|
||||
* When asked for volume, press enter \(unique\)
|
||||
* open Terminal within VSCode \(ctrl-\`\)
|
||||
* Open Terminal in VSCode \(ctrl-\`\)
|
||||
|
||||
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ In order to have a service available out-of-the-box with the necessary startup a
|
||||
|
||||
Note that the deployment process is a fully automated workflow requiring you to merely submit your service assets, i.e., Wasm modules and configuration scripts, in the appropriate format as a PR to the [Fluence](https://github.com/fluencelabs/fluence) repository.
|
||||
|
||||
At this point you should have a solid grasp of creating service modules and their associated configuration files. See the [Developing Modules And Services]() section for more details.
|
||||
At this point you should have a solid grasp of creating service modules and their associated configuration files.
|
||||
|
||||
Our first step is fork the [Fluence](https://github.com/fluencelabs/fluence) repo by clicking on the Fork button, upper right of the repo webpage, and follow the instructions to create a local copy. In your local repo copy, checkout a new branch with a new, unique branch name:
|
||||
|
||||
@ -24,7 +24,7 @@ In our new branch, we create a directory with the service name in the _deploy/bu
|
||||
```text
|
||||
cd deploy/builtins
|
||||
mkdir my-new-super-service
|
||||
cd new-super-service
|
||||
cd my-new-super-service
|
||||
```
|
||||
|
||||
Replace _my_-_new-super-service_ with your service name.
|
||||
@ -55,7 +55,7 @@ Blueprints capture the service name and dependencies:
|
||||
}
|
||||
```
|
||||
|
||||
where
|
||||
Where
|
||||
|
||||
* name specifies the service's name and
|
||||
* dependencies list the names of the Wasm modules or the Blake3 hash of the Wasm module
|
||||
@ -75,7 +75,7 @@ If you decide to use the hash approach, please use the hash for the config files
|
||||
|
||||
### **Start Script**
|
||||
|
||||
Start scripts, which are optional, execute once after service deployment or node restarts and are submitted as _air_ files and may be accompanied by a _json_ file containing the necessary parameters.
|
||||
Start scripts, which are optional, execute once after service deployment or node restarts and are submitted as _AIR_ files and may be accompanied by a _json_ file containing the necessary parameters.
|
||||
|
||||
```text
|
||||
;; on_start.air
|
||||
@ -97,7 +97,7 @@ and the associated data file:
|
||||
|
||||
### **Scheduling Script**
|
||||
|
||||
Scheduling scripts allow us to decouple service execution from the client and instead can rely on a cron-like scheduler running on a node to trigger our service\(s\). For a brief overview, see [additional concepts]()
|
||||
Scheduling scripts allow us to decouple service execution from the client and instead can rely on a cron-like scheduler running on a node to trigger our service\(s\).
|
||||
|
||||
### Directory Structure
|
||||
|
||||
|
||||
@ -1,10 +1,6 @@
|
||||
# Setting Up Your Environment
|
||||
|
||||
In order to develop within the Fluence solution, [Node](https://nodejs.org/en/), [Rust](https://www.rust-lang.org/tools/install) and small number of tools are required.
|
||||
|
||||
### NodeJs
|
||||
|
||||
Download the \[installer\]\([https://nodejs.org/en/download/](https://nodejs.org/en/download/)\) for your platform and follow the instructions.
|
||||
In order to develop within the Fluence solution, [Rust](https://www.rust-lang.org/tools/install) and small number of tools are required.
|
||||
|
||||
### Rust
|
||||
|
||||
|
||||
@ -12,13 +12,9 @@ where the `-d` flag runs the container in detached mode, `-e` flag sets the envi
|
||||
|
||||
Once the container is up and running, we can tail the log \(output\) with
|
||||
|
||||
```text
|
||||
docker logs -f fluence
|
||||
```
|
||||
|
||||
Which gives os the logged output:
|
||||
|
||||
```bash
|
||||
docker logs -f fluence
|
||||
|
||||
[2021-03-11T01:31:17.574274Z INFO particle_node]
|
||||
+-------------------------------------------------+
|
||||
| Hello from the Fluence Team. If you encounter |
|
||||
@ -40,8 +36,6 @@ Which gives os the logged output:
|
||||
<snip>
|
||||
```
|
||||
|
||||
|
||||
|
||||
For future interaction with the node, we need to retain the server peer id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx. And if you feel the need to snoop around the container:
|
||||
|
||||
```bash
|
||||
@ -57,33 +51,20 @@ Now that we have a local node, we can use the `fldist` tool to interact with it.
|
||||
|
||||
Let's inspect our node and check for any available modules and interfaces:
|
||||
|
||||
```text
|
||||
fldist get_modules \
|
||||
--node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--pretty
|
||||
```
|
||||
|
||||
Let's us check on available modules and gives us:
|
||||
|
||||
```bash
|
||||
fldist get_modules --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
client seed: 43PmCycRqLt9h3t5Dbmkc3vpNjF9qrNDEVLvQhjCQYSj
|
||||
client peerId: 12D3KooWQXTe2aFzUsYFf9mBHe4poey45nmAoa8PQwCc2iy9BLMW
|
||||
node peerId: 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
[[]]
|
||||
```
|
||||
|
||||
And checking on available interfaces:
|
||||
|
||||
```text
|
||||
fldist get_interfaces \
|
||||
--node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
--expand
|
||||
```
|
||||
|
||||
Results in:
|
||||
|
||||
```text
|
||||
fldist get_interfaces --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
client seed: DGf3E48yr73tJbxXpfxyNiRNFsoeRgxKUCpUDYafkXaN
|
||||
client peerId: 12D3KooWEY37spzSbrg1GTFEo67p9X8cFqmYDHuzaBWWJ9aRT1G2
|
||||
node peerId: 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
60000
|
||||
[ [] ]
|
||||
to expand interfaces, use get_interfaces --expand
|
||||
```
|
||||
|
||||
Since we just initiated the node, we expect no modules and no interfaces and the `fldist` queries confirm our expectations. To further explore and validate the node, we can create a small [greeting](https://github.com/fluencelabs/fce/tree/master/examples/greeting) service.
|
||||
@ -96,80 +77,49 @@ cd fluence-greeeter
|
||||
echo '{ "name":"greeting"}' > greeting_cfg.json
|
||||
```
|
||||
|
||||
We just grabbed the greeting Wasm file from the Fluence repo and created a service configuration file, `greeting_cfg.json`, which allow us to create a new GreetingService:
|
||||
We just grabbed the greeting wasm file from the Fluence repo and created a service configuration file, greeting\_cfg.json, which allow us to create a new GreetingService:
|
||||
|
||||
```bash
|
||||
fldist --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
new_service \
|
||||
--ms examples/greeting/artifacts/greeting.wasm:greeting_cfg.json \
|
||||
-n GreetingService
|
||||
```
|
||||
|
||||
Which gives us the service id:
|
||||
|
||||
```text
|
||||
fldist --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx new_service --ms /Users/bebo/localdev/fce/examples/greeting/artifacts/greeting.wasm:greeting_cfg.json -n GreetingService
|
||||
client seed: 7VtMT7dbdfuU2ewWHEo42Ysg5B9KTB5gAgM8oDEs4kJk
|
||||
client peerId: 12D3KooWRSmoTL64JVXna34myzAuKWaGkjE6EBAb9gaR4hyyyQDM
|
||||
node peerId: 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
uploading blueprint GreetingService to node 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx via client 12D3KooWRSmoTL64JVXna34myzAuKWaGkjE6EBAb9gaR4hyyyQDM
|
||||
NON-CONSTANT BLUEPRINT ID: Expected blueprint id to be predefined as 88b9b328-7c2b-44fe-8f2c-01b52db12fd9, but it was generated by node as 94d02dfe696549a98e23c5de8713e7c6d6f91694e823790a2f6dcfcc93843be3
|
||||
service id: 64551400-6296-4701-8e82-daf0b4e02751
|
||||
service created successfully
|
||||
```
|
||||
|
||||
We now have a greeting service running on our node. As always, take note of the service id.
|
||||
We now have a greeting service running on our node. As always, make a note of the service id, 64551400-6296-4701-8e82-daf0b4e02751.
|
||||
|
||||
```bash
|
||||
fldist get_modules \
|
||||
--node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--pretty
|
||||
```
|
||||
|
||||
Which now lists our uploaded module:
|
||||
|
||||
```text
|
||||
[
|
||||
{ "config": {
|
||||
"logger_enabled":true,
|
||||
"logging_mask":null,
|
||||
"mem_pages_count":100,
|
||||
"mounted_binaries":null,
|
||||
"wasi":{
|
||||
"envs":null,
|
||||
"mapped_dirs":null,
|
||||
"preopened_files":[]
|
||||
},
|
||||
"hash":"80a992ec969576289c61c4a911ba149083272166ffec2949d9d4a066532eec1d",
|
||||
"name":"greeting"
|
||||
}
|
||||
]
|
||||
fldist get_modules --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
client seed: HXoV5UfoBAtT8vM2zibm6oiTt7ecFBbP3xSF2dec4RTF
|
||||
client peerId: 12D3KooWGJ8crCtYy4es835v5dVhTbD7snyLxCQupuiq2sLSXMyA
|
||||
node peerId: 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
[[{"config":{"logger_enabled":true,"logging_mask":null,"mem_pages_count":100,"mounted_binaries":null,"wasi":{"envs":null,"mapped_dirs":null,"preopened_files":[]}},"hash":"80a992ec969576289c61c4a911ba149083272166ffec2949d9d4a066532eec1d","name":"greeting"}]]
|
||||
```
|
||||
|
||||
Yep, checking once again for modules, the output confirms that the greeting service is available. Writing a small AIR script allows us to use the service:
|
||||
|
||||
```text
|
||||
service GreetingService("service-id"):
|
||||
greeting: string -> string
|
||||
|
||||
func greeting(name:string, node:string, greeting_service_id: string) -> string:
|
||||
on node:
|
||||
GreetingService greeting_service_id
|
||||
res <- GreetingService.greeting(name)
|
||||
<- res
|
||||
(xor
|
||||
(seq
|
||||
(call relay (service "greeting") [name] result)
|
||||
(call %init_peer_id% (returnService "run") [result])
|
||||
)
|
||||
(call %init_peer_id% (returnService "run") [%last_error%])
|
||||
)
|
||||
```
|
||||
|
||||
Compile the script with [`aqua-cli`](https://doc.fluence.dev/aqua-book/getting-started/quick-start) and use the resulting file with the`fldist` tool:
|
||||
|
||||
```text
|
||||
fldist --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
--node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx \
|
||||
run_air \
|
||||
-p greeting.greeting.air \
|
||||
-d '{"service": "64551400-6296-4701-8e82-daf0b4e02751", "name":"Fluence"}'
|
||||
```
|
||||
Copy and save the script to greeting.clj and we can use our trusted `fldist` tool:
|
||||
|
||||
```bash
|
||||
<snip>
|
||||
fldist --node-id 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx run_air -p greeting.clj -d '{"service": "64551400-6296-4701-8e82-daf0b4e02751", "name":"Fluence"}'
|
||||
client seed: 8eXzEhypvkYST82sakeS4NeGFSyxqyCSpv2GQj3tQK5E
|
||||
client peerId: 12D3KooWLFqJwuHNe2kWF8SMgX6cm24L83JUADFcbrj5fC1z3b21
|
||||
node peerId: 12D3KooWLFCmDq4vDRfaxW2GA6kYnorxAiie78XzQrVDVoWEZnPx
|
||||
Particle id: 14db3aff-b1a9-439e-8890-d0cdc9a0bacd. Waiting for results... Press Ctrl+C to stop the script.
|
||||
===================
|
||||
[
|
||||
"Hi, Fluence"
|
||||
@ -191,18 +141,13 @@ Yep, our node and the tools are working as expected. Going back to the logs, we
|
||||
|
||||
```bash
|
||||
docker logs -f fluence
|
||||
```
|
||||
|
||||
And check from the bottom up:
|
||||
|
||||
```text
|
||||
<snip>
|
||||
[2021-03-12T02:42:51.041267Z INFO aquamarine::particle_executor] Executing particle 14db3aff-b1a9-439e-8890-d0cdc9a0bacd
|
||||
[2021-03-12T02:42:51.041927Z INFO particle_closures::host_closures] Executed host call "64551400-6296-4701-8e82-daf0b4e02751" "greeting" (96us 700ns)
|
||||
[2021-03-12T02:42:51.046652Z INFO particle_node::network_api] Sent particle 14db3aff-b1a9-439e-8890-d0cdc9a0bacd to 12D3KooWLFqJwuHNe2kWF8SMgX6cm24L83JUADFcbrj5fC1z3b21 @ [/ip4/172.17.0.1/tcp/61636/ws]
|
||||
```
|
||||
|
||||
Looks like our node container and logging is up and running and ready for your development use. As the Fluence team is rapidly developing, make sure you stay up to date. Check the repo or [Docker hub](https://hub.docker.com/r/fluencelabs/fluence) and update with `docker pull fluencelabs/fluence:latest`.
|
||||
Looks like our node container and logging is up and running and ready for your development use. As the Fluence team is rapidly developig, make sure you stay up to date. Check the repo or [Docke rhub](https://hub.docker.com/r/fluencelabs/fluence) and update with `docker pull fluencelabs/fluence:latest`.
|
||||
|
||||
Happy composing!
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user