Définir des rôles avec Ansible pour Nexus Repository Manager v3.x


Savez-vous comment automatiser l’installation ainsi que la configuration de Nexus Repository Manager version 3.x avec Ansible ? Pas encore ? On vous donne un coup de pouce ici !

Pour rappel, Ansible est un outil de déploiement qui permet à des playbooks d’automatiser les déploiements d’applications et d’infrastructure. L’avantage clé d’Ansible est sa flexibilité puisqu’il permet de modifier les applications avec souplesse et de les appréhender en tant que service. Toutefois, Ansible possède également quelques faiblesses. Avec une conception volontairement simple, il fonctionne uniquement comme une application de paramètres sans tenir compte de la disponibilité de l’information et des problèmes de sécurité, qui doivent alors être gérés par d’autres systèmes. C’est pourquoi un grand nombre de développeurs préfèrent utiliser Ansible en complémentarité avec un système d’agent actif comme Puppet ou avec un outil de gestion centralisé comme Ansible Tower.

Automatisation avec Ansible

Ansible se concentre sur la configuration au niveau de l’application, les scripts d’approvisionnement pouvant être exécutés sur tout outil de support d’infrastructure (PaaS, conteneurs, bare-metal, Vagrant, etc.). Ansible ne nécessite qu’une connexion SSH et un compte sudo sur le système distant.

Les scripts d’approvisionnement Ansible sont écrits dans un style déclaratif à l’aide de fichiers YAML regroupés en rôles. Les instructions atomiques des rôles sont déclarées à l’aide d’un certain nombre de modules de base fournis par Ansible. Consultez la documentation Ansible pour une introduction en profondeur.

Réapprovisionnement et mise à jour de la configuration

L’un des modèles DevOps pour gérer les mises à jour de configuration consiste à fournir un nouvel environnement à partir de zéro et à éliminer complètement l’ancien (pensez à des images de conteneur). Cela implique une gestion fiable de votre cycle de vie des données. Dans notre cas particulier du Nexus Repository Manager, cela consiste à plusieurs gigaoctets d’artefacts téléchargés / mandatés, de certains journaux d’audit et d’objets OrientDB contenant la configuration. Par conséquent, en fonction des contraintes de l’environnement, il peut être logique de mettre à jour la configuration d’une instance Nexus préalablement approvisionnée. La nature déclarative des instructions de base d’Ansible est répond bien à cette contrainte, mais toute logique personnalisée écrite dans un rôle devrait être idempotente et prendre en compte la logique « créer ou éventuellement mettre à jour ».

Il faut également noter que certaines parties de la configuration Nexus ne peuvent pas être mises à jour. Voici quelques exemples :

  • Les paramètres relatifs aux BlobStores
  • Le mot de passe administrateur si vous le perdez (mise à jour: peut-être par cette voie)

Comment bien intégrer l’API Groovy de Nexus avec Ansible

Les étapes de base de l’installation sont très simples et peuvent toutes être écrites en utilisant des modules simples de base Ansible :

  • Télécharger et décompresser l’archive
  • Créer un utilisateur / groupe système
  • Créer un service systemd

(Ces étapes sont dans les tâches / nexus_install.yml)

Et puis vient la surprise : la configuration Nexus n’est pas disponible dans un fichier texte simple qui peut être édité à l’aide d’instructions simples Ansible. Elle est stockée dans une base de données OrientDB intégrée qui ne doit pas être modifiée directement. La manière documentée de configurer Nexus est soit par son interface utilisateur Web, soit par son API d’intégration.

La façon dont l’API d’intégration fonctionne est la suivante :

  1. Écrire un script Groovy qui gère vos changements de configuration;
  2. Charger le script sur Nexus à l’aide d’un requête HTTP PUT, créant une ressource REST pour ce script;
  3. Appeler le script via sa ressource HTTP GET / POST

Module URI à la rescousse !

Le module uri d’Ansible envoie des requêtes HTTP, fournissant une automatisation de ces étapes.

