Projet Tuteuré Function as a Service · 2020-04-13 · Tableau comparatif des solutions libres 11 ... Comparaison des solutions 32 Documentation 32 Installation 33 Utilisation 34

Projet Tuteuré Function as a Service

FOURREAUX Mathias, VAUCEL Gaetan, TOUSSAINT Louis Tuteur : CASSET Stéphane

Année universitaire : 2019-2020

Sujet : FaaS Projet Tuteuré - ASRALL 2019-2020

Function as a Service Page 1


Remerciements

Nous souhaiterions tout d’abord remercier Monsieur Stéphane CASSET qui a su être à notre disposition, nous expliquer notre sujet, nous aider lors de problèmes que l'on a rencontrés tout au long du projet et nous conseiller sur les méthodes de travail à utiliser pour être le plus productif possible. Nous remercions aussi l’ensemble du jury que ce soit les professeurs et les intervenants pour les compétences qui nous ont permi de développer nos connaissances nécessaires à nos expériences professionnelles futures. Merci Monsieur Philippe Dosch et Monsieur Lucas Nussbaum, responsables de la licence qui ont su nous guider tout au long de cette année.



Table des matières Remerciements 1 Table des matières 3 Introduction 5

Contexte 5 Problématique 6 Sujet 6

Support de travail 7 Docker 7 Kubernetes 8 Conteneurs 8

Etat de l’art 10 Analyse de l’état de l’art sur les solutions FaaS 10

Tableau comparatif des solutions libres 11 Tableau comparatif des solutions propriétaire 12

Fonctionnement / Protocoles 13 Principe de fonctionnement d’un FaaS 13 OpenFaaS 14 OpenWhisk 15 FISSION 16

Réalisation / mise en place 17 Cluster de conteneurs 17 Solution FaaS 20

OpenFaaS 20 Installation 20 Déploiement de fonction 22

OpenWhisk 24 Installation 24 Création d’une fonction 26

FISSION 29 Installation 29 Création de fonction 29 Les Triggers 30

Comparaison des solutions 32 Documentation 32 Installation 33 Utilisation 34

Organisation du projet 35 Conclusion 36 Sources 37



Introduction

Contexte

Le «Function as a Service» (FaaS) est une catégorie de services de cloud

computing qui fournit une plate-forme permettant aux clients de développer, d'exécuter et de gérer les fonctionnalités des applications sans la complexité de créer et de maintenir l'infrastructure généralement associée au développement et au lancement d'une application. La construction d'une application suivant ce modèle est un moyen de réaliser une architecture, dit «serverless», et est généralement utilisée lors de la création d'application de micro-services. Le FaaS est un développement extrêmement récent dans le cloud computing, d'abord mis à la disposition du monde byhook.io en octobre 2014, suivi par AWS Lambda, Google CloudFunctions, Microsoft AzureFunctions et Oracle CloudFn en 2017 qui sont disponibles pour un usage public. Les capacités FaaS existent également sur les plateformes privées, comme le démontrent les déclencheurs Schemaless d'Uber.



Problématique

Les entreprises évolutives et développent constamment leurs systèmes d'information. Cela les encourage à utiliser des systèmes de conteneurisation afin de réduire les coûts d'exploitation tels que limiter le nombre de serveurs, une réduction de l'électricité, une réduction des coûts de maintenance. Pour cela, les infrastructures ont décidé de s'appuyer sur un système de conteneurs, où chaque conteneur contient un service ou besoin unique. Les projets comme «Docker» et Kubernetes sont ainsi nés pour répondre à cette nécessité de gérer les conteneurs.

Sujet

L’objectif de notre projet est de proposer une solution clé en main pour pouvoir développer sans avoir à installer de logiciel, utilisé de librairies, compilateur, etc pour les développeurs. Il faut donc pour cela utiliser un serveur à distance possédant les librairies nécessaires aux développeurs et pouvant compiler le code pour en afficher le résultat/sortie sur l’interface graphique du Faas.

Les contraintes minimales :

● Langages des fonctions déployées : Python, Go, Java, .Net (notamment .Net Core).

