Étiquette : container

  • Partage de repertoire entre conteneur

    Par réflexe, j’ai commencé par partagé des répertoires via le protocole samba entre plusieurs conteneurs. Mais cela impose de d’installer les paquets samba sur proxmox.

    Du coup, proxmox commence à faire plus de choses que ce pour quoi je l’ai installé (système de virtualisation).

    J’ai donc chercher une autre solution.

    Dans proxmox, on peut ajouter un point de montage sur un disk.

    Mais le résultat n’est pas intéressant, on se retrouve avec un répertoire vm-108-disk-2 dans le local-lvm. On se retrouve donc avec des répertoires dédiés très loin du résultat recherché.

    En consultant les forums, j’ai trouvé ceci.

    En éditant, le fichier /etc/pve/lxc/.conf

    et changer la ligne

    mp0: local-lvm:vm-108-disk-2,mp=/test,size=8G

    en

    mp0: volume=/tank/test,mp=/opt/test

    On va monter le répertoire /tank/test dans le container sous le chemin /opt/test

    Si on fait cela pour tous les containers, on a un moyen de partager un filesystem sans samba.

  • docker – liens entre container suite

    Maintenant que nous avons la bonne version de docker, nous pouvons modifier le fichier context.xml de l’application pour pointer sur le hostname de redis :

    className="com.radiadesign.catalina.session.RedisSessionManager"
    host="db"
    port="6379"

    On va aussi modifier le démarrage du serveur d’applications pour créer un lien vers redis:

    docker run -i -t --link redis:db session-webapp:1.0-SNAPSHOT

    tomcat et redis sont maintenant connectée sans avoir besoin de connaître l’ip de chacun.

    Et voici le script de démarrage complet :

    docker run --rm --name redis -p 6379:6379 -v /tmp/data:/data dockerfile/redis &
    
    sleep 5
    
    docker run --rm --name appA --link redis:db session-webapp:1.0-SNAPSHOT &
    
    docker run --rm --name appB --link redis:db session-webapp:1.0-SNAPSHOT &
    
    sleep 10
    
    docker run --rm --name haproxy --link appA:app1 --link appB:app2 --env "UPSTREAMS=2" bcharret/haproxy &

    Nous avons donc réussi à déployer des applications qui sont connectées entre elles, sans connaître les ips de chacune à l’avance. En termes de scalabilité, il devient aisé de rajouter un serveur d’application. Il faut juste démarrer un nouveau conteneur et le linker au haproxy.

    Dans un prochain article, nous essayerons de voir comment faire fonctionner un cluster de redis avec docker.

    Les sources sont à jour ici: https://github.com/BenoitCharret/session-webapp/tree/article_3

  • docker – liens entre container

    Une chose qui m’a posé problème dans l’article sur le load balacing est que en fonction de l’ordre de démarrage des conteneurs, il fallait modifier le fichier de configuration haproxy.cfg pour avoir les bonnes ips. Je me suis donc intéressé aux liens entre conteneurs et j’ai un peu fait évoluer les choses. Tout d’abord, j’ai commencé par donné des noms à mes conteneurs applicatifs:

    docker run --name appA session-webapp/1.0-SNAPSHOT &
    
    docker run --name appB session-webapp/1.0-SNAPSHOT &
    
    

    Je vais donc avoir un conteneur 1 avec un nom appA et un conteneur 2 avec un nom appB (les conteneurs étant les mêmes). J’ai ensuite construit une nouvelle image haproxy en repartant de zéro pour  apporter quelques modifications au script de démarrage. J’ai d’abord redéfini le Dockerfile:

    FROM dockerfile/ubuntu
    
    RUN apt-get update
    RUN apt-get install -y haproxy
    RUN sed -i 's|/dev/log|127.0.0.1|g' /etc/haproxy/haproxy.cfg
    RUN sed -i 's/daemon/#daemon/g' /etc/haproxy/haproxy.cfg
    
    ADD start_haproxy.sh /usr/local/bin/start_haproxy.sh
    
    
    CMD [ "bash" , "/usr/local/bin/start_haproxy.sh"]
    
    EXPOSE 80

    J’installe le paquet haproxy et je modifie quelques éléments de la configuration. Notamment, je désactive le mode daemon. J’ajoute un script sh qui servira de base au lancement de l’image et j’expose le port 80. Le fichier script va construire la configuration au démarrage en fonction des conteneurs qui seront linkés. En regardant la documentation sur les links, on voit que pour chaque lien déclarer, docker va pousser des variables d’environnement dans le conteneur parent.

    Exemple avec la commande

    docker run -i -t --link appA:app1 bcharret/haproxy /bin/bash

    j’obtiens les valeurs suivantes

    [ root@c47b85aaf7e5:~ ]$ env | grep APP1 | sort
    APP1_ENV_CATALINA_HOME=/opt/tomcat
    APP1_ENV_TOMCAT_VERSION=6.0.39
    APP1_NAME=/stupefied_euclid/app1
    APP1_PORT=tcp://172.17.0.4:8080
    APP1_PORT_8080_TCP=tcp://172.17.0.4:8080
    APP1_PORT_8080_TCP_ADDR=172.17.0.4
    APP1_PORT_8080_TCP_PORT=8080
    APP1_PORT_8080_TCP_PROTO=tcp
    APP1_PORT_8081_TCP=tcp://172.17.0.4:8081
    APP1_PORT_8081_TCP_ADDR=172.17.0.4
    APP1_PORT_8081_TCP_PORT=8081
    APP1_PORT_8081_TCP_PROTO=tcp
    
    

    Je peux donc me servir de ces valeurs pour construire ma configuration à la volée. La seule valeur supplémentaire dont j’ai besoin est de connaître le nombre de liens que je vais ajouter. Je vais donc introduire la variable UPSTREAMS

    #!/bin/sh
    
    PIDFILE="/var/run/haproxy.pid"
    UP_COUNT=${UPSTREAMS:-1}
    
    ADD_CONFIG="listen session-webapp :80"$'\n'
    
    HAPROXY="/etc/haproxy"
    CONFIG="haproxy.cfg"
    
    cd "$HAPROXY"
    
    index=0
    while [ $index -lt $UP_COUNT ]; do
    #for index in {1..$UP_COUNT}; do
    let $((index++))
    IP_ADDR=`eval echo '$'APP${index}_PORT_8080_TCP_ADDR`
    ADD_CONFIG="${ADD_CONFIG}"$'\n'"server tomcat${index} ${IP_ADDR}:8080 check"
    done
    
    ADD_CONFIG="${ADD_CONFIG}"$'\n'"stats enable"$'\n'"stats uri /stats"
    
    echo "${ADD_CONFIG}" >> "$CONFIG"
    
    haproxy -f /etc/haproxy/haproxy.cfg -p "$PIDFILE"

    on voit bien que je vais ajouter autant de ligne server… que de $UPSTREAMS en me basant sur les valeurs successives de $APP?_PORT_8080_TCP_ADDR Cela donne avec deux liens:

    listen session-webapp :80
    
    server tomcat1 172.17.0.4:8080 check
    server tomcat2 172.17.0.3:8080 check
    stats enable
    stats uri /stats

    Pour lancer un conteneur avec des liens, on utilise la syntaxe suivante (dans un docker run):

    --link container_name:link_name

    container_name étant le nom défini à la suite de la commande
    –name link_name étant le nom qui sera utilisé dans le conteneur parent

    Ce qui donne par exemple :

    docker run  --name haproxy --link appA:app1 --link appB:app2 --env "UPSTREAMS=2" bcharret/haproxy &

    Il est maintenant plus facile de rajouter des serveurs applicatifs. Il faut lancer un conteneur supplementaire un un nom et le linker avec le haproxy:

    docker run  --name appC session-webapp/1.0-SNAPSHOT &
    
    docker run  --name haproxy --link appA:app1 --link appB:app2 --link appC:app3 --env "UPSTREAMS=3" bcharret/haproxy &

     

    Il ne me reste plus qu’a travailler sur le lien entre les serveur applicatifs et la base redis.

    Comme d’habitude les sources sont ici: https://github.com/BenoitCharret/session-webapp. J’ai ajouté un script start_all.sh et stop_all.sh pour simplifier la mise en route.