belkacem@apache:~$ sudo nano /etc/apache2/sites-available/000-default.conf

Lorsqu’une requête arrive sur le port 80, elle est traitée dans le répertoire par défaut « /var/www/html ». En parallèle, les erreurs sont consignées dans le fichier « /var/log/apache2/error.log », tandis que les informations relatives aux accès sont enregistrées dans « /var/log/apache2/access.log ». Ainsi, l’hébergement d’un site internet repose sur une organisation logique illustrée par ces répertoires..

Dans le répertoire /var/www/html/, se trouve une page HTML nommée « index.html ». Pour personnaliser cette page, nous éditons ce fichier et modifions son titre. Plus précisément, à la ligne 208, nous remplaçons le texte « Apache2 Default Page » par un titre de notre choix, reflétant ainsi le contenu ou l’objectif du site. Une fois les modifications effectuées, nous enregistrons le fichier pour appliquer ces changements.

En accédant à notre serveur web à l’aide d’un navigateur, nous constatons que le titre a bien été modifié. Cela confirme que nos modifications ont été prises en compte. Ainsi, héberger un site internet repose sur quelques étapes simples : configurer le serveur, organiser les fichiers dans le répertoire adéquat, et personnaliser les pages selon les besoins du site. Avec ces bases, il devient facile de gérer un hébergement web fonctionnel et adapté.

Hebergement plusieurs sites Web avec Apache en utilisant les ports

Par défaut, comme nous l’avons mentionné dans l’article précédent, Apache écoute sur le port 80. Cependant, vous pouvez configurer Apache pour écouter sur un autre port en créant un second « VirtualHost » dédié. Par exemple, nous allons configurer Apache pour écouter sur le port 81 et associer ce port au répertoire /var/www/html/port81/. Pour cela, nous basons notre travail sur le fichier de configuration par défaut, que nous adaptons pour répondre aux besoins spécifiques de l’hébergement multi-site.

belkacem@apache:~$ sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/port81.conf
belkacem@apache:~$ sudo vim /etc/apache2/sites-available/port81.conf

Nous configurons Apache pour écouter sur le port 81 en modifiant le contenu du fichier de configuration. Nous gérons ensuite les requêtes adressées à ce port à l’aide des fichiers situés dans le répertoire /var/www/html/port81. De plus, nous mettons en place des journaux spécifiques pour ces requêtes, ce qui nous permet d’assurer un suivi clair et détaillé de l’activité liée à ce port.

Listen 81
<VirtualHost *:81>
        DocumentRoot /var/www/html/port81/
        ErrorLog ${APACHE_LOG_DIR}/error_port81.log
        CustomLog ${APACHE_LOG_DIR}/access_port81.log combined
</VirtualHost>

Création du répertoire pour l’hébergement du site web

Nous créons le répertoire requis, puis nous simplifions le processus en copiant et collant le fichier index.html dans le répertoire /var/www/html/port81/ que nous avons créé. Avec cette configuration, nous atteignons notre objectif d’héberger un site internet supplémentaire.

belkacem@apache:~$ sudo mkdir /var/www/html/port81/
belkacem@apache:~$ sudo cp /var/www/html/index.html /var/www/html/port81/

Nous modifierons le titre du fichier « index.html » contenu dans le répertoire /var/www/html/port81/

Actuellement, notre site est dans le répertoire /etc/apache2/sites-available/, ce qui le rend disponible mais pas encore activé. Pour l’activer, nous copions sa configuration dans le répertoire /etc/apache2/sites-enabled/. Ensuite, nous créons un lien symbolique pointant vers le fichier de configuration. Ainsi, nous configurons Apache pour activer ce site et le rendre prêt à l’utilisation. Grâce à cette méthode, nous simplifions la gestion des sites hébergés.

belkacem@apache:~$ sudo ln -s /etc/apache2/sites-available/port81.conf /etc/apache2/sites-enabled/port81.conf

Recharger la nouvelle configuration

Nous appliquons la nouvelle configuration d’Apache en rechargeant ses fichiers. Pour cela, nous rechargeons le service Apache. Cette action garantit que le serveur prend en compte les modifications et fonctionne correctement avec les nouveaux paramètres.

belkacem@apache:~$ sudo systemctl reload apache2

Pour accéder à ce nouveau site internet, nous précisons le port 81 dans l’URL. Nous entrons donc http://<adresse_ip>:81 dans la barre d’adresse du navigateur. Vérifions le résultat.

Hébergement plusieurs site Web en utilisant les noms de domaine

Dans le chapitre précédent, nous avons appris à créer plusieurs sites internet sur un même serveur. Cependant, bien que cette méthode soit adéquate pour un usage privé, elle ne convient pas à un usage public, comme celui d’un site vitrine. En effet, il est important de noter qu’un utilisateur lambda ne prendra pas le temps de saisir un numéro de port ou une adresse IP pour accéder à un site.

Simuler un nom de domaine dans une environnement de test

Ainsi, dans un environnement de production, nous procédons différemment. Nous achetons un nom de domaine auprès d’un registraire (ou registrar en anglais). Ce dernier est une entreprise accréditée par l’ICANN (Internet Corporation for Assigned Names and Numbers) pour fournir des noms de domaine publics. Par conséquent, cette démarche garantit une expérience utilisateur plus professionnelle et accessible.

Bon à savoir : L’ICANN est une organisation à but non lucratif en charge de la gestion des noms de domaine et des adresses IP sur Internet.

Dans notre contexte, nous travaillons en mode « lab » dans un environnement privé. Par conséquent, nous simulons le rôle du registar. Pour cela, nous utilisons une machine Windows Client afin d’interroger notre serveur web.

Ensuite, nous modifions le fichier hosts, situé dans le dossier c:\windows\system32\drivers\etc\. Pour éditer ce fichier, nous ouvrons un éditeur de texte tel que « Notepad ». Nous veillons à exécuter cet éditeur en tant qu’administrateur avant d’ouvrir le fichier. De plus, nous sélectionnons l’option « Tous les fichiers » dans la liste déroulante « Type de fichier » pour afficher le fichier dans le champ « Nom de fichier ». Ainsi, nous pouvons apporter les modifications nécessaires de manière efficace.

Dans ce fichier, nous associons deux noms de domaine à l’adresse IP de notre serveur web. Ensuite, nous enregistrons les modifications pour que la configuration soit prise en compte. Ainsi, nous établissons le lien nécessaire entre les noms de domaine et le serveur.

Ensuite, nous vérifions la configuration en envoyant un ping sur les deux noms de domaine ajoutés dans le fichier hosts.

Dans les captures d’écran ci-dessus, nous voyons que les noms de domaine sont liés à l’adresse IP 10.0.0.3. Cela signifie que deux noms de domaine différents pointent vers la même adresse IP. Dans cet exemple, nous configurons les deux sites pour qu’ils utilisent le port 80. Ensuite, nous créons deux VirtualHost, chacun configuré pour écouter sur ce port. Pour mieux organiser les réglages, nous utilisons un fichier de configuration séparé pour chaque VirtualHost.

Configuration des VirtualHost

D’abord, nous créons un fichier de configuration dans le répertoire /etc/apache2/conf-available/. Pour rendre cela clair, nous nommons chaque fichier en utilisant le nom de domaine. Nous nous assurons aussi que le fichier a l’extension « .conf », car Apache en a besoin pour reconnaître la configuration. Cette approche simple nous aide à structurer nos fichiers de façon pratique et efficace.

belkacem@apache:~$ sudo vim /etc/apache2/conf-available/licorne.fr.conf

Dans ce fichier, nous écrivons seulement les informations nécessaires. Nous précisons d’abord le dossier où les fichiers traiteront les requêtes HTTP. Ensuite, nous ajoutons le nom de domaine qui recevra ces requêtes. Enfin, nous créons un alias pour le nom de domaine. Avec cette configuration de base, les requêtes HTTP fonctionneront correctement.

<VirtualHost *:80>
        DocumentRoot /var/www/html/licorne
        ServerName   www.licorne.fr
        ServerAlias  licorne.fr
</VirtualHost>

Dans cette configuration, nous stockons les fichiers et dossiers liés au domaine www.licorne.fr dans /var/www/html/licorne. Ce dossier n’existe pas encore, donc nous devons le créer. Cette étape permet d’organiser les fichiers du domaine de manière claire et efficace.

belkacem@apache:~$ sudo mkdir /var/www/html/licorne/

Nous y copions le fichier « index.html » présent dans /var/www/html/.

belkacem@apache:~$ sudo cp /var/www/html/index.html /var/www/html/licorne/

Nous créerons ensuite notre lien symbolique du fichier de configuration dans le répertoire /etc/apache2/sites-enabled/.

belkacem@apache:~$ sudo ln -s /etc/apache2/sites-available/ licorne.fr.conf /etc/apache2/sites-enabled/licorne.fr.conf

Pour qu’Apache prenne en compte les modifications, nous rechargeons la configuration.

Ensuite, en répétant les mêmes étapes pour le second site, nous hébergeons deux sites sur la même adresse IP. Cette méthode permet de gérer facilement plusieurs sites sur un seul serveur.

<VirtualHost *:80>
        DocumentRoot /var/www/html/panda
        ServerName   www.panda.fr
        ServerAlias  panda.fr
</VirtualHost>

belkacem@apache:~$ sudo mkdir /var/www/html/panda/
belkacem@apache:~$ sudo cp /var/www/html/port81/index.html /var/www/html/panda/
belkacem@apache:~$ sudo ln -s /etc/apache2/sites-available/ panda.fr.conf /etc/apache2/sites-enabled/panda.fr.conf

L’article 03 Héberger des sites internet avec Apache est apparu en premier sur Pandawan.

Il existe deux principales méthodes pour installer le serveur web Apache sur Ubuntu :

1. Installation via les paquets officiels de la distribution : Cette méthode est la plus simple et la plus couramment utilisée. Elle permet d’installer Apache en utilisant le gestionnaire de paquets APT, garantissant ainsi une installation rapide et une intégration aisée avec le système. Cependant, elle peut limiter l’utilisateur à la version d’Apache disponible dans les dépôts officiels d’Ubuntu.
2. Compilation à partir des sources : Cette approche offre une flexibilité accrue, permettant d’installer la version la plus récente d’Apache ou de personnaliser les options de compilation selon des besoins spécifiques. Néanmoins, elle est plus complexe et nécessite une gestion manuelle des dépendances et des mises à jour.

Installation d’Apache via APT

Pour découvrir et installer Apache en utilisant le gestionnaire de paquets APT sur Ubuntu, Nous suivrons les étapes ci-dessous :

