JCloud#

https://docs.jina.ai/_images/jcloud-banner.png
../../_images/jcloud-banner.png

After building a Jina project, the next step is to deploy and host it on Cloud. JCloud simplifies deploying and hosting your Jina projects on Jina Cloud. It provides a simple CLI with five commands to manage the lifecycle of your Jina projects.

Tip

At this point, Jina Cloud hosts all your Jina projects and offers computational/storage resources for free!

Basic#

Jina Cloud provides a CLI and you can use it simply via jina cloud from the terminal, or jcloud or simply jc for minimalists.

Hint

You can also only install Jina Cloud CLI without install jina package.

pip install jcloud
jc -h

If you installed it individually, all of its commands come under the jc or jcloud executable.

In case jc is already occupied by another tool, please use jcloud instead. If your pip install doesn’t register bash commands for you, you can run python -m jcloud -h.

For the rest of this section, we will be using jc or jcloud. But again they are interchangable to jina cloud.

Login#

jc login

You can use a Google/GitHub account to register and login. For all the next steps, logging in is mandatory.

If you have no access to the web browser in your integration environment, you can set the Environment Variable JINA_AUTH_TOKEN using auth token before working with JCloud. Auth token can be generated by user login or Personal Access Token (PAT) creation, please visit jina-auth for more information (jc includes jina-auth already).

Deploy#

In Jina’s idiom, a project is a Flow, which represents an end-to-end task such as indexing, searching or recommending. In this README, we will use “project” and “Flow” interchangeably.

Caution

Flows have a maximal lifetime after which they are automatically deleted.

A Flow can have two types of file structure: a single YAML file or a project folder.

A single YAML file#

A self-contained YAML file, consisting of all configs at the Flow-level and Executor-level.

All Executors’ uses must follow the format jinahub+docker://MyExecutor (from Jina Hub) to avoid any local file dependencies.

e.g.-

# flow.yml
jtype: Flow
executors:
  - name: sentencizer
    uses: jinahub+docker://Sentencizer

To deploy,

jc deploy flow.yml

Tip

Testing locally before deploying is recommended. You can use

jina flow --uses flow.yml

A project folder#

Tip

The best practice of creating a JCloud project is to use

jc new

This ensures the correct project structure accepted by JCloud.

Just like a regular Python project, you can have sub-folders of Executor implementations; and a flow.yml on the top-level to connect all Executors together.

You can create an example local project using jc new hello. The default structure looks like:

hello/
├── .env
├── executor1
│   ├── config.yml
│   ├── executor.py
│   └── requirements.txt
└── flow.yml

where,

  • hello/ is your top-level project folder.

  • executor1 directory has all Executor related code/config. You can read the best practices for file structures. Multiple such Executor directories can be created.

  • flow.yml Your Flow YAML.

  • .env All environment variables used during deployment.

To deploy,

jc deploy hello

The Flow is successfully deployed when you see:

../../_images/deploy.png

You will get a Flow ID, say 173503c192. This ID is required to manage, view logs and remove the Flow.

As this Flow is deployed with default gRPC gateway (feel free to change it to http or websocket), you can use jina.Client to access it:

from jina import Client, Document

c = Client(host='https://173503c192.wolf.jina.ai')
print(c.post('/', Document(text='hello')))

View logs#

To watch the logs in realtime:

jc logs 173503c192

You can also stream logs for a particular Executor by passing its name:

jc logs 173503c192 --executor sentencizer

Remove Flows#

You can either remove a single Flow, multiple selected Flows or even all Flows by passing different kind of identifiers.

To remove a single Flow:

jc remove 173503c192

To remove multiple selected Flows:

jc remove 173503c192 887f6313e5 ddb8a2c4ef

To remove all Flows:

jc remove all

By default, removing multiple selected / all Flows would be in interactive mode where confirmation will be sent prior to the deletion, to make it non-interactive to better suit your use case, set below environment variable before running the command:

export JCLOUD_NO_INTERACTIVE=1

Get status#

To get the status of a Flow:

jc status 15937a10bd
../../_images/status.png

Monitoring#

Basic monitoring is provided to the Flows deployed on JCloud.

To access the Grafana powered dashboard, get the status of the Flow first, at the bottom of the pane you should see the dashboards link. Visit the URL and you will find some basic metrics such as ‘Number of Request Gateway Received’ and ‘Time elapsed between receiving a request and sending back the response’:

../../_images/monitoring.png

List Flows#

To list all the Flows you have:

jc list

You can see the ALIVE Flows deployed by you.

../../_images/list.png

You can also filter your Flows by passing a status:

jc list --status FAILED
../../_images/list_failed.png

Or see all the flows:

jc list --status ALL
../../_images/list_all.png

Pass environment variables#

A single YAML#

jc deploy flow.yml --env-file flow.env

A project folder#

  • You can include your environment variables in the .env file in the local project and JCloud will take care of managing them.

  • You can optionally pass a custom.env.

    jc deploy ./hello --env-file ./hello/custom.env
    

Troubleshooting#

If your deployment failed, please enable verbose logging and redeploy it. You can add --loglevel DEBUG before each CLI subcommand, e.g.

jc --loglevel DEBUG deploy flow.yml

Alternatively, you can configure it by using environment variable JCLOUD_LOGLEVEL, e.g.

JCLOUD_LOGLEVEL=DEBUG jc deploy flow.yml

If you don’t see any obvious errors, please raise an issue in JCloud

Restrictions#

JCloud scales according to your need. You can demand different resources (GPU / RAM / CPU / Storage / instance-capacity) your Flows & Executors need. We have the following restrictions on its usage. If you have specific resource requirements, please contact us on Slack or raise a Github issue.

Restrictions

  • Deployments are only supported in us-east region.

  • Each Executor is allowed a maximum of 4G RAM, 2 CPU cores & 10GB of block storage.

  • 3 Flows can be deployed at a time, out of which there can be 1 Flow using GPU.

  • A maximum of 2 GPUs are allowed per Flow.

  • Flows with Executors using GPU are removed after 12hrs, whereas other Flows are removed after 72hrs.