lindev.fr

Aller au contenu | Aller au menu | Aller à la recherche

07 fév. 2016

Vagrant, environnement de développement unifié

Vagrant.png Je souhaite proposer aux différents développeurs d'un projet, un moyen simple d'avoir un environnement le plus proche possible du serveur de production, que ce soit au niveau de la distribution, mais également des versions des outils installés ( Php, Mysql MariaDb, MongoDb, python, uwsgi, etc ... ). Le but étant de mettre en place l'environnement en un minimum de temps possible, mais aussi de permettre aux développeurs de rester sur leur système d'exploitation préféré. (Linux Mac ou même Windows) pour développer.

Première approche

Peut être (certainement) dû à l'effet de mode, j'ai commencé mes tests avec Docker. Ce dernier permet ce genre de chose, mais je trouve la façon de faire un peu complexe ( Liaisons entre les conteneurs, maintenabilité de l’ensemble etc ) , juste pour avoir un environnement de dev ! Il est vrai que cette techno est vraiment intéressante, le partage de conteneurs avec les autres utilisateurs, le versionning grâce à l'union FS et tout ça sans exploser la conso d'espace disque.

Plus simple, vagrant

Puis un ami m'a parlé de Vagrant, une techno que je n'avais pas encore étudié plus que ça. Pour résumer, il n'y a rien de magique, c'est "juste" un écosystème de gestion de VMs , basé sur virtualbox, qui permet de créer/manager des VMs à partir de systèmes de bases disponibles sur le net ( catalogue Vagrant Boxes ) et surtout de provisionner ces VMs.

C'est là que ça devient intéressant, on a donc un système de gestion de VMs compatible Linux,Windows,Mac, permettant une gestion de VMs très efficace, start, stop, freeze, resume, reload etc ... mais surtout, vous permet de monter une VMs configurée selon vos souhaits et ce de plusieurs façons.

Testons avec un simple environnement LAMP

Je vais volontairement aller vite sur les options disponibles, la doc en ligne de Vagrant étant extrêmement clair, je ne vais pas la copier/coller ici

