Rust

FlashDrive automatically build your Rust apps created from the platform.

In order to do that FlashDrive uses buildpacks to detect and build automatically your app.

FlashDrive requires several files to be placed inside the root directory of your app to be able to build it :

  • a Procfile with the command that should be executed to run your app.
  • a Cargo.toml file
  • a Cargo.lock file

You can fork or build this repository to see how the app creation process works.

Cargo Configuration

The Cargo configuration can be altered using Environment variables added directly to your app :

Environment VariableDescription
$BP_CARGO_INSTALL_ARGSAdditional arguments for cargo install. By default, the buildpack will run cargo install --color=never --root=<destination layer> --path=<path-to-member> for each workspace member.
$BP_CARGO_WORKSPACE_MEMBERSA comma delimited list of the workspace package names (this is the package name in the member’s Cargo.toml, not what is in the workspace’s Cargo.toml‘s member list) to install. If the project is not using workspaces, this is not used. By default, for projects with a workspace, the buildpack will build all members in a workspace. See more details below.

BP_CARGO_INSTALL_ARGS

Additional arguments for cargo install. Any additional arguments specified, are specified for each invocation of cargo install. The buildpack will execute cargo install once for each workspace member. If you’re not using a workspace, then it executes a single time.

A few examples of what you can specify:

  • --path=./todo to build a single member in a folder called ./todo if you have a non-traditional folder structure
  • --bins to build all binaries in your project
  • --bin=foo to specifically build the foo binary when multiple binaries are present
  • -v to get more verbose output from cargo install
  • --frozen or --locked or customizing how Cargo will use the Cargo.lock file
  • --offline for preventing Cargo from trying to access the Internet
  • or any other valid arguments that can be passed to cargo install

You may not set --color and you may not set --root. These are fixed by the buildpack in order to make output look correct and to ensure that binaries are installed into the proper location.

BP_CARGO_WORKSPACE_MEMBERS

This option may be used in conjunction with BP_CARGO_INSTALL_ARGS, however you may not set --path in BP_CARGO_INSTALL_ARGS when also setting BP_CARGO_WORKSPACE_MEMBERS, as the buildpack will control --path when building workspace members.

In summary:

  • Use BP_CARGO_INSTALL_ARGS and --path to build one specific member of a workspace.
  • Use BP_CARGO_INSTALL_ARGS to specify non---path arguments to cargo install
  • Use BP_CARGO_WORKSPACE_MEMBERS to specify one or more workspace members to build (using BP_CARGO_WORKSPACE_MEMBERS with only one member has identical behavior to BP_CARGO_INSTALL_ARGS and --path)
  • Don’t set either BP_CARGO_INSTALL_ARGS and --path, or BP_CARGO_WORKSPACE_MEMBERS and the buildpack will iterate through and build all of the members in workspace.

Rustup

Rustup is enabled by default

$BP_RUSTUP_ENABLED environment variable must be true (see below)

The buildpack will do the following:

  • Contributes rustup-init to a layer marked cache with command on $PATH
  • Executes rustup-init with the output written to a layer marked build and cache with installed commands on $PATH
  • Executes rustup to install a Rust toolchain to a layer marked build and cache with installed commands on $PATH
Environment VariableDescription
$BP_RUSTUP_ENABLEDConfigure rustup to be enabled. This means that rustup will be used to install Rust. Default value is true. Set to false to use another Rust toolchain provider like rust-dist (see below).
$BP_RUST_TOOLCHAINRust toolchain to install. Default stable. Other common values: betanightly or a specific versin number. Any acceptable value for a toolchain can be used here.
$BP_RUST_PROFILERust profile to install. Default minimum. Other acceptable values: defaultcomplete. See Rustup docs for profile.
$BP_RUSTUP_INIT_VERSIONConfigure the version of rustup-init to install. It can be a specific version or a wildcard like 1.*. It defaults to the latest 1.* version.
$BP_RUSTUP_INIT_LIBCConfigure the libc implementation used by the installed toolchain. Available options: gnu or musl. Defaults to gnu for compatiblity.

Using Rust-dist instead of Rustup

The Rust Dist Cloud Native Buildpack provides a Rust toolchain from a zip archive distribution.

The buildpack installs the Rust toolchain onto the $PATH which makes it available for the builder to use.

Configuration

Set the below environment variable to use Rust-dist :

Environment VariableDescription
$BP_RUST_VERSIONAs a user of the buildpack, you may specify which version of Rust gets installed by setting this environment variable at build time. The version you specify must exist in the buildpack.toml file or you will get an error.

