Ce guide explique comment gérer des utilisateurs pour votre projet Public Cloud.

Préambule

• Pour accéder aux ressources d'un projet, il est nécessaire de créer des utilisateurs de type OpenStack (lire plus bas).
• Ces utilisateurs OpenStack n'ont pas de rapport avec des utilisateurs du Manager Infomaniak.
• Le nom (username) de l'utilisateur est généré automatiquement et est communiqué après sa création.
• Ces utilisateurs OpenStack sont liés à un projet, ils ne peuvent donc pas accéder à plusieurs projets.
• Toutes les opérations sur les utilisateurs (ajout, modification, suppression, etc.) sont asynchrones et peuvent parfois prendre plusieurs minutes pour s'accomplir.

Créer un utilisateur pour votre Public Cloud

Pour créer un utilisateur OpenStack une fois votre Public Cloud commandé:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné:
   
3. Créez un nouveau Projet:
   
4. L'utilisateur défini à la création de votre projet sera de la forme PCU-XXXX et vous pouvez lui attribuer une description pour votre confort d'utilisation.

Gestion des mots de passe utilisateur

Le mot de passe de l'utilisateur OpenStack peut être soit défini immédiatement à la création soit généré par la suite grâce à un lien qui est envoyé par e-mail à l'adresse de votre choix.

Pour le modifier par la suite:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Gérer dans la colonne Utilisateurs du projet concerné:
   
4. Cliquez sur le menu à droite de l'utilisateur concerné pour accéder au changement de mot de passe.

Ajouter un nouvel utilisateur à un projet

Pour ajouter d'autres utilisateurs à votre projet:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Gérer dans la colonne Utilisateurs du projet concerné.
4. Cliquez sur Ajouter un accès OpenStack:
   

Supprimer un utilisateur

Pour supprimer un utilisateur existant:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Gérer dans la colonne Utilisateurs du projet concerné.
4. Cliquez sur le menu à droite de l'utilisateur concerné pour le supprimer:
   

En savoir plus

• Guide de démarrage: Public Cloud
• Public Cloud: Action sur un projet existant
• Documentation complète du produit: https://docs.infomaniak.cloud

Ce guide explique comment consulter et modifier les paramètres de configuration MySQL / MariaDB d’un Serveur Cloud. Ces paramètres permettent d’ajuster le comportement, les performances et certaines fonctionnalités du service, y compris les limites de ressources.

Préambule

• MySQL est installé sur un Serveur Cloud dédié : les ressources ne sont pas partagées avec d’autres clients.
• Une seule instance MySQL ou MariaDB est présente par Serveur Cloud.
• Le nombre et la taille des bases de données dépendent uniquement de l’espace disque et des ressources disponibles.
• Pour de très gros volumes de données non relationnelles, MongoDB est recommandé.

Paramètres configurables MySQL / MariaDB

La liste suivante présente les principales variables que vous pouvez personnaliser dans votre instance MySQL / MariaDB :

Modifier les paramètres MySQL / MariaDB

Pour modifier la configuration de votre instance :

1. Cliquez ici pour accéder à la gestion de votre produit dans le Manager Infomaniak (besoin d’aide ?).
2. Sélectionnez le nom du Serveur Cloud concerné.
3. Cliquez sur MySQL / MariaDB dans le menu latéral.
4. Éditez les paramètres souhaités puis validez vos modifications.

Ce guide explique comment modifier votre offre actuelle de Serveur Cloud.

Modification des ressources et de la configuration

Le plan Serveur Cloud de base contient 5 hébergements et 20 sites Web. Pour ajouter un hébergement supplémentaire ou modifier la configuration du serveur afin d'augmenter CPU / RAM :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez sur le menu d'action ⋮ situé à droite de l'élément concerné.
3. Cliquez sur Modifier l'offre:
   
4. Effectuez les ajustements souhaités et terminez la procédure.

Pour réduire la taille de l'espace disque du Serveur Cloud entier:

