In kind, when we bind-mount a host directory it is first mounted into the kind container at /mnt, then into the pod at the desired location.
We accidentally picked this up for full-blown k8s, and were creating volumes at /mnt. This changes the behavior for both kind and regular k8s so that bind mounts are only allowed if a fully-qualified path is specified. If no path is specified at all, a default storageClass is assumed to be present, and the volume managed by a provisioner.
Eg, for kind, the default provisioner is: https://github.com/rancher/local-path-provisioner
```
stack: test
deploy-to: k8s-kind
config:
test-variable-1: test-value-1
network:
ports:
test:
- '80'
volumes:
# this will be bind-mounted to a host-path
test-data-bind: /srv/data
# this will be managed by the k8s node
test-data-auto:
configmaps:
test-config: ./configmap/test-config
```
Reviewed-on: cerc-io/stack-orchestrator#741
Co-authored-by: Thomas E Lackey <telackey@bozemanpass.com>
Co-committed-by: Thomas E Lackey <telackey@bozemanpass.com>
```
--include-tags TEXT Only include requests with matching tags
(comma-separated).
--exclude-tags TEXT Exclude requests with matching tags (comma-
separated).
```
Reviewed-on: cerc-io/stack-orchestrator#734
Co-authored-by: Thomas E Lackey <telackey@bozemanpass.com>
Co-committed-by: Thomas E Lackey <telackey@bozemanpass.com>
* Add Postgres exporter and it's dashboard
* Use templating for watcher dashboard
* Add subgraph related panels to watcher dashboard
* Remove individual watcher dashboards and update instructions
* Deploy osmosis on Urbit fake ship
* Remove Urbit configuration from existing osmosis stack
* Add a separate stack for Osmosis front end on Urbit
* Run script for renaming build files with bash
* Add environment variables required in urbit osmosis build
* Fix BASEPATH in compose file
* Remove ipfs-glob-host from network config in osmosis readme
* Use laconic branch for osmosis frontend
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* Setup Prometheus and Grafana for monitoring stack
* Add dashboard for azimuth watchers
* Add a dashboard for sushiswap watcher
* Persist prometheus server data
* Additional metrics in watcher dashboards
* Update dashboards and add for merkl sushiswap watcher
* Add dashboards for remaining azimuth watchers
* Separate out preconfigured watcher dashboards and add instructions
* Keep the empty dashboards dir
* Refactor to make Urbit app deployment script generic
* Rename urbit pod and update instructions
* Add a flag to allow skipping app installation on Urbit
* Make remote Urbit app deployment scripts generic
* Move remote deployment scripts to urbit fixturenet
* Update and use existing kubo pod for Urbit glob hosting
* Separate out uniswap gql proxy in a stack
* Use proxy server from watcher-ts
* Add a flag to enable/disable the proxy server
* Update env configuratoin for uniswap urbit app stack
* Update stack file for uniswap urbit app stack
* Fix env variables in instructions
* Use IPFS for hosting glob files for Urbit
* Add env configuration for IPFS endpoints to instructions
* Make ship pier dir configurable in remote deployment script
* Update remote deployment script to accept glob hash arg
* Create uniswap-frontend stack
* Add stack for building uniswap frontend app
* Add a container for Urbit fake ship
* Update with deployment command
* Add a service for uniswap app deployment to urbit
* Use a script to start urbit ship to handle restarts
* Rename stack name to uniswap-urbit-app
* Rename build.sh to build-app.sh and check if build already exists
* Rename stack directory name
* Update uniswap build restart on failure
* Perform uniswap app deployment in the urbit container
* Add steps to create glob for the app
* Tail /dev/null after deployment
* Add steps to install the app to desk
* Host glob files for uniswap
* Update repo branch
* Update readme with command to get urbit password
* Update readme
* Update readme to open urbit web UI
* Expose the port on glob hosting container
* Avoid exposing urbit http port
* Add scripts for installing uniswap on remote urbit instance
* Configure GQL proxy for uniswap app
* Use laconic branch for app repo
* Rename urbit pod for uniswap app deployment
---------
Co-authored-by: Prathamesh Musale <prathamesh.musale0@gmail.com>
* Update stack to run azimuth job runner
* Run azimuth watcher in active mode
* Update stack to run job-runners for all watchers
* Update ports in job-runner health checks
* Map metrics ports to host
* Configure historical block processing batch size for Azimuth watcher
* Use deployment command for azimuth stack
---------
Co-authored-by: neeraj <neeraj.rtly@gmail.com>
Co-authored-by: Prathamesh Musale <prathamesh.musale0@gmail.com>
This fixes three issues:
1. #644 (build output)
2. #646 (error on startup)
3. automatic env quote handling (related to 2)
For the build output we now have:
```
#################################################################
Built host container for /home/telackey/tmp/iglootools-home with tag:
cerc/iglootools-home:local
To test locally run:
docker run -p 3000:3000 cerc/iglootools-home:local
```
For the startup error, it was hung waiting for the "success" message from the next generate output (itself a workaround for a nextjs bug fixed by this PR we submitted: https://github.com/vercel/next.js/pull/58276).
I added a timeout which will cause it to wait up to a maximum _n_ seconds before issuing:
```
ERROR: 'npm run cerc_generate' exceeded CERC_MAX_GENERATE_TIME.
```
On the quoting itself, I plan on adding a new run-webapp command, but I realized I had a decent spot to do effect the quote replacement on-the-fly after all when I am already escaping the values for insertion/replacement into JS.
The "dequoting" can be disabled with `CERC_RETAIN_ENV_QUOTES=true`.
* Upgrade merkl-sushiswap-v3-watcher-ts release
* Increase blockDelayInMilliSecs for merkl-sushiswap-v3 watcher
* Upgrade sushiswap-v3-watcher-ts release
* Add sushiswap-v3 watcher to stack list
* Avoid mapping ports that are not required to be exposed
* Add a sushiswap-v3 watcher stack
* Add services for watcher db and server
* Add service for watcher job-runner
* Use 0.0.0.0 for watcher server config
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* Separate ponder indexer and ponder watcher and add second ponder indexer
* Handle review changes
* Update config to point ponder watcher to indexer 2 to indexer 1
* Update Ponder demo
* Use deployed ERC20 contract in second Ponder indexer
* Add order by timestamp in Ponder watcher app entities query
* Upgrade go-nitro version to v0.1.2-ts-port-0.1.9
* Decrease Ponder start block to process contract transfer event at deployment
---------
Co-authored-by: Shreerang Kale <shreerangkale@gmail.com>
* Use durable store for in-process Nitro node
* Update setup for external go-nitro node
* Add a separate service for ipld-eth-server with remote Nitro node
* Update repo branches / versions
* Wait for external Nitro node endpoint and update instructions
* Update repo branches
* Add support to pass ratesFile in config
* Change branch for ponder to laconic-esm
* Fix repo name for ponder
---------
Co-authored-by: Shreerang Kale <shreerangkale@gmail.com>
* Remove reverse payment proxy service from payment stack
* Remove run-reverse-payment-proxy.sh
* Remove reverse payment proxy port from readme
---------
Co-authored-by: Shreerang Kale <shreerangkale@gmail.com>
* Use ponder in watcher mode and indexer mode separately in payments stack
* Refactor config file and configure env variables for watcher mode
* Update demo.md for payments stack
* Handle review changes
* Setup config to pay for watcher to indexer GQL queries
* Fix config in stack for making payments in watcher ponder app
* Update demo for payment from watcher to indexer mode Ponder apps
* Use laconic-esm brannch for ponder
---------
Co-authored-by: Shreerang Kale <shreerangkale@gmail.com>
* First part of deployments for external repos
* Generate deployment dir
* Create empty config file
* Copy script files into deployment
* Run scripts in deployment
* Refactor
* Integrate external plugins
* Remove debug output
* Add a fixturenet-payments stack
* Export the WebSocket port in fixturenet-eth-geth service
* Add container to run a go-nitro node
* Add container to deploy Nitro contracts
* Read contract addresses from a volume when running the Nitro node
* Add a service for Nitro reverse payment proxy
* Expose payment proxy endpoint to be accessible from host
* Map nitro node messaging and payment proxy ports to host
* Use container to deploy Nitro contracts in mobymask-v3 stack
* Use a common contract deployment script from mobymask-v3 stack
* Add MobyMask contract deployment and watcher services
* Fixes for contract deployment and watcher scripts
* Add a container and service for mobymask-snap
* Add MobyMask app service
* Add container and service for a ponder app
* Fix ponder setup and update instructions
* Handle review comments
* Use enablepaidrpcmethods flag in reverse payment proxy server
* Update go-nitro branch
* Fixes for mobymask-v3 stack
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* Add a mobymask-v3 stack
* Fix Nitro deployment script and add watcher container
* Setup Nitro config
* Run build after setting Nitro addresses
* Setup consensus config
* Add a container for web-app
* Use node 18 for the web-app
* Persist Nitro node data to a volume
* Add clean up steps
* Update query rates
* Add steps to force rebuild and persist peers_ids volume
* Update mobymask-v2 stack with pubsub option
* Update watcher-ts version
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* Update mobymask v1 watcher with new contract
* Update mobymask v1 stack with deployment commands
* Use release tag for mobymask-watcher-ts repo
* Upgrade MobyMask version in v2 stack to use latest contract
* Update sushiswap-subgraph stack to point to filecoin endpoint
* Deploy blocks subgraph in sushiswap-subgraph stack
* Update subgraph config
* Remove duplicate nativePricePool
* Enable debug logs in graph-node and update instructions
* Two additional miner nodes in fixturenet-lotus
* Revert experimental change for additional miner nodes
* Set ETHEREUM_REORG_THRESHOLD env for graph-node to catch up to head
* Take ETH RPC endpoint for graph-node from env
* Set default values for RPC endpoint in graph-node
* Rename fixturenet-graph-node pod to graph-node
* Clean up sushiswap-subgraph stack
* Use deployment command in sushiswap-subgraph stack
* Add a separate fixturenet-sushiswap-subgraph stack
* Fix pods in fixturenet-sushiswap-subgraph
* Fix fixturenet subgraph deployment commands and instructions
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* Use ip utility to get the required miner node multiaddr
* Persist lotus node data to support restarts
* Add clean up steps to instructions
* Fix lotus-seed sector-dir arg
* Add a sushiswap stack with contract deployments
* Add watcher services
* Add a service for the info app
* Add instructions to run smoke tests
* Use sushi-info-watcher in demo mode
* Turn off block prefetching
* Fix sushiswap demo instructions
* Use release version and add healthcheck in Lotus stack
* Wait for Lotus node to start before sushiswap watchers
---------
Co-authored-by: Nabarun <nabarun@deepstacksoft.com>
* move health check inside startup script
* remove pre-built genesis
* move health check inside startup script
* remove pre-built genesis
* Use hardcoded paths for Lotus node data directories
* Persist proof parameters
* Write out miner node's multiaddr with docker network IP
* Enable Lotus ETH RPC API and bind to all available interfaces
* Fund a known account
---------
Co-authored-by: iskay <ikay@lakeheadu.ca>
Co-authored-by: Ian Kay <ian@knowable.vc>
* forward more vars for debugging
forward CERC_GETH_VERBOSITY
forward CERC_STATEDIFF_DB_LOG_STATEMENTS
forward CERC_REMOTE_DEBUG
* fix env var
* remote flag can be set from env
* random nits
* geth - visibility of migration status
* forward CERC_RUN_STATEDIFF to geth container
* fix ipld-eth-server vars
* fix fixturenet-eth-loaded stack
* fixturenet geth genesis - include mergeNetsplitBlock
* forward CERC_STATEDIFF_DB_GOOSE_MIN_VER to env file
* add TAG_SUFFIX arg to lighthouse build
intended to avoid sporadic failures when running lcli on github CI runners, likely related to non-portable builds
* Add a stack for Gelato watcher
* Add option to create and use a state snapshot
* Add commands to create and import a state checkpoint
* Rename ipld-eth-server endpoint env variables
* Fix default env variable
Former-commit-id: 8b4b5deba8
* Setup gateway-server with watchers
* Add js script to merge toml config files
* Remove individual watcher configs
* Add all azimuth watchers in stack
* Fix toml-js install
* Use env variables for ipld-eth-server endpoints
* Checkout to version tag in azimuth-watcher-ts repo
Former-commit-id: 5a94aed7f7
* add fixturenet-gaia stack
* add fixturenet-pocket
* integrate with eth fixturenet
* separate out fixturenet-gaia
* use pocket-deployments Dockerfile
---------
Co-authored-by: iskay <ian@knowable.vc>
Co-authored-by: Ian <ikay@lakeheadu.ca>
Former-commit-id: b23b5ae3bf
* Remove unnecessary check on watcher endpoint
* Add instructions to run MobyMask app with a watcher on network
* Move watcher on network docs to a separate folder
* Add nginx config for watcher endpoint
* Add expected output logs
* Add sample nginx config for hosting the app
* Update instructions
Former-commit-id: 018950858b
* Use the latest stable optimism release
* Remove unnecessary repos from repo-list
* Add op-proposer service to fixturenet-optimism stack
* Add jq and bash to op-proposer image
* Update instructions
* Update op-batcher and op-geth commands
Former-commit-id: 988be0ef9a
* Refactor L2 enpoint check to contract deployment script
* Add instructions to join to an existing watcher network
* Include mobymask-v2-watcher-ts in repositories setup
* Add a clean up section and expected outputs
* Add a troubleshooting section
* Use lxdao frontend
* Update instructions for updated UI
Former-commit-id: f78176a27f
* Add container to stack for lxdao mobymask-app
* Remove shm_size
* Use cerc-io scoped alias for lxdao app package
* Change alias to @cerc-io/mobymask-ui-lxdao
Former-commit-id: 46b36c3cb6
* Use standalone mobymask-v2-watcher-ts to run peer test
* Add watcher-ts image for running peer tests
* Run separate containers for peer ids generation and tests
* Wait for watcher to be up before starting peer-test-app
* Resolve peer-test-app compose file and remove setup-repositories for web-apps
Former-commit-id: c4002dcc5c
* Use mounted volumes for data in geth nodes
* Use mounted volumes for data in lighthouse nodes
* Avoid resetting genesis time in a lighthouse node on restart
* Mount parent datadir for lighthouse nodes
* Trap signals on shutdown and clean up in lighthouse nodes
* Allow stalled sync in lighthouse beacon nodes
* Gracefully shutdown geth nodes
* Add clean up instructions
* Gracefully shutdown lighthouse boot node
Former-commit-id: 3130af1615
* Build MobyMask web-app at container build step
* Fix web-app start script to use env variables in config
* Replace variables in built web-app files
* Use published mobymask-ui package from gitea
* Use published react-peer/test-app from gitea
* Remove local gitea publish TODO
Former-commit-id: cf79f0de0a
* Fix contract deployment script in fixturenet-optimism stack
* Configure relay node's announce domain from env
* Configure relay peers list for the relay node from env
* Create and use peer ids from a mounted volume
* Fix command to create watcher config
* Fix mobymask-app deployment script
Former-commit-id: 882f0b16aa
* Add an option to pass env file to deploy command
* Use env variable mapping in fixturenet-optimism stack
* Use default values from checked in env files
* Use env variable mapping in mobymask-v2 stack
* Update instructions
* Add extra hosts in app compose files and update instructions
* Add CERC prefix to env variables in fixturenet-optimism stack
* Add CERC prefix to env variables in mobymask-v2 stack
Former-commit-id: 6b62247ef7
* Separate out watcher and web-apps in mobymask stack
* Take L2 RPC endpoint from the env file
* Changes to run watcher and mobymask web-app separately
* Support running watcher without contract deployment and L2 txs
* Remove duplicate mobymask params env
* Add code comments
* Add instructions for running web-apps separately
* Self review fixes
* Fix timeout for mobymask-app on watcher server
---------
Co-authored-by: prathamesh0 <prathamesh.musale0@gmail.com>
Former-commit-id: 6f781ae303
* Set optimism geth endpoint from env file
* Set L1 account private keys from env
* Only deploy contract and generate invite in mobymask container
* Add readme for running mobymask v2 stack independently
* Modify mobymask container to stop running server and update readmes
* Check deployer account balance before deploying contract
* Fix for checking account balance before deploying
* Update readme description
* Update MobyMask repo tag in readme
Former-commit-id: 94e38ceaba
* Check existing L1 contracts deployment
* Rename volume used for generated L2 config
* Check for existing L2 geth data directory
* Cross check existing L2 config against L1 deployment config
* Verify sequencer key in existing L2 geth data directory
* Add instructions to troubleshoot corrupt L2 geth dir
* Separate out instructions to run L2 with external L1
* Update docs
Former-commit-id: 9ffa9bb5a9
* Remove unnecessary todos
* Set option to log commands in shell scripts
* Replace fixturenet-eth dependency with wait on endpoint
* Skip lighthouse node dependency check
* Update all services in the stack
* Use debug flag to enable shell commands logging
* Add bash in op-batcher container
* Update mobymask-v2 instructions
* Update fixturenet-optimism instructions
* Add descriptions for services
* Move ts files to container-build
* Take L1 RPC endpoint from the env file
* Add dev mode restriction for editing env file
Former-commit-id: 2515878eeb
* Remove laconicd to use optimism endpoint
* Use fixturenet-optimism stack for mobymask-v2-watcher
* Fix setting L1 account private key in mobymask-v2 stack
Former-commit-id: b266ac78b4
* Initial version
* Update readme
* Build op-geth container
* Add optimism go code containers
* Add optimism contracts container
* Update optimism contracts container build
* Add fixturenet-optimism-contracts service to deploy L1 contracts
* Add fixturenet-optimism op-node and op-geth
* Avoid reading addresses from a file when sending balances
* Fixes for running op-geth container
* Fix image name and command in optimism-contracts service
* Add a healthcheck to lighthouse bootnode to avoid failing eth txs
* Avoid using hardhat ethers to send balances from an account
* Update script to send balance to L1 bridge proxy contract
* Implement op-node container
* Wait for a finalized L1 block to exist
* Fix for running op-batcher
* Add a todo for restart support
* Integrate optimism-contracts service and update instructions
* Update clean-up to remove docker volumes
* Update volume access permissions
* Add a todo to replace foundry usage with web3 js
* Add known issues
* Fix README
* Fix indentation
* Update known issues
---------
Co-authored-by: David Boreham <david@bozemanpas.com>
Co-authored-by: David Boreham <david@bozemanpass.com>
Co-authored-by: nabarun <nabarun@deepstacksoft.com>
Former-commit-id: fc522140ba
* Rename .env file
* Add web app services to docker compose file
* Add laconicd to deploy contract and send txs
* Add demo with steps for running mobymask app with L2 chain
* Add fix for yarn install on M1 platform in react-peer
* Update multiaddrs to use websockets
* Add notes in readmes
---------
Co-authored-by: prathamesh0 <prathamesh.musale0@gmail.com>
Former-commit-id: cacd306b22
Stack Orchestrator allows building and deployment of a Laconic stack on a single machine with minimial prerequisites.
Stack Orchestrator allows building and deployment of a Laconic Stack on a single machine with minimial prerequisites. It is a Python3 CLI tool that runs on any OS with Python3 and Docker. The following diagram summarizes the relevant repositories in the Laconic Stack - and the relationship to Stack Orchestrator.

## Install
**To get started quickly** on a fresh Ubuntu instance (e.g, Digital Ocean); [try this script](./scripts/quick-install-linux.sh). **WARNING:** always review scripts prior to running them so that you know what is happening on your machine.
For any other installation, follow along below and **adapt these instructions based on the specifics of your system.**
## Setup
### Prerequisites
Stack Orchestrator is a Python3 CLI tool that runs on any OS with Python3 and Docker. Tested on: Ubuntu 20/22.
Ensure that the following are already installed:
1. Python3 (the stock Python3 version available in Ubuntu 20 and 22 is suitable)
```
$ python3 --version
Python 3.8.10
```
2. Docker (Install a current version from dockerco, don't use the version from any Linux distro)
```
$ docker --version
Docker version 20.10.17, build 100c701
```
3. If installed from regular package repository (not Docker Desktop), BE AWARE that the compose plugin may need to be installed, as well.
Note: if installing docker-compose via package manager on Linux (as opposed to Docker Desktop), you must [install the plugin](https://docs.docker.com/compose/install/linux/#install-the-plugin-manually), e.g. :
User mode runs the orchestrator from a "binary" single-file release and does not require special Python environment setup. Use this mode unless you plan to make changes to the orchestrator source code.
Now, having selected that directory, download the latest release from [this page](https://git.vdb.to/cerc-io/stack-orchestrator/tags) into it (we're using `~/bin` below for concreteness but edit to suit if you selected a different directory). Also be sure that the destination directory exists and is writable:
This creates a file `./laconic-so` that is executable outside of any venv, and on other machines and OSes and architectures, and requiring only the system Python3:
If Stack Orchestrator was installed using the process described above, it is able to subsequently self-update to the current latest version by running:
Laconic Stack Orchestrator
Options:
--quiet
--verbose
--dry-run
-h, --help Show this message and exit.
Commands:
build-containers build the set of containers required for a complete...
deploy-system deploy a stack
setup-repositories git clone the set of repositories required to build...
```
### CI Mode
_write-me_
```bash
laconic-so update
```
## Usage
There are three sub-commands: `setup-repositories`, `build-containers` and `deploy-system` that are generally run in order:
Note: $ laconic-so will run the version installed to ~/bin, while ./laconic-so can be invoked to run locally built
version in a checkout
### Setup Repositories
Clones the set of git repositories necessary to build a system.
The various [stacks](/stack_orchestrator/data/stacks) each contain instructions for running different stacks based on your use case. For example:
Note: the use of `ssh-agent` is recommended in order to avoid entering your ssh key passphrase for each repository.
```
$ laconic-so --verbose setup-repositories #this will default to ~/cerc or CERC_REPO_BASE_DIR from an env file
#$ ./laconic-so --verbose --local-stack setup-repositories #this will use cwd ../ as dev_root_path
```
### Build Containers
Builds the set of docker container images required to run a system. It takes around 10 minutes to build all the containers from cold.
```
$ laconic-so --verbose build-containers #this will default to ~/cerc or CERC_REPO_BASE_DIR from an env file
#$ ./laconic-so --verbose --local-stack build-containers #this will use cwd ../ as dev_root_path
Use `---include <list of components>` to deploy a subset of all containers:
```
$ laconic-so --verbose deploy-system --include db-sharding,contract,ipld-eth-server,go-ethereum-foundry up
```
```
$ laconic-so --verbose deploy-system --include db-sharding,contract,ipld-eth-server,go-ethereum-foundry down
```
Note: deploy-system command interacts with most recently built container images.
See the [CONTRIBUTING.md](/docs/CONTRIBUTING.md) for developer mode install.
## Platform Support
Native aarm64 is _not_ currently supported. x64 emulation on ARM64 macos should work (not yet tested).
## Implementation
The orchestrator's operation is driven by files shown below. `repository-list.txt` container the list of git repositories; `container-image-list.txt` contains
the list of container image names, while `clister-list.txt` specifies the set of compose components (corresponding to individual docker-compose-xxx.yml files which may in turn specify more than one container).
Files required to build each container image are stored under `./container-build/<container-name>`
Files required at deploy-time are stored under `./config/<component-name>`
Instructions to deploy a local ERC20 watcher stack (core + watcher) for demonstration and testing purposes using [laconic-stack-orchestrator](../../README.md#setup)
Instructions for deploying a local a geth + lighthouse blockchain "fixturenet" for development and testing purposes using laconic-stack-orchestrator (the installation of which is covered [here](https://github.com/cerc-io/stack-orchestrator#user-mode)):
Instructions for deploying a local Laconic blockchain "fixturenet" for development and testing purposes using laconic-stack-orchestrator (the installation of which is covered [here](https://github.com/cerc-io/stack-orchestrator#user-mode)):
The MobyMask watcher is a Laconic Network component that provides efficient access to MobyMask contract data from Ethereum, along with evidence allowing users to verify the correctness of that data. The watcher source code is available in [this repository](https://github.com/cerc-io/watcher-ts/tree/main/packages/mobymask-watcher) and a developer-oriented Docker Compose setup for the watcher can be found [here](https://github.com/cerc-io/mobymask-watcher). The watcher can be deployed automatically using the Laconic Stack Orchestrator tool as detailed below:
## Deploy the MobyMask Watcher
The instructions below show how to deploy a MobyMask watcher using laconic-stack-orchestrator (the installation of which is covered [here](https://github.com/cerc-io/stack-orchestrator#user-mode)).
This deployment expects that ipld-eth-server's endpoints are available on the local machine at http://ipld-eth-server.example.com:8083/graphql and http://ipld-eth-server.example.com:8082. More advanced configurations are supported by modifying the watcher's [config file](../../config/watcher-mobymask/mobymask-watcher.toml).
$ laconic-so deploy-system --include watcher-mobymask up
```
Correct operation should be verified by following the instructions [here](https://github.com/cerc-io/mobymask-watcher/tree/main/mainnet-watcher-only#run), checking GraphQL queries return valid results in the watcher's [playground](http://127.0.0.1:3001/graphql).
## Clean up
Stop all the services running in background:
```bash
$ laconic-so deploy-system --include watcher-mobymask down
This creates a file `./laconic-so` that is executable outside of any venv, and on other machines and OSes and architectures, and requiring only the system Python3:
3. Verify it works:
```
$ cp stack-orchetrator/laconic-so ~/bin
$ laconic-so
Usage: laconic-so [OPTIONS] COMMAND [ARGS]...
Laconic Stack Orchestrator
Options:
--stack TEXT specify a stack to build/deploy
--quiet
--verbose
--dry-run
--local-stack
--debug
--continue-on-error
-h, --help Show this message and exit.
Commands:
build-containers build the set of containers required for a complete...
build-npms build the set of npm packages required for a...
deploy deploy a stack
deploy-system deploy a stack
setup-repositories git clone the set of repositories required to build...
version print tool version
```
For cutting releases, use the [shiv build script](/scripts/build_shiv_package.sh).
Here you will find information about the design of stack orchestrator, contributing to it, and deploying services/applications that combine two or more "stacks".
Most "stacks" contain their own README which has plenty of information on deploying, but stacks can be combined in a variety of ways which are document here, for example:
- [Gitea with Laconicd Fixturenet](./gitea-with-laconicd-fixturenet.md)
- [Laconicd Registry with Console](./laconicd-with-console.md)
See [this PR](https://git.vdb.to/cerc-io/stack-orchestrator/pull/434) for an example of how to currently add a minimal stack to stack orchestrator. The [reth stack](https://git.vdb.to/cerc-io/stack-orchestrator/pull/435) is another good example.
For external developers, we recommend forking this repo and adding your stack directly to your fork. This initially requires running in "developer mode" as described [here](/docs/CONTRIBUTING.md). Check out the [Namada stack](https://github.com/vknowable/stack-orchestrator/blob/main/app/data/stacks/public-namada/digitalocean_quickstart.md) from Knowable to see how that is done.
Core to the feature completeness of stack orchestrator is to [decouple the tool functionality from payload](https://git.vdb.to/cerc-io/stack-orchestrator/issues/315) which will no longer require forking to add a stack.
## Example
- in `stack_orchestrator/data/stacks/my-new-stack/stack.yml` add:
```yaml
version:"0.1"
name:my-new-stack
repos:
- github.com/my-org/my-new-stack
containers:
- cerc/my-new-stack
pods:
- my-new-stack
```
- in `stack_orchestrator/data/container-build/cerc-my-new-stack/build.sh` add:
Deploy a local Gitea server, publish NPM packages to it, then use those packages to build a Laconicd fixturenet. Demonstrates several components of the Laconic stack
These commands can take awhile. Eventually, some instructions and a token will output. Set `CERC_NPM_AUTH_TOKEN`:
```bash
exportCERC_NPM_AUTH_TOKEN=<your-token>
```
### Configure the hostname gitea.local
How to do this depends on your operating system but usually involves editing a `hosts` file. For example, on Linux add this line to the file `/etc/hosts` (needs sudo):
```bash
127.0.0.1 gitea.local
```
Test with:
```bash
ping gitea.local
```
```bash
PING gitea.local (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1ttl=64time=0.147 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2ttl=64time=0.033 ms
```
Although not necessary in order to build and publish packages, you can now access the Gitea web interface at: [http://gitea.local:3000](http://gitea.local:3000) using these credentials: `gitea_admin/admin1234` (Note: please properly secure Gitea if public internet access is allowed).
Navigate to the Gitea console and switch to the `cerc-io` user then find the `Packages` tab to confirm that these two npm packages have been published:
The following tutorial explains the steps to run a laconicd fixturenet with CLI and web console that displays records in the registry. It is designed as an introduction to Stack Orchestrator and to showcase one component of the Laconic Stack. Prior to Stack Orchestrator, the following 4 repositories had to be cloned and setup manually:
- https://git.vdb.to/cerc-io/laconicd
- https://git.vdb.to/cerc-io/laconic-sdk
- https://git.vdb.to/cerc-io/laconic-registry-cli
- https://git.vdb.to/cerc-io/laconic-console
Now, with Stack Orchestrator, it is a few quick commands. Additionally, the `docker` and `docker compose` integration on the back-end allows the stack to easily persist, facilitating workflows.
## Setup laconic-so
To avoid hiccups on Mac M1/M2 and any local machine nuances that may affect the user experience, this tutorial is focused on using a fresh Digital Ocean (DO) droplet with similar specs:
16 GB Memory / 8 Intel vCPUs / 160 GB Disk.
1. Login to the droplet as root (either by SSH key or password set in the DO console)
```
ssh root@IP
```
2. Get the install script, give it executable permissions, and run it:
It's possible to run into an `ESOCKETTIMEDOUT` error, e.g., `error An unexpected error occurred: "https://registry.yarnpkg.com/@material-ui/icons/-/icons-4.11.3.tgz: ESOCKETTIMEDOUT"`. This may happen even if you have a great internet connection. In that case, re-run the `build-containers` command.
4. Set this environment variable to your droplet's IP address:
```
export LACONIC_HOSTED_ENDPOINT=http://<your-IP>
```
5. Deploy the stack:
```
laconic-so --stack fixturenet-laconic-loaded deploy up
3. Go back to the Digital Ocean web console and set an Inbound Rule for Custom TCP of the above port:
-`32778` in this example, but yours will be different.
- do the same for port `9473`
Additional ports will need to be opened depending on your application. Ensure you add your droplet to this new Firewall and wait a minute or so for the update to propagate.
4. Navigate to http://IP:port and ensure laconic-console is functioning as expected:
- ensure you are connected to `laconicd`; no error message should pop up;
- the wifi symbol in the bottom right should have a green check mark beside it
- navigate to the status tab; it should display similar/identical information
- navigate to the config tab, you'll see something like (with your IP):
```
wns
webui http://68.183.195.210:9473/console
server http://68.183.195.210:9473/api
```
## Publish and query a sample record to the registry
1. The following command will create a bond and publish a record:
Note: this page is out of date (but still useful) - it will no longer be useful once stacks are [decoupled from the tool functionality](https://git.vdb.to/cerc-io/stack-orchestrator/issues/315).
## Implementation
The orchestrator's operation is driven by files shown below.
-`repository-list.txt` contains the list of git repositories;
-`container-image-list.txt` contains the list of container image names
-`pod-list.txt` specifies the set of compose components (corresponding to individual docker-compose-xxx.yml files which may in turn specify more than one container).
-`container-build/` contains the files required to build each container image
-`config/` contains the files required at deploy time
It is possible to build and run Next.js webapps using the `build-webapp` and `run-webapp` subcommands.
To make it easier to build once and deploy into different environments and with different configuration,
compilation and static page generation are separated in the `build-webapp` and `run-webapp` steps.
This offers much more flexibilty than standard Next.js build methods, since any environment variables accessed
via `process.env`, whether for pages or for API, will have values drawn from their runtime deployment environment,
not their build environment.
## Building
Building usually requires no additional configuration. By default, the Next.js version specified in `package.json`
is used, and either `yarn` or `npm` will be used automatically depending on which lock files are present. These
can be overidden with the build arguments `CERC_NEXT_VERSION` and `CERC_BUILD_TOOL` respectively. For example: `--extra-build-args "--build-arg CERC_NEXT_VERSION=13.4.12"`
With `run-webapp` a new container will be launched on the local machine, with runtime configuration provided by `--env-file` (if specified) and published on an available port. Multiple instances can be launched with different configuration.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.