Radar has landed - discover the latest DDoS attack trends. Get ahead, stay protected.Get the report
Under attack?

Products

Solutions

Resources

Partners

Why Gcore

  1. Home
  2. Developers
  3. Create Serverless Functions with OpenFaaS

Create Serverless Functions with OpenFaaS

  • By Gcore
  • April 7, 2023
  • 13 min read
Create Serverless Functions with OpenFaaS

OpenFaaS is a serverless functions framework that runs on top of Docker and Kubernetes. In this tutorial, you’ll learn how to:

  • Deploy OpenFaaS to a Kubernetes cluster
  • Set up the OpenFaaS CLI
  • Create, build, and deploy serverless functions using the CLI
  • Invoke serverless functions using the CLI
  • Update an existing serverless function
  • Deploy serverless functions using the web interface
  • Monitor your serverless functions with Prometheus and Grafana

Prerequisites

  • A Kubernetes cluster. If you don’t have a running Kubernetes cluster, follow the instructions from the Set Up a Kubernetes Cluster with Kind section below.
  • A Docker Hub Account. See the Docker Hub page for details about creating a new account.
  • kubectl. Refer the Install and Set Up kubectl page for details about installing kubectl.
  • Node.js 10 or higher. To check if Node.js is installed on your computer, type the following command:
node --version

The following example output shows that Node.js is installed on your computer:

v10.16.3

If Node.js is not installed or you’re running an older version, you can download the installer from the Downloads page.

  • This tutorial assumes basic familiarity with Docker and Kubernetes.

Set Up a Kubernetes Cluster with Kind (Optional)

With Kind, you can run a local Kubernetes cluster using Docker containers as nodes. The steps in this section are optional. Follow them only if you don’t have a running Kubernetes cluster.

  1. Create a file named openfaas-cluster.yaml, and copy in the following spec:
# three node (two workers) cluster configkind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane- role: worker- role: worker
  1. Use the kind create cluster command to create a Kubernetes cluster with one control plane and two worker nodes:
kind create cluster --config kind-specs/kind-cluster.yaml
Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.17.0) 🖼 ✓ Preparing nodes 📦 📦 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 ✓ Joining worker nodes 🚜Set kubectl context to "kind-kind"You can now use your cluster with:kubectl cluster-info --context kind-kindThanks for using kind! 😊

Deploy OpenFaaS to a Kubernetes Cluster

You can install OpenFaaS using Helm, plain YAML files, or its own installer named arkade which provides a quick and easy way to get OpenFaaS running. In this section, you’ll deploy OpenFaaS with arkade.

  1. Enter the following command to install arkade:
curl -sLS https://dl.get-arkade.dev | sudo sh
Downloading package https://github.com/alexellis/arkade/releases/download/0.1.10/arkade-darwin as /Users/andrei/Desktop/openFaaS/faas-hello-world/arkade-darwinDownload complete.Running with sufficient permissions to attempt to move arkade to /usr/local/binNew version of arkade installed to /usr/local/binCreating alias 'ark' for 'arkade'.            _             _  __ _ _ __| | ____ _  __| | ___ / _` | '__| |/ / _` |/ _` |/ _ \| (_| | |  |   < (_| | (_| |  __/ \__,_|_|  |_|\_\__,_|\__,_|\___|Get Kubernetes apps the easy wayVersion: 0.1.10Git Commit: cf96105d37ed97ed644ab56c0660f0d8f4635996
  1. Now, install openfaas with:
arkade install openfaas
Using kubeconfig: /Users/andrei/.kube/configUsing helm3Node architecture: "amd64"Client: "x86_64", "Darwin"2020/03/10 16:20:40 User dir established as: /Users/andrei/.arkade/https://get.helm.sh/helm-v3.1.1-darwin-amd64.tar.gz/Users/andrei/.arkade/bin/helm3/darwin-amd64 darwin-amd64//Users/andrei/.arkade/bin/helm3/README.md darwin-amd64/README.md/Users/andrei/.arkade/bin/helm3/LICENSE darwin-amd64/LICENSE/Users/andrei/.arkade/bin/helm3/helm darwin-amd64/helm2020/03/10 16:20:43 extracted tarball into /Users/andrei/.arkade/bin/helm3: 3 files, 0 dirs (1.633976582s)"openfaas" has been added to your repositoriesHang tight while we grab the latest from your chart repositories......Successfully got an update from the "ibm-charts" chart repository...Successfully got an update from the "openfaas" chart repository...Successfully got an update from the "stable" chart repository...Successfully got an update from the "bitnami" chart repositoryUpdate Complete. ⎈ Happy Helming!⎈VALUES values.yamlCommand: /Users/andrei/.arkade/bin/helm3/helm [upgrade --install openfaas openfaas/openfaas --namespace openfaas --values /var/folders/nz/2gtkncgx56sgrpqvr40qhhrw0000gn/T/charts/openfaas/values.yaml --set gateway.directFunctions=true --set faasnetes.imagePullPolicy=Always --set gateway.replicas=1 --set queueWorker.replicas=1 --set clusterRole=false --set operator.create=false --set openfaasImagePullPolicy=IfNotPresent --set basicAuthPlugin.replicas=1 --set basic_auth=true --set serviceType=NodePort]Release "openfaas" does not exist. Installing it now.NAME: openfaasLAST DEPLOYED: Tue Mar 10 16:21:03 2020NAMESPACE: openfaasSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:To verify that openfaas has started, run:  kubectl -n openfaas get deployments -l "release=openfaas, app=openfaas"======================================================================== OpenFaaS has been installed.                                        ========================================================================# Get the faas-clicurl -SLsf https://cli.openfaas.com | sudo sh# Forward the gateway to your machinekubectl rollout status -n openfaas deploy/gatewaykubectl port-forward -n openfaas svc/gateway 8080:8080 &# If basic auth is enabled, you can now log into your gateway:PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath="{.data.basic-auth-password}" | base64 --decode; echo)echo -n $PASSWORD | faas-cli login --username admin --password-stdinfaas-cli store deploy figletfaas-cli list# For Raspberry Pifaas-cli store list \ --platform armhffaas-cli store deploy figlet \ --platform armhf# Find out more at:# https://github.com/openfaas/faasThanks for using arkade!
  1. To verify that the deployments were created, run the kubectl get deployments command. Specify the namespace and the selector using the -n and -l parameters as follows:
kubectl get deployments -n openfaas -l "release=openfaas, app=openfaas"

If the deployments are not yet ready, you should see something similar to the following example output:

NAME                READY   UP-TO-DATE   AVAILABLE   AGEalertmanager        0/1     1            0           45sbasic-auth-plugin   1/1     1            1           45sfaas-idler          0/1     1            0           45sgateway             0/1     1            0           45snats                1/1     1            1           45sprometheus          1/1     1            1           45squeue-worker        1/1     1            1           45s

Once the installation is finished, the output should look like this:

NAME                READY   UP-TO-DATE   AVAILABLE   AGEalertmanager        1/1     1            1           75sbasic-auth-plugin   1/1     1            1           75sfaas-idler          1/1     1            1           75sgateway             1/1     1            1           75snats                1/1     1            1           75sprometheus          1/1     1            1           75squeue-worker        1/1     1            1           75s
  1. Check the rollout status of the gateway deployment:
kubectl rollout status -n openfaas deploy/gateway

The following example output shows that the gateway deployment has been successfully rolled out:

deployment "gateway" successfully rolled out
  1. Use the kubectl port-forward command to forward all requests made to
    http://localhost:8080
    to the pod running the
    gateway
    service:
kubectl port-forward -n openfaas svc/gateway 8080:8080 &
[1] 78674Forwarding from 127.0.0.1:8080 -> 8080Forwarding from [::1]:8080 -> 8080

Note that the ampersand sign (&) runs the process in the background. You can use the jobs command to show the status of your background processes:

jobs
[1]  + running    kubectl port-forward -n openfaas svc/gateway 8080:8080
  1. Issue the following command to retrieve your password and save it into an environment variable named PASSWORD:
PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath="{.data.basic-auth-password}" | base64 --decode; echo)

Set Up the OpenFaaS CLI

OpenFaaS provides a command-line utility you can use to build and deploy your serverless functions. You can install it by following the steps from the Installation page.