● Facilité de mise en place. ● Facilité pour les développeurs pour le déploiement. ● Portabilité du code entre les différentes solutions ? ● Intégration avec prometheus pour la métrologie serait un gros plus.



Support de travail

Docker

Docker est une solution logicielle open source et libre, publiée sous licence

Apache 2.0, disponible sur les systèmes GNU/Linux et visant le déploiement automatisé de conteneurs, qui contiennent les applications et services à exécuter. Docker est décrit par la société Docker Inc comme" une plate-forme pour développeurs et administrateurs systèmes qui permet de construire, déployer, et mettre en œuvre des applications distribuées". Docker est partagé entre l’exécutable qui fournit les fonctionnalités, et l’écosystème autour permettant le partage d’images (les images sont l’équivalent d’instantanés pour les conteneurs). Créé par Solomon Hykes officiellement le 13 mars 2013, il est écrit en GO, un langage de programmation récent, de type compilé, inspiré de C et Pascal, et développé par Google. Docker est issue des travaux précédents de la société Dotcloud, que dirigeait auparavant Solomon Hykes. Ce qui fait la force de Docker c’est la portabilité. En effet, les images et conteneurs créés peuvent être partagés facilement, et la compatibilité est assuré sur toutes les plates-formes intégrantes Docker. Le fonctionnement de Docker sur la partie partage et versionning des images est fortement inspirée du gestionnaire de version Git, avec des commits et des envois sur serveurs distants, qui peuvent ensuite être partagés.



Kubernetes

Créé par Google et admis à la Cloud Native Computing Foundation (CNCF)

