Ir al contenido principal

gcloud: Run cloud functions from command line

Tired of that slow web interface that Google Cloud Console offers to those lazy programmers out there? Then gcloud comes to your help.

Among other miriad of functions, gcloud allows calling GC functions from the command line of your computer. For instance, this command calls the helloWorld function, deployed on the cloud region "europe-west1":

gcloud functions call helloWorld --region="europe-west1"

Calling gcloud functions list is the way to get all the available GC functions, together with their state, trigger and cloud region.

Functions input data

Most of the times your functions will require some data input to work. Depending on the function triggering method, data can arrive in different ways (in the body of an HTTP request, in a PubSub message...), but they way of sending that data from the gcloud command is always the same:

gcloud functions call helloWorld \
--region "europe-west1" --data '{"data":"cGxhbmV0IEVhcnRo"}'

The --data argument accepts a string that must be a JSON formatted object with one property called data whose value is the function Base64-encoded input. In this case, decoding  "cGxhbmV0IEVhcnRo" you get the string "planet Earth" that becomes the input to your function. A good online tool for Base64 encoding/decoding is available at base64encode.org

Functions output

Running a function in the way exposed above will drop different ouputs:
  • If the function runs successfully, you will get the execution id and result
  • If the function fails, you will get the error message
In case the function logged information, it is possible to check it from the command line by running this command:

gcloud functions logs read helloWorld \
--region "europe-west1" --start-time "2020-07-31T12:00:00Z"

That command will show up to 20 log entries associated to the GC function helloWorld run in the region "europe-west1" logged after 12:00:00 of the 31th of July of 2020 UTC. 

For getting the logs of a specific function execution, you can call the above command by setting the function execution id that, as said, is returned by a successful gcloud functions call execution:

gcloud functions logs read helloWorld \
--region "europe-west1" --start-time "2020-07-31" \
--execution-id "abcdefghijkl"

Note that in the previous example a partial datetime representation (only date) is set to the argument start-time. Check the Google Cloud SDK documentation for knowing additional command options.

Changing the default region

As shown in the above examples, the argument --region is alway present. Setting it is specially important: if it is not set, gcloud will search the requested function or log info in the locally set, default cloud region ("us-central1"). In case that the function or log info was not in that region, the command will fail. 

The way to know the locally set default region is checking your local configuration settings with this command:

gcloud config get-value functions/region

If most of your functions lie in a region that is not the default one ("us-central1"), you'll have to explicitly set it every time you called a gcloud command for which the region was relevant, as gcloud functions call  or gcloud functions logs are.  However the modern programmer Bible says "Only the sinners write too much", so a good way to stay on purity is modifying the local default region by running this command:

gcloud config set functions/region "europe-west1"

The above example sets "europe-west1" as the default region so now we can call the helloWorld GC function in this simplified way:

gcloud functions call helloWorld \
--data '{"data":"cGxhbmV0IEVhcnRo"}'

No panic about that setting, it is only applied to your local machine gcloud installation and therefore it has not impact in your cloud ecosystem.

To known more about

Google Cloud SDK documentation is the official reference for getting more information about gcloud functions features.

Comentarios

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what  linting  is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld {      using System;      public class Program      {           public static void Main(string[] args)           {                Console

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.