Workshop AWS : Construire une plateforme vidéo Serverless

Temps de lecture : 6 minutes

Ils partirent 40 au petit matin, et revinrent 40 à la nuit tombée. Cela pourrait être le pitch d’un film particulièrement mauvais, mais c’est en réalité celui du workshop AWS qui a eu lieu le 14 février dernier à l’espace saint Martin à Paris lors de la ServerlessConf Paris. Et comme vous l’avez deviné, nous n’avons perdu personne en route.

Parce que cette épopée particulièrement épique mérite d’être contée, permettez moi de revenir sur la journée, en vous donnant quelques détails sur les différentes difficultés auxquelles vous pourriez être confrontés si vous décidiez de tenter de faire le workshop chez vous.

Tout commença par un git clone.

L’objectif était ambitieux: tout le monde devait arriver à faire une plateforme de vidéo avec AWS Lambda, API Gateway, S3, Elastic Transcoder, et Auth0 et Firebase en services externes.

1 – Un pipeline de transcodage basique

La première épreuve consistait à mettre en place un pipeline de transcodage: une vidéo qui atterrit dans un bucket S3 et PAF ! Le service de transcodage la prend, la transforme et recrache le résultat dans un autre bucket S3, comme autant de petits chatons venant au monde.

By Salz der Erde – Own work, Public Domain

Certains, selon leur préférence, partirent aux Etats-Unis d’Amérique (us-east-2), d’autres en Irlande (eu-west-1). Le second groupe essuya davantage de difficultés en raison du sujet qui était prévu pour us-east-2. Mais c’est dans l’adversité que naissent les héros.

La leçon 1 présentât assez peu de difficultés, chacun chevauchant à vive allure à travers les instructions du PDF, les irlandais prenant bien soin de mettre leur région en lieu et place de celle du document pour que cela fonctionne. Quelques personnes furent stoppées dans leur élan par une version de nodejs trop ancienne, d’autres avaient une arborescence de fichiers trop longue pour winzip. Trois personnes eurent une mésaventure que nul n’aurait pu prévoir: la version de winzip qu’ils avaient sur leur poste décidait unilatéralement de ne pas packager certains fichiers, entraînant un comportement tout à fait surprenant une fois les lambda déployées. Au final, tout le monde pu déclencher le transcodage de leur vidéo et passer à l’étape suivante.

2 – Authentification avec un service externe

La seconde épreuve consistait à créer une application permettant de s’authentifier avec Auth0. La encore, peu de difficultés, à l’exception de ceux qui avaient oublié certains paramètres comme mettre “localhost” dans la configuration CORS, qui s’étaient trompés de port, ou encore qui n’avaient pas modifié le fichier de configuration avant de lancer le serveur.

3 – Profil utilisateur, et interactions avec Auth0 (custom authorizer sur API Gateway)

La troisième épreuve s’annonça pour beaucoup d’une difficulté plus importante. Elle consistait à créer une fonction qui permettrait de récupérer le profil utilisateur depuis Auth0 et l’afficher via une API à notre site web. Se faisant, elle pose les bases de l’API qui nous permettra de mettre en ligne nos vidéos, à condition que l’utilisateur soit authentifié.

De multiples problèmes nous furent remontés, dûs pour la plupart à la manipulation de la console AWS et au non respect des instructions du PDF. Certains mirent des tags à leur fonction pensant y insérer des variables d’environnement, d’autres n’activèrent pas CORS, recevant des erreurs 401, d’autres oublièrent la configuration Javascript et enfin certains trop pressés ne donnèrent pas les droits à leur fonction de s’exécuter. L’occasion pour beaucoup de découvrir le débogueur de leur navigateur pour traquer les requêtes, et la fonction CloudWatch d’Amazon afin d’y déchiffrer le cri de désespoir de leur API encore naissante, hurlant à la mort à chaque appel infructueux parce qu’il lui manquait un paramètre, ou encore pour y constater le silence de celle-ci alors que pourtant elle était sollicitée.

L’occasion pour nous de souffler tel maître Oogway une tautologie mystérieuse: “Ne pas avoir d’information, est déjà une information” à nos élèves. Ci-contre, un exemple de réaction d’un panda à qui maître Oogway a énoncé une tautologie mystérieuse sur le kung-fu et la force qu’il a en lui pour vaincre Tai Lung.

