Categories
Cloud

pyAggr3g470r vient juste d’exploser la base de données

Et c’est une très bonne nouvelle. Nouvelle qui m’a été transmise cette nuit par une alerte de Heroku concernant l’application pyAggr3g470r. Voici un extrait.

The database HEROKU_POSTGRESQL_CYAN_URL on Heroku app pyaggr3g470r has exceeded its allocated storage capacity. Immediate action is required.

The database contains 15,115 rows, exceeding the Dev plan limit of 10,000. INSERT privileges to the database will be automatically revoked in 7 days. This will cause service failures in most applications dependent on this database.

Il y a donc bien des personnes qui utilisent le service. Je suis également content de voir que le service Heroku n’a pas bloqué l’application et laisse même fonctionner la base durant 7 jours – ainsi malgré cette alerte l’équipe de pyAggr3g470r a pu continuer à dormir tranquillement.

Je viens donc juste de transférer la base vers une nouvelle. Et il faut dire que cette opération est plutôt simple à réaliser grâce au client, voyez:

$ heroku addons:add pgbackups
$ heroku addons:add heroku-postgresql:hobby-basic
$ heroku maintenance:on
$ heroku pgbackups:transfer HEROKU_POSTGRESQL_GOLD_URL
$ heroku pg:promote HEROKU_POSTGRESQL_GOLD_URL
$ heroku maintenance:off
$ heroku addons:remove HEROKU_POSTGRESQL_CYAN_URL

Pour le moment aucune action particulière supplémentaire sera réalisée. Toutefois je songe à mettre en place un plan payant (via Bitcoin de préférence) pour les utilisateurs qui dépasseront un certain seuil.

Categories
Cloud Python

pyAggr3g470r dans le cloud

pyAggr3g470r est dorénavant déployable sur Heroku. Évidemment, il est toujours possible de l’utiliser sur un serveur traditionnel.

Voici comment le déployer sur Heroku. Rien de plus simple. Si vous désirez le tester mais que vous n’avez pas de compte Heroku, je peux vous créer un compte ici. Et oui, pyAggr3g470r est également multi-utilisateur maintenant!

Categories
Cloud Programming

Heroku contre Google App Engine

Pour introduire ce billet j’annonce que l’application (tout à fait inutile) Cédric, on mange où à midi? peut maintenant être déployée sur Google App Engine (instance de test) et sur Heroku (instance de test). Ceci avec le même code source et sans configurations spécifiques requises. J’ai ainsi pu faire une petite comparaison des deux principales plateformes PaaS. Pour faire court, je préfère le service Heroku.

D’abord je trouve les plateformes PaaS plutôt pratiques pour déployer des applications Web rapidement et sans avoir à se soucier de l’infrastructure. Malheureusement ces services sont assez onéreux. Mais les offres de base (gratuites) permettent de faire des choses assez intéressantes (comme déployer un démonstrateur pour une conférence, une application débile «d’aide à la décision», etc.). Les plateformes IaaS comme Amazon EC2 et Google Compute Engine sont également exorbitantes. Je suis plus intéressé par les services PaaS car ils m’apportent une simplicité de déploiement et forcent à structurer correctement le projet (c’est quand même super de pouvoir déployer avec Git un projet sur différentes plateformes PaaS ainsi que sur son serveur privé, sans avoir à modifier une librairie tierce ou le code). Mettant de côté l’avantage des ressources «élastiques», une plateforme IaaS n’a à mes yeux pas de grands avantages par rapport à une solution classique (serveur privé ou mutualisé). Et finalement une application déployée sur Heroku est cloisonnée dans une stack AWS (Celadon) cedar de base (je ne pense pas que l’offre d’entrée permet d’avoir une instance en Europe).
À noter qu’AWS offre actuellement un service PaaS, Elastic Beanstalk, que je n’ai pas encore testé.

Pour en revenir aux plateformes PaaS, le service Heroku est à mon avis clairement plus simple à utiliser que Google App Engine. Il suffit de comparer les documentations de ces plateformes respectives pour déployer une application Flask. Avec Heroku il est essentiellement requis de connaitre Python (bien sûr si vous déployez une application Python) et Git (un minimum). Tandis que App Engine nécessite l’installation d’un framework (à importer dans le code car il propose un certain nombre de fonctionnalités, notamment pour le stockage de données car sur une plateforme PaaS on ne peut généralement pas écrire de fichiers. Ainsi le framework fournit le Datastore) et quelques fichiers de configurations à placer dans votre projet (c’est donc un peu plus invasif dans votre application et ça ne la concerne pas directement).