1. Mise à jour de l’index des paquets : Avant toute installation, il est recommandé de mettre à jour l’index local des paquets pour s’assurer que le système dispose des dernières informations sur les versions disponibles. Exécutons la commande suivante :

belkacem@apache:~$sudo apt update

Installation du paquet Apache : Après la mise à jour, installons Apache en exécutant :

belkacem@apache:~$sudo apt install apache2 apache2-utils -y

Cette commande télécharge et installe Apache et les utilitaires d’Apache ainsi que toutes les dépendances requises.

En listant les processus en cours sur la machine, nous voyons qu’il est en exécution.

belkacem@apache:~$sudo ps aux | grep apache2

Le serveur Web ecoute sur le port 80 par défaut. Le client enverra une requête depuis un port dynamique, le serveur recevra cette requête sur le port 80, il doit par conséquent écouter ce port pour qu’il puisse y répondre.

Les fichiers de configuration d’un serveur Web Apache

Lors de l’installation, une liste de répertoire a été créé dans /etc/apache2/. Nous pouvons voir cette liste de répertoires en exécutant la commande suivante :

belkacem@apache:~$sudo ls -l /etc/apache2/ | egrep "^d"

Ses répertoires contiendront les configurations des futurs site internet.

• sites-available :  contient les fichiers de configuration des sites disponibles
• sites-enabled : contient des liens symboliques vers les configurations, dans site-available, des sites activés
• conf-available : contient les fichiers de configuration des autres services disponibles
• conf-enabled : contient des liens symboliques vers les configurations, dans conf-available, des autres services activés
• mods-available : contient les fichiers de configuration des modules d’Apache disponibles
• mods-enabled : contient des liens symboliques vers les configurations, dans mods-available, des modules activés

Tous ces fichiers vont venir alimenter le fichier apache2.conf.

Fichier de configuration apache2.conf

Le fichier de configuration principal d’Apache2, nommé « apache2.conf », centralise les paramètres du serveur. En l’éditant, nous observons qu’il inclut, via des directives « IncludeOptional », les configurations des répertoires précédemment mentionnés, permettant une organisation modulaire et hiérarchisée des réglages.

belkacem@apache:~$sudo cat /etc/apache2/apache2.conf | grep IncludeOptional

