Skip to content

Instantly share code, notes, and snippets.

@nand2
Last active December 16, 2015 01:08
Show Gist options
  • Save nand2/5352378 to your computer and use it in GitHub Desktop.
Save nand2/5352378 to your computer and use it in GitHub Desktop.

Dyndrop Challenge

Ce challenge tournera autour du PaaS open source CloudFoundry.

Installation de Cloudfoundry

Avant toute chose, je vous conseille d'installer direct CloudFoundry sur une VM, en suivant les instructions sur: https://github.com/cloudfoundry/vcap/ -- C'est long! Ubuntu server 10.04 est necessaire.

Quick intro de l'architecture

Archi http://www.slideshare.net/rajdeep/cloud-g

Challenge 1: "Limitation des resources allouées" - Niveau "moyen"

Hacker le stager PHP pour y ajouter des contraintes d'utilisation CPU.

Lorsqu'une application est envoyée sur Cloudfoundry, vous specifiez le nombre d'instances et la RAM que vous leur allouez. L'idée serait de aussi limiter l'utilisation du CPU. Comme CloudFoundry ne propose pas de spécifier de limitation de CPU, il s'agira de prendre la limitation de RAM comme benchmark: admettons que 2Go de RAM vous donnerai droit a 100% des ressources CPU, 1Go de RAM 50%, 512Mo de RAM 25%, etc...

Au final, si vous uploadez une app php en demandant une instance avec 512Mo de RAM, vous devrez obtenir un dropplet qui fonctionne avec 25% de CPU et qui ne depasse sous aucun cas 512Mo de RAM.

Tous les moyens possibles sont autorisés: configuration dans PHP, apache, ou bien en dehors, au niveau du kernel. La solution doit marcher avec les composants version 1 de CloudFoundry.

Challenge 2: "Démarrage à la volée des Droplets" - Niveau "impossible"

** Hacker le router et/ou le DEA pour démarrer les droplets à la volée en moins de 2s **

Admettons que un CloudFoundry hoste 1000 apps PHP, et que seules 100 sont actives à tout moment: ca a du sens d'éteindre les droplets des 900 apps inactives, qui utilisent de la RAM pour rien.

L'idée est donc d'hacker le router et/ou le DEA pour que lorsqu'une requete est recu pour un site dont les droplets ont été éteint, de les redemarrer à la volée avant que le router ne leur passe la requete. Du point de vue utilisateur, le site doit sembler avoir toujours été actif. Le probable meilleur endroit serait de se hooker à l'endroit ou le routeur fait son lookup pour determiner sur quel serveur DEA se trouve l'app; mais tout autre moyen est OK.

Cela doit fonctionner pour les apps PHP au moins, et le lag du au redémarrage du droplet doit être inférieur a 2s. Cela doit aussi gérer le cas où une requete est recu alors que le droplet est deja en cours de redémarrage.

Resources et infos supplémentaires

2 blog posts expliquant par la pratique comment marchent le stager et le DEA:

Un blog post un peu moins cool mais spécifique à PHP sur le DEA et le stager:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment