Pourquoi des conteneurs ?
Comme pour les ransomwares, la question n'est pas de savoir si, mais quand. L'utilisation des conteneurs continue d'augmenter dans les entreprises. Et, selon les données initiales de l'étude "Spring 2021 Hybrid Cloud Study" d'Evaluator Group, 29 % des entreprises utilisent aujourd'hui Kubernetes dans un environnement de production et 40 % testent Kubernetes avec l'intention de passer à la production. Qu'est-ce qui suscite l'intérêt pour les conteneurs ?
Les conteneurs sont un autre type de virtualisation, et Docker est la plateforme de conteneurs la plus populaire. Les conteneurs sont un environnement spécialisé dans lequel les applications peuvent être déployées facilement. Les conteneurs peuvent être considérés comme des machines virtuelles (VM) légères. Les VM contiennent une copie du système d'exploitation (OS) et les conteneurs partagent l'OS sous-jacent, et chacun d'entre eux ne contient que les fichiers/images et les fichiers d'application requis par l'application pour fonctionner dans un conteneur. Plusieurs conteneurs fonctionnant sur une seule machine virtuelle occupent beaucoup moins de ressources que le même nombre de machines virtuelles fonctionnant ailleurs. Les conteneurs sont généralement conçus pour servir une application telle qu'une base de données, un serveur API ou un équilibreur de charge. Lorsque plusieurs applications doivent communiquer entre elles, elles doivent pouvoir interagir séparément sur le réseau. Cela permet une véritable architecture scale-out pour les applications et contribue à les rendre à la fois résilientes et disponibles.
Les conteneurs ont-ils besoin d'une sauvegarde ?
Les conteneurs peuvent fonctionner dans un environnement où l'état des applications doit être préservé ou non, ce que nous appelons des applications conteneurisées avec ou sans état. Si le conteneur n'a pas besoin de sauvegarder son état de fonctionnement, on considère qu'il s'agit d'une application sans état. Cela signifie qu'aucune donnée n'est stockée par ces applications exécutées dans le conteneur. Il s'agit d'une instance d'une image de conteneur. Dans l'éventualité où le nouveau conteneur contenant l'image de l'application doit être mis en service facilement, il peut l'être par le moteur d'orchestration de conteneurs Kubernetes.
Kubernetes est un moteur d'orchestration de conteneurs qui contrôle le cycle de vie des conteneurs.
Cela ajoute une haute disponibilité à chaque partie de l'infrastructure de conteneurs. Cela signifie également que les conteneurs peuvent être créés et supprimés selon les besoins de n'importe quelle charge de travail. Malheureusement, nombreux sont ceux qui confondent cette haute disponibilité avec la capacité de reprise après sinistre. Avec la modernisation des applications, les développeurs réalisent que l'architecture microservices simplifiée par les conteneurs peut également être étendue aux applications avec état. Cela permet aux entreprises d'accélérer le cycle de développement et de fournir des applications plus rapidement.
Dans les applications avec état s'exécutant dans un cluster Kubernetes, les questions/scénarios suivants doivent être pris en compte :
- La haute disponibilité intégrée à Kubernetes est-elle suffisante pour récupérer les données des applications stateful exécutées dans des conteneurs ?
- Puis-je réparer l'erreur humaine qui consiste à déployer un fichier de configuration incorrect lorsque des applications doivent être déplacées d'un environnement TEST/DEV vers la production, ou de la production vers la phase d'essai avant une mise à niveau ?
- Puis-je apporter une copie de l'application pour TEST/DEV afin de reproduire, d'analyser les problèmes qui ne peuvent pas être exécutés à partir des données de production ?
Si vous n'êtes pas sûr des réponses à ces questions, vous devez revoir votre stratégie de sauvegarde et de reprise après sinistre.
Dans le prochain blog de cette série, nous verrons quelles sont les données que vous devez sauvegarder et comment vous pouvez sauvegarder des conteneurs à l'aide de HYCU.