J’utilisais AWS depuis 2013, mais j’ai récemment mis en place mes propres serveurs afin de réduire les coûts et de gagner en prévisibilité. Je partage ici les raisons du passage à des serveurs internes, le processus, les mesures de sécurité, ainsi qu’un cas d’application de l’authentification multifacteur (MFA).
Raisons du changement
• Réduction des coûts : avec AWS, il était difficile de prévoir les dépenses, et la hausse du taux de change du dollar alourdissait la charge.
• Spécificités d’un service B2B : il est peu probable que le nombre d’utilisateurs augmente brutalement, et le volume des contrats peut être ajusté, donc il n’y a pas de problème de scalabilité.
Processus de transition et défis
• Travaux de migration : la base de données, le serveur de staging et les nouveaux services en cours de développement ont été déplacés vers les serveurs internes.
• Résolution des problèmes initiaux : les problèmes de compatibilité lors de la configuration des serveurs et la nécessité de mettre à niveau le matériel ont été traités.
Avantages à long terme
• Réduction des coûts : diminution des dépenses en exploitant au maximum les ressources des serveurs physiques.
• Renforcement de la sécurité : amélioration de la sécurité, notamment avec l’introduction d’une authentification multifacteur (MFA) utilisant GPT.
Mesures de sécurité
• Gestion des droits d’accès : configuration de plages d’IP, gestion des identifiants et des mots de passe, mise en place de l’authentification multifacteur.
• Sécurité physique : contrôle des accès et système de surveillance du centre de données.
• Vérifications régulières : audits de sécurité et analyse des vulnérabilités, sauvegardes périodiques des données et stockage sur un support externe.
Application de l’authentification multifacteur (MFA)
• Choix de la solution MFA : Google Authenticator, Authy, Yubikey, etc.
• Mise en œuvre : ajout d’une étape MFA dans le flux d’authentification des utilisateurs, intégration d’API et amélioration de l’interface utilisateur.
• Exemple de code : exemples d’intégration MFA fournis avec Python Flask et Ruby on Rails.
Réponses aux questions complémentaires
Q1 : Comment gérez-vous l’exploitation stable de serveurs physiques face aux étés très rudes et à la poussière en Corée ?
• Gestion de l’environnement de la salle serveur : utilisation de climatiseurs et de déshumidificateurs, installation de purificateurs d’air, nettoyage régulier.
• Système de monitoring : surveillance en temps réel de la température et de l’humidité.
• Maintenance matérielle : inspections et maintenance régulières.
Q2 : Quel est le plan de secours en cas de coupure électrique imprévue ou d’indisponibilité d’Internet ?
• Exploitation de serveurs redondants : répartition des serveurs dans plusieurs emplacements physiques.
• Système UPS : installation d’alimentations sans interruption.
• Redondance de la connexion Internet : mise à disposition de deux connexions Internet ou plus.
• Plan de sauvegarde et de restauration des données : sauvegardes régulières et préparation d’un plan de reprise rapide.
8 commentaires
Quitter AWS après plus de 10 ans pour finir sur des Mac mini M1, M2... Ce ne serait pas un peu du marketing viral pour Apple ?
Même si les autres éléments de l’infrastructure semblent très bien pensés, ça a un impact beaucoup trop fort.
Je me demande si vous n’avez pas ressenti le besoin de constituer une équipe dédiée, car il doit s’accumuler pas mal de sujets davantage liés à l’exploitation qu’au développement, comme la configuration réseau incluant pare-feu et routage, les sauvegardes hors site, l’établissement d’un consensus de sécurité, etc. (y compris les exigences de sécurité demandées par les clients s’il s’agit de B2B).
Petite question annexe : est-ce que cela veut dire que vous avez intégré GPT pour mettre en place la MFA ? Ou simplement que vous avez utilisé GPT pour vous aider à coder ? Je me pose la question. Est-ce un cas où ChatGPT est devenu le responsable de la sécurité ?
À lire le contenu, on dirait surtout qu’il demande à ChatGPT, obtient des pistes, puis prend diverses mesures… en gros, c’est ça.
Je peux comprendre qu’on recommande le mac mini du point de vue matériel, mais...
Si on utilise Docker sur Mac, au final on fera tourner une VM, puis Docker tournera au-dessus de cette VM...
Pour un environnement de production, Docker sur Mac me laisse quand même un peu perplexe.
Moi aussi, c’est ce point qui m’étonne : dans un environnement Docker, ARM a encore pas mal de chemin à parcourir, et en plus, comme vous l’avez dit, si c’est sur OSX, ça tournera sur une VM comme QEMU, donc la perte de performances risque d’être loin d’être négligeable. Recommander cette combinaison me paraît donc un peu étrange.
Cela signifie-t-il que l’environnement d’exploitation fonctionne aussi sur un Mac d’Apple ?
L’alimentation et les disques ne semblent pas être redondés ; je me demande donc comment ce serait géré en cas de problème matériel.
Quand on pense au loyer de l’immobilier ou au coût de location d’espace en centre de données, on comprend un peu mieux pourquoi le cloud est cher. J’ai l’impression que l’objectif le plus difficile est d’exploiter des serveurs redondants.