1. Commandez un nouveau serveur avec le nouveau stockage souhaité (contactez le support pour commander gratuitement le nouveau serveur le temps d'effectuer les étapes ci-dessous).
2. Déplacez les hébergements de l'ancien serveur vers le nouveau.
3. Résiliez l'ancien serveur.

Prenez connaissance de cet autre guide pour modifier l'espace disque d'un hébergement.

Augmenter la limite de processus

Sous Linux, le nombre de processus qu'un utilisateur ou un système peut créer simultanément est limité. Ces limites permettent d'éviter que des processus trop rapides ne consomment des ressources excessives et n'affectent la stabilité générale du système. Les limites de processus sont gérées par le noyau Linux et peuvent être visualisées et modifiées à l'aide de commandes et de fichiers de configuration spécifiques. Vous pouvez demander à augmenter les limites en contactant le support.

Ce guide détaille les spécificités liées à la gestion de MongoDB sur votre Serveur Cloud managé, notamment concernant le cycle de vie des versions.

Préambule

• Toute nouvelle installation de l'application déploie MongoDB version 7.0 (ou supérieure) par défaut.

Passer de la version 6 à 7

Il n'est pas possible d'effectuer une mise à jour (upgrade) automatique de la version 6 vers la version 7 directement depuis votre interface.

Deux solutions s'offrent à vous :

1. Commander un nouveau Serveur Cloud : il disposera nativement de la version 7, vous pourrez ensuite y migrer vos données.
2. Réinstaller l'application : désinstaller puis réinstaller MongoDB sur le serveur actuel.

Sauvegardes et responsabilité

En tant qu'administrateur, la gestion et l'intégrité de vos données vous incombent entièrement.

Avant toute manipulation (notamment la réinstallation) :

• Effectuez vos propres sauvegardes et exports (dump) de vos bases de données.
• Prévoyez l'import manuel de vos données une fois la nouvelle version active.

Ce guide explique comment afficher et interpréter les données de monitoring (statistiques réseau, CPU, RAM, etc.) d'un Serveur Cloud.

Surveiller l'activité d'un Serveur Cloud managé

Pour accéder au monitoring

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Monitoring dans le menu latéral gauche

Différentes données sont disponibles pour surveiller l'activité de vos Serveurs Cloud, dont notamment:

• le trafic entrant et sortant (réseau)
• la moyenne de la charge système (load average)
• la moyenne de la charge CPU
• la quantité de mémoire vive (RAM) utilisée
• l'espace disque utilisé
• le nombre de hits / sec.
• la moyenne des requêtes MySQL effectuées

Interpréter les statistiques

En interprétant le monitoring des ressources d'un Serveur Cloud vous pourrez estimer les ressources (la puissance) dont vous avez besoin pour faire fonctionner vos sites et applications Web.

Charge système totale

La charge système totale résume en pourcentage le niveau d'utilisation des processeurs virtuels. Dans cet exemple, le serveur utilise donc moins de 10% de ses ressources (0.10).

Processeur (CPU) et mémoire (RAM)

Ces graphiques montrent que moins de 10% des processeurs virtuels sont utilisés et que moins de 3 Go de RAM sont réellement exploités. Dans cet exemple, la configuration de ce serveur est donc surdimensionnée par rapport aux besoins réels.

Mémoire mise en cache élevée

La mémoire cache élevée sur un serveur n'est pas anormale et est souvent bénéfique dans de nombreux cas. Voici pourquoi :

1. Mise en cache pour des performances accrues : Les systèmes d'exploitation modernes, tels que Linux, utilisent la mémoire libre pour mettre en cache des données provenant du disque afin d'améliorer les performances. Lorsque vous accédez à des fichiers ou des applications, le système peut rapidement récupérer les données à partir du cache au lieu de les lire à partir de périphériques de stockage plus lents, tels que les disques durs. Cela contribue à réduire le temps de réponse global de votre serveur et peut améliorer considérablement les performances.
2. Utilisation efficace de la mémoire : Une utilisation élevée de la mémoire due à la mise en cache signifie que votre serveur utilise efficacement la mémoire disponible. La mémoire inutilisée est une mémoire gaspillée. Ainsi, tant que la mémoire est utilisée à des fins utiles comme la mise en cache, c'est un signe positif.
3. Gestion automatique de la mémoire : Les systèmes d'exploitation sont conçus pour ajuster automatiquement la taille du cache en fonction des besoins des applications en cours d'exécution. Si une application a besoin de plus de mémoire, le cache peut réduire sa taille pour l'accommoder. Cette gestion dynamique de la mémoire assure un équilibre entre la mise en cache et le service des applications actives.
4. Perspective de surveillance : Du point de vue de la surveillance, voir une utilisation élevée de la mémoire due au cache peut initialement susciter des inquiétudes, mais il est essentiel d'interpréter les mesures dans le contexte du comportement de votre serveur. Si vous constatez de bonnes performances et ne remarquez aucun signe de problèmes liés à la mémoire, tels que des échanges (swapping) ou des plantages d'applications, l'utilisation élevée du cache est probablement attendue et bénéfique.

En résumé, une mémoire cache élevée sur un serveur est normale et peut contribuer à améliorer les performances globales du système. Ne vous inquiétez pas si vous observez une utilisation importante de la mémoire cache, tant que votre serveur fonctionne correctement et sans problèmes évidents liés à la mémoire. La mise en cache est un outil essentiel pour optimiser les performances et tirer le meilleur parti des ressources disponibles.

Ce guide détaille le système Kubernetes de Public Cloud qu'il est possible de commander et d'installer directement sur votre Manager:

Interfaces et tarification du Service Kubernetes d'Infomaniak

Infomaniak propose une solution Kubernetes complète avec plusieurs interfaces de gestion et une tarification flexible adaptée à vos besoins.

Interfaces disponibles

Le service Kubernetes d'Infomaniak vous offre plusieurs méthodes d'accès et de gestion :

• API Kubernetes native : Interagissez directement avec votre cluster via l'API Kubernetes standard
• Fichier kubeconfig : Configurez facilement vos outils de ligne de commande comme kubectl
• Terraform/OpenTofu : Gérez votre infrastructure sous forme de code (IaC)
• Kubernetes Manager : Interface web intuitive pour piloter vos clusters
• CLI d'Infomaniak : Automatisez vos opérations via ligne de commande

Structure tarifaire

Le service Kubernetes d'Infomaniak propose plusieurs offres qui correspondent au prix du control plane. Il est important de noter que les ressources incluant réseau, instances, … ne sont pas incluses dans ce tarif de base. 

Les instances nécessaires au fonctionnement de vos applications sont facturées aux tarifs standards du Public Cloud d'Infomaniak. Vous profitez automatiquement des avantages tarifaires d'Infomaniak, y compris le trafic inclus et les instances à bas coût, disponibles sur la page Tarifs.

• Instances (VMs) : à partir d'un montant facturé par heure selon la configuration choisie
• Stockage Block : à partir d'un montant facturé par Go par mois
• Snapshot : à partir d'un montant facturé par Go par mois

Cette structure vous permet de ne payer que pour les ressources que vous utilisez réellement, tout en bénéficiant d'un control plane Kubernetes entièrement géré par Infomaniak.

Infomaniak ne fournit pas d'accès root sur Serveur Cloud.

En revanche, un accès root est possible sur:

• VPS Cloud / VPS Lite
• Jelastic Cloud
• Public Cloud

Ce guide explique comment faire une sauvegarde d'un VPS Cloud sous la forme de snapshot.

Préambule

• Un snapshot, c'est comme une photo de votre VPS Cloud à un instant T, qui contiendra tout ce qui se trouve sur votre serveur, y compris votre système d'exploitation, vos applications, vos données, etc.
• Les snapshots peuvent être utilisés notamment pour…
  • … protéger votre VPS Cloud en cas de problème: si vous rencontrez un problème avec votre VPS Cloud, vous pouvez restaurer un snapshot pour revenir à un état antérieur.
  • … tester des modifications sans risque: avant d'apporter des modifications importantes à votre VPS Cloud, vous pouvez créer un snapshot pour pouvoir revenir en arrière si nécessaire.
• Vous bénéficiez d'un snapshot gratuit pour sauvegarder l'intégralité de votre serveur dans un espace dédié ; en cas de besoin, il est possible de commander des espaces supplémentaires ou de supprimer un snapshot pour en créer un nouveau.
• Deux types de sauvegarde sont possibles:
  1. Snapshot des données: permet de créer une image du volume qui contient vos données (non disponible pour les distributions Windows).
  2. Snapshot du système d'exploitation: permet de créer une image du volume qui contient votre système d'exploitation. Ce type de sauvegarde implique une interruption de quelques minutes de vos applications et sites Web.
• Il est recommandé de créer des snapshots régulièrement, par exemple une fois par semaine ou par mois ; cela vous permettra de disposer d'un historique de votre VPS Cloud et de pouvoir revenir en arrière en cas de problème.
• Il est évidemment possible de restaurer l'état du VPS Cloud grâce au snapshot créé antérieurement.

Créer un snapshot

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Snapshot dans le menu latéral gauche.
4. Cliquez sur le bouton bleu Créer un snapshot:
   
5. Choisissez le type de snapshot à créer (données ou système d'exploitation).
6. Cliquez sur le bouton bleu pour démarrer la création du snapshot:
   
7. Un e-mail est envoyé lorsque le snapshot est généré.

Supprimer un snapshot

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Snapshot dans le menu latéral gauche.
4. Cliquez sur le menu d'action ⋮ à droite de l'objet concerné dans le tableau qui s'affiche.
5. Cliquez sur Supprimer:
   

Commander des snapshots supplémentaires

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Snapshot dans le menu latéral gauche.
4. Cliquez sur l'icône de caddie de supermarché:
   
5. Suivez les indications pour finaliser la commande.

Il n'est pas possible de commander un snapshot supplémentaire si un snapshot est en cours de réalisation.

Ce guide explique comment résilier complètement un VPS Cloud / VPS Lite.

Préambule

• Pour la plupart des produits, confirmez la demande de résiliation par e-mail sinon aucune donnée ne sera supprimée.
• Les frais ouverts et hors forfait demeurent dus.
• Une confirmation de résiliation est envoyée aux éventuels autres administrateurs de l'Organisation.
• Les sauvegardes seront irrémédiablement supprimées lors de la résiliation, rendant toute restauration impossible.

Résilier un serveur

Pour accéder à la résiliation des produits :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez sur le menu d'action ⋮ situé à droite de l'élément concerné.
3. Choisissez Résilier:
   
4. Suivez la procédure jusqu'au bout.

Ce guide détaille l'utilisation de Crontab (crons via SSH), disponible uniquement sur Serveur Cloud, par défaut (il existe aussi un planificateur de tâches pour tout hébergement).

Prérequis

• Les fichiers scripts appelés par le cron doivent être exécutables (CHMOD).

Chemin complet

Les tâches Cron n'ont pas connaissance du chemin absolu (path). Appeler PHP sans spécifier les chemins complets vers l’exécutable rend donc impossible l’exécution de la tâche. Il faut spécifier

/opt/phpX.X/bin/php

en remplaçant X.X par la version de PHP souhaitée (/opt/php8.1/bin/php par exemple).

Autres opérations

Par exemple:

• Lister les crons de l'utilisateur SSH en question: 

  crontab -l -u Username

• Editer les crons:

  crontab -e -u Username

• Etre notifié par mail du résultat de vos tâches cron (à ajouter en début de fichier): 

  MAILTO=e-mail@domain.xyz

Restaurer une sauvegarde

Infomaniak sauvegarde les crons des 7 derniers jours (une fois par jour). En cas de suppression accidentelle, contactez le support Infomaniak pour demander une restauration en précisant l'heure et la date de l'effacement.

Ce guide explique comment réinitialiser un VPS Cloud / VPS Lite.

Préambule

• Cette procédure efface tout le contenu du volume dédié au système d'exploitation (/dev/vda).
• Dans le cas d'un VPS Cloud, le volume dédié au stockage des données (/dev/vdb) n'est pas impacté par la réinitialisation.
   

Reset de l'OS VPS Cloud / VPS Lite

Pour accéder au VPS :

1. Cliquez ici afin d'accéder à la gestion de votre VPS sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au VPS concerné.
3. Cliquez sur le bouton Réinitialiser.
4. Suivez les instructions affichées pour terminer la réinitialisation.

Ce guide concerne le swap sur Serveur Cloud.

Swap et mémoire RAM

Il peut y avoir du swap alors que la consommation de RAM est faible. En effet le système peut utiliser le swap à tout moment s'il le juge utile.

Le swap n'est pas un espace mémoire dédié à être utilisé s'il n'y a pas de RAM libre, bien que ce soit souvent son utilisation principale.

Si vous souhaitez en savoir plus, il existe un paramètre "swappiness" qui permet de définir la manière dont le système utilisera le swap. La valeur par défaut est 60 et elle ne peut pas être modifiée.

Ce guide explique comment augmenter le volume de stockage de votre VPS Cloud une fois le changement d'offre effectué.

Préambule

• Par défaut, le VPS Cloud est fourni avec deux volumes :
  • 1 volume pour le système d'exploitation de votre choix (/dev/vda).
  • 1 volume pour le stockage de vos données (/dev/vdb), c'est celui-ci qui sera augmenté.
• Attention: selon le système d'exploitation installé, le volume système peut se nommer /dev/sda, /dev/sda1 ou /dev/vda ; idem pour le volume de données /dev/sdb, /dev/sdb2 ou /dev/vdb … Il convient donc de remplacer ces indications par celles correspondant à votre situation.

Commandes SSH pour augmenter le volume de stockage

Si vous choisissez du XFS par exemple, il est nécessaire d'installer les outils appropriés (s'ils ne sont pas déjà présents) :

sudo apt install xfsprogs

Puis d'augmenter le volume avec les commandes SSH suivantes :

sudo xfs_grow /dev/vdb

Et si vous choisissez du EXT4 :

sudo resize2fs /dev/vdb

Étendre le volume après une augmentation du volume de stockage

Deux cas de figures peuvent se présenter une fois que vous avez étendu le volume de stockage de votre serveur sous Linux. Noter qu'aucune donnée n'est supprimée lors de l'augmentation de l'espace via le changement d'offre de votre VPS.

Premier cas de figure

Dans le cas ou tout le volume est utilisé sans partition, il n'est pas nécessaire de faire un resizepart, vu qu'il n'y a pas de partition.

sudo umount /dev/vdb
sudo fsck.ext4 -f /dev/vdb
sudo resize2fs /dev/vdb

Second cas de figure

Dans le cas d'un volume qui contient une partition (/dev/vdb1), il faut commencer par arrêter les processus qui utilise ce volume puis il faut démonter la partition.

sudo umount /dev/vdb1

Il faut ensuite augmenter la taille de la partition avec parted qui dispose de la commande resizepart, ce qui n'est pas le cas de fdisk.

sudo parted /dev/vdb
GNU Parted 3.2
Using /dev/vdb
Welcome to GNU Parted! Type ‘help' to view a list of commands.
(parted) resizepart 1 100%
(parted) quit
sudo fsck.ext4 -f /dev/vdb1
sudo resize2fs /dev/vdb1

Et le volume Système ?

Il n'est pas possible d'agrandir la taille du volume système.

Pour Linux, Infomaniak fournit 20 Go, suffisant pour n'importe quelle distribution Linux. 

Pour Windows, Infomaniak fournit 100 Go sur le disque C, suffisant pour Windows. Les applications doivent être installées sur le lecteur D. Si vous disposez de 50 Go vous pouvez demander 100 Go (contactez le support Infomaniak en précisant un créneau pour l'opération car il y a quelques minutes d'interruption à prévoir).

Ce guide explique comment supprimer un appareil (de type sauvegarde Cloud) sur Swiss Backup, la solution de sauvegarde dans un cloud suisse indépendant. 

Supprimer un appareil (Swift, S3, etc.)

Pour accéder à Swiss Backup et retirer l'un des emplacements de sauvegarde libre :

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné:
   
3. Cliquez sur le bouton bleu Gérer mes appareils (dans la partie Espace de sauvegarde Cloud):
   
4. Cliquez sur le menu d'action ⋮ à droite de l'objet concerné dans le tableau qui s'affiche.
5. Cliquez sur Supprimer l'appareil:
   
6. Confirmez la suppression en entrant le mot de passe de connexion au Manager et en activant la case de confirmation.

Pour choisir un nouvel appareil sur Swiss Backup, prenez connaissance de cet autre guide.

Ce guide explique comment se connecter à une base de données externe depuis un Serveur Cloud.

Préambule

• Il est possible de se connecter en SSL à MySQL (externe ou pas) - à spécifier lors de l'établissement de la connexion.
• Le port MySQL 3306 est fermé par défaut - pour l'ouvrir, prenez connaissance de cet autre guide.
• Infomaniak n'installe pas PDO_DBLIB.

Installer PHP_PDO_ODBC

Prérequis

• Avoir le menu Extensions PHP sur le Manager Infomaniak dans la partie Serveur Cloud (si non il sera nécessaire de faire évoluer le Serveur Cloud).

Il est possible d'installer l'extension PHP_PDO_ODBC depuis le menu Extensions PHP de votre Serveur Cloud:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Extensions PHP dans le menu latéral gauche.
4. Cliquez sur le bouton bleu Installer une extension.
5. Choisissez l'extension PHP_PDO_ODBC.
6. Validez l'installation.

Configurer le connecteur

La configuration du driver est déjà définie dans /etc/odbcinst.ini :

[FreeTDS]
Description = MS SQL database access with Free TDS Driver
Driver = /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libtdsS.so

Il n'y a pas besoin de la re-définir statiquement dans le .odbc.ini ou dans la home de l'utilisateur ‍~~/.odbc.ini‍ ou aussi dynamiquement dans le code PHP.

Exemple avec le driver FreeTDS défini au préalable, il faut aussi que la version du driver soit spécifiée à la fin de la déclaration de l'objet pdo:

$con = new PDO('odbc:Driver=FreeTDS;Server=__SERVER IP__;Port=3306;DATABASE=__DATABASE NAME__;UID=__USERNAME__;PWD=__PASSWORD__;TDS_Version=8.0');

Ce guide présente plusieurs exemples d'utilisation de Varnish sur Serveur Cloud Infomaniak.

Préambule

• Consultez ces ressources complémentaires sur le langage de configuration Varnish (VCL) pour maîtriser le traitement des requêtes, le routage et la mise en cache :
  • VCL Tutorial
  • VCL user guide
  • VCL Reference

Configuration de Varnish

Une fois installé, la configuration de Varnish repose sur des règles précises de mise en cache et de purge. Veillez à restreindre l'accès pour éviter que des entités non autorisées puissent vider votre cache.

Voici un exemple de fichier de configuration regroupant les cas d'usage les plus fréquents :

vcl 4.0;

# Default backend configuration
backend default {
    .host = "127.0.0.80";  # Backend IP address
    .port = "80";           # Backend port
}

# Access Control List (ACL) for purge authorization
acl purge {
    "localhost";            # Local access
    "1.2.3.4";              # Trusted home IP
    "42.42.42.0"/24;        # Trusted company range
    ! "42.42.42.7";         # Specific IP exclusion (e.g., problematic user)
}

# Handle incoming requests
sub vcl_recv {
    # Handle PURGE requests
    if (req.method == "PURGE") {
        # Check if client IP is authorized
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGE requests."));
        }
        return (purge);
    }

    # Custom PURGEALL for image directory
    if (req.method == "PURGEALL" && req.url == "/images") {
        if (!client.ip ~ purge) {
            return (synth(405, "IP not authorized for PURGEALL requests."));
        }
        # Invalidate all image-related objects in cache
        ban("req.url ~ \.(jpg|png|gif|svg)$");
        return (synth(200, "Images purged."));
    }

    # Bypass cache for authorized requests (e.g., admin panels)
    if (req.http.Authorization) {
        return (pass);
    }
}

