Quelle stratégie choisir pour conteneuriser une application .net 11 ?
.net 11 arrive à grands pas. Il est donc venu le temps de se poser moult questions sur ce qui change avec cette nouvelle version. Il est aussi temps de confirmer, ou contredire quelques rumeurs.
Avant d'aller plus loin, faisons un petit rappel des approches disponibles avec .net 11, et 10. Pour conteneuriser une application, nous avons deux solutions :
- dockerfile : l'approche historique, commune à toutes les technologies.
- dotnet publish : l'approche moderne disponible depuis .net 7.
Fidèle à mes mauvaises habitudes, je commencerai par la fin, en vous livrant l'approche que je recommande pour .net 10, et 11 : dotnet publish, sans aucune hésitation.
Maintenant, abordons la raison de ce choix, et commençons par tordre le cou à quelques idées reçues.
Il ne peut en rester qu'un !
Non, .net ne va pas soudainement abandonner dockerfile. Ceci est impossible. On ne peut pas vous interdire de conteneuriser une application .net, ou autre avec un dockerfile.
L'un sait tout faire, l'autre ne sait gérer que les cas simples ?
Dockerfile serait la seule véritable solution pour créer des images complexes. Dotnet publish ne serait en mesure que de publier le dossier bin d'une application .net. Voici les deux affirmations qui le dérangent le plus. Oui on peut tout faire avec dockerfile. Il en est de même avec dotnet pulish, car celui-ci s'appuie sur msbuild. On peut donc utiliser le XML d'un projet pour effectuer toutes sortes d'opérations. Tout comme on le fait avec msbuild depuis plus de 20 ans.
Seul dockerfiel offre de bonnes performances
Voilà une affirmation qui me décoiffe. Oui, c'est compliqué vu ce qui me reste sur le caillou, mais une expression reste une expression. Ce n'est pas moi qui fais les règles. Dockerfile, et dotnet publish peuvent fournir des performances similaires. Si votre image est le produit d'une opération de type multistage, dotnet publish devraient vous offrir les meilleures performances. Ceci est lié au fait que msbuild profite davantage des précédentes compilations que dockerfile.
Rapport complexité / optimisations
L'optimisation de dokerfile est un peu plus complexe. Il faut bien comprendre ce que l'on fait si l'on veut optimiser un multistage. Pour accélérer les builds sur les PC de développement, il est souvent plus facile de créer plusieurs images. On se retrouve donc à avoir à maintenir, et publier davantage d'images.
Comme évoqué un peu plus tôt, dotnet publish profile de msbuild. Il offre donc de bonnes performances sans trop de connaissances, et sans compliquer la maintenance. Si en plus, vous maitrisez bien vos builds .net, vous trouverez rapidement vos marques, et des solutions pour accélérer la build.
CI / CD et Pipelines
Côté DevOps, il n'y a pas de comparaison possible :
- dockerfile : dépendance à dotnet, et docker.
- dotnet publish : dépendance à dotnet.
Sur ce point on me dit souvent que docker est une dépendance facile à gérer. Je ne peux pas être d'accord. En fonction de votre plateforme DevOps, vous allez préférer éviter docker pour des raisons de performances ou compatibilité. Ce peut être le cas de certain mixes de cluster k8s, OS, cloud providers (le docker in docker que certain aiment tant détester, et que toutes les solutions ne supportent pas).
De plus, je rappelle un sujet qui parfois dérangent les personnes fans du multistage dockerfile : on ne créé jamais une image sans avoir exécuté des tests unitaires. Ajourd'hui, les solutions de workflow / pipelines, CI / CD s'appuient presque toutes sur des images. On complexifie alors le nombre d'images à gérer, et donc le nombre de versions à suivre, en plus des images référencées dans les dockerfile. Alors qu'avec dotnet publish, l'image de base donet/sdk suffit pour la build, les test, et dotnet publish (+l'image dotnet référencé dans votre projet .net).
Conclusion
J'espère vous avoir convaincu des avantages de donet publish pour .net11. Si vous n'êtes pas d'accord, faites le savoir ;)
