Vous n'êtes pas identifié(e).
Cela fait un petit moment que je joue avec Docker pour mes déploiements et mes tests. ( Mon GitLab / WordPress / Pydio / Mumble / le bot Willie Server tous en container ) .
Pourquoi utiliser Docker ?
Mon point de vue Adminsys:
- Il est possible de créer un template d'architecture via docker et ainsi être facilement déployable ailleurs avec peu de modifications.
- On peut commit / sauvegarder facilement les dockers complet et les exporter. N'importe qu'elle machine utilisant docker seront capable de relancer les containers sauvegarder. Si on a pas de machine sous la main on se prend une bécane, on installe docker.io et zou c'est reparti pour un tour. Mais aussi simplifier les Rollback .
- Ultra léger: En effet seul les éléments nécessaires à faire tourner les applications sont "installées" les containers sont donc bien moins gourmand que des VM .
- Sécurité: On expose que les ports que l'on souhaite à l'extérieur, en plus de ça chaque container vie dans son "Chroot". Si un container est vulnérable, il ne rendra pas vulnérable le reste de l'infrastructure.
Mon point de vue pour les développeurs:
- De nombreuses images pré configurées existe, il est donc très simple de monter un environnement de test sans s'enmerder avec la partie admin.
- Certaines lib nécessaires aux compilation ( glibc6 Debian Sid) sont instables ou impact un système lors de leur installation, l'usage d'un container permet de créer un environnement sain pour ce faire .
- Un environnement sans interférence: et oui vous avez un container qui ne dispose que de ce dont vous avez besoin. Le reste du système reste fiable.
- Vous pouvez développer en local et à la fin des modification et de test pusher votre image en production facilement. Un rollback sera hyper simple à mettre en place si besoin ( vos adminsys vont vous payer des apéro beaucoup plus souvent) .
- tester vos applications dans des environnements différents simplement : CentOS / Debian / Arch dans n'importe quelle version.
Prérequis:
- avoir un linux 64 bits ( 32 bits encore en cours de dev)
Voilà pour la présentation.
Pour vous faire la main voici un excellent tuto du site officiel : Testez moi
Pour la suite du tuto:
Votre premier démarrage de container
Votre premier site web dockérisé
Votre première sauvegare et restauration
Etape 1 > Installation de docker
Ici je prends l'exemple d'une installation sur Viperr 6 / Fedora :
[== Indéfini ==]
sudo yum -y install docker
sudo usermod -a -G docker <user>
Pour les autres Autres architectures
Etape 2 > Trouver les images pour vos tests
Nous allons chercher une image Debian:
[== Indéfini ==]
docker search debian
Voici le résultat:
[== Indéfini ==]
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
debian (Semi) Official Debian base image. 368 [OK]
google/debian 39 [OK]
neurodebian NeuroDebian provides neuroscience research... 5 [OK]
hanswesterbeek/google-debian-oracle-jdk Oracle's JDK installed on top of Google's ... 5 [OK]
mschuerig/debian-subsonic Subsonic 5.1 on Debian/wheezy. 3 [OK]
tutum/debian Debian image with SSH access. For the root... 3 [OK]
shuron/debian-openjdk-7 Open JDK 7 64x on plain debian (Jessie) La... 2 [OK]
webhippie/cedarish-debian Heroku cedar-ish base images for Docker bu... 2 [OK]
maxexcloo/debian Docker base image built on Debian with Sup... 1 [OK]
eboraas/debian Debian base images, for all currently-avai... 1 [OK]
fike/debian-postgresql PostgreSQL 9.4 beta until 9.0 version runn... 1 [OK]
jesselang/debian-vagrant Stock Debian Images made Vagrant-friendly ... 1 [OK]
kalabox/debian 1 [OK]
takeshi81/debian-wheezy-php Debian wheezy based PHP repo. 1 [OK]
jprjr/debian-nginx 1 [OK]
aostanin/debian 0 [OK]
cpuguy83/debian 0 [OK]
reinblau/debian Debian with usefully default packages for ... 0 [OK]
essembeh/debian My own Debian Jessie image 0 [OK]
yaronr/debian-wheezy Debian Wheezy, 85mb, with a few extras 0 [OK]
solict/provisionous-puppet-debian Debian provisions with Puppet included 0 [OK]
razmo/debian Debian base 0 [OK]
tianon/debian-devel 0 [OK]
alexisvincent/debian 0 [OK]
etna/drone-debian
Nous allons récupérer l'image qui nous intéresse:
[== Indéfini ==]
docker pull debian
#par défaut cela équivaut à docker pull debian:latest
docker pull debian:jessy # pull la version "stable" de debian jessy
# ou # docker pull debian:8.0 # ect ....
Nous allons ensuite visualiser les images disponible en local:
[== Indéfini ==]
docker images
Mon résultat:
[== Indéfini ==]
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
debian 7 d5570ef1464a 3 days ago 84.98 MB
debian latest d5570ef1464a 3 days ago 84.98 MB
debian 7.8 d5570ef1464a 3 days ago 84.98 MB
debian unstable 073ffb3a9811 3 days ago 123 MB
debian testing 78964bc51299 3 days ago 122.8 MB
debian stable 45e227ad47b6 3 days ago 84.98 MB
debian 6 fe3630341850 3 days ago 76.66 MB
debian 6.0.10 fe3630341850 3 days ago 76.66 MB
debian 6.0 fe3630341850 3 days ago 76.66 MB
debian squeeze fe3630341850 3 days ago 76.66 MB
debian sid 3503509cb35e 3 days ago 123 MB
debian oldstable 5775473d35b3 3 days ago 76.66 MB
debian 8.0 50ec2d202fe8 3 days ago 122.8 MB
debian 8 50ec2d202fe8 3 days ago 122.8 MB
debian jessie 50ec2d202fe8 3 days ago 122.8 MB
debian 7.7 479215127fa7 9 weeks ago 84.99 MB
debian 7.6 feb755848a9a 5 months ago 85.19 MB
debian 6.0.9 fee2ea4e24af 7 months ago 78.48 MB
debian 7.5 06af7ad6cff1 5 months ago 85.18 MB
debian 7.4 e565fbbc6033 4 months ago 115 MB
debian 6.0.8 d56191e18d6b 8 months ago 113.1 MB
debian 7.3 b5fe16f2ccba 10 months ago 117.7 MB
Supprimer une image locale:
[== Indéfini ==]
docker rmi debian:sid
Dire "J'aime Glaaki!!!" avec un container ( one shot command)
[== Indéfini ==]
docker run debian:latest /bin/echo "j'aime Glaaki!!!!"
Que s'est il passé ? :
Nous avons demander l’exécution d'une commande avec l'option run . Docker a donc lancé l'image debian:latest depuis le local, si nous ne l'avions pas en local elle aurait été automatiquement téléchargée . Une fois le container lancé la commande echo a été effectuée à l'intérieur de celui ci et nous a renvoyé l'affichage.
Mais après ?
Le container c'est tout simplement terminé, La durée de vie dépend tout simplement du temps d’exécution des processus qu'il contient Donc ici le temps d'un echo.
Essayons de faire un peu plus qu'un echo:
[== Indéfini ==]
docker run -i -t debian:latest /bin/bash
root@82t87eb7f25:/#
L'option "-i" permet de se connecter au container en utilisant la sortie standard ( votre tty host) , elle va de paire avec l'option "-t" qui permet l'ouverture d'un terminal dans le même container.
Essayer quelques commandes de "bases" ls/find/grep/.... Vous vous trouvez dans une debian "standard" minimaliste.
Essayer d'installer wget :
[== Indéfini ==]
apt-get update
apt-get install wget
#par défaut aptitude n'est pas installé dans les containers
apt-get install aptitude
Pour sortir du container tapez "exit" ou alors ctrl+d, cette action va terminer le container.
"C'est inutile si ça coupe tout seul !!!!" >> Parfois oui. Mais on peut avoir besoin que d'un test parfois.
Etape 3 Création d'un container persistent.
L'intérêt des premiers container étaient limité, nous allons prendre un exemple d'un container "limité" encore une fois pour comprendre le mode daemon.
Nous allons créer un container qui va utiliser la commande echo précédente mais toutes les secondes:
docker run -d debian:latest /bin/sh -c "while true; do echo je kiff Glaaki; sleep 1; done"
4621164ddb547487253251dc43fb1e7bad4e838729886d93462b7f5cee1126f9
Oui maintenant nous avons un container qui dit j'aime Glaaki toutes les secondes.
L'option -d permet d'instancier notre container en mode daemonisé. Trop cool
Ouep mais je vois rien dans mon terminal.... >> normal tout ce passe en arrière plan.
!!!!!Important La commande docker ps permet d'afficher la liste des container en cours d'éxécution . Avec l'option -a vous verrez la liste complète des containers.
[== Indéfini ==]
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t About a minute ago Up About a minute boring_brattain
Comme vous l'avez peut être remarqué dans la colonne NAME, les noms des containers ne sont pas des plus explicites ... Vous pouvez nommer vos container avec l'option -name <nom> avec la commande run
Les commandes docker run et docker exec (que nous verrons plus tard), permettent l'usage du nom du container mais aussi le container ID .
La commande docker ps ne permet d'afficher que les instances docker en cours .
Pour voir les container que nous avons utilisé plus tôt il faudra utiliser la commande docker ps -a
[== Indéfini ==]
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 2 minutes ago Up 2 minutes boring_brattain
5c74fe3d2411 debian:latest "/bin/echo 'j'aime G 4 minutes ago Exited (0) 4 minutes ago backstabbing_yalow
0dd6c7b7f514 debian:latest "/bin/echo 'j'aime G 5 minutes ago Exited (0) 5 minutes ago jovial_goodall
b7f9e5d47026 debian:latest "/bin/bash" 5 minutes ago Exited (0) 5 minutes ago clever_mccarthy
Notre docker démoniaque est ene cours d'usage mais dit t'il bien "je kiff Glaaki" ou il a changé de sujet ?
Regardons ce qui se passe dans le container, grâce aux logs:
[== Indéfini ==]
docker logs boring_brattain
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
Info: la commande docker -logs --follows permet de suivre le logs comme on pourrait le faire avec la commande tail -f . Si vous voulais voir la "date" des logs utilisez l'option "--timestamp"
Etape 4 > Super j'ai un docker en daemon !!! Mais comment je peux jouer avec et l'arrêter ?
Nous allons commencer par se rattacher au container :
[== Indéfini ==]
docker attach docker attach boring_brattain
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
je kiff Glaaki
....
Nous sommes maintenant dans le container. Appuyez sur ctrl+c pour arrêter le script en cours.
Vérifions l'état de notre boring_brattain
[== Indéfini ==]
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 21 minutes ago Exited (0) 43 seconds ago boring_brattain
Avec l'échappement, nous avons terminé l'éxecution du script et donc également le container.
Cette action nous permet d'aller un peu plus loin dans l'usage de des commandes qui interagissent avec les container.
Démarrer un container précèdement utilisé:
[== Indéfini ==]
docker start boring_brattain
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 24 minutes ago Up 2 seconds boring_brattain
Nous pouvons ajouter des actions supplémentaires à notre container tout en laissant celui tourner en arrière plan grâce à la commande docker exec
[== Indéfini ==]
docker exec boring_brattain echo "pas moi "
pas moi
Nous venons d'utiliser le container pour une deuxième commande echo. Cela n'a pas pour autant arrêter notre script while.
Maintenant nous allons nous connecter au docker avec la possibilité d'utiliser son terminal et en sortir sans pour autant tout couper
[== Indéfini ==]
docker exec -it boring_brattain /bin/bash
root@4621164ddb54:/# exit
## vérification
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 33 minutes ago Up 9 minutes boring_brattain
Voilà nous avons pu intéragir avec notre container pour par exemple faire une mise à jour sans pour autant le couper .
Mettre en pause un container:
Nous pouvons "suspendre" un container en conservant son état puis le relancer
[== Indéfini ==]
docker pause boring_brattain
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 36 minutes ago Up 12 minutes (Paused)
# le remettre en marche
docker unpause boring_brattain
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4621164ddb54 debian:latest "/bin/sh -c 'while t 37 minutes ago Up 13 minutes boring_brattain
Vous pouvez voir dans le STATUS que le container est en pause.
Maintenant arrêtons ce container une bonne fois pour toute et supprimons le:
[== Indéfini ==]
docker stop boring_brattain
docker rm boring_brattain
La commande docker rm permet de supprimer un container, attention à ne pas la confondre avec docker rmi qui permet de supprimer les images locales.
Bonus: nous aurions pu supprime notre premier container dès la fin de l’exécution de son echo avec l'option du run -rm .
[== Indéfini ==]
docker run --rm debian:latest /bin/echo "j'aime Glaaki!!!!"
Cela à pour avantage de garder propre votre liste de container
Etape 5 > C'est super chouette tout ça mais comment je peux faire un serveur Web avec ça ?
Créons un nouveau container daemon basé sur Debian pour commencer.
[== Indéfini ==]
docker run -it -d debian:latest /bin/bash
Et mince, on a oublié de lui donner un joli nom. Pas de soucis, voici la marche à suivre pour renommer l'instance.
[== Indéfini ==]
docker rename desperate_meitner docker-web
Ouf ça sera plus facile de se rappeler de son petit nom maintenant.
Mettons à jours notre container:
[== Indéfini ==]
docker exec -it docker-web /bin/bash
root@ca15064cef27:/# apt-get update
root@ca15064cef27:/# apt-get upgrade
Vous vous souvenez du principe d'instance d'un container ?
En gros chaque container rajouter une surcouche à une instance précédente, ici à l'instance debian:latest
Voici comment voir les différences apporter par rapport à l'image d'origine:
[== Indéfini ==]
docker diff docker-web
C /etc
C /etc/timezone
C /etc/localtime
C /root
A /root/.bash_history
C /usr
C /usr/sbin
C /usr/share
C /usr/share/doc
C /usr/share/doc/tzdata
C /usr/share/doc/tzdata/changelog.Debian.gz
C /usr/share/zoneinfo
[...]
Signification des attributs:
- A ajout
-C modification
-D suppression
Il est préférable d'exporter le résultat dans un fichier car les terminaux ont souvent une limite dans le nombre de ligne à afficher. docker diff docker-web > docker-wev_info_diff
Oui je sais vous voulez créer votre serveur web dockérisé !!!!
Installons le paquet apache dans notre container:
(nous allons installer également le paquet bash-autocompletion c'est quand même pratique ce truc)
[== Indéfini ==]
root@ca15064cef27:/# apt-get install bash-completion bash-completion
root@ca15064cef27:/# service apache2 start
# vérification du service apache2
grep www-data
www-data 4750 0.0 0.0 71544 3760 ? S 20:06 0:00 /usr/sbin/apache2 -k start
www-data 4751 0.0 0.0 295248 4532 ? Sl 20:06 0:00 /usr/sbin/apache2 -k start
www-data 4753 0.0 0.0 295240 4572 ? Sl 20:06 0:00 /usr/sbin/apache2 -k start
root 4882 0.0 0.0 6316 524 ? S+ 20:11 0:00 grep www-data
Nous pouvons également faire cette vérification depuis l'hôte :
[azgarech@Viperr ~]$ docker top docker-web
UID PID PPID C STIME TTY TIME CMD
root 19160 1803 0 20:50 pts/2 00:00:00 /bin/bash
root 27186 1 0 21:06 ? 00:00:00 /usr/sbin/apache2 -k start
33 27188 27186 0 21:06 ? 00:00:00 /usr/sbin/apache2 -k start
33 27189 27186 0 21:06 ? 00:00:00 /usr/sbin/apache2 -k start
33 27191 27186 0 21:06 ? 00:00:00 /usr/sbin/apache2 -k start
Connaître l'ip du container:
Depuis l'hôte
[azgarech@Viperr ~]$ docker inspect --format "{{.NetworkSettings.IPAddress}}" docker-web
172.17.0.11
Depuis le container
[bryce@Viperr ~]$ docker exec -it docker-web /bin/bash
root@ca15064cef27:/# ip a show eth0
28: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:0b brd ff:ff:ff:ff:ff:ff
inet 172.17.0.11/16 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe11:b/64 scope link
valid_lft forever preferred_lft forever
Peux ton accéder à la page depuis l'hôte :
[azgarech@Viperr ~]$ curl -i 172.17.0.11
HTTP/1.1 200 OK
Date: Fri, 27 Mar 2015 20:15:20 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Fri, 27 Mar 2015 20:05:39 GMT
ETag: "81827-b1-5124aa80472f7"
Accept-Ranges: bytes
Content-Length: 177
Vary: Accept-Encoding
Content-Type: text/html
X-Pad: avoid browser bug
<html><body><h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added, yet.</p>
</body></html>
Ou depuis votre navigateur. http://172.17.0.11
Pour le moment nous avons un docker hébergeant un serveur web accessible par l'hôte mais uniquement pour lui . C'est dommage ça, non ?
Il faut en fait utiliser l'option -p ou --publish pour publier un port du container relié à un port de l'hôte.
Je peux vous entendre déjà râler su le fait qu'il va falloir tout recommencer ....
En fait non, nous allons commiter le container actuel et le lancer de noveau avec les bonnes options cette fois ci.
[== Indéfini ==]
docker commit docker-web docker-apache2
docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
docker-apache2 latest 71282c23e18a 26 seconds ago 222.9 MB
debian latest c9fa20ecce88 7 days ago 84.96 MB
Nous venons de créer une image locale depuis le container docker-web avec les dernières modifications.
Le TAG "latest" lui a été automatiquement attribué. Pour créer une copie de l'image avec un tag plus parlant faire comme ceci:
[== Indéfini ==]
docker tag docker-apache2:latest docker-apache2:0.1
docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
docker-apache2 latest 71282c23e18a 4 minutes ago 222.9 MB
docker-apache2 0.1 71282c23e18a 4 minutes ago 222.9 MB
debian latest c9fa20ecce88 7 days ago 84.96 MB
Nous ne venons pas vraiment de créer une nouvelle image, mais une sorte de lien symbolique. Les deux images ne prendront qu'une fois 222.9 MB .
A la prochaine création d'une image:latest seul le différentiel sera stocké sans perte de donnée.
En fait notre image "totale" fait 222.9 MB - 84.96 MB . Pourquoi? Car nous nous sommes basé sur l'image de base Debian.
Comment mieux visualiser les "branches" de notre container:
[== Indéfini ==]
docker history docker-apache2:0.1
IMAGE CREATED CREATED BY SIZE
71282c23e18a 9 minutes ago /bin/bash 137.9 MB << le poids de nos modifications
c9fa20ecce88 7 days ago /bin/sh -c #(nop) CMD [/bin/bash] 0 B
e977d53b9210 7 days ago /bin/sh -c #(nop) ADD file:ef063ed0ae95793628 84.96 MB << Correspond à l'image Debian
511136ea3c5a 21 months ago
Nous allons pouvoir après une longue attente publier notre serveur pour y accéder depuis l'extérieur:
[== Indéfini ==]
[code]
[== Indéfini ==]
docker commit apache2-dev docker-apache2:0.2
aeb9632df5329eeb66f8819130f30cad12f58b1e3e2f63d5c5fe87acbb5a7434
docker stop apache2-production
docker rm apache2-production
docker run -it -d -p 80:80 --name apache2-production docker-apache2:0.2 /bin/bash
b568562bc260cf59e1a54df127ffd2a809689145b70b10ad47281ada89948a35
docker exec -it apache2-production /bin/bash
root@b568562bc260:/# service apache2 start
[....] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.20 for ServerName
. ok
root@b568562bc260:/# exit
[/code]
# Vérification du fonctionnement du docker
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b568562bc260 docker-apache2:0.1 "/bin/bash" 3 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp apache2-production
Nous venons de rendre accessible notre serveur sur le port 80 de notre hôte. Nous pouvons donc nous connecter depuis un autre poste sur la page web avecl'url http://iplocale-hôte/ .
Important :
l'option -p 80:80 lie le port 80 de l'hôte au port 80 du container. (typographie host:container) . Il est donc possible de redirigé un autre port de l'hôte sur le port 80 du container
Nous allons mettre ça en pratique pour la création d'un container de développement. En effet, le port 80 de l'hôte étant déjà occupé nous ne pourrons rendre accessible notre nouveau container sur ce même port .
[== Indéfini ==]
docker run -it -d -p 8080:80 --name apache2-dev docker-apache2:0.1 /bin/bash
52d443d0e083840ab433fc85c5aed864215eedb218ac80abdb9fc97da13a0d79
service apache2 start
[....] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.21 for ServerName
. ok
root@52d443d0e083:/# exit
Nous avons à cette étape deux container identiques un pour la production sur le port d'écoute 80 de notre hôte et l'autre pour le développement sur le port 8080
La preuve :
[== Indéfini ==]
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
52d443d0e083 docker-apache2:0.1 "/bin/bash" About a minute ago Up 59 seconds 0.0.0.0:8080->80/tcp apache2-dev
b568562bc260 docker-apache2:0.1 "/bin/bash" 15 minutes ago Up 15 minutes 0.0.0.0:49161->80/tcp apache2-production
Nous pouvons donc faire nos modifications et tests sur le container apache2-dev sans impacter la production.
Il faut se rappeler que nous pouvons faire des commit d'un container en cours de fonctionnement.
Je vous laisse donc faire vos modifications .
A la fin de tout ça et après vos tests voici la marche à suivre.
[== Indéfini ==]
docker commit apache2-dev docker-apache2:0.2
aeb9632df5329eeb66f8819130f30cad12f58b1e3e2f63d5c5fe87acbb5a7434
docker stop apache2-production
docker rm apache2-producton
docker run -it -d -p 80:80 --name apache2-production docker-apache2:0.2 /bin/bash
b568562bc260cf59e1a54df127ffd2a809689145b70b10ad47281ada89948a35
docker exec -it apache2-production /bin/bash
root@b568562bc260:/# service apache2 start
[....] Starting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.20 for ServerName
. ok
root@b568562bc260:/# exit
Il existe bien évidement d'autres façon d'exporter votre travail sans couper le serveur de production, en fait ce que vous feriez avec un hôte normal ou une VM . Mais aussi des outils propres à docker. Mais pour l'instant restons en là .
Voilà de bonnes bases pour vous lancer dans l'aventure .
Si vous voulez un tutoriel avancé n'hésitez pas
- export sur une machine distance de notre container par exemple
- lier les containers entre-eux ....
PS: si vous êtes arrivé jusqu'au bout, bravo pour votre témérité
Dernière modification par azgarech (27-03-2015 23:39:24)
Security is always excessive until it’s not enough. — Robbie Sinclair
Hors ligne
Sympa ton tuto merci
- Sécurité: On expose que les ports que l'on souhaite à l'extérieur, en plus de ça chaque container vie dans son "Chroot". Si un container est vulnérable, il ne rendra pas vulnérable le reste de l'infrastructure.
C'est bien pratique sauf que, l'inconvénient est que si ton kernel est vulnérable tout tes container seront aussi. voilà pourquoi je préfère utiliser un hypervisor car chaque VM est indépendante du OS hôte et à sont propre kernel.
>> Good things come to those who, Wait.. <<
>> sip:yzeew@ekiga.net << and >> #Pouni3 <<
Hors ligne
Tiens où est passé le plugin pour dire merci ? Bah je le dis par écrit dans ce cas
Hors ligne
Sympa ton tuto merci
azgarech a écrit :- Sécurité: On expose que les ports que l'on souhaite à l'extérieur, en plus de ça chaque container vie dans son "Chroot". Si un container est vulnérable, il ne rendra pas vulnérable le reste de l'infrastructure.
C'est bien pratique sauf que, l'inconvénient est que si ton kernel est vulnérable tout tes container seront aussi. voilà pourquoi je préfère utiliser un hypervisor car chaque VM est indépendante du OS hôte et à sont propre kernel.
Argument pour et contre. Car finalement tu n'as qu'un Host à gérer au niveau kernel au lieu de multiple VM . Mais c'est un point important en effet. D'où l'importance de bien choisir son host.
Security is always excessive until it’s not enough. — Robbie Sinclair
Hors ligne
Je suis d'accord avec toi sur ce point là. mais bon on ne peut pas tout avoir non plus
>> Good things come to those who, Wait.. <<
>> sip:yzeew@ekiga.net << and >> #Pouni3 <<
Hors ligne