# Handle backend responses before caching
sub vcl_backend_response {
    # Set TTL for images to 1 day
    if (beresp.http.content-type ~ "image") {
        set beresp.ttl = 1d;
    }

    # Respect backend's "uncacheable" instruction
    if (beresp.http.uncacheable) {
        set beresp.uncacheable = true;
    }
}

Purge via l'interface CLI

Dès lors que vos règles sont actives, vous pouvez tester la purge de votre site (ex: "domain.xyz") en utilisant l'outil curl :

# Purge the homepage
$ curl -X PURGE https://domain.xyz/

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The page has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 2</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Pour purger une URL spécifique, modifiez simplement le chemin de la requête :

# Purge a specific file
$ curl -X PURGE https://domain.xyz/some_path/some_file.html

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged</title>
</head>
<body>
    <h1>Success 200: Purge completed</h1>
    <p>The file has been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 4</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Ou pour déclencher la purge groupée des images définie dans le VCL :

# Execute PURGEALL for images
$ curl -X PURGEALL https://domain.xyz/images

# Expected Varnish response
<!DOCTYPE html>
<html>
<head>
    <title>200 Purged images</title>
</head>
<body>
    <h1>Success 200: Images purged</h1>
    <p>All images have been successfully purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 32770</p>
    <hr>
    <p>Varnish Cache Server</p>