Une autre différence notable est la manière dont les librairies tierces de votre application sont gérées. Avec Heroku il faut spécifier les dépendances dans un fichier nommé requirements.txt (comme de coutume pour un projet Python) afin qu’elles soient automatiquement installées côté plateforme. Avec App Engine il faut installer les librairies localement (avec pip) puis les envoyer en même temps que votre application grâce à un script Python inclus dans le SDK. Je pense que cette différence est principalement dû au fait que Heroku est basé sur des conteneurs Linux (LinuX Containers), comme le service Docker. Cette approche me plait bien mais je ne sais pas si les problèmes de sécurité connus de LXC s’appliquent dans un contexte PaaS (l’accès à la console ne se fait que via le client Heroku en utilisateur normal).

Le Dashboard de Google App Engine est plus complet (et bien plus compliqué) que celui d’Heroku, il est possible de contrôler beaucoup de choses (logs, facture très détaillée, charge de l’application, etc.). Mais je pense qu’avec un compte payant des choses se débloquent sur Heroku.

D’un point de vue temps de réponse, Google App Engine semble faire un peu mieux que Heroku, surtout lorsqu’un nouveau processus doit être initié après une période de repos de l’application. Je n’ai pas de mesures précises sur ce point et ça ne me pose pas vraiment de problème. À noter aussi qu’avec Heroku HTTPS est utilisé par défaut.

Finalement, vous pouvez utiliser mon petit projet «d’aide à la décision» pour les indécis comme tutoriel. C’est toujours mieux que le Hello World du tutoriel de Google App Engine. Et vous pourrez ainsi vous faire votre propre idée.

Categories
Cloud Web

Déploiement d’applications Web avec Heroku

Depuis quelques temps je m’intéresse au service PaaS offert par Heroku (équivalent de Google App Engine). Ce service permet de déployer des applications (entre autres: node.js, Ruby, Clojure, Python et Scala) sans se soucier de l’administration du serveur (et donc une partie des problèmes de sécurité). Et cela vraiment simplement et rapidement.

Pour preuve, voici ci-dessous les étapes afin d’avoir une première application Python basée sur Flask, juste après la création d’un compte.

debian:/home/cedric# wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh

cedric@debian:~$ git clone git://github.com/heroku/python-sample.git
Cloning into python-sample...
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 12 (delta 1), reused 11 (delta 0)
Receiving objects: 100% (12/12), done.
Resolving deltas: 100% (1/1), done.

cedric@debian:~$ cd python-sample/

cedric@debian:~/python-sample$ heroku create
Enter your Heroku credentials.
Email: kimble.mandel@gmail.com
Password (typing will be hidden):
Found existing public key: /home/cedric/.ssh/id_rsa.pub
Uploading SSH public key /home/cedric/.ssh/id_rsa.pub... done
Creating peaceful-refuge-5673... done, stack is cedar
http://peaceful-refuge-5673.herokuapp.com/ | git@heroku.com:peaceful-refuge-5673.git
Git remote heroku added

cedric@debian:~/python-sample$ git push heroku master
The authenticity of host 'heroku.com (50.19.85.156)' can't be established.
RSA key fingerprint is 8b:48:5e:67:0e:c9:16:47:32:f2:87:0c:1f:c8:60:ad.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'heroku.com,50.19.85.156' (RSA) to the list of known hosts.
Enter passphrase for key '/home/cedric/.ssh/id_rsa':
Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (12/12), 1.13 KiB, done.
Total 12 (delta 1), reused 12 (delta 1)

