All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.Make a contribution
Package is a fundamental rapyuta.io resource that represents a declaration of your application. It is the smallest unit of deployment in rapyuta.io, and it can be deployed either on a device or the cloud or both.
Creating a software package consists of the following high-level procedures.
Step1: Define Package information
Step2: Create Components
To add the metadata of the package:
In the rapyuta.io console, on the left navigation bar, click Development > Packages.
In the Create New Package dialog, select the Package Information and enter:
|Package Name||Enter the package name.|
|Package Version||Enter the package version.|
|IS Singleton||Select this option if the package is not dependent on another package.|
|Is a bindable||Select this option if the package depends on another package or deployment of another package, the package bindings link the package to its dependencies.|
|Description||Enter a brief description about the package.|
A component is a set of executables. All executables are deployed simultaneously on the desired Component Runtime. All executables of a component communicate via Inter-Process Communication (IPC). An executable listening on a port is accessible to its sibling executables via localhost.
To create components:
In the Create New Package dialog, select Components.
Under Component Metadata, enter:
|Component Name||Enter the component name.|
|Component Runtime||Select the component runtime as either Device or Cloud. For more information, see Understand Runtime.|
|IS ROS Component||Select this option if the component is to be deployed on a ROS-enabled device.|
|Replicas to run the component||Enter the number of replication of the component that you want to include.|
|Executable Name||Enter the executable name.|
|Executable Type||Select the executable type as either Builds or Docker. For more information, see Core Concepts.|
|Command to run in the docker container||Enter the command to run the executables.|
|Choose Build (applicable only for type Build)||Select the build from the dropdown list.|
|Docker image (applicable only for type Docker)||Enter the docker image to be used. For more information, see Creating a Build.|
|Private Image (applicable only for type Docker)||Select this option if the docker image is private and also select the credentials from the Credentials dropdown list.|
|Run command from bash shell (applicable only for type Docker)||Command to run in the docker container.|
|Simulation||Enable simulation if your ros application is publishing at higher frequencies.|
|Cloud Resource Limit||Select the CPU and memory requirement for the executable from the dropdown list. You can also choose or enter the custom resource limits for the component executables. For example, 1.025 vCPU and 2.5 GiB Memory.
|Device Resource Limit (optional)||Users now have the option to apply CPU and memory limits for devices using the following command in the CLI:
For example, rio apply riocli/apply/manifests/package-nonros-device.yaml.
Max Executable CPU is 256 cores
|Endpoint Name||Enter the endpoint name.|
|Exposed externally||Enable if the endpoint is exposed publicly and select one of the available protocols:
|Port||Enter the port number for the endpoint. Port is where the application’s service is made visible to other services.|
|Target Port||Enter the target port. The target port is where the application needs to be listening for network requests for the service to work.
The Secure TCP (TLS/SNI) protocol uses SNI headers for routing the request to the desired backend.
|Port Range||Enable this option to open multiple ports on a single DNS hostname.
A maximum of 50 ports is allowed for an endpoint. The allowed format is comma-separated Port Ranges. Each Port Range is either a single port or a range of port mentioning the from port and to port separated by a hyphen (-). Examples: 5000 or 443-445 or 3446-3449,3500,3510-3530
For more information, see Exposing Endpoints Externally.
|Name||Enter the ROS topic name.|
|Compressed||Compression to use for the topic messages.|
|Scoped||A scoped topic is a mapping from a /topic to /robot-peer-name/topic.|
|Targeted||A targeted topic is a mapping from /robot-alias/topic to /topic.|
|QoS||Select one of the available QoS types to ensure reliability of the ROS topics in the transport layer even over the public internet.|
|Name||Enter the ROS service name.|
|Timeout||Enter the timeout in seconds.|
(Optional) To add a ROS actions to the package. Under ROS Actions, click Add ROS action and enter the ROS service name.
(Optional) To add a ROS bag job to the package. Under Record ROS Bag Job, click Add ROS action. For more information on the fields, see Working with Rosbags
(Optional) Configuration parameters operate at the level of the component and apply to executables in the component only. To add configuration parameter to the executable, click Add Parameter and enter:
|Name||Enter the parameter name.|
|Default value||Default value of the parameter.|
|Description||Description of the parameter.|
|This parameter is exposed externally||Select this option if this parameter is publicly exposed.|
rapyuta.io allows you to configure the following additional information for the package.
Volumes: Applications running on the cloud de-allocate any resources consumed when they stop, scale down, or fail. This implies that the working storage associated with them is ephemeral. To get around this problem, rapyuta.io provides a mechanism to consume persistent block storage for your applications running in the cloud. This storage can be associated with at most one running deployment at any given point of time. A user is typically required to manage the lifecycle of the application code independently from the associated storage.
The Rapyuta IO Persistent Volume is a storage package. A storage package is a public package that is available to all users out of the box. You cannot delete or modify storage packages, and they are available to every user.
Dependent Deployment: If your package has a dependency on a deployment, you must define the dependent deployment.
Inbound ROS interface: While having provider semantics provides flexibility but can potentially lead to a case where a user may deploy the package that depends on a previously deployed one without sufficient knowledge of the internal workings of the parent package. Cross talk between topics/services/actions in such cases can cause unintended hard to debug errors and failure of application code.
To prevent such unintentional cross-communication between deployments of two packages, rapyuta.io requires the package to declare a whitelist of ROS inbound topics/services/interfaces it can receive from a child dependent on it.
To add additional information to the package.
Click Additional Information.
To add a volume to the package, click the refresh icon next to the Volume field and do the following. Before adding a volume package, ensure that you have created a volume package. Under Deployment, select the volume deployment that you created.
To add a dependent deployment, click the refresh icon next to the Dependent Deployment field and select the dependent deployment.
Click Confirm Package Creation.