en 2014, Kubernetes est un système de gestion open source pour applications conteneurisées et de microservices sur plusieurs hôtes. Il offre une haute évolution technologique pour les applications, notamment pour les mécanismes de déploiement, la maintenance, etc. On peut trouver son utilisation par Amazon Web Services (AWS) et Google Cloud Platform (GCP). Google et Amazon facilitent l'accès aux utilisateurs du monde en offrant une année de services avec quelques limitations dans leurs procédures. Kubernetes est un orchestrateur de conteneurs Docker. Autrement dit, il se chargera de déployer les conteneurs dans un cluster de la manière la plus optimisée. Kubernetes utilise des pods, c'est un composant qui contient un ou plusieurs conteneurs. Il dispose d’une adresse IP unique, qui évite les conflits de port entre la machine hôte et les conteneurs (les conteneurs à l'intérieur des pods disposent de la même adresse IP), ce qui permet de gérer les pods à l’image des machines virtuelles.



Conteneurs

La technologie des conteneurs existe depuis les années 2000 sur Linux

notamment avec LXC qui est un système de virtualisation qui isole des environnements Linux en partageant le même noyau. Docker et Kubernetes sont en quelque sorte une surcouche qui facilite le déploiement des conteneurs. Un conteneur est généralement qualifié comme une boîte qui permet, virtuellement, d’empaqueter une application avec toutes ces dépendances, tel que des librairies, fichiers de sources, les outils, afin d’établir son bon fonctionnement avec le strict minimum.

Illustration : Différence VM - Conteneur (source : alfa-safety.fr)



Etat de l’art

Analyse de l’état de l’art sur les solutions FaaS

La première chose à faire au début d’un tel projet est de répertorier toutes les

solutions FaaS pour les étudier et juger quels sont les solutions pertinentes les plus adaptées à notre problématique. Toutes les informations présentes dans cette partie seront donc des informations que nous n’aurons pas encore vérifiées. Voici les différentes solutions que nous avons pu trouver sur le net :

Liste non-exhaustive des solutions

Populaire Connu Méconnu Non libre

OpenFaaS Fission Effe AWS Lambda

OpenWhisk Fn Project OpenLambda GCP Functions

Kubeless Nuclio Gestalt Microsoft Azure

Nous avons tout d’abord choisi d’évincer les solutions “méconnues”, les solutions dont nous ne pouvions pas récolter assez d’information pour travailler convenablement dessus (Effe Gestalt et OpenLambda).



Tableau comparatif des solutions libres

Solutions OpenSource Popularité Installation Langages

supportés Clusters Portabilité

OpenFaaS Populaire Facile Tous Docker Kubernetes Correcte

OpenWhisk Populaire Intermédiaire 8 Docker Kubernetes Bonne

Fission Assez populaire Intermédiaire 10 Kubernetes Correcte

Kubeless Assez populaire Facile 8 Kubernetes Bonne

Nuclio Assez populaire Très facile 8

Kubernetes Docker Google Azure

Correcte

Fn project Oracle

Assez populaire Facile 5 Docker Bonne

Iron.io À l’abandon Facile Tous Docker Correcte

Les langages requis pour le projet sont en vert

Nous avons choisi d’étudier OpenFaaS, OpenWhisk et Fission car ces trois solutions respectent toutes nos contraintes et que leur documentation riche nous permettra d’effectuer notre travail dans les meilleures conditions.



Tableau comparatif des solutions propriétaire

Solution Propriétaires Popularité Installation Langages

supportés Clusters Portabilité

AWS Lambda

(Amazon) Populaire Très facile 4 EMR Excellente

GCP Functions (Google)

Populaire Facile Tous Google Container Correct

Microsoft Azure

Assez populaire Facile 8 Kubernetes Bonne

Les langages requis pour le projet sont en vert

Nous allons bien évidemment, omettre les solutions précédentes. Nous avons quand même choisi de comparer entre eux ses différents produits.



Fonctionnement / Protocoles

Principe de fonctionnement d’un FaaS

Le FaaS (Function as a service) est un modèle de cloud computing, ( au

même titre que le IaaS, PaaS et SaaS ) permettant de créer des applications dites serverless. Le principe de FaaS est de proposer une application qui exécute ses fonctions (de quelconque langages) sur un serveur distant qui renvoie le résultat à l’application en question une fois la fonction exécutée. L'intérêt pour les développeurs est de se dispenser de tout le travail lié à la logistique liée à la partie serveur de l’application, et de proposer une application plus légère et performante quelle que soit la machine hôte. Les clients d’une entreprise proposant un tel service sont facturés à chaque fois que le service est sollicité, cela peut être un avantage comme un inconvénient, dépendant du nombre d’utilisateurs.

Illustration : exemple d’une application simple



OpenFaaS

OpenFaaS est un projet Open source créé par Alex Ellis en décembre 2016 avec la philosophie de créer un outil relativement simple, avec le moins de restriction possible. OpenFaaS est un framework assez populaire dans le monde du FaaS (notamment sur GitHub). La société VMware est un des acteurs principaux à l’évolution du framework en embauchant une équipe pour travailler à temps plein sur le projet et des dizaines de contributeurs apportent leur aide chaque jour.

OpenFaaS est compatible avec les conteneurs Docker et Kubernetes et supporte (a priori) n’importe quel langage (que ce soit pour Windows ou pour Linux).

L'architecture d'OpenFaas est relativement simple. La passerelle API peut être invoquée de manière synchrone ou asynchrone via Kafka, SNS, CloudEvents, CRON et d'autres déclencheurs. Les appels asynchrones sont gérés par NATS Streaming. L'auto-scaling est effectué à l'aide de Prometheus et Prometheus Alertmanager, mais il semble que cela puisse être échangé pour utiliser HorizontalPodAutoscaler de Kubernetes.

OpenFaaS permet d'exécuter des fonctions de n’importe quel langage (que ce soit pour Windows ou Linux). Il dispose d’un système d’auto-scales à la demande.

Le cluster peut être créé via Kubernetes ou docker swarm.



OpenWhisk

OpenWhisk est, comme son nom l’indique, également un projet Open source créé en février 2016 par la société Apache foundation et soutenu par IBM. OpenWhisk constitue la base du service IBM Functions Cloud. Les principaux contributeurs sont les employés d'IBM.

Il existe de nombreux composants sous-jacents, ce qui ajoute à la complexité. Il exploite CouchDB, Kafka, Nginx, Redis et Zookeeper. L'avantage est que les développeurs se sont clairement concentrés sur l'évolutivité et la résilience. L'inconvénient est que les développeurs et les opérateurs auraient besoin d'une connaissance pratique de ces outils.

Un autre inconvénient est qu'ils dupliquent des fonctionnalités présentes dans un orchestrateur comme Kubernetes (par exemple, la mise à l'échelle automatique). Les fonctions sont finalement regroupées dans des conteneurs Docker qui s'exécutent à côté du cadre.

