25 mai 2024

Présentation de la prise en charge du cache Varnish pour le CMS Ghost

Vernice.js, un middleware Node.js, pour le nettoyage granulaire du cache Varnish sur Ghost.

Nous sommes ravis d'annoncer paint.js, l'intégration Open Source sous licence AGPL, de support de Varnish dans le CMS Ghost, qui permet le Purge sélective du cache Varnish lorsqu'un nouvel article est publié ou qu'un article existant est modifié. Cette amélioration garantit que le contenu proposé aux utilisateurs est toujours à jour et reflète les dernières modifications en temps réel. Pour rendre cette intégration possible, nous avons développé dans MANAGED SERVER SRL, un middleware appelé Paint.js, un middleware côté serveur écrit en Javascript pour nodejs, conçu pour s'interfacer avec Varnish Cache via les webhooks Ghost CMS. Ce middleware écoute les événements de modification de contenu dans Ghost et envoie des demandes de purge à Varnish, garantissant ainsi que le cache est toujours à jour.

Cette intégration est particulièrement utile puisque Ghost n'offre pas nativement la prise en charge d'un cache pleine page côté serveur. Varnish, avec l'aide de Vernice.js, peut donc être d'une grande aide pour les blogs à fort trafic, à la fois pour supporter les pics de trafic et pour réduire les temps de réponse comme le TTFB (Time To First Byte).

Aide au vernissage

Varnish Cache est un accélérateur HTTP conçu pour les sites Web dynamiques et riches en contenu. Il fonctionne comme un proxy inverse qui met en cache les réponses du serveur Web, améliorant ainsi les performances et réduisant la charge du serveur. Grâce à Vernice.js, nous pouvons profiter pleinement des capacités de Varnish pour toujours fournir du contenu frais et rapide.

Vernice.js garantit que chaque fois qu'un contenu est modifié ou publié dans Ghost, le cache de Varnish est immédiatement mis à jour, gardant ainsi le contenu à jour. L'utilisation de Varnish réduit la charge sur le serveur backend et améliore les temps de réponse (TTFB), un avantage crucial pour les blogs à fort trafic. Cette configuration permet de gérer les pics de trafic sans compromettre les performances du site, rendant le site plus fiable et plus rapide.

TTFB 200 ms

En implémentant Vernice.js, nous pouvons exploiter pleinement la puissance de Varnish pour améliorer les performances et la fiabilité de notre site Ghost. Cela garantit une expérience utilisateur optimale même pendant les périodes de trafic intense, en gardant le contenu toujours à jour et en réduisant considérablement les temps de réponse.

Contrairement à d'autres solutions trouvées en ligne sur le Web et sur les différents dépôts GitHub, qui ont tendance à nettoyer l'intégralité du Cache lorsqu'un post est mis à jour ou qu'un nouveau post est publié, notre middleware paint.js est particulièrement scrupuleux dans la réalisation d'une purge granulaire et sélective. uniquement du contenu mis à jour. Par exemple, si nous avions un blog fantôme rempli de 100 XNUMX articles et que nous mettions à jour un article en modifiant son contenu, paint.js se chargera de purger la page d'accueil et l'URL de l'article mis à jour, laissant tous les autres articles dans cache.

Cela permet d'obtenir un HIT RATIO très élevé, rendant le cache particulièrement fonctionnel avec tous les avantages qui en découlent.

Qu'est-ce que le vernis ?

Aide au cache de vernis

Varnish est un accélérateur HTTP conçu pour les sites Web dynamiques. Il fonctionne comme un proxy inverse qui met en cache les réponses du serveur Web pour améliorer les performances et réduire la charge du serveur. Cela signifie qu'une fois qu'une page Web a été demandée et stockée dans le cache Varnish, les autres demandes pour cette même page sont traitées directement depuis le cache, sans avoir à passer par le serveur backend. Cela accélère non seulement la livraison du contenu aux utilisateurs, mais réduit également considérablement la charge sur le serveur, lui permettant de gérer un nombre beaucoup plus important de requêtes simultanées.

Varnish est particulièrement efficace pour améliorer la réactivité des sites Web et gérer des volumes de trafic élevés. Il peut traiter des milliers de requêtes par seconde, ce qui le rend idéal pour les sites Web qui reçoivent de grandes quantités de trafic. De plus, Varnish offre un certain nombre de fonctionnalités avancées telles que la configuration de règles de mise en cache personnalisées, la prise en charge de l'équilibrage de charge et l'activation de techniques avancées d'accélération HTTP telles que Edge Side Include (ESI). Grâce à ces fonctionnalités, Varnish améliore non seulement les performances, mais également l'évolutivité et la fiabilité des sites Web, ce qui en fait un outil indispensable pour les sites dynamiques et à fort trafic.

Si vous souhaitez en savoir plus sur Varnish Cache nous avons rédigé un guide exhaustif à cette adresse Comprendre la logique de Varnish Cache

Comment fonctionne Vernice.js ?

Vernice.js a été conçu comme un middleware écrit en Node.js qui se situe entre Ghost et Varnish. Il fonctionne indépendamment des deux systèmes, recevant des appels webhook de Ghost, traitant les données reçues et s'interfaçant avec Varnish pour effectuer des purges sélectives du cache.

Opération-Vernice.js

Lorsque Ghost envoie un appel webhook après la publication, la mise à jour ou la suppression de contenu, Vernice.js reçoit cette demande. Les webhooks Ghost incluent une charge utile JSON contenant des détails pertinents, tels que l'URL du contenu modifié. Vernice.js extrait les URL impliquées dans le processus de purge, y compris l'URL spécifique au contenu et la page d'accueil du site.

Le middleware analyse la charge utile JSON du webhook pour obtenir urlObject.pathname e urlObject.host. Ces informations sont essentielles car Varnish ne peut pas traiter directement une charge utile JSON. Vernice.js utilise ces informations pour formater correctement les demandes de purge qui seront envoyées à Varnish.

Le processus fonctionne de la manière suivante : une fois les détails nécessaires extraits, Vernice.js envoie une requête HTTP de type PURGE à Varnish pour le chemin spécifié et pour la page d'accueil. Cela permet à Varnish d'invalider de manière sélective le cache uniquement pour les URL concernées, garantissant ainsi que les utilisateurs reçoivent toujours le contenu le plus à jour. Bien que la commande envoyée soit de type PURGE, Varnish peut être configuré pour traduire cette commande en un BAN, qui constitue une méthode efficace pour le nettoyage sélectif du cache.

Une chose importante à considérer est que même si vous pouvez théoriquement connecter les webhooks Ghost directement à Varnish, en pratique, cela n'est pas réalisable. En effet, Varnish ne peut pas interpréter et gérer une charge utile JSON envoyée par les webhooks Ghost. Vernice.js résout ce problème en agissant comme un intermédiaire qui traduit les informations du webhook dans un format que Varnish peut comprendre.

Qu'est-ce qu'une intégration personnalisée dans Ghost ?

Les intégrations personnalisées dans Ghost vous permettent de connecter Ghost à des applications et outils externes via des webhooks, étendant ainsi considérablement les capacités du CMS. Les intégrations personnalisées sont des configurations personnalisables qui permettent à Ghost d'interagir avec des services externes de manière automatique et réactive.

Les webhooks sont des appels HTTP que Ghost envoie à une URL spécifiée lorsque certains événements se produisent, tels que la publication, la mise à jour ou la suppression d'une publication, la création d'une page ou l'ajout d'une balise. Lorsqu'un de ces événements se produit, Ghost envoie une requête HTTP POST au webhook configuré, incluant les détails de l'événement dans la charge utile de la requête.

Intégrations personnalisées-Ghost-CMS

Ces intégrations permettent aux développeurs d'étendre les fonctionnalités de Ghost et d'automatiser divers processus. Par exemple, vous pouvez configurer un webhook pour envoyer des notifications à un service de chat comme Slack chaque fois qu'un nouveau message est publié, mettre automatiquement à jour un plan du site ou, comme dans notre cas, purger le cache de Varnish pour garantir que le dernier contenu soit proposé aux utilisateurs.

Les intégrations personnalisées offrent un haut degré de flexibilité, vous permettant de connecter Ghost à pratiquement n'importe quel service prenant en charge l'API webhook.. Cela signifie que vous pouvez créer des flux de travail personnalisés et automatisés qui répondent en temps réel aux événements se produisant sur votre site Ghost. Ces intégrations sont configurables directement depuis l'interface d'administration de Ghost, ce qui simplifie l'ajout de nouveaux webhooks et la gestion de ceux existants.

Grâce aux intégrations personnalisées, vous pouvez améliorer l'efficacité opérationnelle et fournir des fonctionnalités avancées sans avoir à modifier directement le code source de Ghost. Cette approche modulaire et évolutive fait de Ghost une plateforme extrêmement polyvalente et puissante pour la gestion de contenu.

Configuration de Ghost pour utiliser des hooks via l'API Web

Pour intégrer correctement Ghost au middleware VERNICE.JS et permettre la purge sélective du cache Varnish, vous devez configurer Ghost pour utiliser les Hooks via l'API Web. Vous trouverez ci-dessous les étapes détaillées pour effectuer cette configuration à partir de l'image fournie.

Connectez-vous au panneau d'administration Ghost et accédez à Paramètres (Paramètres), puis sélectionnez Avancé (Avancé). Dans la rubrique Intégration (Intégrations), sélectionnez l'onglet Personnalisé (Personnalisé) et cliquez sur Ajouter une intégration personnalisée (Ajouter une intégration personnalisée).

Intégrations personnalisées-Ghost-CMS

Une fois que vous avez sélectionné l'option permettant d'ajouter une intégration personnalisée, remplissez les détails requis pour créer une nouvelle intégration. Vous devrez saisir un nom pour l'intégration, tel que « Purge du vernis » et une brève description, telle que « Purge du vernis lors de la modification du contenu ». Après avoir enregistré l'intégration, les options de configuration des webhooks apparaîtront.

 

Sur l’écran d’intégration de Varnish Purge, cliquez sur Ajouter des webhooks (Ajouter un webhook) et remplissez les détails du webhook. Sélectionnez l'événement qui doit déclencher le webhook, par exemple « Post publié » ou « Post mis à jour », et saisissez l'URL cible du serveur sur lequel le middleware VERNICE.JS est exécuté. Par exemple, si le middleware s'exécute sur la même machine que Ghost et sur le port 3000, l'URL peut être http://127.0.0.1:3000/webhook.

Webhook-Ghost

Répétez le processus pour ajouter d'autres webhooks couvrant tous les événements qui vous intéressent, tels que la publication, la mise à jour et la suppression de publications, de pages ou d'autres contenus.

Webhook fantôme pour la purge du vernis

Exemple de configuration de webhook

Vous trouverez ci-dessous un exemple de ce à quoi devrait ressembler la configuration d'un webhook pour mettre à jour une publication :

Webhook-Ghost

Vérification de la configuration

Assurez-vous que Ghost envoie correctement les webhooks lorsque des modifications de contenu sont apportées. Vous pouvez le vérifier en vérifiant les journaux du middleware vernix.js. Vous devriez voir des messages de journal indiquant que des demandes de purge ont été reçues pour des chemins spécifiques.

Code middleware VERNICE.JS

Le middleware doit s'exécuter sur un serveur Node.js, prêt à recevoir et traiter les webhooks. Voici un résumé du code pour VERNICE.JS :

 

/**
 *
 *
 *         (`-.      ('-.    _  .-')        .-') _                          ('-.
 *       _(OO  )_  _(  OO)  ( \( -O )      ( OO ) )                       _(  OO)
 *   ,--(_/   ,. \(,------.  ,------.  ,--./ ,--,'   ,-.-')     .-----.  (,------.
 *   \   \   /(__/ |  .---'  |   /`. ' |   \ |  |\   |  |OO)   '  .--./   |  .---'
 *    \   \ /   /  |  |      |  /  | | |    \|  | )  |  |  \   |  |('-.   |  |
 *     \   '   /, (|  '--.   |  |_.' | |  .     |/   |  |(_/  /_) |OO  ) (|  '--.
 *      \     /__) |  .--'   |  .  '.' |  |\    |   ,|  |_.'  ||  |`-'|   |  .--'
 *       \   /     |  `---.  |  |\  \  |  | \   |  (_|  |    (_'  '--'\   |  `---.
 *        `-'      `------'  `--' '--' `--'  `--'    `--'       `-----'   `------'
 *
 *
 *
 *  VERNICE.JS a Ghost <=> Varnish Middleware Selective Cache Purger and Daemon Cleaner.
 *
 *  Copyright (c) 2024 - Managed Server S.r.l. - Licensed under AGPL 3.0 https://www.gnu.org/licenses/agpl-3.0.en.html
 *
 *
 *  Description:
 *  This Node.js middleware is designed to bridge the Ghost CMS with a selective Varnish Purging system.
 *  It listens for webhooks from Ghost related to content changes (like posts, pages, tags) and triggers
 *  selective cache purging in Varnish. This ensures that the content served to users is always fresh and up-to-date.
 *
 *  Requirement:
 *  Node.js and express, axios, url, body-parser. Varnish Cache 3.0 or Higher. A Linux OS support systemd.
 *
 *  Usage:
 *  Run this script in a Node.js environment. Configure Ghost to send webhooks to this middleware.
 *  The middleware will process these webhooks and send requests to the Varnish server to purge the cache as needed.
 *
 *  Note:
 *  Ensure that webhooks in Ghost and Varnish cache purging rules are correctly set up for this middleware to function properly.
 *
 */


