Architecture micro-services

Bonjour,

Comme je vous disais dans l’article sur Hateoas, je vais maintenant vous parler de l’architecture micro-services. Nous verrons les points communs et les différences avec les autres types d’architecture.

Les points communs

L’architecture micro-service se base sur MVC (pour Model View Controller ou en français : Modèle Vue Contrôleur).
Sur ce point, pas de révolution, votre application aura toujours une partie pour l’accès aux données (Modèle), une partie qui sera le point d’entrée de votre application (Contrôleur) et la partie pages web (Vue).

Comme toute architecture, elle n’est pas liée à un langage particulier mais représente une façon de faire applicable à tout type de langage (sauf exception).

Les différences

Première différence, le contrôleur n’est pas un contrôleur web standard mais le plus souvent un contrôleur REST (basé sur les webservices de type REST).
Ca permet de renvoyer des pages html entières ou directement des flux json à la vue.

Deuxième différence, et la plus importante à mon avis, la responsabilité des contrôleurs.
Chaque contrôleur doit avoir une et une seule responsabilité. C’est-à-dire, gérer un seul type d’objet que ce soit pour la création, modification, affichage ou suppression. Et chaque fonction du contrôleur ne doit faire qu’une seule chose (l’ajout par exemple).

Si lorsque vous ajoutez un nouveau produit, vous souhaitez avoir la liste mise à jour, vous devrez faire deux appels au serveur. Le premier appel permettra l’ajout du nouveau produit et lorsque le retour est « Création OK », alors vous faites le deuxième appel au serveur qui lui servira à renvoyer la liste de tous les produits.
Si vous avez lu l’article précédent sur Hateoas, vous voyez l’intérêt de coupler ces deux notions. Ainsi le niveau de maturité 3 que représente Hateoas vous permettra de communiquer plus en détail avec le serveur et ainsi pouvoir découper vos actions de façon minimaliste.

Souvent avec les micro-services, les gens ne savent pas bien découper le travail et mélange les différentes actions dans une même fonction d’un même contrôleur. L’inconvénient est que la maintenance et les évolutions seront plus chères car plus compliquées.
En découpant de façon minimaliste la responsabilité d’une fonction (ce qu’elle doit faire), vous diminuez sa complexité et donc le cout de sa maintenance.
Imaginons que vous avez une fonction qui renvoie tous les produits et les sous-catégories, car vous n’avez pas respecté les micro-services. Maintenant il faut que vous ne renvoyez plus les sous-catégories car le client ne les veux plus dans cette page. Vous devez modifier plusieurs parties de votre fonction, ce qui augmente le risque de régression et d’impacts sur d’autres pages.
Dans le cas des micro-services, vous n’avez juste qu’à supprimer l’appel aux sous-catégories dans le javascript. Le risque de régression étant quasiment nul et la complexité pareil (sauf si votre JS est mal codé 🙂 ).

Troisième point, votre architecture coté serveur ressemble à vos urls.
C’est-à-dire que si vous avez store/product/ dans votre url, vos packages cotés serveurs auront la même architecture.
Cette logique est identique coté javascript si vous utilisez un framework du type angular.
L’avantage est que même sans connaitre l’architecture du projet, vous pouvez vous y retrouver facilement coté serveur si on vous a donné l’url de la page à modifier ou inversement si vous savez où est le contrôleur.

Voilà, c’était une petite présentation sur l’architecture micro-services, qui j’espère vous donnera l’envie d’en savoir plus et pourquoi pas de la mettre en place sur vos nouveaux projets (modifier l’architecture d’un projet déjà existant est souvent long, compliqué et couteux).

Likes(0)Dislikes(0)

Hateoas

Bonjour,

Aujourd’hui, je veux vous parler du niveau de maturité de maturité de communication de webservices rest : hateoas.
Cet article fera volontairement des raccourcis et sera vulgarisé.

Tout d’abord, il faut faire un petit résumé rapide sur les webservices.

Les webservices

L’objectif d’un webservice est de permettre la communication entre deux machines sans qu’elles ne sachent quel langage de programmation chacune utilise.
Par exemple, un serveur java peut communiquer avec un serveur php sans que ça pose de problème. Le serveur qui met à disposition le webservice va dire ce qu’il attend en entrée comme format (XML pour la norme SOAP par exemple), les informations qui devront être obligatoirement renseignées, celles qui sont facultatives, etc. En sortie, il renverra un fichier, qui lui aussi qui sera normé.

Il existe deux normes de webservice : SOAP (basé sur les fichiers XML) et REST (basé sur le protocole HTTP).
L’avantage du REST est qu’il peut directement appelé par un navigateur web.

Les développeurs se sont dit : « hé, si on peut appeler les webservices REST depuis un navigateur, il y a moyen de développer une application web qui serait basé que sur des webservices REST. Et non plus des controleurs web d’un coté et webservices de l’autre. »
Et oui, avant on devait faire un controleur web qui renvoyait, par exemple, une page d’affichage de données et si un serveur distant devait également avoir accès à ces mêmes données, on devait faire un webservice qui lui renvoyait. Maintenant, on peut faire un seul et même point d’entrée : le webservice REST qui pourra renvoyer les données aussi bien au navigateur qu’à un autre serveur.

