Tuto extrait de http/2: Mécanisme de négociation http2 vs http1.1 dans un GET httpsvoila une petite intro "en chantier" qui traine dans ma todo list.
C'est pour nginx mais adaptable a apache:
// debut tuto
Lancement de nginx dans un container:
pre-requis:
installer Docker (et si on veut eviter d'avoir a taper 'sudo docker ...' tout le temps :
https://docs.docker.com/engine/installation/linux/ubuntulinux/#create-a-docker-group )
docker run -d -p 80:80 -p 443:443 --name web-domain.com\
-v /home/user/domain.com/nginx.conf:/etc/nginx/nginx.conf:ro \
-v /home/user/domain.com/www:/www:ro \
-v //home/user/domain.com/logs:/logs \
nginx:latest
-d: arriere plan
-p: mapping ports réseau ([ip:]externe:interne) - pour limiter a une ip x.y.z.t -> "-p x.y.z.t:80:80"
-v: mapping volumes (chemin-externe:chemin-interne[:ro]). le chemin peut être un fichier ou tout un répertoire. ro= read-only, le container ne pourra écrire dans ce fichier/repertoire.
--name "web-domain.com" : le nom du container, on met ce qu'on veut
"nginx:latest" -> nom de l'image , 'latest': la plus recente. l'image vient d'ici:
https://hub.docker.com/_/nginx/le container démarre de suite (< qques secondes) si l'image est deja présente. on peut pré-charger l'image avec "docker pull nginx:latest" par exemple.
Dans cet exemple on aura donc nginx qui tournera dans un container. sur l'hote, dans le dossier /home/user/domain.com, on aura:
le fichier "nginx.conf" qui est la configuration de nginx
un répertoire www ou on trouve le contenu a publier
un répertoire logs ou nginx enregistrera les logs
Il y a donc une séparation et isolation très clean entre le 'code' et les données importantes (config, input, ouput). L'image nginx:latest fait tourner la dernière version de nginx sur un Debian Jessie quelque soit l'OS de l’hôte (seul le kernel est commun).
Il faut voir un container comme quelque chose de 'jetable' et donc ne rien 'stocker d'important' dedans meme si, en théorie, on peut.
On utilise le mapping de volumes et ports pour échanger des données avec l’extérieur (ou avec d'autre containers). Une astuce est de considérer un container comme un binaire unique, comme si c'était un seul fichier "nginx.exe" par exemple, et de raisonner comme ca.
Pour mettre a jour un container, il suffit donc de le détruire et d'en créer un autre avec une nouvelle image (what?!): c'est le plus propre et reproductible vu qu'en principe il n'y a rien d'important dans le container. En pratique on arrête le container, on crée un nouveau container avec la nouvelle image et si il y a souci on redémarre l'ancien container.
On peut aussi acceder en CLI dans un container (docker exec) et faire des maj dedans (apt, etc) mais ca n'est pas la philosophie du truc. c'est pratique en mode devel/debug mais pas en prod.
On peut snapshot'er un container pour faire une image ("docker commit") ou le sauvegarder "docker save" vers un .tar puis "docker load" pour le déplacer sur une autre machine ou faire un backup.
On peut
limiter et personnaliser la conso mémoire, cpu et i/o des containers.
Gestion des containers:
docker ps : affiche les containers actifs
docker ps -a : affiche tout les containers
docker logs web-domain.com: affiche le logs du container (= stdout+stderr)
docker stop web-domain.com : arrête proprement le container
docker start web-domain.com : démarre le container
docker kill web-domain.com: tue (arrête salement) le container
docker restart web-domain.com: stop, puis kill si timeout, puis start
docker rm web-domain.com: supprime le container
docker exec [-it] web-domain.com <command>: execute <command> dans le container
par exemple: "docker exec -it web-domain.com /bin/bash" : execute "/bin/bash' dans le container et se connecte en session interactive/terminal (-it) = on ouvre un CLI dans le container (il faut bien sur que l'image du container connaisse /bin/bash).
autre exemple : "docker exec web-domain.com nginx -v" va afficher la version de ngnix.
Images:
On peut construire soi-meme des images: il faut créer un fichier appelé "Dockerfile" et mettre des instructions dedans.
Par exemple le Dockerfile qui a servit a construire l'image de
https://hub.docker.com/_/nginx/:
FROM debian:jessie
MAINTAINER NGINX Docker Maintainers "docker-maint@nginx.com"
ENV NGINX_VERSION 1.9.11-1~jessie
RUN apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62 \
&& echo "deb http://nginx.org/packages/mainline/debian/ jessie nginx" >> /etc/apt/sources.list \
&& apt update \
&& apt install -y ca-certificates nginx=${NGINX_VERSION} gettext-base \
&& rm -rf /var/lib/apt/lists/*
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 80 443
CMD ["nginx", "-g", "daemon off;"]
ca dit:
FROM: partir de l'image de
debian:jessie = partir d'une 'machine vierge' ou on vient juste d'installer debian:jessie
MAINTAINER : c'est l'auteur, le contact (important pour publier l'image sur le Docker Hub = le "store"/depot public d'images)
ENV : definie une variable d'environment qui sera conservée dans les instances
RUN: execute des commandes pendant la création de l'image. chaque 'RUN' genere un point de reprise donc en cas d'erreur / modif du Dockerfile on recommence la ou ca a changé/planté et pas du début (tres pratique si y'a un long apt par exemple ou une grosse compilation).
EXPOSE ports réseau exposés par le container (qu'il faut mapper au moment du "run")
CMD la commande qui est lancé quand le container démarre
il y a d'autres instructions comme 'ADD' pour ajouter des fichiers dans l'image, USER, WORKDIR, etc voir:
https://docs.docker.com/engine/reference/builder/Le commande "
docker build" va ensuite contruire l'image.
// fin tuto
pour apache,les images officielles ont pour nom 'httpd':
https://hub.docker.com/_/httpd/
NAS, serveurs et micro-serveurs