const express = require('express');
const axios = require('axios');
const { URL } = require('url');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;


console.log('\x1b[32m%s\x1b[0m',
    " \n" +
    "      (`-.      ('-.    _  .-')        .-') _                           ('-.         \n" +
    "     _(OO  )_  _(  OO)  ( \\( -O )      ( OO ) )                        _(  OO)        \n" +
    " ,--(_/   ,. \\(,------.  ,------.  ,--./ ,--,'    ,-.-')     .-----.  (,------.       \n" +
    " \\   \\   /(__/ |  .---'  |   /`. ' |   \\ |  |\\    |  |OO)   '  .--./   |  .---'       \n" +
    "  \\   \\ /   /  |  |      |  /  | | |    \\|  | )   |  |  \\   |  |('-.   |  |           \n" +
    "   \\   '   /, (|  '--.   |  |_.' | |  .     |/    |  |(_/  /_) |OO  ) (|  '--.        \n" +
    "    \\     /__) |  .--'   |  .  '.' |  |\\    |    ,|  |_.'  ||  |`-'|   |  .--'        \n" +
    "     \\   /     |  `---.  |  |\\  \\  |  | \\   |   (_|  |    (_'  '--'\\   |  `---.       \n" +
    "      `-'      `------'  `--' '--' `--'  `--'     `--'       `-----'   `------'  \n" +
    "\n"+
    " VERNICE.JS a Ghost <=> Varnish Middleware Selective Cache Purger and Daemon Cleaner. \n"+
    "\n" +
    " Copyright (c) 2024 - Managed Server S.r.l. - Licensed under AGPL 3.0 \n" +
    "\n"

);



app.use(bodyParser.json({ limit: '64mb' }));

app.post('/webhook', async (req, res) => {
    if (req.body.post && req.body.post.current && req.body.post.current.url) {
        const fullUrl = req.body.post.current.url;
        const urlObject = new URL(fullUrl);
        const postPath = urlObject.pathname;
        const host = urlObject.host;

        console.log(`Richiesta di PURGE per il percorso: ${postPath} e host: ${host}`);

        try {
            // Effettua una richiesta PURGE per la home page
            axios.request({
                method: 'PURGE',
                url: 'http://127.0.0.1:80/',
                headers: { 'Host': host }
            }).catch(error => {
                console.error('Errore durante la chiamata di PURGE per la home page', error);
            });

            // Effettua una richiesta PURGE per l'URL specifico
            axios.request({
                method: 'PURGE',
                url: `http://127.0.0.1:80${postPath}`,
                headers: { 'Host': host }
            }).catch(error => {
                console.error('Errore durante la chiamata di PURGE per l\'URL specifico', error);
            });

            res.status(200).send('Richieste di PURGE inviate');
        } catch (error) {
            console.error('Errore generico nel blocco try', error);
            res.status(500).send('Errore durante l\'invio delle richieste di PURGE');
        }
    } else {
        console.log('Payload del webhook non valido o mancante di informazioni cruciali');
        res.status(400).send('Richiesta webhook non valida');
    }
});

app.listen(port, () => {
    console.log(`Server VERNICE.JS in ascolto sulla porta ${port}`);
});



En suivant ces étapes, vous pourrez configurer Ghost pour envoyer des webhooks au middleware paint.js, garantissant ainsi que toute modification de contenu est immédiatement reflétée dans le cache Varnish, améliorant ainsi les performances et l'expérience utilisateur de votre site.

Gardez le service actif via une unité Systemd.

Logo système

Pour garantir que le middleware Vernice.js reste actif et démarre automatiquement au redémarrage du système, vous devez configurer une unité systemd. Ceci est essentiel pour garantir que le service est toujours disponible pour gérer les webhooks envoyés par Ghost. Pour ce faire, nous allons créer un fichier de configuration dans /lib/systemd/system/vernice.service qui contiendra le code suivant :

[Unit]
Description=Vernice.js systemd service for vernice.js Node Varnish Cache Purger
After=network.target

[Service]
Type=simple
WorkingDirectory=/root
User=root
ExecStart=/usr/bin/node /root/vernice.js
Restart=always

[Install]
WantedBy=multi-user.target

N'oubliez pas d'adapter les chemins en fonction de l'emplacement du fichier paint.js, dans l'unité Systemd ci-dessus, il est supposé qu'il s'exécute dans le répertoire /root avec les privilèges root.

La section [Unité] définit les informations de base et les dépendances du service. Le paramètre Description fournit une brève description du service. Le paramètre After=network.target indique que le service ne doit être démarré qu'après la cible du réseau (network.target) a été atteint, garantissant que les ressources réseau nécessaires sont disponibles.

La section [Un service] définit la manière dont le service doit être effectué. Le paramètre Type=simple précise que le service est simple et démarré directement à partir de la commande indiquée dans ExecStart. Le paramètre WorkingDirectory=/root définir le répertoire de travail du service sur /root. Le paramètre User=root spécifie que le service doit s'exécuter sous l'utilisateur root. Le paramètre ExecStart=/usr/bin/node /root/vernice.js indique la commande pour démarrer le middleware Vernice.js ; dans ce cas, Node.js est utilisé pour exécuter le script vernice.js situé dans le répertoire /root. Le paramètre Restart=always configurez le service pour qu'il redémarre automatiquement s'il se termine de manière inattendue, garantissant ainsi une plus grande fiabilité.

La section [Installer] définit comment et quand le service doit être démarré. Le paramètre WantedBy=multi-user.target spécifie que le service doit être démarré dans le cadre de la cible multi-user, qui est l'un des niveaux d'exécution standard de systemd et inclut le mode multi-utilisateur sans interface graphique.

Après avoir créé le fichier de configuration, vous devez activer et démarrer le service avec les commandes suivantes :

sudo systemctl daemon-reload
sudo systemctl enable vernice.service
sudo systemctl start vernice.service

Ces commandes rechargeront la configuration des services systemd, permettront au service de démarrer automatiquement au démarrage et démarreront immédiatement le service Vernice.js. Avec cette configuration, Vernice.js sera toujours actif et prêt à gérer les webhooks Ghost pour la purge sélective du cache de Varnish.

Configuration du vernis pour Ghost

Au niveau de la configuration Varnish, par politique d'entreprise, nous n'entrons pas dans la configuration de la configuration et de la VCL associée, en adoptant une version spécifique et personnalisée étendue avec Inline C, cependant la configuration peut être appliquée simplement en s'assurant que le bloc Varnish recv peut être capable de gérer correctement la commande PURGE en bannissant sélectivement l'URL.

Ci-dessous, nous pouvons voir un court extrait de la configuration dans laquelle il y a un contrôle de l'adresse IP requérante (qui doit correspondre soit à l'adresse IP de la machine, soit à l'adresse IP de l'hôte local) qui procède ensuite au BAN de l'URL transmise par le middleware paint.js.

if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}

if (req.request == "PURGE") {

if ((req.http.X-Forwarded-For == "91.107.202.139, 127.0.0.1") || (req.http.X-Forwarded-For == "127.0.0.1")) {
ban("req.url ~ ^" + req.url + "$ && req.http.host == " + req.http.host);
}

else {
error 405 "Not allowed.";
}

}

Si vous devez installer et configurer Varnish, nous pouvons vous fournir des conseils commerciaux à ce sujet et éventuellement étendre les fonctionnalités.

Vous pouvez trouver toutes les mises à niveau, forks et correctifs dans le référentiel officiel GitHub à l'adresse https://github.com/MarcoMarcoaldi/Vernice.js

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

Retour en haut de page