lindev.fr

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

07 juin 2017

Environnement de développement complet avec Docker

Qu'allons nous voir

docker-logo.jpg Nous allons voir comment mettre sur pied avec Docker un environnement de développement Web complet ( LAMP ) en quelques minutes ( si l'on compte uniquement le temps de déploiement, et non la lecture de ce post. ).

Mais surtout , rendre cet environnement facilement configurable pour qu'il réponde à vos attentes.

Au programme, nous aurons donc 3 conteneurs


Petit plus, nous aurons à disposition, un fichier de configuration permettant l'utilisation de la fonction mail() de php.

Pour lancer facilement ces conteneurs Docker, nous utiliseront l'outil docker-compose, qui permet en un seul fichier de déclarer notre environnements et bien plus encore.

Pour les plus pressés : Si vous ne souhaitez pas créer les répertoires et fichiers de conf à la main en suivant tout le billet, vous pouvez directement cloner le projet puis lancer ( Après avoir installé Docker sur votre machine évidemment ). Rendez-vous tout en bas de cette page, dans la section Go go go.

Installation de Docker et docker-compose

Franchement, il n'y a rien de compliqué, je ne vais pas détailler spécialement la méthode , juste vous donner les liens pour les différents systèmes.
Après, il suffit de suivre.

Docker CE

Docker-Compose

Bonne nouvelle pour les utilisateurs de Mac & Windows, l'outil est automatiquement installé avec Docker.

Pour les utilisateurs Linux, je conseille la commande pip

sudo pip install docker-compose

Le projet LAMP

Parfait, nous avons tout les outils nécessaires pour atteindre notre objectif.
Commençons par créer un répertoire qui contiendra l’ensemble des fichiers de configuration et le code source de nos futurs projets Web .

mkdir -p dockerlamp/www dockerlamp/docker/apache/vhosts dockerlamp/docker/mysql dockerlamp/docker/php

Voici en résumé ce que ça donne :

dockerlamp
├── docker
│   ├── apache
│   │   └── vhosts
│   ├── mysql
│   ├── php
└── www

Nous aurons donc les fichiers de configuration dans le répertoire docker/ et le code source sera dans le répertoire www/

docker-compose.yml

Je vais pas tourner autour du pot, je vais tout de suite vous donner le contenu complet du fichier docker-compose.yml, nous verrons ensuite les différents points à compléter.

Créez donc le fichier docker-compose.yml à la racine du répertoire dockerlamp/

# Adopt version 2 syntax:
#   https://docs.docker.com/compose/compose-file/#/versioning
version: '2'

volumes:
    database_data2:
        driver: local

services:
###########################
# Setup the Apache container
###########################
    httpd:
        container_name: dockerapache_httpd_1
        restart: always
        image: httpd:2.4.25
        ports:
            - 80:80
        volumes:
            - ./docker/apache/httpd.conf:/usr/local/apache2/conf/httpd.conf
            - ./docker/apache/vhosts/:/usr/local/apache2/conf/vhosts
        volumes_from:
            - php

###########################
# Setup the PHP container
###########################
    php:
        container_name: dockerapache_php_1
        restart: always
        build: ./docker/php/
        expose:
            - 9000
        volumes:
            - ./www/:/usr/local/apache2/htdocs
            - ./docker/php/ssmtp.conf:/etc/ssmtp/ssmtp.conf:ro
            - ./docker/php/php-mail.conf:/usr/local/etc/php/conf.d/mail.ini:ro


###########################
# Setup the Database (MySQL) container
###########################
    mysql:
        container_name: dockerapache_mysql_1
        restart: always
        image: mysql:5.6.36
        expose:
            - 3306
        volumes:
            - database_data2:/var/lib/mysql
            - ./docker/mysql/conf-mysql.cnf:/etc/mysql/mysql.conf.d/conf-mysql.cnf:ro
        environment:
            MYSQL_ROOT_PASSWORD: secret
            MYSQL_DATABASE: project
            MYSQL_USER: project
            MYSQL_PASSWORD: project

Configuration Apache

Afin de configurer finement le service Apache, nous allons récupérer le fichier httpd.conf et le déposer dans le répertoire dockerlamp/docker/apache/

Voici le lien de téléchargement httpd.conf

La seule modification faite à ce fichier ( comparé à la version d'origine ) est la prise en charge des virtualhosts.

Nous allons par conséquent également récupérer le virtualhost par défaut et le placer dans le répertoire dockerlamp/docker/apache/vhosts/

Voici le lien de téléchargement 000-default.conf


Pour les curieux, si vous éditez le fichier 000-default.conf, vous verrez que l'on utilise le module proxy d'apache pour gérer les sources php . Nous passons ces sources au service nommé "php" sur le port 9000.

Nous en avons terminé avec le service apache . Passons au service php.

Configuration php-fpm

Contrairement au service apache, le conteneur php-fpm doit être modifié, pour ne serait-ce qu'installer les extensions.
Nous allons donc créer un fichier Dockerfile, qui contiendra toutes les instructions pour finaliser notre container .

La bonne pratique

J'aurais pu simplement créer une image du container sur dockerHub et la mettre à disposition, mais pour partager une image modifiée, la bonne pratique consiste à utiliser comme base l'image officielle ( php ), puis d'ajouter explicitement les changements à apporter dans un DockerFile.

Ce qui vous permet d'être certain que l'image finale n'est pas corrompue.

Dockerfile

créez le fichier Dockerfile dans le répertoire dockerlamp/docker/php/, comme précisé dans docker-compose.yml.

FROM php:5.6-fpm

# install the PHP extensions we need
RUN set -ex; \
	\
	apt-get update; \
	apt-get install -y \
		libjpeg-dev \
		libpng12-dev \
                libmcrypt-dev \
                ssmtp \
	; \
	rm -rf /var/lib/apt/lists/*; \
	\
	docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr; \
	docker-php-ext-install gd mysqli opcache pdo_mysql json mcrypt; \
        pecl install -o -f xdebug redis \
        && rm -rf /tmp/pear \
        && echo "extension=redis.so" > /usr/local/etc/php/conf.d/redis.ini \
        && echo "zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20131226/xdebug.so" > /usr/local/etc/php/conf.d/xdebug.ini; 
# TODO consider removing the *-dev deps and only keeping the necessary lib* packages

# set recommended PHP.ini settings
# see https://secure.php.net/manual/en/opcache.installation.php
RUN { \
		echo 'opcache.memory_consumption=128'; \
		echo 'opcache.interned_strings_buffer=8'; \
		echo 'opcache.max_accelerated_files=4000'; \
		echo 'opcache.revalidate_freq=2'; \
		echo 'opcache.fast_shutdown=1'; \
		echo 'opcache.enable_cli=1'; \
	} > /usr/local/etc/php/conf.d/opcache-recommended.ini

RUN { \
                echo '[xdebug]'; \
                echo 'xdebug.default_enable = 0'; \
        } >> /usr/local/etc/php/conf.d/xdebug.ini


RUN { \
        echo 'error_reporting  =  E_ALL'; \
        echo 'log_errors = On'; \
        echo 'display_errors = Off'; \
    } > /usr/local/etc/php/php.ini

CMD ["php-fpm"]
EXPOSE 9000

php7-fpm : Si vous préférez une autre version de php, il vous suffit de la changer sur la première ligne ( ex : FROM php:7.1.5-fpm ).
Toutes les versions sont listées ici.

fonction mail()

Puisque nous utilisons le service php à l'intérieur d'un container, seul ce service est disponible ( bien qu'il soit possible de lancer plusieurs services dans un même conteneur, cette méthode n'est pas conseillée ), le service sendmail n'est pas disponible.

Pour palier à ce problème, nous allons utiliser ssmtp. Cet utilitaire ne fait que rediriger les mails vers un serveur SMTP externe.
Pour le configurer ( l'activer au sein de php et définir quel serveur SMTP utiliser ), nous allons ajouter deux fichiers dans le répertoire dockerlamp/docker/php/

  • php-mail.conf
  • ssmtp.conf
php-mail.conf

Ce fichier de configuration ( chargé comme un php.ini supplémentaire ) ne fait que surcharger le chemin de l’exécutable sendmail afin d'utiliser ssmtp.

[mail function]
sendmail_path = "/usr/sbin/ssmtp -t"
ssmtp.conf

Ce fichier vous permet de définir quel serveur SMTP utiliser pour envoyer vos mails.
Par exemple, pour utiliser un compte Gmail:

mailhub=smtp.gmail.com:587
[email protected]
AuthPass=mypassword

FromLineOverride=YES
hostname=dockerdev.foo.net
UseSTARTTLS=YES

Seules les 3 premières lignes sont à adapter selon votre cas.

Nous en avons terminé avec la configuration de php-fpm. Passons à Mysql

Configuration Mysql

C'est presque le service le plus simple... dans le fichier docker-compose, nous avons défini des variables d'environnements, qui spécifient le mot de passe du compte root, une base de données à créer avec un utilisateur associé (login et mot de passe) .

Par la suite, si vous devez ajouter une nouvelle base de données, deux possibilités .

  1. Ajouter les informations dans le fichier docker-compose, et relancer le conteneur
  2. Se connecter en root sur le service mysql et créer manuellement la base de données et son utilisateur .

Nous allons créer le fichier conf-mysql.cnf, dans le répertoire dockerlamp/docker/mysql/ ce fichier est automatiquement monté dans le conteneur Mysql à son démarrage et permet donc de modifier simplement la configuration de mysql .

Par exemple, si l'on souhaite modifier la variable sql_mode

[mysqld]  
sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

Note : Vous pouvez laisser ce fichier vide si vous n'en avez pas l'utilité pour le moment. Mais il doit être présent dans le répertoire mysql !

Notre environnement LAMP est maintenant prêt !

Lancer l'environnement LAMP

Puisque nous avons configuré notre environnement via un fichier docker-compose.yml, nous allons évidemment utiliser la commande docker-compose pour le lancer.
Placez-vous à la racine du projet dockerlamp/

docker-compose up -d

Cette commande va construire les volumes, les interfaces réseaux, télécharger les images nécessaires, construire les conteneurs si besoin ( via le Dockerfile ) et enfin ... les exécuter en tache de fond . Oui oui .. tout ça en une seule commande .. le pied!

Le test

Nous allons tester notre stack, apache et php.

Créez deux fichiers dans le répertoire www/

  • info.php
  • index.html
info.php
<?php 
echo phpinfo();
index.html
<h1>Hello World</h1>

Enfin ouvrez un navigateur et entrez ces URLs :

Vous devriez normalement voir un magnifique Hello World, et la page d'infos de php ! Selection_999_057_.png

Un vrai projet

Je ne vais pas vous laisser avec un simple phpinfo() et un Hello World !!
Nous allons aller au bout des choses, en installant par exemple un petit Drupal.

L'objectif est d'installer Drupal et qu'il soit accessible ( sur votre machine ) depuis l'url http://drupal.local/


Le Vhost

Afin de pouvoir utiliser un nom de domaine locale, ( drupal.local ), il faut auparavant renseigner le fichier hosts, pour le déclarer .

Linux et Mac
sudo sh -c "echo '127.0.0.1   drupal.local' >> /etc/hosts"
Windows

Pour Windows vous devez ouvrir le fichier c:\Windows\System32\Drivers\etc\hosts en administrateur avec NotePad et y ajouter la ligne :

127.0.0.1   drupal.local

Maintenant, nous allons créer notre vhost afin qu'Apache sache quoi faire lorsqu'il reçoit les requêtes avec le nom de domaine drupal.local.

Editer le fichier dockerlamp/docker/apache/vhosts/drupal.conf

<VirtualHost *:80>
        ServerAdmin [email protected]
        ServerName drupal.local

        <Directory />
            AllowOverride All
            Require all granted
        </Directory>

        DocumentRoot "/usr/local/apache2/htdocs/drupal"
        <Directory "/usr/local/apache2/htdocs/drupal">
                Options Indexes FollowSymLinks
                AllowOverride All
                Require all granted
        </Directory>


    <FilesMatch \.php$>
        # 2.4.10+ can proxy to unix socket
        # SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost/"

        # Else we can just use a tcp socket:
        SetHandler "proxy:fcgi://php:9000"
    </FilesMatch>

</VirtualHost>

On a donc déclaré le nom de domaine à Apache, en lui spécifiant de pointer sur le répertoire drupal/

Les sources

Puisque nous avons demandé à Apache de pointer sur le répertoire drupal/, nous allons télécharger les sources de Drupal dans ce répertoire qui lui-même se trouve dans le répertoire dockerlamp/www/

cd www
wget https://ftp.drupal.org/files/projects/https://ftp.drupal.org/files/projects/drupal-8.3.2.tar.gz
tar xzf drupal-8.3.2.tar.gz 
mv drupal-8.3.2 drupal
mkdir -p drupal/sites/default/files/translations && chmod -R 777 sites/default/files/translations
chmod -R 777 drupal/sites/default/files
touch drupal/sites/default/settings.php && chmod 777 drupal/sites/default/settings.php

Enfin, pour que le conteneur Apache prenne en considération notre nouveau vhost, nous allons redémarrer notre stack

docker-compose restart

L'installation

Pour l'installation, il suffit de pointer sur notre nom de domaine local et suivre les instructions

http://drupal.local/

Arrivé à l'installation de la base de données, remplissez le formulaire comme ceci ( Base de données déclarée dans le fichier docker-compose.yml ),

  • Nom de la base de données : project
  • Utilisateur : project
  • Mot de passe : project
  • Et dans options avancés > Hôte : mysql


Selection_999_058_.png

Après cette étape, Drupal s'installe tranquillement sur votre environnement
Selection_999_059_.png
Remplissez les formulaires durant l'installation, vous devriez rapidement arriver sur la page d'accueil de votre Drupal fraîchement installé .

Selection_999_060_.png Selection_999_061_.png

Conclusion

Vous avez à disposition un environnement de développement complet comme démontré avec Drupal.

Pour chaque projet vous devez donc

  1. Créer un domaine local dans votre fichier hosts
  2. Créer la configuration du virtualHost pour apache
  3. Récupérer les sources et les placer dans le répertoire www/
  4. Relancer la stack LAMP via docker-compose

Voici quelques outils / lignes de commandes pour vous aider à travailler, "debugger".

Vous trouverez ces petits scripts dans le répertoire tools/ du dépôt dockerlamp.

Ces scripts ne représentent qu'une base pour vous aider à travailler, je vous laisse maintenant parcourir la documentation de Docker pour comprendre les différentes commandes / configurations utilisées dans ce billet.

N’hésitez pas à poser des questions si besoin.

Créer un dump d'une base de données

dump_sql.sh

docker exec dockerapache_mysql_1 /usr/bin/mysqldump --databases -uroot -psecret $DATABASE > $DATABASE.sql

Restaurer/Importer une base de donnée depuis un dump sql

restore_sql.sh

cat $DUMP | docker exec -i dockerapache_mysql_1 /usr/bin/mysql -uroot -psecret

Afficher les logs Apache en temps réel ( Pour débugger )

logs.sh

docker logs --tail 100 -f dockerapache_httpd_1 

Afficher les ressources utilisées par les conteneurs sur votre machine

stats.sh

docker stats --format "table {{.Container}}\t{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}"

Selection_999_062_.png

Go go go

On clone l'environnement

git clone https://[email protected]/cdesaintleger/dockerlamp.git && cd dockerlamp

On Configure le smtp

cp docker/php/ssmtp.conf.dist docker/php/ssmtp.conf && vim docker/php/ssmtp.conf

On lance la stack

docker-compose up -d

28 déc. 2016

HAProxy LetsEncrypt et Varnish en front .. rien que ça

L'objectif final

Avoir l'ensemble de ses sites accessibles en https, avec des certificats letsencrypt ( gratuits et surtout renouvelés automatiquement ) et un serveur de cache ( varnish ) pour augmenter la capacité de charge ( bref optimiser les perfs des sites ) pour enfin passer le relais au backend ( Apache, Nginx .. peu importe ).

network_diagram_user_haproxy_varnish_apache.png

le hic

Il y en a toujours un ... et pas des moindres cette fois, varnish ne gère pas l'https !

La solution - TLS Termination Proxy

L'utilisation d'un proxy ( HAProxy ) pour gérer les transactions Https, puis relayer en clair les requêtes vers varnish qui à son tour si nécessaire va relayer les requêtes au(x) serveur(s) ( Apache/Nginx/... )

Plusieurs avantages à cette solution ( Terminaison SSL ), soulager les serveurs finaux ( Apache/Nginx ... ) de la gestion du SSL et surtout pour nous admins, nous simplifier la tâche pour ce qui est de la gestion des certificats.

Dans ce billet

Dans ce billet, je ne vais parler que de HAProxy et letsencrypt pour commencer, varnish étant un assez gros morceau, il fera l'objet d'un second billet.

Mise en place de la situation

Vous pouvez utiliser un seul et même serveur pour héberger l'ensemble de ces services ... mais franchement ça ne devrait jamais être le cas ! Donc pour ce billet nous allons partir du principe que nous possédons 2 serveurs .

Le premier pour héberger HAProxy et Varnish ( 10.0.0.1 ) et le second pour héberger le serveur HTTP ( 10.0.0.2 )

Les deux serveurs sont sous Debian 8 (Jessie).

Serveur HAProxy

Commençons par Installer HAProxy ( plus quelque trucs utils dans ce "tuto" ) ... qui se fait simplement par

apt install haproxy bc vim 

Commençons par copier le fichier de configuration par defaut

cd /etc/haproxy/
cp haproxy.cfg haproxy.cfg.orig


Maintenant nous pouvons éditer le fichier /etc/haproxy/haproxy.cfg

vim /etc/haproxy/haproxy.cfg

Remplacer tout le contenu par :

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL). This list is from:
        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

        maxconn 2048
        tune.ssl.default-dh-param 2048

defaults
        #log    global
        log     /dev/log local0
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

        option forwardfor
        option http-server-close


#################################

frontend www-http
        bind *:80
        mode http

        #option httpclose
        option forwardfor
        option httplog
        option dontlognull

        reqadd X-Forwarded-Proto:\ http
        default_backend www-backend


frontend www-https
        bind *:443 ssl crt /etc/haproxy/certs/
        mode http
        reqadd X-Forwarded-Proto:\ https

        #option httpclose
        option forwardfor
        option httplog
        option dontlognull

        acl letsencrypt-acl path_beg /.well-known/acme-challenge/
        use_backend letsencrypt-backend if letsencrypt-acl

        default_backend www-backend


backend www-backend

        #option httpclose
        option forwardfor

        http-request set-header X-Forwarder-Port %[dst_port]
        redirect scheme https if !{ ssl_fc }
        server www-1 10.0.0.2:80 check

backend letsencrypt-backend
        server letsencrypt 127.0.0.1:54321


listen stats *:1936
        stats enable
        stats uri /
        stats hide-version
        stats auth username:password

Comme vous l'avez certainement remarqué, nous allons chercher les certificats dans le répertoire /etc/haproxy/certs/ qui n'éxiste pas encore.
Créons le

sudo mkdir /etc/haproxy/certs
sudo chmod -R go-rwx /etc/haproxy/certs

Voilà pour HAProxy, nous verrons ensuite dans l'interface de statistics si tout est ok .

Letsencrypt et certbot

Pour la génération des certificats, nous allons utiliser l'outil certbot .
Pour l'installer nous allons devoir activer ( si ce n'est déjà fait ) le dépôt BlackPorts de Debian

sudo echo 'deb http://ftp.debian.org/debian jessie-backports main' > /etc/apt/sources.list.d/blackports.list
apt update

On install certbot depuis ce dépôt

apt-get install certbot -t jessie-backports

Afin d'initialiser letsencrypt, nous allons le lancer une première fois

certbot certonly

Celà ne va pas aboutir, c'est normal, c'est juste pour qu'il crée les répertoires de base.

Celà ne vous a pas échappé, le port 80 est déjà utilisé par HAProxy, et ne peu donc être utilisé par Letsencrypt pour générer ou renouveler un certificat.
L'idée de couper HAProxy le temps de cette action est inconcevable, nous allons simplement utiliser un autre port. ( ici : 54321 )

Pour ne pas avoir à le spécifier à chaque commande, nous allons mettre en place un petit fichier de configuration pour définir quelques paramètres qui ne changent pas . ( ce qui va nous permettre de raccourcir nos lignes de commandes plus tard ).

sudo cd /etc/letsencrypt/ && vim cli.ini

Voici le contenu

# This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Certbot with
# "--help" to learn more about the available options.

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# Uncomment and update to register with the specified e-mail address
email = [email protected]

# Uncomment to use a text interface instead of ncurses
text = True

standalone-supported-challenges = http-01

Afin de tester l'ensemble de notre configuration, nous allons générer notre premier certificat ( manuellement ) .
Imaginons que le domaine soit "lindev.fr" :

sudo certbot certonly --standalone --http-01-port 54321 -d lindev.fr -d www.lindev.fr
sudo cat /etc/letsencrypt/live/lindev.fr/fullchain.pem /etc/letsencrypt/live/lindev.fr/privkey.pem > /etc/haproxy/certs/lindev.fr.pem
sudo service haproxy restart

Bien entendu, il faut que le nom de domaine "lindev.fr" et "www.lindev.fr" pointent sur l'ip de mon serveur ( HAProxy ).

HAProxy est maintenant prêt . Je suppose que le backend ( Nginx ou Apache ) est déjà configuré avec un vhost écoutant sur le port 80 pour le domaine "lindev.fr et www.lindev.fr".

Et voilà le résultat. Capture_d_e_cran_2017-01-03_a__21.15.37.png

Renouvellement automatique

Nous allons maintenant faire en sorte que les certificats LetsEncrypt se régénèrent automatiquement avant expiration et ce tant qu'à faire sans intervention nécessaire d'une admin sys sur le serveur HAProxy.

Le script

Pour celà j'ai concocter un petit script batch générique qui fait très bien le travail.

sudo mkdir /root/scripts & cd /root/scripts
vim /root/scripts/renew_all.sh

Le voici

#!/bin/bash

#Configuration variables
certbot_bin="/usr/bin/certbot"
haproxy_pem_path="/etc/haproxy/certs"
http_01_port='54321'
exp_limit=30

#Then, create domain.pem containing fullchain et privkey for haproxy
for domainconf in $(ls /etc/letsencrypt/renewal/); do
        domain=${domainconf%.conf}

        cert_file="${haproxy_pem_path}/${domain}.pem"
        exp=$(date -d "`openssl x509 -in $cert_file -text -noout|grep "Not After"|cut -c 25-`" +%s)
        datenow=$(date -d "now" +%s)
        days_exp=$(echo \( $exp - $datenow \) / 86400 |bc)

        if [ "$days_exp" -gt "$exp_limit" ] ; then
                echo "[${domain}] : The certificate is up to date, no need for renewal ($days_exp days left)."
                #exit 0;
        else
                echo "The certificate for $domain is about to expire soon. Starting Let's Encrypt (HAProxy:$http_01_port) renewal script..."
                $certbot_bin certonly --standalone --renew-by-default --http-01-port $http_01_port -d ${domain} -d www.${domain}
                cat /etc/letsencrypt/live/${domain}/fullchain.pem /etc/letsencrypt/live/${domain}/privkey.pem > ${haproxy_pem_path}/${domain}.pem
        fi
done

# At the end, reload haproxy
echo "$(date +%c) Reload haproxy"
/usr/sbin/service haproxy reload

Les deux seuls paramètres que vous pourriez vouloir changer sont :

  • http_01_port='54321'
  • exp_limit=30



A savoir, le port utiliser pour la génération des certificats, et la limite (en jours) à partir de laquelle vous souhaitez régénérer un certificat .

sudo chmod +x /root/scripts/renew_all.sh
sudo -s
crontab -e

On ajoute cette ligne dans la crontab ( afin de vérifier chaque jour les certificats à régénérer )

@daily /bin/bash /root/scripts/renew_all.sh 2>&1 | mail -s "[SSL Lindev] Vérification des certificats SSL HAProxy" [email protected]

Et voilà chaque jour, le script sera exécuté et vous recevrez un petit mail résumant le temps restant pour chaque certificat et potentiellement les logs de régénération s'il y en a eu.

Nouveau domaine à gérer

Imaginons que vous souhaitez gérer un autre nom de domaine, vous devrez la première fois créer le nouveau certificat.
Voici un petit script pour vous simplifier la vie.

sudo vim /root/script/new_cert.sh

le voici

#!/bin/bash

#Configuration variables
certbot_bin="/usr/bin/certbot"
haproxy_pem_path="/etc/haproxy/certs"
http_01_port='54321'
domain=$1

$certbot_bin certonly --standalone --renew-by-default --http-01-port $http_01_port -d ${domain} -d www.${domain}
cat /etc/letsencrypt/live/${domain}/fullchain.pem /etc/letsencrypt/live/${domain}/privkey.pem > ${haproxy_pem_path}/${domain}.pem

# At the end, reload haproxy
echo "$(date +%c) Reload haproxy"
service haproxy restart

On le rend exécutable

sudo chmod +x /root/scripts/new_cert.sh

A partir de là pour générer un nouveau certificat (qui sera par la suite automatiquement renouvelé), il vous suffit (en root) d'executer ce script comme ceci

cd /root/scripts
./new_cert.sh mon_nouveau_domaine.com

Et voilà , le certificat sera généré, renouvelé automatiquement et pris en charge par HAProxy .

Conclusion

Nous avons mis en place notre front (HAProxy) qui se charge de la partie SSL puis redirige les flus vers un ou plusieurs backends .
L'avantage de cette configuration et la simplicité de gestion des certificats, même avec plusieurs backends physiquement différents ( load balancing, différents services etc ... ).

Prochaine étape intercaler entre HAProxy et le backend, un serveur de cache ( Varnish ) .

Dans un prochain billet... N'hésitez pas à commenter.

Ch.

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.

15 août 2013

Python Web: Setup Django + MongoDB

django.jpg

Setup Django + MongoDB

Je travaille actuellement sur un projet d'application Web industriel basé sur les technologies suivantes

  • Python ( avec le framework Django V1.5.2 )
  • MongoDB ( Pour son efficacité et flexibilité )

Deux technologies que j'affectionne particulièrement, tant par le coté administration ( Principalement pour mongodb ) que par le coté utilisation.

Le framework MongoDB est parfait pour un projet industriel relativement imposant, mais peut tout aussi bien l'être pour une petit site de quelques page ( bien que pour ce genre de micro projet, je préférerais utiliser le framework flask, ou si je souhaite changer un peu d'air, utiliser Node.js avec le framework express.js ).

Seul "problème", Django n’intègre pas en natif la gestion des bases de données NoSQL comme MongoDB. Heureusement, quelques outils permettent de profiter pleinement de Django et MongoDB ensemble, notamment avec l'utilisation de la librairie MongoEngine, basée sur pymongo

N'ayant pas toujours le temps de transcrire mes tutoriels, je vais mettre le lien de mon document GoogleDoc, qui se complète au fur et à mesure du temps , n'hésitez donc pas à le parcourir, et laisser des commentaires, me corriger...

Django First steps

Bonne lecture,

Ch.

20 oct. 2011

Django étape par étape [Apache2 et mod_wsgi]

logo_django.png
Comme précisé dans le précédent billet, j'aime utiliser un environnement aussi proche que possible à l'environnement de production, cela commence par le serveur web finalement utilisé, dans mon cas Apache.
Voyons comment configurer un Vhost pour gérer notre projet Django

Le programme

  1. -OnLine- Présentation et installation du framework et MysqlDB
  2. --> Configuration du serveur web Apache, liaison avec le projet
  3. -OnLine GDOC- Première application sous django ( urls.py, settings.py )
  4. -OnLine GDOC- Mise en place de Django-Debug-toolbar
  5. -OnLine GDOC- Protection CSRF , utilisation , Jquery et requetes AJAX
  6. -OffLine- Les formulaires, utilisation basique du paquet Django.forms
  7. -OffLine- Les models création, utilisation et synchronisation
  8. ... la suite en fonction de mon apprentissage personnel :)

N'ayant pas toujours le temps de transcrire mes tutoriels, je vais mettre le lien de mon document GoogleDoc, qui se complète au fur et à mesure du temps , n'hésitez donc pas à le parcourir, et laisser des commentaires, me corriger ...

Django First steps

Prérequis


Nous allons nous mettre en condition pour mener à bien cette étape qui finalement, vous allez le voir, sera assez rapide.
Je part du principe ou apache est installé avec les paquets par défaut de la distribution.
Pour prendre en charge un projet python, nous avons plusieurs pistes,

  • mod_python

Déprécié, je ne l'utiliserai donc pas

  • fastcgi ou sgi
  • mod_wsgi

C'est ce dernier mode que je vais détailler ici, bien que les autres soient viables et "comme le dit la documentation" plus performants dans certaines configurations, le mod_wsgi reste le mode conseillé par Django.

Rappel sur wsgi

wsgi est une interface entre le serveur HTTP et l'application Python.
Pour plus d'information sur le sujet je vous conseil le site officiel.

Mise en place

Au niveau de l'application

Pour permettre à notre application de tirer parti de wsgi, nous allons créer à la racine un répertoire nommé "apache", dans ce répertoire , nous allons créer un fichier nommé django.wsgi.
Voici le contenu du fichier "django.wsgi"

import os, sys

sys.path.append('/var/www')

os.environ['DJANGO_SETTINGS_MODULE'] = 'monprojet.settings'

import django.core.handlers.wsgi

_application = django.core.handlers.wsgi.WSGIHandler()

def application(environ, start_response):
    #environ['SCRIPT_NAME'] = '/'
    environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
    return _application(environ, start_response)

info.png Deux lignes sont à modifier selon votre projet, et son emplacement ( lignes 2 et 3 ).
Dans le précédent billet, nous avons créer le projet monprojet à l'emplacement /var/www

Niveau apache

Il nous suffit de configurer correctement notre Vhost en précisant quelques paramètres propres à wsgi.
Voici le vhost de notre projet nommé : monprojet et disponible à l'adresse http://monprojet.com

<VirtualHost *:80>
        ServerAdmin [email protected]
        ServerName  monpropjet.com
        ServerAlias www.monprojet.com

        DocumentRoot /var/www/monprojet/

        Alias /static/ /var/www/monprojet/static/
        Alias /uploads/ /secure_dir/uploads/

        WSGIDaemonProcess daemon-monprojet user=www-data group=www-data processes=1 maximum-requests=1 threads=1 inactivity-timeout=6
        WSGIProcessGroup daemon-monprojet
        WSGIScriptAlias / /var/www/monprojet/apache/django.wsgi

        <Directory /var/www/monprojet/apache>
                Order deny,allow
                Allow from all
        </Directory>

        <Location "/uploads/">
                SetHandler None
        </Location>

        ErrorLog /var/log/apache2/monprojet.error.log
        CustomLog /var/log/apache2/mystock.access.log combined

</VirtualHost>

Les fichiers "statiques" ( img,css,js,... ) seront servi directement par apache, à partir du moment ou les urls pointent vers /static/* , concernant /uploads/, comme son nom l'indique, pointe vers l'espace de stockage des éventuelles uploads des clients, il est conseillé de mettre hors d'atteinte les fichiers uploadés par les clients, et encore moins interprétables, d'ou le SetHandler None.

Pour le reste, apache passe le relais à WSGI, vous devrai certainement affiner les paramètres, tels que processes, maximum-requests threads ou inactivity-timeout, il y en a d'autres, et je vous laisse lire la doc pour ajouter/modifier des paramétrés à WSGIDaemonProcess

warning.pngAttention à mettre un nom de daemon différent à chaque vhost hébergeant un projet Django.
Veillez à adapter le Vhost à votre environnement ( directory, user et group )

Ne vous reste plus qu'à ré-démarrer votre serveur Apache ( apres avoir enregistré votre vhost, en site-enabled ou simplement Inclus dans httpd.conf ).

Conclusion

Voilà , notre environnement de développement est maintenant en place, nous allons pouvoir dans le prochain billet attaquer un peu le code, nous verrons l’organisation des "applications", la configuration de base et les templates partagés ect ..

- page 1 de 2