Deployer Hugo sur AWS S3 avec un Pipeline Gitlab

Il existe beaucoup d’outils pour publier du contenu sur le Web. Des plus connus comme Wordpress ou Drupal, aux services SaaS clés en main comme Medium ou Blogger (pour ne citer qu’eux). Quand les uns demandent une infrastructure à déployer et à maintenir, les autres n’offrent pas forcement la flexibilité attendue.

Nous avions quelques prérequis :

  • serverless, buzzword mais surtout nous n’avions pas envie de maintenir une infrastructure
  • full static, on veut que ce soit rapide
  • épuré, mettre en avant le contenu
  • un système collaboratif avec Git

Ces attentes n’étaient qu’un bon prétexte pour utiliser Hugo. Et Hugo est devenu un autre bon prétexte pour mettre en place un workflow de déploiement avec les pipelines de Gitlab.

Les événements communautaires de la semaine du 22/05/2017

Second digest Oxalide des événéments parisiens de la communauté IT qui nous semblent intéressants, cette semaine. Au programme : du BitCoin, de la BigData et le 1er meetup Rancher !


Les événements communautaires de la semaine du 15/05/2017

Engagée dans la communauté, Oxalide participe régulièrement à des événements de type meetups ou conférences. Pour inciter les collaborateurs à aller à ces événements, Oxalide publie depuis quelques mois, en interne, une newsletter hebdomadaire avec une liste pré-selectionnée de meetups et webinars qui portent sur des sujets d’intérêt pour la société. Nous avons décidé de rendre cette newsletter publique. Voici donc celle de cette semaine !

Gitlab sur Kubernetes

Dans le dernier post, nous avons vu comment créer un cluster Kubernetes (K8s) prêt pour la production sur AWS avec Kops. Maintenant voyons comment, couplé avec des services managés AWS, on peut utiliser ce cluster pour héberger une application hautement disponible : Gitlab.

Connaitre Terraform, AWS et Kubernetes sera un plus pour la compréhension de cet article.

Tout le code source utilisé dans ce post est disponible sur Github.

Kubernetes sur AWS – Kops

Kubernetes est aujourd’hui la solution leader sur le marché des orchestrateurs de conteneurs. Sa promesse est de standardiser la façon dont on fait tourner des applications, sans avoir à se soucier de l’infrastructure sous-jacente : bare-metal, cloud public ou privé.

AWS est le leader sur le marché des clouds publics, il est donc important de pouvoir faire tourner Kubernetes facilement dessus. Dans ce post, je vais vous montrer, depuis 0, comment créer un cluster Kubernetes prêt pour la production sur AWS. Dans un post futur, j’expliquerai comment faire tourner une application relativement complexe -Gitlab- en complète haute disponibilité sur ce cluster.

Gitlab – Grand Master Plan

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.

Barman : Backup And Recovery Manager for PostgreSQL

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.

HashiConf Europe 2016 – What’s new ? #1

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 à 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.

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

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 !).

AWS IAM – Exemple avancé

Oxalide gère un grand nombre de comptes AWS différents pour ses besoins internes et pour ses clients. L’industrialisation de la gestion des comptes AWS est donc un enjeu pour Oxalide. L’une des principales problématiques à laquelle nous sommes confrontés est la gestion des accès et des droits sur ces différents comptes. Ce besoin nous a amené à étudier en profondeur AWS Identity and Access Management (IAM), le service d’authentification et autorisation d’AWS.

IAM est souvent délaissé à cause de sa complexité. C’est un service méconnu, mais qui permet de faire des choses très intéressantes pour la sécurité de son compte AWS et la gestion des ressources. J’ai récemment dû me pencher plus en détails sur IAM pour configurer un compte « bac à sable » dans lequel les utilisateurs doivent avoir des droits très larges, mais tout de même limités sur certains points :

  • accès minimal à IAM (i.e pouvoir changer son password),
  • accès interdits à certains services non-orientés « web »,
  • limité à eu-west-1 pour EC2,
  • limité à un certain type d’instance pour EC2.

Tomcat clustering, Varnish and Blue/Green deployment – Part 2

Previously: Tomcat Clustering, Varnish and Blue/Green deployment - part 1 In part 1, we set up a Tomcat cluster with parallel deployement and cluster-wide deployment. Go back to the first part if you have not read it, this article assumes that you have read it. Installing Varnish in front of everything Now, let’s install Varnish. For this to work, you need the curl vmod. Installing this vmod is outside the scope of this post, so it is assumed that it is already installed.

Tomcat clustering, Varnish and Blue/Green deployment – Part 1

At Oxalide, we aim to provide the best possible uptime to our customers while encouraging them to adopt an agile workflow where they push new versions of their apps often and seemlessly.

Because most of our clients are using PHP (or Ruby), we usually help them to setup Capistrano: it’s efficient and there are a lot of plugins for different frameworks (capifony for instance). Varnish is also quite often in our list of requirements, because of its sheer capacity to absorb trafic and deliver content.

AWS ELB Best Practices

Un tour d’horizon des bonnes pratiques à déployer lors de la mise en oeuvre d’un ELB sur AWS.

Git subtree, du côté obscur de git

Si vous développez depuis plus de trois mois, vous vous êtes sûrement déjà dit « j’aimerai bien factoriser ce petit bout de code pour l’utiliser dans d’autres projets ». Si vous travaillez avec Git, la solution la plus simple est de créer un nouveau dépôt Git et d’y copier le dossier qui vous intéresse. Cela a un gros désavantage : vous perdez tout l’historique du dossier. Si le projet a déjà quelques mois, il est fort à parier que des informations importantes se trouvent dans cet historique (vous écrivez de bon messages de commits, n’est-ce pas ?).

Content is CC BY-SA 4.0 - Powered by Hugo & devops from Oxalide