Tag Archives: cloud

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…

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.

OpenPhoto

Merci à la personne à l’origine de ce commentaire.

OpenPhoto est le projet que j’attends depuis longtemps. Une sorte de Diaspora de la photo (et aussi hébergé sur github). Il s’agit d’un projet écrit en PHP (ça aurait été le summum en Python) que vous pouvez installer sur votre PC à la maison (veinard), sur votre dedibox, etc. OpenPhoto est très simple à installer (installation sur Ubuntu: 3 minutes) et permet d’héberger vos photos et commentaires soit sur votre serveur (photos et base de données pour les commentaires, soit avec Amazon, soit avec Google Storage (donc en mode cloud).

Je vous montrerai bien ma galerie, mais j’ai quelques problèmes de configuration pour le moment. J’ai déjà envoyé un mail au responsable du projet. Regardez donc cette galerie. C’est ce que je veux. Et OpenPhoto est aussi un framework permettant de développer sa propre galerie. L’application Android est déjà disponible. Ce n’est pas une galerie PHP comme une autre car celle-ci permet vraiment de choisir comment les photos seront stockées et de récupérer les commentaires. L’aspect communautaire aussi est présent car quiconque peut se connecter pour laisser un message via Browser ID de Mozilla. Exemple de page de photo hebergée ici.

Pour le moment j’ai choisi de tout (le code PHP, les photos et la base de données en local) héberger sur AlwaysData. Mais pourquoi pas héberger les photos et la base de données sur Amazon ou Google Storage (avec le code sur AlwaysData)? Qu’en pensez vous? Il faut prendre en compte la liberté, qualité de service ainsi que la confiance. Si j’avais mon propre serveur le seul problème serai la qualité de service.

J’espère bientôt pouvoir me désinscrire de certains services Web…

Quand le ciel se couvre

Dark clouds over How Tun Woods

Ces derniers temps avec la monté en puissance du cloud computing pour le grand public nos applications tendent à disparaîtres et nos PC se transforment en petit espace de stockage (quelques gigaoctets sur un SSD) connectés. Les serveurs d’avant deviennent intelligents et ne se content plus de stocker. Ils nous fournissent applications et données. Applications propriétaires. Données trop publiques.

Un récent billet de Joanna Rutkowska me fait penser à une vieille idée. Dans ces conditions je serai partant pour utiliser quelque chose comme un Chromebook. Mon problème principal de la perte du contrôle des données est presque résolu. La solution est le chiffrement. Le chiffrement protège nos données de toute une série d’acteurs dont nous sommes forcé d’accorder notre confiance.

Le problème: est-ce que les fournisseurs de services seraient prêts à héberger toutes nos données chiffrées (donc inintelligible)? En générant nos clés de chiffrement et en chiffrant côté client les données avant de les envoyer sur le cloud toute cette polémique autour de dropbox n’aurait pas eu lieu. En même temps on pouvait s’y attendre, franchement comment un service comme dropbox ou Google pourrait héberger nos données pour ne rien en faire? Absolument rien, mis à part les stocker. Il n’y aurait donc aucune exploitation possible de ces données, quasiment plus d’intelligences dans ce cloud, juste du stockage. Un service si gentil serait de toute manière sous une licence type AGPL. Sinon où est l’intérêt?
Et cette intelligence sur le cloud, qu’elle est son utilité? Généralement établir notre graphe social (comme le dit Éric Schmidt de manière décomplexée), découvrir nos centres d’intérêts. Ce serait un peu plus compliqué avec un carnet d’adresses chiffré.

Je serai vraiment surpris que dans un avenir plus ou moins proche il soit possible de faire cela avec un Chromebook. Nous avons toutes les technologies et l’expérience requise pour implémenter cette idée, ce n’est que de la cryptographie. Il faudrait adapter un peu quelques applications clientes (pensez au potentiel d’aKonadi). Avec différents couples de clés on pourrait choisir avec qu’elle personne ou groupe(s) de personnes on partage une information Il y a des protocoles cryptographiques spécifiques pour ça. La notion d’espace partagé et surtout public de dropbox est une hérésie. Pour de nombreux types de données (agenda, localisation, numéro de téléphone, etc.) l’utilisateur a un besoin presque naturel de partager à des groupes de différents niveaux de confiance. Confiance relative. Confiance absolue pour le partage public.

Il faut donc garder nos bonnes vieilles applications clientes. Mettre plus de données chiffrées dans ce cloud qui est en train de tous nous baiser. Cela n’exclue pas de garder des applications web-based comme Gmail. Avec la solution de Joanna Rutkowska une application comme Gmail pourrait aussi avoir accès à nos données chiffrées.
De plus conserver les applications clientes ne peut que favoriser les standards et l’interopérabilité. J’aime savoir que Kontact, Evolution et Thunderbird puissent exploiter les mêmes données sur mon cloud, ou alors LibreOffice et KOffice. Avec des applications uniquement en ligne comme Gmail ou Google Docs on risque de perdre en interopérabilité (on sera rattaché à un service) et en qualité. Je trouve surtout ça moins élégant d’un point de vue informatique.
Certaines personnes aiment écrire des logiciels amateurs (par plaisir de comprendre comment fonctionne un ordinateur ou pour un besoin particulier) ou aiment savoir si une mise à jour d’un programme utilisé courrament a changée son comportement. La culture du Do It Yourself a besoin de ça.

Par sécurité (cf. les problèmes d’Amazon, du PSN et bien d’autres) il serait bon de synchroniser par exemple un NAS personnel avec notre petit morceau de cloud. Ce support de stockage devrait disposer (tout comme notre smartphone, tablette et PC portable) des clés appropriées pour garder les données non chiffrées (sécurité oblige, mais si souhaitable à ce niveau on peut utiliser TPM ou TXT). Le PC de bureau peut être connecté localement au NAS. Je pense que sur un PC fixe il est idiot d’utiliser un service cloud alors qu’on a un support de stockage qui peut s’occuper de synchroniser les modifications effectuées depuis ce PC. Si je veux regarder Titanic dans mon salon et qu’il est sur mon NAS non chiffré, pourquoi aller le chercher sur Internet? De même pour un simple fichier (et oui, bientôt avec Google Music vous pourrez écouter dans votre salon de la musique en ligne. La même qui se trouve sur votre disque dur). Par contre si le fichier est modifié, le support de stockage peut s’occuper de faire le chiffrement et la synchronisation. Par la suite on pourra continuer à éditer ce fichier avec un smartphone ou appareil type Chromebook sur le cloud. Pourquoi faire confiance inutilement à toute une flopée de services et gâcher des ressources?
On peut citer la couche d’abstraction d’aKonadi qui est très intéressante pour interagir avec le cloud. aKonadi permet de synchroniser son calendrier ainsi que ces contacts (sur gmail ou serveur personnel de façon transparente). Lorsque j’édite mon calendrier en ligne avec ma tablette mon calendrier KOrganizer est mis à jour sur le PC de bureau. Connexions sécurisées et calendrier sur mon disque dur disponible en mode non connecté (malheureusement le calendrier en ligne est visible pour Google). C’est un peu ce fonctionnement qu’il faudrait généraliser à toutes nos données.

La cryptographie est une arme puissante et incontournable qui nous aidera à conserver notre vie privée.

On pourra lire également ceci.

Ce que je pense de ce que pense Stallman sur le Cloud Computing

Stallman n’est pas paranoïaque. Il a raison sur de nombreux points, tous en fait. Des internautes sacrifient leur vie privée sur l’autel de la facilité.

  • perte du contrôle de nos données;
  • effet de mode, en partie. Le cloud, “C’est plus une attitude qu’autre chose au fond”;
  • les utilisateurs espèrent que “le fournisseur fasse bien son boulot avec les sauvegardes”;
  • les fournisseurs pensent avant tout à ce protéger eux;
  • l’informatique dans les nuages va plaire aux marketeux. Il s’agit surtout de “services” derrières des technologies assez classiques;
  • “’Amazon a banni Wikileaks de son service d’informatique dans les nuages EC2, invoquant, unilatéralement et sans proposer de médiation, le non respect des conditions d’utilisation par le site.”;
  • une décentralisation centralisée.

La réalité est moche.

À lire: