🥇Construire notre propre serverless basé sur Fn

Construisons notre propre serverless basé sur Fn

Calculs sans serveur — l'une des tendances les plus remarquables dans le cloud computing. Le principe de fonctionnement repose sur le fait que l'infrastructure est une préoccupation non pas des DevOps, mais du fournisseur de services. La montée en charge des ressources s'ajuste automatiquement à la demande et offre une grande rapidité de changement.

Une autre caractéristique commune est la tendance à la minimisation et à la concentration du code, c'est pourquoi le calcul sans serveur est parfois appelé « fonction comme service » (FaaS).

Historiquement, le premier fournisseur de services cloud à proposer le FaaS avec AWS Lambda était Amazon, d'où vient ce nom. D'autres fournisseurs de cloud proposent également des analogues :

Cloud Functions de Google
Azure Functions de Microsoft

Toutes ces entreprises fournissent des calculs sans serveur, une montée en charge automatique et ne facturent que les ressources effectivement utilisées, tout en liant les clients à leur produit propriétaire. Cependant, il existe des alternatives gratuites et open source pour organiser des calculs sans serveur. À noter :

La plateforme Apache OpenWhisk, développée dans l'incubateur par IBM,
Spring Cloud Functions, comme partie d'un écosystème assez riche du Spring Framework, qui peut également être utilisé comme façade pour AWS Lambda, Azure Functions et OpenWhisk,
Le projet Fn, soutenu par Oracle.

Tous sont complètement indépendants du cloud, c'est-à-dire qu'ils peuvent être installés dans n'importe quel cloud, y compris le vôtre, public ou privé, et bien sûr dans Exoscale.

Comment le projet Fn est structuré

Fn est entièrement construit sur Docker, composé de deux composants principaux :

Une interface en ligne de commande (CLI) conçue pour gérer tous les aspects de l'infrastructure Fn et interagir avec le serveur Fn,
Le serveur Fn lui-même, une application classique emballée dans un conteneur Docker.

Les fonctions déployées dans Fn s'exécutent également dans des conteneurs séparés, ce qui permet de supporter de nombreux langages de programmation, par exemple… Clojure !

Les arguments des fonctions sont transmis via l'entrée standard (STDIN), et les résultats sont écrits sur la sortie standard (STDOUT). Si les arguments ou les valeurs retournées ne sont pas des valeurs simples (par exemple, un objet JSON), ils peuvent être transformés à l'aide de la couche d'abstraction fournie par Fn sous la forme d'un kit de développement de fonctions (FDK).

Pour plus de commodité, des ensembles de modèles intégrés sont proposés, facilitant le déploiement de FaaS sur une large liste de langages différents et leurs versions (Go, plusieurs versions de Java, Python, etc.).

Créer un FaaS est simple, en suivant ce schéma :

Nous déployons la fonction à l'aide de la CLI Fn : un fichier de configuration d'application pour Fn est créé, basé sur le modèle choisi.
Nous déployons notre propre fonction, encore une fois avec la CLI Fn : l'image du conteneur est placée dans un certain dépôt, après quoi le serveur est informé de l'existence et de l'emplacement de cette image.

Construisons notre propre serverless basé sur Fn
Le principe de livraison des fonctions dans Fn

Installation locale et test des fonctions serverless

Commençons par installer Fn sur la machine locale. D'abord, Docker est installé, comme l'exige Fn. On suppose que nous sommes sous Debian/Ubuntu :

$ sudo apt-get update
$ sudo apt-get install docker.io

Ou utilisez le gestionnaire de paquets ou la version de Docker appropriée pour votre système. Ensuite, nous pouvons passer directement à l'installation de la CLI Fn. Par exemple, avec curl :

$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh

Si vous travaillez sur OSX avec Homebrew installé, vous pouvez prendre une autre voie :

$ brew install fn

==> Downloading https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb
######################################################################## 100.0%
==> Pouring fn-0.5.8.high_sierra.bottle.tar.gz
  /usr/local/Cellar/fn/0.5.8: 5 files, 16.7MB

Tout est maintenant prêt pour le déploiement initial de notre fonction en utilisant la CLI. Pour simplifier, nous allons utiliser l'environnement intégré, par exemple Node :

$ fn init --runtime node --trigger http hellonode

Création de la fonction à : /hellonode
Modèle de fonction généré.
func.yaml créé.

Un nouveau répertoire sera créé hellonode pour le développement ultérieur de notre fonction Fn avec quelques fichiers de configuration essentiels. À l'intérieur du répertoire nouvellement créé, vous pouvez créer votre application en respectant les normes du langage ou de l'environnement d'exécution que vous avez choisi :

