Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

J'aimerais vous parler d'infra, de paradigmes de déploiement et de gestion logicielle (Vous trouverez la présentation sur ce lien ; sur mobile c'est pas parfait mais il faut juste swipe pour changer de slide)
Je vais essayer de parler des nouvelles pratiques dans la gestion des déploiements. Disclaimer : - Cette présentation n'est pas exhaustive - Je vais faire des approximations pour simplifier - Il y a certainement des personnes dans cette salle qui s'y connaissent mieux que moi C'est un sujet que je trouve assez sexy, je pourrais déjà faire une conférence d'une heure et demie mais je vais vous épargner ça. On va faire court, si vous avez des question n'hésitez pas à m'interrompre, et si vous voulez en parler c'est quand vous voulez, où vous voulez.
Parlons un peu d'histoire de l'informatique
« Merde ! Ma prod est cassée ! » Qu'est-ce que je fais ? - On évalue le périmètre de la panne, ce qui casse - On détermine les conditions dans lesquelles ça arrive - On évalue les risques possibles - On détermine le coût pour corriger : temps de debug, nouveau déploiement… Enfin, on décide de l'action à prendre et quand.
Différents scénarios: Que se passe-t-il si elle est cassée… + Au déploiement: - facile, on tente de rollback hein ? Oui, mais si on avait changé de DB en même temps ? + 4j : - Est-ce que c'est vraiment lié au dernier déploiement ? - Une panne lente ? - Un changement stateful ? + Au rollback : - Un truc mal rollback ? - Un état persistant ? + It works on my machine: - Quoi ? C'est pas ISO prod ?? + It doesn't work only on my machine: - Quoi ? C'est vraiment pas ISO prod ??
Différents scénarios: Que se passe-t-il si elle est cassée… + Au déploiement: - facile, on tente de rollback hein ? Oui, mais si on avait changé de DB en même temps ? + 4j : - Est-ce que c'est vraiment lié au dernier déploiement ? - Une panne lente ? - Un changement stateful ? + Au rollback : - Un truc mal rollback ? - Un état persistant ? + It works on my machine: - Quoi ? C'est pas ISO prod ?? + It doesn't work only on my machine: - Quoi ? C'est vraiment pas ISO prod ??
Différents scénarios: Que se passe-t-il si elle est cassée… + Au déploiement: - facile, on tente de rollback hein ? Oui, mais si on avait changé de DB en même temps ? + 4j : - Est-ce que c'est vraiment lié au dernier déploiement ? - Une panne lente ? - Un changement stateful ? + Au rollback : - Un truc mal rollback ? - Un état persistant ? + It works on my machine: - Quoi ? C'est pas ISO prod ?? + It doesn't work only on my machine: - Quoi ? C'est vraiment pas ISO prod ??
Différents scénarios: Que se passe-t-il si elle est cassée… + Au déploiement: - facile, on tente de rollback hein ? Oui, mais si on avait changé de DB en même temps ? + 4j : - Est-ce que c'est vraiment lié au dernier déploiement ? - Une panne lente ? - Un changement stateful ? + Au rollback : - Un truc mal rollback ? - Un état persistant ? + It works on my machine: - Quoi ? C'est pas ISO prod ?? + It doesn't work only on my machine: - Quoi ? C'est vraiment pas ISO prod ??
Différents scénarios: Que se passe-t-il si elle est cassée… + Au déploiement: - facile, on tente de rollback hein ? Oui, mais si on avait changé de DB en même temps ? + 4j : - Est-ce que c'est vraiment lié au dernier déploiement ? - Une panne lente ? - Un changement stateful ? + Au rollback : - Un truc mal rollback ? - Un état persistant ? + It works on my machine: - Quoi ? C'est pas ISO prod ?? + It doesn't work only on my machine: - Quoi ? C'est vraiment pas ISO prod ??
Electronic Numerical Integrator And Computer - 1er ordi Turing complete C'est quoi l'infra ? Infrastructure : - structure -> relation entre les éléments d'un système - infra -> « sous », ce qui supporte infrastructure -> tout ce qui supporte un système (ex: -> fondations d'un bâtiment) Ici : infrastructure = bâtiment, l'ENIAC littéralement une pièce — La problématique : ma prod est en panne. On se déplace physiquement, on vérifie les branchements, on documente les nouveaux branchements, on vérifie les entrées-sorties (périphériques) sur cartes perforées, on vérifie la configuration…
Electronic Numerical Integrator And Computer - 1er ordi Turing complete C'est quoi l'infra ? Infrastructure : - structure -> relation entre les éléments d'un système - infra -> « sous », ce qui supporte infrastructure -> tout ce qui supporte un système (ex: -> fondations d'un bâtiment) Ici : infrastructure = bâtiment, l'ENIAC littéralement une pièce — La problématique : ma prod est en panne. On se déplace physiquement, on vérifie les branchements, on documente les nouveaux branchements, on vérifie les entrées-sorties (périphériques) sur cartes perforées, on vérifie la configuration…
On premise: on est responsable de notre serveur, de notre baie, de notre emplacement rack En collocation, on n'est plus responsable du bâtiment on loue un emplacement rack, Selon la panne, l'accès en terminal suffit ; si c'est matériel on a toujours besoin d'un accès physique pour vérifier.
Cas d'usage : On veut une marketplace : on la déploie sur serveur dédié Elle tombe en panne : il faut prendre ses petites jambes, aller regarder ce qu'il se passe : en attendant le service est indispo. Solution ? On l'installe sur plusieurs serveurs Ça tombe en panne : on enquête, mais en attendant l'utilisateur peut toujours accéder à un autre serveur. On dit que notre marketplace tourne sur un « cluster » de serveurs.
Cas d'usage : On veut une marketplace : on la déploie sur serveur dédié Elle tombe en panne : il faut prendre ses petites jambes, aller regarder ce qu'il se passe : en attendant le service est indispo. Solution ? On l'installe sur plusieurs serveurs Ça tombe en panne : on enquête, mais en attendant l'utilisateur peut toujours accéder à un autre serveur. On dit que notre marketplace tourne sur un « cluster » de serveurs.
Cas d'usage : On veut une marketplace : on la déploie sur serveur dédié Elle tombe en panne : il faut prendre ses petites jambes, aller regarder ce qu'il se passe : en attendant le service est indispo. Solution ? On l'installe sur plusieurs serveurs Ça tombe en panne : on enquête, mais en attendant l'utilisateur peut toujours accéder à un autre serveur. On dit que notre marketplace tourne sur un « cluster » de serveurs.
Cas d'usage : On veut une marketplace : on la déploie sur serveur dédié Elle tombe en panne : il faut prendre ses petites jambes, aller regarder ce qu'il se passe : en attendant le service est indispo. Solution ? On l'installe sur plusieurs serveurs Ça tombe en panne : on enquête, mais en attendant l'utilisateur peut toujours accéder à un autre serveur. On dit que notre marketplace tourne sur un « cluster » de serveurs.
Et il a raison ! C'est pratique le cluster, mais pour éviter les pannes et pas mettre tous les œufs dans le même panier il faut déployer dans de régions en même temps (coupure courant, internet…) On prend soin de nos gambettes, on veut pas courir partout pour installer ni pour réparer On loue l'infra, on s'occupe du logiciel : Infra-as-a-service (le hardware est fournit, tu gères l'OS)
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
La même chose, sauf que les serveurs ne sont pas _dédiés_ à ma marketplace, à la place ils hébergent plusieurs *machines virtuelles* Parmi ces VM -> ma marketplace Utilisateur accède directement ma marketplace via la VM -> même chose qu'avant SAUF QUE Si VM 1 en panne, pas besoin d'accéder au datacenter, on peut la recréer, la réinitialiser ou la redéployer ailleurs sans avoir besoin d'aller sur place On appelle aussi ça un VPS —— Pourquoi je parle pas de SSH sur serveur physique ? Parce qu'on parle d'infra (db, charges de travail, config réseau), pas juste du système – Oui mais et moi mon serveur dédié jamais eu besoin d'aller sur place -> le hardware a jamais lâché et eu besoin ticket ? – Oui mais ça arrive jamais -> Si ça lâche une fois en 10 ans, il suffit d'avoir 10 serveurs pour qu'il y en ait 1 qui lâche par an, 100 serveurs et quasiment une panne tous les mois On peut citer VMware, VirtualBox, Xen, Proxmox…
Et si serveur physique en carafe ? Eh bien pas de downtime puisqu'on a toujours le quorum Ça déploie un nouveau serveur — Sur la gestion de projet, concrètement ça veut dire qu'on gère des machines entières, qu'il faut maintenir, sécuriser, tester… et ça tourne pas sur un laptop de dev Ça veut dire déployer un OS entier… Mais on peut trouver encore mieux
Et si serveur physique en carafe ? Eh bien pas de downtime puisqu'on a toujours le quorum Ça déploie un nouveau serveur — Sur la gestion de projet, concrètement ça veut dire qu'on gère des machines entières, qu'il faut maintenir, sécuriser, tester… et ça tourne pas sur un laptop de dev Ça veut dire déployer un OS entier… Mais on peut trouver encore mieux
On reprend nos VM Il y a une notion de sobriété : au début on a du matériel dédié pour faire tourner mes serveurs de marketplace, alors je fais tourner mes serveurs _virtuels_ sur des machines physiques Mais ça veut dire faire tourner des systèmes d'exploitation plusieurs fois, devoir se balader avec un disque dur virtuel de centaines de GiO à upload pour déployer, etc. Comme si, pour aller au boulot tous les jours, on prenait toutes & tous notre bagnole, qu'on s'est dit que c'était pas pratique quand sa voiture tombe en panne alors on a un abonnement à une flotte de voitures en libre service : si elle tombe en panne, c'est le prestataire qui la répare, je me concentre uniquement sur ce qu'elle transporte. Sauf qu'il y aurait encore plus économique en mutualisant encore plus de ressources : au lieu de payer des voitures en libre-service, je peux me contenter de payer un abonnement de bus et de faire mes déplacements en bus. Au lieu d'héberger des applications dans des systèmes d'exploitation ou dans des machines virtuelles, on peut mettre nos applications dans des conteneurs plus légers et plus faciles à transporter
Container-as-a-service : on fournit le hardware et l'OS, tu gères le conteneur Du point de vue de l'appli, qu'elle soit sur un serveur dédié, sur une machine virtuelle, dans un conteneur… Rien ne change. Les 3 seules différences : - les ressources allouées et les ressources consommées - le niveau d'isolation (sécu) - le cycle de vie (quand ça démarre, ça met à jour…) et qui s'occupe de quoi
À partir 2012 avec le nouveau standard O.C.I apporté par Docker, on a commencé à voir deux paradigmes arriver avec les conteneurs : le Hub Docker (un dépôt avec plein d'images de conteneurs desquelles on peut dériver) et la syntaxe Dockerfile (un fichier qui décrit l'état désiré de l'image finale). J'y reviens après au sujet du déclaratif
C'est simplifié (dépend des produits) mais le type définit quel est le niveau qu'on commence à administrer : « on-prem, j'administre le réseau », « SaaS, j'*administre* l'appli mais c'est eux qui sont admins des données dessus » etc. - On Prem : j'achète et conduis ma voiture - IaaS - infra : je loue et conduis une voiture - CaaS - Container : j'ai un abonnement illimité de transport pour me déplacer - PaaS - Platform : je commande un taxi uniquement quand j'en ai besoin, je paie à l'usage - SaaS - Software : je délègue (je fais livrer) Si ça pète on-premise, je me déplace, si l'OS pète j'investigue en console, si le conteneur pète je debug le code, si la plateforme pète je vérivie la config de l'app, si le SaaS pète j'appelle le support En vrai : - il y a quand même un serveur, « serverless » est un terme marketing - le serveur est faillible, il y a des pannes, c'est juste un tiers qui s'en occupe - c'est quand même coûteux de déléguer - il y a des contraintes d'archi & avec le serverless ou SaaS on n'est pas toujours libre des cycles de release - le serveur est toujours déployé avant, il est juste pas dédié qu'à notre marketplace
C'est simplifié (dépend des produits) mais le type définit quel est le niveau qu'on commence à administrer : « on-prem, j'administre le réseau », « SaaS, j'*administre* l'appli mais c'est eux qui sont admins des données dessus » etc. - On Prem : j'achète et conduis ma voiture - IaaS - infra : je loue et conduis une voiture - CaaS - Container : j'ai un abonnement illimité de transport pour me déplacer - PaaS - Platform : je commande un taxi uniquement quand j'en ai besoin, je paie à l'usage - SaaS - Software : je délègue (je fais livrer) Si ça pète on-premise, je me déplace, si l'OS pète j'investigue en console, si le conteneur pète je debug le code, si la plateforme pète je vérivie la config de l'app, si le SaaS pète j'appelle le support En vrai : - il y a quand même un serveur, « serverless » est un terme marketing - le serveur est faillible, il y a des pannes, c'est juste un tiers qui s'en occupe - c'est quand même coûteux de déléguer - il y a des contraintes d'archi & avec le serverless ou SaaS on n'est pas toujours libre des cycles de release - le serveur est toujours déployé avant, il est juste pas dédié qu'à notre marketplace
C'est simplifié (dépend des produits) mais le type définit quel est le niveau qu'on commence à administrer : « on-prem, j'administre le réseau », « SaaS, j'*administre* l'appli mais c'est eux qui sont admins des données dessus » etc. - On Prem : j'achète et conduis ma voiture - IaaS - infra : je loue et conduis une voiture - CaaS - Container : j'ai un abonnement illimité de transport pour me déplacer - PaaS - Platform : je commande un taxi uniquement quand j'en ai besoin, je paie à l'usage - SaaS - Software : je délègue (je fais livrer) Si ça pète on-premise, je me déplace, si l'OS pète j'investigue en console, si le conteneur pète je debug le code, si la plateforme pète je vérivie la config de l'app, si le SaaS pète j'appelle le support En vrai : - il y a quand même un serveur, « serverless » est un terme marketing - le serveur est faillible, il y a des pannes, c'est juste un tiers qui s'en occupe - c'est quand même coûteux de déléguer - il y a des contraintes d'archi & avec le serverless ou SaaS on n'est pas toujours libre des cycles de release - le serveur est toujours déployé avant, il est juste pas dédié qu'à notre marketplace
C'est simplifié (dépend des produits) mais le type définit quel est le niveau qu'on commence à administrer : « on-prem, j'administre le réseau », « SaaS, j'*administre* l'appli mais c'est eux qui sont admins des données dessus » etc. - On Prem : j'achète et conduis ma voiture - IaaS - infra : je loue et conduis une voiture - CaaS - Container : j'ai un abonnement illimité de transport pour me déplacer - PaaS - Platform : je commande un taxi uniquement quand j'en ai besoin, je paie à l'usage - SaaS - Software : je délègue (je fais livrer) Si ça pète on-premise, je me déplace, si l'OS pète j'investigue en console, si le conteneur pète je debug le code, si la plateforme pète je vérivie la config de l'app, si le SaaS pète j'appelle le support En vrai : - il y a quand même un serveur, « serverless » est un terme marketing - le serveur est faillible, il y a des pannes, c'est juste un tiers qui s'en occupe - c'est quand même coûteux de déléguer - il y a des contraintes d'archi & avec le serverless ou SaaS on n'est pas toujours libre des cycles de release - le serveur est toujours déployé avant, il est juste pas dédié qu'à notre marketplace
C'est simplifié (dépend des produits) mais le type définit quel est le niveau qu'on commence à administrer : « on-prem, j'administre le réseau », « SaaS, j'*administre* l'appli mais c'est eux qui sont admins des données dessus » etc. - On Prem : j'achète et conduis ma voiture - IaaS - infra : je loue et conduis une voiture - CaaS - Container : j'ai un abonnement illimité de transport pour me déplacer - PaaS - Platform : je commande un taxi uniquement quand j'en ai besoin, je paie à l'usage - SaaS - Software : je délègue (je fais livrer) Si ça pète on-premise, je me déplace, si l'OS pète j'investigue en console, si le conteneur pète je debug le code, si la plateforme pète je vérivie la config de l'app, si le SaaS pète j'appelle le support En vrai : - il y a quand même un serveur, « serverless » est un terme marketing - le serveur est faillible, il y a des pannes, c'est juste un tiers qui s'en occupe - c'est quand même coûteux de déléguer - il y a des contraintes d'archi & avec le serverless ou SaaS on n'est pas toujours libre des cycles de release - le serveur est toujours déployé avant, il est juste pas dédié qu'à notre marketplace
Available & reliable: haute disponibilité dans un cluster
Available & reliable: haute disponibilité dans un cluster
Available & reliable: haute disponibilité dans un cluster
Available & reliable: haute disponibilité dans un cluster
Available & reliable: haute disponibilité dans un cluster
Un paradigme est — en épistémologie et dans les sciences humaines et sociales — une représentation du monde, une manière de voir les choses, un modèle cohérent du monde qui repose sur un fondement défini (matrice disciplinaire, modèle théorique, courant de pensée). Rappel que la problématique : ma prod est en panne, je sais pas si c'est infra ou software, je sais pas quoi faire, je veux être autonome En impératif, il faut vérifier couche par couche si tout fonctionne bien du software au hardware, sans avoir toutes les permissions à tous les niveaux (sinon on est sysadmin) On _PEUT_ avoir connaissance des processus et de la recette de cuisine, mais difficilement du résultat exact et de la manière dont les étapes ont été suivies.
Un paradigme est — en épistémologie et dans les sciences humaines et sociales — une représentation du monde, une manière de voir les choses, un modèle cohérent du monde qui repose sur un fondement défini (matrice disciplinaire, modèle théorique, courant de pensée). Rappel que la problématique : ma prod est en panne, je sais pas si c'est infra ou software, je sais pas quoi faire, je veux être autonome En impératif, il faut vérifier couche par couche si tout fonctionne bien du software au hardware, sans avoir toutes les permissions à tous les niveaux (sinon on est sysadmin) On _PEUT_ avoir connaissance des processus et de la recette de cuisine, mais difficilement du résultat exact et de la manière dont les étapes ont été suivies.
Alex nous dit… Non j'ai menti, c'est moi :D
Alex nous dit… Non j'ai menti, c'est moi :D
On parle d'infra, on parle de déclaratif, mais en fait on connais toutes et tous des langages déclaratifs Pour autant, tous les langages déclaratifs ne sont pas des langages de programmation.
On parle d'infra, on parle de déclaratif, mais en fait on connais toutes et tous des langages déclaratifs Pour autant, tous les langages déclaratifs ne sont pas des langages de programmation.
- On déclare : je veux construire un conteneur à partir de tel déclaration (Dockerfile) - Je donne l'ordre : je veux que mon conteneur tourne - Docker dit : je réalise toutes ces étapes
- On déclare : je veux construire un conteneur à partir de tel déclaration (Dockerfile) - Je donne l'ordre : je veux que mon conteneur tourne - Docker dit : je réalise toutes ces étapes
- Si on relance plusieurs fois `docker build`, ça existe déjà et ça fait rien de plus : on parle d'« idempotence » (ex: cliquer sur un bouton pour valider le panier) Il faut comprendre que derrière toute étape déclarative se cachent des opérations impératives. C'est une question de responsabilités.
- Si on relance plusieurs fois `docker build`, ça existe déjà et ça fait rien de plus : on parle d'« idempotence » (ex: cliquer sur un bouton pour valider le panier) Il faut comprendre que derrière toute étape déclarative se cachent des opérations impératives. C'est une question de responsabilités.
- Si on relance plusieurs fois `docker build`, ça existe déjà et ça fait rien de plus : on parle d'« idempotence » (ex: cliquer sur un bouton pour valider le panier) Il faut comprendre que derrière toute étape déclarative se cachent des opérations impératives. C'est une question de responsabilités.
Exemple avec NPM: - `npm install [pkg]` -> impératif - le `package.json` déclare la dépendance - `npm install` installe à partir de la déclaration Oui mais et les màjs automatiques ?
Exemple avec NPM: - `npm install [pkg]` -> impératif - le `package.json` déclare la dépendance - `npm install` installe à partir de la déclaration Oui mais et les màjs automatiques ?
Exemple avec NPM: - `npm install [pkg]` -> impératif - le `package.json` déclare la dépendance - `npm install` installe à partir de la déclaration Oui mais et les màjs automatiques ?
Exemple avec NPM: - `npm install [pkg]` -> impératif - le `package.json` déclare la dépendance - `npm install` installe à partir de la déclaration Oui mais et les màjs automatiques ?
On parle de reproductibilité Les mêmes causes produisent les mêmes effets
Les mêmes causes produisent les mêmes effets
`npm install` n'est pas strictement reproductible : il va chercher les updates mineures et _peut_ modifier le lockfile Pour des install strictement reproductibles à partir du `package.json` & lock : `npm ci` On parle aussi de « déterminisme » — Et pour revenir aux conteneurs :
`npm install` n'est pas strictement reproductible : il va chercher les updates mineures et _peut_ modifier le lockfile Pour des install strictement reproductibles à partir du `package.json` & lock : `npm ci` On parle aussi de « déterminisme » — Et pour revenir aux conteneurs :
`npm install` n'est pas strictement reproductible : il va chercher les updates mineures et _peut_ modifier le lockfile Pour des install strictement reproductibles à partir du `package.json` & lock : `npm ci` On parle aussi de « déterminisme » — Et pour revenir aux conteneurs :
`npm install` n'est pas strictement reproductible : il va chercher les updates mineures et _peut_ modifier le lockfile Pour des install strictement reproductibles à partir du `package.json` & lock : `npm ci` On parle aussi de « déterminisme » — Et pour revenir aux conteneurs :
`npm install` n'est pas strictement reproductible : il va chercher les updates mineures et _peut_ modifier le lockfile Pour des install strictement reproductibles à partir du `package.json` & lock : `npm ci` On parle aussi de « déterminisme » — Et pour revenir aux conteneurs :
Et pour revenir aux conteneurs : Est-ce qu'on a des outils déclaratifs au lieu de Docker run ? Docker compose… Kubernetes permet d'orchestrer des conteneurs (et d'autres ressources) sur un cluster
Et pour revenir aux conteneurs : Est-ce qu'on a des outils déclaratifs au lieu de Docker run ? Docker compose… Kubernetes permet d'orchestrer des conteneurs (et d'autres ressources) sur un cluster
Et pour revenir aux conteneurs : Est-ce qu'on a des outils déclaratifs au lieu de Docker run ? Docker compose… Kubernetes permet d'orchestrer des conteneurs (et d'autres ressources) sur un cluster
Et pour revenir aux conteneurs : Est-ce qu'on a des outils déclaratifs au lieu de Docker run ? Docker compose… Kubernetes permet d'orchestrer des conteneurs (et d'autres ressources) sur un cluster
Pour revenir à notre infra…
- Ça se crée à l'apply, c'est destroyed quand c'est supprimé - Terraform traduit en appels API - Une référence dans la gestion d'infra — Il faut faire attention (ex.: Terraform exécuté par Claude qui wipe le Cloud, les DB, les backups de DB) Analogie : Le chef cuistot Terraform interprète la déclaration et fait sa tambouille lui-même avant de servir le plat
- Ça se crée à l'apply, c'est destroyed quand c'est supprimé - Terraform traduit en appels API - Une référence dans la gestion d'infra — Il faut faire attention (ex.: Terraform exécuté par Claude qui wipe le Cloud, les DB, les backups de DB) Analogie : Le chef cuistot Terraform interprète la déclaration et fait sa tambouille lui-même avant de servir le plat
- Ça se crée à l'apply, c'est destroyed quand c'est supprimé - Terraform traduit en appels API - Une référence dans la gestion d'infra — Il faut faire attention (ex.: Terraform exécuté par Claude qui wipe le Cloud, les DB, les backups de DB) Analogie : Le chef cuistot Terraform interprète la déclaration et fait sa tambouille lui-même avant de servir le plat
- Ça se crée à l'apply, c'est destroyed quand c'est supprimé - Terraform traduit en appels API - Une référence dans la gestion d'infra — Il faut faire attention (ex.: Terraform exécuté par Claude qui wipe le Cloud, les DB, les backups de DB) Analogie : Le chef cuistot Terraform interprète la déclaration et fait sa tambouille lui-même avant de servir le plat
Monsieur Roger, dev, pas hyper intéressé par l'ops, peut quand même profiter du déclaratif Infra as code c'est du code : Une feature qui nécessite une nouvelle DB peut avoir les deux changements (infra/code) dans une même PR Plus besoin de faire de ticket infra : les changements peuvent être faits par les devs autonomes, ça va plus vite C'est possible de tester les changements infra de manière autonome avant même que ça parte en prod, en quelques lignes Mais y'a pas moyen que ça serve pour autre chose que l'infra ?
Je voulais parler d'outillage propre au développement
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
Je voulais parler d'outillage propre au développement : par projet, ça permet de garder un système propre et d'avoir des logiciels, versions de logiciels, … indépendants à chaque répertoire - Compiler depuis les sources : le binaire est construit à partir de fichiers qui déclarent du code - Les gestionnaires de packet propres aux langages (`./node_modules`) - Mise, qui permet d'utiliser de faire ce qu'on vient de dire mais pour tous les package managers sans les installer - Docker, en conteneurs - devenv, direnv, .envrc, qui permettent de définir un contexte en entrant dans un répertoire - Nix, qui est à la fois un langage de programmation (turing-complete), déclaratif, et fortement reproductible (toutes les entrées sont signées) En fait, Nix est même le plus grand package manager au monde, parmi les dépôts Github les plus actifs, et avec les batteries de tests les plus solides. Nix permet aussi de charger des logiciels de n'importe quel système en entrant dans un répertoire
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
- On veut éviter sillo *dev* / sysadmin - On veut que les devs contrôlent mieux l'env final - Dev plus iso prod possible = good + Originellement, dev -> cahier des charges -> ops => source d'erreur + Ensuite, environnements devs locaux + en + proches + Idéal : les devs gèrent les environnements et leurs specs eux-mêmes au plus proche du code Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
Que se passe-t-il quand on se rend compte que les spec machine ne suivent pas ? On refait potentiellement toute la boucle (c'est un cycle en v simplifié le schéma) Est-ce qu'on pourrait pas simplifier les intermédiaires ?
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
On reprend ce qu'on avait avant (métier qui parle aux leads qui discute avec les devs) — Et de l'autre côté, on a les ops qui _préparent_ l'infra — Pour que les devs puissent déployer des ressources eux-même — Qu'ils pourront tester — Ça permettra aux devs et aux leads de faire des revues d'infra sur des PR par exemple — Et à la fin n'importe qui peut exécuter des tests end-to-end, y compris sur des feature branches — Le fait de rapprocher l'infra du dev, le dev de l'infra, c'est ce qu'on peut appeler du… DEVOPS — On pourrait aussi parler de gestion de risque, de plan de continuité et de reprise d'activité, de gestion de cycles de déploiement mais ça ferait l'objet d'une autre présentation.
C'est Robin qui en parle très bien et ça pourrait faire l'objet d'une présentation à part. Ce sont les mesures de performance d'un projet et de l'intérêt d'avoir un bon cycle de vie de release. On y travaille activement avec l'équipe PIC.
Ah, et pour boucler la boucle, cette présentation est intégralement générée via un langage de programmation déclaratif, Typst, que j'ai mentionné un peu plus haut :D