OpenWhisk peut être installé à l'aide d’Helm mais nécessite une intervention manuelle. Les applications peuvent être déployées à l'aide de la CLI ou avec le framework sans serveur. Les métriques Prometheus sont exportées hors de la boîte.

OpenWhisk ne supporte pas n’importe quel langage, toutefois, il supporte le .Net, le Go, le Java et JavaScript, le PHP, le Python, le Ruby et le Swift, ce qui résout donc notre contrainte sur les langages que nous devons déployer.

L’équipe OpenWhisk travaille actuellement en parallèle à intégrer Ballerina et Rust

dans les prochaines versions du framework.

OpenWhisk supporte les clusters Docker et Kubernetes.


https://github.com/apache/openwhisk-runtime-ballerina#readme

https://github.com/apache/openwhisk-runtime-rust#readme


FISSION

Fission, est, lui aussi un framework open source, son développement a débuté en août 2016. C’est un outil exclusivement construit pour kubernetes et il ne sera donc pas possible d’utiliser de cluster docker avec cette solution. Le projet regroupe 91 contributeurs et des commits sont effectués assez régulièrement sur GitHub.

Fission prend actuellement en charge NodeJS, Python, Ruby, JVM, Go, PHP, Bash, .NET et Perl, il est annoncé sur la documentation officielle que d’autres langages supplémentaires seront supportés dans le futur.

Dans les sites donnés en tant que point de départ du projet, il y est dit que la documentation est assez pauvre pour ce qui est de Fission mais nous trouvons personnellement à première vue que le site officiel à l’air de proposer une documentation et guides tout à fait convenables.

Fission implémente l’auto-scaling avec le plugin “NewDeploy”. Fission peut être déployé avec un cluster kubernetes uniquement.

Fission se trouve sous license Apache 2.0.


https://github.com/fission/fission


Réalisation / mise en place Cluster de conteneurs

La première chose à effectuer pour mettre en place une solution FaaS est d’installer un cluster de conteneur. Pour cela, nous utiliserons un logiciel en surcouche de kubernetes, il existe plusieurs solutions telles que k8s, k3s ou minikube. Nous utiliserons K3S de Rancher Labs tout simplement parce que c’est un logiciel simple à utiliser et qu’il nous a été conseillé par notre tuteur. Pour mettre en place notre cluster (avec k3s comme avec les autres solutions) donc, nous avons tout d’abord créé 2 VM, une pour accueillir le master et l’autre pour un worker, une fois les 2 VM créer il a fallu installer k3s, voici les étapes de l’installation: On récupère k3s sur le master et on l'installe



On va devoir ensuite récupérer le “token” du serveur qui servira pour l’installation de k3s sur le worker

Une fois l’installation sur le master terminé, on peut passer au worker, il faut donc exporter les paramètres du serveur :

export K3S_URL="https://192.168.0.28:6443" export

K3S_TOKEN="K102459b96d973af01838d2d4ff498ec63c1e2165fa337cf5db0409e541bf7879f0::server:69fba7b58b5f1921f0d91021447beb39"

On peut ensuite recuperer k3s via un curl comme pour le master



Une fois installé sur le master et le worker, on regarde si tout est bien installé correctement :

On essaye donc différentes commandes pour voir les informations du cluster



Solution FaaS

Après avoir mis en place notre cluster, on peut maintenant installer un logiciel

FaaS. Que ce soit pour OpenFaaS, OpenWhisk ou Fission, la marche à suivre est stipulée sur leurs sites respectifs, l’installation se résume à une dizaine de commande approximativement.

OpenFaaS

Installation

Pour installer Openfaas il nous fallait donc un cluster, que ce soit kubernetes

ou docker swarm, une fois le cluster créé il ne reste plus qu’à installer openfaas : On commence donc par récupérer openfaas via git.

git clone https://github.com/openfaas/faas-netes

On se déplace ensuite dans le dossier qu’on vient de télécharger.

cd faas-netes

On vient ensuite appliquer au cluster le namespace.yml.

kubectl apply -f ./namespaces.yml

Il faut ensuite récupérer le mot de passe qui permettra de se connecter sur l’interface web.

PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1) kubectl -n openfaas create secret generic basic-auth \ --from-literal=basic-auth-user=admin \ --from-literal=basic-auth-password="$PASSWORD" echo $PASSWORD



Cette commande nous retourne donc notre mot de passe qui est : b4a40739b3c2652b6ed0986126b708189ce6e285 On peut ensuite déployer OpenFaas sur le cluster.

kubectl apply -f ./yaml

On vérifie qu’OpenFaaS est bien installé.

kubectl get deployments --namespace openfaas

OpenFaaS utilise par défaut un registre DockerHub, il faut donc changer cela pour utiliser notre propre registre privé.

kubectl run registry --image=registry:latest --port=5000 \ --namespace openfaas

kubectl expose deployment registry --namespace openfaas \

--type=LoadBalancer --port=5000 --target-port=5000

L’installation est donc terminée et on peut aller sur l’interface web. http://localhost:31112

Illustration : Interface graphique d’OpenFaaS


http://localhost:31112/


Déploiement de fonction

Pour déployer une fonction il est nécessaire de se connecter à Openfaas.

faas-cli login --gateway http://localhost:31112 --password <pwd>

On vient ensuite récupérer des templates pour différents langages.

faas-cli new --lang python hello-python faas-cli new --lang java8 hello-java8 faas-cli new --lang node hello-node

Une fois cela fait, il faut modifier les .yml des templates récupérées pour modifier le registre utiliser par défaut (lignes en jaunes sont les lignes modifiées).

Une fois les fichiers modifiés il ne reste plus qu’à déployer les fonctions sur le Faas.

faas-cli up -f ./hello-python.yml faas-cli up -f ./hello-java8.yml faas-cli up -f ./hello-node.yml



On peut ensuite récupérer le résultat / la sortie du code directement sur l’interface web ou via un curl.

Illustration : Interface graphique d’OpenFaaS ou



OpenWhisk

Installation

Basé sur l'utilisation de la virtualisation Docker-in-Docker (DIND) et de

kubeadm, kind peut être utilisé pour créer un cluster Kubernetes virtuel à plusieurs nœuds qui convient au déploiement d'OpenWhisk pour le développement et les tests. Nous avons trouvé des instructions détaillées sur kind. Ici, nous ne couvrirons que les opérations de base nécessaires pour créer et faire fonctionner un cluster par défaut avec deux nœuds de travail virtuel. Je commence par installer la dernière version stable de kind sur le github officiel de Kubernetes. Ceci fait, je crée le fichier “kind-cluster.yaml” pour configurer mon cluster.

kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: worker - role: control-plane extraPortMappings: - hostPort: 31001 containerPort: 31001 - role: worker

La partie “extraPortMappings” permet le transfert de port du localhost vers le réseau du cluster. Ceci est obligatoire sur MacOS, mais pour simplifier les instructions, ils utilisent la même configuration pour toutes les plateformes. Maintenant, on peut créer le cluster avec la commande :

kind create cluster --config kind-cluster.yaml

Puis on configure “kubectl” en exécutant :



KUBECONFIG="$(kind get kubeconfig-path)"

On marque les deux “worker node” de manière à ce que l'un soit réservé à l'appelant et que l'autre soit utilisé pour exécuter le reste du système OpenWhisk.

kubectl label node kind-worker openwhisk-role=core kubectl label node kind-worker2 openwhisk-role=invoker

L’installation des clusters étant fait, nous devons créer la configuration d’OpenWhisk avant de le déployer. Et ce pour configurer, il faut définir un fichier “mycluster.yaml” qui spécifie ce qu’il y a dans le cluster, notamment ses informations et la configuration système. Le fichier “mycluster.yaml” suivant permet un déploiement standard d’OpenWhisk.

