Webcampak

Documentation Webcampak 3 en ligne

Mon, 13 Mar 2017 10:00:00 +0000

Basée sur le logiciel mkdocs pour la partie web et pandoc pour la création de la version PDF, nous allons faire de notre mieux pour maintenir la documentation à jour.

La documentation est accessible à l’address suivante: http://doc.webcampak.com/webcampak3.x/web/en/ et n’est, pour le moment, disponible qu’en Anglais.

Pandoc nous permet de construire un PDF automatiquement à chaque changement de la documentation, ce dernier est disponible à cette adresse: http://doc.webcampak.com/webcampak3.x/web/en/PDF/User_Guide.pdf

Comme d’habitude, n’hésitez pas à nous contacter si vous avez des questions ou des commentaires.

Mecanisme d'alerte automatisé

Thu, 01 Dec 2016 10:00:00 +0000

Nous avons rapidement compris, lorsque nous avons dévelopé le système, que la gestion des alertes est un aspect tout aussi critique que sensible à mettre en place. Trop d’alertes créé une accoutumance (et diminue le niveau d’attention de la personne recevant les alertes), pas assez peut entrainer des pertes de clichés.

Webcampak 2

Lors de nos précédentes versions, la gestion des alertes en série sur les captures d’images était très efficace. La configuration se faisait sur trois points:

Définir le seuil d’alerte à partir duquel une alerte est envoyée (après X échecs de capture)
Définir à quel fréquence envoyer un rappel
Définit si l’on souhaite être alerté à chaque rétablissement de la capture (même si on reste sous le seuil d’alerte).

Aucune difficulté pour générer des alertes sur la source directement connecté à l’appareil photo, la capture a fonctionné ou non, c’est aussi simple que ça.

Là Webcampak manquait par contre de flexibilité sur les sources de consolidation, en particulier les sources distantes. Par exemple, un Webcampak sur site, capture à deux rythmes différents et envoi ses clichés sur le Cloud. Comment gérer cette différence de planning tout en prenant en compte de possibles retard causés par le réseau ?

Pour éviter l’envoi de faux positifs, la configuration des alertes sur le cloud devenait un jeu d’équilibriste demandant de la précision.

Webcampak 3

Nous avons donc réfléchi à une meilleure manière de réaliser cette configuraiton et d’envoyer les alertes corresondantes. La configuration peut dorénavant se réaliser de deux manières:

Sur un retard de capture
Sur un calendrier

Alerte sur retard de capture

Ce mode est le plus simple à configurer et reprend un concept très similaire au Webcampak 2.

A intervale régulier le système calcule le temps écoulé depuis la dernière capture. Si ce temps se situe au dessus du seuil configuré, une alerte est envoyée.

Le système continue ensuite à vérifier l’état de la source, puis renvoie un email de rappel à intervale régulier jusque au retour en fonctionnement du système.

Alerte sur calendrier

Le second mode consiste à définir à l’avance un calendrier de capture et vérifier que les images soient présentes au moment souhaité.

En configurant le seuil d’alerte sous forme de créneaux de capture manqués, ce mode permet de gérer facilement un nombre illimité de rythmes de captures différents sur une même source.

Là aussi, le système configure à vérifier l’état de la source et renvoir un email de rappel à intervale régulier.

Il est aussi possible de définir une période de “grace”, pour retarder la déclaration d’une alerte en cas de retard dans la transmission de l’image.

Deux modes compatibles

Les deux modes peuvent être utilisés simultanément. Il est par exemple possible de configurer le système pour déclencher une alerte sur la base du calendrier, plus envoyer un reminder toutes les heures (sur base du retard de capture), le tout pour plus de souplesse.

Conclusion

Cette nouvelle fonctionalité permet de rendre la déclaration des alertes plus simple et aussi plus pertinente, en particulier pour les sources distantes.

Couplé à l’envoi journalier des statistiques de captures il devient quasiment impossible de rater un incident, ceci sans recevoir trop d’emails.

Suivi des versions Webcampak

Mon, 21 Nov 2016 10:00:00 +0000

Nous avons très récemment sorti la version 3.0.1 du Webcampak, à peine deux semaines après la version 3.0.0 et vous vous demandez (légitimement) quelle est la signification de ces numéros de versions.

