A tool to hide the complexity of the cloud.

curl -LsSf https://repo.opencloudtool.com/install.sh | sh

or

wget -qO- https://repo.opencloudtool.com/install.sh | sh

pip install opencloudtool

See the Python library README for details: crates/oct-py/README.md

Basic login (docs):

aws configure

Using AWS SSO (docs):

aws configure sso

• Multiple REST services on the same host with NGINX load balancer
• Multiple REST services on different hosts with NGINX load balancer
• S3 remote state storage
• REST service with domain
• Single host multi services with domains
• Ray single worker
• Inject system env variables
• HTTP server with single dockerfile
• HTTP server with multiple dockerfiles
• Dedicated CS2 server
• FastAPI app via python library

• Base - base cloud resources (networking, VMs, IAM, etc.).
• oct-ctl:
  • Consensus - Raft-based consensus mechanism to maintain a distributed state of the infrastructure.
  • Management - management operations to control the infrastructure resources and user services.
  • Service Discovery - DNS service to let the service communicate using domain name and hide the exact IPs.
• Workload - user services deployed along with proxy sidecars to implement service mesh approach.

• Genesis - step to setup the initial infrastructure to deploy a leader node that'll control everything.
• Life - the main period of infrastructure lifecycle where the leader is already deployed and all main operations with infrastructure and user services happen.
• Afterlife - the final step of the whole infrastructure destruction.

Node can play the following roles:

• Leader - the main node that controls all infrastructure components (follower nodes and underlying infrastructure for them), the user services on the node itself and sends commands to the follower nodes to CRUD user services.
• Follower - the node type that accepts commands from the leader to CRUD user services. The follower node can become a leader if the current leader is not available anymore, according to the Raft consensus algorithm.

The diagrams try to follow C4Model notation at component level.

In the current implementation Infra Graph is hard-coded. It'll be updated to be adaptive to the User Services Graph at L2.

Shows the current state of the graph from crates/oct-cloud/src/infra.

The diagram can be moved to the infra-specific folder later, keeping it here for now to have all the design documents in one place.

pre-commit install

 cargo build

 cd dir/with/oct.toml
 cargo run -p oct-cli deploy

 cargo run -p oct-cli destroy

 cargo run -p oct-cli --help

 cargo run -p oct-cli command --help

For example:

 cargo run -p oct-cli deploy --help

To run all Rust unit and integration tests:

cargo test --workspace

To run E2E tests for the platform:

# 1. Pre-build the platform
cargo build -p oct-platform

# 2. Run E2E tests (requires Deno)
cd crates/oct-platform/e2e
deno task test

Main principles:

• Each module provides its own mocks in a public mocks module.
• Each module's tests cover only the functionality in that module.
• If a module uses external modules, they are mocked using the mocks provided by the imported module.
• In tests, prefer expect("message") over unwrap() to provide context on failure.
• When testing for specific error messages, use unwrap_err() and assert on the error.

Example structure:

...main code...

pub mod mocks {
    ...mocks...
}

#[cfg(test)]
mod tests {
    ...tests...
}

Example mocking:

...other imports...

#[cfg(test)]
use module::mocks::MockModule as Module;
#[cfg(not(test))]
use module::Module;

...main code...

When importing modules, the following order should be used:

• Standard library imports
• Third-party imports
• Local crate imports

use std::fs;

use serde::{Deserialize, Serialize};

use crate::aws::types::InstanceType;

Removes unused dependencies

cargo install cargo-machete
cargo machete

Removes unused features

cargo install cargo-features-manager
cargo features prune

Produces HTML file with building time report. Can be found in target/cargo-timings.html

cargo build -p PACKAGE_NAME --release --timings

This section compares the cost of running a set of services in a cloud with different approaches which do not require the end user to manage underlying infrastructure (serverless).

Note that OpenCloudTool is a free to use open-source tool and there is no charge for using it.

Main components:

• Django REST service (0.5 vCPU, 1GB RAM)
• Celery worker (0.5 vCPU, 1GB RAM)
• Redis (0.5 vCPU, 1GB RAM)
• Postgres (0.5 vCPU, 1GB RAM)
• Load Balancer (nginx, ELB, etc.)

• 2 vCPU (1 vCPU per hour - $0.04048) - $61.5 per month
• 4 GB RAM (1 GB RAM per hour - $0.004445) - $13.5 per month
• Load Balancer ($0.0225 per hour) - $17 per month

Total: $92 per month

• 1 EC2 t4g.medium instance ($0.0336 per hour): $25.5 per month

Total: $25.5 per month