whisk:

ingress:

type: NodePort #<INTERNAL_IP> a remplacer par l'IP du cluster apiHostName: <INTERNAL_IP> apiHostPort: 31001

invoker:

containerFactory:

impl: "kubernetes"

controller:

imageName: "whisk/controller"

imageTag: "latest"

nginx:

httpsNodePort: 31001

Si toutes les étapes sont appliquées, alors le déploiement est possible avec la commande suivante.

#Paquet requis : helm

helm install -f mycluster.yaml



Création d’une fonction

Nombreux sont les nouveaux utilisateurs à avoir testé un exemple partagé par

la communauté. Celui-ci permet aux débutants de comprendre le déploiement sur OpenWhisk. Parmi ces exemples, l’un démontre l’utilisation d’une base de données avec la solution MongoDB. Source : github.com/OrangeFoi. Cette tâche consiste à sauvegarder des données dans la BDD et de recevoir des paramètres concernant l’ID et le nombre d’objets dans celle-ci.

Illustration : Contenu du fichier __main__.py



Après avoir obtenu ou reproduit ce fichier, nous devons le conditionner et installer les dépendances.

Illustration : Commandes exécutées Sur l’environnement d’OpenWhisk, les événements sont caractérisés par des déclencheurs (triggers). De plus, les actions sont utilisées pour invoquer la fonction. Concernant la suite, nous créons l’action en lien avec exec.zip et les déclencheurs. Dans l’exemple ce sont les restocks d’objets et leurs ventes qui sont mis à jour dans l’inventaire sur la base de donnée.

Illustration : Création de l’action et des déclencheurs Maintenant la fonction est prête à recevoir des requêtes, nous pouvons commencer par simuler un restockage dans l’inventaire en définissant le numéro d’un objet (product_id) et le nombre ajouté (stock_change) de l’objet précédemment cité. Exemple de restockage :



wsk trigger fire itemRestocked −p product_id 35 −p stock_change 454

Ici, nous ajoutons 454 nouveaux exemplaires de l’objet numéro 35. Exemple de vente :

wsk trigger fire itemSold −p product_id 58

Cette commande simule une vente d’un exemplaire de l’objet numéro 58, ce qui fait décrémenter le stock dans l’inventaire (BDD).



FISSION

Installation

L’installation de Fission est assez facile dans la théorie, il est possible de l’installer via Helm, qui est un gestionnaire d’applications kubernetes, mais on peut aussi l’installer via des commandes kubectl comme çi dessous :

$ kubectl create namespace fission $ kubectl -n fission apply -f \

https://github.com/fission/fission/releases/download/1.8.0/fission-all-1.8.0

.yaml

$ curl -Lo fission

https://github.com/fission/fission/releases/download/1.8.0/fission-cli-osx \ && chmod +x fission && sudo mv fission /usr/local/bin/

Il est plus rapide de l’installer ainsi et helm est dispensable si l’on ne désire installer que Fission.

Création de fonction

Une fois Fission installé, on peut directement créer des fonctions, voiçi un exemple de mise en place :

$ fission env create --name python --image fission/python-env “on ajoute l’environnement “python” au cluster”

$ fission function create --name function_name --env python --code function.py

“on crée la fonction”

$ fission function test --name function_name “Retour de la fonction”


https://github.com/fission/fission/releases/download/1.8.0/fission-all-1.8.0.yaml

https://github.com/fission/fission/releases/download/1.8.0/fission-all-1.8.0.yaml


Les Triggers

On peut invoquer les fonctions que l’on a créées via ce que l’on appelle des “Triggers”. Il existe des “HTTP Triggers”, qui comme leur nom l’indique, déclenche un fonction via une requête HTTP.

$ fission httptrigger create --url /function --method GET --function function_name

$ curl http://”IP_du_master”/function “Retour de la fonction”

Les “Time triggers”, qui déclenchent les fonctions suivant le temps (toutes les heures, tous les jours….). On spécifie le temps désiré via la notation CRON.

