StreamNative CLI Tutorial
This tutorial demonstrates how to use the StreamNative command-line tools to deploy a Serverless cluster and manage Pulsar resources within it. We will primarily focus on the modern, unified approach using StreamNative Cloud CLI (snctl
) for both cloud infrastructure and Pulsar resource management/interaction. We will also show alternative methods using the traditional pulsarctl
and pulsar-client
tools.
This tutorial covers:
- Provisioning a Serverless Instance (
snctl
). - Provisioning a Serverless Cluster (
snctl
). - Provisioning an Application Service Account (
snctl
). - Creating an API Key for the Service Account (
snctl
). - Method 1 (Unified
snctl
):- Configuring
snctl
Service Context. - Creating Pulsar resources (tenant, namespace, topic) using
snctl pulsar admin
. - Granting permissions using
snctl pulsar admin
. - Producing/Consuming messages using
snctl pulsar client
.
- Configuring
- Method 2 (Traditional Tools - Alternatives):
- Configuring
pulsarctl
context using the API Key. - Creating Pulsar resources using
pulsarctl
. - Granting permissions using
pulsarctl
. - Producing/Consuming messages using
pulsar-client
configured with the API Key.
- Configuring
0. Prerequisites
Install Required CLIs
Make sure you have the following installed:
- snctl (v1.0.0+ recommended)
- pulsarctl (Needed for the alternative method)
- An Apache Pulsar distribution (e.g., from Pulsar Downloads) for the
pulsar-client
alternative method.
Create a new directory for the tutorial
Create a new directory for the tutorial.
Create and Activate a Super-Admin Service Account
You need to create a service account with Super Admin access in StreamNative Cloud Console. Let’s name it snctl-super-admin
. After creating the service account, download and save its OAuth2 credentials file (e.g., snctl-super-admin-credentials.json
).
Activate this service account for snctl
. This identity will be used for provisioning cloud resources (instances, clusters, other service accounts). Make sure to replace /path/to/snctl-super-admin-credentials.json
with the actual path.
After the service account is activated, you should see a similar message:
Set the target organization as the default organization for snctl
to avoid specifying -n
or -O
repeatedly. Replace <your-org-id>
with your actual organization ID.
1. Provision a Serverless Instance
Edit a file named 001-instance.yaml
with the following content:
This yaml file defines a Serverless Instance running in GCP with regional availability mode. Replace the following placeholders with your actual values:
<your-instance-name>
: The name of the Serverless Instance.<your-org-id>
: The organization ID.
Run the following command to provision the Serverless Instance:
You should see the following message:
Query the instance to verify the instance is created.
You will be able to see a similar status block of this instance in the output:
When all the conditions are True
, the instance is ready.
2. Provision a Serverless Cluster
Edit a file named 002-cluster.yaml
with the following content:
This yaml file defines a Serverless Cluster in us-central1
region. Replace the following placeholders with your actual values:
<your-instance-name>
: The name of the Serverless Instance.<your-org-id>
: The organization ID.
Run the following command to provision the Serverless Instance:
You should see the following message:
Please note the <your-cluster-name>
in the output message because the cluster name of a Serverless Cluster is generated by StreamNative Cloud. You will need this cluster name in the future steps.
Query the cluster to verify the cluster is created.
You will be able to see a similar status block of this cluster in the output:
Wait for all the conditions to be True
, then the cluster is ready. A Serverless Cluster is usually ready within 1~2 minutes.
3. Provision a Service Account
Edit a file named 003-sa.yaml
with the following content:
This yaml file defines a Service Account with a name <your-service-account-name>
. Replace the following placeholders with your actual values:
<your-service-account-name>
: The name of the Service Account.<your-org-id>
: The organization ID.
Run the following command to provision the Service Account:
You should see the following message:
Query the service account to verify the service account is created.
You will be able to see a similar status block of this service account in the output:
Wait until the Ready
condition is True
, then the service account is ready.
4. Create an API Key for the Service Account (Optional but shown for completeness)
While snctl
typically uses OAuth2 via auth activate-service-account
or context impersonation (--as-service-account
), you might need an API Key for external clients or tools that only support token authentication. This API key will be used in the alternative pulsarctl
and pulsar-client
method later.
Edit a file named 004-api-key.yaml
:
This yaml file defines an API Key for the Service Account <your-service-account-name>
. Replace the following placeholders with your actual values:
<your-api-key-name>
: The name of the API Key.<your-service-account-name>
: The name of the Service Account.<your-instance-name>
: The name of the Serverless Instance.<your-org-id>
: The organization ID.
Run the following command to create the API Key:
You should see the following message:
Query the API Key to verify the API Key is created and optionally retrieve the token.
You will be able to see a similar status block of this API Key in the output:
Wait until the Issued
condition is True
, then the API Key is issued and ready to use. You can obtain the token from the token
field in the status block.
You can use the following command to obtain the token and export it as an environment variable API_KEY_TOKEN
:
Method 1: Unified Management with snctl
This section demonstrates using snctl
for configuring access, managing Pulsar resources, and interacting with the data plane.
5. Configure snctl
Service Context for Pulsar Interaction
snctl
uses Service Contexts to manage connections to Pulsar/Kafka clusters. After creating a cluster, snctl
usually discovers it automatically. Let’s explicitly set the context for the cluster we created to ensure subsequent commands target it correctly.
Set the active context to your newly created cluster. Replace <your-instance-name>
and <your-cluster-name>
with the actual name from step 2.
Verify the current context:
Now, verify connectivity by listing tenants. Since we activated the snctl-super-admin
service account (in step 0), snctl
commands will run as that identity by default.
You should see the default tenants:
This confirms snctl
can communicate with the Pulsar cluster’s admin endpoint using the super-admin credentials via the active context.
6. Create Pulsar Resources using snctl
Now, let’s create the tenant, namespace, and topic for our application sl-app
using snctl pulsar admin
commands. These commands will use the active context (<your-cluster-name>
) and run as the activated super-admin user (snctl-super-admin
).
First, create a tenant named sl-app-tenant
.
Output:
Second, create a namespace named sl-app-ns
under the tenant sl-app-tenant
.
Output:
Next, create a partitioned topic named sl-app-topic
with 4 partitions under the namespace sl-app-tenant/sl-app-ns
.
Output:
Finally, grant the application Service Account <your-service-account-name>
(created in step 3) the permission to produce and consume messages within the sl-app-tenant/sl-app-ns
namespace. We are still running as snctl-super-admin
to grant these permissions. Replace <your-service-account-name>
with the name from step 3.
Output:
7. Produce and consume messages using snctl pulsar client
Now we’ll use snctl pulsar client
commands to produce and consume messages. Crucially, these actions should be performed as the application service account (<your-service-account-name>
) because we granted it the produce/consume permissions, not the super-admin. We use the --as-service-account
flag for this, leveraging snctl
’s ability to impersonate the specified service account (assuming the logged-in super-admin has permission to do so, which is typical).
Produce 10 messages to the topic, acting as the application service account. Replace <your-service-account-name>
with the name from step 3.
You should see output indicating successful production, similar to:
(Exact output message may vary)
Consume the 10 messages from the topic, again acting as the application service account. Replace <your-service-account-name>
with the name from step 3.
You should see the 10 messages printed to your console, similar to:
Followed by a confirmation like:
(Exact output format may vary)
This demonstrates using snctl
for the entire lifecycle using the unified approach.
sidebarTitle: Tutorial
Method 2: Traditional Management with pulsarctl
and pulsar-client
(Alternative)
This section demonstrates the alternative approach using the separate pulsarctl
tool for admin tasks and the pulsar-client
tool for producing/consuming. This method often relies on API Key authentication for simplicity when interacting with StreamNative Cloud clusters via these tools.
Alt 5. Configure pulsarctl
Context (Using API Key)
First, get the admin service URL of the cluster by running the following command:
Once you get the ADMIN_SERVICE_URL
, you can use the following command to configure pulsarctl
to access the cluster we created in the previous steps:
This command will create a new context named <your-cluster-name>-admin
and update the pulsarctl
configuration to use the oauth2 credentials of snctl-super-admin
to authenticate to the cluster.
You should see the following message:
You can verify the pulsarctl
has been configured properly by running the following command:
You should see the following message:
Then you can run pulsarctl tenants list
to verify if you configured the pulsarctl
properly.
You should be able to see the tenants in the cluster.
Alt 6. Create Pulsar Resources using pulsarctl
Assume you want to build a sample application sl-app
that produces messages to a topic persistent://sl-app-tenant/sl-app-ns/sl-app-topic
and consumes messages from the same topic.
First, create a tenant named sl-app-tenant
.
Output:
Second, create a namespace named sl-app-ns
under the tenant sl-app-tenant
.
Output:
Next, create a topic named sl-app-topic
with 4 partitions under the namespace sl-app-tenant/sl-app-ns
.
Output:
Finally, grant the Service Account <your-service-account-name>
the permission to produce and consume messages from the namespace sl-app-tenant/sl-app-ns
.
Output:
Alt 7. Produce and consume messages using pulsar-client
-
Download the Pulsar distribution from Pulsar Downloads. Assume you have downloaded the Pulsar distribution and extracted the tarball to
/path/to/pulsar-dist
. -
Enter the root directory of the Pulsar distribution:
-
Configure the
conf/client.conf
file:- webServiceUrl: Set the
webServiceUrl
to theADMIN_SERVICE_URL
you obtained in the previous steps. - brokerServiceUrl: Set the
brokerServiceUrl
to theBROKER_SERVICE_URL
you obtained in the previous steps. - authPlugin: Set the
authPlugin
toorg.apache.pulsar.client.impl.auth.AuthenticationToken
. - authParams: Set the
authParams
to betoken:<your-api-key>
.<your-api-key>
is the API Key you obtained in the previous steps.
- webServiceUrl: Set the
-
Produce 10 messages.
You should see a similar message in the output:
-
Consume the messages.
You should see a similar message in the output:
You should see a final message in the output:
8. Next Steps
Once you have verified the application works as expected using either method, you can try out more guided tutorials:
- Kafka Client Guides
- Pulsar Client Guides
- Run Pulsar I/O Connectors
- Run Kafka Connect Connectors
- Deploy Pulsar Functions
9. Clean up
After you finish the tutorial, you can clean up the resources you created in this tutorial by running the following command:
Please note that you can’t use snctl delete -f 002-cluster.yaml
to delete the cluster because the cluster name is generated by StreamNative Cloud. So you need to delete the cluster using the snctl delete PulsarCluster <your-cluster-name>
command.