Aller au contenu principal

Exploiter BYOS

Une fois votre serveur connecté, le travail quotidien ressemble en tout point à celui de l'hébergement géré. Cette page couvre les domaines dans lesquels l'exécution sur votre propre serveur se comporte différemment : domaines et SSL, Odoo Enterprise, sauvegardes et comportement de l'abonnement.

Domaines et SSL​

Les déploiements sur votre propre serveur ne reçoivent pas d'adresses *.skysize.io automatiques ; celles-ci sont réservées à l'hébergement cloud géré. Pour accéder à un déploiement BYOS sur le web, vous apportez votre propre domaine.

Sans domaine​

Un déploiement sans domaine reste accessible à des fins de test à l'adresse http://<your-server>:<port>, à partir de l'adresse du serveur et du port attribué à la branche. Le tableau de bord affiche l'URL exacte sur le déploiement. Il s'agit de HTTP simple, à réserver de préférence à la vérification interne plutôt qu'aux utilisateurs finaux.

Ajouter votre domaine​

  1. Ouvrez la section Domaines de la branche et ajoutez votre domaine (par exemple erp.mycompany.com), en laissant SSL activé.
  2. Chez votre fournisseur DNS, créez un enregistrement A pointant le domaine vers l'adresse IPv4 publique de votre serveur (indiquée sur la page de détail du serveur dans le tableau de bord).
  3. Attendez la propagation du DNS, puis ouvrez le domaine dans un navigateur.
remarque

Sur l'hébergement géré, vous faites pointer un CNAME vers votre nom d'hôte *.skysize.io. Sur BYOS, ce nom d'hôte n'existe pas : vous faites donc pointer un enregistrement A directement vers l'IP de votre serveur. Le reste du guide sur les domaines personnalisés s'applique sans changement.

Certificats SSL​

Les certificats HTTPS des déploiements BYOS sont émis sur votre serveur via Let's Encrypt, et y sont renouvelés automatiquement. Les certificats de plateforme propres à Skysize ne sont jamais installés sur du matériel client.

