Migration depuis Heroku vers Amazon Web Services (beanstalk)

45aaf962ff22d69e4d2cd3c4b91f671f_large

INTERLUDE #1 – INTRODUCTION A HEROKU

Petite introduction: Heroku est un PaaS (Platform As A Service) qui propose donc de coder sans se soucier de l’infrastructure et de la plateforme sous-jacente. La solution offre, clefs en main, les couches “basses” nécessaires pour faire fonctionner un développement: serveur, réseau, stockage, système d’exploitation, librairies et logiciels. Heroku propose 8 languages différents (Ruby, PHP, Node.js, Pyhton, Java, Go, Clojure, Scala)

Heroku propose d’interagir avec ces environnements gràce a Heroku Toolbelt qui est composé d’une CLI et de Git. Sans trop rentrer dans les détails, l’architecture de Heroku s’appuie sur des conteneurs, nommés des Dynos, qui peuvent etre configurés de trois facons (Web, Worker, One-off).

Les bases de données, PostgreSQL, sont elles hébergées sur AWS et utilisent RDS. Pour en savoir plus sur Heroku je vous invite a consulter leur site, sur lequel la documentation est riche, detaillée et simple a apréhender

INTERLUDE #2 – POURQUOI QUITTER HEROKU

La technique ? Non. Le service est excellent et on tombe vite fan du système.

L’argent ? Non. Heroku propose une version gratuite, non viable pour de la production car votre conteneur se met en sommeil apres 30 minutes d’inutilisation, ce qui créé des lenteurs d’accès (quelques secondes à peine) et l’obligation d’etre dans cet état durant 6 heures pour 24 heures. L’option Hobby permet de faire disparaitre cette limitation contraignante pour quelques dollars par mois. Ce n’est donc apparement pas non plus une question de gros sous. Plus de détails ici.

En faite la raison est toute simple. L’ami que j’aide sur ce projet dispose d’un compte AWS avec assez de dollars pour au moins 1 an alors… pourquoi s’en priver…

RECUPERATION DEPUIS HEROKU

Récuperer l’app depuis heroku avec la CLI

Récuperer la database depuis heroku

Premiere étape terminée

J’ ai tout récupéré. Pour commencer, nous allons faire tourner ce code en local. Le premier “probleme” a régler est que, sur heroku, la db n’est pas localisée sur le meme système que la webapp (souvenez vous, elle est sur AWS). Il va donc falloir remédier à cela pour valider le bon fonctionnement en local. Ensuite, sur AWS nous re-paramètrerons une utilisations distante car nous utiliserons aussi RDS qui ne sera pas local a l’instance EC2 Beanstalk.

VALIDATION DE BON FONCTIONNEMENT EN LOCAL

Préparer PostreSQL

Importer la bdd dans PostgreSQL

Linker la configuration de la webapp avec notre base locale

Editer le fichier production.py commenter ces lignes:

et ajouter celles-ci:

A present et depuis le repertoire Django, on doit pouvoir lancer la commande

Et valider le bon fonctionnement de notre site sur http://127.0.0.1:8000

Seconde étape terminée

Le code a été correctement récupéré depuis Heroku et il tourne parfaitement en local.

INTERLUDE – INTRODUCTION A BEANSTALK

Petite introduction: Beanstalk est un hybride entre le IaaS et le PaaS dans le sens où, par défaut, sont but premier est de fournir une infrastructure et une plateforme

PREPARER BEANSTALK LOCALEMENT

Créer un environnement virtuel Python

Activer

Installer django

Vérifier la bonne installation de django

Générer son App

Test et validation

La webapp est accessible sur le port 5000 en local.

Preparer l’App pour beanstalk

Creer l’environnement sur beanstalk

Pousser l’App sur beanstalk

NOTES

Sur l’instance EC2 comment rejouer les actions:

Localisations et fichiers interessants sur l’EC2 beanstalk:

Les incontournables

Liens

Deployer django avec pgsql sur Beanstalk.
Documentation AWS

 

Leave a Reply

Your email address will not be published. Required fields are marked *