Une incrémentation du dernier chiffre indique que les changements associés à cette mise à jour ne vont pas casser la compatibilité avec la version précédente. Par exemple le migration de la version 3.0.3 vers la version 3.0.4 ou de la version 3.0.1 vers la version 3.0.7 devrait être simple et peu risquée.

Une incrémentation du second chiffre indique un changement pouvant potentiellement impacter la configuration existante. Par exemple une modification de la structure des fichiers de configuration des sources. La migrations vers cette version doivent donc se faire avec précaution. Par exemple migrer de la version 3.0.10 vers la version 3.1.0. Nous essayerons autant que possible de bien documenter la procédure de migration vers toute version majeure.

Une incrémentation du premier chiffre indique une mise à jour majeure de l’application (changement de framework, nouvelle fonctionalité ayant un impact sur l’ensemble du système, …). Dans ce cas précis, il sera probablement conseillé de réaliser une installation fraiche du système. Par exemple migrer de la version 3.1.10 vers la version 4.0.0

Voilà en espérant avoir été clair sur notre plan concernant les numéros de versions.

Une histoire d'insecte ... et de migration.

Wed, 26 Oct 2016 10:00:00 +0000

Comme vous le savez peut être, nous sommes actuellement en train de migrer nos serveurs cloud vers la nouvelle version du Webcampak. Les tests sont terminés et le système est maintenant prêt pour le déploiement.

Stratégie de migration

Nous avons donc plusieurs terabytes de données à transférer entre nos serveurs. Pour limiter les risques d’incidents et d’interruptions, nous réalisons une migration Active/Active.

La procédure est la suivante; nous installons le Webcampak sur un nouveau serveur, réalisons un duplicata des fichiers, reconfigurons le Webcampak distant pour envoyer les clichés vers le nouveau serveur à la place de l’ancien. Puis réalisons une nouvelle synchronisation des fichiers pour transférer les derniers clichés.

Cette procédure limite l’interruption et nous permet aussi de revenir en arrière facilement.

Mais parfois tout ne se passe pas comme prévu …

Synchronisation des clichés

Nous avons donc commencé à transférer les clichés, mais maintenant que nous avons cette fonctionalité de synchronisation des clichés, nous avons décidé de l’utiliser à la place de Rsync.

Nul doute qu’avec Rsync la manipulation aurait été plus rapide, une seule commande pour copier l’ensemble des clichés pour l’ensemble de nos clients sur le serveur. Mais utiliser notre fonctionalité de synchronisation, bien qu’ayant à initier le transfer pour chacun de nos clients, nous permet aussi de réaliser un peu de test de charge.

Un nombre de clichés importants

Et ce fut le drame…

Nous exagèrons un peu étant donné l’absence d’impact pour nos clients. Mais ça a mis en lumière un point que nous n’avions pas validé lors de nos tests. Nous avions testé avec quelques milliers de fichiers, plus précisément les 8640 clichés capturés lors des vieilles charrues 2011.

Aucuns problèmes lors des différents tests de transfer, dans les deux sens (disant vers local ou local vers distant).

Revenons donc au sujet de ce billet, l’étape suivante consistait donc à sauvegarder une “vraie” source, un projet en cours et ses plus de 58300 clichés pour plus de 200GB (ci-dessous).

Etant confiant, autant lancer quelques synchronisations en parralèlle pour les différents clients à migrer.

L’application de visualiation des rapports devint inaccessible… Impossible de consulter les rapports, remplacés par des messages d’erreurs en provenance de notre API.

Un diagnostique rapide

Trouver la cause du soucis n’a pas été très complexe.

Pour améliorer la réactivité du système et économiser les resources système, en particulier pour les Webcampak installés sur site, nous avons tendance à privilégier le stockage d’information système par rapport au calcul ou à la génération de ces informations. L’espace disque pour ce type de fichiers est rarement problématique, et dans ce cas précis nous stockions tout simplement beaucoup, beaucoup, trop d’informations.

Le rapport stockait la liste des fichiers présents sur la source, sur la destination, les fichiers communs entre les deux source, les fichiers manquants sur la source et enfin les fichier manquants sur la destination.

Beaucoup trop, d’autant plus qu’à court terme seul les fichiers manquants sur la destinations (les fichiers à transférer) nous étaient utiles.

La solution a donc consisté à supprimer les informations inutiles et compresser (GZip) la liste des fichiers manquants dans un fichier à part (cette liste n’étant utilisée qu’une seule fois). Nous ne conservons dans ce rapport que quelques statistiques (nombre de fichiers, taille).

Quelques lignes de code plus tard et les informations inutiles (pour le moment) enlevés, tout était rentré dans l’ordre, avec un rapport de synchronisation passant de 70MB à 1.7MB. Nous aurions pût pousser encore plus loin et ne pas conserver la liste, faisant passer le rapport de synchronisation à 3.9KB mais nous aurions perdu un historique pouvant se révéler utile pour de futures fonctionalités.

Voici notre insecte (bug) identifié et éliminé, nous pouvons reprendre nos activités.

Webcampak 3.0 en production - La synchronisation

Fri, 21 Oct 2016 10:00:00 +0000

Synchronisation de fichiers

Ce nouveau module, que nous avons appellé, “Sync-Reports”, permet à nos clients de répondre aux problématiques suivantes:

S’assurer que tous les clichés ont correctement étés transférés sur un serveur distant
Ajouter un nouveau serveur distant et y transférer l’ensemble des clichés
Transférer les clichés n’ayant pas étés transférés du fait d’une panne réseau

Fonctionnement du système

Le fonctionnement est assez simple, une fois une demande de rapport créée, le Webcampak va comparer les fichiers situés à deux emplacement différents. Il utilisera pour comparer chaque fichier, son nom, son emplacement et sa taille.

Le Webcampak va ensuite générer un rapport, qui pourra ensuite être utilisé pour initier le transfer des fichiers manquants.

Création du rapport

Lors de la création du rapport, l’utilisateur renseigne la source et la destination qu’il souhaite comparer.

Le rapport est ensuite placé dans une file d’attente et est traité.

Analyse du rapport

Le rapport affiche des informations sur les clichés présents sur la source, présents sur la destination, communs entre les deux, absent de la source ou absent de la destination.

Il ne reste plus qu’à cliquer sur “Re-run & Sync” pour déclencher le transfer des fichiers.

Webcampak 3.0 en production - Le transfer de fichiers

Thu, 20 Oct 2016 10:00:00 +0000

Après de nombreuses ré-installations, redémarrages et coupures (controllées et impromptues) nous avons maintenant un système aussi stable que la version précédente, tout en amenant de nombreuses améliorations.

Ce billet est le premier d’une série détaillant les nouvelles fonctionalités de cette nouvelle version du Webcampak.

Transfer de fichiers

Nous avons maintenant deux modes pour le transfer de fichier:

le mode série, envoyant les fichiers dès leur capture par le Webcampak. Cette fonctionalité est la même que précédemment, après les manipulations choisies, les fichiers sont envoyés sur le serveur distant de votre choix.
le mode xfer, place les fichiers dans une file d’attente et les envoie à la vitesse permise par la bande passsante disponible.

Ces deux modes fonctionnent en FTP, mais nous pouvons à tout instant, et simplement, ajouter de nouveaux modes de connexion.

Ce nouveau mode xfer répond à deux problématiques que nous avons rencontrés sur nos projets, les périodes de fortes augmentation du rythme de capture et les dégradations temporaires de la connectivité réseau.

Augmentation du rythme de capture

Durant certaines phases du projet nos clients souhaitent parfois fortement augmenter la cadence de prise de clichés (par exemple un cliché toutes les 20 secondes). En mode série et pour éviter l’engorgement du système, il était nécessaire de s’assurer que l’ensemble du processus de capture soit terminé avant de démarrer le suivant. Et, selon le mode de capture sélectionné, la connectivitié réseau pouvait se révéler bloquante.

Précédemment nous contournions de problème en désactivant temporairement l’envoi de fichier (nos Webcampak ont habituellement entre 250GB et 500GB de stockage local) pour ensuite re-synchroniser le tout progressivement.

Ce nouveau mode permettra d’éviter de réaliser ces ajustements, le système continuera d’envoyer au rythme préalablement sélectionné, seule la taille de la file d’attente augmentera.

Dégradations de la connectivité réseau

Ce problème est de loin le plus problématique car difficile à prévoir car non lié à nos infrastructure. Il est arrivé pour certains Webcampak que la bande passante baisse très fortement, ce qui en plus de retarder l’arrivée des clichés, créé un engorgement des resources sur le Webcampak en lui même.

Bien qu’étant équippé depuis de nombreuses versions d’un mécanisme permettant de décider combien de fois tenter l’envoi d’un cliché avant d’abandonner, la baisse de performances représente un challenge problématique dans le sens où l’envoi des clichés est fonctionnel. Le Webcampak n’avait donc pas conscience de cette difficulté (une coupure réseau est par contre facile à traiter et ne posait pas de problèmes) et commençait à empiler les processus de capture jusqu’à saturation.

Fonctionnement du mode Xfer

Lorsque ce mode de transfer est utilisé, plusieurs files d’attentes sont crées, chacune de ces files d’attendre recevra un ordre de traitement pour l’envoi des fichiers. Les files d’attentes sont communes à l’ensemble du Webcampak et isolées des autres processus de traitement (une source envoi un ordre au système xfer, mais n’agit pas directement sur la file d’attente).

La configuration se fait ensuite à plusieurs niveaux, lors de la configuration générale, nous indiquons au système le nombre des files d’attentes que nous voulons créer, et le nombre maximum de fichiers que peut contenir chaque file d’attente.

Ces paramètres varieront en fonction du type de matériel sur lequel le Webcampak est installé. Un serveur cloud controllant 50 Webcampak aura des réglages différents d’un Webcampak installé sur un chantier.

Ensuite lors de l’ajout d’un serveur distant, vous pourrez choisir d’activer le mode xfer et pourrez définir combien ce serveur distant pourra supporter d’envoie en parrallèle.

Le système s’assurera ensuite de répartir la charge de travail entre les différentes files d’attentes tout en respectant la configuration choisie.

Par exemple, sur la capture d’écran ci-dessus, vous pouvez constater que le système dispose de 3 files d’attentes de configurées mais seules 2 sont utilisés.

Avantages, Inconvénients

Le système xfer se révèle particulièrement intéressant dans les cas où la connectivité réseau peut être instable ou insuffisante pour transférer les clichés en temps réel.

Il entraine néanmoins un possible délais dans l’envoi des clichés (par exemple si la file d’attente contient déjà des clichés) et une très légère augmentation de l’utilisation des resources locales.

Nous recommendons d’utiliser le mode xfer dans la majeure partie des cas, seuls certains cas précis tels que l’envoi d’une image “live” sur un site Web, font que le mode série conserve sa pertinence et c’est pourquoi le Webcampak conserve ces deux modes. 0

Webcampak 3.0 est 'feature complete'

Mon, 15 Aug 2016 10:00:00 +0000

Comme avez put le constater, la mise à jour vers la version 3.0 a pris beaucoup plus de temps que prévu. Durant cette migration, nous avons changé de nombreux éléments clefs du système.

Le Webcampak est divisé en plusieurs composants, chacuns ayant un rôle précis dans le système.

Le fonctionement interne

L’interface graphique

L’interface a été entièrement ré-écrite pour devenir plus modulaire, structurée et permettre l’ajout plus facile de nouvelles fonctionalités.

Le framework Sencha Extjs/Touch 4.x a été remplacé par Sencha Extjs 6.x.

L’API

Précédemment basée sur un framework PHP custom, l’API a été entièrement ré-écrite et est maintenant basée sur le framework Symfony.

Le Core

La capture d’image est les opérations internes sont gérés par un coeur en Python, l’ensemble a été lui aussi ré-écrit et le framework CLI Cement est maintenant utilisé pour les appels à ces outils faisant parti du coeur du Webcampak.

Cette ré-écriture nous a aussi permis de nettoyer le code et enlever des fonctionalités qui n’étaient pas utilisées.

La Base de Données

Nous essayons au maximum de limiter les dépendences à la base de données, mais elle reste nécessaire pour toute la partie base utilisateurs et authorisations. Nous avons migré la base de données de MySQL vers SQLite, ce qui rend l’ensemble un peu plus léger.

