Thématiques principales

jeudi 22 août 2019

Chaines youtube intéressantes

On me demande parfois si je regarde des chaînes youtubes…. alors je ne sais pas si c’est parce que les gens ont des préjugés sur ce média où effectivement on trouve de “tout”... mais avec un peu de curiosité et d’esprit critique je pense que l’on peut vraiment y trouver son bonheur.

À vrai dire, je pense même intimement que internet et des médias tels que youtube sont  probablement l’avenir du partage de l’informations sous toutes ses formes et remplacera même à terme les médias traditionnels et les chaînes nationales (j’avoue même personnellement ne plus y trouver quoique ce soit d'intéressant….)

Ce qui manque encore aujourd'hui à ce support c’est des moyens pour canaliser l’information, mettre en évidence celle qui est pertinente et enfin la rendre accessible par différents degrés de vulgarisation.

lundi 19 août 2019

Docker Compose

Nous rebondissons une nouvelle fois! Dans l’article précédent nous avions traité d’un exemple de déploiement de python dans docker [1] . Mais nous avions constaté que nous devions spécifier dans nos images des informations concernant le contexte d'exécution, entre autre le hostname de la machine hôte… et franchement c’est un peu dégueu...

Alors jusqu’à maintenant nous avons utilisé docker dans différents exemples ou soit nous voulions expliquer certains aspects de son fonctionnement soit parce que tout simplement c'était plus simple pour  traiter le sujet en question.

À chaque fois nous n’avions eu besoin que d’un container ce qui ne posait pas de problème sauf dans ce dernier exemple!

Du coup on va voir comment s’en défaire et ça va justement être l’occasion de parler un peu de docker-compose [2].

Docker compose est justement la pour faciliter l’orchestration et le lancement de container docker dans un contexte commun cohérent [24].

vendredi 16 août 2019

Python dans docker

Nous avons dans un article précédent [1] proposer un exemple de mise en oeuvre  de deux applications python exploitant ou exposant une interface ReST.

Dans un second article [2],  nous avons également vu qu’il était possible de de packager et livrer des applications python avec divers outils comme setuptools[3] ou pyinstaller [4].

Nous avions cependant laisser une question en suspend concernant une dernière façon de déployer nos appli python. Ainsi, comme vous l’avez deviné, (le titre à tout spoiler…) nous allons dans ce présent article nous intéresser au packaging python dans des container docker.

Alors du coup après avoir lu l’article précédent, vous allez surement demander, mais pourquoi? quel est l'intérêt? et bien pour deux raisons:

  • la première est la devise de docker [5]: build once, run everywhere ce qui permet d’aller bien au delà des plateformes et des machines virtuelles
  • la seconde est que comme à la place de livrer un package ou des sources, on va livrer une image docker, alors peu importe ce que nous mettrons dans le conteneur, cela restera dans le conteneur sous notre responsabilité en minimisant complètement les interventions d’installations d’un utilisateur

La limitation est évidemment que nous ne nous intéresserons qu’aux applications basées sur le réseaux…. (WEB, CLI, etc)

Du coup pour illustrer cet article, je vous propose de reprendre l’exemple déjà traité précédemment [1] avec lequel nous proposons de déployer dans un ou plusieurs conteneur docker les différentes parties applicatives.

Pour cela nous allons donc utiliser une image de base de type alpine dans laquelle nous allons ensuite déployer ce que nous aurons décidé d’etre notre livrable. Ici, le plus simple, et de directement pousser nos sources dans l’image en s’assurant préalablement que python est bien installé ainsi que les dépendances de notre application.

On va donc définir deux Dockerfile en s’inspirant de [6]: Dockerfile_people et Dockerfile_stat respectivement pour chaque applications:


#Dockerfile_people:

FROM alpine:latest
RUN apk add --no-cache python3
RUN pip3 install setuptools Wheel
RUN pip3 install flask
COPY . /opt/
CMD cd /opt;python3 -m people



#Dockerfile_stat:

FROM alpine:latest
RUN apk add --no-cache python3
RUN pip3 install setuptools Wheel
RUN pip3 install flask python_http_client
COPY . /opt/
CMD cd /opt;python3 -m people_stat


Puis on construit nos images:


$ docker build -t people -f ./Dockerfile_people .
$ docker build -t people_stat -f ./Dockerfile_stat .


Et on les lances (en oubliant pas d’exposer leur ports d'écoutes respectifs 5001 et 5002 avec le paramètre -p)


$ docker run -it -p 5001:5001 people
$ docker run -it -p 5002:5002 people_stat


Et la ca marche! euh oui mais pas complètement… autant si on essaye d'accéder à l’interface http://localhost:5001/humans, cela fonctionne mais…. si ont tente http://localhost:5002/recall, la rien ne va plus!

Qu’est ce qui se passe?

C’est simple dans la configuration applicative réalisant les requêtes sur “recall”, nous avons dit à notre application d’aller chercher les informations sur localhost:5001/humans…. mais ce localhost…. c’est lui même! Ce que l’on voulait c'était qu'il aille sur l’autre container! Alors l’erreur semble évidente mais souvent on la fait car on développe sur un poste en local sans se préoccuper de l'aspect distribué du système que l’on est en train de faire… et donc je vous assure tout le monde tombera dans cette erreur.

Donc du coup on fait quoi?

C’est simple on ne met pas localhost mais le hostname de la machine qui expose réellement ce port! C’est à dire dans notre situation, la machine physique. (je vous laisse essayer ).

Alors bien sur généralement une information comme celle ci ne devra pas être mis en dur dans le code, on préférera s’appuyer sur des fichiers de configuration, accessibles depuis un volume ou définis par des variables d’environnement alimenté au moment du lancement du container. L’idée ici n’est pas d’aller jusque la mais déjà de voir ce que permet docker basiquement et certaines des limitations que cela induit, ici entre autre une adhérence résiduelle à la machine physique.

Nous verrons dans un prochain article comme avec docker toujours s’en affranchir.

Références:

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2019/08/rest-avec-python.html
[2] https://un-est-tout-et-tout-est-un.blogspot.com/2019/08/deployer-du-python.html
[3] https://setuptools.readthedocs.io/en/latest/setuptools.html
[4] https://www.pyinstaller.org/
[5] https://uwm.edu/business/event/docker/
[6] https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-xix-deployment-on-docker-containers

dimanche 11 août 2019

Déployer du Python

L’idée de cet article est de nous intéresser aux modes de livraison possible d’un programme python. L'enjeux est important car, en effet, écrire du code c’est bien mais sans livraison, c’est comme si ce code n’existait pas! Il faut donc avoir des moyens fiables et rapides permettant de fournir à un client son application python “clef en main”.

Via les sources

Dans cette approche ce qui sera fourni ce sera directement les sources qui seront mis à disposition de l’utilisateur final. Ce dernier aura alors la charge de fournir un environnement disposant non seulement de python dans la version adéquate mais aussi d’avoir pre-installer les modules dont l’application dépende.

Par exemple, sur une machine Debian, pour lancer l’application, il va être nécessaire préalablement de faire :

1
2
3
4
5
$ apt-get update && apt-get install -y --no-install-recommends python3 \
   python3-pip python3-dev \
$ apt-get clean && rm -rf /var/lib/apt/lists/
$ pip3 install --upgrade pip setuptools
$ pip3 install dependencies

Pour finalement pouvoir lancer l’application sur un appel du module :

1
$ python3 -m monAppli

Le point négatif de cet approche est la gestion des droits car lors du lancement de l’application, et à moins de préciser que l’on veille que python reste en mode interpréteur [pyt-pyc], différents fichiers vont être générés sur le poste cible. Il importe donc que ces fichiers puisse être généré sans être gêné par des permissions du systèmes mal prévu (et qui seront de toute façon délicat à mettre en oeuvre).

Via les fichiers pré-compilés

C’est une possibilité il faut l’avouer mais alors il ne sera pas possible de faire de patch ou de modification du code source sans compter que ce code sera globalement dispatcher dans un ensemble de fichiers et de répertoire (à l’image des sources).

Cela n'empêchera pas de devoir aussi préparer l’environnement d'exécution comme avec les sources. Donc c’est moins risqué coté permissions systèmes mais on perd un peu l'intérêt du python (le côté interpréteur)

À ce compte là, il serait alors mieux de simplifier la livraison en réalisant un package de l’application.

Exe, deb, rpm, etc...

Alors il est clair que faire un package de livraison, ca sera forcement en prenant en compte l’environnement de déploiement et il ne sera pas possible de déployer de la même manière sous windows où sous linux.

L'intérêt de l’approche est de fournir au client une seule référence et sera donc plus simple à gérer d’autant plus que selon la plateforme, cela permettre de bénéficier mécaniquement des avantages du mode de distribution (utilisation de aptitude et gestionnaire de paquet sous linux, pre-installation et configuration de paquets en dépendances, etc.

Pourtant les problèmes cités ci dessus seront toujours présents, code sources ou fichiers pre-compilés, il faudra gérer la dispersion de fichiers dans l’environnement.

On voit bien donc que le problème ici n’est pas le package de livraison, mais son contenu. Heureusement la communauté python à pensé à tout et à fournir différents outils pour livrer de façon cohérente notre application.

Pre-packaging

Ainsi pour réaliser ce pre-packaging, il existe quelques outils comme [setuptools], [distutils], [zipapp], [pyInstaller], py2exe (Windows) ou encore [cx_Freeze] (Windows et Linux) pour ne citer que les plus connu.

PyInstaller


Le plus simple à utiliser est PyInstaller, on l’installe et on l’applique sur le main:

1
2
$ pip install pyinstaller
$ pyinstaller monAppliv.py

et on obtient un répertoire dist dans nos sources contenant notre applications et toutes les librairies nécessaire à son exécution.

En voyant ca vous allez me dire, ok on a troqué les fichiers sources oi pre-compilé avec des librairies…. oui mais la il n’est pas nécessaire d’installer python sur le poste! Par contre attention, la construction qui à été réalisé à être spécifique à une plateforme… donc il faudra prévoir un build pyinstaller par plateforme cible.

setuptools


Setuptools est à l’inverse un package qui va permettre de construire un module versionable comme ceux télécharger lors de l’utilisation de pip install.

Setuptools repose sur distutils et je ne présenterai donc pas ce dernier qui est de plus bas niveau dans la construction des modules package python.

Setuptools est probablement l’outil le plus employé par la communauté car il permet l'intégration du module développé au sein d’un Server exploitable via pip. Ainsi même si python doit être préalablement installer sur le poste cible, la gestion des sources et fichier pre-compilés devient complètement transparent pour le développeur et le client.

De plus, contrairement au contraintes d’une gestion externe du packaging, setuptools, en gérant le versionning va faciliter via pip la mise à jour et l'évolution de l’application.

Pour cela il faut d’abord créer un descripteur de l’application et ce en python. Par exemple dans le cas de nos applications ReST [rest-py], on va créer un fichier setup.py contenant le code suivant:

1
2
3
4
5
6
7
8
from setuptools import setup, find_packages
setup(
    name="people",
    version="0.1.0",
    packages=find_packages(),
    scripts=['people.py','json_tk.py','human.py'],
    install_requires=['docutils>=0.3','Flask>=1.1.1']
)

Ensuite ce code sera exécuté bêtement comme un script :

1
$python setup.py sdist

Ce code va alors produire un targz de notre application contenant nos sources et déclarant les dépendances adéquates pour son installation.

Ainsi une fois packager il suffit alors de fournir ce package au client que celui ci exécute la commande suivante:

1
$ pip install people-0.1.0.tar.gz

Notre application est alors installée dans python (à cette occasion on préférera utiliser un virtualenv…) Et utilisable comme ceci:


1
$ python -m people

Dans cet exemple, avec setuptools, on voit que l’on est beaucoup moi adhérant à la plateforme mais que cela implique que python soit préalable installer dans celle-ci.

L’avantage sera évidemment sa mise à jour mais on notera que si ici on a créé un module setup.py, le nom de ce fichier est impératif sinon l’installation ne sera pas possible avec pip. du coup on notera que notre façon de faire nos applications dans l’exemple [rest-py] se prête finalement assez mal avec cette approche (à moins de séparer le code métier du code applicatif mais cela peut être laborieux)

Conclusions

Nous venons de passer en revue l’ensemble des manière de livrer et déployer une application python. Toutes ces façons de faire comportent leur lot d’avantages et d'inconvenants. On notera malgré tout que la communauté python n’est pas en reste de solution pour fournir des approches, il restera ensuite à la charge des développeurs de faire un choix selon le contexte et les contraintes.

Cependant, nous n’avons pas évoqué une dernière solution possible pour la livraison et le déploiement de nos applications python…. à votre avis???

Références:

[rest-py] https://un-est-tout-et-tout-est-un.blogspot.com/2019/08/rest-avec-python.html
[pyt-pyc] https://stackoverflow.com/questions/154443/how-to-avoid-pyc-files
[distutils] https://docs.python.org/fr/3/library/distutils.html
[pyinstaller] https://www.pyinstaller.org/
[zipapp] https://docs.python.org/fr/3/library/zipapp.html
[setuptools] https://setuptools.readthedocs.io/en/latest/setuptools.html
[cx-freeze] https://cx-freeze.readthedocs.io/en/latest/index.html

jeudi 8 août 2019

Docker registry

Quand on utilise docker, on en vient forcément un jour à se dire (et en fait ca arrive même très très vite), je veux publier les images que j’ai construit. Dans l’utilisation que l’on en fait quotidiennement, c’est à dire le cadre privé, l’utilisateur utilisera le docker hub.

Pourtant le docker hub est publique, c’est à dire que toutes les images que vous allez y déployer seront disponibles aux autres utilisateurs de docker.

C’est évidemment une approche qui se tient de favoriser par défaut la diffusion de images et de vouloir en faire profiter tout le monde dans un esprit de libre échange et bien sur il est quand même possible moyennant un loyer de disposer d’un espace privé dans le docker hub afin de rendre nos images accessibles qu’à un ensemble d’utilisateurs spécifiques ayant les permissions adéquates.

Pourtant, tout cela implique donc de laisser la responsabilité à docker hub de gérer l’accessibilité à nos données alors qu’en fait si le besoin de réutilisation des images est local et interne à l’entreprise, alors il devient légitime de vouloir avoir votre propre “docker hub” à la maison.

Alors sans aller sur un docker-hub avec toute l’interface graphique, ce qui importe c’est de disposer du logiciel qui va gérer nos images. Pour cela, comme le docker hub, il faut utiliser l’image registry [1] fourni par docker [2] [3].

Pour l’utiliser rien de compliqué: il suffit de lire la doc:

$ docker pull registry

Ensuite on lance un conteneur instance de cette image en exposant le port de l’API pour y accéder en prévoyant son redémarrage en l'état en montant un volume:


$ docker run -d -p 5000:5000 -v “/media/storage/registry-volume:/var/lib/registry:rslave” registry:2.7.1


Une fois le container lancer, il reste à tester la registry:

$ docker pull ubuntu
$ docker tag ubuntu localhost:5000/ubuntu
$ docker push localhost:5000/ubuntu

et c’est tout? oui pour déployer des images mais, comment les récupérer? et surtout savoir qu’elles existent?

C’est la que l’on va utiliser l’API [4] de la registry. Par exemple pour connaitre le contenu de notre registry on peut exécuter la requête ReST GET suivant:

$ curl -X GET http://localhost:5000/v2/_catalog

{"repositories":["artifactory-oss","hello-world","hw","jenkins","nginx","registry","sonarqube"]}

On obtient alors au format Json l’ensemble des images contenu dans la registry.

Pour en connaître ensuite le détail des tags existant pour une image, il va falloir élaborer une autre requête:


$ curl -X GET http://localhost:5000/v2/hello-world/tags/list

{"name":"hello-world","tags":["latest"]}


Il existe via cette API bien d’autres types de requêtes permettant de manipuler les informations contenues dans la registry et entre autre de les manipuler manuellement comment en faisant les push ou les pull avec la commande docker.

Pour en savoir plus la doc est la référence [4].

Références

[1] https://github.com/docker-library/docs/tree/master/registry
[2] https://docs.docker.com/registry/
[3] https://hub.docker.com/_/registry
[4] https://docs.docker.com/registry/spec/api/

mardi 6 août 2019

Rest avec Python


Après de nouveau un bon mois sans rien avoir poster dans le blog, voici la suite de l'article précédent sur ReST [rest-th] mais en rentrant un peu plus dans le concret.

Ainsi je vous propose de voir ce que python nous propose pour aborder cette problématique de réalisation ou d'interrogation d’une interface ReST.

Pour faire simple, nous allons considérer une population d’individu sur laquelle nous allons collecter des informations et que nous exposerons via une première interface ReST. Grâce à ce référentiel, nous pousserons un peu plus loin le travail en proposant une seconde interface ReST dont la logique ici sera d’exploiter la première interface afin de fournir divers indicateurs.



Le schema precedent présente les deux applications et leur environnement. L’idée est simple l’une expose des données génériques, l’autre les exploite pour exposer des données de plus haut niveau.

Rest-people

Cette partie de l’application est celle présentant les données à plat. Elle s’alimente sur une base de données (que l’on simplifiera par un liste par soucis de simplicité) et les exposera via deux interfaces ReST, un GET permettant de récupérer la liste complément des individu de la base et un GET permettant d’en sélectionner un seul en fonction de son Id. On complètera cette application par une méthode POST pour ajouter un élément à la population.

En python pour faire cela, on va commencer par créer des humains, des hommes et des femmes en faisant des classes python très classiques.


class Human:

    def __init__(self, id, name, age):
        self.id = id
        self.name = name
        self.age = age

    def __getitem__(self, name):
        return self.__getattribute__(name)

    def __setitem__(self, name, valeur):
        return self.__setattr__(name, valeur)

    def __delitem__(self):
        return ","


class Men(Human):

    def __init__(self, id, name, age):
        Human.__init__(self, id, name, age)


class Women(Human):

    def __init__(self, id, name, age):
        Human.__init__(self, id, name, age)


Ensuite avant de réaliser l’interface ReST, on va s'intéresser au format des données que l’on va manipuler. Ici pas de xml, mais du Json [json].

Dans python, pour manipuler du json, on utilise…. la librairie Json… c’est aussi simple et dans les faits la seule chose dont on va avoir besoin ce sont les méthodes “jsonify“ et “loads“.

  • La première nous servira à transformer un objet en json à la particularité que l’objet en paramètre doit être un dictionnaire ou une liste de dictionnaires. 
  • La seconde à l’inverse nous chargera notre json… pourtant comme le travail est fait à moitié, on va devoir compenser un peu et au passage se faciliter la vie.

En l'occurrence nous allons utiliser du code permettant de serialiser les informations d’un objet (avec les données des attributs, le nom de classe ou son module) et à l’inverse de deserialiser afin de recréer les instances. Ce code peut se trouver sur internet [json-conv].


def convert_to_dict(obj):
    """
    A function takes in a custom object and returns a dictionary representation of the object.
    This dict representation includes meta data such as the object's module and class names.
    """

    #  Populate the dictionary with object meta data
    obj_dict = {
        "__class__": obj.__class__.__name__,
        "__module__": obj.__module__
    }

    #  Populate the dictionary with object properties
    obj_dict.update(obj.__dict__)

    return obj_dict


def dict_to_obj(our_dict):
    """
    Function that takes in a dict and returns a custom object associated with the dict.
    This function makes use of the "__module__" and "__class__" metadata in the dictionary
    to know which object type to create.
    """
    if "__class__" in our_dict:
        # Pop ensures we remove metadata from the dict to leave only the instance arguments
        class_name = our_dict.pop("__class__")

        # Get the module name from the dict and import it
        module_name = our_dict.pop("__module__")

        # We use the built in __import__ function since the module name is not yet known at runtime
        module = __import__(module_name)

        # Get the class from the module
        class_ = getattr(module, class_name)

        # Use dictionary unpacking to initialize the object
        obj = class_(**our_dict)
    else:
        obj = our_dict
    return obj


Enfin maintenant que les éléments sont en place, il reste à mettre en oeuvre l’interface ReST. Pour cela on va utiliser le framework Flask [flask] qui permet comme avec Spring-WS (nous y reviendrons) de spécifier des routes associées aux verbes http et décorant des méthodes qui seront alors exécuté en fonction des chemins appelés.

Mais avant cela initialisons le contexte Flask: il nous faut des imports, un jeu de données (oui parce que dans cet exemple, on va pas non plus faire une BDD  pour 3 humains….) et définir le main qui construira le contexte Flask:


#!flask/bin/python
from flask import Flask, jsonify, request
import json

from json_tk import convert_to_dict, dict_to_obj
from human import Men, Women

people = [
    Men(1, "Bob", 12),
    Women(2, "Alice", 10)
]

app = Flask(__name__)

if __name__ == '__main__':
    app.run(debug=True, port=5001, host='0.0.0.0')


Maintenant on va définir les méthodes associées aux routes et verbes http.


@app.route('/humans', methods=['GET'])
def get_humans():
    return jsonify([convert_to_dict(human) for human in people])


@app.route('/humans/<int:human_id>', methods=['GET'])
def get_human(human_id):
    return jsonify([convert_to_dict(human) for human in people if human.id == human_id][0])


@app.route('/humans', methods=['POST'])
def post_human():
    print("REQUEST:" + str(request.data))
    json_response = json.loads(request.data)
    human = dict_to_obj(json_response)
    human.id = len(people)+1
    people.append(human)
    return jsonify(human.id)


On lance ca avec IntelliJ et on consulte les chemins avec un navigateur (http://0.0.0.0:5001/humans)


[
  {
    "__class__": "Men", 
    "__module__": "human", 
    "age": 12, 
    "id": 1, 
    "name": "Bob"
  }, 
  {
    "__class__": "Women", 
    "__module__": "human", 
    "age": 10, 
    "id": 2, 
    "name": "Alice"
  }
]


Pour le test du POST, on va utiliser Postman [postman], un outil indispensable pour tester une API ReST.

On interroge alors la liste et on voit que notre nouvel humain est bien la!


[
  {
    "__class__": "Men", 
    "__module__": "human", 
    "age": 12, 
    "id": 1, 
    "name": "Bob"
  }, 
  {
    "__class__": "Women", 
    "__module__": "human", 
    "age": 10, 
    "id": 2, 
    "name": "Alice"
  }, 
  {
    "__class__": "Men", 
    "__module__": "human", 
    "age": 24, 
    "id": 3, 
    "name": "Micka"
  }
]

ReST-people-stat

On a une première application qui fournit des données de base. La seconde doit s’interfacer sur celle-ci et disons

  • fournir la liste des humains tel quel
  • fournir la moyenne des âges des humains
Il faut un outil pour interroger la première interface. Pour cela on va utiliser le framework  python_http_client qui fournit un client http.


import json
import functools
from flask import Flask, jsonify
from python_http_client import Client

from response import str_http_response
from json_tk import dict_to_obj, convert_to_dict
from human import Moyenne

client = Client(host='http://localhost:5001/humans')
app = Flask(__name__)

if __name__ == '__main__':
    app.run(debug=True, port=5002, host='0.0.0.0')

On va ajouter une classe calculant la moyenne en utilisant la librairie functools:


import functools

class Moyenne:

    def __init__(self, humans):
        self.moyenne = (functools.reduce(lambda x, y: x.age + y.age, humans)) / len(humans)


Ensuite on va d’un côté faire un recall pour voir comment fonctionne le client.

@app.route('/recall', methods=['GET'])
def get_recall():
    response = client.get()

    str_http_response(response)

    json_response = json.loads(response.body)
    humans = [dict_to_obj(human) for human in json_response]
    print("HUMANS" + str(humans))
    return jsonify([convert_to_dict(human) for human in humans])


Et on va pouvoir implementer la methode get_moy. pour  cela on aussi utiliser un module permettant une approche map/reduce. Je vous laisse analyser le code:


@app.route('/moy', methods=['GET'])
def get_moy():
    response = client.get()
    str_http_response(response)

    json_response = json.loads(response.body)
    humans = [dict_to_obj(human) for human in json_response]
    print("HUMANS" + str(humans))

    moyenne = Moyenne(humans)
    print("MOYENNE:" + str(moyenne))
    return jsonify(moyenne.__dict__)


Il ne reste plus qu’à tester! On lance l’application people. La second ensuite, on vérifie alors la methode recall:


[
  {
    "__class__": "Men", 
    "__module__": "human", 
    "age": 12, 
    "id": 1, 
    "name": "Bob"
  }, 
  {
    "__class__": "Women", 
    "__module__": "human", 
    "age": 10, 
    "id": 2, 
    "name": "Alice"
  }
]


Puis on regarde si la moyenne fonctionne:


{
  "moyenne": 11.0
}


Pour le jeux on ajoute dynamiquement un nouvel humain dans l’application people… avec Postman et on vérifie que la moyenne à changé:


{
  "moyenne": 13.0
}


Voilà nous avons fait le tour de notre application en deux temps. Pourquoi en deux parties? ba parce que ça va être un bon prétexte de mettre ça dans des conteneurs docker! Mais ça sera pour le prochain article!

Références

[rest-th] https://un-est-tout-et-tout-est-un.blogspot.com/2019/06/rest-introduction.html
[json-conv] https://school.geekwall.in/p/ByaW0IVqN/json-the-python-way
[json] https://medium.com/python-pandemonium/json-the-python-way-91aac95d4041
[flask] https://flask.palletsprojects.com/en/1.1.x/
[rest-tuto] https://www.codementor.io/sagaragarwal94/building-a-basic-restful-api-in-python-58k02xsiq
[flask-mega] https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world
[postman] https://www.getpostman.com/