Remote Debugging .NET Containers

DotnetDockerBanner

You will find several articles that will talk about local debugging .NET container through the magic of Visual Studio or VS Code, but it’s not easy to find the right information for remote debugging.

Local debugging with the different IDEs is much easier because they install the .NET debugger in the container for us without telling us and configure it properly. Compared to traditional remote debugging for .NET Framework, debugging for .NET Core does not require the use of msvsmon.exe. Instead, you need to use vsdbg provided by OmniSharp.

Local debugging requires us to run our container on our machine from the compiled source code. This is convenient during the development phase when we produce our code, but it is less convenient when we need to fix an anomaly that occurs in a subsequent phase of our delivery process. In this case, local debugging of a container can be long and tedious given the time required to retrieve the correct version of the image to be executed and its dependencies.

In this article, we will see how to debug a remote Linux Container that contains an ASP.NET Core application. For reference, here is a Dockerfile generated by Visual Studio for an ASP.NET Core application:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. 
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base 
WORKDIR /app 
EXPOSE 80 
EXPOSE 443 

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build 
WORKDIR /src 
COPY ["TestRemoteDebugK8s.csproj", "/src"] 
RUN dotnet restore "TestRemoteDebugK8s.csproj" 
COPY . . 
WORKDIR "/src" 
RUN dotnet build "TestRemoteDebugK8s.csproj" -c Release -o /app/build 

FROM build AS publish 
RUN dotnet publish "TestRemoteDebugK8s.csproj" -c Release -o /app/publish 
FROM base AS final WORKDIR /app COPY --from=publish /app/publish . 
ENTRYPOINT ["dotnet", "TestRemoteDebugK8s.dll"]

 

Build once, deploy everywhere

A simple search will show you several debugging examples that require you to modify the Dockerfile. The simplest approach is to include the .NET Core vsdbg debugger directly in our container image. It is simple to understand, but it complicates the developer’s job because he has to generate a new docker image and redeploy it before he can debug.

In DevOps, we favor the Build once, deploy everywhere principle. The goal here is to minimize the chances of introducing anomalies in our application by recompiling after testing. If all the tests of our application are done on a Debug version that potentially includes the debugger and that must be recompiled in Release before delivering to production, we introduce a risk of failure or we have to redo more tests. This is why we try as much as possible to deliver the binary that was used during the testing phase and, in this case, the image of the container used for the tests.

The approach of modifying the Dockerfile therefore takes us away from our Build once, deploy everywhere approach. Instead, it is possible to use the Release version of our application/image for the first tests, as this configuration includes the debugging symbols by default.

Installing the debugger

The first thing we need to do to be able to debug our application is to install the debugger. As mentioned before, it is not included in the basic container image. This allows us to keep the image size as small as possible. When we debug a Container locally, the IDE associates a volume to our container that contains the .NET Core debugger. When debugging remotely, since the container image is already created, it is preferable to install it manually.

IMPORTANT: Depending on your container base image, the following script may need to be modified. Getting packages under Linux varies from one distribution to another. For the example, I used the aspnet:3.1-buster-slim base image which is based on Debian.

To install the debugger, we must first connect in interactive mode inside the container :

Docker:

docker exec -it remote /bin/bash

Here, remote is the name given to the container at startup.

Kubernetes :

kubectl exec -it remote-7ff879f496-5jvdg -- /bin/bash

Here, remote-7ff879f496-5jvdg is the name of the pod containing the container to be debugged.

Once connected, you need to run the following script:

apt update && \
apt install -y unzip procps && \
curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

Note the following:

  • The first line allows the apt manager package to update its local list of packages without installing them.
  • The second line installs unzip (required by the getvsdbgsh script provided by Microsoft) and procps (required by the IDEs to list the processes running in the container).
  • The last line fetches the debugger installation script and installs it to the /root/vsdbg location inside the container.

You will have noticed that you need to access the container in interactive mode to install what you need.

Attaching to the process

We now have a .NET Core application in a container with a debugger installed right next to it. Since you can’t just press F5 to start debugging, you have to attach to the process running inside the container. A valid approach would be to open an SSH channel to the container, but this is something that can be simplified by using the features of our favorite IDE.

With VS Code, you need to create a debugging launch configuration specific to the runtime context:

Docker

When our container simply runs under Docker, the following configuration can be used:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        },
        {
             "name": ".NET Core Docker Attach",
             "type": "coreclr",
             "request": "attach",
             "processId": "${command:pickRemoteProcess}",
             "pipeTransport": {
                 "pipeProgram": "docker",
                 "pipeArgs": [ "exec", "-i", "remote" ],
                 "debuggerPath": "/root/vsdbg/vsdbg",
                 "pipeCwd": "${workspaceRoot}",
                 "quoteArgs": false
             },
             "justMyCode":false,
             "sourceFileMap": {
                 "/src/": "${workspaceRoot}"
             }
         }
    ]
}

Launch.json file under .vscode folder

 

The interesting part is in blue. Note the following:

${command:pickRemoteProcess}:
Tells VS Code to open a pick list of the process to be debugged in the container. This is why procps had to be installed previously.

AttachProcess

« pipeProgram »: « docker » and « pipeArgs »: [ « exec », « -i », « remote » ], :
Tells VS Code the command line to execute when starting the debugger.

« debuggerPath »: « /root/vsdbg/vsdbg », :
Indicates where to find the debugger in the container file system. This path is linked to the end of the line seen above :

curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

« sourceFileMap »: {
               « /src/ »: « ${workspaceRoot} »:
This parameter tells the debugger where to find the source files for debugging. Since the default Dockerfile template copies the source files to a src directory in the container, we must indicate that the src directory actually corresponds to our working directory in VS Code.

Breakpoints do not work

If you have copied the configuration mentioned above entirely, you probably won’t have any problems with breakpoints. It is important to mention that, since we are using a Release version of our .NET Core application, the debugger will not be able to load the symbol (pdb) files automatically. You just need to specify the parameter « justMyCode »:false for the magic to work. By doing so, breakpoints will work normally.

Kubernetes

For Kubernetes, it is recommended to use the Kubernetes extension for VS Code. It makes it much easier to connect to a pod to debug it. However, you will still have to install the debugger yourself beforehand. Once this is done, you can use the context menu of a pod from the Kubernetes extension as follows :

VSCodeK8sExtensionDebugAttach
However, the default configuration sets the justMyCode parameter to true. If you want to stay in the same workflow as mentioned at the beginning of the article (Build once, deploy anywhere), you must be able to set this parameter to false. The extension does not yet allow to change the configuration used to attach the debugger. So we have to use our own debug configuration as follows :

{
    "name": ".NET Core K8s Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:pickRemoteProcess}",
    "pipeTransport": {
        "pipeProgram": "kubectl",
        "pipeArgs": [ "exec", "-i", "remote-75c859fc4c-gcx7d", "--" ],
        "debuggerPath": "/vsdbg/vsdbg",
        "pipeCwd": "${workspaceRoot}",
        "quoteArgs": false
    },
    "sourceFileMap": {
        "/src/TestRemoteDebugK8s/": "${workspaceRoot}"
    },
    "justMyCode":false
}

Launch.json file under the .vscode directory

Note that the name of the pod to be debugged will have to be modified according to your context.

Conclusion

I hope I’ve been able to clearly explain how to remotely debug a .NET Core container. Your environment may be a bit different if you have changed your base image or if your privileges are restricted in the runtime environment. You can always use the above examples to adapt them to your context.

A good application security practice is to use base images that contain only the bare essentials. The distroless images published by Google have been worked to eliminate what is not necessary to run your application. However, these images are problematic for debugging, as they do not contain a Shell that allows tools to be installed after the image is created. In Kubernetes, the use of Ephemeral Containers may help us with the arrival of Kubernetes version 1.18. A good subject for a next article!

 

Prefer reading in French? You can find a french version here : Déboguer les conteneurs .NET à distance

Déboguer les conteneurs .NET à distance

DotnetDockerBanner

Vous trouverez plusieurs articles qui parleront du débogage local d’un container .NET en passant par la magie de Visual Studio ou de VS Code, mais il n’est pas facile de trouver la bonne information pour le débogage à distance.

Le dégage local avec les différents IDE est beaucoup plus facile parce que ces derniers installent le débogueur .NET dans le conteneur pour nous à notre insu et le configurent adéquatement. Comparativement au débogage à distance traditionnel pour .NET Framework, celui pour .NET Core ne nécessite pas d’utiliser msvsmon.exe. Il faut plutôt utiliser vsdbg fournit par OmniSharp.

Le débogage local nous oblige à exécuter notre conteneur sur notre machine à partir du code source compilé. C’est pratique pendant la phase de développement où on réalise nos lignes de code, mais ça l’est moins lorsqu’on doit corriger une anomalie qui survient dans une phase subséquente de notre processus de livraison. Dans ce cas, le débogage local d’un conteneur peut s’avérer long et fastidieux étant donné le temps requis pour récupérer la bonne version de l’image à exécuter ainsi que ses dépendances.

Dans cet article, nous verrons comment déboguer un conteneur Linux à distance qui comporte une application ASP.NET Core. Pour référence, voici un Dockerfile généré par Visual Studio pour une application ASP.NET Core :

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["TestRemoteDebugK8s.csproj", "/src"]
RUN dotnet restore "TestRemoteDebugK8s.csproj"
COPY . .
WORKDIR "/src"
RUN dotnet build "TestRemoteDebugK8s.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "TestRemoteDebugK8s.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TestRemoteDebugK8s.dll"]

Build once, deploy anywhere

Une simple recherche vous montrera plusieurs exemples de débogage qui nécessitent de modifier le fichier Dockerfile. L’approche simple vise à inclure le débogueur .NET Core vsdbg directement dans notre image de conteneur. Cette approche est simple à comprendre, mais elle complexifie le travail du développeur parce qu’il doit générer une nouvelle image docker et la redéployer avant de pouvoir déboguer.

En DevOps, on privilégie le principe Build once, deploy everywhere. On vise ici à minimiser les chances d’introduire des anomalies dans notre application en recompilant après les essais. Si tous les essais de notre application sont fait sur une version Debug incluant potentiellement le débogueur et qui faut recompiler en Release avant de livrer en production, on introduit un risque de défaillance ou on se doit de refaire plus de tests. C’est pourquoi on tente au maximum de livrer le binaire qui a été utilisé pour faire les essais et, dans ce cas-ci, l’image du conteneur utilisée pour les tests.

L’approche de modifier le fichier Dockerfile nous éloigne donc de notre approche Build once, deploy everywhere. Il est possible d’utiliser la version Release de notre application/image des les premiers tests, car cette configuration inclut par défaut les symboles de débogage.

Installer le débogueur

La première chose que l’on doit faire pour être en mesure de déboguer notre application est d’installer le débogueur. Comme mentionné précédemment, il n’est pas inclus dans l’image de base du conteneur. On peut ainsi garder la taille de l’image la plus petite possible. Lorsqu’on débogue un conteneur en local, l’IDE associe un volume à notre conteneur qui contient le débogueur .NET Core. En débogage à distance, comme l’image de conteneur est déjà créée, il est préférable de l’installer manuellement.

IMPORTANT : Dépendamment de votre image de base pour votre conteneur, le script suivant pourrait devoir être modifié. L’obtention des packages sous Linux change d’une distribution à l’autre. Pour l’exemple, j’ai utilisé l’image de base aspnet:3.1-buster-slim qui est basée sur Debian.

Pour installer le débogueur, on doit d’abord se connecter en mode interactif à l’intérieur du conteneur :

Docker :

docker exec -it remote /bin/bash

Ici, remote est le nom donné au conteneur lors de son démarrage.

Kubernetes :

kubectl exec -it remote-7ff879f496-5jvdg — /bin/bash

Ici, remote-7ff879f496-5jvdg est le nom du pod contenant le conteneur à déboguer.

Une fois connecté, il faut exécuter le script suivant :

apt update && \
apt install -y unzip procps && \
curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

À noter :

  • La première ligne permet au package manager apt de mettre à jour sa liste locale de packages sans les installer.
  • La deuxième ligne installe unzip (requis par le script getvsdbgsh fournit par Microsoft) et procps (requis par les IDEs pour lister les processus en exécution dans le conteneur)
  • La dernière ligne récupère le script d’installation du débogueur et l’installe à l’emplacement /root/vsdbg à l’intérieur du conteneur.

Vous aurez noté qu’il faut avoir accès au conteneur en mode interactif pour installer ce qu’il faut.

S’attacher au processus

Nous avons maintenant une application .NET Core dans un conteneur avec un débogueur installé juste à côté. Comme on ne peut pas simplement appuyer sur F5 pour démarrer le débogage, on doit s’attacher au processus qui s’exécute à l’intérieur du conteneur. Une approche valable serait d’ouvrir un canal SSH vers le conteneur, mais c’est quelque chose qui peut être simplifié avec l’utilisation des fonctionnalités de notre IDE préféré.

Avec VS Code, il faut créer une configuration de lancement du débogage propre au contexte d’exécution :

Docker

Lorsque notre conteneur s’exécute simplement sous Docker, on peut utiliser la configuration suivante :

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        },
        {
            "name": ".NET Core Docker Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeArgs": [ "exec", "-i", "remote" ],
                "debuggerPath": "/root/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}",
                "quoteArgs": false
            },
            "justMyCode":false,
            "sourceFileMap": {
                "/src/": "${workspaceRoot}"
            }
        }
    ]
}

Fichier Launch.json sous le répertoire .vscode

 

La partie intéressante se trouve en bleu. Notons les éléments suivants :

${command:pickRemoteProcess} :
Indique à VS Code d’ouvrir une liste de sélection du processus à déboguer dans le conteneur. C’est pour cette raison qu’il a fallu installé procps précédemment.

AttachProcess

« pipeProgram »: « docker » et « pipeArgs »: [ « exec », « -i », « remote » ], :
Indique à VS Code la ligne de commande à exécuter lors du démarrage du débogueur.

« debuggerPath »: « /root/vsdbg/vsdbg », :
Indique où trouver le débogueur dans le système de fichier du conteneur. Ce chemin d’accès est lié à la fin de la ligne vue précédemment : 

curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