Les fonctionalités

Mais ce qui vous intéressera probablement le plus sont les nouvelles fonctionalités et les changements du Webcampak qui vous impacterons au jour le jour.

Nous détaillerons prochainement ces différents changements, mais pour faire simple, un effort important a été dédié à rendre la gestion d’un ou d’une flotte de Webcampak plus simple, ainsi que de simplifier la gestion des incidents (panné réseau par exemple), voici une rapide liste de ces changements.

Rapports de synchronisation

Le Webcampak est maintenant en mesure de comparer les photos qu’il a stocké en interne à une source distance. Et si des différences sont trouvés, l’utilisateur peut décider de transférer les fichiers manquants.

Ces rapports peuvent êtres générés à n’importe quel moment, et peuvent par exemple êtres utilisés pour re-synchroniser un nombre important de fichiers après une panne réseau.

Xfer

La fonctionalité Xfer est une file d’attente pour les transfer de fichiers. Précédemment le transfer de fichier était sérialisé à la capture, avec Xfer ce transfer se déroule en parralèle des captures et vous permet de transférer à un rythme défini sans risquer de saturer le Webcampak.

Cette fonctionalité permet aussi de capturer, pour de courtes périodes, à un taux plus important que la bande passante disponible. La file d’attente Xfer se déroulant à son propre rythme.

Emails

Le système envoie dorénavant de meilleurs emails résumant la capture du jour, et pour les utilisateurs possédant plusieurs Webcampak, un seul email est envoyé chaque jour (et non un email par Webcampak comme précédemment)

Nouvelle interface mobile

Une nouvelle interface mobile a été développée, elle fourni plus de détails sur le bon déroulement des captures et permet de réaliser quelques manipulations simples.

Et Ensuite ?

Nous allons maintenant entrer un phase de correction de bugs, et préparer Webcampak 3.0 pour son entrée en production. Une grande étape a été franchie !

Nouveau site web

Mon, 10 Aug 2015 10:00:00 +0000

Nous avons donc réalisé une migration vers jekyll.

Jekyll peut être considéré comme un compilateur de sites web. Il analyse des templates, des fichiers markdown et génère le site web correspondant.

Vu que Jekyll n’utilise pas de fichiers PHP, les besoins de mise à jour et les risques de sécurité en sont grandement réduit. De plus, Github supportant Jekyll nativement, nous pouvons tout héberger sur cette plateforme.

Les Panam Games à Toronto

Fri, 24 Apr 2015 19:07:50 +0000

Notre Webcampak à Toronto était aux premières loges.

Webcampak 3.0 - Development on track

Fri, 24 Apr 2015 19:07:50 +0000

Parmi les nombreuses fonctionnalités dans les tuyaux, nous sommes actuellement en train de complètement ré-écrire l’interface d’administration. L’objectif est toujours de donner un maximum de contrôle et d’autonomie à nos clients dans l’utilisation de leur Webcampak(s). En faisant une utilisation plus poussée de nos APIs REST, chaque Webcampak pourra faire office de centre de contrôle pour les autres Webcampak, permettant une configuration centralisée, le tout sans nécessiter de serveur spécifique.

Il y a quelques années le Webcampak faisait ses premiers pas dans le cloud, il va dorénavant mettre le pied dans le “BigData”.

Nous allons aussi améliorer la gestion transfert de données et en particulier dans les situations tendues (rythme de capture supérieur à la bande passante, panne électrique sur le dispositif de stockage de masse pour les projets à forte cadence, …). Nos process existant nous permettent d’êtres avertis en cas d’incident et les différents mécanismes dont nous disposons (principalement un cache volumineux) nous permettent d’éviter de perdre les clichés. Nous allons ajouter une couche d’automatisation complémentaire pour limiter encore les interventions en cas d’incident en donnant au Webcampak la capacité de déterminer par lui même si incident est terminé et si il peut transférer les clichés qu’il a stocké dans son cache pendant un incident.

Au niveau matériel, nous visons une baisse de la consommation, un support natif de la 4G/LTE et probablement un boitier plus compact.

De nombreuses autres nouveautés devraient suivre, stay tuned.