Sommaire
AWS et Azure débarquent en France
Le mois de septembre fût riche en annonces de déploiement de nouvelles régions pour les providers de Cloud public. Chez Amazon les bruits de couloirs se sont confirmés avec l’annonce de la création d’une région contenant trois zones de disponibilités qui ouvrira en 2017. Cette nouvelle offre hébergée sur le sol Français pourra aider à lever les derniers freins des entreprises soucieuses de la sécurité de leurs données. Il y aura donc quatre régions AWS en Europe avec Dublin, Londres, Francfort et Paris. Pour plus de détails, vous pouvez consulter l’annonce officielle du 27 Septembre.
Microsoft a de son côté répondu à cette déclaration en annonçant l’ouverture pour 2017 de nouveaux datacenters en France pour déployer les services Azure, Office 365 et Dynamic 365. L’objectif de Microsoft est d’ouvrir 36 nouvelles régions d’ici à la fin 2017 dépassant ainsi le nombre de régions ouvertes par ses concurrents. N’hésitez pas à lire l’annonce officielle sur le blog de Microsoft France.
De son côté, Google n’est pas en reste avec l’annonce le 29 septembre de l’ouverture prochaine de 8 nouvelles régions dont 3 en Europe (Londres, Finlande, Francfort). La France devra encore attendre un peu, mais Google laisse planer le doute en prévenant que d’autres régions seront annoncées en 2017. Pour plus de détails, vous pouvez lire le billet sur le blog de Google Cloud.
L’Europe est donc définitivement devenue un fort axe de croissance pour les providers de Cloud Public.
AWS annonce un plugin Collectd pour CloudWatch
AWS vient d’annoncer la disponibilité d’un plugin Collectd permettant de pousser les données dans CloudWatch : https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/.
Dans une stack de métrologie open-source typique, nous trouvons :
- Collectd : l’agent installé sur chaque machine qui remonte un ensemble de métriques. Collectd propose de nombreux plugins, qui permettent de remonter un large panel de métriques (CPU / Disk / JMX / log parsing / Nginx …)
- Graphite : le backend time series qui stocke les métriques
- Grafana : l’interface web permettant de créer des dashboards de manière aisée. Notons que Graphite propose aussi une interface Web mais Grafana se révèle beaucoup agréable à utiliser.
Aujourd’hui, avec l’annonce d’AWS, nous pouvons nous affranchir de la mise en place de Graphite. Dans ce cas, nous perdons la possibilité d’utiliser les fonctions mathématiques de Graphite mais nous nous affranchissons de la mise en place d’un cluster Graphite, ce qui n’est pas négligeable : avoir une infrastructure Graphite scalable est faisable mais pas trivial, nous avons d’ailleurs écrit un article sur ce point.
RKTnetes the hard way
Sur ce repository Github nous est proposé un tutoriel permettant de créer son propre cluster Kubernetes étape par étape. Contrairement à ce que le titre indique, ce tutoriel peut s’appliquer à RKT mais aussi à Docker.
Le but de ce tutoriel est de construire un cluster Kubernetes étape par étape, afin de pouvoir comprendre quels sont les composants nécessaires à un cluster ainsi que leurs interactions. Quelques points, tels que la remontée de logs vers un système centralisé (Rsyslog, ELK, Graylog), l’intégration GCE/AWS (installation automatique) ne sont pas traités. Ce tutoriel est purement à but éducatif et le cluster construit n’a pas vocation à devenir un cluster de production. La compréhension acquise permettra de réaliser l’automatisation du déploiement d’un cluster Kubernetes correspondant à des besoins spécifiques (l’utilisation uniquement de RKT comme système de container par exemple).
Ce tutoriel propose d’exécuter la mise en place d’un cluster Kubernetes soit sur Google Cloud Platform ou Amazon Web Services. Bien évidemment, toutes les étapes sont exécutables sur du baremetal, VMWare, Virtualbox, QEMU-KVM.
RethinkDB Shutdown
La société derrière RethinkDB ferme ses portes.
Malgré plus de 11000 stars, 1700 forks et 126 contributeurs, ils n’ont pas réussi à trouver un business model viable.
Certains recherchent des alternatives mais la communauté reste très active et les plus pessimistes ne voient aucun risque pour le produit sur les 24 prochains mois.
Cela peut sembler peu mais c’est en fait déjà beaucoup pour un milieu évoluant aussi vite et il va falloir du temps avant de voir émerger une alternative sérieuse.
Source :
Pokemon GO on Google Container Engine
Kubernetes est sans conteste l’orchestrateur de conteneurs du moment.
Google, son initiateur propose une offre Kubernetes nommée Google Container Engine, elle a déjà fait ses preuves auprès de différentes entreprises mais c’est sans nul doute Pokemon GO qui détient le plus gros cluster Google Container Engine.
Pokemon GO est un succès mondial et Niantic n’imaginait pas voir arriver un trafic 5 fois supérieur au pire scénario prévu.
Mais comment orchestrer de plus en plus de conteneurs tous les jours tout en s’occupant des améliorations produit et pas de la plateforme.
Kubernetes, capable d’orchestrer des milliers de conteneurs sans problème et les infrastructures de Google, capables de se dimensionner de façon dynamique en fonction de la demande en font le couple parfait pour ce genre de situation.
C’est donc naturellement vers ce couple que Niantic c’est tourné.
Source :
Datadog lance son APM
La société Datadog, célèbre pour son outil d’analyse/monitoring en mode SAAS, propose désormais en bêta un nouvel outil pour l’analyse du comportement des applications. Ce nouvel outil permet à la fois de couvrir le comportement applicatif ainsi que celui de l’infrastructure sous-jacente. Les caractéristiques principales sont les suivantes :
- une identification fine et automatique de l’ensemble de l’infrastructure permettant à l’application de fonctionner
- tout comme l’agent Datadog existant, l’installation de l’agent APM est très simple
- il est possible de mettre en place rapidement des dashboards, modifiables suivant le besoin. De plus, Datadog fournit tout ce qui est nécessaire afin de suivre l’exécution de requêtes SQL, de frameworks comme Django et autres composants standards dans les applications “modernes”
- L’application est analysée de bout en bout. Ainsi, pour une requête sur un applicatif, toutes les interactions entre les différents composants sont tracés. De cette façon, peu importe où se trouve le goulet d’étranglement, celui-ci sera détectable
- les fonctionnalités existantes de Datadog sont disponibles avec l’APM : rétention des données, alerting fin
Pour avoir accès à la béta, il faut s’inscrire ici (liste d’attente) : https://www.datadoghq.com/apm/
Source :
Conteneur un point sur la situation
Les choses s’accélèrent dans la communauté Kubernetes RedHat et Google principaux contributeurs se sont lancés dans la création d’un runtime pour exécuter des conteneurs. Le projet initialement nommé OCID pour marquer son adhérence au standard OCI a été renommé cri-o pour Container Runtime Interface – OCI. Le but de cet outil est de fournir un moyen d’exécuter des images issues des Docker Registry dans un runtime qui ne se chargera d’aucune orchestration. La démarche affiché de ce non fork de Docker est de fournir une implémentation de référence pour le projet OCI qui implémente une interface de contrôle destinée aux orchestrateurs.
Dans le même temps Kubernetes est en pleine refonte sur la partie de ses interactions avec Docker. Kelsey Hightower le lead developper de Kubernetes explique que le but est de découpler son orchestrateur du runtime qu’il utilise en introduisant au travers du projet CRI une API utilisée par les kubelets pour contrôler les conteneurs.
Cette API ouverte à pour but de définir un standard de communication entre orchestrateur et conteneurs. La prochaine version de Kubernetes est prévue pour intégrer l’utilisation de la fameuse CRI dans kubelet et de fournir les implémentations de référence pour Docker, hyper.sh, rkt et cri-o. La démarche de Red Hat et Google a tendance à ménager Docker en évitant la création brutale d’un fork et en favorisant l’émergence d’un réel standard qui serait le plus petit dénominateur commun.
Sources :