Pour que l'émission aboutisse :

  • Le DNS du domaine doit déjà résoudre vers votre serveur.
  • Les ports 80 et 443 du serveur doivent être accessibles depuis internet (Let's Encrypt valide le domaine en HTTP).

Tant que le certificat n'est pas émis, le site peut n'être brièvement accessible qu'en HTTP.

Odoo Enterprise sur votre propre serveur​

Les déploiements Enterprise sur votre serveur téléchargent le code source d'Odoo Enterprise en utilisant vos propres identifiants GitHub, depuis votre propre abonnement Odoo Enterprise. Les identifiants enterprise de Skysize ne sont jamais utilisés sur du matériel client.

Pour le configurer, ouvrez la page de détail de votre serveur et repérez les paramètres Source Odoo Enterprise :

  • Jeton GitHub : un jeton d'accès personnel d'un compte GitHub lié à votre abonnement Odoo Enterprise. Il est stocké chiffré et n'est plus jamais affiché après l'enregistrement.
  • URL du dépôt : laissez vide pour utiliser le dépôt officiel odoo/enterprise, ou indiquez votre propre miroir (doit commencer par https://).

Vous pouvez également fournir le jeton lors de la création d'un projet Enterprise ; le tableau de bord ne le demande que si le serveur cible n'en a pas encore de configuré.

attention

Sans jeton valide, les builds Enterprise sur ce serveur échouent car le code enterprise ne peut pas être téléchargé. Les projets Community ne sont pas concernés.

Workers et mémoire​

Votre serveur, votre dimensionnement : en BYOS, le nombre de workers du déploiement n'est pas fixé par le plan, c'est vous qui le choisissez. Ouvrez les Paramètres du projet et accédez à Workers et mémoire. Ces réglages dimensionnent uniquement le déploiement de production ; les déploiements de staging et de développement s'exécutent toujours en processus Odoo unique, sur des ressources fixes.

  • Workers : le nombre de processus HTTP d'Odoo. Laissez 0 pour un processus unique qui sert à la fois le HTTP et les actions planifiées, ce qui convient à une petite instance ou à un serveur modeste. Indiquez 2 ou plus pour exécuter Odoo en mode multiprocessus, où chaque worker traite les requêtes en parallèle.
  • Workers cron : le nombre de processus qui exécutent les actions planifiées. Utilisé uniquement en mode multiprocessus ; la valeur par défaut d'Odoo est 2.
  • Mémoire par worker : le plafond mémoire de chaque processus Odoo, en Mo. Le minimum est de 512 Mo et la valeur par défaut de 1024 Mo. Un processus qui le dépasse est redémarré par Odoo : augmentez-le si votre charge de travail comporte de gros imports ou rapports.

Lorsque vous modifiez l'un de ces réglages, le tableau de bord affiche, avant application, la mémoire maximale que le déploiement peut utiliser : chaque processus à son plafond, plus 512 Mo de marge pour le conteneur. Vérifiez que votre serveur dispose de cette mémoire, en plus de Postgres et de tout ce qu'il exécute par ailleurs.

Appliquer et redémarrer enregistre le dimensionnement et redémarre le déploiement de production : prévoyez une courte interruption.

remarque

Les réglages Délai d'expiration des requêtes et Délai d'expiration des workers cron se trouvent dans la même section et fonctionnent exactement comme en hébergement infogéré. Voir Limites de temps.

Sauvegardes​

L'ensemble du système de sauvegarde fonctionne sur BYOS : sauvegardes quotidiennes automatiques de la production, sauvegardes manuelles, restaurations, téléchargements et imports. Les tâches de sauvegarde s'exécutent sur votre serveur, puis l'archive est téléversée vers la cible de stockage configurée pour le projet.

Choisir l'emplacement de stockage des sauvegardes​

Les projets BYOS sauvegardent vers votre propre stockage : le stockage de la plateforme Skysize n'est pas proposé comme cible, de sorte que les données actives (sur votre serveur) comme les sauvegardes restent sur une infrastructure que vous contrôlez. Tant qu'aucune cible n'est configurée, aucune sauvegarde n'est effectuée, et le projet affiche une bannière rouge qui le signale.

  1. Ouvrez les Paramètres du projet et accédez à Cible de sauvegarde.
  2. Sous Vos cibles de sauvegarde, cliquez sur Ajouter une cible et créez une cible de type Système de fichiers, AWS S3 ou Google Cloud Storage (voir les exemples ci-dessous). Utilisez Tester pour vérifier la connexion.
  3. La première cible ajoutée est automatiquement sélectionnée comme Cible de stockage du projet. Si vous en ajoutez d'autres par la suite, choisissez celle à utiliser sous Cible de stockage et enregistrez.

Exemples de configuration​

Une cible de sauvegarde comporte un nom, un type et un champ Configuration (JSON) dont les paramètres dépendent du type. La configuration est stockée chiffrée ; les identifiants n'apparaissent plus jamais en clair après l'enregistrement. Un exemple par type :

Système de fichiers​

Écrit les archives dans un répertoire du serveur lui-même :

{
    "base_path": "/var/lib/skysize/backups"
}

base_path est facultatif et vaut par défaut /var/lib/skysize/backups.

attention

Les sauvegardes sur le système de fichiers résident sur la même machine que vos bases de données. Elles protègent contre les données corrompues (suppressions accidentelles, mises à niveau échouées) mais pas contre la perte du serveur lui-même. Pour la reprise après sinistre, utilisez une cible S3 ou Google Cloud Storage, ou copiez vous-même le répertoire de sauvegarde hors du serveur.

AWS S3​

Téléverse les archives vers un bucket S3 :

{
    "bucket": "mycompany-odoo-backups",
    "region": "eu-central-1",
    "prefix": "erp-production",
    "access_key_id": "AKIAIOSFODNN7EXAMPLE",
    "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

bucket est obligatoire ; region vaut us-east-1 par défaut si omis. prefix est facultatif et place chaque archive sous ce préfixe de clé, ce qui est utile lorsque plusieurs projets partagent un même bucket.

access_key_id et secret_access_key sont facultatifs. S'ils sont omis, l'agent utilise les identifiants de la machine sur laquelle il tourne (chaîne d'identifiants AWS par défaut). Si votre serveur est une instance EC2, c'est la configuration recommandée : attachez un rôle IAM à l'instance et n'indiquez aucune clé ; aucun secret longue durée n'est stocké et la rotation est gérée par AWS :

{
    "bucket": "mycompany-odoo-backups",
    "region": "eu-central-1",
    "prefix": "erp-production"
}

Que vous utilisiez un rôle d'instance ou une clé d'accès, l'identité doit pouvoir lister le bucket et y écrire, lire et supprimer des objets. Politique minimale :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
            "Resource": "arn:aws:s3:::mycompany-odoo-backups"
        },
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts"],
            "Resource": "arn:aws:s3:::mycompany-odoo-backups/*"
        }
    ]
}

N'utilisez une clé d'accès que si le serveur ne tourne pas sur AWS (créez un utilisateur IAM avec la politique ci-dessus, puis Informations d'identification de sécurité → Créer une clé d'accès). Le bouton Tester exécute la vérification depuis votre serveur lui-même : il valide donc le rôle d'instance exactement comme le ferait une vraie sauvegarde.

Google Cloud Storage​

Téléverse les archives vers un bucket GCS :

{
    "bucket": "mycompany-odoo-backups",
    "prefix": "erp-production",
    "credentials_json": "{\"type\": \"service_account\", \"project_id\": \"my-project\", \"private_key_id\": \"...\", \"private_key\": \"...\", \"client_email\": \"[email protected]\", ...}"
}

bucket est obligatoire ; prefix est facultatif, comme pour S3. credentials_json est le contenu complet d'un fichier de clé de compte de service, intégré sous forme d'une seule chaîne JSON (guillemets échappés). Le compte de service a besoin du rôle Storage Object Admin sur le bucket. Si vous laissez credentials_json vide, l'agent se rabat sur les identifiants Google par défaut de la machine, qui n'existent en général que lorsque votre serveur tourne sur Google Cloud.

astuce

Les sauvegardes sont créées sur le serveur avant leur téléversement : conservez donc suffisamment d'espace disque libre pour une copie compressée de votre plus grande base de données et de son filestore.

Si votre abonnement expire​

Si votre abonnement Bring Your Own Server expire ou est annulé, Skysize n'intervient jamais sur votre serveur pour arrêter quoi que ce soit :

  • Les déploiements en cours continuent de fonctionner. Vos instances Odoo et leurs données restent actives sur votre matériel.
  • Les nouvelles opérations sont bloquées. Les builds, les déploiements et les sauvegardes des projets BYOS sont refusés tant que l'abonnement n'est pas réactivé, et aucun nouveau serveur ni projet BYOS ne peut être ajouté. Les projets concernés affichent une bannière dans le tableau de bord.
  • Le renouvellement rétablit tout. Renouvelez ou rachetez l'abonnement depuis la page Agents et les builds et sauvegardes reprennent ; aucune réinstallation n'est nécessaire.
attention

Si le compte reste sans abonnement Bring Your Own Server actif pendant une période prolongée (environ 30 jours), les serveurs connectés qui n'hébergent pas de déploiements de projets actifs sont retirés du tableau de bord. Vous devriez alors les enregistrer et les enrôler à nouveau après avoir repris un abonnement. Les serveurs qui hébergent encore vos déploiements en cours d'exécution ne sont pas retirés.

Limites et différences par rapport à l'hébergement cloud​

  • Pas de domaines *.skysize.io. Chaque déploiement que vous souhaitez rendre accessible sur le web nécessite votre propre domaine, avec un enregistrement A pointant vers votre serveur.
  • Pas de bouton de proxy Cloudflare. Le trafic va directement vers votre serveur. Si vous souhaitez placer un CDN ou une protection DDoS devant celui-ci, configurez-les chez votre propre fournisseur DNS ou proxy.
  • Pas de choix de région. L'emplacement de votre serveur constitue la région. La latence et la résidence des données dépendent de l'endroit où vous l'hébergez.
  • Pas de palier gratuit. Les projets BYOS nécessitent toujours un abonnement Bring Your Own Server actif, un par projet.
  • La capacité est à votre charge. Le CPU, la RAM et le disque sont limités par votre matériel. Surveillez les métriques du serveur dans le tableau de bord et ajoutez des ressources, ou connectez des serveurs supplémentaires, avant qu'elles ne soient épuisées. Avec plusieurs serveurs, la production s'exécute sur le serveur que vous avez sélectionné et les autres branches se répartissent sur l'ensemble.
  • La maintenance du serveur vous incombe. Les mises à jour du système d'exploitation, l'application des correctifs de sécurité et la configuration du pare-feu de la machine relèvent de votre responsabilité. Skysize maintient à jour l'agent et vos déploiements Odoo.

Tout le reste, y compris les flux de travail par branche, les journaux de build, la gestion des accès et les restaurations, se comporte exactement comme sur l'hébergement géré.