Skip to content

Latest commit

 

History

History
305 lines (198 loc) · 7.66 KB

index.md

File metadata and controls

305 lines (198 loc) · 7.66 KB
Raw

(jcloud)=

JCloud

:hidden:

yaml-spec

:width: 0 %
:scale: 0 %

:scale: 0 %
:width: 0 %

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.

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.

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

```bash
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.

Flows have a maximal {ref}`lifetime<jcloud-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
Testing locally before deploying is recommended. You can use 

```bash
jina flow --uses flow.yml
```

A project folder

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:

:width: 70%

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

(jcloud-flow-status)=

Get status

To get the status of a Flow:

jc status 15937a10bd
:width: 70%

Monitoring

Basic monitoring is provided to the Flows deployed on JCloud.

To access the Grafana powered dashboard, get {ref}the status of the Flow<jcloud-flow-status> 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':

:width: 70%

List Flows

To list all the Flows you have:

jc list

You can see the ALIVE Flows deployed by you.

:width: 70%

You can also filter your Flows by passing a status:

jc list --status FAILED
:width: 70%

Or see all the flows:

jc list --status ALL
:width: 70%

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.

  
- 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.