-----> Python app detected
-----> No runtime.txt provided; assuming python-2.7.3.
-----> Preparing Python runtime (python-2.7.3)
-----> Installing Distribute (0.6.34)
-----> Installing Pip (1.2.1)
-----> Installing dependencies using Pip (1.2.1
.
.
.
-- snip --
.
.
.
-----> Discovering process types
       Procfile declares types -> web

-----> Compiled slug size: 23.7MB
-----> Launching... done, v4
       http://peaceful-refuge-5673.herokuapp.com deployed to Heroku

To git@heroku.com:peaceful-refuge-5673.git
 * [new branch]      master -> master

Et voici le résultat. Il faut savoir qu’Heroku repose en fait sur le service IaaS EC2 d’Amazon (équivalent de Google Compute Engine). Vous êtes donc dépendant de la qualité de service d’Amazon.

Le service est élastique et de nombreuses configurations sont possibles. J’utilise un compte gratuit. Pour la persistance des données de votre application vous pouvez utiliser l’addon MongoHQ avec 512 Mo de stockage offert.

On va voir ce qu’on peut faire avec ça…

Categories
Cloud

Article When EC2 Hardware Changes Underneath You…

Lorsque le cloud trouve ces limites dans l’abstraction du matériel. Un article fort intéressant.

Categories
Cloud

Au revoir EC2

Mon instance EC2 va fêter son premier anniversaire dans quelques jours. Ça devrait être la fête. Malheureusement je vais devoir la tuer (oui après il faut payer, rendez-vous compte). C’est dommage. D’autant plus que j’attends toujours mon invitation pour GCE! Merci de ne pas me signaler si vous avez déjà votre invitation.

Et dépêchez vous de profiter de près de deux années d’articles de L’essentiel.

Effet de pyAggr3g470r sur une instance EC2 de base.
Effet de pyAggr3g470r sur une instance EC2 de base.
Categories
Cloud Python Virtualization

pyAggr3g470r dans les nuages

Tu veux tester une version de pyAggr3g470r avec près de 40.000 articles dans les nuages? C’est par ici:

python -c "print __import__('base64').b64decode('aHR0cDovL2VjMi0xMDctMjItNi02MS5jb21wdXRlLTEuYW1hem9uYXdzLmNvbToxMjU1Ng==')"

Attention les ressources ne sont pas vraiment… élastiques.

Categories
Cloud Photography

OpenPhoto, ça y est!

Je parlais sur ce billet d’OpenPhoto. Projet bien sympathique mais que je n’arrivais pas à faire fonctionner sur AlwaysData. Et bien le dernier pull a arrangé mes problèmes et mon instance OpenPhoto fonctionne enfin! C’est par ici.

Comme on le voit, c’est assez simple pour le moment mais il y a tout ce qu’il me faut. Et comme je l’avais expliqué l’API est géniale. Exemple:

cedric@debian:~$ GET http://photos.cedricbonhomme.org/photo/1/view.json
{"message":"Photo 1","code":200,"result":{"id":"1",
"appId":"openphoto-frontend","host":"cedricbonhomme.org\/photos",
"title":"Sanga","description":"","key":null,
"hash":"bbc977b2f16a9040702bd02c3b1abc229bf76abe",
"size":"5707","width":"4752","height":"3168","views":"0",
"status":"1","permission":"1","license":"CC BY-NC-SA","dateTaken":"1317010841",
"dateTakenDay":"25",
"dateTakenMonth":"9","dateTakenYear":"2011",
"dateUploaded":"1318535165","dateUploadedDay":"13",
"dateUploadedMonth":"10","dateUploadedYear":"2011",
"pathOriginal":"\/original\/201110\/1318535163-20110925T212041.jpg",
"pathBase":"\/base\/201110\/1318535163-20110925T212041.jpg",
"tags":["","2011","September"],"latitude":"","longitude":""}}

Voici la documentation de l’API.

Pour le moment avec tous les tests déjà effectués sur Amazon AWS ES3 et simple DB, je n’ai toujours rien payé. Cependant sur le forum d’Amazon j’ai trouvé ceci. C’est un peu flippant quand même. Donc actuellement les photos sont hébergées localement. Il est aussi possible d’utiliser DropBox (que je n’ai jamais utilisé). Je passerai peut être à Google Storage, car là au moins on sait qu’on ne peut pas payer plus qu’une certaine somme. Mais bon, maintenant les migrations ne sont plus un problème. Il est même possible d’utiliser le stockage local avec Amazon ou le stockage local avec DropBox. Et même d’avoir la base de données en local avec les photos sur Amazon. Bref, c’est très souple.