IBM Virtual Private Cloud#

The IBM VPC client of Lithops can provide a truely serverless user experience on top of IBM VPC where Lithops creates new VSIs (Virtual Server Instance) dynamically in runtime, and scale Lithops jobs against them. Alternatively Lithops can start and stop an existing VSI instances.

Note that IBM VPC is a standalone backend, and as such, you can configure extra parameters in the ‘standalone’ section of the configuration:

Group

Key

Default

Mandatory

Additional info

standalone

runtime

python3

no

Runtime name to run the functions. Can be a Docker image name

standalone

auto_dismantle

True

no

If False then the VM is not stopped automatically.

standalone

soft_dismantle_timeout

300

no

Time in seconds to stop the VM instance after a job completed its execution

standalone

hard_dismantle_timeout

3600

no

Time in seconds to stop the VM instance after a job started its execution

standalone

exec_mode

consume

no

One of: consume, create or reuse. If set to create, Lithops will automatically create new VMs for each map() call based on the number of elements in iterdata. If set to reuse will try to reuse running workers if exist

standalone

pull_runtime

False

no

If set to True, Lithops will execute the command docker pull <runtime_name> in each VSI before executing the a job (in case of using a docker runtime)

standalone

workers_policy

permissive

no

One of: permissive, strict. If set to strict will force creation of required workers number

standalone

gpu

False

no

If True docker started with gpu support. Requires host to have neccessary hardware and software preconfigured and docker image runtime with gpu support specified

Configure a Container registry#

To configure Lithops to access a private container registry, you need to add the following keys to the standalone section in config:

standalone:
    ....
    docker_server    : <Container registry server>
    docker_user      : <Container registry username>
    docker_password  : <Container registry access token>

Configure IBM Container Registry#

To configure Lithops to access to a private docker repository in your IBM Container Registry, you need to extend the standalone config and add the following keys:

standalone:
    ....
    docker_server    : us.icr.io  # Change-me if you have the CR in another region
    docker_user      : iamapikey
    docker_password  : <IBM IAM API KEY>

IBM VPC#

The assumption that you already familiar with IBM Cloud, have your IBM IAM API key created (you can create new keys here), have valid IBM COS account, region and resource group.

Follow IBM VPC setup if you need to create IBM Virtual Private Cloud. Decide the region for your VPC. The best practice is to use the same region both for VPC and IBM COS, hoewever there is no requirement to keep them in the same region.

Choose an operating system image for VSI#

Any Virtual Service Instance (VSI) need to define the instance’s operating system and version. Lithops support both standard operting system choices provided by the VPC or using pre-defined custom images that already contains all dependencies required by Lithops.

  • Option 1: Lithops is compatible with any Ubuntu 22.04 image provided in IBM Cloud. In this case, no further action is required and you can continue to the next step. Lithops will install all required dependencies in the VSI by itself. Notice this can consume about 3 min to complete all installations.

  • Option 2: Alternatively, you can use a pre-built custom image that will greatly improve VSI creation time for Lithops jobs. To benefit from this approach, navigate to runtime/ibm_vpc, and follow the instructions.

Lithops and the VSI create and reuse mode#

In this mode, Lithops will automatically create new worker VM instances in runtime, scale Lithops job against generated VMs, and automatically delete VMs when the job is completed.

Lithops configuration for the create and reuse mode#

Edit your lithops config and add the relevant keys:

lithops:
    backend: ibm_vpc

ibm:
    iam_api_key: <iam-api-key>

standalone:
    exec_mode: reuse

ibm_vpc:
    region: <REGION>
    resource_group_id: <RESOURCE_GROUP_ID>

Summary of the configuration keys for the create and reuse mode#

Group

Key

Default

Mandatory

Additional info

ibm_vpc

region

yes

VPC Region. For example us-south. Choose one region from here

ibm_vpc

resource_group_id

yes

Resource group id from your IBM Cloud account. Get it from https://cloud.ibm.com/account/resource-groups

ibm_vpc

vpc_id

no

VPC id of an existing VPC. Get it from https://cloud.ibm.com/vpc-ext/network/vpcs

ibm_vpc

vpc_name

no

