• 15 septembre 2016

    Gitlab – Grand Master Plan

    gitlab grend master plan Oxalide

    Hier, à 19h, a eu lieu la présentation du « Grand Master Plan » de Gitlab : la direction que la société et son produit vont prendre dans les mois à venir.

    Rappels

    Gitlab est une société qui a été créée pour soutenir le produit éponyme. Gitlab a été conçu comme un concurrent open-source de Github : une plateforme centralisée de gestion de dépôts Git avec une interface graphique accessible via un navigateur. Comme Github, Gitlab propose les notions de forks (créer sa propre copie d’un projet) et de Pull Requests (appelée de manière plus correcte Merge Requests dans Gitlab) qui permettent des proposer des modifications sur un projet qui seront soumises à une code review.

    Depuis ses débuts, Gitlab a énormément évolué fonctionnellement et apporte aujourd’hui un certain nombre de features qui ne sont pas disponibles chez la concurrence (liste non exhaustive) :

    • GitlabCI : intégration continue directement intégrée dans Gitlab, essentiellement à base de Docker,
    • Docker Registry : hébergement d’images Docker,
    • Issues board : un kanban directement intégré au projet,
    • Graphical Merge Conflict Resolution : lorsqu’il y a un conflit lors d’une merge request, Gitlab propose maintenant une interface graphique pour le résoudre alors qu’il faut habituellement passer par le terminal.

    Modèle économique

    Gitlab est un produit open-source, que vous pouvez installer à volonté, où vous voulez. https://gitlab.com/users/sign_in est la version SaaS de Gitlab : totalement gratuite, avec toutes les features (CI, projets privés, etc.). gitlab.com a cependant tendance à être un peu surchargé (les jobs de CI notamment peuvent mettre longtemps à tourner) et fait toujours tourner la toute dernière version de Gitlab, bugs inclus.

    Gitlab Enterprise Edition est la version payante de Gitlab sur laquelle Gitlab gagne de l’argent. Elle reprend la version open source tout en lui ajoutant des fonctionnalités (par exemple, l’utilisation d’ElasticSearch comme backend de recherche).

    L’entreprise

    L’entreprise Gitlab comptait 9 employés il y a 18 mois. Ils sont aujourd’hui une centaine et viennent de compléter leur deuxième tour de financement à hauteur de 20 millions de dollars.

    Gitlab a la particularité d’être une entreprise complètement « remote » : si elle est basée à Amsterdam, la totalité de ses employés sont répartis dans le monde entier et communiquent via des chats, des visio-conférences et les tickets Gitlab. Gitlab est aussi un projet qui a un rythme de release périodique : une nouvelle version mineure sort tous les 22 du mois, quelques soient les nouveautés. Cette méthode de release management leur a permis de fournir un nombre impressionnant de nouveautés sur les 18 derniers mois.

    Grand Master Plan

    L’ambition présentée par Gitlab est de fournir un ensemble très bien intégré de produits pour gérer le cycle de vie entier d’un projet : de l’idée à la mise en production, tout en gardant une traçabilité complète et pour permettre de réduire les cycles de développement. Gitlab indique aussi vouloir éviter le vendor lock-in et ouvre donc un maximum d’API pour pouvoir remplacer n’importe quel outil de la stack par un autre.

    Ils ont appelé ce concept comme du « Conversational Development », présenté comme une évolution de l’Agile.

    Les images étant plus parlantes que les mots, voici une démonstration de ce qu’ils veulent faire (note : je dirai que 80% des features montrées dans cette vidéo existent déjà) :

    L’intégralité du webcast d’hier est disponible ici :

    Conclusion

    Je pense que Gitlab a déjà grignoté une part de marché non négligeable à Github et que cette progression va continuer grâce au rythme très soutenu auquel le produit est développé. Les features existantes et celles qui arrivent vont en effet faire de Gitlab un outil encore plus central qu’il ne l’est aujourd’hui. Il est probable que dans les mois à venir, nous n’ayons plus besoin que de Gitlab pour gérer tout le cycle de vie d’un projet.

    Article rédigé par Théo Chamley, consultant architecture & DevOps chez Oxalide.

  • 30 août 2016

    DevOps, pour accélérer le passage de l’idée au business

    Avis d’Expert par  Maxime Kurkdjian, Directeur associé d’Oxalide rédigé à l’occasion de l’Apérotech DevOps*

    Avec la révolution digitale, les entreprises sont sous pression. Au risque de perdre leurs avantages concurrentiels historiques, elles sont invitées à opérer au plus vite leur transformation numérique. Pour rester compétitives, le délai de mise sur le marché de leurs produits ou services doit être réduit de façon radicale. La réponse à cet impératif tient en six lettres : DevOps.

    DevOps, trait d’union entre les développeurs et la production

    Malgré la popularité grandissante de ce buzzword, il est bon de rappeler ce qu’est le DevOps. Il s’agit littéralement de la contraction des mots anglais « development » (développement) et « operations » (exploitation).

    Méthodologie ? Boîte à outils ? Processus ? Non. Le terme DevOps fait plutôt référence à une culture qui vise, au sein d’une direction des systèmes d’information (DSI), à améliorer la communication et la collaboration entre, d’un côté, les équipes en charge du développement des applications (les Devs) et, de l’autre, celles responsables de leur mise en production et de leur maintien en condition opérationnelle (les Ops).

    Faire dialoguer ces deux populations est un défi d’autant plus grand qu’elles ont pour coutume de travailler en silos. Elles ne partagent pas les mêmes priorités, les Devs pensent vitesse et court terme, tandis que les Ops raisonnent stabilité et long terme.

     

    Une vitesse de déploiement des applications exceptionnelle

    Aujourd’hui, DevOps n’est pas seulement un buzzword, c’est une réalité opérationnelle. Une réalité qui se mesure par des gains tangibles quand les différentes équipes du département IT parviennent à resserrer leurs liens en se conformant aux principes de DevOps.

    L’étude « 2015 State of DevOps Report » de PuppetLabs et IT Revolution Press conduit auprès de 20.000 Devs et Ops révèle ainsi que les équipes passées à DevOps déploient 30 fois plus fréquemment, dans des délais 200 fois plus courts, et rencontrent 60 fois moins d’incidents. Et quand elles font face à des dysfonctionnements, elles les résolvent 168 fois plus rapidement.

     

    L’extension des méthodes agiles aux équipes de l’exploitation

    Voilà maintenant cinq ans que le terme DevOps a fait son apparition. Il a été inventé par un « Ops », le Belge Patrick Debois. Celui-ci était frustré de voir à quel point l’agilité avait révolutionné la culture des équipes de développement – celle des « Devs » -, alors que les équipes de production et d’exploitation IT – celle des « Ops » – accusaient en la matière un sérieux retard.

    DevOps est de fait l’extension des méthodes agiles au domaine de l’exploitation. Maîtrisées depuis une dizaine d’années, les méthodes agiles, telles Scrum, facilitent l’intégration continue des besoins des utilisateurs au sein des applications, grâce à des cycles de développement courts, sur un mode itératif et collaboratif, avec une mise des développeurs au contact régulier des utilisateurs.

    Or, la mise en production des applications n’est possible que lorsque l’infrastructure est prête à les accueillir. Avec une méthode agile comme Scrum, on a l’impression de faire des cycles courts de production. En réalité, on produit des fonctionnalités qu’on empile en environnement de recette ou en pré-production, mais qui ne passent jamais en production parce que le département Ops n’est pas du tout dans la boucle.

  • 23 août 2016

    Hands On Rancher – Part 2

    Le 19 juillet dernier, notre consultant Théo Chamley a fait une présentation de Rancher au 42ème Docker Paris Meetup. Rancher est un orchestrateur Docker et, en tant que tel, un concurrent de Docker Swarm et Kubernetes. Il a cependant quelques autres fonctionnalités qui le rendent très intéressant et pas incompatible avec Swarm ou Kubernetes.

    Retrouvez la première partie de ce Hands On ici : http://wp.me/p4iWGf-2k8

    Pour cette deuxième partie, deux sujets sont abordés :

    • Démonstration du catalogue de Rancher,
    • Création d’un catalogue personnalisé, mise à jour d’un produit du catalogue,
    • Création d’un cluster Kubernetes via Rancher.

    Deux liens importants :

    1. Code source : https://github.com/MrTrustor/rancher-vagrant
    2. Instructions : https://github.com/MrTrustor/rancher-vagrant/blob/master/HANDSON.md

    Des sous-titres français sont disponibles sur la vidéo.

  • 04 août 2016

    Hands On Rancher – Part 1

    Le 19 juillet dernier, notre consultant Théo Chamley a fait une présentation de Rancher au 42ème Docker Paris Meetup. Rancher est un orchestrateur Docker et, en tant que tel, un concurrent de Docker Swarm et Kubernetes. Il a cependant quelques autres fonctionnalités qui le rendent très intéressant et pas incompatible avec Swarm ou Kubernetes.

    Voici la première partie de la présentation :

    • Présentation générale de Rancher,
    • Première démonstration : création d’un cluster ElasticSearch et ajout de nœuds dans Rancher.
    1. Code source : https://github.com/MrTrustor/rancher-vagrant
    2. Instructionshttps://github.com/MrTrustor/rancher-vagrant/blob/master/HANDSON.md

    Des sous-titres français sont disponibles sur la vidéo.

    Dans la seconde partie qui arrivera sous peu, vous pourrez apprendre à créer votre propre catalogue de services dans Rancher (une de ses meilleures fonctionnalités) et comment gérer un cluster Kubernetes via Rancher.

  • 27 juillet 2016

    Barman : Backup And Recovery Manager for PostgreSQL

    logo1

    Barman est un outil d’administration développé par 2ndQuadrant, permettant le backup et la restauration PITR d’instances PostgreSQL complètes, comme par exemple démarrer un serveur de test restauré dans l’état d’une date précise, ou encore le montage d’un read replica.

    Prérequis :

    • 1 serveur master pgsql
    • 1 serveur de backup (barman)
    • 1 serveur slave pour la restauration
    • Des accès au user postgres et à la replication (en trust ip côté pg_hba) et ssh (avec clef) sont nécessaires pour que barman puisse accéder à PSQL et au filesysteme du serveur. Cela lui permet d’effectuer les backups, et de pousser les wals lors d’une restauration.
    • Le serveur master doit, de son coté, pouvoir se connecter à la machine barman pour l’archivage continu des wals (ssh avec clef également).
    • Les wals stockés sur le serveur de backup sont ensuite compressés, puis réutilisés avec un systeme de liens symboliques afin de reduire l’espace utilisé par l’archivage.

    Pour cela il faut ajouter ceci à la configuration de barman :

    /etc/barman.conf
    compression = gzip
    reuse_backup = link
    • Enfin, le serveur de restauration doit avoir la même version majeure de pgsql que le master.

    Installation (repo psql officiel) et exemple de configuration

    apt-get install postgresql-client-9.5
    apt-get install barman
    /etc/barman.conf
    [barman]
    barman_home = /space/barman
    barman_user = barman
    log_file = /space/logs/barman/barman.log
    compression = gzip
    reuse_backup = link
    minimum_redundancy = 1
    immediate_checkpoint = true
    basebackup_retry_times = 3
    basebackup_retry_sleep = 30
    last_backup_maximum_age = 1 DAYS
    [main]
    description = "serveur_master_pgsql"
    ssh_command = ssh postgres@serveur_master_pgsql
    conninfo = host=serveur_master_pgsql user=postgres
    incoming_wals_directory = /space/barman/wal/master
    retention_policy_mode = auto
    retention_policy = RECOVERY WINDOW OF 7 days
    wal_retention_policy = main
  • 22 juillet 2016

    HashiConf Europe 2016 – What’s new ? #1

    Hashiconf_002

    S’est déroulé en juin dernier à Amsterdam la Hashiconf Europe 2016, première du nom, et à laquelle la team Oxalide était présente en force 🙂

    Cette conférence a à l’origine lieu aux Etats Unis, elle est organisée par HashiCorp pour ceux qui ne connaissent pas déjà. Ils éditent quelques outils que nous manipulons de plus en plus chez Oxalide, nous allons en faire le tour ici pour vous présenter certains méconnus ou peu utilisés dans nos environnements et d’autres déjà bien installés dans notre quotidien en production.

    Je vous invite à regarder les vidéos sélectionnées dans cet article qui contiennent la matière technique de ces deux jours de conférence,  pour les sujets qui vous intéressent, le format est ni trop long ni trop court à mon sens ( environ 30 minutes ) pour chaque session.

  • 20 juillet 2016

    REX sur le service DMS proposé par AWS dans le cadre de migrations de bases de données

    AWS – Test de Database Migration Service (DMS)

    Contexte

    Dans le cadre de migration d’infrastructures vers AWS, nous avons besoin de migrer les bases de données en réduisant au minimum le downtime. Pour se faire, AWS nous propose son service Database Migration Service (DMS) : https://aws.amazon.com/fr/dms/

    TL;DR: avec DMS on spécifie une base de données source (un MySQL hébergé en premise), une base de données cible (une instance RDS) et une copie des données de la source vers la cible est réalisée avec la possibilité de mettre en place une réplication (pas de setup spécifique à réaliser, c’est « presque » magique). Il faut préalablement rendre la base de données accessible pour AWS (n’oubliez pas le filtrage !).

    Mise en place

    Ci-dessous les actions à réaliser dans la console AWS pour effectuer une copie d’une base de données que l’on appellera « testdatabase« .

    Subnet groups

    Il faut créer un groupe de subnet dans lequel seront renseignés au moins deux subnets qui pourront accéder à l’instance RDS présente dans le VPC. Ces subnets devront aussi être rattachés à une table de routage possédant une route pour sortir vers l’extérieur (0.0.0.0/0 -> IGW ou NATGW).

    dms_01

  • 18 juillet 2016

    Oxalide porte la connaissance jusque sur ses bancs

    Quels bancs ? Les bancs de l’école avec Oxalide Academy. Des sessions réservées aux ingénieurs de ses clients, désireux d’en savoir plus sur des technologies qu’ils auront bientôt entre les mains.

    Oxalide Academy, libérer la connaissance

    Depuis qu’Oxalide érige le DevOps en art de faire, ses collaborateurs n’ont eu de cesse d’accompagner leurs clients, d’abord dans sa découverte, puis son introduction en interne. Mieux collaborer, prendre conscience des contraintes des autres, les comprendre et les intégrer dans ses pratiques, est un des aspects du DevOps qui conduit au succès d’un projet.

    Pour toujours mieux servir ses clients, l’infogéreur maintient une longueur d’avance sur la maîtrise des technologies et dégage du temps à ses équipes pour les explorer, les maîtriser et les proposer in fine en réponse à l’amélioration continue de son offre. Mais pour maintenir l’indispensable collaboration avec le client, ces mêmes technologies doivent être connues de chacun, sans quoi, quiproquos et malentendus s’invitent à la table des négociations.

    Alors quoi de plus normal que d’offrir les conditions idéales pour partager ces connaissances ? En 2014, Oxalide Academy prenait vie dans l’esprit des fondateurs et devenait une réalité en 2015, aux côtés des Apéro’techs et des Pizza’nTools, des formats déjà appréciés des clients d’Oxalide.

    Des ateliers 100 % technologies

    Ces workshops sont entièrement dédiés aux ingénieurs, autour de technologies partagées entre Dev’ et Ops’, comme Varnish ou Docker, ou encore ElasticSearch.

    La formation se déroule sur une matinée, afin de ne pas monopoliser les équipes clients. Entre théorie et pratique, ce sont trois heures très intenses qui attendent les participants. Pour répondre précisément aux besoins, les approches sont orientées en fonction des niveaux d’expertise, évidemment disparates. Débutants, intermédiaires ou avancés, chaque workshop n’en demeure pas moins une plongée concrète dans les arcanes des meilleures technologies.

    Ainsi et par exemple, Docker (niveau débutant à intermédiaire), aborde le fonctionnement de Docker, les nouvelles collaborations entre Dev et Ops, un écosystème riche ouvrant le champ des possibles. L’événement a rassemblé des profils venant de différents secteurs tels que médias, immobilier et BTP, fabricant et distributeur d’équipement sportif. Ainsi des CTO, Chefs de projet, Lead dev et Dev, Admin Sys ont pu partager la connaissance sur le sujet de Docker.

    Ce n’est que le début !

    Les nombreuses demandes des équipes clients confirment le succès de la formule, qui privilégie les petits groupes, plus favorables aux échanges. Chaque formation est aussi l’occasion de signaler son intérêt pour une technologie en devenir.

    Les ingénieurs d’Oxalide y trouvent aussi leur compte. Former sur une technologie qu’ils maîtrisent reste pour eux une excellente façon de se challenger et de ne pas se contenter de leurs acquis. Enfin, il n’y a rien de plus efficace que ces rencontres pour conduire une collaboration vers un partenariat de confiance.

    Bien partie pour s’installer dans la durée, Oxalide Academy se révèle le pendant indispensable à la proximité instaurée entre Oxalide, l’expert Devops, et ses clients, soucieux de rester à la pointe de la technologie.

  • 15 juin 2016

    AWS représente déjà 25% de l’activité d’Oxalide

    Interview réalisée par  de Channelnews

    Sébastien Lucas

    L’infogéreur devops Oxalide vient de recevoir d’Amazon Web Services le prix de la meilleure croissance partenaire pour la France. Nous avons demandé à Sébastien Lucas, son directeur associé, de nous présenter plus en détail Oxalide et son partenariat avec AWS.

    Channelnews : Lors du dernier AWS Summit qui s’est tenu à Paris le 31 mai dernier, Oxalide a été récompensé pour sa croissance sur AWS. Peut-être est-il utile de rappeler qui est Oxalide et quel est son métier ? Doit-on d’ailleurs plutôt parler d’infogéreur ou d’hébergeur ?

    Sébastien Lucas : Oxalide se définit comme un spécialiste de l’infogérance DevOps des infrastructures web critiques. L’hébergement est la matière première que façonne Oxalide mais la société se positionne avant tout comme l’équipe de production web de ses clients, via la délégation d’une partie de leur système d’information. S’y greffe une dimension conseil et expertise, indispensable pour aider les clients à relever les défis de la transformation digitale.

    Vous insistez sur la notion de devops.

    Sébastien Lucas : Oui. La société était tournée à sa création en 2000 vers le conseil et le développement avant de bifurquer vers l’infogérance et l’hébergement. L’hébergement est arrivé sur le tard, en 2009. C’est d’ailleurs de cette époque que date notre première marque d’intérêt pour AWS. Mais le marché n’était alors pas prêt pour le Cloud public. On est donc venu à l’hébergement par les services et non par les infrastructures. Le code reste d’ailleurs au cœur de notre culture. Nul n’intègre nos équipes qui ne sache coder. À l’heure où les infrastructures ne se déploient plus mais se codent, savoir programmer nous semble un prérequis indispensable.

    Quel est la part de votre activité infogérance exercée dans le Cloud public ?

    Sébastien Lucas : C’est aujourd’hui environ 25% de notre activité totale. Surtout, cette part est en très forte croissance puisqu’il y a un an, elle était encore quasiment nulle.

    AWS est-il votre seul partenaire dans le Cloud public ?

    Sébastien Lucas : Oui. D’où le prix de la meilleure croissance reçu pour le 31 mai.

    Quand avez fait ce choix d’un partenaire unique et pourquoi ?

    Sébastien Lucas : Nous avons effectué une comparaison des acteurs du marché il y a environ 18-24 mois qui nous a conduits à sélectionner AWS comme partenaire unique pour son avance technologique et son rythme d’innovation, qui nous permet d’aller nous même vite. Son avance est considérable et à même tendance à s’accélérer par exemple dans la gestion de la sécurité, l’orchestration des images machines (AMI), ses solutions de files d’attente, ses services de IaaS prêt à l’emploi, ses outils décisionnels (Quicksight), etc.

    Pourquoi votre partenariat avec AWS n’a-t-il pas démarré plus tôt ?

    Sébastien Lucas : Comme je vous l’ai dit, le marché n’était pas prêt. Il y a quelques années en arrière, il fallait motiver les clients, justifier le choix de Cloud public. Les applications non plus n’étaient pas prêtes. Les coûts pour migrer étaient importants. De son côté, AWS avait encore du chemin à faire vers ses utilisateurs pour rendre ses produits plus attractifs. Le fait pour AWS d’avoir étoffé son équipe en France a été également déterminant. AWS a su constituer une équipe performante, à l’écoute du marché, qui mouille le maillot pour former, évangéliser, signer des grands comptes, et mettre en œuvre des services professionnels dignes de ce nom.

    Quelle a été la croissance d’Oxalide en 2015 et quelles sont vos perspectives 2016 ?

    Sébastien Lucas : Oxalide a réalisé un chiffre d’affaires de 12 M€ en croissance de 20% en 2015 avec un effectif de 75 personnes. Cette année l’effectif devrait atteindre les 100 personnes.

  • 09 juin 2016

    Le prix de la plus forte croissance sur AWS est attribué à Oxalide!

    Oxalide, expert DevOps des infrastructures web critiques, est un des membres très investi du réseau de partenaires AWS (APN) . Pour sa stratégie de développement, pour avoir su aller à la vitesse du Cloud, pour la transformation de sa chaîne de valeur, Oxalide reçoit une belle reconnaissance d’Amazon Web Services.

    Oxalide transforme la production informatique en s’appuyant sur AWS

    Membre du programme partenaire AWS depuis 2013, Oxalide offrent à ses clients désireux d’entrer dans une démarche DevOps toutes les conditions de vélocité et de flexibilité pour y parvenir en s’appuyant sur AWS. Le choix pour Oxalide de se concentrer sur un seul fournisseur de Cloud s’appuie sur la volonté de clarifier et d’optimiser la chaîne de valeur. A ce jour, l’ensemble des ingénieurs WebOps chez Oxalide sont certifiés et de plus en plus de clients historiques et récents de l’infogéreur migrent vers les environnements d’Amazon Web Services. Des migrations réalisées avec les bonnes pratiques d’AWS.

    C’est une situation qui offre le meilleur terrain d’évolution possible aux entreprises, en fonction de leur degré d’expérience sur ces questions et de leur besoin d’accompagnement. Et ce, dans l’optique d’exploiter au mieux les performances et la richesse d’AWS pour leurs activités métiers.

    Le premier Award AWS et la consécration d’un savoir-faire

    Oxalide et ses équipes se réjouissent de cette récompense qui souligne la capacité d’Oxalide à aller à la vitesse du Cloud et son investissement massif. Ce prix récompense aussi la vision à long terme d’Oxalide qui a compris très tôt la puissance de l’automatisation sur les process de l’infogérance. Pour les clients d’Oxalide, ce prix est la confirmation du meilleur choix dans la conduite de leurs stratégies business.

    Retrouvez cet article sur www.cloudmagazine.fr

Newsletter

Inscrivez-vous et tenez vous au courant de l’actualité Oxalide