La directive « IncludeOptional » dans la configuration d’Apache permet d’inclure des fichiers supplémentaires de manière conditionnelle. Contrairement à la directive « Include », qui génère une erreur si le fichier spécifié n’existe pas, « IncludeOptional » ignore silencieusement les fichiers manquants. Par exemple, l’instruction « IncludeOptional conf-enabled/*.conf » inclura tous les fichiers avec l’extension .conf présents dans le répertoire conf-enabled, sans provoquer d’erreur si aucun fichier ne correspond au motif.

Les directives

La configuration d’Apache repose sur des directives spécifiques qui définissent le comportement du serveur pour différents répertoires et fichiers. Pour configurer le serveur Apache afin qu’il applique des directives spécifiques à un répertoire, on utilise la section <Directory>.

Options Indexes FollowSymLinks :

• Indexes : Active l’affichage de la liste des fichiers si aucun fichier index (comme index.html) n’est présent dans le répertoire.
• FollowSymLinks : Autorise le serveur à suivre les liens symboliques présents dans le répertoire.

AllowOverride None : Empêche l’utilisation de fichiers .htaccess pour surcharger les directives définies dans le fichier de configuration principal pour ce répertoire.

Require all granted : Accorde l’accès à tous les utilisateurs aux fichiers et sous-répertoires du répertoire spécifié.

Les modules

Apache HTTP Server est conçu de manière modulaire pour s’adapter à une variété d’utilisations. Il intègre des modules statiques, compilés directement dans le noyau du serveur, et des modules dynamiques, chargés au besoin. Pour répertorier tous les modules activés, exécutez la commande suivante :

belkacem@apache:~$sudo apache2ctm -M

Cette commande affiche la liste des modules actuellement chargés par Apache, en précisant pour chacun s’il est statique ou dynamique.

La liste des modules est disponible dans le répertoire «/etc/apache2/mods-available ».

Pour voir la liste des modules partagés c’est-à-dire marqué par (shared), il faudra lister le contenu du répertoire « /etc/apache2/mods-enabled/ ».

Si nous y regardions de plus près, nous constaterions que le nombre de module partagé et le nombre de fichier portant l’extension load, sera le même.

belkacem@apache:~$ echo -e "- nombre de fichier dans mods_enable : $(ls -1 /etc/apache2/mods-enabled/ | grep "load"| wc -l )\n- nombre de module chargé dans Apache : $(apache2ctl -M | grep "shared" | wc -l)"

Installer un module

Nous installons un module dynamique lorsque nous ajoutons un module à Apache. Un module statique, quant à lui, est directement intégré aux binaires d’Apache. Pour installer un module statique, nous devons recompiler Apache. Nous décrivons ici les étapes nécessaires pour ajouter une fonctionnalité qui réduit les risques de déni de service et d’attaques par force brute. Le module utilisé pour cet objectif est « mod_evasive ». Nous débutons par l’installation de ce module.

belkacem@apache:~$sudo apt install libapache2-mod-evasive -y

Une fois le module installé, il est chargé par défaut. Pour s’en assurer, il nous suffira de lister les modules et de recherche le mot clé « evasive ».

belkacem@apache:~$sudo apache2ctl -M | grep evasive

belkacem@apache:~$sudo apache2ctl -M | grep evasive

Configurons ce module, en créant un fichier portant l’extension « .conf ». Précédemment, nous avons vu que les fichiers de configuration des modules sont é créer dans le répertoire « /etc/apache2/mods-available/ »

belkacem@apache:~$sudo vim /etc/apache2/mods-available/evasive.conf

<IfModule mod_evasive24.c>
   # Configuration globale
   DOSHashTableSize 2048
   DOSPageCount 10
   DOSSiteCount 50
   DOSPageInterval 1
   DOSSiteInterval 1
   DOSBlockingPeriod 10
   # Configuration pour les requêtes HTTP
   DOSSystemCommand "sudo /usr/local/bin/block_ip %s"
   DOSLogDir "/var/log/mod_evasive"
   DOSWhitelist 127.0.0.1
   # Configuration pour les tentatives d'authentification
   DOSEmailNotify admin@domain.tld
   DOSLogOnly On
   DOSWhiteList /etc/apache2/mods-available/mod-evasive/whitelist
</IfModule>

Nous créerons un fichier qui contiendras les adresses IP qui ne sont pas concerné par les restrictions du module « evasive ».

belkacem@apache:~$ sudo mkdir /etc/apache2/mods-available/mod-evasive
belkacem@apache:~$ sudo vim /etc/apache2/mods-available/mod-evasive/whitelist

# Liste blanche pour mod_evasive
# Adresses IP à ignorer
127.0.0.1
10.0.0.1
# Noms d'hôte à ignorer
Localhost
client.apache.dev

Activons maintenant le module

belkacem@apache:~$ sudo a2enmod evasive

Pour que cette configuration soit prise en considération par Apache, nous devons installer recharger le configuration Apache ou redémarrer le service apache2

belkacem@apache:~$ sudo apache2ctl restart

Bon à savoir

Le module evasive à lui seul, ne peut pas offrir une garantie d’efficacité de 100% contre toutes les attaques par déni de service, il convient de l’adjoindre à d’autres mesure de sécurité (Service de protection anti-DDOS, utilisation d’un équilibreur de charge, limiter la bande passante, surveillances des journaux, etc)

L’article 02 Installation d’un serveur web Apache est apparu en premier sur Pandawan.

Tim Berners-Lee, un scientifique anglais, a créé le World Wide Web dans les années 1990 lorsqu’il travaillait au CERN (Conseil Européen pour la Recherche Nucléaire). Le World Wide Web est né dans le cadre d’un projet permettant aux scientifiques de partager leurs travaux. Comme toute communication informatique, l’échange s’appuie sur un modèle standardisé nommé TCP/IP.

Le modèle TCP/IP : La base de la communication entre Serveur Web et client

L’IETF a défini le modèle TCP/IP dans les documents RFC791 et RFC793. Il le décompose en 4 couches. Chacune de ces couches joue un rôle spécifique et s’appuie sur des protocoles pour remplir ses fonctions. Pour illustrer son fonctionnement, imaginez un bâtiment de 4 étages sans ascenseur. Pour se rendre au 4ème étage, il faut d’abord passer par le 1er, puis le 2ème, ensuite le 3ème, et enfin arriver au 4ème. On ne peut pas aller du 1er au 3ème sans passer par le 2ème étage. Tim Berners-Lee a créé le protocole HTTP pour être conforme à la logique de ce modèle de communication. Nous le situons dans la couche « Application » du modèle TCP/IP.

L’acronyme WWW (World Wide Web) et les URL

Le terme WWW est souvent utilisé dans les adresses URL (Uniform Resource Locator) pour identifier un site web accessible par un lien hypertexte. Pour accéder à ces pages, nous avons besoin d’un navigateur qui transformera notre clic sur un lien hypertexte en requête HTTP. La machine où est installé le navigateur qui nous permet d’envoyer une requête est le client, et la machine qui reçoit et traite la requête est le serveur.

En effet, cette illustration offre une vision simplifiée de la communication, mais elle met en évidence l’importance du protocole HTTP dans le World Wide Web

Le protocole TCP dans les serveurs WEB

Avant que le client puisse envoyer une requête HTTP, il doit établir une connexion TCP. Cette phase permet au client et au serveur de négocier les paramètres de connexion pour garantir que les données transmises seront correctement reçues et dans l’ordre. Le client et le serveur utilisent le processus « Three-way handshake » pour établir la connexion.

Le premier échange consiste en un paquet SYN envoyé par le client au serveur, ce paquet demande l’établissement de la connexion. Le serveur renvoie une requête SYN/ACK avec les options de connexion. Le client répond en envoyant un paquet ACK. Ce message indique au serveur qu’il a bien reçu les informations et qu’il est prêt à commencer les échanges.

Le protocole HTTP

La RFC1945 a standardisé le protocole HTTP en 1996. Cette RFC décrit les méthodes de requêtes, les codes de statut et les en-têtes. Une seconde RFC, la RFC 2616, publiée en 1999, ajoute des fonctionnalités qui permet de réduire la latence.

La version 2 du protocole HTTP ajoute des fonctionnalités de compression et de multiplexage de requêtes, ce qui améliore la vitesse de chargement. Elle intègre aussi une couche de sécurité imposant le chiffrement des requêtes. Actuellement, un travail sur la version 3 est en cours. En effet, cette nouvelle version s’appuiera sur le protocole QUIC au lieu de TCP. Ainsi le « Three-Way Handshake » sera supprimé, ce qui aura pour effet les requêtes. En observant les différentes versions du protocole, nous remarquons que l’accent est mis sur la rapidité d’exécution des requêtes HTTP et la sécurité.

Les requêtes HTTP 1.0

Une requête HTTP comprend une méthode qui spécifie l’action à effectuer sur une ressource. Dans la version HTTP/1.0, les méthodes prises en charge étaient :

• GET : utilisée pour récupérer des informations depuis le serveur.
• POST : utilisée pour envoyer des informations au serveur pour une utilisation ultérieure.
• HEAD : utilisée pour ne renvoyer que les en-têtes d’une réponse HTTP.

Les requêtes HTTP 1.1

Le protocole HTTP a été conçu pour l’échange de travaux scientifiques et non pour un usage commercial. Ces méthodes étaient suffisantes à l’époque. Cependant, avec l’essor commercial d’Internet, les quatre méthodes listées sont devenues insuffisantes. Il manquait la gestion des sessions, permettant, entre autres, à un utilisateur de s’identifier sur un site internet et de maintenir sa session active même lors de la navigation entre les pages. La version HTTP/1.1 a ajouté les méthodes suivantes :

• PUT : utilisée pour envoyer des données à un serveur pour créer ou remplacer une ressource.
• DELETE : utilisée pour supprimer une ressource sur un serveur.
• TRACE : utilisée pour envoyer une requête pour déboguer.
• OPTIONS : utilisée pour découvrir les options disponibles pour une URL donnée.
• CONNECT : utilisée pour établir une connexion à travers un proxy.
• PATCH : utilisée pour envoyer des modifications partielles à une ressource sur le serveur..

Bon à savoir :

Dans la version http/2, les méthodes seront les mêmes que pour HTTP/1.1, la différence va être sur les fonctionnalités, permettant ainsi de traiter des requêtes multiples en simultanés.

Le client recevra alors une réponse du serveur web contenant un statut sous la forme d’un code d’état, classé en cinq catégories :

• La classe 1XX : indique que la requête a été reçue et bien interprétée, mais qu’elle n’a pas encore été traitée.
• La classe 2XX : indique que la requête a été traitée avec succès.
• La classe 3XX : indique que le serveur a besoin de plus d’informations pour traiter la requête (par exemple, une redirection vers une autre URL).
• La classe 4XX : indique que la requête contient une erreur.
• La classe 5XX : indique que le serveur a rencontré une erreur en tentant de traiter la requête.

L’article 01 Serveur web et ses protocoles est apparu en premier sur Pandawan.

Création d’un répertoire de travail

Pour ce projet, nous créer un nouveau répertoire sur notre machine hôte, puis nous allons nous y rendre.

[root@docker ~]# mkdir /home/stack-lamp-compose-dockerfile
[root@docker ~]# cd /home/stack-lamp-compose-dockerfile

Création du Dockerfile pour MariaDB

Dans ce répertoire nous créerons notre premier dockerfile pour le conteneur « mariadb ».

[root@docker stack-lamp-compose-dockerfile]# vi dockerfile-mariadb
Contenu du dockerfile MariaDB
# Utilisez l'image officielle MariaDB
FROM mariadb:latest
# Définir les variables d'environnement
ENV MYSQL_ROOT_PASSWORD=p@ssw0rd1 \
MYSQL_DATABASE=wordpress \
MYSQL_USER=wordpress_user \
MYSQL_PASSWORD=p@ssw0rd1
# Copiez le script d'initialisation
COPY init.sql /docker-entrypoint-initdb.d/
# Exposez le port 3306 pour MariaDB
EXPOSE 3306

Dans ce dockerfile, nous allons copier un fichier « init.sql », ce fichier que nous allons créer contiendras les requêtes SQL :

• Création de la base de données
• Création de l’utilisateur
• La gestion des droits de l’utilisateur sur la base de données

[root@docker stack-lamp-compose-dockerfile]# vi init.sql

Contenu init.sql

CREATE DATABASE IF NOT EXISTS wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress_user'@'%' IDENTIFIED BY 'p@ssw0rd1';
FLUSH PRIVILEGES;

Ce script sql devra avoir le droit en exécution.

[root@docker stack-lamp-compose-dockerfile]# chmod +x init.sql

Création du Dockerfile pour MariaDB

Nous créerons également le Dockerfile pour le serveur web et WordPress.

[root@docker stack-lamp-compose-dockerfile]# vi dockerfile-wordpress

Contenu du Dockerfile WordPress

# Utilisez l'image Ubuntu la plus récente
FROM ubuntu:latest
# Mises à jour et installations nécessaires
RUN apt-get update \
&& export DEBIAN_FRONTEND=noninteractive \
&& apt-get install -y apache2 php libapache2-mod-php php-mysql mysql-client php-gd php-curl php-zip php-mbstring php-xml wget \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
&& cd /var/www/html/
&& rm index.html
# Télécharger et configurer WordPress
RUN cd /var/www/html && \
wget https://wordpress.org/latest.tar.gz && \
tar -xzvf latest.tar.gz --strip-components=1 && \
rm latest.tar.gz && \
mv wp-config-sample.php wp-config.php && \
sed -i 's/database_name_here/wordpress/g' wp-config.php && \
sed -i 's/username_here/wordpress_user/g' wp-config.php && \
sed -i 's/password_here/p@ssw0rd1/g' wp-config.php && \
sed -i 's/localhost/mariadb-server/g' wp-config.php && \
chown -R www-data:www-data /var/www/html
# Attribue une adresse IP au serveur web
CMD ["apache2ctl", "-D", "FOREGROUND"]
# Expose le port 80 pour Apache
EXPOSE 80

Nous créerons le fichier Docker-Compose qui s’appuiera sur les deux Dockerfile que nous avons créé.

version: '3.8'
services:
# Service pour le serveur web Apache
web-server:
container_name: wp
build:
context: .
dockerfile: dockerfile-wordpress
depends_on:
- mariadb-server
ports:
- "80:80"
# Service pour la base de données MariaDB
mariadb-server:
container_name: mariadb-server
build:
context: .
dockerfile: dockerfile-mariadb

Déploiement de conteneur en s’appuyant sur Dockerfiles et Docker Compose

Nous pouvons tester que notre déploiement de WordPress est maintenant fonctionnel.

[root@docker stack-lamp-compose-dockerfile]# docker-compose up -d

Depuis un navigateur, nous allons tenter de nous connecter à notre serveur WEB.

L’approche qui combine Docker Compose et Dockerfiles segmente le travail de développement et de déploiement d’applications en conteneurs. En effet, cette segmentation introduit une séparation claire des responsabilités à plusieurs niveaux.

Tout d’abord, les Dockerfiles décrivent en détail la construction des images de conteneurs. Ainsi, les développeurs définissent les dépendances, les configurations et les étapes d’installation spécifiques à chaque composant de l’application. Grâce à cette séparation des préoccupations, les développeurs peuvent se concentrer sur la construction et la maintenance des images conteneurs, sans avoir à gérer la configuration des environnements de déploiement.

En parallèle, Docker Compose intervient au niveau de la composition et de la gestion de l’ensemble de l’application. En effet, les opérations d’orchestration des conteneurs, la gestion des réseaux et la coordination entre les services sont encapsulées dans le fichier docker-compose.yml. De cette manière, les équipes opérationnelles peuvent se concentrer sur la gestion des aspects liés au déploiement global de l’application, en utilisant une configuration déclarative simplifiée.

Cette segmentation du travail permet donc une collaboration plus fluide entre les équipes de développement et d’exploitation. Les développeurs créent des environnements conteneurisés spécifiques à leurs applications, tandis que les opérations prennent en charge l’orchestration et la gestion des déploiements à grande échelle. En résumé, Docker Compose et Dockerfiles encouragent une approche modulaire et efficace du développement et du déploiement d’applications en conteneurs.

L’article 10 – Le combo Dockerfile et Docker Compose est apparu en premier sur Pandawan.

Présentation de Docker Compose

Docker Compose est un service qui permet d’envoyer des instructions à Docker, telles que la spécification des dépendances, des informations de configuration et des interactions, afin de créer et de gérer des conteneurs Docker pour une application multi-conteneurs. Les instructions sont données sous forme de mot clé dont en voici les principaux utilisés :

Les instructions doivent être contenu dans un fichier qui se nommera « docker-compose.yml ». Dans ce Docker compose, nous allons pouvoir faire des appels à des Dockerfiles. Dans un premier temps nous nous concentrerons sur Docker compose. Cela nous permettra de comprendre sont fonctionnement. Dans un second temps nous verrons comment faire fonctionner Docker-compose avec des Dockerfiles.

Exemple de Docker-compose

Pour illustrer, nous prendrons comme exemple la conteneurisation d’un stack LAMP (Linux Apache MariaDB et PHP) où nous installerons WordPress.

Installation de Docker Compose

Avant cela, nous allons avoir besoin d’installer l’outils Docker Compose. Docker Compose est un outil écrit en Python et il est distribué via le gestionnaire de paquet Python appelé « pip ».

Installation le gestionnaire pip puis nous installerons Docker-Compose.

[root@docker ~]# dnf install -y python3-pip
[root@docker ~]# pip3 install docker-compose

Création environnement de travail

Ensuite, nous créerons ensuite un répertoire de travail.

[root@docker ~]# mkdir /home/Stack-LAMP

Création du fichier YAML

Nous ne rendrons dans le répertoire que nous avons créés , nous créerons un fichier nommé « docker-compose.yml ». Nous éditerons ce fichier à l’aide d’un éditeur de texte en ligne de commande (nano, vi, etc…)

[root@docker ~]# cd /home/Stack-LAMP/

[root@docker Stack-LAMP]# vi docker-compose.yml

Contenu du fichier de YAML

Pour rappel, les fichiers YAML à une syntaxe basée sur l’indentation (espaces ou tabulations). Cette contrainte rend le code plus lisible mais exige une attention particulière à la mise en forme. Rappelons également YAML est sensible à la case.

Dans un premier temps , nous allons définir la version de la syntaxe qui sera utilisé dans ce fichier. La version de la syntaxe est liée à la version de Docker Engine installée sur la machine. Dans notre exemple, nous sommes en version 24.0.5, nous utiliserons la version 3.8.

Nous commencerons donc notre fichier à déclarer la version de la syntaxe.

version: '3.8'

Déclaration des services

Ensuite, nous allons spécifier nos services : un container hébergera la base de données, le second hébergera le serveur web et l’application WordPress. Ses informations seront renseignées dans la section « services ».

version: '3.8'
services :
#Service base de données
db :
#Instruction
# Web Server et wordpress
wordpress :
#Instruction

Instruction pour le service db

Dans les instructions du conteneur db, nous indiquerons l’images que nous utiliserons, à savoir l’image officiel de mariadb dans sa dernière version, les données de la base de données devront être persistante, nous montrons donc un volume.

services :
#Service base de données
db:
 image: mariadb:latest
 volumes:
 - db_data:/var/lib/mysql
# Web Server et wordpress
wordpress :
#Instruction

Nous allons définir les variables d’environnement pour paramétrer la base de données, en spécifiant un mot de passe pour l’utilisateur root. Nous créerons également un utilisateur dédié à la gestion de la base de données WordPress, avec un identifiant et un mot de passe spécifiques, et créerons une base de données dédiée à WordPress.

services :
#Service base de données
db:
image: mariadb:latest
volumes:
- db_data:/var/lib/mysql
 environment:
 MYSQL_ROOT_PASSWORD: p@ssw0rd1
 MYSQL_DATABASE: wordpress
 MYSQL_USER: wordpress_user
 MYSQL_PASSWORD: p@ssw0rd1
# Web Server et wordpress
wordpress :
#Instruction

Instruction pour le service WordPress

Le conteneur de notre base de données étant configuré, nous pouvons maintenant passer à la création de notre conteneur WordPress. Nous indiquerons que le conteneur « wordpress » dépend du conteneur « db », cela aura pour conséquence que Docker s’assurera que le container « db» soit démarrer avant le container « Apache ».

services :
#Service base de données
db:
#+---------------+
#|Instruction db |
#+---------------+
# Web Server et wordpress
wordpress :
 depends_on:
 - db
 image: wordpress:latest

Le conteneur « wordpress » sera en écoute sur le port 80 de la machine hôte, il nous faut donc mapper le port 80 de notre conteneur (qui est le port pas défaut d’écoute du serveur web) sur le port 80 de la machine hôte.

services :
#Service base de données
db:
#+---------------+
#|Instruction db |
#+---------------+
# Web Server et wordpress
wordpress :
depends_on:
- db
image: wordpress:latest
 ports:
 - "80:80"

Les données de l’application seront persistantes, nous créerons le volumes pour stocker les fichiers de WordPress.

services :
#Service base de données
db:
#+---------------+
#|Instruction db |
#+---------------+
# Web Server et wordpress
wordpress :
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
 volumes:
 - wordpress_data:/var/www/html

Pour conclure la configuration du conteneur, nous configurerons notre environnement pour permettre à WordPress de se connecter à la base de donnée que nous avons préparer dans le conteneur « db ».

services :
#Service base de données
db:
#+---------------+
#|Instruction db |
#+---------------+
# Web Server et wordpress
wordpress :
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
volumes:
- wordpress_data:/var/www/html
 environment:
 WORDPRESS_DB_HOST: db
 WORDPRESS_DB_USER: wordpress_user
 WORDPRESS_DB_PASSWORD: p@ssw0rd1
 WORDPRESS_DB_NAME: wordpress

Gestion des volumes

Pour assurer la persistance des données des volumes utilisées par nos conteneurs, nous devons les déclarés explicitement. Nous monterons le volumes que nous avons utilisées dans nos conteneurs.

services :
#Service base de données
db:
#+---------------+
#|Instruction db |
#+---------------+
# Web Server et wordpress
wordpress :
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
volumes:
- wordpress_data:/var/www/html
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress_user
WORDPRESS_DB_PASSWORD: p@ssw0rd1
WORDPRESS_DB_NAME: wordpress
volumes:
 db_data:
 wordpress_data:

Exécution du Docker compose

Nous exécuterons ce docker-compose à l’aide de la commande suivante :

[root@docker Stack-LAMP]# docker compose up

Après avoir exécuter la commande, un certain nombre de tâche s’exécute, notamment les téléchargement des images utilisées dans le fichier docker-compose.yml. Une fois que toutes les tâches ont été exécuté, nous testerons l’accès à notre serveur WordPress depuis un navigateur.

Exécution de nos conteneur en arriere plan avec Docker-compose

Notre serveur est pleinement opérationnel. Ceux-ci étant dit, nous avons perdu l’accès à notre terminal, en effet, il est attaché à nos conteneurs, si nous le détachons cela provoquera l’arrêt des conteneurs. Pour exécuter les containeurs en arrière-plan, nous devons ajouter le commutateur « -d », lorsque nous exécutons le docker-compose. Pour tester cette commande, nous allons supprimer ce que nous avons fait, nous tuerons nos conteneurs à l’aide de la combinaison de touche [ctrl]+[c].

Nous supprimerons les services à l’aide de la commande suivante :

[root@docker Stack-LAMP]# docker compose down

Dans notre docker-compose des volumes sont créés, nous les supprimerons afin de repartir d’une configuration initiale, nous listerons les volumes pour récupérer leurs noms complets.

[root@docker Stack-LAMP]# docker volume list | grep "stack-lamp"

[root@docker Stack-LAMP]# docker volume rm stack-lamp_db_data stack-lamp_wordpress_data

Nous exécutons à nouveau le docker-compose en précisant l’option « -d ».

Docker Compose offre une approche déclarative, simplifiant la définition complète d’une application, de ses services, de ses dépendances et de ses configurations dans un unique fichier (docker-compose.yml). Cette approche favorise un déploiement homogène et reproductible en décrivant l’état souhaité sans spécifier les détails de mise en œuvre.

Pour exploiter pleinement Docker Compose, il est essentiel de comprendre comment l’associer à un autre élément clé de l’écosystème Docker que nous avons vu plus tôt : les Dockerfiles.

L’article 09 Docker Compose : Création et gestion de multi-conteneur est apparu en premier sur Pandawan.

Il pourrait s’avérer fastidieux de recréer cette image à chaque que nous souhaitons la reproduire. Au lieu de cela, nous créer un fichier qui contiendras toutes les instructions pour créer notre image docker personnalisé. Ce fichier s’appelle un DockerFile, il listera un ensemble d’instruction qui sont défini par des mots clés, les Dockerfiles. En voici une liste non-exhaustive :

• FROM : Spécifie l’image de base à partir de laquelle vous allez construire votre image. L’argument est le nom de l’image de base, par exemple : FROM ubuntu:20.04.
• RUN : Exécute une commande dans l’image pour installer des logiciels, mettre à jour des paquets, créer des répertoires, etc. L’argument est la commande à exécuter, par exemple : RUN apt-get update && apt-get install -y apache2.
• CMD : Définit la commande par défaut à exécuter lorsque le conteneur est lancé. L’argument est la commande, généralement sous forme d’une liste, par exemple : CMD [« apachectl », « -D », « FOREGROUND »].
• EXPOSE : Spécifie les ports sur lesquels le conteneur écoutera. L’argument est le numéro de port ou une plage de ports, par exemple : EXPOSE 80.
• ENV : Définit des variables d’environnement pour l’image. L’argument est une paire clé-valeur, par exemple : ENV MY_VARIABLE= »valeur ».
• ADD : Copie des fichiers depuis le système de fichiers hôte dans l’image, tout en permettant des opérations plus avancées. L’argument est le chemin source et de destination, par exemple : ADD app.tar.gz /app.
• COPY : Copie des fichiers depuis le système de fichiers hôte dans l’image, sans les opérations avancées offertes par ADD. L’argument est le chemin source et de destination, par exemple : COPY index.html /var/www/html/.
• WORKDIR : Définit le répertoire de travail actuel pour les instructions suivantes dans le Dockerfile. L’argument est le chemin du répertoire, par exemple : WORKDIR /app.
• USER : Spécifie l’utilisateur ou l’identifiant de l’utilisateur sous lequel les commandes RUN, CMD, et ENTRYPOINT sont exécutées. L’argument est le nom de l’utilisateur ou l’identifiant.
• VOLUME : Crée un point de montage de volume pour le stockage de données persistantes en dehors du conteneur. L’argument est le chemin du point de montage, par exemple : VOLUME /data.

En somme toutes les étapes que nous avions réalisées dans le chapitre 03 Image Docker pour créer nos images peuvent être fait à l’aide d’un Dockerfile.

Création un DockerFile

Dans cette mise en pratique nous allons créer un Dockerfile qui nous permettra d’exécuter PHP en version 7.4.Nous commencerons par créer un répertoire de travail.

[root@docker ~]# mkdir /home/MonProjet

Aprés avoir créer ce répertoire, nous allons créer un fichier, qui devra se nommer Dockerfile.

[root@docker ~]# vi /home/MonProjet/Dockerfile

Dans ce fichier, nous allons renseigner les instructions pour la création de mon image. Nous indiquerons l’image que nous souhaitons utiliser.

# Utilisation d’une image Ubuntu de base
FROM ubuntu:latest

Supprimons maintenant toutes les interactivités imposée lors de l’installation de paquets en utilisant les Dockerfiles.

ENV DEBIAN_FRONTEND=nonintercative

Nous mettons ensuite à jours la distribution puis nous installons le service Apache2.

# Mise à jour des packages et installation d'Apache2
RUN apt update -y && apt install -y apache2

Installons les dépendances nécessaires à l’installation de PHP 7.4 puis nous installerons PHP.

# Installation de PHP7.4

RUN apt install software-properties-common -y && add-apt-repository ppa:ondrej/php -y && apt install php7.4 -y

Nous exposerons le port 80 de notre image.

# Exposer le port 80 pour Apache
EXPOSE 80

Ensuite créons le volume pour rendre les données persistantes. Pour cette étape, nous créerons le répertoire sur notre machine. Ensuite nous le monterons dans un volume de notre image.

# Créez un répertoire pour les données d'Apache et configurez un point de montage de volume
RUN mkdir /var/www/html/data
VOLUME /var/www/html/data

Nous créerons un fichier PHP qui affichera les informations PHP.

# Créez un fichier PHP qui exécute phpinfo()
RUN echo "" > /var/www/html/data/phpinfo.php

Nous démarrerons ensuite PHP.

# Démarrer Apache en premier plan
CMD ["apachectl", "-D", "FOREGROUND"]

Executer le DockerFile

La liste de ses instructions, vont être exécuté lorsque nous créerons notre image à l’aide de la commande « docker build ». Nous allons nous rendre dans le répertoire de travail où se trouver notre Dockerfile afin d’exécuter les Dockerfiles.

[root@docker ~]# cd /home/MonProjet/

Dans ce répertoire, nous exécuterons la commande de création de notre image, en lui donnant un nom.

[root@docker MonProjet]# docker build -t php74 .

Une fois la commande exécutée, nous voyons les étapes de la création.

Nous vérifierons que l’images à bien été ajouter à notre registre interne.

[root@docker MonProjet]# docker images | grep php74

Testons cette images, après avoir créé notre instance, nous tenterons d’accéder à notre page « phpinfo.php », en utilisant les Dockerfiles correctement configurés.

[root@docker MonProjet]# docker run -d -p 80:80 php74

L’article 08 Dockerfiles : Automatiser la création d’image Docker est apparu en premier sur Pandawan.

Nous créons des images et les stockons sur notre propre ordinateur. À mesure que nos projets se développent, nous utiliserons un Docker registry pour partager ces images personnalisées. La première idée qui nous vient souvent à l’esprit est de les stocker sur une plateforme publique, comme Docker Hub.

Limitations de Docker Hub gratuit

Néanmoins, il est important de noter que la version gratuite de Docker Hub présente certaines limitations. La capacité totale de stockage peut être restreinte, ce qui constitue une des principales limitations. Pour des projets de petite envergure, cette limite peut être suffisante. Cependant, pour des projets plus importants ou des équipes de développement collaboratives, cette capacité limitée peut rapidement devenir un obstacle. De plus, la version gratuite peut également imposer des restrictions de bande passante, de vitesse de téléchargement et de stockage. Ces restrictions peuvent affecter la rapidité avec laquelle vous pouvez distribuer vos images.

Création d’un registre Docker privé

Pour les projets nécessitant un espace de stockage plus important, il peut être judicieux de créer un registre Docker privé. Cette option offrira un contrôle total sur l’espace de stockage, la bande passante et la vitesse.

Sécurité et confidentialité

Lorsque nous utilisons Docker Hub en version gratuite, les images sont par défaut publiques. Toute personne connaissant le nom de référence de notre image peut y accéder et la télécharger. Cette caractéristique avantage les projets open source ou les collaborations publiques. Cependant, pour les projets sensibles ou privés, elle pose des problèmes de sécurité ou de confidentialité. Nous devons donc prendre en compte cette caractéristique publique lors du choix de l’outil pour héberger nos images Docker.

Options pour la confidentialité

Si la confidentialité est une préoccupation, nous devrions passer à un abonnement payant sur Docker Hub. Une autre option est de créer notre propre Docker Hub, appelé un Registry local. Pour certains projets, créer notre propre registre Docker privé est la meilleure solution pour avoir un contrôle total.

Mise en place d’un conteneur privé local

Dans ce ce chapitre, nous allons explorer le processus d’installation d’un registre Docker privé. Notons que cet outil était autrefois appelé « Docker Registry », a été renommé en « Docker Distribution » dans sa version 2.

Téléchargerons l’image depuis le portail Docker hub.

[root@docker ~]# docker pull registry

Ensuite, créerons ensuite un répertoire sur notre machine local pour y stocker les images.

[root@docker ~]# mkdir -p /var/lib/registry

Maintenant, nous pouvons démarrer notre instance docker-registry

[root@docker ~]# docker run -d -p 5000:5000 --restart=always --name registry -v /var/lib/registry:/var/lib/registry registry:latest

Ajout dimage dans Docker registry local

Nous allons ensuite peupler ce registre en y envoyant nos images que nous avons créé précédemment. Il nous faudra modifier le « tag » puis pousser l’image vers notre registre.

[root@docker ~]# docker tag srv_web_php8 localhost:5000/srv_web_php8 
[root@docker ~]# docker push localhost:5000/srv_web_php8

En nous rendant dans le catalogue de notre registre, nous pouvons remarquer que nous voyons notre image.

[root@docker ~]# curl http://localhost:5000/v2/_catalog

Nous suivrons la même approche pour les images « reverse-proxy » et « srv_web_php7 ». Tout d’abord, nous allons modifier le tag de ces images :

[root@docker ~]# docker tag srv_web_php7 localhost:5000/srv_web_php7
[root@docker ~]# docker tag reverse-proxy localhost:5000/reverse_proxy

Ensuite, nous allons les téléverser vers notre registry local :

[root@docker ~]# docker push localhost:5000/srv_web_php7
[root@docker ~]# docker push localhost:5000/reverse_proxy

De cette manière, notre catalogue d’images dans le registry local s’enrichira avec ces nouvelles images. Le déplacement d’une image vers un autre dépôt n’entraîne pas la suppression de l’image d’origine. En réalité, l’attribution d’un tag à une image n’est qu’un alias. Cela devient évident lorsque nous examinons notre liste d’images en filtrant :

• par la chaîne de caractères « srv » pour nos images « srv_web_php7 » et « srv_web_php8 »,
• par « reverse» pour notre image « reverse-proxy ».

[root@docker ~]# docker images --format {{.Repository}} | grep -E 'srv|reverse'

Nous supprimerons les images que nous avons transférer dans notre repository local.

[root@docker ~]# docker rmi reverse-proxy srv_web_php8 srv_web_php7

Ajouter le Docker registry en utilisant Portainer

Nous ajouterons notre Docker registry dans Portainer, après nous être connecter, nous sélectionnerons dans le menu latéral gauche « Registries ».

Nous cliquerons ensuite sur le bouton « Add registry ».

Dans la page d’ajout de registry, nous sélectionnerons « Custom Registry », puis dans le formulaire en dessous, nous indiquerons un nom, puis l’adresse de notre registry, dans notre contexte, Portainer et notre registry sont installés sur la même machine, nous indiquerons donc notre adresse IP localhost avant de cliquer sur le bouton « Add Registry ».

De retour sur notre pages « Regestries », notre Docker registry est maintenant listé et donc ajouté.

Pour conclure cette partie, rappelons qu’un registry permet de centraliser les images de conteneurs dans un seul emplacement, ce qui facilite la gestion et le partage des images entre les équipes. Un registre Docker peut également être utilisé pour améliorer la sécurité et les performances des applications conteneurisées.

L’article 07 Docker registry : un registre Docker privé est apparu en premier sur Pandawan.

Présentation de Portainer

Portainer vous offre une interface de gestion conviviale pour les conteneurs et les images Docker, simplifiant ainsi la gestion des conteneurs Docker. Étant lui-même un conteneur Docker, vous pouvez facilement le déployer sur votre système Docker. En se connectant à l’API Docker de votre système, Portainer vous permet de visualiser et de gérer tous les aspects de Docker via une interface web conviviale. Par conséquent, vous pouvez créer et gérer des images, des conteneurs, des volumes et des réseaux sans avoir à mémoriser des commandes Docker complexes. Une fois connecté à Portainer via un navigateur web, vous pouvez alors effectuer des tâches telles que :

• le déploiement de nouveaux conteneurs à partir d’images existantes,
• la surveillance en temps réel des performances de vos conteneurs,
• la gestion de volumes de stockage, et la configuration de réseaux pour vos conteneurs.

Un des avantages de Portainer est sa simplicité d’installation et d’utilisation. Cet avantage fait de Portainer un outil idéal pour gérer Docker.

Installation de Portainer et lancement du conteneur Docker

L’installation est également simplifiée, car Portainer est fourni sous forme d’image Docker, ce qui le rend facile à déployer. Globalement, Portainer facilite la gestion de Docker en rendant les opérations courantes plus simples.

L’image Docker que nous utiliserons est « portainer/portainer-ce :latest ». Nous mapperons deux ports :

• le 8000 qui servira aux requêtes http
• le 9443 pour les requêtes https.

Nous ajouterons l’argument « –restart=always ». Cet argument permet au conteneur de démarrer automatiquement à chaque redémarrage du service Docker.

De plus, Nous monterons deux volumes :

• -v /var/run/docker.sock:/var/run/docker.sock: On monte le socket Docker de l’hôte (/var/run/docker.sock) dans le conteneur. Cela permet à Portainer d’interagir avec le démon Docker de l’hôte, ce qui permettra la gestion des conteneurs.

• -v portainer_data:/data: Cet indicateur monte un volume nommé « portainer_data » dans le conteneur à l’emplacement « /data ». Ce volume est utilisé pour stocker les données de configuration et de stockage persistantes de Portainer.

En considérant tous les points que nous avons traités la commande sera la suivante :

[root@docker ~]# docker run -d -p 9000:9000 -p 9443:9443 -p 8000:8000 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Dans l’exemple précédent, nous lançons le conteneur Portainer directement. Comme nous n’avons pas encore téléchargé l’image spécifiée dans la commande, Docker la télécharge automatiquement depuis la plateforme Docker Hub.

Nous configurerons notre pare-feu pour qu’autoriser les requêtes sur le port 9443 et 8000.

[root@docker ~]# firewall-cmd --add-port=8000/tcp --permanent
[root@docker ~]# firewall-cmd --add-port=9443/tcp --permanent
[root@docker ~]# firewall-cmd --reload

Accéder à l’interface web de l’outil

Depuis le navigateur de notre machine connectée au même réseau que celle exécutant Docker, nous devons d’abord accéder à l’URL https://:9443. Ensuite, nous recevrons un avertissement de sécurité car nous utilisons un certificat autosigné. Une fois que nous sommes sur l’interface Portainer, nous serons alors invités à renseigner un mot de passe pour l’utilisateur « admin ». Après avoir configuré le mot de passe, nous pourrons commencer à utiliser Portainer pour gérer nos conteneurs Docker. Enfin, assurons-nous de sauvegarder nos informations de connexion pour un accès futur..

Présentation de l’interface web

Depuis le navigateur de notre machine connectée au même réseau que celle exécutant Docker, nous accédons d’abord à l’URL https://:9443. Ensuite, nous recevons un avertissement de sécurité car nous utilisons un certificat autosigné. Une fois sur l’interface Portainer, nous renseignons un mot de passe pour l’utilisateur « admin ». Après avoir configuré le mot de passe, nous commençons à utiliser Portainer pour gérer nos conteneurs Docker. Enfin, nous sauvegardons nos informations de connexion pour un accès futur.

Nous avons un bref récapitulatif de notre environnement local, dans la capture ci-dessous, nous pouvons voir que nous avons 4 conteneurs qui tournent, 2 volumes ou encore 5 images, nous avons également accès à des informations liées à l’hôte, nous voyons que notre hôte a 4 CPU et 3.8 Go de ram. Pour avoir plus de détails, nous cliquerons sur le bandeau « local ».

En cliquant sur le bandeau « local », nous accédons à une interface qui offre plus d’information et plus d’options sur Portainer.

Sur la partie latérale de Portainer, nous avons accès aux différents composants de Docker. Cliquons sur Containers, nous devrions y voir nos conteneurs et leurs états.

Dans la section Images de Portainer, nous avons accès à nos images, celles qui ne seront pas utilisées seront marquées « Unused ». Nous voyons, en haut de page, que le registry, c’est-à-dire l’endroit où Docker ira chercher les images par défaut. Il est tout à fait possible de télécharger les images Docker en indiquant leur nom dans le champ images.

Dans la partie réseau, il nous sera possible de voir les réseaux créés à l’installation de Docker. Ils sont reconnaissables au tag « system » mais aussi ceux que nous avons créés.

En cliquant sur le nom du réseau, nous connaîtrons les conteneurs qui y sont connectés. Par exemple, reseau_php7 contient deux conteneurs « rp » et « app-php7 ».

La logique restera un peu la même pour les volumes de Portainer.

L’article 06 Gestion des conteneurs et Images Docker avec portainer.io est apparu en premier sur Pandawan.

Contexte de la mise en pratique de l’isolation d’un conteneur Docker

Pour illustrer le concept de l’isolation de conteneur Docker, prenons un exemple concret. Supposons que vous ayez une application web relativement ancienne qui exige PHP7. En outre, sur cette machine, vous souhaitez également installer une autre application plus récente qui nécessite la version PHP8. Dans une installation traditionnelle, vous auriez besoin de deux machines virtuelles distinctes (ou deux machines physiques). Cependant, en les intégrant dans un conteneur Docker, nous pouvons exécuter les deux applications sur la même machine en s’appuyant sur des conteneurs Docker. Ainsi, cela évitera la complexité et les coûts supplémentaires associés à la gestion de plusieurs machines. C’est ce concept de la conteneurisation que nous allons couvrir dans un premier temps.

Création d’un conteneur Docker exécutant php7

Nous illustrerons cet exemple par une mise en pratique. Précédemment, nous avons récupérer une image Ubuntu, nous allons nous en servir pour créer un conteneur Docker.

Nous créerons ce conteneur Docker que nous nommerons « apache_php7 » soit la commande suivante :

[root@docker ~]# docker run -it --name apache_php7 ubuntu

Après avois créé notre conteneur Docker, nous mettrons à jours ce dernier.

root@94331d07f35a:/# apt update -y
root@94331d07f35a:/# apt upgrade -y

Installation serveur web Apache

PHP a besoin d’un serveur web pour fonctionner. Apache est l’un des serveurs web les plus couramment utilisés pour exécuter des applications PHP. Par conséquent nous installerons « Apache httpd »

root@94331d07f35a:/# apt install apache2 -y

Installation de PHP 7.4

La version 22.04 d’Ubuntu inclut des dépôts qui fournissent PHP dans sa version 8 par défaut. Si nous souhaitons installer la version 7 de PHP, nous devrons recourir à un PPA (Personal Package Archive). Dans le PPA de ondrej nous y retrouverons les packages requis pour installer PHP 7. Pour pouvoir ajouter un PPA, nous allons avoir besoin de l’utilitaire « add-apt-repository » présent dans le package « software-properties-common ».

root@94331d07f35a:/# apt install software-properties-common -y
root@94331d07f35a:/# add-apt-repository ppa:ondrej/php -y
root@94331d07f35a:/# apt install php7.4 -y

Lors de l’installation, il nous sera demandé le choix de zone géographique pour configurer le fuseau horaire de php (php.ini).

Vérifions que la version de PHP est effectivement bien la version 7 à l’aide de la commande suivante : .

root@94331d07f35a:/# php --version

Nous allons générer un fichier qui exécute la fonction phpinfo(), ce qui nous permettra d’afficher la configuration de PHP. Ce fichier sera placé dans le répertoire par défaut d’Apache, qui est /var/www/html.

La configuration est terminé . Nous sortirons de notre conteneur à l’aide de la combinaison de touche [ctrl]+[p], [ctrl]+[q].

Nous listerons nos conteneurs pour s’assurer que celui que nous venons de créer est bien présent et actif.

[root@docker ~]# docker ps

Mappage de port

Pour accéder à ce conteneur Docker, nous devons associer le port d’écoute du conteneur au port de la machine hôte. Dans notre exemple, nous avons conteneurisé un serveur web Apache. Le serveur apache par défaut écoute sur le port 80. En mappant le port 80 du conteneur au port 80 de la machine hôte, il sera accessible via son IP. L’adresse de la machine utilise l’adresse 10.0.0.3, cette sur cette adresse que le serveur web sera accessible

Nous n’avons pas précisé d’écoute à la création de notre container. Par conséquent, nous pouvons constater que le conteneur n’écoute sur aucun port.

Dans la partie suivante, nous verrons comment convertir ce conteneur Docker en une image. En effet, pour exposer le port 80 de notre conteneur Docker, nous devons le préciser au lancement de l’image. Dans notre cas, si nous ne convertissons pas le conteneur Docker en une image Docker, nous devrions tout refaire. Le fait de convertir ce conteneur Docker en image Docker, nous permettra de repartir de là où on en était.

Convertir un conteneur Docker en image Docker

Configurez le mappage de port lors de la création du conteneur Docker. Ensuite, pour éviter de répéter toutes les commandes utilisées pour créer ce conteneur, transformez-le en une image. Appelez cette image srv_web_php7 et ajoutez-y un tag.

[root@docker ~]# docker commit apache_php7 srv_web_php7:latest

Nous vérifierons que l’image Docker a bien été ajouter sur la machine hôte.

[root@docker ~]# docker images

Supprimer un conteneur

Nous répliquons la configuration de cette image chaque fois que nous l’utilisons pour créer un conteneur Docker. En résumé, nous pouvons supprimer le conteneur Docker utilisé pour créer cette image. Pour cela, nous commençons par arrêter le conteneur Docker, puis nous le supprimons. Enfin, nous vérifions que le conteneur Docker a bien été supprimé.

[root@docker ~]# docker stop apache_php7
[root@docker ~]# docker rm apache_php7
[root@docker ~]# docker ps -a

Supprimer plusieurs conteneurs

Pour rappel, un conteneur est conçu pour être léger et jetable. Donc, dans une utilisation typique, lorsqu’un conteneur est éteint, il n’a généralement plus de raison d’être. Nous supprimerons donc les conteneurs stockés sur la machine hôte après avoir arrêté ceux qui sont en statut « UP ».

[root@docker ~]# docker stop 7c85ed7d6261
[root@docker ~]# docker rm -f $(docker ps -aq)

Explication de la commande :

• docker ps -aq : liste tous les conteneurs, en incluant ceux qui ne sont pas en cours d’exécution
• docker rm -f supprime tous les conteneurs dont les IDs sont renvoyés par la commande précédente.

Nous vérifierons qu’il n’y a plus aucun conteneur.

[root@docker ~]# docker ps -a

Exposition d’un port d’un conteneur Docker

Maintenant nous avons un environnement sans aucun conteneur préexistant.Nous testerons notre image précédemment créé. Cette fois nous mapperons le port 80 du conteneur et le port 80 de la machine. Étant donné que le service httpd d’Apach n’est pas démarrer par défaut, nous allons le lancer manuellement.

[root@docker ~]# docker run -it -p 80:80 --name php7 srv_web_php7
root@81610801a595:/# apachectl start

L’adresse IP de la machine est 10.0.0.3. Par conséquent,le serveur Web de notre conteneur sera accessible à partir de cette adresse. Pour permettre à la machine hôte de recevoir des requêtes sur le port 80. Il nous faudra donc configurer le pare-feu de la machine hôte pour autoriser le trafic entrant sur ce port.

root@81610801a595:/# [ctrl]+[P] & [ctrl]+[Q]
[root@docker ~]# firewall-cmd --add-service=http --permanent
[root@docker ~]# firewall-cmd –reload

En lançant un navigateur depuis une machine connectée au même réseau nous nous connecterons à l’URL http://10.0.0.3/. Nous devrions avoir accès à notre serveur WEB

Nous nous rendrons sur http://10.0.0.3/phpinfo.php, pour vérifier que nous utilisons PHP version 7.

Création d’un conteneur en exécutant php8

La création de notre conteneur Docker qui exécutera PHP 8 suivra la même logique que conteneur exécutant PHP 7. Nous commencerons à partir de notre image Ubuntu de base. Nous installerons à la fois le service httpd d’Apache Foundation et PHP. Il est important de noter que la version 8 de PHP est disponible par défaut dans les dépôts d’Ubuntu 22.04. Par conséquent nous n’aurons pas besoin de recourir à l’utilisation de PPA (Personal Package Archive) pour obtenir cette version spécifique.

Le port 80 de la machine hôte est déjà occupé par le conteneur qui exécute PHP version 7. Nous ne pouvons pas l’utiliser pour ce conteneur. Nous utiliserons dons le port 81 de la machine hôte.

Configuration le conteneur docker PHP 8

Nous commencerons par créer notre conteneur avec la commande suivante :

[root@docker ~]# docker run -it -p 81:80 --name php8 ubuntu

Dans le conteneur que nous venons de créer, Aprés avoir mis à jour le systeme nous y installerons :

• le serveur web Apache
• php 8

root@fb9b37059606:/# apt update -y && apt upgrade -y
root@fb9b37059606:/# apt install apache2 -y
root@fb9b37059606:/# apt install php -y
root@fb9b37059606:/# apachectl restart

Une fois PHP installé, nous pouvons vérifier qu’il s’agit bien de la version 8 qui est en cours d’exécution.

root@fb9b37059606:/# php -v

Nous créerons également un fichier exécutant la fonction phpinfo() à la racine du répertoire « html » présent dans « /va/www/ »

root@fb9b37059606:/# echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php

Après être sorti de notre conteneur, nous autoriserons la machine hôte à recevoir des requêtes sur le port 81.

root@fb9b37059606:/#
[root@docker ~]# firewall-cmd --add-port=81/tcp --permanent
[root@docker ~]# firewall-cmd --reload

Nous pouvons maintenant nous rendre sur le port 81 de notre machine hôte pour accéder à notre conteneur. Nous constaterons que le conteneur exécutant PHP8 est bien fonctionnel.

Docker référencie bien ses deux conteneurs, un qui est mapper sur le port 80 et un autre mapper sur le port 81.

[root@docker ~]# docker ps

Accéder au conteneur derrière un reverse proxy

Dans un environnement de production, nous configurons un serveur Web pour qu’il soit accessible sur son port par défaut, correspondant aux protocoles « http » ou « https » : le port 80 pour http et le port 443 pour https. Pour atteindre cet objectif, nous utilisons un reverse proxy qui reçoit les requêtes entrantes et les redirige vers le conteneur Docker approprié. Pour faciliter l’identification de ces conteneurs Docker par les utilisateurs, nous employons des noms de domaine pleinement qualifiés (FQDN) en mettant en place un système de résolution de noms. Nous allons maintenant découvrir comment réaliser cette configuration.

Création d’u conteneur de l’image PHP8

Pour démarrer ce nouveau projet, nous capitalisons sur notre travail antérieur. Cependant, avant de poursuivre, nous créons en priorité l’image Docker pour le conteneur Docker exécutant PHP 8. Autrement dit, nous élaborons cette nouvelle image de la même manière que nous l’avons fait pour l’image du conteneur Docker srv_web_php7.

[root@docker ~]# docker commit fb9b37059606 srv_web_php8:latest

Nous vérifierons que l’image a bien été créée.

[root@docker ~]# docker images

Nous créerons l’architecture suivante :

Dans cette configuration de base, nous disposons déjà de l’image « srv_web_php7 » pour créer le conteneur « PHP7 », ainsi que de l’image « src_web_php8 » pour créer le conteneur « PHP8 ». Notre prochaine étape consiste à créer l’image qui exécutera le reverse proxy, lequel sera configuré sur un serveur nginx. Cependant, avant de faire cela, nous commencerons avec un environnement Docker propre, sans aucun conteneur. Supprimons donc ceux que nous avons précédemment créer.

[root@docker ~]# docker rm -f $(docker ps -aq)

Nous commencerons par créer notre conteneur PHP7. Nous allons également avoir besoin d’outils « ip » pour configurer la partie réseau et de l’outils ping pour tester la communication entre nos conteneurs. L’outils « ip » est présent dans le paquet « iproute2 » et l’outil « ping » sera disponible en installant le paquet « iptutils-ping ». Ce conteneur sera ensuite converti en images, par conséquent, pour le moment, nous le mapperons sur aucun port de la machine physique.

[root@docker ~]# docker run -it --name PHP7 srv_web_php7
root@413ddd8824ab:/# apt update -y && apt upgrade -y
root@413ddd8824ab:/# apt install iproute2 iputils-ping -y

Nous vérifierons que nous avons bien la possibilité d’utiliser la commande « ip », par exemple, nous utiliserons la commande « ip » pour connaître l’adresse IP de notre passerelle.

root@413ddd8824ab:/# ip route show

Nous testerons également la commande « ping » en tenant de communiquer avec la passerelle configurée sur le conteneur.

root@413ddd8824ab:/# ping 172.17.0.1 -c 4

Création du conteneur PHP8

Pour la création du conteneur PHP8, nous procéderons de la même façon après avoir détacher notre terminal de l’invite de commande de notre nouveau conteneur en utilisant la combinaison de touche [ctrl]+[P] & [ctrl]+[Q].

Ensuite nous mettrons à jours le système et nous installerons les paquets « iproute2 » et « iputils-ping ».

root@212bbec8e72c:/# apt update -y && apt upgrade -y
root@212bbec8e72c:/# apt install iproute2 iputils-ping -y

Nous effectuerons les mêmes tests que ceux que nous avons fait sur le conteneur que nous avons précédemment créé.

root@212bbec8e72c:/# ip route show
root@212bbec8e72c:/# ping 172.17.0.1 -c4

Nous constaterons que les conteneurs partagent la même adresse de passerelle, ce qui indique clairement que les deux conteneurs sont sur le même réseau à savoir 172.17.0.0/16. Si l’adresse de ce conteneur est 172.17.0.3, l’adresse du précédent conteneur est 172.17.0.2. Cette information est donnée lors de la commande « ip route show » à la fin de la seconde ligne.

Ce conteneur étant configurer nous pouvons détacher notre terminal de l’invite de commande du conteneur.

Création du conteneur NGINX

Pour le conteneur docker qui exécutera nginx, nous devons repartir d’une image vierge. Nous repartirons sur l’image Ubuntu vu qu’elle est présente sur notre machine.

[root@docker ~]# docker run -ti --name reverse_proxy ubuntu

Dans ce conteneur, nous installerons le paquet « nginx » qui sera configuré en reverse proxy et nous y ajouterons les outils « iproute2 » et « iputils-ping » après avoir mis à jour le système d’exploitation.

root@e4cee4f4deb3:/# apt update -y && apt upgrade -y
root@e4cee4f4deb3:/# apt install nginx iproute2 iputils-ping -y

Rappelle fonctionnement Reverse Proxy

Le reverse proxy fonctionne en se basant sur l’URL de la requête. Une seule machine peut héberger plusieurs sites ou applications. Pour différencier ces sites, il est essentiel d’utiliser des noms de domaine pleinement qualifiés (FQDN) uniques. Lorsqu’une requête HTTP est reçue, le reverse proxy examine l’entête HTTP, en particulier l’URL et le nom d’hôte, pour déterminer où rediriger la requête. Cela nécessite que le reverse proxy puisse résoudre le nom d’hôte (FQDN) en une adresse IP pour identifier la destination correcte et transmettre la requête au bon conteneur ou serveur.

Configuration de la résolution de nom

Pour éviter d’avoir à déployer un DNS, nous utiliserons le fichier /etc/hosts présent dans le conteneur « reverse_proxy ». Nous rappellerons ici qu’un conteneur n’a pas d’éditeur de texte par défaut, nous utiliserons donc la commande « echo » pour modifier le fichier /etc/hosts. Une ligne étant une information, dans notre contexte, nous avons à renseigner la résolution de nom de deux conteneurs, nous aurons donc un saut de ligne, il nous faudra donc utiliser le commutateur « -e » pour la prise en charge du saut de ligne ( \n ) dans la commande echo

Etant donnée que le conteneur PHP7 a pour adresse IP 172.17.0.2, nous lui attribuerons le nom pleinement qualifier « php7.elkhrissi.lab » et pour le conteneur PHP8 disponible à l’adresse IP 172.17.0.3 avec le FQDN « php8.elkhrissi.lab ».

Nous ajouterons donc ses informations dans le fichier hosts de notre conteneur « reverse_proxy ».

root@e4cee4f4deb3:/# echo -e "172.17.0.2 php7 php7.elkhrissi.lab \n172.17.0.3 php8 php8.elkhrissi.lab" >> /etc/hosts

Nous vérifierons que la résolution de nom est bien effective à l’aide de la commande « ping ».

root@e4cee4f4deb3:/# ping php7.elkhrissi.lab -c1
root@e4cee4f4deb3:/# ping php8.elkhrissi.lab -c1

Ce conteneur doit pouvoir communiquer avec les deux autres conteneurs PHP7 et PHP8, nous exécuterons une commande ping pour vérifier que le conteneur nginx peut joindre le conteneur PHP7 et PHP8.

Configuration du reverse proxy

Nous mettrons en place une configuration dans nginx qui permettra de rediriger les requêtes adressées au nom de domaine pleinement qualifié (FQDN) « php7.elkhrissi.lab » vers le conteneur PHP7, et les requêtes adressées à « php8.elkhrissi.lab » vers le conteneur PHP8.

Reverse proxy pour PHP7

Pour la configuration des requêtes à destination du conteneur PHP7, nous créerons un fichier de configuration php7.conf qui devra être stocké /etc/nginx/conf.d/. Le contenu de se fichier sera le suivant :

server {
listen 80;
server_name php7.elkrhissi.lab;
location / {
proxy_pass http://php7.elkhrissi.lab;
}

• server { … } : Cela définit un bloc de configuration pour un serveur virtuel. Cela signifie que les instructions à l’intérieur de ce bloc s’appliqueront aux requêtes entrantes qui correspondent au nom du serveur spécifié (server_name) et au port spécifié (listen).
• listen 80; : Cette ligne indique au serveur nginx d’écouter les requêtes entrantes sur le port 80. Le port 80 est le port par défaut pour les requêtes HTTP non chiffrées.
• server_name php7.elkrhissi.lab; : Ici, nous spécifions le nom de domaine pleinement qualifié (FQDN) auquel le reverse proxy répondra. Dans ce cas, il s’agit de php7.elkrhissi.lab. Cela signifie que ce serveur nginx traitera les requêtes entrantes pour ce FQDN spécifique.
• location / { … } : Cela configure une directive location qui spécifie comment le serveur nginx doit gérer les requêtes pour les chemins correspondant à la racine (« / »). Cela signifie que toutes les requêtes entrantes seront gérées par cette directive.
• proxy_pass http://php7.elkhrissi.lab; : C’est la partie la plus importante de la configuration. Cette directive indique à nginx de rediriger toutes les requêtes entrantes à cette location vers le conteneur Docker nommé « php7.elkhrissi.lab » en utilisant le protocole HTTP. En d’autres termes, lorsque le serveur nginx reçoit une requête pour php7.elkrhissi.lab, il transmettra cette requête au conteneur Docker qui exécute PHP7, permettant ainsi au conteneur de traiter la requête et de renvoyer la réponse.

Pour créer ce fichier, nous utiliserons l’outil « echo »

root@e4cee4f4deb3:/#echo 'server {
   listen 80;
   server_name php7.elkhrissi.lab;
   location / {
   proxy_pass http://php7.elkhrissi.lab;
   }
}' | tee /etc/nginx/conf.d/php7.conf

Reverse proxy pour PHP8

Pour les requêtes à destination du conteneur exécutant PHP8, nous créerons un fichier de configuration en gardant la même logique que le fichier que nous avons créé précédemment.

root@e4cee4f4deb3:/#echo 'server {
    listen 80;
    server_name php8.elkhrissi.lab;
    location / {
    proxy_pass http://php8.elkhrissi.lab;
   }
}' | tee /etc/nginx/conf.d/php8.conf

Conversion conteneur docker en image docker

Nous convertirons ses conteneurs en une image, pour ce faire, nous devrons détacher notre terminal de l’invite de commande de notre conteneur à l’aide des combinaisons de touche [ctrl]+[P] & [ctrl]+[Q]

root@e4cee4f4deb3:/# [ctrl]+[P] & [ctrl]+[Q]
[root@docker ~]# docker commit e4cee4f4deb3 reverse-proxy

Nous avons notre image prête à l’emploi, nous allons pouvoir l’exécuter et mapper le port 80 du conteneur avec le port 80 de la machine hôte. Le conteneur s’appellera nginx-rp.

[root@docker ~]# docker run -ti -p 80:80 --name nginx-rp reverse-proxy

En lançant le service nginx dans notre conteneur, nous sommes confrontés à une erreur. Cette erreur survient en raison de l’absence de persistance des données stockées dans notre conteneur précédent, qui a servi de base pour créer cette image.

Cette caractéristique essentielle des conteneurs, à savoir leur nature éphémère, signifie qu’ils ne conservent pas les données au-delà de leur cycle de vie, du moins pas celles qui ne sont pas présentes dans leur système de fichiers principal. Par défaut, lors de l’installation d’une nouvelle application, les fichiers de configuration sont généralement stockés dans les répertoires du service, c’est-à-dire dans le système de fichiers principal du conteneur. Ainsi, nous retrouverons bien nos fichiers de configuration.

root@1c6760241900:/# ls /etc/nginx/conf.d/

En revanche, les modifications que nous avons apportées au fichier /etc/hosts n’ont pas été conservé.

Par conséquent, lors du démarrage du service nginx, nous avons configuré des fichiers de configuration dans lesquels nous avons spécifié les noms de domaine vers lesquels il doit rediriger les requêtes. Cependant, le service nginx ne peut pas les contacter car le système ne peut pas résoudre ces noms de domaine en adresses IP. En conséquence, le service nginx génère une erreur. Nous ajouterons nos deux entrées dans le fichier /etc/hosts puis nous serons en mesure de démarrer le service nginx.

root@1c6760241900:/# echo -e "172.17.0.2 php7 php7.elkhrissi.lab \n172.17.0.3 php8 php8.elkhrissi.lab" >> /etc/hosts
root@1c6760241900:/# service nginx start

Verification des accès aux serveurs Web

À partir d’une machine cliente Windows connectée au même réseau que notre machine hôte, nous vérifierons la fonctionnalité de notre configuration. Avant de procéder aux vérifications, nous ajusterons le fichier hosts de la machine cliente afin qu’elle puisse résoudre les noms de domaine de nos deux conteneurs. Nous ouvrions « notepad » en tant qu’administrateur, nous ouvrions le fichier hosts disponible au chemin C:\Windows\System32\drivers\etc. En sélectionnant « Tout les fichiers » en bas à doite nous devrions voir le fichier hosts. Nous le sélectionnerons et cliquerons sur le bouton « Ouvrir »

L’adresse IP que nous renseignerons sera l’adresse IP de notre machine hôte qui, dans le cadre de cette documentation est 10.0.0.3 qui cela la résolution de nom de « php7.elkhrissi.lab » et « php8.elkhrissi.lab »

Une fois que la modification a été enregistré, nous allons nous rendre aux URLs après nous êtes assurer que les services apache sur nos conteneurs est bien démarré :

Après avoir enregistré la modification, nous allons accéder aux URLs suivant une fois que nous nous sommes assurés que les services Apache dans nos conteneurs Docker sont bien démarrés :

• http://php7.elkhrissi.lab/phpinfo.php
• http://php8.elkhrissi.lab/phpinfo.php

Nous vérifierons que les deux conteneurs ne communiquent pas ensemble. Pour ce faire, nous allons utiliser l’outils ping qui, par défaut, n’est pas présent. Nous l’installerons dans le conteneur app-php7, app-php8

[root@docker ~]# docker exec -it app-php7 apt-get install -y iputils-ping
[root@docker ~]# docker exec -it app-php8 apt-get install -y iputils-ping

Pour rappel, l’adresse IP du conteneur Docker de « app-php7 » est 192.168.1.2 et l’adresse IP de « app-php8 » est 192.168.2.2

Nous testerons que la communication entre app-php7 et app-php8 ne peux pas se faire.

[root@docker ~]# docker exec -it app-php7 ping -c 4 192.168.2.2

En toute logique, le conteneur app-php8 ne sera pas en mesure de communiquer avec app-php7.

[root@docker ~]# docker exec -it app-php7 ping -c 4 192.168.2.2

Dans ce chapitre, nous avons vu le cloisonnement sans passer par des solutions UTM. Si nous voulions durcir le cloisonnement la solution docker ne serait pas adaptée, d’autres solutions existent.

L’article 05 conteneur Docker : l’isolation est apparu en premier sur Pandawan.

[root@docker ~]# docker run ubuntu

Cette commande recherche l’image Ubuntu sur la machine locale. Si l’image n’est pas présente, elle la télécharge depuis Docker Hub. Ensuite, elle crée un conteneur basé sur cette image. Le conteneur exécute généralement la commande par défaut, souvent /bin/bash, pour permettre l’interaction. Pour lister les conteneurs en cours d’exécution, exécutez la commande « docker ps ».

[root@docker ~]# docker ps

Comme nous pouvons le constater sur la capture d’écran ci-dessus, il n’y a aucun conteneur. Cela s’explique par le fait qu’après avoir exécuté la commande « /bin/bash », il n’exécute plus aucune autre commande. Un conteneur docjer qui n’éxecutre rien s’éteinds automatiquement d’où le statut « Exited ». Ce conteneur, même s’il est éteint, est tout de même présent dans la machine. Pour voir tous les conteneurs actifs ou inactifs (statut exited), nous exécuterons la commande « docker ps -a ».

[root@docker ~]# docker ps -a

Afin de pouvoir interagir avec une instance dès sa création, il nous faudra le précisier au lancement du conteneur Docker. Pour cela, nous spécifierons lnous ajouterons le mode interactif (-i)et d’un terminal (-t). Cela nous permettra d’engager une interaction avec le conteneur via notre propre terminal.

[root@docker ~]# docker run -it ubuntu

Dans notre invite de commande, sur prompt, nous sommes passé du nom de l’hôte « docker » à l’identifiant de l’instance « 7c85ed7d6261 ».

Dans ce conteneur, le seul processus en cours d’exécution est le shell Bash.

Pour revenir à l’invite de commande de l’hôte sans éteindre le conteneur, nous utiliserons la combinaison de touches [Ctrl]+[P] [Ctrl]+[Q].

Nous exécuterons la commande permettant de répertorier tous les conteneurs, et nous constaterons que notre conteneur affiche un statut « UP ».

L’utilisation de la combinaison de touches [Ctrl]+[P] et [Ctrl]+[Q] nous détache de l’invite de commande du terminal de notre conteneur. Pour revenir au terminal de notre conteneur, nous attacherons le terminale de l’hôte à celui du conteneur. Nous utiliserons son identifiant unique, soit « 7c85ed7d6261″ dans notre exemple, ou même en tronquant l’identifiant en indiquant « 7c ».

[root@docker ~]# docker attach 7c

Les modifications apportées à un conteneur n’affectent ni l’image d’origine, ni la machine où le moteur Docker est exécuté. Pour illustrer ce concept, prenons notre conteneur, nous allons créer un fichier nommé « panda » dans le répertoire /home/.

Après avoir créer et vérifier la présence du fichier « panda », nous détacherons l’invite de commande. Pour rappel le détachement de l’invite de commande se fait à l’aide de la combinaison de touche clavier [ctrl]+[P] et [ctrl]+[Q]. Nous vérifierons ensuite que le répertoire /home/ de notre machine n’héberge pas ce fichier.

Après avoir créé et vérifié la présence du fichier « panda », nous détacherons l’invite de commande de notre conteneur à l’aide de la combinaison de touches [Ctrl]+[P] et [Ctrl]+[Q], puis nous vérifierons que le répertoire /home/ de notre machine ne contient pas ce fichier. Pour récapituler ce qui a été expliqué précédemment, Docker crée une couche de données supplémentaire pour stocker ces nouvelles données. Cela s’appelle la couche de données différentielle. La couche de données différentielle est fusionnée avec les autres données de notre conteneur pour former un seul objet, qui est le conteneur lui-même. Les informations de cette couche de données différentielle sont stockées dans les bibliothèques de Docker. Il nous sera possible de lister les données différentielles et les données fusionner, c’est-à-dire notre fichier panda en le recherchant dans notre système.

Nous retournerons dans notre conteneur, puis nous ajouterons des données dans le fichier « panda ».

[root@docker ~]# docker attach 7c
root@7c85ed7d6261:/home# echo "Bonjour" > panda
root@7c85ed7d6261:/home# cat panda

Retournons sur l’invite de commande de notre machine et éditons le fichier de différencier.

[root@docker ~]# vi /var/lib/docker/overlay2/14401c86fa9a626c1d8b39a7c6ba94968a3d4c6e8a54fe745db8f97efb307e8e/diff/home/panda

Nous ajouterons des données dans ce fichier.

Après avoir enregistrer les modifications nous retournerons dans notre conteneur, puis nous éditerons le fichier que nous avons créée.

[root@docker ~]# docker attach 7c
root@7c85ed7d6261:/home# cat panda

Les données n’auront pas été altérer par la modification que nous avons apporté à notre fichier vu qu’elles n’ont pas été fusionner avec les autres éléments de notre conteneur, c’est dire les données stockées dans le fichier : « var/lib/docker/overlay2/14401c86f../merged/home/panda ».

Sortons une nouvelle fois de notre conteneur à l’aide des combinaisons de touche [ctrl]+[P] et [ctrl]+[Q], nous ajouterons des données dans le fichier :

« var/lib/docker/overlay2/14401c86f…/merged/home/panda».

👍🏻 Les … sont à remplacer par la suite alphanumérique complet.

[root@docker ~]# vi /var/lib/docker/overlay2/14401c.../merged/home/panda

Après avoir enregistrer cette modification, nous attacherons une nouvelle fois le conteneur à notre invite de commande puis nous afficherons le contenu du fichier « panda ».

Docker se concentre principalement sur la séparation des programmes, appelés processus, pour éviter qu’ils ne se perturbent mutuellement et sur la gestion équitable des ressources telles que la puissance de calcul (CPU) et la mémoire. Cependant, en ce qui concerne les données, Docker n’impose pas une séparation aussi stricte par défaut. Cela signifie que, si nous ne prenons pas de précautions, les programmes dans les conteneurs pourraient partager ou même accéder à des données que nous souhaitons garder privées. Il est donc essentiel d’être attentif à la manière dont nous gérons et partageons les données dans Docker pour garantir la sécurité et la confidentialité des informations sensibles.

L’article 04 Conteneur Docker est apparu en premier sur Pandawan.