La première étape consiste à téléverser le script Groovy sur Nexus. Notez que le script peut déjà être présent. Par conséquent, lors des ré-exécutions du playbook, nous essayons de le supprimer avant d’entreprendre d’autres actions, par le biais de tasks/declare_script_each.yml, comme suit :

  ---
  - name: Removing (potential) previously declared Groovy script {{ item }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script/{{ item }}"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      method: DELETE
      force_basic_auth: yes
      status_code: 204,404

  - name: Declaring Groovy script {{ item }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      body_format: json
      method: POST
      force_basic_auth: yes
      status_code: 204
      body:
        name: "{{ item }}"
        type: 'groovy'
        content: "{{ lookup('template', 'groovy/' + item + '.groovy') }}"

Les requêtes HTTP sont exécutées à partir de l’hôte cible, c’est pourquoi localhost est utilisé ici. force_basic_auth: yes s’assure que le client HTTP n’attende pas une réponse 401 avant de fournir des informations d’identification. Autrement, Nexus répondra immédiatement avec une réponse 403 lorsque aucune authentification n’est passée. status_code est l’état HTTP attendu de la réponse fournie par Nexus. Étant donné que le script Groovy peut ne pas nécessairement exister à ce moment-là, nous devons également accepter le code d’état 404.

L’étape suivante consiste à appeler le script Groovy créé via l’appel HTTP précédent. La plupart des scripts prendront certains paramètres d’entrée (par exemple, créer un utilisateur <x>), et c’est là que Ansible et Groovy aideront. Tous deux issus de l’âge des principes REST, ils peuvent parler et comprendre le format JSON de manière relativement transparente.

Du côté du script Groovy :

import groovy.json.JsonSlurper
parsed_args = new JsonSlurper().parseText(args)
security.setAnonymousAccess(Boolean.valueOf(parsed_args.anonymous_access))

Et pour appeler ce script à partir des arguments passés via Ansible  :

  - include: call_script.yml
    vars:
      script_name: setup_anonymous_access
      args: # this structure will be parsed by the groovy JsonSlurper above
        anonymous_access: true

Avec call_script.yml :

  ---
  - name: Calling Groovy script {{ script_name }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script/{{ script_name }}/run"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      headers:
        Content-Type: "text/plain"
      method: POST
      status_code: 200,204
      force_basic_auth: yes
      body: "{{ args | to_json }}"

Cela nous permet de passer de manière transparente les paramètres structurés de Ansible aux scripts Groovy, en gardant la structure, les tableaux et les types de base des objets.

Scripts Groovy pour Nexus : conseils et astuces pour le développement

Voici quelques conseils qui peuvent aider les développeurs travaillant sur les scripts Groovy.

Configurer le Classpath dans votre IDE

Comme décrit dans la documentation Nexus, avoir les scripts Nexus dans le classpath de votre IDE peut vraiment vous aider à travailler. Si vous automatisez la configuration de Nexus autant que possible, vous allez inévitablement tomber sur certaines API internes sans documentation. De plus, certaines parties de l’API n’ont aucune source disponible (par exemple, l’API LDAP). Dans de tels cas, un décompilateur peut être utile.

Puisque notre rôle sur Github utilise Maven avec toutes les dépendances nécessaires, vous pouvez simplement l’ouvrir avec IntelliJ et éditer les scripts situés dans « files/groovy ».

Points d’entrée de l’API de Scripting

Comme documenté, il y a quatre points d’entrée implicites pour accéder aux entrailles de Nexus à partir de votre script:

  • core
  • repository
  • blobStore
  • security

Ceux-ci sont utiles pour des opérations simples, mais pour tout ce qui est plus compliqué, vous devrez résoudre plus en profondeur les services par:

  • Indirection à partir des points d’entrée principaux: blobStore.getBlobStoreManager ()
  • Résolution d’un @Singleton interne du contexte du conteneur : container.lookup (DefaultCapabilityRegistry.class.getName())

Prenez des exemples du code source de Nexus

Certaines parties de Nexus (7,4%, selon Github) sont également écrites à l’aide de Groovy, contenant de nombreux bons exemples de code: CoreApiImpl.groovy.

Créer des requêtes HTTP à partir de l’interface Web de configuration (requêtes AJAX) fournit également des indications sur les structures de données attendues, les paramètres ou les valeurs de certains paramètres.

Enfin, mettre en place un débogueur distant depuis votre IDE vers une instance Nexus peut aider, car il existe de nombreux endroits où une structure de données très générique est utilisée (comme Map <String, Object>) et seule l’inspection au moment de l’exécution peut rapidement indiquer les types réels nécessaires.

Exemples détaillés

Voici quelques exemples commentés de scripts Groovy tirés du rôle Ansible

Configuration d’une Capability

Les Capabilities de Nexus  peuvent être configurées à l’aide d’une interface utilisateur unifiée. Dans notre cas, cela couvre:

  1. L’accès anonyme
  2. L’URL publique de base
  3. La marque (en-tête et pied de page HTML personnalisés).

Instructions :


    import groovy.json.JsonSlurper
    import org.sonatype.nexus.capability.CapabilityReference
    import org.sonatype.nexus.capability.CapabilityType
    import org.sonatype.nexus.internal.capability.DefaultCapabilityReference
    import org.sonatype.nexus.internal.capability.DefaultCapabilityRegistry

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // Type casts, JSON serialization insists on keeping those as 'boolean'
    parsed_args.capability_properties['headerEnabled'] = parsed_args.capability_properties['headerEnabled'].toString()
    parsed_args.capability_properties['footerEnabled'] = parsed_args.capability_properties['footerEnabled'].toString()

    // Resolve a @Singleton from the container context
    def capabilityRegistry = container.lookup(DefaultCapabilityRegistry.class.getName())
    def capabilityType = CapabilityType.capabilityType(parsed_args.capability_typeId)

    // Try to find an existing capability to update it
    DefaultCapabilityReference existing = capabilityRegistry.all.find {
        CapabilityReference capabilityReference -&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
            capabilityReference.context().descriptor().type() == capabilityType
    }

    // update
    if (existing) {
        log.info(parsed_args.typeId + ' capability updated to: {}',
                capabilityRegistry.update(existing.id(), existing.active, existing.notes(), parsed_args.capability_properties).toString()
        )
    } else { // or create
        log.info(parsed_args.typeId + ' capability created as: {}', capabilityRegistry.
                add(capabilityType, true, 'configured through api', parsed_args.capability_properties).toString()
        )
    }

Configuration d’un mandataire de dépôt Maven

    import groovy.json.JsonSlurper
    import org.sonatype.nexus.repository.config.Configuration

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // The two following data structures are good examples of things to look for via runtime inspection
    // either in client Ajax calls or breakpoints in a live server

    authentication = parsed_args.remote_username == null ? null : [
            type: 'username',
            username: parsed_args.remote_username,
            password: parsed_args.remote_password
    ]

    configuration = new Configuration(
            repositoryName: parsed_args.name,
            recipeName: 'maven2-proxy',
            online: true,
            attributes: [
                    maven  : [
                            versionPolicy: parsed_args.version_policy.toUpperCase(),
                            layoutPolicy : parsed_args.layout_policy.toUpperCase()
                    ],
                    proxy  : [
                            remoteUrl: parsed_args.remote_url,
                            contentMaxAge: 1440.0,
                            metadataMaxAge: 1440.0
                    ],
                    httpclient: [
                            blocked: false,
                            autoBlock: true,
                            authentication: authentication,
                            connection: [
                                    useTrustStore: false
                            ]
                    ],
                    storage: [
                            blobStoreName: parsed_args.blob_store,
                            strictContentTypeValidation: Boolean.valueOf(parsed_args.strict_content_validation)
                    ],
                    negativeCache: [
                            enabled: true,
                            timeToLive: 1440.0
                    ]
            ]
    )

    // try to find an existing repository to update
    def existingRepository = repository.getRepositoryManager().get(parsed_args.name)

    if (existingRepository != null) {
        // repositories need to be stopped before any configuration change
        existingRepository.stop()

        // the blobStore part cannot be updated, so we keep the existing value
        configuration.attributes['storage']['blobStoreName'] = existingRepository.configuration.attributes['storage']['blobStoreName']
        existingRepository.update(configuration)

        // re-enable the repo
        existingRepository.start()
    } else {
        repository.getRepositoryManager().create(configuration)
    }

Créer un rôle

    import groovy.json.JsonSlurper
    import org.sonatype.nexus.security.user.UserManager
    import org.sonatype.nexus.security.role.NoSuchRoleException

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // some indirect way to retrieve the service we need
    authManager = security.getSecuritySystem().getAuthorizationManager(UserManager.DEFAULT_SOURCE)

    // Try to locate an existing role to update
    def existingRole = null

    try {
        existingRole = authManager.getRole(parsed_args.id)
    } catch (NoSuchRoleException ignored) {
        // could not find role
    }

    // Collection-type cast in groovy, here from String[] to Set&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
    privileges = (parsed_args.privileges == null ? new HashSet() : parsed_args.privileges.toSet())
    roles = (parsed_args.roles == null ? new HashSet() : parsed_args.roles.toSet())

    if (existingRole != null) {
        existingRole.setName(parsed_args.name)
        existingRole.setDescription(parsed_args.description)
        existingRole.setPrivileges(privileges)
        existingRole.setRoles(roles)
        authManager.updateRole(existingRole)
    } else {
        // Another collection-type cast, from Set&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; to List&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
        security.addRole(parsed_args.id, parsed_args.name, parsed_args.description, privileges.toList(), roles.toList())
    }

Le rôle est disponible sur Ansible Galaxy et Github. Il comporte:

  • Le téléchargement et l’extraction de Nexus
  • La création de l’unité de service systemd
  • (Facultatif) La configuration d’un reverse-proxy Apache supportant SSL
  • La configuration du mot de passe administrateur
  • La configuration LDAP
  • La configuration des privilèges et des rôles
  • La création des utilisateurs locaux
  • La configuration des Blobstores
  • La configuration de tous les types de dépôts
  • La spécification de l’URL de base
  • La mise en place de la marque (en-tête HTML et pied de page personnalisés)
  • La mise en place des tâches automatiques

 

Maîtriser la génération de thumbnails sur Liferay 7CE et DXP

par

Maîtriser la génération de thumbnails avec Liferay DXPLe Thumbnail Generator vise à améliorer la génération de thumbnails, proposée par Liferay.

Ce plugin a été créé au cours d’un projet nécessitant la présence d’un très grand nombre de thumbnails de dimensions précises, afin d’optimiser au maximum les temps de chargement des pages Web. En effet, Liferay offre seulement  deux thumbnails lors du chargement d’une image sur la plateforme. Le Thumbnail Generator permet donc d’avoir un contrôle total sur le nombre de thumbnails créés, mais aussi sur la façon dont ils sont créés.

Après avoir brièvement décrit les principaux composants de ce plugin, j’expliquerai comment le configurer pour maîtriser complètement la génération de thumbnails avec Liferay.

I. Description des composants du plugin

Les Listeners

Le Thumbnail Generator utilise deux Model Listeners permettant de repérer les événements de création, de modification et de suppression de documents dans l’application Liferay. Un document peut correspondre à n’importe quel type de fichier (texte, image, vidéo, pdf…), nous verrons plus tard comment configurer le plugin pour qu’il traite uniquement les documents nous intéressant.

Le premier Listener repère la création et la modification d’un document, puis crée ou met à jour les thumbnails du document.
Le deuxième repère la suppression d’un document et supprime dans la foulée les thumbnails qui lui sont associés.

Le Servlet Filter

Le Servlet Filter intercepte toutes les requêtes faisant appel à un document de l’application et effectue une série de vérification avant de renvoyer un thumbnail en réponse.

Il va tout d’abord analyser les paramètres de la requête afin de savoir si un thumbnail est demandé. Le filtre va ensuite vérifier que le thumbnail existe bel et bien, pour finalement le retourner à l’auteur de la requête. Si l’une de ces vérifications échoue, la requête sera ignorée par le filtre et elle suivra son cours normal, retournant le document original demandé.

Le ThumbnailService

Enfin, le ThumbnailService s’occupe de la création/suppression des thumbnails et de leur organisation dans le système de stockage de Liferay, en utilisant les paramètres de la configuration du plugin.

II. Utilisation du plugin

L’utilisation du Thumbnail Generator se résume à la configuration du plugin et à la récupération des thumbnails.

Configuration

La page de configuration du Thumbnail Generator (Menu => Control Panel => Configuration => System Settings => Thumbnail Configuration) permet de définir deux options :

  • Le format des fichiers qui seront traités par le plugin : par exemple, pour restreindre la création de thumbnails pour les fichiers de type JPG et PNG, il suffit d’ajouter ces formats dans la configuration et tous les autres fichiers ne seront pas pris en compte par le plugin.
  • Les lignes de commande permettant de créer les thumbnails : pour définir un thumbnail à générer, il faut ajouter une ligne dans la configuration avec la syntaxe suivante : ‘nom:commande. Le nom permettra par la suite d’accéder à ce thumbnail, la commande correspond à la ligne de commande qui générera le thumbnail (voir la documentation ImageMagick pour explorer toutes les options possibles).
    Par exemple : ‘img_480:convert ${inputFile} -resize 480×270 ${outputFile}‘ permet de générer un thumbnail de dimension 480×270 et qui sera récupérable grâce à son nom « img_480 ».

 page de configuration du Thumbnail Generator

Dans la capture d’écran ci-dessus, trois thumbnails différents seront créés pour chaque fichiers .jpg et .png chargés dans l’application Liferay.

La configuration du plugin permet de contrôler le nombre de thumbnail à générer, mais aussi la façon dont ils sont créés. La commande convert provient de la très puissante librairie de retouche d’image ImageMagick.
À la place de cette commande, on aurait pu utiliser toute autre commande exécutable sur la machine hebergeant l’application.

Récupération des thumbnails

Une fois  que le module est déployé et configuré, il est prêt à l’utilisation. Des thumbnails seront générés automatiquement lors de l’upload de documents dans l’application.
Pour récupérer un thumbnail d’un document, il suffit d’ajouter le paramètre « thumb={nomDuThumbnail} » dans l’url faisant appel à ce document.

Exemple
L’URL  d’un document (test.jpg) sur une instance Liferay en local ressemble à ceci : http://localhost:8080/documents/20147/0/test.jpg/0d72d709-3e48-24b3-3fe6-e39a3c528725?version=1.0&t=1494431839298&imagePreview=1
L’URL d’un thumbnail associé à ce document, dont le nom est img_480, pourra être appelé de la façon suivante : http://localhost:8080/documents/20147/0/test.jpg/0d72d709-3e48-24b3-3fe6-e39a3c528725?version=1.0&t=1494431839298&imagePreview=1&thumb=img_480

III. Administration

Afin de donner plus de contrôle à l’utilisateur dans la gestion de ce module, une page d’administration (votre site > Configuration >  Thumbnails administration) a été créée permettant d’effectuer quelques actions sur les thumbnails :

  • Re-générer tous les thumbnails.
  • Effacer tous les thumbnails.
  • Effacer les thumbnails orphelins (qui ne sont plus liés à aucun documents mais qui sont toujours présents à cause d’un changement de la configuration).

Administration du Thumbnail Generator

En conclusion, ce bref tutoriel vous a présenté le plugin Liferay appelé Thumbnail Generator et décrit comment utiliser, configurer, récupérer les vignettes et administrer le plugin. Téléchargez, essayez et faites nous part de vos commentaires !

Notre expertise et la puissance des technologies open source dans Azure

Logos Microsoft + Savoir-faire Linux  

 

 

 

Nous sommes heureux de vous annoncer la sortie d’une vidéo promotionnelle produite par Microsoft eux-même ! Fruit d’une collaboration autour de la plateforme Azure, cette vidéo souligne la pertinence et l’essor des technologies open source dans l’environnement infonuagique Azure de Microsoft ainsi que notre capacité d’innovation en combinant technologies open source et solutions infonuagiques hybrides.

Premier  «partenaire Microsoft Open Source» au Canada

Savoir-faire Linux est, depuis 2015, le premier  «partenaire Microsoft Open Source» au Canada. Ce partenariat rappelle notre force : la conception et l’intégration de technologies libres et open source dans des écosystèmes complexes ou hybrides, comme la plateforme Azure. Nous aidons nos clients grâce à l’innovation des technologies ouvertes et à des alliances stratégiques pour maximiser la puissance des systèmes d’information complexes ou hétérogènes et créer des environnements spécifiques pour nos clients.

Pour Microsoft, l’open source fait désormais partie intégrante de l’approche quotidienne de l’innovation cloud. En tant qu’expert et chef de file de l’industrie du logiciel libre et  des technologies open source au Canada, Savoir-faire Linux se devait d’offrir des moyens d’améliorer l’expérience des utilisateurs et des développeurs en ajoutant à son éventail de solutions, la plateforme Azure, désormais compatible avec de nombreuses technologies open source.

Savoir-faire Linux, partenaire Platinium au Liferay Symposium 2017 Paris

En quête d’une expérience digitale enrichie ? Envie de créer des environnements personnalisés à travers le web, mobile et objets connectés ? Le Liferay Symposium est pour vous ! Le Symposium est l’occasion de poser vos questions, d’échanger sur les bonnes pratiques Web d’aujourd’hui et de découvrir Liferay,  le portail web open source de référence.

Partenaire Platinum du Liferay Symposium 2017 à Paris et expert en solutions Liferay, Savoir-faire Linux vous donne rendez-vous les 26 et 27 avril 2017 au Pavillon Dauphine pour rencontrer notre équipe, échanger avec l’éditeur et imaginer ensemble vos prochaines solutions d’affaires. Du site web client léger ou riche à l’application critique d’entreprise hautement sécurisée, en passant par la gestion de contenu web, la gestion documentaire, l’intégration d’applications métier… Liferay se présente comme la solution de référence mondiale, fiable, flexible et puissante pour propulser la stratégie numérique de votre entreprise !

Du 26 au 27 avril, plus de 200 membres de la communauté Liferay sont attendus : développeurs, chefs de projet, décideurs techniques ou métier et partenaires Liferay. À travers plusieurs présentations, partages des bonnes pratiques et retours d’expérience (dont Airbus, Danone, CNAF, Msheireb et TOTAL), nous tenterons de repenser les parcours clients, de casser les silos organisationnels et de créer des nouvelles expériences digitales cohérentes sur l’ensemble des canaux… Bref, autant d’impératifs et de sujets qui seront abordés lors de cette 7ème édition.

Ne manquez pas l’occasion d’en apprendre plus sur les solutions Liferay et de découvrir l’expertise de nos équipes au service de l’expérience client !

  • 26 avril : Rencontre technique
  • 27 avril : Symposium

Érudit, un savoir à cultiver… librement

Premier diffuseur de ressources francophones en sciences humaines et sociales en Amérique du Nord, Érudit s’est refait une beauté en 2017. Fruit d’un travail d’un an et demi, cette refonte technique et visuelle offre de nouvelles fonctionnalités, auxquelles notre expert Python Morgan Aubert s’est fait un grand plaisir de contribuer.

En accès libre
Avant d’aborder cette refonte, revenons un petit peu en arrière. En 1998, les Presses de l’Université de Montréal lancent Érudit, plateforme de ressources pour les sciences humaines et sociales. Six ans plus tard, en 2004, elle bénéficie du soutien d’un consortium unissant l’Université de Montréal, l’Université Laval et l’Université du Québec à Montréal. Cette union renforce Érudit dans sa mission de diffuser en accès libre du contenu de haut niveau dans plus de 30 disciplines : des revues savantes et culturelles, des livres, des actes, des mémoires, des thèses ainsi que des rapports de recherche.

Ce volume conséquent de plus de 200 000 documents fait de la plateforme un acteur de référence pour la recherche francophone, contribuant au partage du savoir et encourageant par là même la publication scientifique en français sur le territoire nord-américain. En 2016, le compteur des consultations est monté 21 millions !

Par ailleurs, Érudit s’est engagé dès sa création envers l’utilisation des logiciels libres : son environnement de travail, son infrastructure et ses services reposent sur des logiciels libres. Directeur des technologies du consortium, Davin Baragiotta insiste sur le fait d’avoir «la capacité d’utiliser des technologies développées/maintenues par des tiers, d’y contribuer au besoin -comme on a pu le faire- et de mettre à disposition notre propre code en vue d’une réutilisation complète ou partielle par des tiers. C’est une culture technique de partage et de collaboration qui permet d’avoir une meilleure capacité de développement et de maintenance de nos TI. Aussi, d’un point de vue organisationnel, cette approche technique s’inscrit dans une culture plus large d’ouverture, de collaboration et de partenariat. Essentiellement, Érudit met en valeur des contenus scientifiques et culturels que l’on veut voir d’avantage diffusés en Open Access. »

Lors des travaux préliminaires de la refonte, le projet visait à doter Érudit d’une plateforme moderne qui permettra une évolution continue et une extension des fonctionnalités. Il s’agissait donc de réécrire la plateforme en Python/Django en remplacement de Cocoon/Drupal/WordPress, mais en gardant la même couverture fonctionnelle. C’est dans ce contexte que notre expert Morgan Aubert a travaillé en tant consultant développeur Python. Il y a fait du développement back end et front end, en utilisant le framework web Django, alors que les développements front end impliquaient Javascript et Sass.

Bonjour Morgan, quels ont été les défis techniques auxquels tu as confronté pour cette plateforme ?
L’un des principaux défis technologiques était lié au gros volume de données à importer, traiter, présenter et servir sur la plateforme. En effet, la plateforme Érudit met à disposition plus de 200 000 documents savants et culturels. Avant d’être visibles sur la plateforme Erudit.org, ces documents doivent être importés depuis différentes sources de données – ce qui implique plusieurs protocoles sous-jacents (par exemple Fedora Commons, un système de gestion de bibliothèques numériques, ou encore OAI-PMH, Open Archive Initiative Protocol for Metadata Harvesting, un protocole permettant l’échange de métadonnées provenant de sources diverses). Gérer un tel volume de document impliquait également d’anticiper les différents usages de la plateforme afin d’assurer une navigation fluide et performante pour les utilisateur d’ Erudit.org.

Il y avait également d’autres défis : assurer une certaine rétro-compatibilité entre l’ancienne plateforme et la nouvelle, qu’il s’agisse de redirections entres les anciennes URLs et les nouvelles, ou des techniques de conservation de l’indexation des documents Érudit dans Google et Google Scholar (https://scholar.google.ca/). Un autre défi consistait à permettre la collecte de métriques de consultations de documents en vue de produire des statistiques dans divers formats, et ainsi représenter ces statistiques de consultation de documents savants ou culturels avec des outils tel que COUNTER, ou des webservices, qui implémentent plusieurs normes de webservices liés à la récupération de données de consultation de documents savants ou culturels tel que Schemas for the Standardized Usage Statistics Harvesting Initiative (SUSHI).

Et quelle fut la partie de ton travail la plus intéressante ?
L’objectif de la plateforme Erudit.org s’inscrit dans une dynamique très vertueuse; le fait d’effectuer des travaux de conception et de développement sur la nouvelle version de cette plateforme était ainsi très valorisant. Outre les travaux liés à la mise en place de cette nouvelle application avec le cadriciel Django, l’un des aspects les plus intéressants de cette mission de plusieurs mois était lié aux spécificités mêmes de la plateforme : le fait de découvrir les spécificités techniques et exigences du milieu universitaire/bibliothécaire était particulièrement intéressant. Qu’il s’agisse de protocoles d’échange de métadonnées, de technologies de gestion de bibliothèques numériques ou de normes de présentation de citations, c’est un milieu qui vient avec son lot de problématiques techniques, d’enjeux technologiques… et de solutions libres. J’ai d’ailleurs été amené à réaliser plusieurs contributions lors de mon mandat, notamment dans le cadre de l’utilisation d’outils Python proposant des mécanismes d’interactions avec des technologies de gestion de bibliothèques numériques tels que eulfedora pour Fedora Commons .

Christophe Villemer, vice-président de Savoir-faire Linux, rebondit sur ces contributions : «en apportant notre expertise Python/Django à ce projet d’envergure, nous avons pu à la fois participer au développement d’un moteur de recherche important pour la communauté scientifique et offrir de nouvelles ressources à celle des technologies open source destinées à la gestion documentaire. Ce qui correspond parfaitement à la philosophie de notre entreprise».


Une version bêta

Complété à l’interne, le nouvel Érudit est encore en version bêta, et au cours de l’année de nouvelles fonctionnalités seront graduellement intégrées au site. Dans l’esprit des technologies ouvertes, vous pouvez contribuer à l’amélioration de la plateforme en signalant tout bogue à l’adresse bogue@erudit.org, et vous pouvez aller consulter le projet sur github, où Érudit a même son propre dépôt.

En attendant ces améliorations, libre à vous d’aller consulter la plateforme de recherches et trouver une multitude de ressources sur le logiciel libre, entre les thèses, les mémoires de maîtrise, les articles de revue savante ou culturelle, vous aurez l’embarras du choix…