Deploying Functions

On This Page

This tutorial guides you through the process of deploying functions and specifying the function configuration.

Writing a simple function

After successfully installing Nuclio, you can start writing functions and deploying them to your cluster. All supported runtimes (such as Go, Python, or NodeJS) have an entry point that receives two arguments:

Context: An object that maintains state across function invocations. Includes objects like the logger, data bindings, worker information and user specified data. See the appropriate context reference for your specific runtime for more

Event: An object containing information about the event that triggered the function including body, headers, trigger information and so forth

The entry point, essentially a function native to the runtime, is called whenever one of the configured triggers receives an event (more on configuring triggers later).

Note

Nuclio supports configuring multiple triggers for a single function. For example, the same function can be called both via calling an HTTP endpoint and posting to a Kafka stream. Some functions can behave uniformly, as accessing many properties of the event is identical regardless of triggers (for example, event.GetBody()). Others may want to behave differently, using the event’s trigger information to determine through which trigger it arrived.

The entry point may return a response which is handled differently based on which trigger configured the function. Some synchronous triggers (like HTTP) expect a response, some (like RabbitMQ) expect an ack or nack and others (like cron) ignore the response altogether.

To put this in Python code, an entry point is a simple function with two arguments and a return value:

importosdefmy_entry_point(context,event):# use the logger, outputting the event bodycontext.logger.info_with('Got invoked',trigger_kind=event.trigger.kind,event_body=event.body,some_env=os.environ.get('MY_ENV_VALUE'))# check if the event came from cronifevent.trigger.kind=='cron':# log somethingcontext.logger.info('Invoked from cron')else:# return a responsereturn'A string response'

Deploying a simple function

To convert source code to a running function, you must first deploy the function. A deploy process has three stages:

The source code is built to a Docker image and pushed to a Docker registry

A function object is created in Nuclio (i.e., in Kubernetes, this is a function CRD)

A controller creates the appropriate function resources on the cluster (i.e., in Kubernetes this is the deployment, service, ingress, etc.)

This process can be triggered through nuctl deploy which you will use throughout this tutorial. You will now write the function that you wrote in the previous step to a /tmp/nuclio/my_function.py file. Before you do anything, verify with nuctl that everything is properly configured by getting all functions deployed in the “nuclio” namespace:

nuctl get function --namespace nuclio
No functions found

Now deploy your function, specifying the function name, the path, the “nuclio” namespace to which all setup guides expect functions to go to and applicable registry information:

Once the function deploys, you should see Function deploy complete and an HTTP port through which you can invoke it. If there’s a problem, invoke the above with --verbose and try to understand what went wrong. You can see your function through nuctl get:

Providing function configuration

There are often cases in which providing code is not enough to deploy a function. For example, if

The function expects environment variables or secrets

You would like to trigger the function through Kafka, Kinesis, etc. These require configuration to connect to the data source

There are third-party dependencies or additional files (both language packages and OS) that need to reside alongside the function

For such cases and many others you need to provide a function configuration alongside your function code. Nuclio provides you with several mechanisms for providing the function configuration:

A function.yaml file

Inline configuration by means of crafting a comment in your code that contains the function.yaml contents

Command-line arguments for the Nuclio CLI (nuctl). This argument will override the function.yaml configuration, if present

The UI, through the Configuration tab

While there are several mechanisms to provide the configuration, there is only one configuration schema. In the following examples, you’ll set an environment variable (MY_ENV_VALUE) and add a cron trigger through nuctl, a function.yaml file and inline configuration.

After you provide this configuration, you can invoke the function and notes that MY_ENV_VALUE is now set to my value:

Providing configuration via inline configuration

Sometimes it’s convenient to have the source and configuration bundled together in a single, human readable file. While it’s not recommended for production, it’s great for trying things out. To do this, you craft a special comment somewhere in your function source and provide the containing file as path (this will not work if path is a directory).