Create a Serverless Function Using the CLI

Now that OpenFaaS and the faas-cli command-line utility are installed, you can create and deploy serverless functions using the built-in template engine. OpenFaaS provides two types of templates:

  • The Classic templates are based on the Classic Watchdog and use stdio to communicate with your serverless function. Refer to the Watchdog page for more details about how OpenFaaS Watchdog works.
  • The of-watchdog templates use HTTP to communicate with your serverless function. These templates are available through the OpenFaaS Incubator GitHub repository.

In this tutorial, you’ll use a classic template.

  1. Run the following command to see the templates available in the official store:
faas-cli template store list
NAME                     SOURCE             DESCRIPTIONcsharp                   openfaas           Classic C# templatedockerfile               openfaas           Classic Dockerfile templatego                       openfaas           Classic Golang templatejava8                    openfaas           Classic Java 8 templatenode                     openfaas           Classic NodeJS 8 templatephp7                     openfaas           Classic PHP 7 templatepython                   openfaas           Classic Python 2.7 templatepython3                  openfaas           Classic Python 3.6 templatepython3-dlrs             intel              Deep Learning Reference Stack v0.4 for ML workloadsruby                     openfaas           Classic Ruby 2.5 templatenode10-express           openfaas-incubator Node.js 10 powered by express templateruby-http                openfaas-incubator Ruby 2.4 HTTP templatepython27-flask           openfaas-incubator Python 2.7 Flask templatepython3-flask            openfaas-incubator Python 3.6 Flask templatepython3-http             openfaas-incubator Python 3.6 with Flask and HTTPnode8-express            openfaas-incubator Node.js 8 powered by express templategolang-http              openfaas-incubator Golang HTTP templategolang-middleware        openfaas-incubator Golang Middleware templatepython3-debian           openfaas           Python 3 Debian templatepowershell-template      openfaas-incubator Powershell Core Ubuntu:16.04 templatepowershell-http-template openfaas-incubator Powershell Core HTTP Ubuntu:16.04 templaterust                     booyaa             Rust templatecrystal                  tpei               Crystal templatecsharp-httprequest       distantcam         C# HTTP templatecsharp-kestrel           burtonr            C# Kestrel HTTP templatevertx-native             pmlopes            Eclipse Vert.x native image templateswift                    affix              Swift 4.2 Templatelua53                    affix              Lua 5.3 Templatevala                     affix              Vala Templatevala-http                affix              Non-Forking Vala Templatequarkus-native           pmlopes            Quarkus.io native image templateperl-alpine              tmiklas            Perl language template based on Alpine imagenode10-express-service   openfaas-incubator Node.js 10 express.js microservice templatecrystal-http             koffeinfrei        Crystal HTTP templaterust-http                openfaas-incubator Rust HTTP templatebash-streaming           openfaas-incubator Bash Streaming template

☞ Note that you can specify an alternative store for templates. The following example command lists the templates from a repository named andreipope:

faas-cli template store list -u https://raw.githubusercontent.com/andreipope/my-custom-store/master/templates.json
  1. Download the official templates locally:
faas-cli template pull
Fetch templates from repository: https://github.com/openfaas/templates.git at master2020/03/11 20:51:22 Attempting to expand templates from https://github.com/openfaas/templates.git2020/03/11 20:51:25 Fetched 19 template(s) : [csharp csharp-armhf dockerfile go go-armhf java11 java11-vert-x java8 node node-arm64 node-armhf node12 php7 python python-armhf python3 python3-armhf python3-debian ruby] from https://github.com/openfaas/templates.git

☞ By default, the above command downloads the templates from the OpenFaaS official GitHub repository. If you want to use a custom repository, then you should specify the URL of your repository. The following example command pulls the templates from a repository named andreipope:

faas-cli template pull https://github.com/andreipope/my-custom-store/
  1. To create a new serverless function, run the faas-cli new command specifying:
  • The name of your new function (appfleet-hello-world)
  • The lang parameter followed by the programming language template (node).