4 – Upload de vidéo

La quatrième étape commença alors pour les plus en avance de nos aventuriers, elle consistait à créer un utilisateur dans AWS ayant les droits d’uploader des fichiers afin de se servir de celui-ci pour générer des URLs signées pour l’upload.

Une question fondamentale revint plusieurs fois à nos oreilles: “pourquoi construire un tel processus où on fait un appel d’API pour récupérer une URL signée pour uploader un fichier alors qu’on pourrait envoyer la vidéo directement à l’API avec un contenu multipart ?”. La réponse demande à se plonger dans le mécanisme d’API Gateway. Oui, nous pourrions envoyer la vidéo dans un stream ou comme un contenu multipart à l’API qui ferait juste passe-plat à S3, mais cela ne serait pas efficace; d’abord parce que nous serions obligés payer de la mémoire lambda pour charger le fichier, ensuite, parce que la vidéo est potentiellement énorme et qu’on a envie que le temps d’attente lors de l’upload soit côté client et non backend (une lambda est limitée à 5 minute). L’astuce est justement que notre UI Javascript peut directement pousser le fichier potentiellement énorme dans S3 à son rythme et laisser le traitement se déclencher en asynchrone avec le mécanisme de notification que nous avons mis en place à l’étape 1.

Les doutes levés, ceux qui étaient partis en Irlande tombèrent dans un traquenard du sujet que nous avions anticipé lorsque nous avions testé avec amour le workshop qui avait été préparé par CloudGuru: l’URL décrite dans le PDF est l’URL pour la virginie du nord, et la région n’est pas visible dedans. En effet, si vous indiquez https://s3.amazonaws.com/BUCKET_NAME pour aller taper un bucket BUCKET_NAME, implicitement il s’agit de us-east-2, il faut alors penser à insérer la région eu-west-1 dans l’URL, alors que depuis le début on n’avait fait que remplacer us-east-2 en eu-west-1. Plus de détails sont disponibles dans la documentation officielle.

Et puis, soudain, quelqu’un eu un problème inédit. Un élu, frappé par la malchance divine du ciel, chez qui l’API continuait de répondre des erreurs 401 comme si la configuration CORS était invalide, mais chez qui pourtant nous passâmes successivement à la recherche d’indices, émettant des hypothèses, mais qui s’avérèrent toutes infructueuses. Ce n’est que bien plus tard dans la journée que l’un d’entre nous reprenant derechef chaque étape de son API, identifia que le bougre avait écrit “authorize” au lieu de “authorization” dans le nom du header envoyé par l’API, entraînant (à tort) une erreur CORS. Subtil mais fatal.

5 – Through the fire and the base (Firebase integration)

La dernière étape consistait à compléter notre pipeline en permettant à l’utilisateur de voir sa vidéo apparaître quand le transcodage était terminé. Ce traitement étant asynchrone, l’état de transcodage de la vidéo est alors stocké dans Firebase par les lambdas AWS, et récupéré de manière asynchrone par l’UI via un mécanisme de websocket branché directement sur Firebase.

Les principales difficultés se sont séparées en trois catégories:

  • Les informations sur la vidéo n’arrive pas dans Firebase
  • L’information que le transcodage et terminé n’est pas poussé dans Firebase
  • L’UI ne récupère pas d’information de Firebase

Ces trois problèmes seront résolus facilement en reprenant avec les élèves chaque étape, à savoir :

  • Pour le premier, vérifier la configuration de la lambda qui se déclenche au moment où la vidéo arrive dans le bucket initial
  • Pour le second, vérifier si la lambda de notification de Firebase est bien branchée sur le bucket de destination du transcodage (avec les bon paramètres)
  • Pour le dernier, vérifier qu’on a correctement copié/collé le code Javascript donné par l’interface de Firebase dans l’UI contenant les paramètres de connexion pour la websocket.

A la fin de la journée, tout le monde (à quelques exceptions près) est reparti avec sa plate-forme de vidéo sous le bras (ou plutôt dans le cloud). On raconte que ce soir-là, YouTube a tremblé.

Commentaires :

A lire également sur le sujet :