Oui, mais on doit pouvoir donner des informations sur les échanges entre les machines.
Si mon navigateur envoie des données qui ne sont pas attendues par le webservice, ce dernier doit pouvoir lui dire qu’il y a eu un problème.

C’est là qu’intervient les différents niveaux de maturité des webservices.

Les maturités des API webservices

Niveau 0

Dans ce niveau, le plus bas, tout se passe en POST (signifie normalement qu’on envoie des données au serveur) sur une même url et le serveur répondra toujours 200 (code pour OK), que la requête se soit bien passée ou non.

Le problème est que pour afficher des données, le POST ne sert à rien; et le code 200 renvoyé, quelque soit le vrai état de la requête coté serveur, n’est pas satisfaisant car ça peut cacher une erreur.

Niveau 1

Avec ce niveau, on appelle toujours le serveur en POST, mais là on va enrichir l’url en lui disant par exemple quel objet on cherche à avoir.
Ex, si on veut récupérer l’utilisateur 42, l’url sera du type :
www.monsupersite.fr/user/42
Si on cherche à avoir le produit 12, l’url sera du type :
www.monsupersite.fr/product/12
Si on veut avoir tous les utilisateurs, l’url sera du type :
www.monsupersite.fr/users

Ainsi, on voit que l’url commence à « dessiner » ce qu’on fait réellement sur le site.

Niveau 2

Là, en plus d’avoir des url différentes suivant ce qu’on fait, on demande au serveur des données d’affichage avec le mot GET, l’ajout d’un nouvel élément avec le code PUT, la modification avec POST et la suppression avec DELETE.
Le serveur en retour répondra avec un code différencié du style : 201 pour dire que la création s’est bien passée, 404 pour dire que la ressource n’a pas été trouvée, etc.

Niveau 3 : hateoas

L’objectif de ce niveau est d’en plus d’avoir un échange verbeux entre les machines (niveau 2, pour rappel), permet aussi d’envoyer des liens vers d’autres webservices liés à l’action qu’on vient de faire.
Par exemple, si on veut récupérer les informations d’un utilisateur, on fera :
Appel en GET vers l’url : www.monsupersite.fr/user/42
Le serveur renvoie 200 et en plus des liens vers le webservice qui liste les produits achetés par ce même utilisateur.
Le retour est du style :

[
{
"user" : {
"id" : 42,
"name" : "toto",
"email" : "toto@monsupersite.fr",
"links" : [
{
"rel" : "self",
"href" : "http://www.monsupersite.fr/user/42"
}
],
"products" : {
"links" : [
{
"rel" : "self",
"href" : "http://www.monsupersite.fr/user/42/products"
}
]
}
}
}
]

Ainsi, en plus d’avoir les informations liées à l’utilisateur directement, nous avons aussi le lien vers le webservice qui permettra de récupérer les produits achetés par ce même utilisateur.

Il peut bien sur avoir plus d’une sous partie dans le résultat renvoyé par le serveur.

Comme il s’agit d’un degré de maturité proposé par une personne, Leonard Richardson, il ne s’agit pas d’un standard. Donc chacun peut faire ce qu’il veut.
A mon sens, l’intérêt de Hateoas est d’autant plus important si on l’utilise dans le cadre d’une application basée sur l’architecture microservices (qui sera expliqué dans le prochain article).

Sauvegarde journalière d’owncloud

Bonjour à tous,

Aujourd’hui je vais vous expliquer comment programmer facilement une sauvegarde quotidienne d’owncloud.
Mon script fonctionne pour les personnes qui sont restées avec la base de données SQLite (base de données mise par défaut avec owncloud).

L’objectif est de faire une copie du répertoire owncloud afin d’avoir les fichiers d’owncloud et les données renseignées.

Dans un premier temps, il faut créer un répertoire où l’on mettra les sauvegardes.
mkdir /sauv_owncloud
mkdir /sauv_owncloud/owncloud_backup

Dans mon exemple, je les ai mises dans le répertoire /sauv_owncloud/owncloud_backup/

Ensuite, il faut créer un fichier .sh qui contiendra nos commandes qui feront les sauvegarde. Je l’ai appelé backup.sh :
vi /sauv_owncloud/backup.sh
Et il faut y mettre le code suivant :
BACKUPDIR=/sauv_owncloud/owncloud_backup/;OWNCLOUDDIR=/var/www/pulic_owncloud/;TODAY=`date +"%Y%m%d"`;AVANTHIER=`date --date='-2 day' +"%Y%m%d"`;cp -r ${OWNCLOUDDIR} ${BACKUPDIR}${TODAY}_owncloud 2>> ${BACKUPDIR}cron.log && rm -r ${BACKUPDIR}${AVANTHIER}_owncloud 2>> ${BACKUPDIR}cron.log;
Chez moi, owncloud se trouve dans le répertoire /var/www/public_owncloud.

N’oubliez pas de mettre les droits de l’utilisateur voulu sur le fichier (chown nomutilisateur:nomgroupe backup.sh).