faas-cli new appfleet-hello-world --lang node
Folder: appfleet-hello-world created.  ___                   _____           ____ / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \| |_| | |_) |  __/ | | |  _| (_| | (_| |___) | \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/      |_|Function created in folder: appfleet-hello-worldStack file written: appfleet-hello-world.ymlNotes:You have created a new function which uses Node.js 12.13.0 and the OpenFaaSClassic Watchdog.npm i --save can be used to add third-party packages like request or cheerionpm documentation: https://docs.npmjs.com/For high-throughput services, we recommend you use the node12 template whichuses a different version of the OpenFaaS watchdog.

At this point, your directory structure should look like the following:

tree . -L 2
.├── appfleet-hello-world│   ├── handler.js│   └── package.json├── appfleet-hello-world.yml└── template    ├── csharp    ├── csharp-armhf    ├── dockerfile    ├── go    ├── go-armhf    ├── java11    ├── java11-vert-x    ├── java8    ├── node    ├── node-arm64    ├── node-armhf    ├── node12    ├── php7    ├── python    ├── python-armhf    ├── python3    ├── python3-armhf    ├── python3-debian    └── ruby21 directories, 3 files

Things to note:

  • The appfleet-hello-world/handler.js file contains the code of your serverless function. You can use the echo command to list the contents of this file:
cat appfleet-hello-world/handler.js
"use strict"module.exports = async (context, callback) => {    return {status: "done"}}
  • You can specify the dependencies required by your serverless function in the package.json file. The automatically generated file is just an empty shell:
cat appfleet-hello-world/package.json
{  "name": "function",  "version": "1.0.0",  "description": "",  "main": "handler.js",  "scripts": {    "test": "echo \"Error: no test specified\" && exit 1"  },  "keywords": [],  "author": "",  "license": "ISC"}
  • The spec of the appfleet-hello-world function is stored in the appfleet-hello-world.yml file:
cat appfleet-hello-world.yml
version: 1.0provider:  name: openfaas  gateway: http://127.0.0.1:8080functions:  appfleet-hello-world:    lang: node    handler: ./appfleet-hello-world    image: appfleet-hello-world:latest

Build Your Serverless Function

  1. Open the appfleet-hello-world.yml file in a plain-text editor, and update the image field by prepending your Docker Hub user name to it. The following example prepends my username (andrepopescu12) to the image field:
image: andrepopescu12/appfleet-hello-world:latest

Once you’ve made this change, the appfleet-hello-world.yml file should look similar to the following:

version: 1.0provider:  name: openfaas  gateway: http://127.0.0.1:8080functions:  appfleet-hello-world:    lang: node    handler: ./appfleet-hello-world    image: <YOUR-DOCKER-HUB-ACCOUNT>/appfleet-hello-world:latest
  1. Build the function. Enter the faas-cli build command specifying the -f argument with the name of the YAML file you edited in the previous step (appfleet-hello-world.yml):
faas-cli build -f appfleet-hello-world.yml
[0] > Building appfleet-hello-world.Clearing temporary build folder: ./build/appfleet-hello-world/Preparing: ./appfleet-hello-world/ build/appfleet-hello-world/functionBuilding: andreipopescu12/appfleet-hello-world:latest with node template. Please wait..Sending build context to Docker daemon  10.24kBStep 1/24 : FROM openfaas/classic-watchdog:0.18.1 as watchdog ---> 94b5e0bef891Step 2/24 : FROM node:12.13.0-alpine as ship ---> 69c8cc9212ecStep 3/24 : COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog ---> Using cache ---> ebab4b723c16Step 4/24 : RUN chmod +x /usr/bin/fwatchdog ---> Using cache ---> 7952724b5872Step 5/24 : RUN addgroup -S app && adduser app -S -G app ---> Using cache ---> 33c7f04595d2Step 6/24 : WORKDIR /root/ ---> Using cache ---> 77b9dee16c79Step 7/24 : ENV NPM_CONFIG_LOGLEVEL warn ---> Using cache ---> a3d3c0bb4480Step 8/24 : RUN mkdir -p /home/app ---> Using cache ---> 65457e03fcb1Step 9/24 : WORKDIR /home/app ---> Using cache ---> 50ab672e5660Step 10/24 : COPY package.json ./ ---> Using cache ---> 6143e79de873Step 11/24 : RUN npm i --production ---> Using cache ---> a41566487c6eStep 12/24 : COPY index.js ./ ---> Using cache ---> 566633e78d2cStep 13/24 : WORKDIR /home/app/function ---> Using cache ---> 04c9de75f170Step 14/24 : COPY function/*.json ./ ---> Using cache ---> 85cf909b646aStep 15/24 : RUN npm i --production || : ---> Using cache ---> c088cbcad583Step 16/24 : COPY --chown=app:app function/ . ---> Using cache ---> 192db89e5941Step 17/24 : WORKDIR /home/app/ ---> Using cache ---> ee2b7d7e8bd4Step 18/24 : RUN chmod +rx -R ./function     && chown app:app -R /home/app     && chmod 777 /tmp ---> Using cache ---> 81831389293eStep 19/24 : USER app ---> Using cache ---> ca0cade453f5Step 20/24 : ENV cgi_headers="true" ---> Using cache ---> afe8d7413349Step 21/24 : ENV fprocess="node index.js" ---> Using cache ---> 5471cfe85461Step 22/24 : EXPOSE 8080 ---> Using cache ---> caaa8ae11dc7Step 23/24 : HEALTHCHECK --interval=3s CMD [ -e /tmp/.lock ] || exit 1 ---> Using cache ---> 881b4d2adb92Step 24/24 : CMD ["fwatchdog"] ---> Using cache ---> 82b586f039dfSuccessfully built 82b586f039dfSuccessfully tagged andreipopescu12/appfleet-hello-world:latestImage: andreipopescu12/appfleet-hello-world:latest built.[0] < Building appfleet-hello-world done in 2.25s.[0] Worker done.Total build time: 2.25s
  1. You can list your Docker images with:
docker images
REPOSITORY                             TAG                 IMAGE ID            CREATED             SIZEandreipopescu12/appfleet-hello-world   latest              82b586f039df        25 minutes ago      96MB

Push Your Image to Docker Hub

  1. Log in to Docker Hub. Run the docker login command with the --username flag followed by your Docker Hub user name. The following example command logs you in as andreipopescu12:
docker login --username andreipopescu12

Next, you will be prompted to enter your Docker Hub password:

Password:Login Succeeded
  1. Use the faas-cli push command to push your serverless function to Docker Hub:
faas-cli push -f appfleet-hello-world.yml
The push refers to repository [docker.io/andreipopescu12/appfleet-hello-world]073c41b18852: Pusheda5c05e98c215: Pushedf749ad113dce: Pushede4f29400b370: Pushedb7d0eb42e645: Pushed84fba0eb2756: Pushedcf2a3f2bc398: Pushed942d3272b7d4: Pushed037b653b7d4e: Pushed966655dc62be: Pushed08d8e0925a73: Pushed6ce16b164ed0: Pushedd76ecd300100: Pushed77cae8ab23bf: Pushedlatest: digest: sha256:4150d4cf32e7e5ffc8fd15efeed16179bbf166536f1cc7a8c4105d01a4042928 size: 3447[0] < Pushing appfleet-hello-world [andreipopescu12/appfleet-hello-world:latest] done.[0] Worker done.

Deploy Your Function Using the CLI

  1. With your serverless function pushed to Docker Hub, log in to your local instance of the OpenFaaS gateway by entering the following command:
echo -n $PASSWORD | faas-cli login --username admin --password-stdin
  1. Run the faas-cli deploy command to deploy your serverless function:
faas-cli deploy -f appfleet-hello-world.yml
Deploying: appfleet-hello-world.WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.Handling connection for 8080Handling connection for 8080Deployed. 202 Accepted.URL: http://127.0.0.1:8080/function/appfleet-hello-world

☞ OpenFaaS provides an auto-scaling mechanism based on the number of requests per second, which is read from Prometheus. For the sake of simplicity, we won’t cover auto-scaling in this tutorial. To further your knowledge, you can refer the Auto-scaling page.

  1. Use the faas-cli list command to list the functions deployed to your local OpenFaaS gateway:
faas-cli list
Function                      	Invocations    	Replicasappfleet-hello-world          	0              	1

☞ Note that you can also list the functions deployed to a different gateway by providing the URL of the gateway as follows:

faas-cli list --gateway https://<YOUR-GATEWAT-URL>:<YOUR-GATEWAY-PORT>
  1. You can use the faas-cli describe method to retrieve more details about the appfleet-hello-world function:
faas-cli describe appfleet-hello-world
Name:                appfleet-hello-worldStatus:              ReadyReplicas:            1Available replicas:  1Invocations:         1Image:               andreipopescu12/appfleet-hello-world:latestFunction process:    node index.jsURL:                 http://127.0.0.1:8080/function/appfleet-hello-worldAsync URL:           http://127.0.0.1:8080/async-function/appfleet-hello-worldLabels:              faas_function : appfleet-hello-worldAnnotations:         prometheus.io.scrape : false

Invoke Your Serverless Function Using the CLI

  1. To see your serverless function in action, issue the faas-cli invoke command, specifying:
  • The -f flag with the name of the YAML file that describes your function (appfleet-hello-world.yml)
  • The name of your function (appfleet-hello-world)
faas-cli invoke -f appfleet-hello-world.yml appfleet-hello-world
Reading from STDIN - hit (Control + D) to stop.
  1. Type CTRL+D. The following example output shows that your serverless function works as expected:
appfleetHandling connection for 8080{"status":"done"}

Update Your Function

The function you created, deployed, and then invoked in the previous sections is just an empty shell. In this section, we’ll update it to:

  • Read the name of a city from stdin
  • Fetch the weather forecast from the openweathermap.org
  • Print to the console the weather forecast
  1. Create an OpenWeatherMap account by following the instructions from the Sign Up page.
  2. Log in to OpenWeatherMap and then select API KEYS:
  1. From here, you can either copy the value of the default key or create a new API key, and then copy its value:
  1. Now that you have an OpenWeatherMap API key, you must use npm to install a few dependencies. The following command moves into the appfleet-hello-world directory and then installs the get-stdin and request packages:
cd appfleet-hello-world && npm i --save get-stdin request
  1. Replace the content of the handler.js file with:
"use strict"const getStdin = require('get-stdin')const request = require('request');let handler = (req) => {  request(`http://api.openweathermap.org/data/2.5/weather?q=${req}&?units=metric&APPID=<YOUR-OPENWEATHERMAP-APP-KEY>`, function (error, response, body) {    console.error('error:', error)    console.log('statusCode:', response && response.statusCode)    console.log('body:', JSON.stringify(body))  })};getStdin().then(val => {   handler(val);}).catch(e => {  console.error(e.stack);});module.exports = handler

☞ To try this function, replace <YOUR-OPENWEATHERMAP-API-KEY> with your OpenWeatherMap API KEY.

  1. You can use the faas-cli remove command to remove the function you’ve deployed earlier in this tutorial:
faas-cli remove appfleet-hello-world
Deleting: appfleet-hello-world.Handling connection for 8080Removing old function.
  1. Now that the old function has been removed, you must rebuild, push, and deploy your modified function. Instead of issuing three separate commands, you can use the openfaas-cli up command as in the following example:
faas-cli up -f appfleet-hello-world.yml
[0] > Building appfleet-hello-world.Clearing temporary build folder: ./build/appfleet-hello-world/Preparing: ./appfleet-hello-world/ build/appfleet-hello-world/functionBuilding: andreipopescu12/appfleet-hello-world:latest with node template. Please wait..Sending build context to Docker daemon  43.01kBStep 1/24 : FROM openfaas/classic-watchdog:0.18.1 as watchdog ---> 94b5e0bef891Step 2/24 : FROM node:12.13.0-alpine as ship ---> 69c8cc9212ecStep 3/24 : COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog ---> Using cache ---> ebab4b723c16Step 4/24 : RUN chmod +x /usr/bin/fwatchdog ---> Using cache ---> 7952724b5872Step 5/24 : RUN addgroup -S app && adduser app -S -G app ---> Using cache ---> 33c7f04595d2Step 6/24 : WORKDIR /root/ ---> Using cache ---> 77b9dee16c79Step 7/24 : ENV NPM_CONFIG_LOGLEVEL warn ---> Using cache ---> a3d3c0bb4480Step 8/24 : RUN mkdir -p /home/app ---> Using cache ---> 65457e03fcb1Step 9/24 : WORKDIR /home/app ---> Using cache ---> 50ab672e5660Step 10/24 : COPY package.json ./ ---> Using cache ---> 6143e79de873Step 11/24 : RUN npm i --production ---> Using cache ---> a41566487c6eStep 12/24 : COPY index.js ./ ---> Using cache ---> 566633e78d2cStep 13/24 : WORKDIR /home/app/function ---> Using cache ---> 04c9de75f170Step 14/24 : COPY function/*.json ./ ---> Using cache ---> f5765914bd05Step 15/24 : RUN npm i --production || : ---> Using cache ---> a300be28c096Step 16/24 : COPY --chown=app:app function/ . ---> 91cd72d8ad7aStep 17/24 : WORKDIR /home/app/ ---> Running in fce50a76475aRemoving intermediate container fce50a76475a ---> 0ff17b0a9fafStep 18/24 : RUN chmod +rx -R ./function     && chown app:app -R /home/app     && chmod 777 /tmp ---> Running in 6d0c4c92fac1Removing intermediate container 6d0c4c92fac1 ---> 1e543bfbf6b0Step 19/24 : USER app ---> Running in 6d33f5ec237dRemoving intermediate container 6d33f5ec237d ---> cb7cf5dfab12Step 20/24 : ENV cgi_headers="true" ---> Running in 972c23374934Removing intermediate container 972c23374934 ---> 21c6e8198b21Step 21/24 : ENV fprocess="node index.js" ---> Running in 3be91f9d5228Removing intermediate container 3be91f9d5228 ---> aafb7a756d38Step 22/24 : EXPOSE 8080 ---> Running in da3183bd88c5Removing intermediate container da3183bd88c5 ---> 5f6fd7e66a95Step 23/24 : HEALTHCHECK --interval=3s CMD [ -e /tmp/.lock ] || exit 1 ---> Running in a590c91037aeRemoving intermediate container a590c91037ae ---> fbe20c32941fStep 24/24 : CMD ["fwatchdog"] ---> Running in 59cd231f0576Removing intermediate container 59cd231f0576 ---> 88cd8ac65adeSuccessfully built 88cd8ac65adeSuccessfully tagged andreipopescu12/appfleet-hello-world:latestImage: andreipopescu12/appfleet-hello-world:latest built.[0] < Building appfleet-hello-world done in 13.95s.[0] Worker done.Total build time: 13.95s[0] > Pushing appfleet-hello-world [andreipopescu12/appfleet-hello-world:latest].The push refers to repository [docker.io/andreipopescu12/appfleet-hello-world]04643e0c999f: Pusheddb3ccc4403b8: Pushed24d1d5a62262: Layer already existsadfa28db7666: Layer already existsb7d0eb42e645: Layer already exists84fba0eb2756: Layer already existscf2a3f2bc398: Layer already exists942d3272b7d4: Layer already exists037b653b7d4e: Layer already exists966655dc62be: Layer already exists08d8e0925a73: Layer already exists6ce16b164ed0: Layer already existsd76ecd300100: Layer already exists77cae8ab23bf: Layer already existslatest: digest: sha256:818d92b10d276d32bcc459e2918cb537051a14025e694eb59a9b3caa0bb4e41c size: 3456[0] < Pushing appfleet-hello-world [andreipopescu12/appfleet-hello-world:latest] done.[0] Worker done.Deploying: appfleet-hello-world.WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.Handling connection for 8080Handling connection for 8080Deployed. 202 Accepted.URL: http://127.0.0.1:8080/function/appfleet-hello-world

☞ Note that you can skip the push or the deploy steps:

  • The following example command skips the push step:
faas-cli up -f appfleet-hello-world.yml --skip-push
  • The following example command skips the deploy step:
faas-cli up -f appfleet-hello-world.yml --skip-deploy
  1. To verify that the updated serverless function works as expected, invoke it as follows:
faas-cli invoke -f appfleet-hello-world.yml appfleet-hello-world
Reading from STDIN - hit (Control + D) to stop.BerlinHandling connection for 8080Hello, you are currently in BerlinstatusCode: 200body: "{\"coord\":{\"lon\":13.41,\"lat\":52.52},\"weather\":[{\"id\":802,\"main\":\"Clouds\",\"description\":\"scattered clouds\",\"icon\":\"03d\"}],\"base\":\"stations\",\"main\":{\"temp\":282.25,\"feels_like\":270.84,\"temp_min\":280.93,\"temp_max\":283.15,\"pressure\":1008,\"humidity\":61},\"visibility\":10000,\"wind\":{\"speed\":13.9,\"deg\":260,\"gust\":19},\"clouds\":{\"all\":40},\"dt\":1584107132,\"sys\":{\"type\":1,\"id\":1275,\"country\":\"DE\",\"sunrise\":1584077086,\"sunset\":1584119213},\"timezone\":3600,\"id\":2950159,\"name\":\"Berlin\",\"cod\":200}"
  1. To clean-up, run the faas-cli remove command with the name of your serverless function (appfleet-hello-world as an argument):
faas-cli remove appfleet-hello-world
Deleting: appfleet-hello-world.Handling connection for 8080Removing old function.

Deploy Serverless Functions Using the Web Interface

OpenFaaS provides a web-based user interface. In this section, you’ll learn how you can use it to deploy a serverless function.

  1. First, you must use the echo command to retrieve your password:
echo $PASSWORD
49IoP28G8247MZcj6a1FWUYUx
  1. Open a browser and visit
    http://localhost:8080
    . To log in, use the admin username and the password you retrieved in the previous step. You will be redirected to the OpenFaaS home page. Select the DEPLOY NEW FUNCTION button:
  1. A new window will be displayed. Select the Custom tab, and then type:
  • docker.io/andreipopescu12/appfleet-hello-world in the Docker Image input box
  • appfleet-hello-world in the Function name input box
  1. Once you’ve filled in the Docker image and Function name input boxes, select the DEPLOY button:
  1. Your new function will be visible in the left navigation bar. Click on it:

You’ll be redirected to the invoke function page:

  1. In the Request body input box, type in the name of the city you want to retrieve the weather forecast for, and then select the INVOKE button:

If everything works well, the weather forecast will be displayed in the Response Body field:

Monitor Your Serverless Functions with Prometheus and Grafana

The OpenFaaS gateway exposes the following metrics:

Retrieved from https://docs.openfaas.com/architecture/metrics/

In this section, you will learn how to set up Prometheus and Grafana to track the health of your serverless functions.

  1. Use the following command to list your deployments:
kubectl get deployments -n openfaas -l "release=openfaas, app=openfaas"
NAME                READY   UP-TO-DATE   AVAILABLE   AGEalertmanager        1/1     1            1           15mbasic-auth-plugin   1/1     1            1           15mfaas-idler          1/1     1            1           15mgateway             1/1     1            1           15mnats                1/1     1            1           15mprometheus          1/1     1            1           15mqueue-worker        1/1     1            1           15m
  1. To expose the prometheus deployment, create a service object named prometheus-ui:
kubectl expose deployment prometheus -n openfaas --type=NodePort --name=prometheus-ui
service/prometheus-ui exposed

☞ The --type=NodePort flag exposes the prometheus-ui service on each of the node’s IP addresses. Also, a ClusterIP service is created. You’ll use this to connect to the prometheus-ui service from outside of the cluster.

  1. To inspect the prometheus-ui service, enter the following command:
kubectl get svc prometheus-ui -n openfaas
NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGEprometheus-ui   NodePort   10.96.129.204   <none>        9090:31369/TCP   8m1s
  1. Forward all requests made to
    http://localhost:9090
    to the pod running the prometheus-ui service:
kubectl port-forward -n openfaas svc/prometheus-ui 9090:9090 &
  1. Now, you can point your browser to
    http://localhost:9090
    , and you should see a page similar to the following screenshot:
  1. To deploy Grafana, you’ll the stefanprodan/faas-grafana:4.6.3 image. Run the following command:
kubectl run grafana -n openfaas --image=stefanprodan/faas-grafana:4.6.3 --port=3000
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.deployment.apps/grafana created
  1. Now, you can list your deployments with:
kubectl get deployments -n openfaas
NAME                READY   UP-TO-DATE   AVAILABLE   AGEalertmanager        1/1     1            1           46mbasic-auth-plugin   1/1     1            1           46mfaas-idler          1/1     1            1           46mgateway             1/1     1            1           46mgrafana             1/1     1            1           107snats                1/1     1            1           46mprometheus          1/1     1            1           46mqueue-worker        1/1     1            1           46m
  1. Use the following kubectl expose deployment command to create a service object that exposes the grafana deployment:
kubectl expose deployment grafana -n openfaas --type=NodePort --name=grafana
service/grafana exposed
  1. Retrieve details about your new service with:
kubectl get service grafana -n openfaas
NAME      TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGEgrafana   NodePort   10.96.194.59   <none>        3000:32464/TCP   60s
  1. Forward all requests made to
    http://localhost:3030
    to the pod running the grafana service:
kubectl port-forward -n openfaas svc/grafana 3000:3000 &
[3] 3973Forwarding from 127.0.0.1:3000 -> 3000Forwarding from [::1]:3000 -> 3000
  1. Now that you set up the port forwarding, you can access Grafana by pointing your browser to
    http://localhost:3000
    :
  1. Log into Grafana using the username admin and password admin. The Home Dashboard page will be displayed:
  1. From the left menu, select Dashboards –> Import:
  1. Type https://grafana.com/grafana/dashboards/3434 in the Grafana.com Dashboard input box. Then, select the Load button:
  1. In the Import Dashboard dialog box, set the Prometheus data source to faas, and then select Import:

An empty dashboard will be displayed:

  1. Now, you can invoke your function a couple of times using the faas-cli invoke command as follows:
faas-cli invoke -f appfleet-hello-world.yml appfleet-hello-world
  1. Switch back to the browser window that opened Grafana. Your dashboard should be automatically updated and look similar to the following screenshot:

We hope this tutorial was useful for learning the basics of deploying serverless functions with OpenFaaS.

Thanks for reading!

Discover more with Gcore Function as a Service

Related Articles

How to get the size of a directory in Linux

Understanding how to check directory size in Linux is critical for managing storage space efficiently. Understanding this process is essential whether you’re assessing specific folder space or preventing storage issues.This comprehensive guide covers commands and tools so you can easily calculate and analyze directory sizes in a Linux environment. We will guide you step-by-step through three methods: du, ncdu, and ls -la. They’re all effective and each offers different benefits.What is a Linux directory?A Linux directory is a special type of file that functions as a container for storing files and subdirectories. It plays a key role in organizing the Linux file system by creating a hierarchical structure. This arrangement simplifies file management, making it easier to locate, access, and organize related files. Directories are fundamental components that help ensure smooth system operations by maintaining order and facilitating seamless file access in Linux environments.#1 Get Linux directory size using the du commandUsing the du command, you can easily determine a directory’s size by displaying the disk space used by files and directories. The output can be customized to be presented in human-readable formats like kilobytes (KB), megabytes (MB), or gigabytes (GB).Check the size of a specific directory in LinuxTo get the size of a specific directory, open your terminal and type the following command:du -sh /path/to/directoryIn this command, replace /path/to/directory with the actual path of the directory you want to assess. The -s flag stands for “summary” and will only display the total size of the specified directory. The -h flag makes the output human-readable, showing sizes in a more understandable format.Example: Here, we used the path /home/ubuntu/, where ubuntu is the name of our username directory. We used the du command to retrieve an output of 32K for this directory, indicating a size of 32 KB.Check the size of all directories in LinuxTo get the size of all files and directories within the current directory, use the following command:sudo du -h /path/to/directoryExample: In this instance, we again used the path /home/ubuntu/, with ubuntu representing our username directory. Using the command du -h, we obtained an output listing all files and directories within that particular path.#2 Get Linux directory size using ncduIf you’re looking for a more interactive and feature-rich approach to exploring directory sizes, consider using the ncdu (NCurses Disk Usage) tool. ncdu provides a visual representation of disk usage and allows you to navigate through directories, view size details, and identify large files with ease.For Debian or Ubuntu, use this command:sudo apt-get install ncduOnce installed, run ncdu followed by the path to the directory you want to analyze:ncdu /path/to/directoryThis will launch the ncdu interface, which shows a breakdown of file and subdirectory sizes. Use the arrow keys to navigate and explore various folders, and press q to exit the tool.Example: Here’s a sample output of using the ncdu command to analyze the home directory. Simply enter the ncdu command and press Enter. The displayed output will look something like this:#3 Get Linux directory size using 1s -1aYou can alternatively opt to use the ls command to list the files and directories within a directory. The options -l and -a modify the default behavior of ls as follows:-l (long listing format)Displays the detailed information for each file and directoryShows file permissions, the number of links, owner, group, file size, the timestamp of the last modification, and the file/directory name-a (all files)Instructs ls to include all files, including hidden files and directoriesIncludes hidden files on Linux that typically have names beginning with a . (dot)ls -la lists all files (including hidden ones) in long format, providing detailed information such as permissions, owner, group, size, and last modification time. This command is especially useful when you want to inspect file attributes or see hidden files and directories.Example: When you enter ls -la command and press Enter, you will see an output similar to this:Each line includes:File type and permissions (e.g., drwxr-xr-x):The first character indicates the file type- for a regular filed for a directoryl for a symbolic linkThe next nine characters are permissions in groups of three (rwx):r = readw = writex = executePermissions are shown for three classes of users: owner, group, and others.Number of links (e.g., 2):For regular files, this usually indicates the number of hard linksFor directories, it often reflects subdirectory links (e.g., the . and .. entries)Owner and group (e.g., user group)File size (e.g., 4096 or 1045 bytes)Modification date and time (e.g., Jan 7 09:34)File name (e.g., .bashrc, notes.txt, Documents):Files or directories that begin with a dot (.) are hidden (e.g., .bashrc)ConclusionThat’s it! You can now determine the size of a directory in Linux. Measuring directory sizes is a crucial skill for efficient storage management. Whether you choose the straightforward du command, use the visual advantages of the ncdu tool, or opt for the versatility of ls -la, this expertise enhances your ability to uphold an organized and efficient Linux environment.Looking to deploy Linux in the cloud? With Gcore Edge Cloud, you can choose from a wide range of pre-configured virtual machines suitable for Linux:Affordable shared compute resources starting from €3.2 per monthDeploy across 50+ cloud regions with dedicated servers for low-latency applicationsSecure apps and data with DDoS protection, WAF, and encryption at no additional costGet started today

How to Run Hugging Face Spaces on Gcore Inference at the Edge

Running machine learning models, especially large-scale models like GPT 3 or BERT, requires a lot of computing power and comes with a lot of latency. This makes real-time applications resource-intensive and challenging to deliver. Running ML models at the edge is a lightweight approach offering significant advantages for latency, privacy, and resource optimization.  Gcore Inference at the Edge makes it simple to deploy and manage custom models efficiently, giving you the ability to deploy and scale your favorite Hugging Face models globally in just a few clicks. In this guide, we’ll walk you through how easy it is to harness the power of Gcore’s edge AI infrastructure to deploy a Hugging Face Space model. Whether you’re developing NLP solutions or cutting-edge computer vision applications, deploying at the edge has never been simpler—or more powerful. Step 1: Log In to the Gcore Customer PortalGo to gcore.com and log in to the Gcore Customer Portal. If you don’t yet have an account, go ahead and create one—it’s free. Step 2: Go to Inference at the EdgeIn the Gcore Customer Portal, click Inference at the Edge from the left navigation menu. Then click Deploy custom model. Step 3: Choose a Hugging Face ModelOpen huggingface.com and browse the available models. Select the model you want to deploy. Navigate to the corresponding Hugging Face Space for the model. Click on Files in the Space and locate the Docker option. Copy the Docker image link and startup command from Hugging Face Space. Step 4: Deploy the Model on GcoreReturn to the Gcore Customer Portal deployment page and enter the following details: Model image URL: registry.hf.space/ethux-mistral-pixtral-demo:latest Startup command: python app.py Container port: 7860 Configure the pod as follows: GPU-optimized: 1x L40S vCPUs: 16 RAM: 232GiB For optimal performance, choose any available region for routing placement. Name your deployment and click Deploy.Step 5: Interact with Your ModelOnce the model is up and running, you’ll be provided with an endpoint. You can now interact with the model via this endpoint to test and use your deployed model at the edge.Powerful, Simple AI Deployment with GcoreGcore Inference at the Edge is the future of AI deployment, combining the ease of Hugging Face integration with the robust infrastructure needed for real-time, scalable, and global solutions. By leveraging edge computing, you can optimize model performance and simultaneously futureproof your business in a world that increasingly demands fast, secure, and localized AI applications. Deploying models to the edge allows you to capitalize on real-time insights, improve customer experiences, and outpace your competitors. Whether you’re leading a team of developers or spearheading a new AI initiative, Gcore Inference at the Edge offers the tools you need to innovate at the speed of tomorrow. Explore Gcore Inference at the Edge

10 Common Web Performance Mistakes and How to Overcome Them

Web performance mistakes can carry a high price, resulting in websites that yield low conversion rates, high bounce rates, and poor sales. In this article, we dig into the top 10 mistakes you should avoid to boost your website performance.1. Slow or Unreliable Web HostYour site speed begins with your web host, which provides the server infrastructure and resources for your website. This includes the VMs and other infrastructure where your code and media files reside. Three common host-related problems are as follows:Server location: The further away your server is from your users, the slower the site speed and the poorer the experience for your website visitors. (More on this under point 7.)Shared hosting: Shared hosting solutions share server resources among multiple websites, leading to slow load times and spotty connections during peak times due to heavy usage. Shared VMs can also impact your website’s performance due to increased network traffic and resource contention.VPS hosting: Bandwidth limitations can be a significant issue with VPS hosting. A limited bandwidth package can cause your site speed to decrease during high-traffic periods, resulting in a sluggish user experience.Correct for server and VM hosting issues by choosing a provider with servers located closer to your user base and provisioning sufficient computational resources, like Gcore CDN. Use virtual dedicated servers (VDS/VPS) rather than shared hosting to avoid network traffic from other websites affecting your site’s performance. If you already use a VPS, consider upgrading your hosting plan to increase server resources and improve UX. For enterprises, dedicated servers may be more suitable.2. Inefficient Code, Libraries, and FrameworksPoor-quality code and inefficient frameworks can increase the size of web pages, consume too many resources, and slow down page load times. Code quality is often affected by syntax, semantics, and logic errors. Correct these issues by writing clean and simple code.Errors or inefficiencies introduced by developers can impact site performance, such as excessive API calls or memory overuse. Prevent these issues by using TypeScript, console.log, or built-in browser debuggers during development. For bugs in already shipped code, utilize logging and debugging tools like the GNU debugger or WinDbg to identify and resolve problems.Improving code quality also involves minimizing the use of large libraries and frameworks. While frontend frameworks like React, Vue, and Angular.js are popular for accelerating development, they often include extensive JavaScript and prebuilt components that can bloat your website’s codebase. To optimize for speed, carefully analyze your use case to determine if a framework is necessary. If a static page suffices, avoid using a framework altogether. If a framework is needed, select libraries that allow you to link only the required components.3. Unoptimized Code Files and FontsEven high-quality code needs optimization before shipping. Unoptimized JavaScript, HTML, and CSS files can increase page weight and necessitate multiple HTTP requests, especially if JavaScript files are executed individually.To optimize code, two effective techniques are minification and bundling.Minification removes redundant libraries, code, comments, unnecessary characters (e.g., commas and dots), and formatting to reduce your source code’s size. It also shortens variable and function names, further decreasing file size. Tools for minification include UglifyJS for JavaScript, CSSNano for CSS, and HTMLminifier for HTML.Bundling groups multiple files into one, reducing the number of HTTP requests and speeding up site load times. Popular bundling tools include Rollup, Webpack, and Parcel.File compression using GZIP or Brotli can also reduce the weight of HTTP requests and responses before they reach users’ browsers. Enable your chosen compression technique on your server only after checking that your server provider supports it.4. Unoptimized Images and VideosSome websites are slowed down by large media files. Upload only essential media files to your site. For images, compress or resize them using tools like TinyPNG and Compressor.io. Convert images from JPEG, PNG, and GIF to WebP and AVIF formats to maintain quality while reducing file size. This is especially beneficial in industries like e-commerce and travel, where multiple images boost conversion rates. Use dynamic image optimization services like Gcore Image Stack for efficient processing and delivery. For pages with multiple images, use CSS sprites to group them, reducing the number of HTTP requests and speeding up load times.When adding video files, use lite embeds for external links. Standard embed code, like YouTube’s, is heavy and can slow down your pages. Lite embeds load only thumbnail images initially, and the full video loads when users click the thumbnail, improving page speed.5. No Lazy LoadingLazy loading delays the rendering of heavy content like images and JavaScript files until the user needs it, contrasting with “eager” loading, which loads everything at once and slows down site load times. Even with optimized images and code, lazy loading can further enhance site speed through a process called “timing.”Image timing uses the HTML loading attribute in an image tag or frameworks like Angular or React to load images in response to user actions. The browser only requests images when the user interacts with specific features, triggering the download.JavaScript timing controls when certain code loads. If JavaScript doesn’t need to run until the entire page has rendered, use the defer attribute to delay its execution. If JavaScript can load at any time without affecting functionality, load it asynchronously with the async attribute.6. Heavy or Redundant External Widgets and PluginsWidgets and plugins are placed in designated frontend and backend locations to extend website functionality. Examples include Google review widgets that publish product reviews on your website and Facebook plugins that connect your website to your Facebook Page. As your website evolves, more plugins are typically installed, and sometimes website admins forget to remove those that are no longer required.Over time, heavy and unused plugins can consume substantial resources, slowing down your website unnecessarily. Widgets may also contain heavy HTML, CSS, or JavaScript files that hinder web performance.Remove unnecessary plugins and widgets, particularly those that make cURL calls, HTTP requests, or generate excessive database queries. Avoid plugins that load heavy scripts and styles or come from unreliable sources, as they may contain malicious code and degrade website performance.7. Network IssuesYour server’s physical location significantly impacts site speed for end users. For example, if your server is in the UK and your users are in China, they’ll experience high latency due to the distance and DNS resolution time. The greater the distance between the server and the user, the more network hops are required, increasing latency and slowing down site load times.DNS resolution plays a crucial role in this process. Your authoritative DNS provider resolves your domain name to your IP address. If the provider’s server is too far from the user, DNS resolution will be slow, giving visitors a poor first impression.To optimize content delivery and reduce latency, consider integrating a content delivery network (CDN) with your server-side code. A CDN stores copies of your static assets (e.g., container images, JavaScript, CSS, and HTML files) on geographically distributed servers. This distribution ensures that users can access your content from a server closer to their location, significantly improving site speed and performance.8. No CachingWithout caching, your website has to fetch data from the origin server every time a user requests. This increases the load time because the origin server is another physical hop that data has to travel.Caching helps solve this problem by serving pre-saved copies of your website. Copies of your web files are stored on distributed CDN servers, meaning they’re available physically closer to website viewers, resulting in quicker load times.An additional type of caching, DNS caching, temporarily stores DNS records in DNS resolvers. This allows for faster domain name resolution and accelerates the initial connection to a website.9. Excessive RedirectsWebsite redirects send users from one URL to another, often resulting in increased HTTP requests to servers. These additional requests can potentially crash servers or cause resource consumption issues. To prevent this, use tools like Screaming Frog to scan your website for redirects and reduce them to only those that are absolutely necessary. Additionally, limit each redirect to making no more than one request for a .css file and one for a .js file.10. Lack of Mobile OptimizationForgetting to optimize for mobile can harm your website’s performance. Mobile-first websites optimize for speed and UX. Better UX leads to happier customers and increased sales.Optimizing for mobile starts with understanding the CPU, bandwidth, and memory limitations of mobile devices compared to desktops. Sites with excessively heavy files will load slowly on mobiles. Writing mobile-first code, using mobile devices or emulators for building and testing, and enhancing UX for various mobile device types—such as those with larger screens or higher capacity—can go a long way to optimizing for mobile.How Can Gcore Help Prevent These Web Performance Mistakes?If you’re unsure where to start in correcting or preventing web performance mistakes, don’t worry—you don’t have to do it alone. Gcore offers a comprehensive suite of solutions designed to enhance your web performance and deliver the best user experience for your visitors:Powerful VMs: Fast web hosting with a wide range of virtual machines.Managed DNS: Hosting your DNS zones and ensuring quick DNS resolution with our fast Managed DNS.CDN: Accelerate both static and dynamic components of your website for global audiences.With robust infrastructure from Gcore, you can ensure optimal performance and a seamless experience for all your web visitors. Keep your website infrastructure in one place for a simplified website management experience.Need help getting started? Contact us for a personalized consultation and discover how Gcore can supercharge your website performance.Get in touch to boost your website

How to Choose Between Bare Metal GPUs and Virtual GPUs for AI Workloads

Choosing the right GPU type for your AI project can make a huge difference in cost and business outcomes. The first consideration is often whether you need a bare metal or virtual GPU. With a bare metal GPU, you get a physical server with an entire GPU chip (or chips) installed that is completely dedicated to the workloads you run on the server, whereas a virtual GPU means you share GPU resources with other virtual machines.Read on to discover the key differences between bare metal GPUs and virtual GPUs, including performance and scalability, to help you make an informed decision.The Difference Between Bare Metal and Virtual GPUsThe main difference between bare metal GPUs and virtual GPUs is how they use physical GPU resources. With a bare metal GPU, you get a physical server with an entire GPU chip (or chips) installed that is completely dedicated to the workloads you run on the server. There is no hypervisor layer between the operating system (OS) and the hardware, so applications use the GPU resources directly.With a virtual GPU, you get a virtual machine (VM) and uses one of two types of GPU virtualization, depending on your or a cloud provider’s capabilities:An entire, dedicated GPU used by a VM, also known as a passthrough GPUA shared GPU used by multiple VMs, also known as a vGPUAlthough a passthrough GPU VM gets the entire GPU, applications access it through the layers of a guest OS and hypervisor. Also, unlike a bare metal GPU instance, other critical VM resources that applications use, such as RAM, storage, and networking, are also virtualized.The difference between running applications with bare metal and virtual GPUsThese architectural features affect the following key aspects:Performance and latency: Applications running on a VM with a virtual GPU, especially vGPU, will have lower processing power and higher latency for the same GPU characteristics than those running on bare metal with a physical GPU.Cost: As a result of the above, bare metal GPUs are more expensive than virtual GPUs.Scalability: Virtual GPUs are easier to scale than bare metal GPUs because scaling the latter requires a new physical server. In contrast, a new GPU instance can be provisioned in the cloud in minutes or even seconds.Control over GPU hardware: This can be critical for certain configurations and optimizations. For example, when training massive deep learning models with a billion parameters, total control means the ability to optimize performance optimization—and that can have a big impact on training efficiency for massive datasets.Resource utilization: GPU virtualization can lead to underutilization if the tasks being performed don’t need the full power of the GPU, resulting in wasted resources.Below is a table summarizing the benefits and drawbacks of each approach: Bare metal GPUVirtual GPUPassthrough GPUvGPUBenefitsDedicated GPU resourcesHigh performance for demanding AI workloadsLower costSimple scalabilitySuitable for occasional or variable workloadsLowest costSimple scalabilitySuitable for occasional or variable workloadsDrawbacksHigh cost compared to virtual GPUsLess flexible and scalable than virtual GPUsLow performanceNot suitable for demanding AI workloadsLowest performanceNot suitable for demanding AI workloadsShould You Use Bare Metal or Virtual GPUs?Bare metal GPUs and virtual GPUs are typically used for different types of workloads. Your choice will depend on what AI tasks you’re looking to perform.Bare metal GPUs are better suited for compute-intensive AI workloads that require maximum performance and speed, such as training large language models. They are also a good choice for workloads that must run 24/7 without interruption, such as some production AI inference services. Finally, bare metal GPUs are preferred for real-time AI tasks, such as robotic surgery or high-frequency trading analytics.Virtual GPUs are a more suitable choice for the early stages of AI/ML and iteration on AI models, where flexibility and cost-effectiveness are more important than top performance. Workloads with variable or unpredictable resource requirements can also run on this type of GPU, such as training and fine-tuning small models or AI inference tasks that are not sensitive to latency and performance. Virtual GPUs are also great for occasional, short-term, and collaborative AI/ML projects that don’t require dedicated hardware—for example, an academic collaboration that includes multiple institutions.To choose the right type of GPU, consider these three factors:Performance requirements. Is the raw GPU speed critical for your AI workloads? If so, bare metal GPUs are a superior choice.Scalability and flexibility. Do you need GPUs that can easily scale up and down to handle dynamic workloads? If yes, opt for virtual GPUs.Budget. Depending on the cloud provider, bare metal GPU servers can be more expensive than virtual GPU instances. Virtual GPUs typically offer more flexible pricing, which may be appropriate for occasional or variable workloads.Your final choice between bare metal GPUs and virtual GPUs depends on the specific requirements of the AI/ML project, including performance needs, scalability requirements, workload types, and budget constraints. Evaluating these factors can help determine the most appropriate GPU option.Choose Gcore for Best-in-Class AI GPUsGcore offers bare metal servers with NVIDIA H100, A100, and L40S GPUs. Using the 3.2 Tbps InfiniBand interface, you can combine H100 or A100 servers into scalable GPU clusters for training and tuning massive ML models or for high-performance computing (HPC).If you are looking for a scalable and low-latency solution for global AI inference, explore Gcore Inference at the Edge. It especially benefits latency-sensitive, real-time applications, such as generative AI and object recognition.Discover Gcore bare metal GPUs

How to Configure Grafana for Visualizing Kubernetes (K8s) Cluster Monitoring

Kubernetes monitoring allows you to observe your workloads and cluster resources, spot issues and failures, and efficiently manage pods and other resources. Cluster admins should prioritize tracking the performance and stability of clusters in these environments. One popular tool that can help you visualize Kubernetes monitoring is Grafana. This monitoring solution lets you display K8s metrics through interactive dashboards and real-time alerts. It seamlessly integrates with Prometheus and other data sources, providing valuable insights.Gcore Managed Kubernetes simplifies the Grafana setup process by providing a managed service that includes tools like Grafana. In this article, we’ll explain how to set up and configure Grafana to monitor Kubernetes, its key metrics, and dashboards.Setting Up Grafana for Effective Kubernetes MonitoringTo begin monitoring Kubernetes with Grafana, first, check that you have all the requirements in place: a functioning Kubernetes cluster, the Helm package manager installed, and kubectl set up to communicate with your cluster.Install Grafana in a Kubernetes Cluster. Start by adding the Grafana Helm repository.helm repo add grafana https://grafana.github.io/helm-chartshelm repo updateNext, install Grafana using Helm. This command deploys Grafana into your Kubernetes cluster:helm install grafana grafana/grafanaNow it’s time to configure Grafana for the Kubernetes environment. After installation, retrieve the admin password by using the command below:kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echoThen access the Grafana UI by port-forwarding:kubectl port-forward svc/grafana 3000:80Open your web browser and navigate to http://localhost:3000. Log in using the default username admin and the password you retrieved. Once logged in, you can configure Grafana to monitor your Kubernetes environment by adding data sources such as Prometheus and creating custom dashboards.You’ve now successfully set up Grafana for Kubernetes monitoring!Key Metrics for Kubernetes MonitoringUnderstanding metrics for Kubernetes monitoring allows you to visualize your cluster’s reliability. Key metrics are the following:Node resources. Track CPU and memory usage, disk utilization, and network bandwidth to understand resource consumption and identify bottlenecks.Cluster metrics. Monitor the number of nodes to understand resource billing and overall cluster usage, and track running pods to determine node capacity and identify failures.Pod metrics. Measure how pods are managed and deployed, including instances and deployment status, and monitor container metrics like CPU, memory, and network usage.State metrics. Keep an eye on persistent volumes, disk pressure, crash loops, and job success rates to ensure proper resource management and application stability.Container metrics. Track container CPU and memory usage relative to pod limits, and monitor network data to detect bandwidth issues.Application metrics. Measure application availability, performance, and business-specific metrics to maintain optimal user experience and operational health.Setting Up Grafana DashboardsYou can opt to design and tailor Grafana dashboards to monitor your Kubernetes cluster. This will help you better understand your systems’ performance and overall well-being at a glance.Log into Grafana. Open your web browser, go to http://localhost:3000/, and log in with the default credentials (admin for both username and password), then change your password if/when prompted.Grafana—Log In to Start MonitoringAdd data source. Navigate to Configuration and select Data Sources. Click on Add Data Source and choose the appropriate data source, such as Prometheus.Create a dashboard. Go to Create > Dashboard, click Add New Panel, choose the panel type (e.g., Time series chart, Gauge, Table), and configure it with a PromQL query and visualization settings.Adding a New Panel in Grafana DashboardOrganize and save the dashboard. Arrange panels by clicking Add Panel > Add Row and dragging panels into the desired rows. To save the dashboard, click the save icon, name it, and confirm the save.Gcore Managed Kubernetes for Kubernetes MonitoringWhether you’re getting started with monitoring Kubernetes or you’re a seasoned pro, Gcore Managed Kubernetes offers significant advantages for businesses seeking efficient and reliable Kubernetes cluster monitoring and container management:Ease of integrating Grafana: The service seamlessly integrates with Grafana, enabling effortless visualization and monitoring of performance metrics via dashboards.Automated control: Gcore Managed Kubernetes simplifies the setup and monitoring process by using automation. This service conducts health checks on your nodes, automatically updating and restarting them when needed to keep performance at its best.Enhanced security and reliability: Gcore Managed Kubernetes guarantees the management of nodes by integrating features like automatic scaling and self-repairing systems to maintain optimal performance.Discover Gcore Managed Kubernetes, including automated scaling, one-click provisioning, and Grafana integration.

TCO Comparison: Self-Managed Kubernetes vs. Managed Kubernetes Provider

Calculating the total cost of ownership (TCO) for Kubernetes requires identifying all major expenses, including infrastructure costs, personnel costs, and potential cloud provider fees. With a clear picture of TCO, you can make a more informed decision when choosing between self-managed (self-hosted) Kubernetes and a managed Kubernetes provider. The TCOs of the two approaches are significantly different, and this article will show you exactly how and why.TCO Comparison SummaryThe table below shows the key aspects of the TCO comparison between self-managed Kubernetes and managed Kubernetes providers. It compares infrastructure expenses, including provider fees, and an engineer’s salary.For this comparison, we’ll assume that a company would need only one DevOps engineer for managed Kubernetes, whereas companies opting for self-hosted Kubernetes would need three. We’ll look at rented cloud VMs for self-hosted, and out-of-the-box K8s clusters for managed Kubernetes—two standard scenarios for a fair comparison. For both scenarios, the infrastructure costs shown in the table are the average when considering AWS, Azure, Google Cloud, and Gcore. InfrastructureEngineers’ salaryTotal annual costSelf-hosted Kubernetes$13,737.64$321,500$335,238Managed Kubernetes$6,157.8$107,167$113,325As you can see, the TCO of self-hosted Kubernetes is almost three times higher than that of managed Kubernetes. Let’s explore the reasons for this major cost discrepancy.Infrastructure Cost ComparisonKubernetes is a free software. But to run it, you have to rent or buy infrastructure, such as VMs or physical servers. The way you do so differs depending on whether you opt for self-hosted or managed Kubernetes. To understand infrastructure costs, we need to take a closer look at each method in turn and explore the components required.Self-hosted KubernetesIf you choose to run K8s independently, you’ll need to rent VMs for the Kubernetes master node (the control plane) and worker nodes. Let’s consider a production-grade cluster consisting of the following:3 VMs for the control plane, required for fault tolerance2 VMs for the worker nodesFor simplicity, we choose VMs with a configuration suitable for an average web project: 8 vCPU, 16 GB RAM, and 75 GB SSD.Here is the pricing* offered by four cloud providers for VMs available in the US:ProviderVM types and resourcesTotal annual cost of five VMsAWSc6g.2xlarge—8 vCPU, 16 GB RAM, 75 GB SSD$12,273.6AzureA8 v2 series—8 vCPU, 16 GB RAM, 64 GB SSD**$17,764.2Google CloudN1 series—8 vCPU, 16 GB RAM, 75 GB SSD$16,721.33Gcoreg1 standard series—8 vCPU, 16 GB RAM, 75 GB SSD$8,191.42Average$13,737.64* Prices are for on-demand VMs; no commitment; no VAT; ingress traffic is not included.** Azure only offers fixed volume sizes for built-in storage.Managed KubernetesWith managed K8s, you don’t have to worry about renting separate VMs and setting up the Kubernetes software. You choose the VM configurations for your worker nodes, and a provider prepares them for you. The result is an out-of-the-box Kubernetes cluster.Sometimes, you also have to consider fees for control plane management (fixed) and egress traffic (consumption-based). Providers like AWS, Google Cloud, and Azure charge for this, while others—like Gcore—don’t.Here are the prices* offered by four cloud providers for similar cluster configurations in the US:ProviderControl plane managementCluster of two worker nodesTotal annual costConfigurationAnnual costAmazon EKS$8768 vCPU, 16 GB RAM, 75 GB SSD$4,909.44$5,785.44AKS (Azure)$8768 vCPU, 16 GB RAM, 64 GB SSD**$7,048.08$7,924.08GKE (Google)$876X vCPUs, X GB RAM$6,832.08$7,708.08Gcore Managed Kubernetes08 vCPU, 16 GB RAM, 75 GB SSD$3,213.6$3,213.6Average$6,157.8* Prices are for on-demand VMs; no commitment; no VAT; ingress traffic is not included.** Azure only offers fixed volume sizes for built-in storage.Engineer Cost ComparisonTo maintain a production-grade cluster for an average web project, you need:For a self-hosted K8s cluster—3 DevOps engineersFor a managed K8s cluster—1 DevOps engineerTo learn more about the technical reasons behind these calculations, read our article on the difference between managed and self-managed Kubernetes.According to Glassdoor, the median salary for a DevOps engineer is as follows:In the US: $140,000In Germany: €69,000 (or $74,333, the highest in Europe) DevOps salary in the USDevOps salary in GermanyAverage annual salarySelf-hosted Kubernetes (3 engineers)$420,000$222,999$321,500Managed Kubernetes (1 engineer)$140,000$74,333$107,167Final ComparisonHere is the final TCO comparison between self-managed Kubernetes and managed Kubernetes providers:ProvidersInfrastructureEngineers’ salaryTotal annual costBy providerAverageSelf-hosted KubernetesAWS$12,273.6$13,737.64$321,500$335,238Azure$17,764.2GCP$16,721.33Gcore$8,191.42Managed KubernetesAmazon EKS$5,785.44$6,157.8$107,167$113,325AKS (Azure)$7,924.08GKE (Google)$7,708.08Gcore Managed Kubernetes$3,213,6Summing UpPlease note that these approximate calculation probably aren’t exactly what you’ll experience. The actual numbers will depend on many factors, including:Size and complexity of your projectLocation where you hire engineers and deploy a K8s clusterChoice of providerHow you consume and scale computing resourcesHowever, the difference between the TCO of the two methods is relevant to what we got above: the total cost of ownership of self-managed Kubernetes is about three times higher than that of managed Kubernetes.The main reason is that Managed Kubernetes means a provider handles many of the most complex operations. This includes managing the underlying infrastructure and control plane, regular and security upgrades, monitoring, scaling the cluster, and, critical to production, high availability guaranteed by an SLA. With self-hosted K8s, you have to do that yourself, which means a larger infrastructure, larger team size, and higher salary costs.ConclusionUnderstanding the TCO difference between self-managed Kubernetes and a managed Kubernetes provider can help you choose a solution that is more suitable for your team and meets your budget. Kubernetes cost analysis can also help you identify areas for optimization, such as right-sizing your infrastructure or optimizing workloads for better resource utilization. However, the TCO isn’t the only aspect of choosing how to run Kubernetes: you should also consider things like the setup and maintenance responsibilities, as well as your project requirements.If you’re looking for reliable, high-performance, and scalable Kubernetes clusters, try Gcore Managed Kubernetes. We offer free cluster management with a 99.9% SLA, bare metal and GPU support for worker nodes, and free egress traffic.Explore Gcore Managed Kubernetes

Subscribe
to our newsletter

Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.