VPC name of an existing VPC (if vpc_id is not provided)

ibm_vpc

security_group_id

no

Security group id of an existing VPC. Get it from https://cloud.ibm.com/vpc-ext/network/securityGroups

ibm_vpc

subnet_id

no

Subnet id of an existing VPC. Get it from https://cloud.ibm.com/vpc-ext/network/subnets

ibm_vpc

ssh_key_id

no

SSH public key id. Get it from https://cloud.ibm.com/vpc-ext/compute/sshKeys

ibm_vpc

gateway_id

no

Gateway id. Get it from https://cloud.ibm.com/vpc-ext/network/publicGateways

ibm_vpc

image_id

no

Virtual machine image id

ibm_vpc

ssh_username

root

no

Username to access the VPC

ibm_vpc

ssh_password

no

Password for accessing the worker VMs. If not provided, it is created randomly

ibm_vpc

ssh_key_filename

no

Path to the ssh key file provided to access the VPC. It will use the default path if not provided

ibm_vpc

boot_volume_profile

general-purpose

no

Virtual machine boot volume profile

ibm_vpc

boot_volume_capacity

100

no

Virtual machine boot volume capacity in GB. Set it to 10 if using a custom image.

ibm_vpc

worker_profile_name

cx2-2x4

no

Profile name for the worker VMs

ibm_vpc

master_profile_name

cx2-2x4

no

Profile name for the master VM

ibm_vpc

delete_on_dismantle

True

no

Delete the worekr VMs when they are stopped

ibm_vpc

max_workers

100

no

Max number of workers per FunctionExecutor()

ibm_vpc

worker_processes

2

no

Number of Lithops processes within a given worker. This can be used to parallelize function activations within a worker. It is recommendable to set this value to the same number of CPUs of a worker VM.

ibm_vpc

singlesocket

False

no

Try to allocate workers with single socket CPU. If eventually running on multiple socket, a warning message printed to user. Is True standalone workers_policy must be set to strict to trace workers states

Lithops and the VSI consume mode#

In this mode, Lithops can start and stop an existing VM, and deploy an entire job to that VM. The partition logic in this scenario is different from the auto create mode, since entire job executed in the same VM.

Lithops configuration for the consume mode#

Edit your lithops config and add the relevant keys:

lithops:
   backend: ibm_vpc

ibm:
   iam_api_key: <iam-api-key>

ibm_vpc:
   region   : <REGION>
   instance_id : <INSTANCE ID OF THE VM>
   floating_ip  : <FLOATING IP ADDRESS OF THE VM>

If you need to create new VM, then follow the steps to create and update Lithops configuration:

  1. Create an Ubuntu 22.04 virtual server instance (VSI) in IBM VPC virtual server instances UI with CPUs and RAM needed for your application.

  2. Reserve and associate a floating IP address in IBM VPC floating IPs UI to be used for the virtual server instance.

  3. Get the floating IP address of your virtual server instance which can be found here.

  4. Get the endpoint of your subnet region, endpoint URLs list can be found here.

  5. Get the virtual server instance ID by selecting on your instance in IBM VPC virtual server instances UI and then extracting from the instance’s details.

Summary of the configuration keys for the consume mode#

Group

Key

Default

Mandatory

Additional info

ibm_vpc

region

yes

VPC Region. For example us-south. Choose one region from here

ibm_vpc

instance_id

yes

virtual server instance ID

ibm_vpc

floating_ip

yes

Floatting IP address atached to your VM instance

ibm_vpc

ssh_key_filename

no

Path to the ssh key file provided to create the VM. It will use the default path if not provided

ibm_vpc

worker_processes

2

no

Number of Lithops processes within a given worker. This can be used to parallelize function activations within a worker. It is recommendable to set this value to the same number of CPUs of the VM.

Test Lithops#

Once you have your compute and storage backends configured, you can run a hello world function with:

lithops test -b ibm_vpc -s ibm_cos

Viewing the execution logs#

You can view the function executions logs in your local machine using the lithops client:

lithops logs poll

The master and worker VMs contains the Lithops service logs in /tmp/lithops/service.log

You can login to the master VM and get a live ssh connection with:

lithops attach -b ibm_vpc