TLPR : Docker est fantastique pour le développement en petites équipes.
J'ai commencé à m'intéresser à Docker à PyCon 2014 après avoir écouté l'excellent exposé introductif de @amjithr.
À l'époque, je faisais partie d'une équipe de 3 personnes travaillant sur le développement d'un logiciel analytique spécialisé. Ne disposant pas d'une équipe dédiée au DevOps, nous avons mis Docker aux côtés de Chef et de divers autres outils fantaisistes dans la catégorie « Nous ne sommes pas encore assez grands pour cela. »
En 2018, il semble y avoir un malentendu courant lorsqu'il s'agissait de conteneurisation : vous devez développer à l'échelle pour vous y mettre. Ce n'est plus le cas.
Bien sûr, vous profitez d'avantages tels que la mise à l'échelle automatique avec la plate-forme d'orchestration Kubernetes et les conteneurs en production, mais la mise à l'échelle est-elle vraiment le problème auquel vous êtes confronté en ce moment?
La conteneurisation peut résoudre vos problèmes avant même que votre application ne soit prête pour la production.
Chez Osedea, nous codons et maintenons des dizaines de projets clients.
Déployer des solutions personnalisées pour les plus grands projets (6 mois et plus) n'est pas un problème, passez x jours à s'amuser avec des fichiers de configuration n'affectera pas les résultats et ce gain de vitesse de développement de 1-3% en vaudra la peine à long terme.
Cependant, lorsque vous ne disposez que de 4 semaines pour développer une solution pour un client disposant d'un budget limité, ces x jours peuvent faire la différence entre respecter la date limite et la manquer.
Nous avons établi quelques exigences lors du développement de prototypes/projets à petite échelle :
- L'environnement de développement doit être le même pour chaque développeur
- Le temps de préparation des petits projets (un à trois mois) doit être minimal.
- Cohérence entre les petits projets pour réduire la courbe d'apprentissage.
Nous avons réussi à surmonter ces difficultés en utilisant Docker et Docker Compose. Nous utilisons principalement deux projets open-source comme modèles pour nos environnements de développement : LaraDock et NoDock.
LaraDock
Pour ma part, j'ai commencé à utiliser Docker en 2016 après que ma machine virtuelle Vagrant ait interrompu pour la énième fois mon développement en PHP pour une journée entière.
Heureusement pour moi, Docker Compose était sorti à ce moment-là, ce qui a facilité le passage de MV à Docker. Le reste de nos équipes nous ont rapidement emboîté le pas.
@Mahmoud_Zalt de LaraDock a été le premier grand projet open-source Docker Compose à fournir un environnement de développement incluant des batteries qui allait au-delà du «nous avons tout mis dans un conteneur, en espérant que cela fonctionne» ; cela a donné à chacun de mes services leur propre conteneur, et les a mis en réseau sans problème.
C'était aussi le premier grand projet open-source sur lequel je suis devenu un contributeur principal.
LaraDock a grandi et compte aujourd'hui plus de 5000 étoiles, 1500 forks et 180 contributeurs sur Github. Je le recommande vivement à tout développeur qui utilise PHP.
NoDock
Nous nous sommes retrouvés à développer de plus en plus de backends avec Node et nous avions envie de démarrer à une vitesse fulgurante.
Notre propre NoDock, un environnement Docker Compose pour les projets Node, a pris vie vers la fin 2016, nous avons commencé à l'utiliser pour des projets clients début 2017.
NoDock est fait pour être extensible, la plupart de nos projets commencent avec la configuration par défaut, qui se modifie au fil du temps pour grandir avec l'application. Il se trouve actuellement à plus de 400 étoiles et 60 forks.
L'un des plus grands avantages de NoDock est sa facilité à gérer plusieurs versions de Node à travers de multiples dépôts. Nous avons parfois 2 ou 3 dépôts configurés dans le même projet Docker Compose pour simuler notre environnement de production et faire exécuter le projet localement par un nouveau développeur prend 15 à 30 minutes maximum, y compris le téléchargement des images.
...
Alors que ces dernières années ont vu la plupart des grandes entreprises technologiques s'orienter vers la conteneurisation et les approches conteneur-first, espérons que 2018 verra même les équipes constituées d'un seul homme rattraper leur retard et qu'au tournant de la décennie, l'exécution d'un MV pour le développement ne sera plus qu'un lointain souvenir.
Image: Kevin Ku
