Nous avons réduit le temps de déploiement dans plusieurs environnements de 10 à 1 grâce à l’utilisation de Docker, ce qui a également permis d’économiser deux postes de maintenance pour une équipe de dix personnes.

Le mois dernier, notre petite équipe de SaaS pour le e-commerce à Singapour a failli échouer : avant une grande promotion, nous avons mis à jour la fonction de synchronisation des stocks pour trois sites en Asie du Sud-Est. Les tests locaux se sont déroulés sans problème, mais dès que nous l'avons déployé sur les serveurs cloud en Indonésie, nous avons rencontré des problèmes de dépendances manquantes. Deux développeurs backend et un administrateur système ont dû travailler pendant 18 heures pour résoudre le problème, ce qui a retardé le plan de test de charge prévu de trois jours.

Comprenez d'abord : qu'est-ce que le déploiement avec Docker ?

En d'autres termes, cela consiste à regrouper tout votre code d'application, vos bibliothèques dépendantes, vos fichiers de configuration, et même les paramètres du noyau de votre système d'exploitation dans une « image de conteneur » standard. Lorsque vous l'exécutez localement, l'application fonctionne de la même manière que sur n'importe quel serveur équipé du moteur Docker.20MB peut être effectué au minimum pour une seule image, le temps de démarrage ne dépasse pas 1 seconde.。

Nous avons utilisé les revenus réels de 3 mois.

Tout d’abord, le problème des incohérences environnementales a été complètement résolu. Auparavant, il fallait passer la majeure partie de la journée à configurer différentes versions de Node.js et des drivers de base de données pour chaque site. Maintenant, les images prêtes à l’emploi sont directement transférées dans le répertoire d’images, et il suffit d’une seule action pour récupérer et lancer les trois sites. Le temps de déploiement est passé d’en moyenne 4 heures à 24 minutes, et il n’est plus nécessaire de passer des nuits entières à mettre à jour les versions avant les promotions importantes.

Ensuite, l'utilisation des ressources serveur a doublé. Auparavant, nous louions un serveur cloud de type 2 cœurs (4G) pour chaque site séparément, et l'utilisation du CPU était inférieure à 10 % en période de faible activité. Maintenant, nous utilisons Docker pour regrouper les applications, les caches et les tâches planifiées des trois sites sur un seul serveur de type 4 cœurs (8G), et les ressources sont parfaitement suffisantes.Les coûts mensuels du serveur ont été économisés de 620 dollars.Ce n'est pas une petite somme pour une équipe de moins de 10 personnes.

Enfin, la vitesse d'expansion est parfaitement adaptée pour suivre les pics de trafic soudains. L'année dernière, pendant le Black Friday, il nous a fallu près de 2 heures pour ajouter des serveurs temporairement et mettre en place l'environnement. Cette année, 10 minutes avant la période de pointe, nous avons activé 12 copies de conteneurs qui ont pu gérer un trafic trois fois supérieur à la normale, et il n'y a plus eu de cas de temps d'attente pour les demandes.

Ne vous pressez pas de monter dans la voiture, nous avons déjà vérifié ces problèmes pour vous.

Le premier problème est que l'image créée est trop encombrante. Au début, nous avons simplement utilisé l'image complète officielle de Node.js pour l'emballage, et une seule image d'application pesait déjà beaucoup.1.2GIl faut plus de 20 minutes pour transférer les fichiers vers le répertoire d'image à l'étranger. Plus tard, nous avons utilisé une image de base Alpine et avons supprimé toutes les dépendances inutiles, de sorte que l'image finale ne contient plus que les éléments essentiels.90MBLa vitesse de transmission a été augmentée de plus de dix fois.

Le deuxième problème est que les données étaient stockées dans un conteneur. Au début, nous n’y avons pas prêté attention et avons stocké les images des produits téléchargées par les utilisateurs directement dans le répertoire local du conteneur. Plus tard, lorsque le conteneur a été redémarré, toutes les images ont disparu, et il a fallu une journée pour les récupérer à partir des sauvegardes. Par la suite, toutes les données persistantes ont été montées dans le répertoire local du serveur ou dans le stockage objet, et depuis, nous n’avons plus rencontré de problèmes.

Le troisième problème est l'absence de restrictions sur les ressources. Lors du lancement initial, aucune limite n'avait été fixée pour la CPU et la mémoire des conteneurs. Un jour, un bug dans une tâche planifiée d'un site a consommé toute la CPU du serveur, entraînant l'arrêt des deux autres sites. Par la suite, des limites de ressources ont été définies pour chaque conteneur, de manière à ce que le problème d'un seul service ne affecte pas l'ensemble du système.

Faut-il vraiment utiliser Docker ? Notre critère de décision est très simple.

Cas d'utilisation : Lorsque vous devez déployer la même application sur plusieurs serveurs, que vous devez souvent passer entre les environnements de développement, de test et de production, et que l'équipe compte plus de trois personnes dont chacun dispose d'un environnement de développement différent, l'utilisation de Docker améliorera simplement l'efficacité.

Cas où il ne faut pas l'utiliser : Si vous n'avez qu'un petit blog, que vous le hébergez sur un seul serveur et que vous ne mettez à jour le code qu'une fois tous les six mois, il n'est absolument pas nécessaire de passer du temps à apprendre Docker. Il est plus simple d'utiliser des outils comme Baota ou de procéder à des déploiements manuels.

Trois conseils concrets pour ceux qui commencent pour la première fois

• Pour les 3 premières fois où vous créez des images, il est préférable de rechercher directement les modèles de meilleures pratiques officiels plutôt que d'écrire vous-même un Dockerfile. Cela vous permettra d'éviter 80 % des problèmes de surcharge des images et d'erreurs de permissions.
• Au début, il n’est pas nécessaire d’utiliser des outils de gestion complexes tels que K8s ; il suffit de utiliser Docker Compose pour gérer jusqu’à trois services, ce qui est tout à fait suffisant.
• Pour le répertoire d'image, utilisez les nœuds internationaux des fournisseurs de cloud ; n'installez rien vous-même, le temps économisé vous permettra de développer plusieurs fonctionnalités supplémentaires.

Réponses unifiées aux petits problèmes courants

Question : Va-t-il y avoir une consommation supplémentaire de ressources serveur avec Docker ? Selon nos tests, la perte de performance est inférieure à 5 %, ce qui est totalement imperceptible pour la plupart des petites et moyennes équipes.

Question : Can the old applications be migrated to Docker? Of course they can. We have a PHP project that has been in use for 3 years, and it only took us 2 days to create the image and complete the migration, which is much faster than setting up the environment from scratch.