# Каталог с node выглядит так:

   hellonode
   ├── func.js
   ├── func.yaml
   └── package.json

# Свежеустановленное окружение Java11 такое:

   hellojava11
   ├── func.yaml
   ├── pom.xml
   └── src
       ├── main
       │   └── java
       │       └── com
       │           └── example
       │               └── fn
       │                   └── HelloFunction.java
       └── test
           └── java
               └── com
                   └── example
                       └── fn
                           └── HelloFunctionTest.java

Fn crée la structure initiale du projet, crée le fichier func.yaml, contenant les configurations nécessaires pour Fn, et met en place un modèle pour le code dans le langage que vous avez choisi.

Dans le cas de l'environnement d'exécution Node, cela signifie :

$ cat hellonode/func.js

const fdk=require('@fnproject/fdk');

fdk.handle(function(input){
  let name = 'World';
  if (input.name) {
    name = input.name;
  }
  return {'message': 'Hello ' + name}
})

Nous allons maintenant tester rapidement notre fonction localement pour voir comment tout fonctionne.

Pour commencer, nous allons lancer le serveur Fn. Comme déjà mentionné, le serveur Fn est un conteneur Docker, donc une fois lancé, il ira chercher l'image dans le registre Docker.

$ fn start -d                    # lance le serveur local en arrière-plan

Impossible de trouver l'image 'fnproject/fnserver:latest' localement
latest : Récupération depuis fnproject/fnserver
ff3a5c916c92 : Téléchargement complet
1a649ea86bca : Téléchargement complet
ce35f4d5f86a : Téléchargement complet

...

Statut : Image plus récente téléchargée pour fnproject/fnserver:latest
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5

Pour déployer notre fonction, elle doit être « publiée ». Cela nécessite le nom de l'application: dans Fn, toutes les applications doivent être définies sous forme d'espaces de noms pour les fonctions associées.

Le CLI Fn cherchera le fichier func.yaml dans le répertoire actuel, qui sera utilisé pour configurer la fonction. Donc, il faut d'abord accéder à notre répertoire hellonode.

$ cd hellonode
$ fn deploy --app fnexo --local  # publie la fonction localement, le nom de l'application est fnexo.
                                 # Le paramètre local ne télécharge pas l'image dans le registre distant,
                                 # l'exécutant directement

Déploiement de hellonode vers l'application : fnexo
Version augmentée à 0.0.2
Construction de l'image nfrankel/hellonode:0.0.3 .
Mise à jour de la fonction hellonode en utilisant l'image nfrankel/hellonode:0.0.3...
Application créée avec succès :  fnexo
Fonction créée avec succès : hellonode avec nfrankel/hellonode:0.0.3
Déclencheur créé avec succès : hellonode-trigger

Comme on peut le voir dans la sortie de la commande, une nouvelle image de conteneur Docker est créée, contenant notre fonction. La fonction est prête à être appelée, et nous avons deux moyens de le faire :

en utilisant la commande Fn invoke
en l'appelant directement via http

de system-nspawn invoke via Fn, cela émule simplement le fonctionnement par HTTP pour des tests, ce qui est pratique pour une vérification rapide :

$ fn invoke fnexo hellonode      # appelle la fonction hellonode de l'application fnexo

{"message":"Hello World"}

Pour appeler la fonction directement, il faut connaître l'URL complète :

$ curl http://localhost:8080/t/fnexo/hellonode-trigger

{"message":"Hello World"}

Le serveur Fn fournit ses fonctions via le port 8080, et il semble que l'URL de la fonction suive le schéma t/app/function, mais pas complètement. Par HTTP, la fonction n'est pas appelée directement, mais via ce qu'on appelle un déclencheur, qui, comme son nom l'indique, « déclenche » l'appel de la fonction. Les déclencheurs sont définis dans `func.yml le projet :

schema_version: 20180708
name: hellonode
version: 0.0.3
runtime: node
entrypoint: node func.js
format: json
triggers:
- name: hellonode-trigger
  type: http
  source: /hellonode-trigger    # URL du déclencheur

Nous pouvons changer le nom du déclencheur pour qu'il corresponde au nom de la fonction, cela simplifiera tout :

triggers:
- name: hellonode-trigger
  type: http
  source: /hellonode    # correspond au nom de la fonction

Ensuite, nous relançons le déploiement de la fonction et l'appelons depuis le nouveau déclencheur :

$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode

{"message":"Bonjour le monde"}

Tout fonctionne ! Il est temps de passer aux expériences pratiques et de publier notre FaaS sur le serveur !

Installation des services de fonctions sans serveur sur votre propre infrastructure