Bindings

The rust-dist buildpack optionally accepts the following bindings:

Type: dependency-mapping

KeyValueDescription
<dependency-digest><uri>If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Procfile

A default Procfile uses only the web argument :

web: ROCKET_PORT=$PORT ROCKET_KEEP_ALIVE=0 /workspace/bin/<project>

To uses more than one argument, just add more lines to Procfile.

One of the lines needs to be named web, which is the expected name for the default process.

Do not use cargo start inside your Procfile, instead direct the web argument to your binaries folder.

Default Behavior

/workspace is where your application files live.

Apps are compiled into a binary, the builder doesn’t propagate the application source into the final container.

That leaves you with /workspace/bin/<your-binaries> as a folder structure. This is the path that must be used inside the Procfile

Debug and Access Logs

The log page inside your App settings only provides limited logs and is erased after each app reboot or rebuild.

Visit this page to learn how to make logs persistent for NodeJS and access them at any time from your browser.

Create persistent storage

One of the major improvements of FlashDrive in comparison to others app hosting solutions is the ability to create Virtual Disks available for any copy of your app inside the same stack.

Virtual disks allow you to store data safely and securely, without the need to use an additional S3 bucket, and every app size gets free disk space depending on its size (see our pricing for more information).

In addition to that, Virtual disks are backup every day with 10 days history and ransomware protection at no additional cost.

Read this article for more information about virtual disks and how to add one to your app.

Define environment variables

Note: Environment variables set in your app settings are injected during the build process. If the build of your app needs to use an env variable make sure to set it before requesting the build.

FlashDrive lets you externalize the configuration of your app : the FlashDrive cluster will automatically injects the data when the app start or restart.

Environment variables can include any external data your app needs to run like external resources, databases addresses, encryption keys, etc…

To add an environment variable, access your app settings and click “Add ENV Variable” :

Enter the key (like DATABASE_USER) and the value and click “Add”. FlashDrive will automatically add your environment variable and restart your app after a one-minute delay (to let you add more env variables if necessary without restarting the app each time a new variable is added).

Add a domain name

Please check this article for a detailed method on how to use your domain name with FlashDrive apps.

Provision a database

FlashDrive Marketplace includes all popular datastore engines including Mysql, Postgres, MongoDB, and Redis.
To add a database to your app, click on Marketplace and select the database you want to run, then create the new app database inside the same stack as your Node.JS app.

Once the app is running, visit the database app’s settings and retreive the “internal name” :

Use this internal name as you would use a server address, for instance for MySQL this name replaces the usual “localhost”. Some scripts require you to add the database port at the end of the server address. FlashDrive uses a common port for each database software, for MySQL it will be 3306 and you can write it like that inside your scripts: internal-name:3306
Postgres usually uses credentials sent inside the login URL, like that : postgres://<user>:<password>@<internalname>:5432/<database>

The login and password information is available inside the Environment Variables of the database app.

Reach your app from another app

Inside your app stack, you can reach any other FlashDrive app member of this stack on any port. FlashDrive automatically routes the traffic internally and opens the appropriate port. By opposition, your app is only reachable on ports 80/443 from outside of FlashDrive.

To reach your app internally, retrieve the internal name from your app settings page :

This name can be used to reach your app from another app inside the same stack. Use it in any form that works with your script :

http://<internalname>
<internalname>
http://internalname>:port

Note: https:// is not available, all the traffic inside apps is already encrypted by the cluster.

Encryption

FlashDrive uses at rest encryption for the app virtual disks, build images, and encrypted transport from inside the cluster. To make sure the traffic is encrypted between your app and the browser of your users you can set up SSL certificates for any domain name connected to the app (including the FlashDrive’s default domain name).

Scale your App

From your app settings you can scale your app vertically and horizontally: by upgrading the app size (refer to our pricing for app sizes details) or by adding more nodes.

Additional nodes will run another copy of your app inside another FlashDrive server located inside the same cluster (same geographical location). Traffic is automatically sent to the least occupied node by FlashDrive’s load balancer.

Note: Apps that use Virtual Disks will share the same file structure and read/write on the same disk. It’s fine in most cases for intensive read activity but can create bottlenecks and corrupted data if several nodes of the same app write on the same file at the same time. If your apps use intensive reads on virtual disks consider upgrading the app size instead of adding more nodes.

Was this helpful?

0 / 0