Subscribe
Share
Share
Embed
- (01:26) - Introduction et présentation de Covry
- (04:13) - Déploiement d'infrastructures et services sur Covry
- (07:55) - Facilité de déploiement d'environnements éphémères avec Covery
- (14:13) - Différences de maturité des clients dans l'adoption de Covery
- (17:15) - Covery prévoit une plateforme open source pour les DevOps
- (20:00) - Créer un écosystème pour définir les applications clients
- (22:10) - L'IDP comble un manque mais nécessite du temps et de la standardisation
- (23:50) - Besoin de capitaliser sur des façons de faire différentes
- (25:39) - Gérer la stabilité et la charge sur différents cloud providers
- (28:15) - Possibilité de déployer Covery sur un cluster existant
- (31:05) - Hiérarchie et taille des équipes
- (32:06) - Performance et choix de Rust pour le control plane
- (33:04) - Python pour survivre, mais l'infra nécessite peu d'erreurs
- (36:16) - Developing DevOps Portals with Rust
- (39:23) - Présentation de Replaybytes et de la réplication des environnements
Creators & Guests
What is DevObs?
Dev'Obs
Le magazine et observatoire du DevOps
Bonjour à tous et à toutes, et bienvenue dans un nouveau numéro de DevOps.
Alors aujourd'hui, je suis accompagné de Pierre et on va parler de Covry.
Le but étant de vraiment comprendre un peu plus Covry, ce qu'ils font,
comment ils en sont arrivés là, et de voir un peu ce qu'ils vont faire dans le futur.
Je me présente, du coup je m'appelle Pierre Mavro, je suis CTO et Co-Founder de Covry.
Je suis passé par pas mal de boîtes, ça fait une vingtaine d'années que je travaille,
donc je suis passé par des boîtes qui c'est de la finance de marché donc Qlink
des boîtes un peu plus grosses qui c'est des OS et tout un tas de choses de
ce type là Red Hat ou encore de l'ADS chez Criteo,
et et donc j'ai on va dire un
début de carrière plutôt 6 admins puis DevOps puis SRE et puis SRE Dev enfin
plus Dev que du coup système aujourd'hui donc si vous avez notre bio vous saurez
qu'on s'est rencontré justement donc chez Criteo t'es pas dans exactement la
même équipe mais on a travaillé ensemble et donc depuis Criteo,
toi justement t'es parti sur Kovri, est-ce que tu peux un peu présenter ce que
vous faites chez Kovri justement ?
Du coup Kovri on est une internal développeur plateforme,
donc en gros ce qu'on va permettre, notre but c'est de vraiment rendre les devs
autonomes sans qu'ils aient forcément besoin d'avoir des notions d'infra,
et c'est de permettre également aux DevOps de pouvoir tout contrôler sans sans
exposer la complexité d'infra au dev.
Donc, on peut voir ça comme un mode self-service, en fait, pour les devs.
En termes d'usage et techniquement ensuite, comment ça se représente ?
Parce que le terme de plateforme interne, il y en a vraiment beaucoup.
Alors, en plus, si on rajoute à ça les passes externes qu'on peut connaître,
là, c'est quoi ? Je pousse mon code un peu à la Heroku.
C'est quoi exactement, vous, ce que vous proposez ?
De mettre de main, on prend vos services. Peut-être qu'il y en a plusieurs,
d'ailleurs, je ne sais pas.
Alors nous, ce qu'on demande, c'est un Dockerfile et un repo.
Donc on fait le build. Ce n'est pas obligatoire, mais on peut le faire.
Une fois que l'image est créée, on va le pousser sur un repo.
De ce repo-là, ensuite, on va le déployer.
Alors là, c'est vraiment la version grosse maille, mais ce qu'il faut comprendre,
c'est qu'à la base, nous, ce qu'on fait, c'est de l'infra.
C'est-à-dire qu'on va déployer une infrastructure state-of-the-art sur le compte cloud de nos clients.
Comme ça, c'est l'infrastructure des customers.
Nous, on a un contrôle plain de notre côté qui permet justement de lancer tous
ces déploiements à distance.
Donc, au travers soit d'une interface, donc pour les devs une console c'est
très pratique, soit une CLI, soit du Terraform, vous allez pouvoir en fait contrôler
tout ce qui se passe sur Kovei.
Donc l'idée c'est de pouvoir déployer des bases de données, des applications,
en fait tout ce dont un développeur va avoir besoin pour tout simplement développer
des fonctionnalités sans vraiment se prendre la tête.
Que ce soit très, très simple. Il y a beaucoup de complexités qui sont masquées.
Et donc, justement, pour un développeur, donc là, tu as dit que c'était un repo et un Dockerfile.
Si jamais je veux déclarer l'accès à une base de données, des choses comme ça,
comment ça va se passer, justement ? Est-ce que j'ai besoin de demander à un
DevOps qui va cliquer dans l'interface que je dois le faire moi-même ?
Est-ce que je peux directement l'annoncer dans un paramètre quelconque ?
Oui. Alors, on fournit quelques primitives de base, quelques services.
Donc, on a quatre bases de données aujourd'hui, donc MySQL, Postgre,
DocumentDB, Redis et ça couvre généralement la plupart des besoins,
et donc l'idée c'est que tu vas créer un environnement donc un environnement
ça va être production, staging, ce que tu veux et tu vas créer tous tes services
dedans donc typiquement j'ai
un backend, j'ai un frontend, on va faire simple et une base de données,
tu crées ces trois services là donc la base de données comme j'ai dit on la
fournit en primitive donc soit en mode conteneur soit en mode manager et c'est
un simple clic sur l'interface et en quelques secondes,
tu as ton conteneur de base de données.
Et en fait, on vient automatiquement injecter tout ce qui est environment variable
au sein de l'environnement, ce qui fait que toutes les applications que tu vas
utiliser derrière, tu vas pouvoir leur dire « Moi,
typiquement, mon application a besoin de DB host, DB login, DB password, etc.
» nous on a créé des built-in environment variables avec du coup ce que tu as
déployé donc typiquement là la base de données.
Et tu vas pouvoir faire un alias vers, donc typiquement si une application,
typiquement un WordPress ou ce genre de choses que tu vas déployer qui vont
demander expressément à ce qu'il y ait exactement tel nom de variable, etc.
Tu vas pouvoir la faire pointer en fait vers la built-in variable qu'on a créée,
donc c'est un simple alias.
Et si tu veux l'avantage de ça, c'est que les développeurs quand ils font une
nouvelle feature, ce genre de truc, ils n'ont pas envie de travailler à 50 sur
le même environnement de staging typiquement parce que ça devient vite le foutoir.
Ce qu'ils ont envie, c'est de pouvoir dupliquer les environnements.
Et donc ça, c'est une des grosses forces de Cori, c'est qu'on vient en un seul
clic te permettre de cloner un environnement complet.
Et donc, tous les aliases, etc., que tu as fait pointer vers les built-in,
en fait, nous, on te garde ça de l'autre côté, mais ça reste complètement isolé.
En fait, on vient refaire automatiquement tout le mapping, etc.
Même si tu as 50 applications dans ton environnement, ça va se faire tout seul.
La seule chose que tu auras à reparamétrer, c'est tout ce qui est vraiment unique,
typiquement si t'as mis un custom domaine ou si t'as mis des secrets t'as pas
forcément envie de partager les secrets ça c'est le genre de choses qu'il faudra
que tu remettes mais sinon c'est vraiment très très simple c'est copier-coller.
Donc là en fait on partirait tu pars de la prod tu la dérives en fait dans un
environnement de développement tu pars de la prod, tu dérives et ensuite tu
peux promouvoir justement t'as cette notion de promotion pour repartir sur la
prod quand j'ai fini mon développement,
alors ça, ça va être plutôt toi qui va te débrouiller avec ta CI.
Une fois que tu vas émerger dans main, typiquement, ça va te débrouiller sur
ta prod. Après, ça, c'est des stratégies qui sont propres à chacun,
enfin, chacune des boîtes, chacune des équipes, etc.
Là où nous, en fait, on va augmenter la productivité aussi, si tu veux,
c'est que le dev, il n'a pas besoin de se connecter sur Covery pour faire des trucs.
C'est-à-dire qu'il part de sa branche main, il veut faire une nouvelle feature,
il reste dans son git, en fait, donc dans ce qu'il connaît.
Il teste en local le salaire d'aller il pousse ça, il fait une nouvelle PR dans
la PR typiquement sur GitHub ça va lui dire tiens si tu veux créer un environnement
éphémère, t'as juste à répondre ça en commentaire et on va te le faire pour
toi et donc automatiquement ça va cloner,
ça va lui donner l'URL sur laquelle il va pouvoir accéder au back, au front,
jusqu'à ce dont il avait besoin dans cet environnement,
et donc il a accès automatiquement de manière vraiment très simple et quand
il va détruire sa branche parce qu'elle sera mergée ou elle sera tout simplement
détruite ça va lui supprimer automatiquement son environnement éphémère D'accord,
donc vous gérez les environnements éphémères directement et justement vous êtes
compatible avec GitHub tu le disais avec d'autres environnements ou pas ?
On a GitLab et Bitbucket aussi.
Ok, super. Bon, nous, on est sur Azure DevOps, mais bon, je comprends qu'on
ne va pas supporter Azure DevOps.
Ce n'est pas qu'on ne veut pas, c'est qu'on a quatre ans d'existence aujourd'hui
et qu'il faut choisir des combats.
Et pour l'instant, c'est cela, mais on se ferme la porte à rien du tout.
Quatre ans d'existence, historiquement, c'était ce que vous aviez vraiment voulu
faire ? Comment ça s'est passé, un peu, la genèse de Covery ?
Alors pas du tout en fait donc moi j'étais à Criteo encore et avec donc mes associés,
on avait un play au Techstar donc pour c'est un peu comme le YC le Techstar
pour être pris c'est vraiment compliqué et on a été pris en gros il y avait
1000 boîtes 10 boîtes sélectionnées on était dans l'hélice,
donc du coup ça faisait un moment de façon qu'on avait
des side projects qu'on essayait des trucs et tout lancé dans
un truc qui avait rien à voir c'était de l'analyse d'images
à des fins de marketing donc beaucoup d'IA beaucoup de
trucs comme ça et avec le Techstar ce qui est bien c'est que t'apprends vite
est-ce que ton idée ton produit va
réussir ou pas et on a rapidement vu que ça
n'irait pas donc on s'est reconcentré après sur ce qu'on connaissait qu'est-ce
qu'on fait depuis des années on passe de boîte en boîte c'est quoi notre but
en tant que DevOps etc c'est faire plaisir aux devs enfin en tout cas faire
plaisir leur donner matière à pouvoir utiliser l'infra travailler rapidement être efficace etc etc.
Et comme dans toutes les boîtes, on galère, c'est compliqué,
ça prend du temps et tu as l'impression de refaire beaucoup de choses à chaque fois.
Donc on s'est dit, en fait, le pain point pour nous, il est là,
on va changer du coup notre fusil d'épaule et on va se lancer là-dedans.
Et c'est comme ça que l'aventure, elle a commencé et on s'est dit,
en fait, il faut qu'on propose aux entreprises quelque chose qui leur permette de démarrer.
Et d'avoir quelque chose vraiment de souple qui plaît aux devs.
Parce qu'en tant que DevOps ou SRE, je pense que tu connais bien le problème.
Ce sont des gens qui sont très bons côté back, mais côté front,
malheureusement, ce n'est pas forcément les meilleurs pour faire des super UI et UX.
Donc, il faut un mix de tout. Et donc là, c'est vraiment ça aussi qu'on apporte.
C'est une facilité et une souplesse pour les DevOps pour pouvoir proposer à
leurs devs quelque chose de joli, utilisable et simple.
Et donc là aujourd'hui vos clients ça va être quoi comme type de client qui
vous rejoignent, vous en avez pas forcément le nombre exact mais c'est quoi
à peu près la proportion ouais bah aujourd'hui on a une centaine de clients un peu plus.
Et on a des boîtes de 3 personnes qui démarrent avec Kovri et qui évoluent comme
ça et on a des boîtes plus de 200 dev donc c'est assez hétérogène mais ils viennent
pas forcément non plus pour la même chose.
Tu vas avoir des petites boîtes qui vont venir parce que quand tu prends Covery,
du fait qu'on va te déployer une infra, qu'on va te la gérer,
etc., c'est super pratique au début. Tu n'as pas à te prendre la tête.
Quand on déploie une infra, tu es sort de direct.
Donc c'est pratique aussi si tu veux avoir une besoin de certification rapidement.
Et tu vas avoir des plus grosses boîtes qui viennent parce qu'en fait,
ils galèrent sur les environnements éphémères.
Et ça, c'est un pain point pour beaucoup de boîtes parce que les devs en ont besoin.
C'est compliqué à mettre en place. Ça a un coût aussi parce que du coup,
on a fait beaucoup d'optimisation de coût derrière et on propose pas mal de choses.
Tout à l'heure, je te disais tu vois, un dev, il déploie une nouvelle PR,
il peut avoir son environnement éphémère.
Ok, c'est cool, mais derrière si ça tourne 24-24, ça va commencer à coûter cher.
Donc on a des optimisations comme ça pour dire au bout de deux heures,
si tu n'as pas utilisé, ça se coupe tout seul. et donc il peut le rallumer quand il veut enfin.
Il y a plein de trucs autour de ça et donc ça c'est ce qui va plutôt intéresser
les grosses boîtes après on a des moyennes grosses boîtes qui rentrent par cover
là dessus et puis qui se disent ah putain mais en fait ça marche bien,
c'est cool bah en fait on va commencer à basculer de la prod aussi dessus et
donc comme ça ça leur permet d'avoir le faux complet et puis bah du coup cloner
des environnements c'est relativement simple du coup dès lors que t'as tout
la question c'est est-ce que je peux mettre un cover et continuer d'avoir le
reste de ma prod qui fait autre chose est-ce que c'est un.
Comment si jamais demain j'ai déjà une prod je peux intégrer Covery à certains
de mes développements c'est quoi je sais pas je suis sur Azure par exemple ou
je suis chez GCP comment je vais intégrer Covery je dois faire un truc complètement à côté ou pas ?
Alors ça dépend du niveau de maturité des boîtes typiquement
si t'es une boîte qui fait déjà du conteneur t'as ta
CI tu sais déployer du conteneur aujourd'hui tu
build tes images etc on va pas rebuilder à chaque fois de nous
aussi les images tu peux aller directement chercher le conteneur sur
un registre et donc si déjà tu fais
du conteneur c'est tu as moins de
boulot à faire on gère aussi elle donc si tu as si tu déploies du mb avec covry
tu peux aussi déployer duel tu peux déployer en fait quasiment tout ce que tu
veux on a un truc qui s'appelle life cycle job et dedans tu n'as absolument
ce que tu veux tu peux mettre du m tu peux du terraform tu peux être du chasse
tri du beau peu importe donc tu peux déployer vraiment tout tout ce que tu veux.
Et donc, en fait, il y a des transitions qui se font comme ça où typiquement,
tu vas avoir une prod qui est sur un compte AWS dans un VPC en particulier.
Le client va décider de déployer Covery sur un autre VPC.
Il va faire du VPC piring entre les deux et il va commencer à faire communiquer
ses infras, ce genre de choses et petit à petit, en fait, il passe du coup ses
environnements de dev ou ses jeux de test sur Covery.
Alors, des fois, c'est très, très simple parce que, comme je te disais,
ils ont déjà une CI avec des containers etc et donc on vient juste récupérer
les containers et puis des fois ils sont un peu moins matures sur ce côté là
et donc ils fondent pas aussi vers plus de cloud native et ce genre de choses,
ça dépend vraiment des clients de leur infra, de leur maturité Et quel est l'intérêt
justement d'utiliser Covery pour du Helm si jamais j'ai déjà toute une stack
avec du Helm, du Kubernetes donc si jamais c'est du Helm, il y a du Kubernetes,
mais quel est l'intérêt que je vais avoir là d'utiliser ça ça va être que pour des gens qui ont,
qui sont on-prem et vous installez directement un Kubernetes ou est-ce que c'est
quelque chose à mettre chez un cloud provider enfin quel va être l'intérêt et
sur quel environnement je vais pouvoir le mettre ouais,
aujourd'hui on ne fait pas de on-prem c'est que du cloud.
C'est en train de changer, enfin on est en train de rejouter ce type de fonctionnement aussi.
Mais ce qui est important de comprendre, c'est que Helm, la destination,
qui c'est qui va vraiment utiliser ça ? Généralement c'est les DevOps et les SRE.
La plupart du temps, pour ne pas dire 90% du temps, à chaque fois que je parle
à des devs qui doivent eux-mêmes déployer du Helm, en fait c'est un enfer parce
que c'est un bout de la stack que eux n'ont pas envie de gérer.
En fait c'est une dépendance qui leur a été plus ou moins imposés parce qu'en
fait on leur a dit que s'ils voulaient tel ou tel truc il fallait qu'ils passent
pas et puis ils devaient gérer ça et en fait
juste ça les ennuie alors quand
tu passes par Kovri t'as une interface qui te permet de dire bah voilà.
Moi mes DevOps ils m'ont préparé un environnement je sais que si ça je le clone
je le déploie en fait je vais avoir tout qui va marcher et je vais pouvoir builder
par dessus et en fait les devs ils ont la main parce qu'ils contrôlent exactement
ils peuvent faire tout ce qu'ils veulent dans son environnement.
Ils peuvent même, je t'ai dit, faire du Terraform, donc déployer des services
tiers sur des cloud providers qu'on ne gère même pas du tout.
Et faire en sorte que ça soit vraiment très simple pour le end-user.
En fait, la force, elle est là. On ne cherche pas à changer les méthodes classiques que le DevOps a.
C'est vraiment, on cherche à amener une expérience que le développeur ne peut pas avoir aujourd'hui.
Donc là, en fait, si jamais je veux une base de données donc comme ça le développeur
peut directement demander une base de données t'as parlé tout à l'heure de soit
des conteneurs de bases de données soit des bases de données managées aujourd'hui
vous supportez quoi comme type d'environnement donc si jamais c'est pas le on-prem ça va être
quel type c'est GCP AWS et Azure ouais,
alors de base nous on supporte quand je te disais managé aujourd'hui on ne fait
que AWS en managé et il y a que les 4 bases que j'ai citées tout à l'heure donc
MySQL Postgre, Redis et Mongo ça s'arrête là
on ne compte pas forcément en mettre plus parce qu'on a les lifecycle jobs déjà,
qui permettent du coup de déployer autre chose si tu veux faire du Dynamo si
tu veux faire des bases de données,
spécifiques à Google ou tu veux faire du Mongo A-Class ou n'importe quoi en
fait tu peux le faire déjà.
Et début d'année prochaine, on va arriver, donc remarquez qu'on a déjà un petit
peu utilisé, donc remarquez que c'est le signaux de Cowboy,
mais on arrive avec une espèce de plateforme open source qui permettra d'avoir
un espèce de catalogue, si tu veux,
sur lequel les DevOps vont pouvoir builder par-dessus et proposer sous forme
de catalogue aux développeurs de pouvoir déployer certains services.
Donc ça peut être du complètement in-house ou ça peut être des trucs externes,
comme je viens de citer Mongo Atlas ce genre de trucs c'est bien que tu en parles
de ce genre de choses parce que j'étais à l'OVH Summit il y a peu,
et je parlais avec Levercloud oui je parle avec Levercloud et justement eux
ils ont un peu cette problématique là en fait où tout le monde aujourd'hui on
voit qu'il y a un mouvement vers une espèce de pass at edge,
qui tend à apparaître donc moi j'avais un projet comme ça depuis très longtemps
qui s'appelait CapLiance,