« sourceFileMap »: {
               « /src/ »: « ${workspaceRoot} » :
Ce paramètre permet d’indiquer au débogueur où trouver les fichiers sources pour effectuer le débogage. Comme le gabarit par défaut du Dockerfile copie les fichiers sources dans un répertoire src dans le conteneur, il faut indiquer que le répertoire src correspond en fait à notre répertoire de travail dans VS Code.

Les points d’arrêt ne fonctionnent pas

Si vous avez copié intégralement la configuration mentionnée ci-dessus, vous n’aurez sans doute pas de problèmes avec les points d’arrêts. Il est important de mentionné que, puisqu’on utilise une version Release de notre application .NET Core, la débogueur ne sera pas en mesure de charger les fichiers de symbole (pdb) automatiquement. Il suffit de spécifier le paramètre « justMyCode »:false pour que la magie opère. Ce faisant, les points d’arrêt fonctionneront normalement.

Kubernetes

Pour Kubernetes, il est recommandé d’utiliser l’extension Kubernetes pour VS Code. Il facilite grandement la tâche quand vient le temps de se connecter à un pod pour le déboguer. Cependant, vous aurez tout de même à installer le débogueur vous-même auparavant. Une fois que c’est fait, vous pouvez utiliser le menu contextuel d’un pod à partir de l’extension Kubernetes comme suit :
VSCodeK8sExtensionDebugAttach

Cependant, la configuration par défaut définit le paramètre justMyCode à vrai. Si on veut demeurer dans le même flux de travail comme mentionné au début de l’article (Build once, deploy anywhere), il faut être en mesure de passer ce paramètre à faux. L’extension ne permet pas encore de changer la configuration utilisée pour attacher le débogueur. Il faut donc utiliser notre propre configuration de débogage comme suit :

{
    "name": ".NET Core K8s Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:pickRemoteProcess}",
    "pipeTransport": {
        "pipeProgram": "kubectl",
        "pipeArgs": [ "exec", "-i", "remote-75c859fc4c-gcx7d", "--" ],
        "debuggerPath": "/vsdbg/vsdbg",
        "pipeCwd": "${workspaceRoot}",
        "quoteArgs": false
    },
    "sourceFileMap": {
        "/src/TestRemoteDebugK8s/": "${workspaceRoot}"
    },
    "justMyCode":false
}

Fichier Launch.json sous le répertoire .vscode

Il est à noter que le nom du pod à déboguer devra être modifié en fonction de votre contexte.

Conclusion

J’espère avoir réussi à expliquer clairement comment effectuer du débogage à distance d’un conteneur en .NET Core. Il se peut que votre environnement soit un peu différent si vous avez changé d’image de base où si vos privilèges sont restreints dans l’environnement d’exécution. Vous pourrez toujours vous inspirer des exemples ci-dessus pour les adapter à votre contexte.

Une bonne pratique de sécurité applicative est d’utiliser des images de base contenant le stricte nécessaire. Les images distroless publiées par Google ont été travaillées pour éliminer ce qui n’est pas nécessaire à l’exécution de votre application. Toutefois, ces images posent problème pour déboguer, car elle ne contiennent pas de Shell permettant l’installation d’outils après la création de l’image. Dans Kubernetes, l’utilisation des Ephemeral Containers pourra nous venir en aide avec l’arrivée de la version 1.18 de Kubernetes. Un bon sujet pour un prochain article !

Build 2019 – Jour 2

Écrire un article résumant une journée complète de conférences qui n’aurait pas l’air de sauter du coq à l’âne n’est pas une tâche facile. Pourtant, je pense que l’information recueillie aujourd’hui est très pertinente. C’est pourquoi je vous propose des résumés des différentes présentations intéressantes auxquelles j’ai assisté aujourd’hui à la deuxième journée de la conférence Build 2019 de Microsoft.

Productivité avec Visual Studio 2019

20190507_153018 (2).jpg

Le but n’était pas de vous énumérer toutes les améliorations de VS 2019 comme une liste d’épicerie, je mentionnerai seulement celles qui m’apparaissent plus pertinentes. Pour la liste complète, vous pouvez consulter les notes de livraison.

Depuis la version 2017, Visual Studio améliore sans cesse ses performances. Il gère de mieux en mieux les solutions de grande taille et la nouvelle expérience de démarrage ainsi que les filtres de solutions sont dans cette lignée.

Les Code lens sont maintenant offertes dans la version Community et sont aussi extensibles. Il est maintenant possible de créer ses propres Code lens!!!

On peut aussi voir ou éditer les fichiers de projet avec un banal double-clique. Know it, learn it, love it!

Aperçu de certaines fonctions

Dans les versions Preview, certaines fonctions sont disponibles pour recueillir le feedback. L’ajout de l’auto-complétion dans les chaînes de caractères RegEx a notamment retenu mon attention.

Aussi, IntelliCode a été livré formellement, mais certaines nouvelles fonctionnalités sont déjà en route.

Pour rappel, IntelliCode permet d’utiliser le Machine Learning pour améliorer l’expérience des développeurs. Entre autres, les éléments d’intellisense les plus populaires, dans le contexte de notre curseur, apparaîssent en premier.

Il sera prochainement possible d’entraîner le modèle d’IntelliCode avec notre propre code pour qu’il soit en mesure de nous aider avec les classes que nous développons nous-mêmes. L’exécution se fait localement pour plus de confidentialité. Il sera également possible de partager le modèle ainsi généré avec nos collègues au besoin.

Toute les équipes finissent par avoir une convention de style pour le code. Le fichier .editorconfig permet aux utilisateurs de VS de personnaliser cette expérience. Toutefois, il peut être difficile de répertorier toutes ces conventions. IntelliCode viendra à la rescousse et permettra de générer un fichier .editorconfig basé sur les conventions informelles de notre base de code.

JAM Stack + Azure Functions

Cette présentation était constituée d’une série de démos pour montrer l’intégration des différents outils de la JAM Stack telle que vue par John Papa et Matt Hernandez. Cet acronyme sert à désigner un ensemble de technologies qui fonctionnent bien ensembles. On parle ici de Javascript, APIs et Markup.

20190507_083546

Les démos ont servi à montrer comment il était facile de développer une application Angular dans VS Code qui repose sur un back-end Azure Functions écrit en TypeScript dans le même répertoire que l’application Angular. En plus des capacités formidables d’édition web, VS Code est un excellent outil pour développer et déboguer les Azure Functions localement sur notre poste. La démo utilisait NodeJS pour l’exécution locale et les présentateurs ont montré comment démarrer l’Azure Function et l’application web dans le navigateur en même temps en appuyant sur F5. L’utlisation du fichier launch.json étant la clé.

Les présentateurs ont aussi utilisé les extensions VS Code pour déployer leur application dans Azure directement, ce qui procure une expérience très intuitive et une boucle de rétroaction rapide. Ils ont terminés en montrant comment Azure DevOps pouvait être utilisé simplement pour assembler des artéfacts de déploiement et ensuite les déployer vers les ressources Azure. Dans le pipeline de build, l’utilisation des tâches npm permet de réutiliser le même outillage que l’environnement local pour la partie Angular. Bref, l’intégration est très intéressante et semble assez mature.

Windows Subsystem for Linux v2 (WSL2)

Microsoft a annoncé la nouvelle version de son Windows Subsystem for Linux : WSL 2. Les deux principaux avantages sont la performance et la compatibilité avec les fonctionnalités natives des distributions Linux. Le tout repose sur l’utilisation de la virtualisation légère qu’ils appellent Lightweight utility VM qui est rendu possible avec les travaux qui ont été faits pour le support des conteneurs dans Windows. Une VM Linux est donc démarrée par la couche WSL 2 qui s’occupe d’abstraire les détails pour nous. C’est pourquoi Microsoft distribuera les versions du noyau Linux via les Windows Update. Qui aurait dit que cela se produirait un jour? Toutes les distribution de Linux seront exécutées dans une seule VM en utilisant les fonctionnalités natives qui soutiennent les technologies des conteneurs sous Linux. Il est donc possible d’accéder aux fichiers Windows à partir de WSL et aussi d’accéder aux fichiers de la VM Linux à partir de Windows comme si de rien n’était. Les avancées de WSL 2 permettent aussi l’utilisation de Docker dans WSL directement.

20190507_104059.jpg

À la fin de la présentation, un rappel a été fait sur le mode « remote » de VS Code. Ce dernier permet d’exécuter l’interface utilisateur sous windows, mais de déléguer l’ensemble de l’exécution au WSL. Pour en savoir plus

Développement de microservices avec AKS, GitHub et Azure Pipelines

Microsoft est sérieux pour ce qui est de l’intégration de Kubernetes dans ses différentes plateformes. En plus de l’expérience du portail Azure en constante amélioration, les outils de développement demeurent une priorité. Dans une présentation comportant plusieurs démos, nous avons vu à quel point il est facile d’itérer rapidement dans un contexte AKS avec Visual Studio. Le débogage d’un conteneur dans AKS est possible directement à partir de notre IDE favori. Une possibilité incroyable est aussi de pouvoir modifier notre application sans avoir à regénérer notre image de conteneur et à la publier dans AKS. L’exécution se fait localement et AKS route les appels vers notre machine de développement, ce qui accélère grandement le développement. Tout cela est rendu possible grâce à DevSpaces : des espaces de développement isolés dans un cluster partagé. Un développeur peut alors modifier un composant et le tester sans impact sur les autres personnes qui effectuent des essais dans le même environnement.

20190507_130315

Des outils de ligne de commande ont été ajoutés à la CLI Azure pour faciliter le démarrage. Par exemple,  pour configurer notre espace, les lignes de commande suivantes sont suffisantes :

az aks use-dev-spaces -g [resourceGroupName] -n [clusterName]

az azds prep

az azds up

Il est donc facile de démarrer rapidement avec AKS dans Azure.

Des ajouts intéressants ont été fait dans Azure DevOps qui permettent de voir nos environnements Kubernetes directement dans le portail Azure DevOps.

Screenshot_20190507-225111_Chrome (2).jpg

Toujours dans le but d’accélérer le démarrage avec AKS, Azure DevOps fournit maintenant un assistant de création de pipeline pour AKS. Ce dernier automatise la création des fichiers azure-pipelines.yaml et des manifestes requis par Kubernetes pour déployer notre application. Le tout est alors archivé dans notre dépôt de code pour être modifié comme du code par la suite.

Un scénario qui est vraiment intéressant avec tous ces ajouts est celui de pouvoir effectuer des tests manuels dans un espace DevSpaces AKS basé sur une Pull Request. En détectant qu’un pipeline de déploiement a été déclenché à partir d’une Pull Request, on peut concevoir notre pipeline de sorte qu’il crée un espace DevSpaces à la volée pour nos tests. Toutes ces étapes sont intégrées également dans GitHub.

Conclusion

En plus des nouveautés mentionnées plus haut, une foule d’autres sujets ont capté mon attention comme l’annonce de l’API Management d’Azure qui permettra de fédérer des gateways on-prem avec Azure à l’aide de conteneurs.

De plus, les discussions avec les équipes des différentes produits sont très intéressantes pour obtenir des réponses détaillées sur une foule de sujets.

Encore une autre belle journée en perspective demain. Au menu, Web Assembly et plus!

 

Azure DevOps Wiki + VS Code : Super!

Depuis quelques semaines, je rédige de la documentation pour mon travail autour du DevOps. Nous avons cru bon en équipe d’appliquer ce que l’on prône comme pratique : « Everything as Code ». C’est pourquoi nous avons choisi une approche qui vise à considérer la documentation comme du code. Pour ce faire, nous avons bien entendu opté pour la syntaxe Markdown. Ce « langage » est relativement simple et portable si on utilise les fonctionnalités de base. Pas que je n’ai pas envie de parler de la documentation en tant que code, mais je trouvais intéressant de plutôt partager la démarche qui m’a amené à choisir un ensemble d’outils comme Azure DevOps Wiki et VS Code pour accélérer la mise en place de notre documentation.

Comparaison des plateformes évaluées

L’idée n’est pas d’écrire le résultat complet de l’analyse par laquelle je suis passé, mais je pense que les faits saillants de la comparaison sont intéressants. En effet, différents outils sont disponibles pour rédiger, héberger et publier votre documentation. Certaines plateformes sont Open Source et d’autres sont payantes.

MkDocs

On m’avait déjà parlé de cette plateforme dans le passé. Il s’agit d’une boîte à outils qui permet de générer un site de documentation à partir de fichiers Markdown. Le HTML ainsi obtenu doit alors être publié à l’aide d’un hébergeur ou d’un serveur web quelconque. L’idée n’est pas mauvaise et offre la possibilité de personnaliser l’aspect final et général du site de documentation. Toutefois, il faut être un peu à l’aise en Python ou être prêt à l’apprendre. Comme c’est un des langages les plus populaires dans le monde, ce n’est pas une mauvaise chose! Étant toutefois néophytes dans ce domaine, je n’aimais pas la barrière à l’entrée. Par ailleurs, certaines des équipes avec qui je travaille ont eu des petits problèmes de performance au niveau de la recherche qui peut être longue à s’initialiser. Le moteur de recherche est Lunr.js.

Site MkDocs

DocFx

DocFx est la plateforme de documentation as code de Microsoft. Elle sert à plusieurs de leurs sites de documentation ou est en fait un produit Open Source dérivé de leur vraie plateforme. Son gros avantage est qu’il est plutôt en .NET Core, donc plus facile d’approche que le Python dans mon cas. Cependant, il est aussi basé sur Lunr.js. Comme j’avais peur de vivre les mêmes problèmes de performance que mes collègues, je n’aimais pas l’idée. Le support multilingue prévu pour une nouvelle version prochainement était aussi intéressant.

Pour publier le site en HTML, il faut aussi trouver une manière de l’héberger, ce qui n’est pas intéressant dans l’optique d’un Minimal Valuable Product (MVP). Je voulais valider l’approche « As Code » avant de m’embourber dans les problématiques d’hébergement ou autre.

Site DocFx

Azure DevOps Wiki

C’est alors que j’ai découvert Azure DevOps Wiki. Une plateforme de documentation Wiki fournie avec Azure DevOps. En plus d’être hébergée gratuitement à même notre abonnement Azure DevOps, elle permet de publier les fichiers Markdown directement à partir d’un repo Git.

Publish

On peut choisir la branche de laquelle on veut publier et aussi un sous-répertoire au besoin. Tout changement qui sera inclus dans un commit sera automatiquement en ligne sur le Wiki.

Ce qui est également important dans un site de publication de documentation est d’avoir une bonne navigation. Azure DevOps Wiki permet de structurer la documentation de manière hiérarchique en créant des répertoires dans le repo. C’est plutôt minimal, mais ça « fait la job ». Pour plus de détails sur les options disponibles, consultez la page suivante.

Révisions et collaboration

L’avantage d’utiliser les repos Git pour la documentation vient avec l’utilisation des Pull Request (PR). Auparavant, le meilleur moyen était de distribuer un document à travers un courriel ou par Teams/Slack et de recueillir les commentaires. Il fallait aussi intégrer les commentaires de chacun dans un même document et plusieurs personnes ne pouvaient pas collaborer à la révision en prenant connaissance des commentaires des autres. On aurait peut-être pu utiliser un document en édition partagée, mais cela comporte un certain nombre de défis également.

Avec les PR, on obtient une gestion unifiée des commentaires, la possibilité de désigner des réviseurs qui seront informés par courriel que leur contribution est requise et la possibilité de discuter très tôt de son contenu avec le mode brouillon.

Brouillon

Bref, un excellent outil de collaboration pour de la documentation.

PR

Comment gérer le multilingue ?

Un autre critère de sélection pour notre plateforme était d’être en mesure de gérer les différentes langues d’une manière correcte. Je voulais que la documentation des deux langues puisse faire partie de la même PR afin de comparer le contenu traduit avec l’original et surtout de pouvoir valider que le contenu était fourni dans les deux langues.

Pour ce faire, j’ai opté pour une solution simple : un répertoire racine pour chaque langue. Évidemment, la responsabilité nous incombe de s’assurer que la structure est équivalente dans les deux hiérarchies, mais c’est un compromis acceptable.

Azure DevOps ne supporte pas la gestion des langues lors de la publication. Il faut donc publier deux Wikis distincts : un pour chaque langue. C’est là que prends de l’importance la possibilité de publier un sous-répertoire.

PublishSubfolder

VS Code + Extensions

Pour la création du contenu Markdown, VS Code est un éditeur pas mal du tout si on installe certaines extensions :

  • Markdown All in One :
    Permet plusieurs raccourcis dans l’édition du Markdown comme les effets gras et soulignés, la création de tables des matières et la possibilité d’avoir un panneau de prévisualisation intégré à VS Code.
  • Azure Repos :
    Extension fournie par Microsoft pour gérer les éléments relatifs à Azure DevOps comme les PR.
  • Paste Image :
    Permet de coller une image provenant du presse-papier directement dans le Markdown. Le raccourcir Ctrl + Alt + V crée un fichier dans le même répertoire que le fichier en édition et ajoute un lien où se trouve le curseur.

EditionMD

What’s next ?

Ces outils permettent une mise en place rapide d’un site de documentation. Lorsque des besoins plus spécifiques apparaîtront, on pourrait imaginer de finalement publier le même Markdown avec une des plateformes mentionnées précédemment et, pourquoi pas, intégrer la recherche Bing Search ou QnA Maker d’Azure 😊. Bonne documentation!

DevOpsDays Montréal 2018 – Jour 2

IMG_3767.JPG

Dans mon précédent article, je suis revenu sur les faits saillants de la première journée de la nouvelle conférence DevOpsDays Montréal. C’est maintenant le temps de faire le tour de la deuxième journée. Au menu, nous avions Keynotes, API Gateway, changement de culture et sécurité. Let’s go!

Industry 4.0 – Daniel Koffler

Pour faire suite à la conférence d’hier portant sur les changements menant à la discontinuité, Koffler a présenté les changements que subissaient présentement les secteurs manufacturiers et industriels. La quatrième révolution industrielle est en marche et elle se nomme cyber-physique. Après la vapeur, l’électricité et l’électronique, cette révolution est reliée à l’interconnexion des éléments automatisés.

cyberPhysicalRevolution

(image : https://people.duke.edu/~mp275/research/evm.html)

Pour Koffler, ces secteurs ont besoins des pratiques DevOps et ils auront besoin des habiletés des gens experts dans le DevOps. Rien pour régler le problème de main-d’œuvre…

Voyage en Tanzanie – Adrian Hooper

En relatant son voyage en Tanzanie, Hooper rappelle les fondements du développement agile et DevOps. Livrez fréquemment, mais pour une bonne raison : parler aux utilisateurs. L’intention est de leur parler afin de comprendre leurs besoins et de pouvoir réagir au feedback obtenu rapidement.

Étouffez-vous ? Un cas d’API Gateway – Alex Gervais

Alex Gervais a été le seul à faire sa présentation en français. Ce n’est pas la seule chose qui m’a plus, au contraire. Il a présenté un retour d’expérience sur l’introduction d’un API Gateway dans leur solution kubernetes. Étape par étape, il a expliqué le chemin qu’ils avaient pris chez AppDirect pour en arriver à utiliser ambassador.

Pour cette entreprise, les principes suivants étaient très importants :

  • Pas de dépendances à un fournisseur cloud
  • Pratiques gitops
  • Architecture cloud-native

C’est pourquoi ils ont utilisé Kubernetes pour gérer leur infrastructure. Toutefois, l’exposition de leurs différents services était faite au départ de manière traditionnelle avec un balanceur de charge. Ils géraient leurs entrées DNS et les ports d’accès des nœuds de manière statique, ce qui est vite devenu compliqué. En plus, ils ont voulu simplifier l’API exposé à leurs clients afin d’abstraire différents détails internes. Ils en sont donc venus à opter pour un API Gateway.

APIGateway.JPG

Implementing DevOps in an International multi-cultural and multi-geography environment – Jesse Hurkens

Malgré le titre, cette présentation a davantage parlé de l’importance de la culture DevOps au sein d’une entreprise. M. Hurkens a marqué avec énergie qu’il ne suffit pas d’avoir un beau « pipeline » DevOps pour avoir un vrai succès. C’est d’abord une affaire de culture et il faut que cette culture change, au besoin, pour accueillir les échecs et en apprendre. Mais par où commencer?

IMG_3772

Il recommande d’initier ce changement par un petit projet qui, lorsqu’il aura eu son succès, pourra rayonner sur les autres. La pollinisation peut se faire de manière organique et elle créera une fondation solide dans l’organisation. Un truc intéressant qu’il mentionne est de donner des objectifs communs à tous les silos de notre organisation afin de faire travailler les gens dans la même direction.

Voici aussi les principaux challenges qu’il note dans les entreprises qui amorcent le voyage DevOps :
IMG_3773

Security Considerations for Containers as a Service (CaaS) and Serverless Architectures – Tsvi Korren

Cette présentation a été selon moi une des mieux structurée. Le présentateur a réussi à bien expliquer les enjeux de sécurité autour du serverless et des conteneurs hébergés et gérés. Si j’essais de résumé, l’enjeu est que l’abstraction de l’infrastructure demande aux spécialistes de sécurité de revoir leurs mécanismes de mitigation des risques. Traditionnellement, on avait l’habitude de mettre en place des antivirus et des contrôles d’accès à l’exécution, mais il n’est pas toujours aussi facile de bien contrôler ces éléments dans un monde où on a aucune visibilité sur ce qui héberge notre code. Comme l’OS et le runtime d’exécution est complètement abstrait, on ne peut pas le sécuriser.

Il propose donc quelques mesures qui peuvent aider comme de baser les images docker sur les versions les plus légères des OS et d’intégrer les validations de sécurité dans le pipeline de livraison. (« Shift-left »).

IMG_3776

Comme ce n’est pas suffisant, il recommande de faire en sorte que si un conteneur est compromis, qu’il ne donne pas accès à de multiples ressources. On doit donc pratiquer la micro-segmentation et donner les accès qui sont vraiment requis à chaque ressource. (Shift-up).

IMG_3775.JPG

Pour finir, voici les différents contrôles de sécurité généraux qu’il recommande :
IMG_3777.JPG

Le DevSecOps a encore de la maturité à prendre, mais certains outils sont déjà utilisables dans nos pipelines de développement pour détecter les vulnérabilités dans les images Docker que l’on construit et que l’on déploie. En voici quelques exemples :

  1. Microscanner
  2. Kube-Hunter
  3. Kube-bench
  4. Arachni

Conclusion

La conférence s’est achevée avec des Open Spaces qui ont été assez diversifiés. Pour moi, cette conférence a été grandement teintée d’infrastructure et de gestion des opérations. J’avais une conception du DevOps un peu plus équilibrée entre le développement et les opérations. Peut-être que c’est seulement parce que les pratiques en émergences sont surtout du côté de l’infrastructure. Je me demande maintenant s’il faut voir le DevOps comme étant plutôt les pratiques de développement adoptées par les gens des opérations… Mon côté développeur s’est senti un peu délaissé durant ces deux jours… Malgré tout, c’est une conférence que je recommande pour ceux qui veulent apprendre des expériences des autres et aussi à ceux qui veulent partager ou faire des rencontres.

DevOpsDays Montréal 2018 – Jour 1

logoDevOpsDays

J’ai la chance de participer à la conférence DevOpsDays Montréal 2018 qui en est à sa première édition. Comme cette conférence est relativement nouvelle, je vous décrirai les présentations auxquelles j’ai assisté, mais je tenterai aussi de dépeindre un peu l’ambiance et l’organisation de l’événement en guise de conclusion.

KeyNote #1 – Alistair Croll

Dans sa conférence principale, M. Croll a placé les bases qui justifient, selon lui, l’adoption des pratiques DevOps et surtout, le changement de culture que les entreprises doivent prendre pour survivre. En relatant les évolutions fulgurantes dans plusieurs domaines comme l’agriculture et l’émergence de nouveau modèles comme la rémunération pour les youtubeurs, il a mis l’emphase sur la discontinuité. Pour lui, ce qu’il faut surveiller, ce ne sont pas les éléments de rupture ou perturbateurs dans notre marché, mais plutôt ceux qui vont mener à discontinuer certaines façons de faire ou certains produits. Chaque industrie et chaque entreprise doit se poser les bonnes questions pour être en mesure d’innover.

Traditionnellement, les entreprises commençaient par avoir du succès en développant un procédé ou une approche et faisaient en sorte de l’étendre à plus grande échelle par la suite. Exemple : trouver une façon de vendre un produit facilement et ensuite engager plusieurs vendeurs qui adopteront la même approche pour vendre les mêmes produits. Cependant, le passé n’est plus garant du futur. L’adaptation l’est.

Pour la plupart des organisations d’aujourd’hui, la performance passe par les TI. Tout est maintenant TI. C’est donc logique de devoir automatiser et améliorer les processus TI pour être en mesure de s’adapter aux changements qui surviennent rapidement tout en innovant. Le DevOps est la clé pour y arriver. Les autres compagnies vont le faire. À vous de choisir votre destiné.

Shaky to solid: a test-based approach to legacy code – Catherine Proulx (CNRC)

Cette présentation avait pour but d’indiquer aux gens que le code legacy est inévitable et que l’on doit le considérer et surtout le respecter. On ne peut pas penser tout refaire le code qui ne répond pas aux critères de qualité actuels sur cette seule base.

La seule façon de prendre le contrôle du code legacy et d’inverser la vapeur est d’ajouter des tests automatisés. Mme Proulx propose de commencer par la correction des anomalies plutôt que de viser une approche TDD sur l’ensemble d’un système. Lorsqu’on travaille sur une anomalie, il est recommandé d’ajouter des tests pour d’abord prouver qu’elle existe et aussi prouver que nous avons bel et bien réglé le problème avec notre modification. Elle ne croit pas aux projets qui visent à ajouter des tests sur une partie majeure d’une application. Ça doit se faire de manière itérative, un changement à la fois.

Elle mentionne aussi qu’il faut faire attention à la métrique de couverture de code. Étant déjà discutable en contexte d’un nouveau développement, elle ne représente pas grand chose dans un contexte de code patrimonial. Comme il y forcément un paquet de bouts de code qui ne sont pas couverts par des tests automatisés, on ne peut s’y fier pour nous donner un sentiment de sécurité.

Catherine Proulx fait aussi mention d’un type de tests qu’elle utilise avec du code patrimonial. Elle le nomme « test canary ». Ça ressemble davantage aux tests de caractérisation que présente Michael Feathers dans son livre « Working Effectively with Legacy Code« . Ces tests permettent de comprendre ce que fait un bout de code patrimonial avant de le modifier. Une fois ce harnais de sécurité en place, on peut procéder à la modification avec confiance.

Mme Proulx a aussi profité de l’occasion pour mentionner que les tests manuels ne sont pas choses du passé. Bien que plusieurs se plaisent à dire qu’il faut tout automatiser, elle n’a pas vu un endroit encore où les tests manuels ont été annihilés. Elle dit même que plutôt que de les appeler tests manuels, certaines firmes les appellent maintenant tests utilisateurs. 🙂

Burnout: community problem & community solution – Jason Yee (DataDog)

M. Yee a présenté les enjeux du surmenage et de l’épuisement professionnel. Il a donné plusieurs conseils sur la manière de le détecter et sur les façons de le prévenir. Une multitude de ressources ont été citées. Vous pouvez trouver sa présentation à l’adresse suivante.

http://bit.ly/dodyul-burnout

IMG_3763[1]
Le lien avec le DevOps était un peu tiré par les cheveux. En se référant à une autre présentation, il dit que le DevOps, par sa stabilité, crée un climat plus serein dans les équipes de développement et qu’il contribuerait donc à diminuer le taux d’épuisement.

L’élément le plus troublant dans la présentation selon moi a été le parallèle qu’il a fait entre le CAP Theorem pour les systèmes distribués et celui pour la vraie vie. Il y trois composantes : Famille, Travail et Santé physique. Malheureusement, pour ceux qui croient à ce théorème, on ne peut avoir que deux des trois composantes à la fois.

Next Generation Config Mgmt: The Language – James Shubin

Cette présentation portait sur un projet open source créé par le présentateur. Il vise à rendre dynamique la gestion de la configuration à différents niveau à l’aide de la programmation réactive et d’un nouveau langage inventé pour l’occasion. Basé sur Etcd, on peut y définir des règles définissant la configuration à différents niveau de nos VMs ou cluster.

Ce projet demeure expérimental pour le moment, mais il est vrai qu’il y a du potentiel à ce niveau. Par exemple, on peut définir des règles beaucoup plus complexes d’auto-scaling basées sur autre chose que le CPU et la mémoire. La seule limite est l’imagination des développeurs. Reste à voir si ce projet connaîtra l’envol que son créateur lui souhaite.

https://github.com/purpleidea/mgmt

Open Spaces

J’ai découvert ce concept aujourd’hui. En bref, on a proposé aux participants à la conférence de cibler des sujets dont ils voulaient parler. Les gens se sont regroupés autours des sujets qu’ils jugeaient les plus intéressants afin de discuté.

Pour ma part, la séance que j’ai le plus apprécié est Scaling Kubernetes. Certaines personnes ont partagé leur expérience autour de Kubernetes, Docker, Istio, Weave Net etc. Il semble, bien que l’engouement soit présent, qu’il n’est pas si facile de faire fonctionner ces technologies. Il a été fait mention de plusieurs problématiques dans le déploiement de Kubernetes à plus grande échelle comme la latence DNS, la segmentation réseau complexe et la gestion des clusters proprement dite.

Le découpage des cluster et namespace semble être un enjeu de taille. Est-ce qu’il est mieux d’avoir un gros cluster en production ou plusieurs? Le groupe penchait plutôt vers le plusieurs. Toutefois, en avoir trop occasionne une maintenance difficile et ardue. La question n’a pas été réglée.

Mon constat est que ces technologies fonctionnent, mais elles ont un coût important en apprentissage et en maintenance. Les efforts et la complexité demeurent considérables. Soyez prêts à configurer des vnet, des politiques réseaux et des ingress/egress à profusion. Et bonne chance quand surviendra une mise à jour de ces technologies. Ce qui devrait arriver… il y a tout juste une minute… 🙂

Conclusion

Les présentations ont été un peu légères à mon avis, mais c’est quand même réussi pour une première journée de conférence. L’ambiance est conviviale et dynamique. Les fournisseurs commerciaux ont peut-être une trop grande place, mais la conférence n’aurait pas lieu sans eux. Je souhaite que cette conférence puisse prendre de la maturité afin de rendre justice au DevOps. Je pense qu’on pourrait y ajouter un peu de professionnalisme, mais les intentions sont louables. Je suis convaincu que ça s’améliorera dans le futur vu le succès de l’édition 2018.

À suivre demain pour le résumé de la deuxième journée!

MS Build 2018 Day 1

msbuild2018

Le keynote de cette édition 2018 du Build m’est apparu moins riche que l’année dernière en termes de nouveautés et de percées technologiques sans pour autant me décevoir. J’ai eu une impression de continuité dans le message et la perception que Microsoft confirmait et affinait sa vision du futur. Voici les points qui ont retenu mon attention.

Aujourd’hui l’informatique est omniprésente. Le monde est sur le point de devenir un ordinateur géant, hyper connecté, générant des masses de données. L’informatique fait partie de notre quotidien que ce soit au travail ou dans la vie privée. Ce monde présente beaucoup d’opportunités et nous mettra devant nos responsabilités en tant qu’humains. La mission que Microsoft se donne est de fournir les plateformes et les outils aux individus et entreprises pour concevoir les solutions de demain.

La stratégie de Microsoft repose sur 3 grands piliers:

  1. Le respect de la vie privée. Il s’agit d’un droit fondamental qui doit être respecté. Microsoft s’engage à fournir des plateformes et des outils qui facilitent la traçabilité et la mise en place de la conformité qui assure ce respect de la vie privée.
  2. La cybersécurité. Évidemment dans un monde connecté d’aujourd’hui, il est nécessaire d’investir dans la sécurité et la cryptographie. Il faut fournir des outils et des librairies qui facilitent le développement d’applications sécurisées.
  3. L’étique de l’intelligence artificielle. Qu’est ce que la machine fait et qu’est-ce qu’elle devrait faire. S’assurer que les innovations sont accessibles au plus grand nombre et qu’elles préservent les droits de l’homme.

Ces trois grands piliers devraient être des préoccupations collectives. La contribution de Microsoft à ce niveau est de rendre les outils et les technologies disponibles au plus grand nombre et pas seulement dans les mains de deux ou trois grandes entreprises. La stratégie d’ouverture et d’open sourcing de ses technologies se poursuit.

Azure se porte bien.

L’offre infonuagique de Microsoft est au top:

  • 90% des compagnies qui composent le fortune 500 utilisent Microsoft Azure pour gérer leurs affaires.
  • Les développeurs aiment l’homogénéité de la plateforme et ses services que ce soit pour la conception, l’exploitation et la configuration
  • En 2017 pas moins de 130 services et fonctionnalités majeures ont été mises en place. 70 seront mises en place et/ou annoncés pendant la conférence Build

Intelligent cloud – intelligent edge

D’ici 2020, 20 milliards d’appareils intelligents connectés devraient être en fonction. C’est 3x plus que le nombre d’humains vivant sur terre aujourd’hui. Tous ces appareils connectés vont générer des volumes de données astronomiques que même le cloud ne pourra pas digérer tels quels. L’idée est donc de déporter certains traitements du cloud (intelligent cloud) vers ces appareils (intelligent edge). Par exemple un appareil ne transmettra pas intégralement un flux vidéo vers le cloud pour y être analysé. Plutôt le flux sera analysé en local sur l’appareil et seules les informations pertinentes identifiées seront transmises vers le cloud. Cela permettra de diminuer drastiquement les volumes échangés.

Dans ce domaine Microsoft a effectué quelques annonces qui montrent clairement qu’il ne s’agit pas que d’un concept mais qu’il y a du concret à venir prochainement:

  • Le runtime IoT Edge va être rendu open source pour favoriser son portage partout où cela sera nécessaire. A terme cela viendra augmenter l’offre d’appareils capables d’exécuter localement des modèles jusque-là destinés à être exécutés dans le cloud.
  • Un partenariat avec Qualcomm pour produire une caméra intelligente capable d’analyser en temps réel le flux audio et vidéo avec des modèles personnalisés entrainés dans le cloud et déployés directement dans la caméra. Le tout viendra avec un SDK permettant à tous d’exploiter la technologie.
  • Le projet Kinect pour Azure consiste à livrer un matériel compact inspiré de la Kinect et influencé par HoloLens qui permettra l’analyse du champ de vision, l’évaluation du relief, la reconnaissance d’objets ainsi que des mouvements du corps. Prometteur.
  • Un partenariat avec Dji pour intégrer la technologie IoT Edge dans un drone high tech. DJI fournira un API pour Windows 10 permettant de contrôler le plan de vol ainsi que de récupérer les données émises par le drone.
  • Un kit de développement pour la gestion de la parole qui sera supporté par plusieurs fabricants dont Roobo par exemple qui fournit un haut-parleur intelligent capable de supprimer le bruit ambiant dans un flux audio pour améliorer l’efficacité de la reconnaissance vocale dans les environnements bruyants.
  • Project Brainwave est une offre azure qui permet de tourner des modèles AI sur des FPGA. Le temps de latence HW est diminué de 5x. La vitesse d’exécution constatée est 10 à 12x supérieure à un CPU classique!

Les agents conversationnels (aka Chatbots)

Les agents conversationnels représentent une nouvelle catégorie d’applications dont tout le monde veut. Toutes les compagnies veulent en développer des personnalisés qui répondent très précisément à leurs besoins.

C’est un domaine dans lequel il y a encore beaucoup d’innovations à venir pour améliorer la richesse d’interaction avec l’humain mais aussi pour permettre à ces agents de converser entre eux! Pas moins de 100 nouvelles fonctionnalités ont été introduites pour améliorer leurs personnalisations.

Microsoft supporte aujourd’hui 16 canaux différents pour déployer les applications créées avec son Bot Framework. Cela permet d’augmenter la portée de nos applications conversationnelles.

Cortana + Alexa

cortana_alexa

Un grand moment de ce keynote a été l’annonce du partenariat signé entre Microsoft et Amazon pour permettre à leurs Ai respectives, Cortana et Alexa, d’interagir entres elles. La démonstration sur scène a été sans faille et très probante. C’est un passage que vous pourriez avoir envie de regarder. Tous ces scénarios de productivité qui impliquent la reconnaissance vocale pour effectuer des tâches comme ajouter un article à la liste d’épicerie ou céduler un rendez-vous sont encore perçus comme de la science-fiction et pourtant sont déjà bien réels.

Lors d’une conversation avec Alexa, on peut lui demander de passer le contrôle à Cortana et vice et versa. Cortana est implantée dans Windows 10, au coeur des applications Office et bientôt dans Microsoft Teams. Cela ouvre des horizons plus larges.

Visual Studio Live Share

vsliveshare

Dans le domaine de la productivité des développeurs, Microsoft a annoncé l’arrivée de Visual Studio Live Share. Visual Studio Live Share est une extension qui permet de partager son environnement de développement avec une autre personne pour obtenir de l’assistance. Au départ je m’attendais à quelque chose du genre logiciel de prise de contrôle à distance optimisé pour développeur. La démo a finalement dépassé de loin mes attentes. Voici une liste des fonctionnalités et caractéristiques les plus intéressantes:

  1. L’extension fonctionne aussi bien pour Visual Studio 2017, Visual Studio for Mac ainsi que pour VS Code. Lors du partage, chaque personne utilise l’outil qui lui convient le mieux.
  2. Le développeur qui a besoin d’aide, invoque l’extension pour générer une URL qu’il transfère ensuite si à la personne qui va aider pour lui permettre de rejoindre la session.
  3. La personne qui aide peut suivre l’activité du développeur pour voir et comprendre. Elle garde cependant une autonomie pour effectuer des recherches et analyses dans le code sans impacter le développeur. Elle peut par exemple ouvrir d’autres fichiers de la solution du développeur. À tout moment, elle peut se resynchroniser avec l’activité du développeur.
  4. Les sessions de débogage sont partagées. La personne qui aide peut mettre des points d’arrêts à distance dans le code, inspecter le contenu de variables et utiliser la plupart des fenêtres du débogueur.
  5. Cerise sur le gâteau, dans le cas de débogage de services ou sites web, il est possible de les rendre accessibles à la personne qui aide et ce même s’ils sont hébergés localement sur le poste du développeur! Absolument bluffant.

VSTS et DevOps

VSTS_DevOps

Quelques démos très intéressantes qui démontrent l’efficacité et le degré d’intégration de tous les outils fournis dans la plateforme azure:

  1. Démonstration de l’intégration de AppCenter avec GitHub ou comment construire un pipeline DevOps fonctionnel en 3 minutes. Sur base de l’URL du repo GitHub qui contient l’application mobile, l’outil de Microsoft clone le repo, analyse le code, identifie le langage de développement utilisé, les plateformes mobiles ciblées et génère un pipeline CI-CD sans intervention humaine ou presque. La compilation démarre, l’application est déployée sur tous les appareils du marché.
  2. Démonstration du projet DevOps par Donovan Brown. Cette démo mérite d’être vue rien que pour la prestation de Donovan. Un vrai showman. La démo consiste à créer un pipeline CI-CD pour une nouvelle application. On commence par choisir le langage de développement, ensuite les framework principaux et finalement la plateforme d’exécution (AKS ou App Service). Click Finish et quelques secondes plus tard tout est configuré, il ne reste plus qu’à coder.
  3. Release Gates permet de gérer le déploiement incrémental d’une application en utilisant plusieurs groupes de consommateurs cibles. Un lien est fait avec les mécanismes de surveillance pour éventuellement arrêter la propagation de l’application à d’autres groupes quand les métriques mettent en lumière des problématiques.
  4. Il est maintenant possible de créer une branche dans un repo Git directement à partir d’un work item de carnet de sprint. L’intérêt réside dans le fait que la branche est associée au work item pour une traçabilité accrue.

 

Sonarqube – Plugin VB.NET Gratuit

sonarLogo

Sonarqube est un outil plus qu’intéressant pour gérer les métriques de code de manière centralisée. Il permet de voir du même coup d’œil les analyses statiques de code de plusieurs langages comme C#, JavaScript, Java et plusieurs autres. Le principal élément d’intérêt dans cet outil est de pouvoir évaluer et quantifier la dette technique d’une application.

Le problème?

L’organisation pour laquelle je travaille était très intéressée par l’outil (bon d’accord, disons que c’était moi plus que les autres…), mais un élément était bloquant pour vraiment évaluer l’outil : l’analyse du langage VB.NET coutait 6000 euros et est maintenant inclus dans un package pour entreprise qui requiert un abonnement. Bref, difficile de valider l’utilité de l’outil quand notre dette réside probablement dans le code patrimonial qui a été fait depuis plusieurs années, principalement en VB.NET.

 

Radin ou ingénieux?

Les motivations derrière la découverte que j’ai faite peuvent laisser place à interprétation mais, en analysant le code du plugin C#, j’ai pu remarquer que l’équipe SonarSource avait publié tous les éléments pour créer notre propre plugin VB.NET sans trop d’efforts. Un bon travail de copier-coller et le tour est joué.

 

Résultat (GitHub)

J’ai placé les sources dans GitHub dans un « fork » du repository de SonarSource que vous trouverez à l’emplacement suivant. J’hésite encore à faire une pull request pour leur proposer de le rendre gratuit pour tous.

https://github.com/karoldeland/sonar-csharp/commit/a1d748832f6fba1a940288450c436a50f63e1088

 

Pour arriver à compiler le plugin VB.NET, juste à suivre les instructions pour le plugin C#. Bonne chance avec Maven ! 🙂

Suis-je seul à trouver ce hack super cool? 🙂

Petits trucs…

J’ai aussi pu intégrer mon nouveau plugin dans TFS 2017 à l’aide des tâches fournies dans le « marketplace ». Toutefois, comme l’exécution des tests unitaires pour tous mes projets étaient conservés dans un fichier unique (C# et VB.NET combinés), on doit faire l’importation du fichier trx par un seul des deux plugins .NET. Pour la couverture de code, on peut importer le même fichier .coveragexml par les deux plugins et tout fonctionne correctement.

Développeur T-shaped

Lors de cette première journée du DevOps Enterprise Summit 2017, à plusieurs reprises dans différentes sessions, le concept de « T-shaped developer » a été cité.

Ce que les entreprises cherchent aujourd’hui ce sont des candidats qui sont à la fois pointus dans un domaine particulier et qui ont, en complément, des connaissances générales dans domaines connexes. Un développeur doit pouvoir œuvrer en marge du code, il doit faire preuve de polyvalence: écrire des tests automatisés, monter des scripts de déploiement, comprendre les outils intégration et livraison continue, avoir une culture…

Les développeurs T-Shaped sont prisés des équipes DevOps où leur polyvalence est mise à profit. Ils transcendent les silos que l’on rencontre habituellement dans les équipes classiques où les membres tiennent des rôles précis dont ils ne sortent pas ou peu: analystes fonctionnels, développeurs, testeurs, opérateurs etc.

Dans « T-Shaped developer », la barre verticale du ‘ T ‘ fait référence à la profondeur de l’expertise tandis que la barre horizontale du ‘ T ‘ fait référence à l’étendue des connaissances générales.

t-shaped_dev

On parle parfois aussi de développeur « Full Stack ». L’idée de base est similaire à ce qui a trait à l’étendue des compétences. Cependant les lectures que j’ai faites à ce propos me laissent à penser qu’on parle plus de la capacité à pouvoir développer dans différents contextes comme les interfaces graphiques (web ou app), les services, les API web, l’accès aux données, la logique d’affaire etc.

Voici quelques lectures complémentaires sur le sujet: