MyDMAM est système de gestion de médias centralisé que je développe seul depuis quelques années. J'avais déjà écrit ici il y a quelque temps un article de présentation. Voici des nouvelles fraiches.
Les changements depuis un an
- L'ajout d'un système de watchfolder distribué, pour transcoder des médias depuis un dossier via plusieurs machines sans qu'elles se marchent sur les pieds.
- L'intégration d'un serveur FTP (Apache Mina / FTPd) (protocole encore utilisé dans le monde des médias) qui permet de suivre facilement l'activité des comptes depuis une page web.
- L'analyse du loudness audio, transparent et applicable massivement sur des dossiers contenant des fichiers vidéo et audio. En utilisant la libebur128, via ffmpeg, je récupère et remonte en base de donnée des statistiques de LUFS, de niveaux audio et de courbes de loudness.
- L'analyse plus poussée des fichiers MXF via la BMX BBC MXF.
- La prise en charge du système archivage sur bandes (propriétaire) Active Circle dans la navigation de fichiers et la recherche intégrée.
- Quelques corrections de bug, du refactoring, beaucoup de refactoring : la stabilité étant ma première préoccupation.
Et une nouvelle version vient d'être publiée
Cette nouvelle version est la première à proposer des archives téléchargeables depuis le site, et comportant un script de préparation à lancer après l'extraction. Pour ce faire, un gros travail a été fourni pour créer une méthode de build permettant la génération et de téléchargement d'archives zip/tar.gz prêtes à l'emploi, téléchargeables.
Ce nouveau mode de package dispense de l'installation préalable d'une JVM et du déploiement de Play ! Framework car ils sont inclus dans les archives. Il n'y a plus non plus de dépendance avec Git pour l’installation.
Il facilite aussi le déploiement de zéro car il y a aussi un package pour les bases de données testé et prêt à l’emploi.
Tous les packages sont préparés pour Windows, macOS et Linux, mais n'ont été testé que sous Linux Debian 8 pour le moment.
L'ancienne approche basée sur le code, via git, et reposant toujours sur Play 1 reste possible, notamment dans un cadre de développement (votre IDE compilera).
Plus techniquement, cette version marque d'abord la fin de la refonte de du moteur de l'interface web.
L'objectif était de passer d'une façon de générer des pages à une autre. Plus précisément ? de passer à un mode ou les pages web étaient générés côté serveur tout en ayant une petite interactivité côté client avec jQuery, vers un mode ou l'ensemble de l'interface est téléchargée et générée côté client, avec React JS, et l'interaction avec le serveur ne se fait plus que grâce à des échanges dynamiques de données les plus petits et les plus rapides possibles.
Visuellement, ce que ça change ? Pas grand-chose, l'interface reste la même. Mais elle est devenue beaucoup plus rapide dans la navigation entre les éléments et les pages.
Cette transition permet beaucoup de choses :
- l'utilisation ici de React facilite beaucoup le développement d'interfaces complexes, et accélère la réactivité des pages pour l'utilisateur.
- comme toutes les infos échangées par le serveur passent par des données optimisées pour cela (messages json), il sera facile de bâtir une API HTTP REST plus tard.
- l'ancien mode reste disponible pour d'autres besoins, soit en injectant du contenu html dans React, soit en générant des pages de 0 sans React (mais toujours sous la protection des sessions) avec Groovy.
Enfin, une correction et amélioration de la méthode de session utilisée dans Play, avec un contrôle stricte de la durée d'une session, et la gestion de la déconnexion côté client/javascript.
Pas de révolution, juste de l'évolution. Je dispose maintenant d'un socle fonctionnel, évolutif et stable. A moi maintenant d'ajouter plus de fonctions et de possibilités renversantes ; ce ne sont pas les idées qui manquent !
Enfin, il y a quand même une révolution : on peut quand même déployer MyDMAM en quelques minutes (testé sur Debian 8) !
Et même s'il y en aura jamais assez, j'ai écrit un peu de doc, notamment sur la performance et la sécurité.
# Et les logs ? Dockers ?
Posté par Mimoza . Évalué à 4.
Salut,
Je suis heureux de voir que tu continue a faire vivre ton projet.
Tu ne parle pas des logs, as tu changé de ton système maison pour Log4J ?
Pour le déploiement en quelques minutes c'est a base de scripts ? As tu regarder du coté de dockers qui est très a la mode en ce moment ?
[^] # Re: Et les logs ? Dockers ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
Merci Mimoza !
Oui, je ne l'ai pas mentionné ici, mais j'ai basculé sur log4j. Mon ancien système de log m'a beaucoup appris, mais log4j est aussi puissant que simple et pratique. La marche a passer est un peu haute au début, et après cela va tout seul.
Le déploiement n'est pas vraiment "automatique". C'est un script ant qui mache le travail, et un script bash (un pour linux, un pour macOS) pour la pose de chemins absolus dans les déclarations de services (de fait, ils sont produits pas le bash).
Pour windows, j'utilise WinRun4J (64). Il n'y a même pas besoin de scripts pour lui.
Docker… je suis pas trop fan car je n'ai pas encore touché ses avantages par rapport aux inconvénients. Notamment par le fait que ça fait un truc de plus à gérer et tester car je suis obligé de garder un déploiement traditionnel. Et je n'aime pas les modes. Techniquement, il n'y a aucune contre-indication à Docker.
[^] # Re: Et les logs ? Dockers ?
Posté par Mimoza . Évalué à 3.
Pour Docker non ça ne te fait pas un truc de plus a générer, mais plutôt 2 de moins. Ça te remplaceras tout tes script de déploiement en un seul. Tu peux même regarder du coté de Vagrant pour avoir un couche d'abstraction en plus.
[^] # Re: Et les logs ? Dockers ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Non, car je préfère garder un fonctionnement hors Docker. Il n'est pas disponible partout, demande des prérequis d'admin que tout le monde n'a pas, je ne connais pas son comportement sur des FS exotiques et lors de gros IO et enfin je manque de visibilité sur du long terme. En tout cas c'est mon avis. Si quelqu'un propose une config Docker et un how-to, je l’intégrerai !
# choix d'architecture logiciel
Posté par steph1978 . Évalué à 3.
Est-ce que tu as une documentation qui décrit tes choix techniques.
En particulier, je trouve les choix de ELS et Cassandra très overkill pour ce type d'application.
Même si je peux comprendre que ce sont des outils avec lesquels il est intéressant de se familiariser.
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Je n'ai pas encore de documentation écrite "pointue". Je pense que cela va venir au fur et a mesure.
Pour les choix de ES et de Cassandra, se sont le résultat de grosses réflexions car le besoin est très varié. j'aimerai me passer de l'un ou de l'autre, voir des deux, mais ce n'est pas encore possible.
J'ai notamment besoin :
Et tout cela depuis 2011, au moment ou j'ai commencer les travaux sur MyDMAM.
Pleins de technos peuvent répondre à ces besoins. Mais il n'y en a que peut qui sont facilement accessibles de 0, libres, sans avoir une courbe d’apprentissage très raide.
[^] # Re: choix d'architecture logiciel
Posté par Quinane . Évalué à 2.
Tout d'abord bravo. L'occasion aussi de te remercier pour ton ExtendCopy que j'utilise pour copier massivement (Tio), et sûrement, sur tous les OS.
Le LL ou l'OS ont encore du chemin à faire dans le monde des médias. Mais entre MediaInfo (merci Zenitram !), FFmpeg, des sociétés comme Mikros qui contribue sur pas mal de projets, ou comme Intellique, pour les NAS/SAN (et leur solution d'archivage n'est pas libre mais en utilise), il y a déjà de bonnes briques !
[^] # Re: choix d'architecture logiciel
Posté par steph1978 . Évalué à 2.
De la copie de fichier en java, j'avoue, c'est couillu..
Wut !
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
Pourquoi un problème avec Java ? Les perfs ne sont pas ridicules du tout ! et c'est parfois plus simple à déployer quand on doit jouer avec des OS un peu anciens ou exotiques.
Pour les dates et les droits, c'est une volonté.
En archivage de média, la date d'archivage (ici de copie) est importante car elle marque le début du stockage sur un nouveau support d'archives des éléments de travail. Ensuite, ça arrive d'avoir des gros systèmes qui ne sont pas du tout à l'heure (ou qui ne la gère pas) et de se retrouver avec une date qui ne correspond à rien.
Pour les droits, ça n'a pas beaucoup d’intérêt en archivage car c'est très rare que cela serve, sans compter les potentiels problèmes avec des montages de FS réseau qui gèrent ça très mal (ou qui mentent, c'est pareil).
Pour les histoires de dates et de droits, rsync fait ça très bien ! Et il y a toujours moyen de modifier ExtendCopy pour le prendre en charge.
[^] # Re: choix d'architecture logiciel
Posté par steph1978 . Évalué à 3.
Je sais que les perf sont bonnes, j'ai joué avec du mmap en java et ça marche très bien. Mais une JVM et plus de 700MB de mémoire pour copier une arborescence, c'est pas sexy.
En fait, pour moi, je problème est plus profond. Je fais plus confiance à une série d'outil utilisé depuis la nuit des temps qu'un logiciel monolithique fait ad-hoc.
J'ai lu la doc qui parle de déplacer le contenu d'un NAS vers un SAN. Outre le fait que je ne comprends pas comment on replace l'un par l'autre, ce n'est pas un cas d'archivage.
Un avantage par rapport aux commandes GNU serait de faire le checksum en même temps que la lecture. Mais ce n'est pas ce que fait l'outil, d'après la doc.
Rien ne m'oblige à me servir de extendcopy en effet. C'est juste pour la discussion : j'aime regarder dans les boîtes à outils :)
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 3.
En fait, pour mieux comprendre le pourquoi, il faut comprendre le besoin :
T'a des To de fichiers (qq Mo à 100 Go) étalés dans des stockages hétérogènes, dans des stations de travail spécialisées, dans des vieux stockages, dans des SAN/NAS à protocoles et clients proprios.
Tu doit bricoler des montages de montages, rebondir de machines en machines. Via des vieux linux, des vieux macs.
Et le but c'est de tout réunir pour l'envoyer dans un stockage "sur" qui est parfois le sas d'entrée vers un système d'archive vers LTO.
Et la copie est lancée, t'a 150000 fichiers, la copie va prendre une 30aine d'heures. Tu voudrait enlever certains types de fichiers, et donc tu voudrait faire un tri préalable avant de tout lancer. Et parfois la copie rate en cours. Un montage saute. Les perfs s'effondrent. Pire, un file system saute et bloque net le transfert. Obligé de reboot.
Et tu ne veux pas tout recommencer, le scan, le tri, les copies, etc…
Le calcul du débit moyen et instantané pour détecter les pb avec le FS, c'est redoutable quand il que dit que tu fait du 2 MB/sec en moyenne et du 100 MB/sec en instantané.
ExtendCopy est fait pour cela. Surtout pour cela.
Ensuite, ce n'est peut-être pas clair, mais il calcul un MD5 (ou autre) pendant la copie, le note, et il y a une fonction qui fait un replay sur les fichiers copiés et qui vérifie les mesures.
Le fichier produit en sorti (un txt tabulé) est la preuve de ce qui a été copié, et que c'est bien copié. Quand on parle client/fournisseur/prestation/assurance/facturation, c'est important.
J'ai fait ce dev car… j'ai rien trouvé pour faire cela facilement. Les scripts bash, c'est bien quand t'est chez toi a ton bureau, c'est chaud quand t'est en clientèle, dans leur nodal, à 4 pattes par terre devant le seul écran trouvé, le nez sur un XSAN bardé de bad-blocs.
[^] # Re: choix d'architecture logiciel
Posté par Quinane . Évalué à 2.
Le checksum à la volée, c'est piégeux. Pour cela, il y a dc3dd, un outil Forensic, patch de GNU dd, et donc en GPL.
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 3.
Pourquoi est-ce piégeux ?
[^] # Re: choix d'architecture logiciel
Posté par Quinane . Évalué à 1.
Lire le même flux que celui de la copie ne permet pas de voir de corruption inhérente à la mémoire ou en amont. J'avais lu un article de Microsoft que je ne retrouve plus, qui expliquait pourquoi il n'avait pas implémenté de vérif' à la volée des copies à cause de cela. Il expliquait ainsi que si les données corrompues sont dans le tampon ou en mémoire, une relecture ne détectera pas la corruption. La vérification a posteriori, surtout si les fichiers sont gros comme en médias est plus sûre car les données lues sont celles du disque. C'est résumé, désolé si ce n'est pas clair.
[^] # Re: choix d'architecture logiciel
Posté par steph1978 . Évalué à 4.
On ne parle pas de paralléliser les lecture+checksum+écriture+vérification ;
mais lecture+checksum+écriture et de faire la vérification après ;
au lieu de lecture+écritre puis lecture+checsum puis vérification.
Le gain est qu'on ne lit qu'une fois au lieu de deux.
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Oui, et le cache disque, c'est bien, mais ça a ses limites. Quand on pelte des Go de fichiers, vient vite le moment ou c'est depuis les disques que viennent les données. L'idée du cksum ici est surtout une façon absolue de dire que la copie est intégrale plus de dire que le fichier source n'est pas altéré. Si un cksum n'a pas été calculé au moment d'écrire la première fois, on ne peut plus savoir (enfin être certain) que le fichier est toujours intègre au moment de son archivage.
[^] # Re: choix d'architecture logiciel
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Wow ! ExtendCopy, ça marche toujours ?! C'est super vieux dev ! Il mériterai peut-être rafraîchissement avec NIO2.
Et… ça va ? Pas de problèmes ou de manques en particulier ?
Oui, le LL arrive là où le proprio atteins ses limites (notamment en terme de tarifs). Le monde des médias évolue énormément, et des gens comme Netflix font leurs petites révolutions, y compris dans le LL.
[^] # Re: choix d'architecture logiciel
Posté par Quinane . Évalué à 2. Dernière modification le 27 mars 2017 à 21:10.
Désolé de répondre que maintenant.
Le non respect des dates et des permissions n'était pas un problème. Au contraire même parfois.
Et… ça marche.
RSync, sur OSX, c'est antédiluvien (ils en sont toujouts encore à des versions <3). Ça marche aussi vous me direz.
+1
Oui Netflix qui, si mes souvenirs sont bons, ont libéré leurs outils de contrôle des instances EC2. Leur blog technique est souvent intéressant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.