Docker convient-il à mon cas d'utilisation?

Mon entreprise a un système que nous vendons qui consiste essentiellement en un mini-ordinateur "Smartbox" qui exécute Ubuntu 12.04. Cette boîte exécute une application Django plus un certain nombre de processus différents qui lui sont associés. Pas grand chose d'autre. Nous avons des milliers de ces boîtes sur le terrain. Nous gérons les dépendances des packages, l'enregistrement des processus, etc. via un package deb avec différents degrés de succès.

Nous avons besoin d'un moyen de diffuser les mises à jour de manière efficace et robuste à nos utilisateurs sur le terrain. Nous avons également besoin de quelque chose qui, lorsque nous mettons à niveau le système d'exploitation (nous sommes en retard pour une mise à niveau d'Ubuntu, comme vous pouvez le voir), nous pouvons nous sentir relativement en sécurité à propos de nos packages "fonctionnant".

Je ne sais pas grand-chose sur Docker, mais quand j'ai entendu parler de notre problème pour la première fois (je suis une nouvelle recrue), Docker a été ma première pensée. Mais plus j'y pensais, plus je pensais que ce n'était peut-être pas le cas, car ces boîtes sont les nôtres, nous contrôlons le système d'exploitation, ce qui constitue une grande partie de la proposition de valeur de Docker, du moins je comprends. Donc, si nous SAVONS que nos boîtes seront toujours Ubuntu et que nous avons simplement une application Django et certains processus à exécuter, Docker est-il meilleur qu'un package deb?

TL; DR: packages Docker vs deb pour une appliance distribuée qui exécutera toujours Ubuntu, donc l'indépendance de la plate-forme n'est pas si importante.

Je ne suis pas sûr à 100% de la question, mais il semble que la solution Docker consisterait à passer d'une application (physique?) Avec un système d'exploitation et votre application installée à celle-ci, à une application avec un système d'exploitation et Docker dessus, exécutant un seul conteneur avec votre application dedans. Cela n'empêche pas la nécessité de mettre à jour le système d'exploitation dans l'hôte, et cela ajoute une couche de complexité (et plus de mises à jour à gérer, car vous devrez maintenant garder Docker et le système d'exploitation corrigés) sans aucun avantage évident. en ce qui concerne les domaines spécifiques mentionnés dans la question.

Cependant, si vous parlez de passer d'une appliance virtuelle à un conteneur Docker, cela pourrait potentiellement vous faciliter la tâche, mais cela ajoute également Docker en tant que dépendance pour votre produit; vous excluez quiconque n'utilise pas Docker et ne souhaite pas l'ajouter à sa pile uniquement pour utiliser votre produit. Vous pouvez continuer à prendre en charge ceux qui n'utilisent pas / n'utiliseront pas Docker en continuant à expédier l'appliance virtuelle (désormais «héritée») comme auparavant, mais maintenant vous venez de doubler votre charge de travail car vous avez deux distributions à prendre en charge au lieu de un.

Je travaille avec Docker depuis longtemps. L'indépendance de la plate-forme est agréable, mais ce n'est pas ce que je considère le plus utile à propos de Docker.

D'abord et avant tout, vous obtenez la répétabilité. Vous pouvez créer un Dockerfile, déboguer dans un conteneur sur votre machine de développeur, exécuter des tests sur un serveur d'intégration continue, puis dans votre produit final, et vous savez qu'il se comportera de la même manière dans tous ces environnements. Sans oublier une dépendance qu'un développeur avait installée sur sa machine. De plus, vos développeurs n'ont pas à utiliser Ubuntu à leur bureau. Important de nous satisfaire les utilisateurs d'Arch Linux :-)

Deuxièmement, pour votre scénario de mise à niveau, vous pouvez avoir plusieurs versions tirées sur une machine à la fois. Si vous exécutez un docker pull myapp:2.0certain temps 1.0, vous pouvez passer à 2.0très rapidement. Cela prendrait beaucoup plus rapidement qu'une mise à niveau complète du système d'exploitation. Si vous utilisez un orchestrateur avec plusieurs instances de microservices, vous pouvez même effectuer des mises à niveau continues qui n'interrompent pas du tout le service.

Si vous utilisez un modèle de microservices, Docker fournit également des bacs à sable qui peuvent limiter la quantité de dégâts que les attaquants peuvent faire en cas d'exploitation. Au lieu de prendre le contrôle d'une machine entière, ils ne prennent le contrôle que sur un conteneur.

L'inconvénient principal est que vous avez besoin du système d'exploitation hôte et d'une sorte d'orchestration. Il y a beaucoup de choix pour cela, mais ne sous-estimez pas la quantité de travail qu'il faut pour en évaluer un, le mettre en place et le maintenir.

Dans l'ensemble, le docker offre de nombreux avantages pour les développeurs et le personnel d'exploitation. J'utilise docker pour certaines de mes applications et je trouve que c'est une approche très fiable et robuste.

Mon problème avec votre adoption de Docker est que je ne vous entends pas poser les bonnes questions et vous pourriez potentiellement vous compliquer la vie sans répondre à vos exigences les plus importantes.

La première question que vous devriez poser (vous avez dit que vous étiez nouveau) est de savoir comment les mises à jour du système d'exploitation et de l'application sont-elles gérées maintenant? La méthodologie actuelle fonctionne-t-elle pour vous (votre entreprise)? Qu'est-ce qui fonctionne bien? Qu'est-ce qui pourrait être amélioré? Pouvez-vous effectuer un audit de configuration physique sur vos machines cibles sur le terrain pour vérifier qu'elles ont les correctifs du système d'exploitation, l'application et y a-t-il eu des modifications non autorisées?

J'adore le docker, mais je ne sauterais pas dans le train des dockers sans d'abord évaluer où vous en êtes en ce moment, y compris ce qui fonctionne bien et ce qui doit être amélioré.

Bien qu'il existe de minuscules régions qui se chevauchent, Docker et les systèmes de conditionnement Debian résolvent essentiellement deux problèmes très différents :

• Le système d'empaquetage Debian est conçu pour installer le logiciel sur un hôte et le mettre à jour aussi facilement que possible. Il est capable de gérer des modèles de dépendance et de contraintes complexes entre les composants logiciels, comme «le logiciel X version A nécessite un logiciel Y avec la version B ou une version plus récente installée» ou «le logiciel X ne doit jamais être installé avec le logiciel Z version C».

• Le système Docker est conçu pour décrire et déployer facilement des services, en particulier des micro-services, éventuellement sur plusieurs hôtes - par exemple un essaim Docker ou un cluster Kubernetes.

Ces deux problèmes sont essentiellement orthogonaux, ce qui signifie qu'étant donné le problème de déploiement à résoudre, on peut utiliser l'un d'eux, les deux, ou peut-être même aucun d'entre eux, dans le cadre de la solution. Lorsque vous les utilisez tous les deux, le paquet Debian est utilisé dans la production de l'image Docker, et votre Dockerfile (les recettes utilisées pour préparer l'image Docker décrivant le «système virtualisé» exécuté dans un conteneur) enregistrerait essentiellement votre référentiel Debian dans le sources du système de conditionnement Debian et installez votre paquet.

Dans cet esprit, il me semble que ce que vous cherchez vraiment, c'est d'implémenter le modèle de serveur immuable. Le développement récent des technologies cloud a permis de mettre à niveau le logiciel non pas en utilisant le système de mise à niveau de logiciel classique à partir d'un système de progiciel (comme le système de conditionnement Debian) mais plutôt en remplaçant simplement le serveur complet à la fois. (Certaines personnes l'ont fait avant ce développement en disposant de trois OS sur un serveur, deux utilisés en alternance pour exécuter l'appliance et un mini-OS dédié au remplacement de l'appliance. Bien qu'il ne soit pas trop complexe, cela semble être toujours resté un niche.) Cette technique peut vous intéresser car si vous êtes habitué à mettre à niveau le logiciel sur votre serveur à l'aide du gestionnaire de packages, l'état final du serveur dépend de l '«historique de mise à niveau» du serveur - surtout si des erreurs se produisent dans le processus de mise à niveau. Cette hétérogénéité est mauvaise,

Nous avons des milliers de ces boîtes sur le terrain. Nous gérons les dépendances des packages, l'enregistrement des processus, etc. via un package deb avec différents degrés de succès.

pourrait se rapporter à cela. Le modèle de serveur immuable efface cette source d'erreurs en détruisant essentiellement la notion d '«historique de mise à niveau» du problème.

Il existe maintenant différentes options pour implémenter le modèle de serveur immuable, deux choix populaires consistent à utiliser des images Docker, des images ou à utiliser des «images d'instance principale» de votre fournisseur de cloud (elles sont appelées AMI dans AWS et juste des images personnalisées dans Google Compute Engine) . Votre cas d'utilisation interdit l'utilisation de techniques basées sur le cloud, je suppose donc que les images Docker sont le seul choix éligible. (Dans un souci d'achèvement, il est certainement possible d'utiliser d'autres approches, par exemple en utilisant Virtual Box ou une solution de virtualisation similaire, comme alternative à Docker.)

Lorsque vous utilisez la technique de modèle de serveur immuable, vous introduisez un nouvel artefact (l'image Docker) représentant votre serveur et cet artefact peut également être testé, et il est très facile d'obtenir une configuration reproduisant fidèlement vos paramètres de production - en dehors de la charge de service.

Maintenant, pour considérer le problème concret que vous avez décrit, supposons que l'implémentation du modèle de serveur immuable avec Docker soit réellement ce que vous voulez. Étant donné que le système Docker et le système d'empaquetage Debian sont complémentaires plutôt que mutuellement exclusifs (cf. intro), nous devons encore répondre à la question de savoir si vous devez préparer un paquet Debian pour votre logiciel.

La pertinence d'utiliser un paquet Debian pour installer votre logiciel (dans l'image Docker ou sur un hôte) réside dans la complexité du problème de versioning que vous devez résoudre. Si vous exécutez en même temps plusieurs versions de votre logiciel, avez parfois besoin de rétrograder et avez des exigences de version complexes que vous devez documenter soigneusement, avoir un paquet Debian est un must. Sinon, cette étape peut être ignorée - mais comme vous avez déjà fait un effort pour produire et déployer ces packages, il n'y a pas vraiment de valeur à abandonner votre travail. Je suggère donc de continuer à produire vos paquets Debian.

Je pense que cela pourrait être une bonne option (des tests supplémentaires sont nécessaires)

Vous pouvez fournir une URL avec toutes les balises / version du conteneur que vous avez créé et les clients liront cette URL pour voir s'il existe une nouvelle version du conteneur.

Vous pouvez stocker des fichiers / paramètres personnels sur local et vous ne perdrez jamais ces informations dans les mises à niveau et vous vous assurerez que ce que vous avez créé et testé fonctionnera pour tout le monde de la même manière.

Même vous pourriez donner aux utilisateurs la possibilité de choisir la version parmi les disponibles qu'ils veulent utiliser (si vous voulez donner cette possibilité).

Ce sera comme "" seulement mettre à jour un paquet "", en parlant de récupérer seulement une nouvelle version du conteneur, bien mieux que de traiter avec les paquets debian;)

Docker me semble raisonnable, car vous pouvez apporter et tester des modifications au conteneur en interne, puis en fonction de votre processus de publication, redémarrez toujours les conteneurs en tirant: dernier ou quelque chose de similaire qui fournirait une mise à niveau testée.

Les considérations auxquelles vous devez faire face incluent le stockage des données car les conteneurs ne conservent pas les modifications au redémarrage, vous souhaiterez donc un volume de données. Il y a probablement beaucoup plus de considérations que vous auriez également une fois que vous y aurez creusé. Le système avec lequel je travaille actuellement (tous basés sur des dockers) est en développement depuis plus d'un an et nous trouvons toujours des domaines dans lesquels nous devons apporter des modifications au conteneur, aux configurations, etc.