</body>
</html>

Purge depuis un CMS (PHP)

La gestion du cache peut aussi se faire dynamiquement via votre backend. Dans la configuration précédente, un contrôle sur l'en-tête Uncacheable a été ajouté. Votre CMS peut envoyer cet en-tête pour forcer Varnish à ne pas stocker une réponse.

Voici comment envoyer une requête de purge programmatique en PHP :

<?php
// Initialize cURL for a specific URL
if ($curl = curl_init("http://127.0.0.1/some_url")) {
    curl_setopt_array($curl, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => "PURGE",
        CURLOPT_HTTPHEADER => [
            "Host: {$_SERVER['HTTP_HOST']}" // Match the target host
        ]
    ]);

    curl_exec($curl);
    
    // Check if the purge was successful (HTTP 200)
    if (curl_getinfo($curl, CURLINFO_HTTP_CODE) == 200) {
        echo "Cache purged!";
    }
    curl_close($curl);
}
?>

Ce guide explique comment restaurer un snapshot de VPS Cloud Infomaniak.

Restaurer un snapshot

Pour cela:

1. Cliquez ici afin d'accéder à la gestion de votre produit sur le Manager Infomaniak (besoin d'aide ?).
2. Cliquez directement sur le nom attribué au produit concerné.
3. Cliquez sur Snapshot dans le menu latéral gauche.
4. Cliquez sur le menu d'action ⋮ à droite de l'objet concerné dans le tableau qui s'affiche.
5. Cliquez sur Restaurer:
   