Puis tapez la commande suivante :
crontab -u nomutilisateur -e
Et mettez à la fin la ligne :
0 0 * * * sh /sauv_owncloud/backup.sh
Ainsi, votre script se lancera tous les jours à 00h00.
Il fera une copie du répertoire d’owncloud avec la date du jour et supprimera la copie de l’avant veille. Ainsi, si votre dernière sauvegarde a un raté, il vous restera celui de la veille.

Likes(0)Dislikes(0)

Désactiver le compte invité sous Lollipop

Bonjour à tous,

Et oui, je sais, ça fait quelques temps qu’on n’avait rien publié, mais le temps manque parfois. 🙂

Aujourd’hui, je vais vous expliquer comment désactiver le compte invité sous Lollipop. Et oui, je ne sais pas si vous l’avez remarqué, mais Google a ajouté un compte invité. Le plus sympa, c’est qu’on peut passer dessus même si l’écran verrouillé. Cette session permet par défaut de téléphoner (idée géniale si on se fait voler son portable).

Pour désactiver ce compte, il faut afficher la barre de notification (en faisant glisser son doigt du haut de l’écran vers le bas). Là apparait l’icône de votre compte. Cliquez dessus et vous allez voir apparaitre une autre icône marquée « invité ». Cliquez dessus pour basculer sur cette session.
Une fois que vous êtes sur la session invitée, refaites apparaitre la barre de notification et recliquez sur l’icône de session. Vous arrivez de nouveaux sur les deux icônes de session. Faites un appui long sur l’icône « invité » et cliquez ensuite sur « supprimer ». Ca va vous demander de confirmer votre choix, ce que vous faites.
Vous rebasculez automatiquement sur votre session et la session invité est désactivée de votre téléphone.

Maj : Si vous pouvez encore jouter un utilisateur quand l’appareil est activé, cliquez sur la photo de votre profil. Ensuite, allez sur plus de paramètres et sur les … en haut à droite et décocher « Ajout utilis. quand appareil verr. » et normalement c’est bon.

Maj 2 : Pour que ce qui est décrit ci-dessus fonctionne, il faut qu’il y ait une sécurité pour déverrouiller l’écran (au minimum le schéma). S’il n’y a que le balayage, on peut toujours ajouter un compte invité.

Je vous ferais un ou deux autres articles sur quelques trucs et astuces sous Lollipop.

Bonne journée à vous tous,

Likes(4)Dislikes(14)

Le cron sous Owncloud

Et oui, encore un article sur owncloud (et non, je n’ai pas d’action chez eux 🙂 ).

Je voulais vous parler d’un petit réglage intéressant à connaitre sur owncloud, il s’agit de la réactualisation des informations. Ce réglage est présent dans la partie administration et est global pour tout owncloud (et non par utilisateur).

Par défaut, la réactualisation se fait via l’ajax. En gros, lorsqu’un utilisateur affiche une page, ça lance un appel ajax afin que le serveur réactualise les informations (pour les contacts, calendrier, news, etc).
L’avantage est que pour avoir l’actualisation, il suffit de ré-afficher une page. L’inconvénient, c’est que si vous êtes sur un petit serveur (par exemple raspberry), ça surcharge vite la machine, et la bande passante.

Il existe deux autres options : webcron et cron.
Si j’ai bien compris le webcron permet d’appeler le réactualisation des informations via une requête http. L’avantage est lorsqu’on n’a pas accès au système du serveur pour ajouter un cron. L’inconvénient est qu’il faut s’inscrire à un service tiers qui réalisera cette opération et que la réactualisation des données est périodique.

Le cron permet de lancer de façon automatique la réactualisation des informations, qu’on soit connecté ou non. L’avantage est que c’est le serveur qui gère ça. L’inconvénient est qu’il faut avoir accès au système du serveur et que la réactualisation est périodique.

Pour le webcron et le cron, normalement c’est vous qui choisissez la période. Perso, mes info sont réactualisées tous les quarts d’heures.

Voyons maintenant comment passer en cron.

Premièrement, il faut que se connecter sur la machine sur laquelle est installé owncloud en ssh (via putty par exemple)
Il faut ensuite taper la commande suivante :
crontab -u www-data -e
*/15 * * * * php -f /var/www/owncloud/cron.php

Le /15 signifie que le cron doit tourner toutes les 15 minutes. A vous de changer ce temps s’il ne vous convient pas.

Une fois ça fait, il suffit d’aller dans la partie administration et de choisir Cron :
Cron dans owncloud

Vous pouvez voir qu’à coté du titre, il est notifié si la tache tourne bien et quand elle a tourné pour la dernière fois (en heure GMT, soit en été pour la France heure actuelle – 2 heures).

Et voila, votre owncloud fonctionne en cron. L’intérêt est que vous pouvez avoir vos flux rss rafraichis sans avoir besoin d’aller sur le site. Ce qui est utile quand vous avez une application de lecture de flux rss sur votre téléphone qui est synchro avec votre owncloud.

Likes(2)Dislikes(0)