$ fission timer create --name minute --function function_name --cron "@every 1m"



Et pour finir, les “Messages Queue Triggers”, qui se relient et écoutent des logicielles tierces de messageries pour déclencher les fonctions. Pour le moment, fission ne supporte uniquement que ces trois logiciels de files de message : Kafka, NATS Streaming et Azure Queue Storage. Pour illustrer ce concept de trigger, il est plus intéressant ici de montrer le schéma associé sur le site de Fission.

Illustration : Schéma du fonctionnement du Message Queue Trigger Source : https://docs.fission.io/docs/triggers/message-queue-trigger/


https://docs.fission.io/docs/triggers/message-queue-trigger/


Comparaison des solutions

Nous avons donc testé 3 solutions de Faas pour ce projet, ces solutions sont OpenFaas, Fission et Openwhisk. Nous les avons donc toutes comparées pour savoir laquelle était la plus adaptée à notre problématique.

Documentation

Le nombre de documentation varie entre ces trois solutions, on retrouve

assez facilement des solutions détaillées et diverses tutoriales. Plus particulièrement, sur la solution OpenFaaS auquel la communauté est très présente et de nombreux exemples sont fournis par eux et sont généralement relayés par le site officiel. OpenWhisk dispose lui aussi d’une bonne communauté, mais l’organisation des informations est inférieure à celle d’OpenFaaS, ce qui rend les solutions moins aisées à trouver. Concernant Fission, hormis le site officiel fournissant l’essentiel de la documentation nécessaire à la mise en place de Fission, il n’existe pas d’autres compléments d’informations sur le web (ou très peu). Fission ne semble pas avoir beaucoup d’utilisateurs actifs sur les forums et si des problèmes sont rencontrés lors de l’utilisation de Fission, il est de mise de savoir de débrouiller seul.



Installation

Pour les solutions comme OpenWhisk et OpenFaaS, leurs documentations

abondantes donnent de nombreuses informations concernant leurs installations. Ceux-ci sont si nombreux que nous avons trouvé un minimum de 5 méthodes différentes chacun pour déployer ses logiciels. Globalement les trois solutions se déploient assez aiséments, tous disposent de peu de commandes et celles-ci sont assez explicites pour comprendre leurs utilités. Les erreurs éventuelles sont généralement des problèmes causés par la configuration faite au préalable, très peu proviennent des solutions. OpenWhisk est simple d’installation lorsqu’on désire d’utiliser des langages séparément, mais devient alors compliqué quand il est question de faire fonctionner plusieurs langages en simultané. C’est une étape contraignante malgré la documentation, car un utilisateur qui s'initie au FaaS peut facilement se perdre dans sa réalisation. OpenFaaS permet grâce à sa documentation riche une installation très rapide puisqu'il suffit de le récupérer via Gît et de suivre le tutoriel qui est disponible sur le site dédié, que ce soit pour installer sur un cluster docker ou sur un cluster kubernetes. Fission est dans la théorie un outil facile et rapide à installer mais son absence d’informations supplémentaires sur le web fait qu'à la première rencontre de problèmes, il n’est pas rare rester bloqué un bon moment avant de trouver une solution.



Utilisation

In fine, l’usage de ses différentes solutions est assez simple.

OpenFaaS et OpenWhisk possédant une large communauté, on peut trouver sur des dépôts Git, des templates clés en main pour presque chaque langage (en tout cas pour les langages que nous avons à utilisées), ce qui permet un déploiement très facile même pour une personne débutante dans le domaine, puisqu'il suffit de savoir suivre les instructions données sur le dépôt. Fission possède une documentation convenable sur son site officiel, les commandes sont simples et la syntaxe permet de comprendre rapidement ce que l’on est en train de faire. Mais comme dit précédemment, si des problèmes surviennent, les solutions ne seront que rarement directement accessible sur le net. Pour finir, nous nous sommes mis d’accord pour affirmer qu’OpenFaaS est sans doutes la meilleure solution FaaS adaptée à notre problématique initiale. OpenFaaS est simple d’utilisation, intuitif grâce à son interface graphique, bien documenté, fréquemment mise à jour et possède la plus large communauté parmis non seulement les trois solutions étudiées mais aussi toutes les autres solutions FaaS existantes et non sans raison.



