render_cdk 0.0.14

This crate provides a streamlined interface for interacting with Render, a platform that allows you to build, deploy, and scale your apps with ease.
Documentation

crates.io

Technical Documentation

Configuration

To configure the environment variables for use with render_cdk, you need to set the API_KEY and OWNER_CREDENTIALS environment variables. You can do this by creating a .env file in the root of your project with the following content:

API_KEY=rnd_xxxxXXXXxxxxXXXXxxxXX
OWNER_CREDENTIALS=<render>@<email>.com

Make sure to replace rnd_xxxxXXXXxxxxXXXXxxxXX with your actual Render API key.

Installation

Add render_cdk to your Cargo.toml:

[dependencies]
render_cdk = "0.0.14"
  • Alternatively, running at the cargo add render_cdk root of your project will also add render_cdk to your project.

Usage Examples

Here are basic examples of how to use the render_cdk crate to interact with Render Cloud:

1. Querying for Deployed Services

The following example demonstrates how to query deployed services base on specified criteria.

use render_cdk::environment_management::prelude::*;
use render_cdk::resource_management::prelude::*;
use tokio::main;

#[main]
async fn main() {
    let services = ServiceManager::list_all_services("10").await;
    let services = ServiceManager::find_service_by_name_and_type("my_api", "web_service").await;
    let services = ServiceManager::find_service_by_region("oregon", "10").await;
    let services = ServiceManager::find_service_by_environment("image", "10").await;

    // Process the services as needed...

    // Deleting services.
    ServiceManager::delete_service("my_api", "web_service").await;
}

2. Using Simple .conf Files for Resource Provisioning

  • .conf files offer a convenient alternative to programmatic resource provisioning, allowing you to define and manage resources through simple configuration settings.

Configuration File Example

The following is a sample configuration_ file. This will be used to provision a managed Postgres instance and a managed Redis instance.

  • [database] section specifies the configuration for a managed Postgres instance.

  • The name and user fields should be filled with the desired database name and user. enable_high_availability indicates whether high availability should be enabled. plan specifies the pricing plan for the instance, and version indicates the Postgres version.

# The following is a sample configuration file.
# This will be used to provision a
# managed postgres instance and managed redis instance.
[database]
databaseName = ""                   # Replace with the desired database name 
databaseUser = ""                   # Set to true to enable high availability
enableHighAvailability = false      # Pricing plan for the database instance
plan = "starter"
version = "12"                      # Postgres version
name = ""
# The following portion enables <public> access.
cidrBlocks = [
    { cidrBlock = "0.0.0.0/0", description = "Everywhere" }
    # { cidrBlock = "0.0.0.0/0", description = "Everywhere" },
    # { cidrBlock = "0.0.0.0/0", description = "Everywhere" }
    # Add more CIDR blocks here...
]

Note Blank fields will be autogenerated.

  • [redis] section specifies the configuration for a managed Redis instance. plan specifies the pricing plan for the instance.
[redis]
plan = "starter"              # Pricing plan for the Redis instance` 

Explanation

  • [database] Section:

    • name: The name of the Postgres database.

    • user: The user for the Postgres database.

    • enable_high_availability: Boolean value to enable or disable high availability for the database.

    • plan: The pricing plan for the Postgres instance. Options may include "starter", "standard", "premium", etc.

      Note free plan will result in failed deployments.

    • version: The version of Postgres to be used.

  • [redis] Section:

    • plan: The pricing plan for the Redis instance. Options may include "free", "standard", "premium", etc.

      Note free plan will result in failed deployments.

This configuration file allows you to easily set up managed database and caching services with specific plans and options suited to your project's needs.

use render_cdk::config::Conf;

fn main() {
    let config = Conf::read_configuration_file().unwrap();
    println!("Sample Configuration: {:?}\n", config);
}

3. Retrieve the Authorized User's Id

The Owner Id is used to tie the deployed resource to the Acting Service Principal/Render Account Owner.

use crate::authentication::owner::*;
use tokio::main;

#[main]
async fn main() {
    let owner_id = Info::get_owner_id().await;
}

4. Creating Services

The following examples shows how to deploy a static site.

use crate::authentication::owner::*;
use render_cdk::environment_management::prelude::*;
use render_cdk::resource_management::{self, models::prelude::*, prelude::*};
use tokio::main;

#[main]
async fn main() {
    let owner_id = Info::get_owner_id().await;

    let deployment_config = template::Template {
        type_: "static_site".to_owned(), // Options ->
        name: "test_deployment".to_owned(),
        owner_id,
        repo: "https://github.com/<username>/<repo_name>".to_owned(),
        auto_deploy: "yes".to_owned(), // By default, Render automatically deploys your service whenever you update its code or configuration.
        branch: None,
        image: None,
        build_filter: None,
        root_dir: "./public".to_owned(),
        env_vars: vec![],
        secret_files: vec![],
        service_details: Some(ServiceDetails {
            build_command: None, // Render runs this command to build your app before each deploy e.g npm run build, yarn build.
            headers: vec![],
            publish_path: Some("./".to_owned()), // This will translate to /public/
            pull_request_previews_enabled: Some("yes".to_owned()),
            routes: vec![],
        }),
    };

    let service = ServiceManager::create_service(deployment_config)
        .await
        .unwrap();
}