L'informatique sans serveur est l'une des tendances les plus visibles du cloud computing. Le principe de base du travail est que l'infrastructure n'est pas l'affaire de DevOps, mais du prestataire de services. La mise à l'échelle des ressources s'adapte automatiquement à la charge et a un taux de changement élevé.
Une autre caractéristique commune est la tendance à minimiser et à concentrer le code, c'est pourquoi l'informatique sans serveur est parfois appelée «fonction en tant que service» (FaaS).
Historiquement, le premier fournisseur de services cloud Ă proposer FaaS avec AWS Lambda Ă©tait Amazon, d'oĂą le nom vient. D'autres fournisseurs de services cloud proposent Ă©galement des analogues:
- Fonctions Google Cloud
- Fonctions Azure de Microsoft
Toutes ces sociétés fournissent de l'informatique sans serveur, une mise à l'échelle automatique et ne paient que pour les ressources réellement utilisées, mais en même temps, elles lient les clients à leur produit propriétaire. Cependant, il existe des alternatives open source gratuites pour l'informatique sans serveur. Il convient de noter:
Tous sont complètement indépendants des clouds, c'est-à -dire qu'ils sont installés dans n'importe quel cloud, y compris le vôtre, public ou privé, et bien sûr dans Exoscale.
Fonctionnement du projet Fn
Fn est entièrement basé sur Docker, se compose de deux composants principaux:
- Programme CLI conçu pour gérer tous les aspects de l'infrastructure Fn et interagir avec le serveur Fn,
- En fait, le serveur Fn, l'application habituelle emballée dans un conteneur pour Docker.
Les fonctions déployées dans Fn sont également exécutées dans des conteneurs séparés, ce qui vous permet de prendre en charge de nombreux langages de programmation, par exemple ... Clojure!
Les arguments des fonctions sont transférés sur l'entrée standard (STDIN), les résultats sont écrits sur la sortie standard (STDOUT). Si les arguments ou les valeurs de retour ne sont pas des valeurs simples (par exemple, un objet JSON), ils peuvent être convertis à l'aide de la couche d'abstraction fournie par Fn lui-même en tant que kit de développement de fonction (FDK).
Pour plus de commodité, des modèles intégrés sont disponibles pour faciliter le déploiement de FaaS dans une liste complète de différentes langues et de leurs versions (Go, différentes versions de Java, Python, etc.).
La création de FaaS est facile en suivant ce modèle:
- 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 sélectionné.
- Nous déployons notre propre fonction, toujours en utilisant la CLI Fn: l'image du conteneur est placée dans un certain référentiel, après quoi le serveur est informé de l'existence et du placement de cette image.
Principe de livraison des fonctions en Fn
Installation locale et test de fonctions sans serveur
Nous procédons à l'installation de Fn sur la machine locale. Docker est installé en premier, comme l'exige Fn. Nous sommes censés être sur Debian / Ubuntu:
$ sudo apt-get update $ sudo apt-get install docker.io
Eh bien, ou utilisez le gestionnaire de packages / build Docker en fonction de votre système. Ensuite, vous pouvez accéder directement à l'installation de la CLI Fn. Par exemple, en utilisant curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
Si vous exécutez OSX avec Homebrew installé, vous pouvez aller dans l'autre sens:
$ 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
Maintenant, tout est prêt pour le déploiement initial de notre fonction à l'aide de la CLI. Par souci de simplicité, nous utiliserons l'environnement intégré pour exécuter, par exemple, Node:
$ fn init --runtime node --trigger http hellonode Creating function at: /hellonode Function boilerplate generated. func.yaml created.
Un nouveau répertoire hellonode sera créé pour développer davantage notre fonction Fn avec quelques fichiers de configuration de base. Dans le répertoire nouvellement créé, vous pouvez créer votre application qui respecte les normes de la langue ou du runtime 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 de projet initiale, crée un fichier func.yaml contenant les paramètres nécessaires pour Fn et installe un modèle pour le code dans la langue que vous avez sélectionnée.
Dans le cas de l'exécution du nœud, 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 vérifier rapidement notre fonction localement pour voir comment tout fonctionne.
Tout d'abord, nous allons démarrer le serveur Fn. Comme déjà mentionné, le serveur Fn est un conteneur Docker, donc, après le démarrage, il ira prendre l'image dans le registre Docker.
$ fn start -d # Unable to find image 'fnproject/fnserver:latest' locally latest: Pulling from fnproject/fnserver ff3a5c916c92: Pull complete 1a649ea86bca: Pull complete ce35f4d5f86a: Pull complete ... Status: Downloaded newer image for fnproject/fnserver:latest 668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5
Pour exécuter notre fonction, vous devez la déployer. Cela nécessite un
La CLI Fn recherchera le fichier func.yaml dans le répertoire courant, qui sera utilisé pour configurer la fonction. Vous devez donc d'abord aller dans notre répertoire hellonode .
$ cd hellonode $ fn deploy --app fnexo --local # , - fnexo. # local , # Deploying hellonode to app: fnexo Bumped to version 0.0.2 Building image nfrankel/hellonode:0.0.3 . Updating function hellonode using image nfrankel/hellonode:0.0.3... Successfully created app: fnexo Successfully created function: hellonode with nfrankel/hellonode:0.0.3 Successfully created trigger: hellonode-trigger
Comme vous pouvez le voir sur la sortie de la commande, une nouvelle image de conteneur pour Docker est créée qui contient notre fonction. La fonction est prête à être appelée, et nous avons deux façons de procéder:
- Ă l'aide de la commande fn
invoke - appeler directement via
http
L'appel d' invoke via Fn émule simplement le travail HTTP pour les tests, ce qui est pratique pour une vérification rapide:
$ fn invoke fnexo hellonode # hellonode fnexo {"message":"Hello World"}
Pour appeler directement la fonction, vous devez 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 corresponde au schéma t/app/function , mais pas complètement. Par HTTP, la fonction n'est pas appelée directement, mais par le soi-disant déclencheur qui, selon son nom, «lance» l'appel de fonction. Les déclencheurs sont définis dans le projet `func.yml :
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
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 #
Ensuite, nous recommençons la livraison de la fonction et l'appelons à partir du nouveau déclencheur:
$ fn deploy --app fnexo hellonode --local $ curl http://localhost:8080/t/fnexo/hellonode {"message":"Hello World"}
Tout fonctionne! Il est temps d'aller à des expériences à grande échelle et de publier notre FaaS sur le serveur!
Installation de services de fonction sans serveur sur votre propre infrastructure
Installons rapidement une machine virtuelle à l'aide de CLI Exoscale. Si vous ne l'avez pas encore configuré, vous pouvez utiliser notre guide pour le lancer rapidement . Il s'agit d'un outil génial qui améliorera encore votre productivité. N'oubliez pas que vous devez 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 fonctionnalités:
$ 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 ssh dans la machine virtuelle et installer le serveur Fn distant:
$ exo ssh fn-server The authenticity of host '185.19.30.175 (185.19.30.175)' can't be established. ECDSA key fingerprint is SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '185.19.30.175' (ECDSA) to the list of known hosts. Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)
Installez ensuite Docker et le serveur Fn de la même manière que nous l'avons fait sur la machine locale, démarrez 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 pour les fonctionnalités! Pour le transfert ciblé de fonctions vers un serveur distant, nous utiliserons la commande deploy de l'ordinateur local, en omettant l'indicateur --local .
De plus, Fn vous oblige à spécifier l'emplacement du serveur Fn et du registre Docker. Ces paramètres peuvent être définis via les variables d'environnement FN_API_URL et FN_REGISTRY respectivement, mais un moyen plus pratique est proposé pour gérer facilement la création et la gestion des configurations de déploiement.
En termes de Fn, la configuration de déploiement est appelée context . La commande suivante créera le contexte:
$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel
Vous pouvez afficher les contextes disponibles comme celui-ci:
$ fn list contexts CURRENT NAME PROVIDER API URL REGISTRY default default http://localhost:8080/ exoscale default http://185.19.30.175:8080 nfrankel
Et passez au contexte qui vient d'être créé, comme ceci:
$ fn use context exoscale Now using context: exoscale
À partir de ce moment, la fourniture des fonctions Fn téléchargera des images Docker à l'aide du compte sélectionné sur DockerHub (dans mon cas, nfrankel ), puis informera le serveur distant (dans cet exemple, http://185.19.30.175:8080 ) de l'emplacement et de la version La dernière image contenant votre fonction.
$ fn deploy --app fnexo . # hellonode Deploying function at: /. Deploying hellonode to app: fnexo Bumped to version 0.0.5 Building image nfrankel/hellonode:0.0.5 .
Enfin:
$ curl http://185.19.30.175:8080/t/fnexo/hellonode {"message":"Hello World"}
Cycle de vie des fonctions dans l'informatique sans serveur basée sur Fn
Les avantages de l'informatique sans serveur dans ses installations
L'informatique sans serveur est une solution pratique pour implémenter rapidement des composants d'application indépendants qui interagissent avec des applications ou des microservices plus complexes.
Cela est souvent dû au coût caché de la liaison avec le fournisseur sélectionné, qui, selon le cas d'utilisation spécifique et le volume, peut entraîner des coûts plus élevés et une flexibilité réduite à l'avenir.
Les architectures multi-cloud et cloud hybride souffrent Ă©galement dans ce cas, car vous pouvez facilement vous retrouver dans une situation oĂą vous souhaitez utiliser l'informatique sans serveur, mais en raison de la politique de l'entreprise, cela peut ne pas ĂŞtre possible.
Fn est assez simple à travailler, il peut donner à peu près la même interface FaaS, à faible coût. Il élimine toutes les liaisons avec le fournisseur; vous pouvez l'installer localement ou dans n'importe quel fournisseur de solutions cloud de votre choix. Il y a aussi la liberté de choisir un langage de programmation.
Seules les bases de Fn sont présentées dans l'article, mais la création de votre propre environnement d'exécution est assez simple, et l'architecture générale peut être développée plus largement à l'aide de l'équilibreur de charge Fn, ou en plaçant Fn derrière un proxy pour la protection.