Organisation du projet Lors de la première partie de notre projet, l’objectif était de faire une étude des solutions FaaS existante pour finalement en sélectionner trois, en parallèle, nous avions aussi comme objectif d’installer un cluster de conteneur. Gaëtan s’est donc chargé en majeure partie de trouver un moyen d’installer un cluster, et Mathias et Louis se sont occupés d’effectuer les recherches sur les différentes solutions ainsi que d’établir un comparatif. Après avoir choisi les trois solutions à mettre en place, nous nous somme naturellement réparti le travail en trois, Gaëtan ayant été le plus en avance dû à son installation préliminaire de cluster, il a pu apporter son aide aux autres membre du groupe à plusieurs reprises.



Conclusion Nous avons su travailler en groupe autour d’un même sujet, ainsi que se répartir les tâches et gérer les rôles de chacun. Pour réaliser ce projet, nous nous sommes organisés assez rapidement en utilisant des outils que nous connaissions déjà auparavant et grâce à la phase de découverte du sujet. Grâce à nos professeurs et aux intervenants, nous avons pu corriger certains points qui nous ont permis de toujours avancer dans la bonne direction. Au final, ce projet nous a permis d’apprendre à travailler à plusieurs sur une longue période, et sur un sujet réaliste dans le monde des entreprises d’aujourd’hui. Nous avons donc pu apprendre beaucoup de choses au sujet des solutions FaaS et du fonctionnement des différents logiciels que nous utilisons tous dans la vie courante. C’est un savoir non négligeable que nous pourrons réutiliser lorsque nous intégrerons le monde professionnel.



Sources

https://hackernoon.com/serverless-and-open-source-where-do-we-stand-today-dff8aec67026 https://winderresearch.com/a-comparison-of-serverless-frameworks-for-kubernetes-openfaas-openwon-kubeless-and-more/ https://fission.io https://k3s.io https://actu.alfa-safety.fr/devops/conteneur-docker-fonctionnement-et-avantages-pour-heberger-ses-applications/ https://github.com/kubernetes-sigs/kind https://kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/a https://medium.com/@robertdiers/setup-openfaas-on-k3s-with-local-docker-registry-7a84ebb54a6f https://docs.openfaas.com/deployment/kubernetes/


https://hackernoon.com/serverless-and-open-source-where-do-we-stand-today-dff8aec67026

https://hackernoon.com/serverless-and-open-source-where-do-we-stand-today-dff8aec67026

https://winderresearch.com/a-comparison-of-serverless-frameworks-for-kubernetes-openfaas-openwhisk-fission-kubeless-and-more/

https://winderresearch.com/a-comparison-of-serverless-frameworks-for-kubernetes-openfaas-openwhisk-fission-kubeless-and-more/

https://fission.io/

https://k3s.io/

https://actu.alfa-safety.fr/devops/conteneur-docker-fonctionnement-et-avantages-pour-heberger-ses-applications/

https://actu.alfa-safety.fr/devops/conteneur-docker-fonctionnement-et-avantages-pour-heberger-ses-applications/

https://github.com/kubernetes-sigs/kind

https://kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps:/kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps://kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps:/kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/a

https://kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps:/kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps://kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/ahttps:/kauri.io/37-install-and-configure-a-kubernetes-cluster-with/418b3bc1e0544fbc955a4bbba6fff8a9/a

https://medium.com/@robertdiers/setup-openfaas-on-k3s-with-local-docker-registry-7a84ebb54a6f

https://medium.com/@robertdiers/setup-openfaas-on-k3s-with-local-docker-registry-7a84ebb54a6f

https://docs.openfaas.com/deployment/kubernetes/

Documents

Projet Tuteuré Function as a Service · 2020-04-13 · Tableau comparatif des solutions libres 11 ... Comparaison des solutions 32 Documentation 32 Installation 33 Utilisation 34