6. Cliquez sur le bouton bleu pour démarrer la restauration du snapshot.
7. Un e-mail est envoyé lorsque le snapshot est restauré.

Restaurer le disque du système d'exploitation

La restauration du volume système comme dans l'exemple ci-dessus est une opération irréversible. Le disque du système d'exploitation sera remplacé par le snapshot et le serveur se retrouvera dans l'état exact de la date de la sauvegarde.

Les données stockées sur le volume des données (vdb) ne sont pas affectées par cette opération.

Restaurer le disque des données (vdb)

Deux modes de restauration de données sont possibles :

1. Mode “Lecture seule”

Si la taille du snapshot diffère de la taille du volume, seul ce mode lecture seule est disponible.

Cette option permet de monter l'image du snapshot de données, ce qui permet d'accéder en lecture seule aux données de la sauvegarde.

À titre d'information, voici des commandes utiles pour exploiter votre sauvegarde :

• Pour accéder au volume de données principal : mount /dev/vdb /mnt/.
• Pour monter le volume des données dans un dossier spécifique "backup" : mount -o nouuid -o ro,norecovery /dev/vdc /backup.

Pour savoir quelle lettre utiliser (/dev/vd?), utilisez la commande lsblk:

2. Mode “Restauration”

La restauration du volume des données est une opération irréversible. Le disque des données (vdb) sera remplacé par le snapshot. À la fin de la restauration, il sera nécessaire de remonter le volume des données afin que votre système d'exploitation rafraichisse le contenu.