Installer rapidement une machine virtuelle en utilisant l'interface en ligne de commande Exoscale. Si vous ne l'avez pas encore configurée, vous pouvez consulter notre guide pour un démarrage rapide. C'est un excellent outil qui augmentera encore votre productivité. N'oubliez pas de configurer une règle pour ouvrir le port 8080 dans le groupe de sécurité ! Les commandes suivantes lanceront une machine virtuelle propre, prête à héberger nos fonctions :

$ exo firewall create fn-securitygroup
$ exo firewall add fn-securitygroup ssh --my-ip
$ exo firewall add fn-securitygroup -p tcp -P 8080-8080 -c 0.0.0.0/0
$ exo vm create fn-server -s fn-securitygroup

Ensuite, vous pouvez vous connecter via ssh à la machine virtuelle et installer le serveur Fn :

$ exo ssh fn-server

L'authenticité de l'hôte '185.19.30.175 (185.19.30.175)' ne peut pas être confirmée.
L'empreinte de clé ECDSA est SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Êtes-vous sûr de vouloir continuer à vous connecter (oui/non) ? oui
Avertissement : '185.19.30.175' (ECDSA) ajouté de façon permanente à la liste des hôtes connus.
Bienvenue dans Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)

Ensuite, nous installons Docker et le serveur Fn de la même manière que sur la machine locale, puis nous démarrons le serveur :

$ sudo apt-get update
$ sudo apt-get install docker.io
$ sudo systemctl start docker
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
$ sudo fn start

...

    ______
   / ____/___
  / /_  / __ 
 / __/ / / / / /
/_/   /_/ /_/
    v0.3.643

Fn est prêt à recevoir des fonctions ! Pour transmettre des fonctions au serveur distant, nous allons utiliser la commande deploy depuis l'ordinateur local, en omettant le drapeau --local.

De plus, Fn nécessite que vous spécifiiez l'emplacement du serveur Fn et du registre Docker. Ces paramètres peuvent être définis via des variables d'environnement FN_API_URL et FN_REGISTRY respectivement, mais une méthode encore plus pratique est proposée pour gérer facilement la création et la gestion des configurations de déploiement.

En termes de Fn, la configuration pour le déploiement est appelée context. La commande suivante créera un contexte :

$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel

Vous pouvez afficher les contextes disponibles de cette manière :

$ fn list contexts

CURRENT NAME      PROVIDER      API URL                      REGISTRY
    default       default       http://localhost:8080/
    exoscale      default       http://185.19.30.175:8080    nfrankel

Et pour passer au contexte qui vient d'être créé, faites ainsi :

 $ fn use context exoscale

 Maintenant en utilisant le contexte : exoscale

À partir de cet endroit, la livraison des fonctions Fn commencera à charger des images Docker en utilisant le compte choisi sur DockerHub (dans mon cas — nfrankel), puis notifiera le serveur distant (dans cet exemple — http://185.19.30.175:8080) de l'emplacement et de la version de la dernière image contenant votre fonction.

$ fn deploy --app fnexo .   # s'exécute sur la machine locale depuis le répertoire hellonode

Déploiement de la fonction à : /.
Déploiement de hellonode dans l'application : fnexo
Version mise à jour 0.0.5
Construction de l'image nfrankel/hellonode:0.0.5 .

Enfin :

$ curl http://185.19.30.175:8080/t/fnexo/hellonode

{"message":"Hello World"}

Construisons notre propre serverless basé sur Fn
Cycle de vie de la fonction dans le calcul sans serveur basé sur Fn

Avantages du calcul sans serveur sur vos propres infrastructures

Le calcul sans serveur est une solution pratique pour introduire rapidement des parties indépendantes d'une application, interagissant avec des applications plus complexes ou des microservices.

Cela est souvent lié au coût caché d'un engagement envers un fournisseur choisi, ce qui, selon le cas d'utilisation spécifique et l'échelle, peut entraîner des coûts plus élevés et une diminution de la flexibilité à l'avenir.

Les architectures multi-cloud et hybrides souffrent également dans ce cas, car il est facile de se retrouver dans une situation où l'on souhaiterait utiliser le calcul sans serveur, mais en raison de la politique d'entreprise, cela peut être impossible.

Fn est suffisamment simple à utiliser, il peut offrir presque la même interface FaaS, avec peu de frais. Il libère de tout engagement vis-à-vis d'un fournisseur, pouvant être installé localement ou chez n'importe quel fournisseur de solutions cloud de votre choix. De plus, il offre la liberté de choisir le langage de programmation.

L'article présente seulement les bases de Fn, mais créer votre propre environnement d'exécution est assez simple, et l'architecture globale peut être étendue en utilisant un répartiteur de charge Fn, ou en plaçant Fn derrière un proxy pour protection.

Source : habr.com