Commencez par installer Vagrant ( pas besoin d'explication pour cette étape triviale )

Système de base

Nous allons travailler sur une Debian Jessie . Commençons par créer un répertoire pour notre projet ( je le nomme lamp )

mkdir lamp && cd lamp
vagrant init debian/jessie64

Dans notre répertoire lamp, nous trouvons maintenant un fichier de configuration de notre environnement nommé Vagrantfile. Nous allons bientôt mettre les mains dedans .

Capture_d_e_cran_2016-02-13_a__14.53.05.png

Le téléchargement est terminé ? oui ? très bien lançons notre "machine" et allons faire un tour dedans .

Lancer la VM et tour du propriétaire

vagrant up

Une fois la machine lancée, prenons la main en ssh

vagrant ssh

Vous voilà connecté à notre machine. Le système est nu. Avez-vous remarqué au lancement de la vm, ces deux lignes :

==> default: Installing rsync to the VM...
==> default: Rsyncing folder: /Users/moi/lamp/ => /vagrant

Par défaut, vagrant synchronise le répertoire local ( dans notre cas /Users/moi/lamp/ ) avec le répertoire /vagrant présent à la racine du système de fichiers de la VM.
Nous pouvons bien entendu ajouter d'autres répertoires ( voir le fichier de configuration Vagrantfile ligne: config.vm.synced_folder "../data", "/vagrant_data" ).

Retournons sur notre machine hôte ( Cmd + D )

LAMP

Linux ( Ok ça c'est fait ), Apache ( à installer ), Mysql/MariaDB ( à installer ), Php ( à installer ).
Bon on sait ce qu'il nous reste à faire. Mettons les quelques lignes nécessaires à l'installation de ces derniers dans un script bash. Éditons donc dans le répertoire lamp, un fichier que nous nommerons bootstrap.sh

Voici le contenu:

#!/usr/bin/env bash

#Login par defaut : root et pwd : rootpass ( à modifier bien évidemment )
debconf-set-selections <<< 'mysql-server-5.5 mysql-server/root_password password rootpass'
debconf-set-selections <<< 'mysql-server-5.5 mysql-server/root_password_again password rootpass'

apt-get update
apt-get install -y apache2
apt-get install -y mysql-server
apt-get install -y php5 php5-mysql php-pear


if ! [ -L /var/www ]; then
  rm -rf /var/www
  ln -fs /vagrant /var/www
fi

Éditons ensuite le fichier Vagrantfile, et en dessous de la ligne config.vm.box = "debian/jessie64" ajouter :

config.vm.provision :shell, path: "bootstrap.sh"

Ne reste plus qu'à provisionner la VM

vagrant reload --provision

Capture_d_e_cran_2016-02-13_a__14.55.18.png

Vous voilà avec un lamp de base, mais comment communiquer facilement avec ?

Le réseau

Il y a plusieurs solutions selon votre besoin.

  • Natter un port de votre machine hôte vers la VM
  • Créer un bridge avec une des vos interfaces pour que la VM soit présente comme n'importe quel autre poste sur votre réseau local
  • Créer un réseau privé permettant à la machine hôte d’accéder à la VM , tout en restant inaccessible depuis l'extérieur pour les autres postes ( solution retenu dans mon cas ).

Éditons le fichier de configuration pour activer ce mode. dé-commenter/compléter cette ligne :

config.vm.network "private_network", ip: "192.168.33.10"

Relançons notre vm

vagrant reload

Testons notre serveur Apache, ouvrez un navigateur, et entrez l'ip de votre vm : http://192.168.33.10

Et là ... vous avez un magnifique "404 not found" !!!.
Normal, le vhost par défaut d'apache cherche ses sources dans le répertoire /var/www/html . et si vous avez bien observé, dans le fichier bootstrap.sh, nous avons ces lignes :

if ! [ -L /var/www ]; then
  rm -rf /var/www
  ln -fs /vagrant /var/www
fi

Qui a pour but de mettre le répertoire "vagrant" ( partagé entre l'hôte et la vm ) accessible ( via un lien symbolique ) vers /var/www . Il nous suffit donc de créer un répertoire nommé html dans notre répertoire de projet, lamp ( sur la machine hôte ).

Donc, sur notre machine hôte, dans notre répertoire lamp :

mkdir html && cd html
echo '<?php echo phpinfo();' > index.php

Relançons notre vm

vagrant reload

Maintenant allons rafraichir notre navigateur . Vous devriez avoir la belle page de phpinfo qui s'affiche . Capture_d_e_cran_2016-02-13_a__13.54.36.png

NFS

C'est magnifique, mais si vous ajoutez des fichiers depuis la machine hôte dans le répertoire html, ces derniers ne seront pas accessibles ( synchronisés ) sur la VM. Il faudra pour celà lancer la commande

vagrant rsync-auto

Pas très pratique. Je me suis donc tourné vers le protocole NFS qui est pris en charge en natif avec vagrant ( attention.. ne fonctionne pas avec Windows ).
Éditons notre fichier Vagrantfile et ajoutons ces quelques lignes avant de relancer notre vm

  config.vm.synced_folder ".", "/vagrant",
    :nfs => true

Relançons la VM

vagrant reload

Vagrant va vous demander le mot de passe sudo, afin de modifier pour le fichier /etc/exports.
Afin que le mot de passe ne soit pas demandé à chaque démarrage, vous pouvez soit:

  • Ajouter des règles dans le fichier de config sudo ou ...
  • Renseigner une bonne fois pour toute votre fichier exports et indiquer à vagrant qu'il n'a rien à faire . ( voir les options NFS ).

Conclusion

Voilà pour le premier tour d'horizon de Vagrant, nous avons dans nos main un système de gestion de VM bien ficelé, doté de nombreuses autres options, ( snapshots/restauration, share, ... ) je ne peux que vous conseiller d'aller faire un tour sur le site officiel pour découvrir les différentes options qui s'offrent à vous. Enfin, pour gérer vos environnements, je vous conseil de versionner votre projet ( dossier lamp dans notre exemple ) avec Git par exemple, car c'est grâce aux fichiers de ce répertoire que vous serez en mesure de remonter/partager une VM configurée à l'identique sans aucun effort et en un minimum de temps.

23 janv. 2016

Python pip et son cache local

Afin d'éviter de re-télécharger les paquets pour chaque projet nous allons voir ce petit truc extra simple qui est d'activer le cache local de pip.
Le principe est simple, la première fois que vous installez un paquet, ce dernier est téléchargé, puis mis en cache.
La seconde fois ( s'il s’agit de la même version ), pip va simplement l'installer depuis le cache.

Ok, ça ne va pas vous changer la vie, mais moi je trouve ça sympa à utiliser, surtout lorsque vous devez installer des gros paquets avec une connexion d’hôtel faiblarde, ça peut vous faire gagner de précieuses minutes .

Configuration de PIP

Commençons par éditer le fichier de configuration de pip

vim ~/.pip/pip.conf

Ajouter dans la section "global":

[global]
download-cache=/usr/local/pip/cache

enfin on donne les droits d'écriture

mkdir -p /usr/local/pip/cache
chmod -R 755 /usr/local/pip/cache

Deuxième méthode un peu plus courte

Simplement ajouter dans votre fichier de profil : ~/.bash_profile

export PIP_DOWNLOAD_CACHE=$HOME/.pip_download_cache

Voilà pour ce micro billet.

Bon weekend .

15 sept. 2014

Réparer son virtualenv aprés un update Systéme/Libs

Après une belle maj de votre système, vous avez, au moment de vous remettre au travail, un sympathique message du genre

ImportError: No module named datetime

detatime !! Cette lib fait pourtant partie du standard de python ! Le fait est que lorsque l'on met à jour python, les liens utilisés à la création du venv sont hs !

Ici c'est la lib datetime qui a été remonté, mais ça peu être n'importe laquelle ..

Solution

Il ne m'a pas fallu longtemps pour résoudre ce problème tout bête, ( beaucoup de cas similaires sur le net ).

Réinitialiser le virtualenv

Par exemple avec mon venv nommé foo

virtualenv /home/cdsl/.virtualenvs/foo
New python executable in /home/foo/.virtualenvs/creasoft3/bin/python
Installing setuptools............done.
Installing pip...............done.

Et voilà ..

17 janv. 2014

Recrutement Développeur web Python/PHP

CDI Développeur PHP/Python Nord - Comines

comines2.png

Lire la suite...

02 oct. 2013

Mezzanine épisode 2

mezzanine.png Nous avons vu dans un précédent billet, comment installer le CMS mezzanine et créer un nouveau projet.
Après s'être familiarisé avec son utilisation, voyons comment customiser notre projet.

Organisation des Thèmes

Un thème mezzanine = une app ( app: répertoire avec un fichier nommé init.py dedans )

Créons notre thème montheme

mkdir montheme && touch montheme/__init__.py

Puis nous allons le déclarer dans le fichier settings.py , au début de le liste INSTALLED_APPS

INSTALLED_APPS = (
    "montheme", # thème à utiliser
    "django.contrib.admin",
    ...

Bien, maintenant nous allons créer la structure de notre thème, à savoir, créer les répertoires de fichiers qtatiques ("static/") et celui des templates ("templates/")

mkdir -p montheme/static/css && mkdir montheme/static/img && mkdir montheme/static/js
mkdir -p montheme/templates/pages/menus && mkdir montheme/templates/includes

Nous voilà avec un superbe template ...... qui ne fait rien !

Il ne nous reste donc plus qu'à créer nos feuilles de styles et fichiers Html pour surcharger le thème par défaut .

Récupérer le thème par défaut

Pour avoir une base fonctionnel, nous allons récupérer les templates et fichiers statiques du thème mezzanine par défaut.

Toujours à la racine de notre projet,

python manage.py collectstatic
python manage.py collecttemplates

Vous vous retrouvez avec deux nouveaux répertoires templates et static qui contiennent donc respectivement les templates et fichiers statiques nécessaires au fonctionnement de base de Mezzanine.

/!\ Attention : si vous laissez tel quel les répertoires, votre template ne sera jamais pris en compte car les répertoires templates et static à la racine du projet sont prioritaires . ( Scannés en premier par Django )
Renommons donc ces répertoires afin de les rendre inactifs

mv templates templates_orig
mv static static_orig

Création de notre thème

Avant d'entrer dans le vif du sujet, il faut bien comprendre comment Mezzanine cherche ses templates.

Par défaut, Mezzanine cherche le template, qui a le même nom que la page demandée. Par exemple, dans l'interface admin, je crée une page dont le titre est "Authors" et le "slug" ( non .. pas la limace, mais une url propre ) : "About/authors", mezzanine va chercher une des correspondances suivantes :

  1. pages/about/authors.html
  2. pages/about/authors/about.html
  3. pages/about/about.html
  4. pages/about.html
  5. pages/page.html


page.html étant la page générique qui sera appelée en dernier recours, c'est cette page qui est disponible "entres-autres" dans les templates du thème par défaut.
Voilà notre point de départ, nous allons donc commencer par copier cette page dans notre thème, qui sera aussi notre page par défaut.

cp templates_orig/pages/page.html montheme/templates/pages/

Si on édite le fichier page.html, nous pouvons voir qu'il s'agit juste d'une structure d'affichage qui s’intègre dans le template base.html .
Copions le également.

cp templates/base.html montheme/templates/

Feuilles de style et javascript

Afin de ne pas perdre les styles et fonctions javascript de base, nous allons créer les nôtres ( au besoin évidemment )

touch montheme/static/css/montheme.css
touch montheme/static/js/montheme.js

Puis modifiez les blocs suivants pour ajouter montheme.css et montheme.js

block compress css
<link rel="stylesheet" href="{% static "css/montheme.css" %}">
block compress js
<script src="{% static "js/montheme.js" %}"></script>

Conclusion

Nous voilà avec un thème qui pour le moment ne fait que reprendre celui par défaut, mais il est en place ! Il ne reste plus qu'à personnaliser les fichiers page.html et base.html dans un premier temps à votre gout .
Si vous souhaitez allez plus loin sur l'intégration des différents éléments dans votre thème, il suffit de suivre le même principe .

  1. Copier les pages concernées du thème original dans votre thème
  2. Les adapter à votre gout ! c'est tout .

Par exemple, si je souhaite modifier le menu en entête, je vais chercher le fichier dropdown.html qui se trouve dans le répertoire templates/pages/menus/ , je le copie dans mon thème montheme/templates/pages/menus/ et je peux travailler dessus en toute liberté .

N'hésitez pas à activer django_debug_toolbar ( dans votre fichier settings.py ) pour vous aider.

Ch.

- page 1 de 3