La procédure et les commandes suivantes sont uniquement fournies à titre indicatif :

1. Assurez-vous que votre volume de données n'est pas monté :
   * umount /mnt (/mnt ou l'emplacement que vous aviez choisi pour accéder à vos données).
2. Remontez le volume de données :
   * mount /dev/(vdb) /mnt

Pour connaître le nom du volume de données attaché à votre serveur, utilisez la commande lsblk (voir ci-dessus).

Supervisor n'est pas proposé directement car systemd est recommandé, mieux intégré à Debian et disponible dans Fast installer.

Si vous deviez l'installer malgré tout, contactez le support Infomaniak par écrit.

Ce guide explique les modalités de retrait et de restitution des actifs lors de la résiliation d'un produit Public Cloud.

Retrait et restitution des actifs sur Public Cloud

Lorsqu'une résiliation volontaire est effectuée, les ressources associées au Public Cloud sont progressivement désactivées puis supprimées.

Les ressources DNS de type DNSaaS (Designate) sont immédiatement supprimées dès la résiliation.

Les autres ressources sont désactivées sur l'ensemble des régions Public Cloud :

• désactivation des utilisateurs et des projets ;
• impossibilité d'accéder aux ressources restantes ;
• désactivation des ressources encore exposées :
  • Buckets S3 et conteneurs Swift (Object Storage) ;
  • instances Compute arrêtées (power-off) ;
  • sortie automatique du mode pause avant arrêt des instances ;
  • sortie automatique du mode rescue avant arrêt des instances ;
  • désactivation des Load Balancers (LBaaS) ;
  • désactivation des orchestrations et alarmes (Heat).

Les ressources non exposées ne sont pas immédiatement modifiées, notamment :

• volumes ;
• images ;
• sauvegardes ;
• snapshots ;
• clés publiques ;
• réseaux privés ;
• secrets.

Délai de conservation des actifs

À l'exception des ressources DNS, les actifs sont conservés pendant une durée de 7 jours après la résiliation.

Le 7e jour à 3h du matin, l'ensemble des ressources restantes est définitivement supprimé, sans possibilité de restauration.

Restitution des actifs après résiliation

Après la résiliation du produit, une demande de restitution peut être effectuée dans un délai maximal de 3 jours calendaires.

Cette demande nécessite :

• une souscription active à un produit Public Cloud ;
• une situation de facturation à jour ;
• le respect des conditions contractuelles applicables.

Sous réserve que les données soient encore disponibles sur les infrastructures de stockage, les services suspendus pourront être réactivés dans un délai maximal de 4 jours après validation de la demande.

Les instances arrêtées ne sont pas redémarrées automatiquement. Elles peuvent toutefois être relancées manuellement si nécessaire.

L'export des actifs reste à votre charge.

Ce guide explique comment installer et configurer systemd sur un Serveur Cloud et présente les principales commandes utilisables.

Prérequis

• Suivre le guide d'installation systemd pour Serveur Cloud.
• Consulter la documentation officielle pour prendre connaissance de l'ensemble des possibilités offertes par systemd
• Les fichiers "unit" devront être placés dans : ~/.config/systemd/user/ ( /home/clients/absolute-path-id/.config/systemd/user ) (en remplaçant absolute-path-id visible dans votre Manager) et les permissions doivent être réglées en 0644.
• Le paramètre --user doit être indiqué dans chaque commande.

Principales commandes 

Voici une liste non-exhaustives de commandes utilisables avec systemd.

Forcer systemd à lire à nouveau les unit files et à prendre en compte les modifications:

systemctl --user daemon-reload

Activation d'un service: 

systemctl --user enable --now SERVICENAME.service

Vérification de l'état d'un service:

systemctl --user status SERVICENAME.service

Configuration de Node en tant que service avec systemd

Il sera nécessaire de créer un fichier "Unit" avec l'extension ".service", qu'il faudra enregistrer dans le répertoire:

~/.config/systemd/user/

Il est possible de réutiliser l'exemple ci-après en remplaçant les valeurs commençant par {} :

[Unit]
Description={Le nom du service} # Spécifier ici un nom du service. Celui-ci est obligatoire mais n'a pas d'impact sur le fonctionnement
[Service]
Restart=always
Environment=NODE_VERSION={la version souhaitée} # Spécifier ici la version de Node à utiliser. S'assurer qu'elle soit installée au préalable avec "nvm install {la version souhaitée}"
WorkingDirectory=%h/{repertoire du projet Node} # %h correspond à la racine de l'hébergement
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec {commande de lancement du script node}" # Cette commande dépend du projet. Par exemple, "npm run start", "npm run serve" ou encore "node server.js" sont courants
[Install]
WantedBy=default.target

Actions supplémentaires avec un fichier Unit

systemctl --user daemon-reload

Démarrer le service (si celui-ci est déjà actif, rien ne se passe):

systemctl --user start [Nom du Unit]

Arrêter le service (si celui-ci n'est pas actif, rien ne se passe):

systemctl --user stop [Nom du Unit]

Redémarrer le service (s'il ne tourne pas, il est lancé):

systemctl --user restart [Nom du Unit]

Obtenir des informations sur le service ; notamment:

• "Active" qui indique si le service tourne et depuis quand
• "CGroup" montre le groupe de processus que gère le service, ça permet de voir les processus actifs, avec leurs arguments et leur ID

En dessous de "CGroup" se trouvent d'éventuels logs (la sortie standard et erreur du processus):

systemctl --user status [Nom du Unit]

Activer le démarrage automatique du service au boot du serveur ; NB: ça ne démarre pas le service:

systemctl --user enable [Nom du Unit]

Désactiver le démarrage automatique du service au boot du serveur ; NB: ça n'arrête pas le service:

systemctl --user disable [Nom du Unit]

Configuration avec les entrées user:

[Unit]
Description="nom service"
[Service]
Restart=always
Environment=NODE_VERSION=16.17
WorkingDirectory=%h/sites/"nom-repertoire-site"/
ExecStart=/bin/bash -c "exec $HOME/.nvm/nvm-exec npm run start"
[Install]
WantedBy=default.target