Installation et Configuration d’Elastix

Introduction

Elastix est un logiciel libre disponible sous licence GPLv2 développé par Palosanto. Il tourne sur un noyau CentOS. Il est entièrement libre et toutes les versions sont disponibles sans limitation de fonctionnalité.

C’est un système de communication unifié qui peut gérer l’ensemble des besoins de communication d’une entreprise. Il possède des fonctionnalités telles que la VOIP (passer des communications téléphoniques (Option vidéo disponible) sur le réseau IP) que nous allons détailler dans ce tutoriel, la messagerie électronique (comme Yahoo mail) et la messagerie instantanée (comme Facebook) que nous verrons plus tard dans un autre tutoriel, le fax (dont nous n’allons pas parler dans notre article), etc.

Nous allons présenter tous au long de cet article l’installation et la Configuration du service IPBX(VoIP). Commencer par Télécharger l’ISO du système depuis le site officiel, dans notre cas nous utiliseront la version 2.5.0 qui est la version stable disponible actuellement.

Nous verrons donc ensemble :

  • L’installation d’Elastix 2.5.0
  • Les Configurations de l’accès distant à Elastix.
  • La configuration de la VOIP sur Elastix
  • Configuration des Clients PC et Mobile

1. Installation d’Elastix

Après avoir téléchargé l’ISO d’Elastix vous n’avez plus qu’à la graver ou à la mettre sur une clé bootable selon les options disponibles sur l’ordinateur de destination. Lorsque vous insérez votre support veux verrez l’écran de démarrage ci-dessous.

Appuyer sur la touche Entrée et attendre la fin du chargement des informations d’installation.

ic-elastic

Ensuite vous verrez une page pour le choix des langues. Déplacer vous avec les touches de direction et sélectionner la langue de votre choix. Ensuite, appuyer sur la touche tabulation pour sélectionner le bouton OK. Et valider avec la touche entrée.

ic-elastic1

Choisissez le type de clavier : utilisez la touche de tabulation pour sélectionner le bouton OK et valider avec la touche Entrée.

ic-elastic2

Attendre la fin du chargement des ressources sélectionner le bouton Oui avec valider avec la touche Entrée.

ic-elastic3

Ensuite l’assistance vous demande de choisir un mode d’installation Laisser celui par défaut (il est annoté ici que toutes les données présente sur votre disque serons perdu) et utiliser la touche tabulation pour sélectionner le bouton OK et valider avec la touche Entrée.

ic-elastic4

IL vous demande ensuite si vous souhaitez examiner les partitions. Nous n’avons pas besoin de le faire, car nous avons choisir le mode par défaut donc avec la touche Tabulation sélectionner le bouton Non et valider avec la touche Entrée.

ic-elastic5

Il vous demande ensuite si vous souhaitez configurer l’interface Eth0 sur le système (votre carte réseau) Appuyer sur Entrée pour la configurer, car il faut que le serveur est une IP fixe (sinon bonjour la catastrophe).

ic-elastic6

Ensuite vous aurez la possibilité de choisir le support a activé laisser les paramètres par défaut et appuyer juste la touche tabulation pour sélectionner le Bouton OK et ensuite appuyer la touche Entrée au clavier pour valider.

ic-elastic7

L’assistance vous demandera de choisir les configurations par défaut de la carte appuyé sur la touche tabulation (vous verrez une casse rouge apparaitre à côté de Configuration d’adresses manuelle). Ensuite appuyer sur la touche Espace pour sélectionner cette option. Vous pourrez ensuite remplir les deux champs Adresse IP et Préfixe (Masque réseau).

Utiliser encore la touche Tabulation pour sélectionner le bouton OK et appuyer la touche Entrée pour valider.

ic-elastic8

Il vous affiche la page de configuration de l’adresse IPV6 si vous utilisez l’adressage IPV6 sur votre réseau configurer le sinon laisser l’option par défaut utiliser la touche Tabulation pour sélectionner le bouton OK et valider avec la touche Entrée.

ic-elastic9

Vous pourrez ensuite indiquer les adresses de la passerelle ainsi que celle des serveurs DNS primaires et secondaires. Ensuite, utiliser la touche de tabulation pour sélectionner le bouton OK et valider avec la touche Entrée.

ic-elastic10

SI vous ne spécifiez pas de serveur DNS, il vous affichera le message qui suit (n’y prêtez pas attention si vous n’avez pas de Serveur DNS). Validez avec la touche Entrée. Si vous avez spécifié un serveur vous n’aurez pas se message.

ic-elastic11

Ensuite il vous demande de spécifier le nom d’Hôte. Appuyer la touche tabulation pour pouvoir écrire dans le champ texte (indiquer le nom voulu). Ensuite appuyer encore sur la touche Tabulation pour sélectionner le bouton OK et valider ensuite avec la touche Entrée.

ic-elastic12

Appuyer ensuite la touche tabulation pour pouvoir choisir votre fuseau horaire (déplacer vous avec les touches de direction) ensuite appuyer encore la touche Tabulation pour sélectionner le bouton OK et enfin valider avec la touche Entrée.

ic-elastic13

Ensuite il vous demande d’indiquer un mot de passe pour le compte super administrateur (root) du système indiquer le et appuyer la touche tabulation pour sélectionner le bouton OK. Et valider avec la touche Entrée.

ic-elastic14

Attendre la fin de l’installation des paquets.

ic-elastic15

Une fois l’installation des paquets  terminez le PC va redémarrez et continuer l’installation il vous demandera de spécifier le mot de passe de l’utilisateur Root de MySQL. Une fois le mot de passe entrée appuyer sur la touche Entrée au clavier pour valider.

ic-elastic16

Bien sûr il vous demande ensuite de le confirmer (ce ne serait pas drôle sinon). Fait le et valider avec la touche Entrée.

ic-elastic17

Attendre la fin de l’enregistrement du mot de passe. Ensuite il vous demande de spécifier le mot de passe de l’utilisateur administrateur de l’interface Web.

NB : Vous pouvez utiliser le même mot de passe à chaque fois (mais cela n’est pas très conseillé).

ic-elastic18

Bien sûr il vous demande de confirmer votre mot de passe (Se ne serais pas drôle sinon). Indiquer le a nouveau et valider enfin avec la touche Entrée.

Une fois l’installation terminez-vous verrez apparaitre ne page noir comme celle-ci :

ic-elastic19

Félicitation l’installation est terminée.

2. Configuration de l’accès distant sur Elastix

Si vous voulez vous connecter au serveur via ssh ou bien directement sur cette console utiliser comme login root et comme password votre mot de passe pour l’utilisateur root (le premier mot de passe que nous avons saisi durant l’installation).  Une fois vos informations de connections indiqué, vous verrez apparaitre la page suivante :

ic-elastic20

Bon maintenant il faut connecter votre serveur à votre réseau et vous connecter sur un autre PC du réseau (bien sûr il faut que votre Serveur Elastix soir allumé et que les 2 PC puissent communiquer). Maintenant à partir d’un autre PC connecté au même réseau essayé de faire un Ping sur l’adresse du serveur qui dans notre cas est 192.168.2.20 (ce n’est pas obligatoire, mais c’est utile pour teste si les 2 machines sont bien en réseau). Si le Ping ne passe pas ? Vérifier bien votre connectique.

Enfin le Ping passe, ouvrez un navigateur sur le deuxième ordinateur (celui sur lequel vous avez fait le Ping vers le serveur). Taper l’adresse du serveur dans le navigateur. http://192.168.2.20 et valider vous verrez une page vous indiquant que le certificat de votre serveur n’est pas valide cette page change en fonction de votre navigateur et de sa version (dans notre cas c’est chrome 41).

ic-elastic21

Cliquer sur Paramètres avancés et ensuite sur continuer vers le site 192.168.2.20 (dangereux) :

ic-elastic22

Ce n’est pas dangereux de le faire, car nous nous connectons a notre serveur personnel se message est dû au fait que le certificat que vous avec dans votre serveur n’est pas reconnue par Chrome. Vous pourrez plus tard si vous le voulez avoir un certificat reconnu (aucun intérêt si ce serveur est juste destiné à être utilisé dans l’entreprise).

3. Configuration de la VOIP

A. Configuration d’Elastix

Très bien parvenue à ceux niveau  après avoir cliqué sur continuer vers le site vous verrez la page ci-dessous. Le nom d’utilisateur c’est admin et le mot de passe c’est celui que vous avez spécifié lors de l’installation (le dernier mot de passe crée durant l’installation) cliquez ensuite sur le bouton Submit.

ic-elastic23

NB : Si un jour il vous arrive d’oublier votre mot de passe de l’administrateur Web ou alors celui de la base de données, il vous suffira de vous connecter en tant que root et de taper la commande :

elastix-admin-passwords –change

Ensuite un assistant vous demandera de rentrer un nouveau mot de passe pour la base de données et pour l’administrateur Web.

Une fois connectée, vous verrez, une interface similaire à celui-là :

ic-elastic24

Cliquez sur l’onglet Préférences et ensuite choisissez la langue qui vous convient le mieux. Pour finir cliquer sur Save.

ic-elastic25

Maintenant nous allons configures des numéros SIP pour les utilisateurs. Cliquer sur l’onglet PBX. Rassurez-vous que périphérique SIP est sélectionné et cliquer sur Soumettre.

ic-elastic26

Vous verrez ensuite une page avec beaucoup de champ à remplir. Ne renseigner que les champs donc je vais faire mention ici :

ic-elastic27

ic-elastic28

Activer la boite vocale et indiquer un mot de passe pour la boite vocale (en chiffre) ainsi que l’email (facultatif c’est pour recevoir les messages vocaux le cas échéant).

ic-elastic29

 Le code de la langue (le code a deux chiffres) ex : fr pour français, en pour anglais.

Ensuite aller à la fin de la page (tous en bas) et cliquer sur le bouton soumettre

Nous avons fini de configurer notre compte SIP sur le serveur. Maintenant nous allons passer à la configuration de notre Client qui utilisera le protocole SIP pour passer des appels.

B.      Configuration du Client

Client PC

Maintenant il  vous suffit d’installer un client SIP sur votre PC :

En fonction de votre OS dans notre cas puisse que nous utilisons Linux nous allons installer Ekiga (Cette configuration reste la même quel que soit l’OS que vous avez donc sur Windows ou sur Mac la configuration ne changera pas il faudra juste installer le bon Client). Une fois le paquet d’ekiga installé lancer l’application :

ic-elastic30

Cliquer sur Édition et suite cliqué sur Comptes. Une fois dans compte cliquer encore sur Compte puis cliquer sur ajouter un Compte SIP.

Remplir les différents champs comme suite avec les informations indiqués plus haut et ensuite cliquer sur OK.

ic-elastic31

Ensuite il vous marque Client connectez faire cela sur 2 PC connectés sur le même réseau que votre Serveur (Bien sûr en utilisant 2 compte SIP différent sur ces 2 PC) et enfin à partir d’un PC composer le numéro de l’autre PC et voilà vous avez un serveur de Téléphonie avec des clients prêt à être exploitez.

Client Mobile

La Configuration d’un client mobile  quel que soit votre système la configuration est presque la même. L’interface sera juste un peu différente.  Télécharger un client de votre choix :

  • adoreSoftPhone,
  • Sipmobile,
  • Zoiper

Bref celui disponible sur votre version de Smartphone. Dans notre cas nous allons configurer AdoreSoftphone.

ic-elastic32

Conclusion

Tout au long de cet article, nous avons vu ensemble :

  • L’installation d’Elastix
  • La configuration de l’accès distant
  • La configuration de la VOIP sur Elastix
  • La configuration des clients VOIP

Vous êtes maintenant capable d’installer votre propre serveur de téléphonie et de le configurer afin de pouvoir utiliser des PC et des Smartphones pour émettre des appels en local ou à travers internet pour votre entreprise.

J’espère avoir bien détaillé les différentes procédures.  N’oublier pas avant de choisir une solution de VOIP pour votre entreprise faite une bonne étude des besoins réels, présents et futurs avant de choisir une solution gratuite ou payante pour limiter les dépenses, mais aussi ne pas avoir à tous refaire à zéro si les besoins augmentent considérablement.

SharePoint APP Store

1. Introduction

Cher utilisateur de SharePoint 2013 Bonjour, nous verrons dans ce tutoriel comment activer SharePoint 2013 App Store sur notre serveur SharePoint 2013. Pour cela nous allons devoir faire quelque petite configuration. Cette procédure fonctionne aussi bien avec SharePoint fondation que SharePoint Standard.

Voici les étapes à suivre:

  • Configuration préliminaire ‘créer le nom de domaine qui sera utilisé par App Store’
  • Configuration du service SharePoint 2013 App Store qui fera tourner notre catalogue d’application (Notre SharePoint App Store local).
  • Création de l’application qui portera notre catalogue d’application
  • Paramétrer une application pour qu’elle utilise notre catalogue d’application (Notre SharePoint 2013 App Store local)

Dans ce tutoriel nous supposons que votre Platform SharePoint 2013 est déjà installé et bien fonctionnel.  Voici le schéma récapitulatif du processus recommandé par Microsoft :

sp-appstore

Référence : Microsoft

2. Configuration préliminaire

Pour faire fonctionner SharePoint App Store il nous faut créer un nom de domaine suis sera utilisé par SharePoint 2013 App Store pour référencer les applications que nous allons installer. La convention de nommage des applications dans SharePoint App Store sera la suivante :

<un préfix>-< id App >.nom_de_domaine.fr

Nous avons 2 possibilités :

  • Créer un nom de domaine unique réservé pour les applications qui seront installées sur notre SharePoint 2013 App Store (recommandé par Microsoft).
  • Configurer un alias CNAME qui renverra vers notre nom de domaine (a utilisé si la méthode précédente ne fonctionne pas pour une raison quelconque ou si vous souhaitez que votre application soit préfixée directement avec le nom de votre domaine) principal utilisé par Sharepoint.

Choisir l’une des procédures suivantes :

  1. Crée un nom de domaine

Pour créer un nom de domaine, il suffit d’ouvrir le gestionnaire de serveur et de lancer le gestionnaire DNS.

Ouvrir le gestionnaire DNS : Gestionnaire de serveur ensuite Outils ensuite DNS

sp-appstore1

Ensuite, faire un clic droit sur Nouvelle zone de Recherche ensuite Nouvelle Zone

sp-appstore2

Vous verrez donc l’assistance de création d’une nouvelle zone de recherche. Cliquer simplement sur suivant.

sp-appstore3

Ensuite vous vous rassuré que zone principale soit bien cochée :

sp-appstore4

Choisissez l’option qui vous convient le mieux. Nous avons choisi de créer une zone de  réplication exécutée sur des contrôleurs de domaine dans notre domaine utilisé par SharePoint.

sp-appstore5

Cliquer ensuite sur suivant. Il vous demande d’entrer le nom de la nouvelle zone. Nous avons choisi SPAppStore.fr bien sûr si votre serveur est accessible depuis internet il faut penser à faire une réservation pour ce nom de domaine si vous voulez que cela fonctionne correctement.

sp-appstore6

Choisissez ensuite l’option qui vous convient le mieux.

sp-appstore7

Il vous affiche un récapitulatif des actions qui vont être effectuées. Cliquer sur terminer pour finaliser la procédure.

sp-appstore8

Nous avons donc créé une nouvelle zone de recherche. Maintenant il faudrait configurer cette zone de recherche pour qu’elle pointe vers notre zone principale.

sp-appstore9

Nous allons donc crée un alias CNAME (*) dans cette nouvelle zone de recherche qui pointera vers le serveur qui héberge notre site SharePoint 2013.

sp-appstore10

Remplir les champs comme suit :

Nom de l’alias : *

Nom du domaine complet (FQDN) : Entrez le nom de domaine complet du serveur qui héberge notre site SharePoint 2013. Pour ne pas faire d’erreur vous pouvez cliquer sur parcourir a droit pour pointer directement sur ce serveur en navigant d’ans l’arborescence de la forêt.

sp-appstore11

Validé ensuite avec OK. Nous avons donc fini la configuration.

Pour tester si tous fonctionnent correctement faire un PING vers un nom qui a la structure de celle d’une application qui serait installée sur le domaine que nous venons de créer par exemple :

ping App-val54d2f3.SPAppStore.fr

sp-appstore12

Sautez l’étape 2 et passez à la suite du tutoriel.

  1. Créer un alias CNAME

Si l’étape une ne fonctionne pas pour une raison ou pour une autre ou alors que vous avez simplement préféré créer un CNAME dans la zone de recherche principale sur la qu’elle votre SharePoint est installé, il vous suffit donc d’ouvrir le gestionnaire DNS :

Gestionnaire de serveur ensuite Outils ensuite DNS

sp-appstore13

Maintenant il faut ajouter dans notre DNS un alias CNAME générique.

Clic droit ensuite Nouvel alias (CNAME) …

sp-appstore14

Ensuite nous renseignons comme nom d’alias *. Dans le dernier champ  il faut renseigner le nom de domaine complet (FQDN) pour l’hôte de destination on renseigne le nom de domaine FQDN de notre machine qui hébergera le service SharePoint Store.

sp-appstore15

Pour tester si vous avez bien fait les configurations faites, un ping sur l’adresse suivante : dsszecze-562.monserveur.domaine.fr     Si tout est bien, configurer le ping devrait passer.

3. Configuration des services sur la ferme SharePoint

A. Installation des Services de l’App Store

Une fois notre nom de domaine crée et testé nous allons maintenant configurer le service SharePoint App Store.

Ouvrez SharePoint Management Shell.

sp-appstore16

Ensuite, tapez-y les commandes suivantes. Après avoir pris soin d’indiquer le nom de votre compte ferme dans l’emplacement indiqué.

$compte = Get-SPManagedAccount "votre compte ferme"

$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $compte

$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName "SettingsServiceDB"

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc

$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $compte

$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName "AppServiceDB"

$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

Si vous n’avez pas d’erreur alors cela veut dire que tous les services ont bien été installés maintenant aller dans l’administration centrale de SharePoint ensuite gérer les applications de service.

sp-appstore17

Vous devrez voire 2 nouveaux services qui ont apparu : AppServiceApp et SettingServiceApp :

sp-appstore18

B. Configuration de l’APP Store

Maintenant que nous avons l’application de services SharePoint installer et lancée, nous allons le configurer. Connectez-vous à l’administration centrale ensuite Applications ensuite configurer les URL d’application :

sp-appstore19

Si vous obtenez un message comme celui-ci :

sp-appstore20

Cela veut dire que le service de paramètre d’abonnement n’est actuellement pas en cour d’exécution donc nous allons lancer ce service en fessant : Administration centrale ensuite Paramètres système ensuite gérer les services sur le serveur.

sp-appstore21

Nous allons à la ligne Service de paramètres d’abonnement Microsoft SharePoint Fondation nous pouvons voire qu’il est désactivé, activons-le en cliquant sur Démarrer sur la gauche.

sp-appstore22

Maintenant retournons l’administration centrale ensuite Applications ensuite Configurer les URL d’application 

Si vous avez encore le message précédent vous signale que le service des paramètres d’abonnement et … n’a pas démarré veillez patienté quelque minute le temps qu’il mette à jour ces informations et ensuite recharger la page.

Après avoir patienté quelque minute rechargée la page vous aurez le résultat suivant :

sp-appstore23

Vous pouvez indiquer le nom que vous voulez comme préfix d’application, moi j’ai indiqué le nom App.

4. Création du catalogue d’application

Maintenant nous allons créer une application AppCatalog qui va gérer les demandes qui concernent nos applications et à l’aide de ce site vous pouvez mettre à disposition vos applications ou des applications que vous avez récupérées sur SharePoint App Store. Cela vous permet de garder votre SharePoint propre et bien ordonnée.

Administration centrale ensuite Applications ensuite gérer le catalogue d’applications  

sp-appstore24

Ensuite vous verrez :

sp-appstore25

Maintenant vous pouvez remplir les champs concernant la création du site qui va contenir les applications l’administrateur de se Site sera notre compte de service nommé SPSite prévue à cet effet et tout le monde aura accès aux applications que nous téléchargerons depuis le store.

sp-appstore26

sp-appstore27

Maintenant votre SharePoint App Store est prêt et peut contenir vos applications. Maintenant toutes les applications que vous allez télécharger dans cette Application Web (SharePoint – 80) seront accessibles depuis ce site et depuis toute les autres applications et sites.

5. Téléchargement d’une application

Maintenant nous allons télécharger une application.

Connectez-vous à votre site SharePoint :

Paramètre (roue dentée) ensuite Contenu du Site ensuite Ajouter une Application

sp-appstore28

sp-appstore29

À gauche de la page, vous cliquez sur SharePoint Store.

sp-appstore30

Ensuite il vous affiche la page de téléchargement d’application de SharePoint App Store :

sp-appstore31

Les applications grisées sont celles non compatibles avec votre version actuelle de SharePoint. Vous cliquez donc sur une application qui n’est pas grisée et qui vous intéresse :

sp-appstore32

Vous cliquez ensuite sur le bouton Ajouter en Bleu.

IL vérifie que vous venez bien du site SharePoint de votre entreprise.

Dans la page qui suit cliquez sur le bouton se connecter en haut à droite :

sp-appstore33

Ensuite il vous demande d’entrer votre adresse mail Microsoft. Eh oui pour télécharger des applications depuis le store de Microsoft il faut posséder une adresse mail Microsoft cela permet de garder réunir toute les licences des applications Microsoft que vous avez payées dans votre compte (même ci ces applications sont gratuite) comme cela vous n’aurez pas besoin de payer une application 2 fois. Même si vous réinstallez votre Serveur SharePoint votre compte Microsoft vous permettra de réutiliser les licences que vous aviez déjà acquises.

sp-appstore34

sp-appstore35

Une fois que vous vous êtes connecté il vous affiche la page précédente qui vous  demande de confirmer votre installation en cliquant sur le bouton Continuer en vert.

sp-appstore36

sp-appstore37

sp-appstore38

Cliquer sur revenir au site en vous rassurant que la caser a cocher Ajouter cette application au site Nom_du_site est bien coché.  Ensuite il vous demande d’approuver l’installation de l’application en cliquant sur approuver.

sp-appstore39

Vous êtes ensuite redirigé vers votre site web et vous pouvez donc maintenant voir cette application qui est disponible dans la liste des applications.

sp-appstore40

Conclusion

Tous au long de ce tutoriel nous avons appris a :

  • Crée un nom de domaine et un alias CNAME pour notre SharePoint 2013 Store
  • Configurer les Services de SharePoint 2013 Store sur la ferme
  • Créer un catalogue d’application qui contiendra l’ensemble de nos applications
  • Télécharger une application depuis le Store.

NB :

  • Vous ne pouvez pas télécharger des applications du SharePoint App Store avec le compte système
  • Vous devez disposer d’un compte Live ID pour télécharger des applications
  • Les licences des applications sont attachées à votre Live ID
  • Si vous achetez une application et que vous réinstallez votre ferme, pas besoin de la repayer!
  • la méthode préconisée par Windows fonctionne très bien (création d’un nom de domaine exclusivement réservé aux applications) il suffit juste en cas de problème de naviguer à l’intérieur de la machine en utilisant localhost au lieu du nom de la machine

Les Bases Sur DOCKER

Dans ce tutoriel nous allons voir comment fonctionne docker et nous allons présenter quelques fonctionnalités incontournables de docker.  Si vous lisez cet article, nous supposons que vous avez déjà lu notre article précédent sur la découverte de docker ou alors vous avez lu d’autres articles sur internet, donc vous savez au moins ce qu’est docker. Mais ne vous inquiétez pas, la présentation est très explicite donc pas besoin d’être un pro sur docker pour lire cet article il faut juste savoir de quoi il est question. Bon assez bavardé…. Action.

1. Dockerfile et Cycle de vie d’un conteneur

1.1. Cycle de vie des images et des conteneurs

Avant toute chose il est important de savoir que sur docker nous manipulons des Dockerfile qui sont compilés en images et ensuite instanciés en Conteneur. Donc en gros l’on part d’un fichier Dockerfile qui nous permet de construire une image qui une fois instanciée va devenir un conteneur. Le conteneur ainsi instancié reste toutefois lié à son image de départ.

1

Voici un schéma illustrant le cycle de vie d’un conteneur avec les commandes du client Docker :

2

Quelque commandes qui vous seront surement très utiles :

docker images : Lister les images présentes en local
docker ps : Liste les conteneurs démarrés
docker ps –a : Liste tous les conteurs (ceux qui sont démarrés, arrêtés normalement ou après une erreur)
docker log : attache la sortis console à celle du conteneur.
docker stop $(docker ps -q) : arrêter tous les conteneurs lancés d’un coup de baguette magique.
docker start $(docker ps -q) : relancer en même temps tous les conteneurs qui ont été arrêtés et qui sont en mémoire.
docker exec -it Nom_Du_Conteneur /bin/bash : Se connecter au Shell d’un conteneur.
docker rm  $(docker ps -a  -q --filter "status=exited") : Effacer tous les conteneurs arrêtés d’un coup de baguette magique.

1.2 Dockerfile

Le fichier qui nous permet de créer des images s’appelle un  Dockerfile. C’est un fichier qui permet de décrire comment une image sera construite avec la commande docker build. Il contient le nom de l’ensemble des paquets qui seront installés dans l’image, les répertoires qui seront partagés par l’image, les ports qui seront exposés, l’ensemble des variables d’environnements qui seront instanciés de base, etc.

Syntaxe

Voici la syntaxe de base d’un Dockerfile qui vous permettra de décrire une image et la manière dont elle sera créée:

MAINTAINER <name>
FROM <image>
ENV <key> <value>
ADD <src> <dest>
VOLUME ["/<dir>"]
USER <user>
EXPOSE <port>
RUN <command>   ou  RUN ["exécutable", "param1", "param2"]
CMD <command>   ou  CMD ["exécutable", "param1", "param2"]

 Légende :

MAINTAINER  <name> : Auteur de l’image vous pouvez mettre votre nom par exemple

FROM <image> : Nom de l’image de base. Cela permet de ne pas partir de rien et d’utiliser une image existante. Par exemple se base sur une image Debian pour créer un conteneur APACHE.

ENV <key> <value> : Permets de définir des variables d’environnement qui seront créées lors de l’instanciation du conteneur. Ex : MYSQL_PASSWORD qui permettra à celui qui lance l’instance du conteneur de passer le mot de passe de SQL via l’option -e.

ADD <src> <dest> : Il permet de récupérer des fichiers en local et de les uploader dans l’image lors de sa compilation. Ces fichiers feront désormais partie de l’image.

VOLUME [« /<dir> »] : Répertoire monté au démarrage du conteneur et qui est externe à celui-ci. Cela permet de rendre des fichiers du conteneur directement accessible sur l’hôte.

USER <user> : Permets d’indiquer l’utilisateur Linux qui sera utilisé lors du démarrage du conteneur.

EXPOSE <port> : Permet d’indiquer les ports réseaux exposés par le conteneur. Il définir sur quels ports réseau les conteneurs communiquent avec l’extérieur.

RUN <command>   ou  RUN [« exécutable », « param1 », « param2 »] : Il permet d’exécuter une commande sur l’image lors de sa création. Ex : run apt-get install apache

CMD <command>   ou   CMD [« exécutable », « param1 », « param2 »] :

  • il faut noter qu’il ne doit y avoir qu’un seul CMD dans un Dockerfile. c’est une commande qui est lancée dans les conteneurs qui utilisent cette image à chacun de leurs démarrages.
  • Si l’image contient le serveur NGINX, il peut s’agir de lancer l’exécution du serveur NGINX au démarrage du conteneur.
  • La commande n’est lancée qu’à l’exécution du conteneur et non durant la construction de l’image
  • Cette commande peut être redéfinie dans la commande de lancement du conteneur (Docker run)

2. Réseau et partage de fichier sous docker

Sachez-le.  Quoi que vous fassiez sur docker, quel que soit l’architecture que vous déciderez de mettre en place vous utiliserez forcement de manière consciente ou non le réseau et/ou le  partage de fichier.

1.1 Partage de fichier

Le partage de fichier se fait dans un conteneur en réalisant le montage de volumes disques ce qui permettra à un conteneur d’utiliser le contenu d’un répertoire de la machine hôte. Le conteneur peut ainsi avoir des fichiers que nous aurons définis (fichier de conf par exemple) lors de son premier démarrage et ces fichiers sont stockés sur la machine hôte donc ils ne seront pas effacés lors de l’arrêt et de la suppression du conteneur.

  • Le partage de fichiers nécessite de :
    • Créer le répertoire de partage sur la machine hôte (machine utilisée pour le lancement du conteneur)
    • Spécifier le répertoire de partage au sein du conteneur (dans le Dockerfile)
  • Ajouter la ligne suivante dans le fichier Dockerfile pour indiquer quel répertoire du conteneur sera partagé :

VOLUME [« [répertoire du conteneur] »]

  • Au lancement du conteneur, indiquer le mapping entre le répertoire de partage du conteneur et la machine hôte.
  • Dans la commande docker run, ajouter l’option -v [répertoire de la machine hôte]:[répertoire du conteneur] pour mapper le répertoire de la machine hôte avec celui du conteneur:

 docker run -v [host directory]:[container directory]

ajouter :ro à la fin pour activer la lecture seule :

docker run -v [host directory]:[container directory]:ro

1.2 Communications réseau.

L’interfaçage réseau permet à un conteneur de communiquer avec l’extérieur et/ou avec les autres conteneurs. Pour définir l’interfaçage réseau, il est nécessaire de :

  • Exposer le port réseau du conteneur :
    • soit dans le fichier Dockerfile de l’image : EXPOSE [port conteneur]
    • soit via l’option –expose de la commande docker run : –expose [port conteneur]

Pour que le port réseau du conteneur soit accessible à l’extérieur de la machine hôte nous devons mapper le port réseau du conteneur avec celui de la machine hôte via l’option -p de la commande docker run. Le mappage peut être manuel ou automatique :

  • Pour Mapper manuellement les ports. Dans ce cas nous fixons manuellement qu’elles port de l’hôte et du conteneur seront mappez ensemble.
    Utilisation : 
    docker run -p ip :port/protocole   
    docker run -p [port hôte]:[port conteneur]
    docker run -p [IP]:[port hôte]:[port conteneur]
    docker run -p [IP]:[port hôte]:[port conteneur]/[protocol]
    
    NB :   
    [IP] : Adresse IP (non obligatoire),
    [port hôte] : Port de la machine hôte,  
    [port conteneur] : Port du conteneur,  
    [protocol] : Protocol réseau (non obligatoire) (exemple : tcp ou udp).

    Il est possible de définir plusieurs mapping de ports à l’aide de plusieurs options -p dans la même commande docker run: docker run …  -p 80:80  -p 8080:8080

  • Mapper automatiquement tous les ports exposés d’un conteneur avec des ports livre de la machine hôte.

L’option -P de docker run utilisée toute seule sans spécification de numéro de port permet de mapper chacun des ports exposés d’un conteneur sur un des ports de la machine hôte sur une plage comprise entre 49000 et 49900.

docker run ... -p

Il faudrait alors lancer la commande docker ps pour voir sur quels ports de la machine hôte sont mappés les ports du conteneur.

Pour qu’un conteneur puisse communiquer directement avec un autre conteneur sans forcément avoir besoin de leur affecter des ports sur la machine hôte, il est nécessaire de lié les 2 conteneurs. Pour cela on lance un 1er conteneur et ensuite au lancement du 2ème  conteneur on le lie au 1er.  Cela permet ainsi au 2ème conteneur d’avoir des informations sur le 1er Conteneur. On devra donc lancer le 2ème conteneur avec en plus le paramètre.

 Docker run …  --link=[nom conteneur lié]:[alias du conteneur] 

[nom conteneur lié] : Nom du conteneur lié qui doit être en cours d’exécution (le nom de conteneur doit avoir été défini lors du lancement de ce conteneur via l’option –name de la commande docker run)

[alias lien] : alias du lien dans le conteneur

Docker vas fournir au deuxième conteneur les variables d’environnement qui ont été déclarées pour le 1er  conteneur dans le fichier Dockerfile ou via la commande docker run (via l’aide des options -e). Ces variables d’environnements sont préfixés par le nom de l’alias qui a été formaté en majuscules. Ex: Pour un alias apache, les variables d’environnement commencent par APACHE_.

Le conteneur lié doit être en cours d’exécution et doit donc être dans la liste des conteneurs en cours d’exécution via la commande docker ps. Le nom d’alias sert au nommage des variables d’environnement dans le conteneur qui va appeler le 1er. Donc en gros pour le 2ème conteneur c’est-à-dire celui qui appel. Le conteneur 1 nommé [nom conteneur lié] sur la machine hôte aura pour nom [alias lien]  dans le conteneur.

Voilà en gros à quoi cela peut ressembler schématiquement.

3

Le conteneur 1 expose le port 111. Nous démarrons le premier conteneur :

docker run -d --name conteneur1 --expose 111 demo/image1

Nous démarrons un second conteneur en le liant avec le premier conteneur :

docker run -d --name conteneur2 -P --link conteneur1:in_conteneur1 demo/image2

Docker ajoute dans le conteneur 2 des variables d’environnement concernant le conteneur 1 pour chaque port exposé par le conteneur 1 :

Pour le port 111 du conteneur 1 :

IN_CONTENEUR1_PORT_111_TCP_ADDR=172.17.0.2
IN_CONTENEUR1_PORT_111_TCP_PORT=111
IN_CONTENEUR1_PORT_111_TCP_PROTO=tcp

Nous pouvons ainsi récupérer l’adresse IP du conteneur lié pour que le conteneur 2 puisse communiquer avec le conteneur 1.

Si le conteneur 1 exposait le port 22 avec un serveur SSH, le conteneur 2 pourra se connecter en SSH sur ce premier conteneur via le port 22 et en utilisant la variable d’environnement contenant l’adresse IP « IN_CONTENEUR1_PORT_22_TCP_ADDR« .

Exemple : MySql + Drupal

Démarrer conteneur SQL

docker run -d -v /home/joel/data/webstack/bdd/:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=docker2016 --name webstack_mysql mysql

Démarrer Conteneur Drupal lié à SQL

docker run --name drupal_01 --link webstack_mysql:mysql -p 3001:80  -d drupal

Démarrage de WordPress lié à SQL

docker run --name wordpress_01 --link webstack_mysql:mysql -v /data/webstack/wordpress/1/:/var/www/html/ -p 3002:80 -d wordpress

Attention: il n’est possible de communiquer qu’avec les ports exposés d’un conteneur. Même entre 2 conteneur lié.

1.3 Changer les paramètres spécifiés lors de l’exécution du conteneur

Il n’y a pas de commande docker pour modifier les informations spécifiées via la commande docker run  du conteneur lors de l’exécution de celui-ci, que ce soit le mapping des ports réseau ou des fichiers.

Il faut alors enregistrer l’état ‘Commiter’ et redémarrer le conteneur en spécifiant le nouveau mapping de ports ou de fichiers. Lors du commit, il faut indiquer le nouveau nom d’image d’export  qui sera utilisé pour redémarrer le conteneur à partir de cette image (en gros c’est le nom de l’image de sauvegarde). Il ne faut pas utiliser le nom de l’image initial qui avait servi lors du premier démarrage du conteneur.

docker commit [identifiant] [nom image temporaire]

docker run (…) [nom image temporaire] (…)

3.    Webographie

Blog2dev  « Réseau et Fichiers » 

DÉCOUVERTE DE DOCKER

1. Présentation de docker

Docker est un logiciel open source (sous licence Apache 2.0) et un service en ligne optionnel (Docker.io) permettant de gérer des conteneurs (« dockers »). C’est un produit développé par la société de même nom. Initialement développé par un ingénieur français (Solomon HYKES), le produit a été dévoilé en mars 2013.

Docker est une application disponible aussi bien sous Windows que sous Linux. Il va vous permettre d’empaqueter d’autres applications et leurs dépendances dans un conteneur que l’on pourra ensuite déplacer et faire fonctionner sur n’importe qu’elle serveur fonctionnant sous Linux ou sous Windows (les conteneurs Linux vers des Linux et des Windows vers des Windows). Contrairement aux solutions de machines virtuelles (VM) classiques qui comprennent un système hôte (« guest OS ») et les librairies/applications utilisées par le ‘‘guest OS’’ ou l’application finale, les conteneurs ne contiennent, au maximum, que les applications/librairies finales. Cela permet donc d’avoir des conteneurs qui sont moins gourmands en ressource (HDD – CPU – RAM) que des machines virtuelles.

2

De plus une copie d’un conteneur qui ne change que la partie application ne contiendra que les différences par rapport au conteneur initial. Plusieurs conteneurs peuvent être des copies du même conteneur parent, ce qui vous permet de faire un gros gain en espace.

3

Le système qui héberge les conteneurs (l’hôte) est ainsi géré directement par le Docker Engine (en vert dans le premier schéma plus haut). Nous avons ainsi une mutualisation qui permet de lancer les conteneurs de manière presque instantanée, aussi rapide que le lancement d’une simple application. Vu que les conteneurs n’ont pas de système d’exploitation propre et utilisent celui de l’hôte, il n’y a plus de phase de démarrage et d’initialisation du système d’exploitation.

Il faut garder à l’esprit que même si l’on n’est pas dans une machine virtuelle, on dispose tout de même d’un environnement isolé (processus, système de fichier, ports réseau). L’utilisateur n’a qu’à se préoccuper que de ce qu’il veut virtualiser (les applications/services) et ne s’occupe pas du reste. Mais il est aussi possible de configurer manuellement la charge (IPs, ports, ram, processeur …) des conteneurs. La taille des conteneurs est considérablement réduite et ils sont aussi portables d’une machine docker a une autre sans configuration particulière.

2. Installation de docker

Pour faire fonctionner correctement la version actuelle de docker sous Linux, il est conseillé d’avoir un système 64bits et un kernel en version 3.10 minimum. Notre Debian 8 en version 64 bits possède toutes ces caractéristiques.

ouvrir la liste des dépôts

nano  /etc/apt/sources.list

Pensez à ajouter si vous ne les avez pas déjà, les dépôts suivants dans le fichier sources.

deb http://ftp.debian.org/debian jessie-backports main
deb-src http://ftp.debian.org/debian jessie-backports main
deb http://ftp.debian.org/debian jessie main contrib
deb-src http://ftp.debian.org/debian jessie main contrib 

Ensuite taper les commandes suivantes pour mettre à jour la liste de paquet et installer le paquet docker.

sudo apt update 
sudo apt install docker.io

NB: Toutes les manipulations faites avec les commandes docker doivent être faites avec le compte administrateur ayant le maximum de droit root. Ou alors vous pouvez ajouter votre compte utilisateur normal au groupe docker pour ne pas avoir à utiliser le compte root ou la commande sudo a tous les coups.

Maintenant pour vérifier que tout fonctionne correctement taper cette commande qui devrait lancer le conteneur hello-world qui affiche un message dans l’invite de commande avant de s’arrêter.

Vous devriez avoir ceux-ci comme résultat

sudo docker run hello-world
root@sw:/home/arsene# sudo docker run hello-world

Hello from Docker!

This message shows that your installation appears to be working correctly.



To generate this message, Docker took the following steps:

The Docker client contacted the Docker daemon.
The Docker daemon pulled the "hello-world" image from the Docker Hub.
The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.

The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.



To try something more ambitious, you can run an Ubuntu container with:

 $ docker run -it ubuntu bash



Share images, automate workflows, and more with a free Docker Hub account:

 https://hub.docker.com



For more examples and ideas, visit:

 https://docs.docker.com/engine/userguide/


root@sw:/home/arsene#

Maintenant nous pouvons procéder à la configuration de nos conteneurs. Si vous n’avez aucun résultat rassurez-vous que le service docker est bien lancé avec la commande :

service docker status

Elle vous affichera l’état du service docker. S’il n’est pas lancé, démarrez-le avec la commande :

service docker start

3. Configurer des conteneurs sur docker

Mise en service d’un conteneur : NGINX

On commence par télécharger le conteneur :

sudo docker pull nginx

Ensuite on lance le conteneur, j’ai créé un dossier Webstack : /data/webstack/www qui va contenir les fichiers de configuration de mon serveur et les fichiers de configurations des sites web.

sudo docker run --name webstack_nginx -d -p 80:80 -p 443:443 -v /data/webstack/www:/usr/share/nginx/html/  nginx

Explication :

–name permet de donner un nom à notre conteneur

-d permet de lancer notre conteneur en tâche de fond.

-p permet de spécifier les ports ouverts Port-Hôte : Port-Conteneur  c’est-à-dire les ports de l’hôte qui seront matché avec certains ports du conteneur.

-v permet de monter un dossier ou un fichier de l’hôte vers le conteneur. Ce fichier ou dossier sera vu par le conteneur comme le fichier / dossier de départ.

/data/webstack/www : répertoire de l’hôte ou seront hébergé les sites web que nous allons créer

     /usr/share/nginx/html/ : répertoire par défaut NGINX où sont hébergé les sites.

NGINX est tout simplement le nom de l’image docker que l’on veut démarrer.

Avec la commande précédente le répertoire  /data/webstack/www  est monté en tant que répertoire  /usr/share/nginx/html/ dans notre conteneur. Le conteneur a donc un accès en lecture et en écriture à ce répertoire et nous aussi depuis la machine hôte nous pouvons modifier le contenu de ce répertoire.

Si vous ne souhaitez pas que le conteneur est un accès en écriture, mais uniquement en lecture au dossier ou au fichier que vous allez lui passer en paramètre (généralement utilisé pour des fichiers de conf. Ou même pour des sites web en fonction de vos besoins), il vous faut juste ajouter le paramètre :ro à la fin du chemin.

sudo docker run --name webstack_nginx -d -p 80:80 -p 443:443 -v  /data/webstack/www:/usr/share/nginx/html/:ro  nginx

:ro :  Read Only : il permet de monter le répertoire en mode lecture seul pour le conte

NB : Si nous n’avions pas encore téléchargé l’image nginx avec la commande docker pull, docker aurait téléchargé cette image pour nous directement avant de la monter.

Ici on peut utiliser le répertoire /usr/share/nginx/html parce qu’il a été déclaré en tant que volume dans le Dockerfile de l’image Nginx.

Liaison entre 2 conteneurs 

PhpMyAdmin et MySql

On lance tous d’abord le 1er conteneur celui auquel le second va se lier conteneur MySQL :

sudo docker run --name webstack_mysql -d -v /data/webstack/bdd/:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=docker2016 mysql

Explication :

-e MYSQL_ROOT_PASSWORD=docker2016   on fixe la variable MYSQL_ROOT_PASSWORD qui contient le mot de passe qu’on décide d’attribuer au compte root de MySql au démarrage.

Ici, vous pouvez remarquer que nous n’avons spécifié aucun port pour la communication extérieure cela veut dire que seuls la machine hôte et les conteneurs qui sont liés au conteneur MySQL pourront communiquer avec lui (ceux-ci est partiellement vrais, car nous verrons que tous les conteneurs peuvent communiquer entre eux par défaut via leur IP. Mais cette fonctionnalité peux être désactivé en passant le paramètre –icc a false cette manipulation est expliquée dans le chapitre sur les bonnes pratiques de docker). Ce qui peut s’avérer être un gros avantage au niveau sécurité.

Ensuite on lance le conteneur PhpMyAdmin et on le relit au conteneur MySql.

sudo docker run --name webstack_phpmyadmin -d --link webstack_mysql:db  -p 2000:80 phpmyadmin/phpmyadmin

Explication :

–link webstack_mysql:db : il créer un lien entre le conteneur webstack_mysql (celui que nous avons créé précédemment avec MySQL) et PhpMyAdmin. PhpMyAdmin verra le nom d’hôte db dans son fichier hôte pointé sur le conteneur  webstack_mysql. Dans ce cas-ci, veillez à bien spécifier db sinon cela pourrait ne pas fonctionner. Bien évidemment, si vous avez spécifié un autre nom à MySql au lieu de (webstack_mysql) vous devez spécifier le bon nom.

Connecté vous ensuite sur : votre_ip :2000     En utilisant le compte root et le mot de passe que vous avez précédemment mis dans mysql.

5

Mysql et WordPress

docker run --name webstack_wordpress --link webstack_mysql:mysql -v /data/webstack/wordpress/:/var/www/html/ -p 3001:80 -d wordpress

Dans ce cas il utilisera les options par défaut. Pour configurer vous-même les variables utilisées, vous devez faire :

docker run --name webstack_wordpress_2  --link webstack_mysql:mysql  -p 3006:80 -e WORDPRESS_DB_USER=wordpress1 -e WORDPRESS_DB_PASSWORD=wordpress1 -e WORDPRESS_DB_NAME=wordpress1 -d  wordpress

Vous devez bien évidemment avoir créé sur votre serveur MySql l’utilisateur wordpress1 et la base de données wordpress1.

4. Arrêter / Supprimer des conteneurs et des images docker

Lorsque vous utilisé docker, différent cas de figure peuvent se poser.

  • Lister les conteneurs en court d’exécution
sudo docker ps
root@sw:/home/arsene# docker ps

CONTAINER ID        IMAGE                          COMMAND                CREATED             STATUS              PORTS               NAMES

8dbb57d6f332        wordpress:latest               "/entrypoint.sh apac   4 days ago          Up 4 days           80/tcp              webstack_wordpress_atomit
6c0f15270888        wordpress:latest               "/entrypoint.sh apac   5 days ago          Up 5 days           80/tcp              webstack_wordpress_1
39ee17373646        phpmyadmin/phpmyadmin:latest   "/run.sh phpmyadmin"   9 days ago          Up 9 days           80/tcp              webstack_phpmyadmin
0aac8e893ab1        mysql:latest                   "docker-entrypoint.s   9 days ago          Up 9 days           3306/tcp            webstack_mysql

root@sw:/home/arsene#
  • Vous souhaitez stopper un conteneur docker temporairement.

Docker stop ID_conteneur ou Nom_Conteneur :

sudo docker stop webstack_wordpress_1
root@sw:/home/arsene# docker stop webstack_wordpress_1
webstack_wordpress_1

Cette commande arête juste le serveur donc si vous faite un sudo docker ps pour lister les images en cours vous ne la verrez plus. Mais l’instance existe toujours la preuve c’est que si vous tentez de lancer un conteneur avec le même nom docker va refuser.

Pour voire la liste de tous les conteneurs docker (même ceux qui sont arrêtés), vous faite

sudo docker ps -a

Cette commande est aussi particulièrement utilise lorsqu’un conteneur refuse de se lancer (il faut noter que docker auras créé tout de même une instance).

root@sw:/home/arsene# docker ps -a

CONTAINER ID        IMAGE                          COMMAND                CREATED             STATUS                      PORTS               NAMES

94f49f7fcf81        hello-world:latest             "/hello"               11 minutes ago      Exited (0) 11 minutes ago                       desperate_jones         
8dbb57d6f332        wordpress:latest               "/entrypoint.sh apac   4 days ago          Up 4 days                   80/tcp              webstack_wordpress_atomit
6c0f15270888        wordpress:latest               "/entrypoint.sh apac   5 days ago          Exited (0) 2 minutes ago                        webstack_wordpress_1    
  • Pour supprimer un conteneur docker qui a été lancé, il faut :

Arrêter le conteneur et ensuite taper la commande :  sudo docker rm ID_conteneur ou nom

root@sw:/home/arsene# sudo docker rm webstack_wordpress_1
webstack_wordpress_1

Pour supprimer l’ensemble des conteneurs docker qui sont à l’arrêt :

docker rm  $(docker ps -a  -q --filter "status=exited")

Stopper tous les conteneurs qui tourne d’un coup :

sudo docker stop $(docker ps -q)

Lancer ensemble tous les conteneurs docker qui ont été stoppés :

 sudo docker start $(docker ps -q)

Pour se connecter à l’interface de commande d’un conteneur par exemple pour faire des mises à jour ou installer un paquet :

 sudo docker exec -it webstack_nginx /bin/bash 

10

Pour vous déconnecter un simple exit suffit

11

NB : Lorsque vous stoppez un conteneur, les mises à jour que vous aviez installées dessus vont rester. Lorsque vous allez le relancer, vous retrouverez les mises à jour. Par contre si vous supprimez un conteneur sans avoir créé une image avec ce dernier afin de sauvegarder vos modifications vous perdez automatiquement toutes les modifications que vous aviez apportées au conteneur.

5. Liste des commandes DOCKER CLI

Je vais rapidement lister les commandes Docker disponibles, en expliquant leurs rôles (informations issues des manpages Docker). Vous pouvez obtenir ces informations depuis l’invite de commande en tapant : docker -h (résultat en anglais). Vous pouvez aussi obtenir les informations sur une commande particulière en tapant : docker [commande] –help

docker attach : Joindre à un conteneur en cours d’exécution
docker build : Construire une nouvelle image à partir du code source dans le PATH
docker commit : Créer une nouvelle image à partir des changements d’un conteneur
docker cp : Copier des fichiers ou des dossiers depuis le PATH d’un conteneur vers le HOSTDIR ou vers STDOUT
docker create : Créer un nouveau conteneur
docker diff : Inspectez changements sur le système de fichiers d’un conteneur
docker events : Obtenir des événements en temps réel depuis le serveur
docker exec : Exécuter une commande dans le conteneur en cours d’exécution
docker export : Exporter le contenu d’un système de fichiers d’une archive tar vers STDOUT
docker history : Afficher l’historique d’une image Docker
docker images : Lister des images
docker import : Créer une image de système de fichiers vide et y importer le contenu d’une l’archive (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz), puis éventuellement y ajouter une étiquette (tag)
docker info : Afficher l’ensemble des informations système
docker inspect : Afficher les informations de bas niveau sur un conteneur ou une image Docker
docker kill : Tuer un conteneur en cours d’exécution en utilisant SIGKILL ou un signal spécifié
docker load : Chargez une image à partir d’une archive tar sur STDIN
docker login : Inscrivez-vous ou connectez-vous à le Docker Register (HUB)
docker logout : Déconnexion du Docker Register (HUB)
docker logs : Fetch des journaux d’un conteneur
docker pause : Mettre en pause tous les processus dans un conteneur
docker port : Liste les ports d’un conteneur, ou rechercher les ports “public” naté vers un PRIVATE_PORT
docker ps : Liste de conteneurs
docker pull : Récupérer une image ou un repository à partir du Docker HUB
docker push : Publier une image ou un repository vers le Docker HUB
docker rename : Renommer un conteneur Docker
docker restart : Redémarrez un conteneur en cours d’exécution
docker rm : Supprimer une ou plusieurs conteneurs
docker rmi : Supprimer une ou plusieurs images
docker run : Exécuter une commande dans un nouveau conteneur
docker save : Enregistrer une image dans une archive tar (streaming vers STDOUT par défaut)
docker search : Rechercher des images sur le Docker Hub
docker start : Lancer un ou plusieurs conteneurs arrêtés
docker stats : Afficher l’utilisation des ressources d’un ou plusieurs conteneurs sous la forme d’un flux
docker stop : Arrêtez un conteneur en cours d’exécution en envoyant SIGTERM et SIGKILL après une période de grâce
docker tag : Étiqueter une image dans un repository
docker top : Afficher les processus en cours d’exécution d’un conteneur
docker unpause : Réactiver tous les processus dans un conteneur
docker version : Afficher les informations de version Docker
docker wait : Bloquer jusqu’à l’arrêt du conteneur, puis imprime son code de sortie

6. Webographie

Wanadev

Le Blog Nicolargo

 

NGINX et Let’sEncrypt

1.Configuration de Let’s Encrypt

Pour faire ce tutoriel, nous supposons que vous avez lu notre précédent article sur la configuration de NGINX. Votre serveur nginx doit être installé et fonctionnel. Maintenant que notre serveur web fonctionne correctement, nous pouvons essayer de faire des améliorations en sécurisant les échanges entre notre serveur et nos clients. Pour cela nous allons mettre en place du HTTPS. Au lieu d’acheter un certificat, nous allons utiliser ce petit projet gratuit, mais aussi  génial qu’est Let’s Encrypt. Il va nous permettre de créer des certificats automatiques et gratuits pour chacun de nos sites et nous pourrons même utiliser ses certificats pour sécuriser les sites pour lesquelles nous jouons le rôle de serveur proxy.

1.1 Installation du Client Certbot

Le nouveau client recommandé pour let’s Encrypt est Certbot. Nous allons commencer par l’installer sur notre système. Pour cela nous allons ajouter dans notre liste de dépôt (/etc/apt/source.list) si ce n’est pas déjà le cas le dépôt qui contient certbot. Nous sommes sur debian 8 (Jessie) donc si vous avez une autre version de linux ou une autre version de debian je vous invite a retrouver le dépôt qui a certbot (informations sur https://certbot.eff.org) ou alors d’utiliser un autre client.

Ouvrir le fichier avec :

nano /etc/apt/sources.list

Ajouter la ligne suivant à la fin du fichier :

deb http://ftp.debian.org/debian jessie-backports main non-free contrib
deb-src http://ftp.debian.org/debian jessie-backports main non-free contrib
deb http://ftp.debian.org/debian jessie main non-free contrib
deb-src http://ftp.debian.org/debian jessie main non-free contrib

Ensuite, mettez à jour la liste des paquets et installer certbot

apt update  &&  apt-get install certbot -t jessie-backports

Maintenant Certbot est installé. Certbot dispose d’un mode automatique qui va installer les dépendances nécessaires à l’outil et mettre en place les certificats en fonction de votre configuration serveur. Cette méthode d’installation automatique fonctionne  déjà très bien avec un le serveur web apache, mais reste à l’heure  actuelle (26/09/2016) expérimentale pour nginx (ce qui a peux être changé entre-temps). Il possède aussi le mode manuel. Dans ce cas, vous allez vous-même lancer la commande de génération de certificat pour chacun des sites que vous voulez passer en HTTPS et modifier vous-même les fichiers de configuration pour rediriger automatiquement les requêtes HTTP vers HTTPS.  Nous allons utiliser ce dernier mode.

1.2 Utilisation du client Certbot

1.2.1 Mode de fonctionnement et configuration

Pour générer nos certificats manuellement nous pouvons utiliser notre propre serveur web ou alors le serveur web interne à certbot.

  • Pour utiliser le serveur web interne à certbot, il est recommandé de couper momentanément notre serveur web personnel pour libérer le port 80 (pas très pratique si vous avez des sites qui tournent déjà et que vous ne voulez pas les interrompre). Dans ce cas on utilise la commande  certbot certonly –standalone -d example.com -d example.com
  • Pour utiliser notre propre serveur Web interne, nous allons faire appel aux plug-ins WebRoot. Afin de vérifier que vous êtes bien le possesseur du nom de domaine pour lequel vous souhaitez obtenir un certificat, Let’s Encrypt va générer un fichier sur votre serveur et va ensuite essayer d’y accéder depuis son serveur. Donc votre site web doit déjà être présent, fonctionnel et accessible de l’extérieur via le port 80. Cette configuration permet à Nginx d’avoir accès au répertoire .well-known/acme-challenge  afin de  créer les fichiers utiles à la validation de votre nom de domaine. Ajouter dans les configurations du site le contenu suivant  dans les balises server  { }.
# .well-known doit rester accessible pour que NGINX puisse le manipuler

    location ~ /\.well-known/acme-challenge {

        allow all;
    }

# On interdit habituellement l'accès au dotfiles (les fichiers cachés)

    location ~ /\. {

		deny all;

		access_log off;

		log_not_found off;

    }

NB : Quand vous souhaitez utiliser NGINX comme proxy vous devez vous aurez plutôt à ajouter ceux-ci dans le virtualhost. Dans la partie HTTP de la requête avant la redirection vers le https.

location ~ /.well-known/acme-challenge {

        root /var/www/html/;

        allow all;

}

1.2.2 Commande à utiliser

Pour utiliser chacune de ces méthodes vous avec le choix entre le mode interactif et le mode ligne de commande. Dans tous les cas noter que lorsque vous lancé la requête de demande de certificat avec let’s Encrypt, il vérifiera que le nom de domaine pour le qu’elle vous demandé un certificat correspond bien à l’adresse IP publique avec la qu’elle vous lancé la requête. IL faudra aussi se rassurer que le port 80 de votre IP public soit bien natté sur le serveur ou est installé le client Certbot.

  1. Pour appeler le mode interactif (graphique) utilisez la commande :
certbot certonly

Ensuite, suivez les indications données par l’interface et renseignez les informations qui vous sont demandées.

  1. Pour utiliser le mode commande, vous renseignez la commande suivante :
certbot certonly --email mon_adresse@google.com --webroot -w /var/www/exemple -d exemple.com -d www.exemple.com -w /var/www/thing -d truc.fr -d m.truc.fr

Explication:

L’option –w permet de spécifier le répertoire racine (répertoire root) du ou des noms de domaine qui sont spécifiés juste après avec l’option –d (les noms de domaine (-d) spécifié avant la prochaine option –w pointe tous sur le même site).

L’option –email permet de spécifier une adresse email. Elle n’est pas obligatoire, mais elle vous permet de recevoir un mail lorsque votre certificat approche de sa date d’expiration (très pratique tout ça).

Donc dans ce cas il va créer :

  • Un certificat pour le domaine example.com qui a aussi pour nom example.com et qui a pour répertoire Racine /var/www/exemple.
  • Un Certificat pour pour le domaine thing.is qui a aussi pour nom m.thing.is et qui a pour répertoire racine /var/www/thing.
  • La demande de renouvellement du certificat sera envoyée à l’adresse gkja2013@gmail.com

NB : Les certificats ne sont pas créés dans les répertoires racines des serveurs.  Ce répertoire est utilisé juste pour la création des fichiers de validation du nom de domaine qui sont supprimés par la suite. Les certificats et clés de let’sEncrypt se trouvent dans les répertoires :

/etc/letsencrypt/archive
/etc/letsencrypt/keys
/etc/letsencrypt/live
/etc/letsencrypt/renewal/

Les fichiers créés respectent à chaque fois la convention :

Dans le Dossier live :

Certificat principal :  /etc/letsencrypt/live/mon_domaine.fr/cert.pem
Chaine de certificats supplémentaires  :  /etc/letsencrypt/live/mon_domaine.fr/chain.pem
Certificat principale + Chaine de certificats supplémentaires :  /etc/letsencrypt/live/mon_domaine.fr/fullchain.pem
Clé privée du certificat  :  /etc/letsencrypt/live/mon_domaine.fr/privkey.pem

Dans le dossier Archive :

/etc/letsencrypt/archive/mon_domaine.fr/fullchain.pem
/etc/letsencrypt/archive/mon_domaine.fr/privkey.pem
/etc/letsencrypt/archive/mon_domaine.fr/chain.pem
/etc/letsencrypt/archive/mon_domaine.fr/cert.pem

Donc en tapant

 ls /etc/letsencrypt/live/

vous aurez la liste des Certificats (en réalité le dossier parent qui les contient).

Si la génération de certificat se passe correctement vous devez avoir le message suivant :

Qui vous confirme que la génération de certificat a bien été effectuée.

1.3 Création des paramètres de session et configuration du Virtual Host

1.3.1 Création des paramètres de session

Attention : La création de paramètres de session n’est à effectuer qu’une seule fois sur le serveur et sera utilisée pour tous les sites. Vous pouvez néanmoins le relancer si vous souhaitez renouveler les paramètres (attention aux sessions en cours).

Après avoir créé les certificats, vous devez générer les clés de session et le paramètre Diffie-Helman (sert crypter le premier échange entre le serveur et le client).  Ceux-ci n’est pas obligatoires, mais permet d’accroitre la sécurité (si vous ne l’utilisez pas pour une raison ou pour une autre pensez à supprimer les lignes correspondantes dans le fichier de configuration). Nous allons créer un répertoire nommé ssl dans le répertoire de configuration de NGINX pour y générer ces fichiers.

sudo mkdir /etc/nginx/ssl
sudo openssl rand 48 -out /etc/nginx/ssl/ticket.key
sudo openssl dhparam -out /etc/nginx/ssl/dhparam4.pem 4096

NB: La dernière commande (celle qui génère le paramètre Diffie-Helman) prend beaucoup de temps vu que j’ai spécifié une clé de 4096 pour un max de sécurité. Donc, soyez très patient. Bon la vitesse dépendra aussi un peu de votre configuration.

1.3.2 Configuration du Virtual Host

Modifier ensuite votre Virtual host (le fichier de configuration du site) comme celui-ci en adaptant les configurations. Pensez à modifier mon_domaine.fr par le nom de votre domaine et /var/www/html  par le répertoire racine de votre site web. Ou alors, adaptez-le comme il faut pour un serveur proxy.

  • Pour un Site web:
# Redirection HTTP vers HTTPS

server {

        listen 80;

        # Vous pouvez en mettre plusieurs à la suite, Bien sûr faudrait qu’il ait été spécifié dans le certificat
        server_name mon_domaine.fr www.mon_domaine.fr;

  		location ~ /.well-known/acme-challenge {

        	root /var/www/html/;
        	allow all;

        }


		location / {

              return 301 https://www.mon_domaine.fr$request_uri;

        }

}



# Notre bloc serveur

server {

    # spdy pour Nginx < 1.9.5

    listen 443 ssl spdy;

    listen [::]:443 ssl spdy;

    spdy_headers_comp 9;


    server_name mon_domaine.fr www.mon_domaine.fr;
    root /var/www/html;
    index index.html index.htm;
    error_log /var/log/nginx/mon_domaine.fr.log notice;
    access_log off;


    ####    Locations

    # Si On veut cacher les fichiers statiques

    # location ~* \.(html|css|js|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires max; }

    # On interdit les dotfiles

    location ~ /\. { deny all; }


    #### SSL

    ssl on;
    ssl_certificate /etc/letsencrypt/live/mon_domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mon_domaine.fr/privkey.pem;



    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/mon_domaine.fr/fullchain.pem;

    # Google DNS, Open DNS, Dyn DNS

    resolver 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220 216.146.35.35 216.146.36.36 valid=300s;
    resolver_timeout 3s;



     ####    Session Tickets

    # [ATTENTION] Session Cache doit avoir la même valeur sur tous les blocs "server" et doivent être générés.

    ssl_session_cache shared:SSL:100m;
    ssl_session_timeout 24h;
    ssl_session_tickets on;

    # [ATTENTION] il faudra générer le ticket de session.

    ssl_session_ticket_key /etc/nginx/ssl/ticket.key;


    # [ATTENTION] Les paramètres Diffie-Helman doivent être générés

    ssl_dhparam /etc/nginx/ssl/dhparam4.pem;


    ####    ECDH Curve

    ssl_ecdh_curve secp384r1;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';



}

Pensez vérifier que les configurations de nginx sont correctes avec :

nginx -t 

avant de faire un reload des configurations du serveur pour éviter de le faire cracher.  Si tous est OK vous aurez  le message suivant :

Si tout est OK faite un :

services nginx reload     

ou

 systemctl reload nginx

Vous pouvez aussi écrire un script qui fait cela tout seul. Vous lui passez juste en paramètre les noms de domaines et les chemins racines souhaités pour les sites et lui il s’occupe du reste. Le script peut également faire toute les vérifications nécessaires.

  • Pour un site proxy :

Adapter les configurations précédemment utilisées pour le site web, pensez surtout à commenter ou a supprimer les 4 lignes suivantes :

  root /var/www/html;
  
  index index.html index.htm;
  
  error_log /var/log/nginx/ mon_domaine.fr.log notice;
  
  access_log off;

Et à les remplacer par les lignes suivantes en remplaçant http://127.0.01:3000  par l’adresse IP réelle et le port (l’adresse complète) du site vers lequel vous souhaitez pointer. Si  vous souhaitez accéder à un site en local utilisé plutôt localhost au lieu de 127.0.0.1.

     location / {

                proxy_pass         http://127.0.0.1:3000/;
                }

Vous avez surement remarqué que j’utilise ici HTTP au lieu de HTTPS en fait, je suppose, ici que c’est votre serveur proxy qui héberge le certificat SSL. Vous pouvez adapter les configurations en fonction de votre architecture.

  • Pour le site maitre :

C’est celui qui va être appelé par défaut si les autres sont indisponibles ou celui qui sera retourné tant que le nom de domaine pointe sur le serveur et n’est pas défini explicitement dans un virtual host(pour un Site). Cette configuration n’est pas absolument nécessaire. Vous la mettez en place sur un site si vous le souhaitez. Vous pouvez aussi  tous simplement laisser le visiteur tomber sur une page d’erreur au cas où il tape mal l’adresse de l’un de vos sites. Cette option est particulièrement intéressante si vous avez référencé tous les sites que vous hébergez sur une page.

NB : Il ne peut y avoir qu’un seul site maitre sur un serveur NGINX.

  • Ajouter simplement sur la ligne listen 80 ; de la configuration par défaut d’un site web le mot clé default_server. Vous aurez ceux-ci :   listen 80 default_server;
  • Et mettez le tild (_) comme nom de serveur : server_name _ ;
  • Vérifier vos configurations :

Une fois que le SSL a été mis en place pour tester la robustesse de votre système il vous suffit de coller l’adresse de votre site ici. Se site testera si votre configuration respecte tous les principes de sécurité, car malgré l’utilisation du SSL si votre configuration est mal faite, il y aura des portes ouvertes pour les hackers.

1.4 Renouvellement du Certificat

Les certificats Let’sEncrypt ne sont valables que pendant 90 jours (3 mois).  Donc il est très facile d’oublier de les renouveler. La commande suivante renouvelle les certificats sans interaction de votre part. Cette commande ne fera rien si le certificat n’a pas encore besoin d’être renouvelé:

certbot renew

Si cela fonctionne correctement vous pouvez ajouter une entrée a la cron table ou job systemd pour faire cela automatiquement.

Le job se lance avec la commande :

certbot renew -q

La cron table nous permettra d’exécuter une tâche de manière récurrente :

sudo crontab -e

Ensuite, choisissez votre éditeur si c’est la première fois que vous utilisez crontab et qu’il vous le demande. Entrer les lignes suivantes.

La syntaxe des lignes de ce fichier est la suivante :  mm hh jj MMM JJJ tâche > log

mm : représente les minutes (de 0 à 59)

 hh : représente l’heure (de 0 à 23),

 jj : représente le numéro du jour du mois (de 1 à 31)

MMM : représente le numéro du mois (de 1 à 12) ou l’abréviation du nom du mois (jan, feb, mar, apr, …)

JJJ : représente l’abréviation du nom du jour ou le chiffre correspondant au jour de la semaine (0 représente le dimanche, 1 représente le lundi, …)

Tâche : représente la commande ou le script shell à exécuter

log : représente le nom d’un fichier dans lequel stocker le journal des opérations. Si la clause > log n’est pas spécifiée, cron enverra automatiquement un mail de confirmation. Pour éviter cela il suffit de spécifier > /dev/null.

Ex : tous les 23h30 :   30 23 * * * df >>/tmp/log_df.txt

Ajoutez les lignes suivantes dans votre cron table :

25 2 * * * date >> /var/log/certbot-renew.log

30 2 * * * certbot renew -q >> /var/log/certbot-renew.log

25 12 * * * date >> /var/log/certbot-renew.log

30 12 * * * certbot renew -q >> /var/log/certbot-renew.log

Si nginx a du mal à prendre en compte le nouveau certificat vous pouvez rajouter la ligne suivante :

35 2 * * * service nginx reload

NB : Si vous ajoutez la commande a la cron table ou à systemd, il est conseillé mettre une tâche récurrente qui se lance 2 fois par jour afin de rester actif auprès de let’sEncrypt . Cela vous permet de réduire les risques que votre certificat soit révoqué parce qu’arrivé à expiration ou pour une raison quelconque. De toutes les façons si le certificat n’a pas besoin d’être renouvelé, la commande ne fera rien.

1.5 Révocation de certificat

Si pour une raison ou une autre vous voulez révoquer votre certificat par exemple si votre clé privée a été corrompue, vous pouvez essayer la commande suivante :

certbot revoke --cert-path /etc/letsencrypt/live/mon_site.fr/cert.pem

Dans mon cas généralement elle ne renvoie aucune erreur et par moment elle renvoie une erreur (là je suppose qu’en même qu’elle a bien fonctionné). Mais peut-être a-t-elle été mise à jour entre temps. J’ai parfois l’erreur suivante alors que je lance la commande de suppression d’un certificat  d’un sous domaine pour la première fois.

An unexpected error occurred:
The request message was malformed :: Certificate already revoked
Please see the logfiles in /var/log/letsencrypt for more details.

Dans tous les cas une fois que cette commande a été exécutée pensez à supprimer les fichiers de l’ancien certificat :

rm  -r /etc/letsencrypt/live/mon_site.fr
rm -r /etc/letsencrypt/archive/mon_site.fr
rm /etc/letsencrypt/renewal/mon_site.fr.conf

NB : Je ne suis pas sûr que c’est très propre. Mais bon cela a le mérite de fonctionner.

Pour vérifier que votre certificat a bien été retiré de la liste de vos certificats, lancer la commande certbot renew. Elle vérifiera chacun de vos certificats et vous les affichera. Vous pouvez constater que le certificat qui a été révoqué et supprimé de la liste de vos certificats n’y est plus.

Si vous relancer la commande de création de certificats avec le même nom de domaine que vous avez précédemment révoqué vous pouvez constater que  le certificat est créé de nouveau et que la date d’expiration est différente du précédent certificat elle est calculée  à partir de la date à laquelle vous avez ressaisi la commande de création de certificats.

2.    Webographie

G33keries.org 

ZCFY (en anglais)

Configuration de NGINX

1.    Installation de NGINX

NGINX est un logiciel libre qui peut jouer le rôle de serveur web, reverse proxy etc. Son développement a débuté en 2002 pour les besoins d’un site russe à très fort trafic (Rambler).  NGINX est un serveur asynchrone par opposition aux serveurs synchrones ou chaque requête est gérée par un processeur dédié. Le traitement de chaque requête est découpé en plusieurs petites tâches qui sont réparties sur les différents processeurs du serveur.  Il offre donc une performance plus élevée et une charge de consommation de mémoire particulièrement faible comparativement aux serveurs HTTP.

Dans ce tutoriel nous allons parler du mode serveur web et du mode proxy de NGINX.  Il faut noter sur nginx, ses différents modes fonctionnent tous en même temps et il suffit de les configurer. Le mode serveur web est le mode classique et est déjà configuré de base. Le mode proxy qu’en a lui permet de jouer le serveur proxy pour d’autres sites hébergés en local ou alors sur d’autre serveur web sur le réseau.

Nous allons commencer par installer NGINX sur notre machine.

apt   update   &&   apt   install   nginx

Une fois l’installation terminée, si tout s’est passé correctement vous pouvez constater que la page web par défaut de NGINX est accessible via le port 80. Taper dans votre navigateur l’IP de votre serveur ou alors http://localhost.

Ce qu’il faut savoir :

Le fichier de configuration principal de NGINX c’est : /etc/nginx/nginx.conf

Les répertoires utilisés pour ajouter des configurations à NGINX sont :

  • /etc/nginx/conf.d/*.conf (pour les fichiers avec l’extension .conf) : dans ce répertoire on place par exemple le fichier de configuration de PHP ou du serveur proxy pour NGINX.
  • /etc/nginx/sites-enabled/* (pour tous les fichiers qu’il contient) : Dans se répertoire nous aurons la liste des sites actifs. Il contiendra uniquement des liens symboliques des fichiers de configuration des sites qui sont situés en réalité dans le répertoire /etc/nginx/sites-available/.

NB : Ces 2 répertoires sont spécifiés dans le fichier de configuration principal de NGINX.

2.  Configuration d’un site web

Pour configurer un site web il suffit de :

  • Créer un fichier qui contiendra les configurations du site dans le répertoire /etc/nginx/sites-available/. Attention, à ce stade le site n’est pas encore connu de nginx donc il n’est pas encore actif.
  • Un fichier de configuration pour le site par défaut existe déjà il se nomme défaut.

Les informations de base que doit contenir le fichier de configuration d’un site sont les suivants.

Créer un fichier :

nano  /etc/nginx/sites-available/first_site

Éditer son contenu comme suite :

server {

	listen 80;

	server_name first_site.com;
	root /var/www/first_site;
	index index.html index.php;

	location / {

		try_files $uri $uri/ =404;

	}

}

Explication :

listen : désigne le port d’écoute.

Server_name : c’est le nom de domaine que l’on veut filtrer.

Root : c’est le répertoire qui hébergera notre site web. (Pensez à attribuer correctement les droits d’accès).

Index : permets de spécifier dans l’ordre les fichiers qui seront recherchés en premier comme fichier d’index par le serveur web.

Location : permets de configurer des actions automatiques lorsqu’un chemin est appelé, de charger des Frameworks, etc.

  • Créer ensuite un lien symbolique de ce fichier dans le répertoire /etc/nginx/sites-enabled/ afin d’activer le site. Il est à noter que pour désactiver le site temporairement il suffit de supprimer le lien symbolique qui est dans sites-enabled et pour le réactiver, il faut refaire un lien symbolique avec le fichier qui se trouve dans site-available.

Créer un lien symbolique pour activer notre site :

Positionné vous dans le répertoire sites-enabled

cd  /etc/nginx/sites-available/
ln -s /etc/nginx/sites-available/default
  • Vérifier les configurations de NGINX et recharger le fichier de configuration.

Vérifier les configurations :

nginx  -t

Vous devez avoir un résultat comme celui-ci

Recharger la configuration de NGINX :

service nginx reload

Essayer ensuite d’accéder à votre site web via le nom spécifié dans server_name. Bien évidemment vous devez avoir mis en place une résolution de nom afin que ce nom pointe vers votre serveur web.

3. Configuration de la fonction proxy

Contrairement à la fonctionnalité serveur web qui est configurée par défaut, la fonctionnalité serveur proxy doit être configurée pour être utilisable.

Il suffit de créer un fichier.  Proxy.conf dans le répertoire conf.d. ce fichier permet de spécifier les paramètres de configuration du serveur proxy.

nano    /etc/nginx/conf.d/proxy.conf

Entrer ensuite le contenu :

proxy_redirect          off;

proxy_set_header        Host            $host;

proxy_set_header          X-Forwarded-Host $host;

proxy_set_header          X-Forwarded-Server $host;

proxy_set_header          X-Forwarded-Proto $scheme;

proxy_set_header        X-Real-IP       $remote_addr;

proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

client_max_body_size    10m;

client_body_buffer_size 128k;

client_header_buffer_size 64k;

proxy_connect_timeout   90;

proxy_send_timeout      90;

proxy_read_timeout      90;

proxy_buffer_size   16k;

proxy_buffers       32   16k;

proxy_busy_buffers_size 64k;

Vérifier les configurations de nginx :

nginx -t

Si tout est OK, alors relancez le service :

service nginx reload

Maintenant que la fonctionnalité Proxy est configurée. Si vous voulez créer un site qui pointe vers un autre (fonction proxy). Il suffit de créer un site en respectant les mêmes spécifications que celles vues plus haut dans le chapitre Configuration d’un site web. Sauf que nous allons adapter le fichier de configuration du site avec les configurations minimales suivantes :

nano /etc/nginx/sites-available/first_proxy.com
server {

	listen   80;
	server_name     first_proxy.com;

	location / {

		proxy_pass         http://localhost/;

	}

}

Pensez à créer le lien symbolique pour votre site si cela n’avait pas déjà été fait.

NB :

Ici nous n’avons plus de répertoire root car les requêtes seront redirigées vers le site pour lequel nous jouerons le rôle de serveur proxy.

Proxy_pass : permets de spécifier l’adresse du serveur proxy. http://localhost/. Si le site est accessible via un port autre que le port 80 vous devez spécifier l’adresse du site suivie du port  Ex : http://localhost:8080.

4. Système d’authentification Basic

Un système d’authentification basic vous permet de demander à l’utilisateur d’entre un login et un mot de passe pour avoir accès à une ressource (dans notre cas un site web).  Ce système est différent de l’interface de connexion du site, car il se lance avant même le chargement du code dans le répertoire.  Donc en gros le client n’a même pas accès à la page d’authentification du site s’il n’a pas les bons identifiants.

Ceci permettrait par exemple de protéger le répertoire qui contient les pages d’administration d’un site web.  Pour faire cela, on choisit un chemin qui sera protégé par notre code. Exemple : /admin ou /wp-admin comme c’est le cas sur WordPress. Cela permet d’accroitre la sécurité et de limiter les risques de brute force sur la page d’administration de votre site.

Pour commencer, nous allons installer l’outil apache2-utils  qui va nous permettre de créer le fichier de configuration pour l’authentification. Pour créer un fichier caché (.htpasswd) dans le répertoire /data/wordpress/, avec un utilisateur appelez Joel (vous pouvez avoir plusieurs utilisateurs différents dans le même fichier) utiliser la commande :

sudo   htpasswd   -c   /data/wordpress/.htpasswd   joel

Pour ajouter des utilisateurs à un fichier existant, utilisez la commande :

sudo   htpasswd    /data/wordpress/.htpasswd   joel

Si vous passez en paramètre le nom d’un utilisateur qui existe déjà, le mot de passe de ce dernier sera mis à jour.

Maintenant, ajouter les lignes suivantes dans le virtual host (dans le fichier de configuration de votre site web).  Ajoutez les dans les balises location de votre choix afin de protéger un chemin en particulier (se chemin peut être le  /). Dans mon cas je l’ajoute sur le chemin /admin

location   /admin/ {

	root   /var/www/mywebsite.com/admin;
	
	index  index.html index.htm;

	auth_basic "Restricted";                     #For Basic Auth

	auth_basic_user_file  /data/wordpress/.htpasswd; #For Basic Auth

}

Cette configuration est à adapter à votre configuration réelle.

Ensuite, vérifier les configurations de nginx :

nginx  -t 

rechargé ensuite les configurations si tout est correct :

Service  nginx  reload

Quand  vous essayez d’accéder à l’adresse qui a été spécifiée, vous aurez cette page d’authentification. La forme de la page d’authentification dépend bien sûr de votre navigateur :

1

5. Configuration de PHP

Après avoir configuré votre serveur web, vous pouvez ajouter un interpréteur php a NGINX afin de pouvoir héberger des sites codés en PHP sur votre Serveur.  Pour faire cela il suffit d’installer les paquets PHP (dans notre, car nous allons utiliser PHP-FPM) sur votre serveur et de configurer NGINC pour qu’il l’utilise PHP.

5.1  Installations de PHP-FPM

Mise à jour de la base de paquets et installation de PHP5-FPM

apt update && apt install PHP5-FPM

Nous utilisons ici php5-fpm au lieu de php car php-fpm est une implémentation alternative à PHP FastCGI qui offre en général de bien meilleures performances qu’en tant que module du serveur web. Le principe est de faire fonctionner php de manière séparée et d’utiliser le module FastCGI  afin de faire communiquer le serveur web avec l’interpréteur PHP.

5.2 Configuration de PHP-Fpm

Pour que nginx puisse transmettre les requêtes php a php-fpm il faut configurer le service d’écoute de php-fpm et ensuite le renseigner dans nginx pour qu’il puisse communiquer avec ce dernier.

Pour configurer php-fpm 2 possibilité s’offre à nous :

  • Si NGINX et PHP tourne sur la même machine, pour des raisons de performance nous utiliserons le socket Unix pour la communication.
  • Si nos 2 outils ne sont pas sur la même machine on se tourne vers le socket TCP.

Vu que dans notre cas PHP-FPM est installé sur la même machine que NGINX on va donc configurer PHP-Fpm pour qu’il utilise le Socket Unix.  Pour se faire nous allons modifier le fichier /etc/php5/fpm/pool.d/www.conf.

nano  /etc/php5/fpm/pool.d/www.conf

Chercher et modifier les 2 lignes suivantes. Vous commentez la première si elle est présente et vous décommettez la seconde si ce n’est pas déjà le cas.

;listen = 127.0.0.1:9000
listen = /var/run/php5-fpm.sock

ensuite pensez à redémarrer le service php-fpm pour appliquer les modifications.

service php5-fpm restart

5.3 Configuration de NGINX

On commence par déclarer le socket Unix de PHP-FPM au niveau de Nginx pour que celui-ci puisse lui transmettre les requêtes PHP qu’il reçoit, via /etc/nginx/conf.d/php5-fpm.conf.

nano   /etc/nginx/conf.d/php5-fpm.conf

Mettez-y le contenu suivant :

upstream php5-fpm-sock {

	server unix:/var/run/php5-fpm.sock;

}

Ensuite, adapter les configurations de votre Virtual host (fichier de configuration du site) pour qu’il ressemble à celui-ci. Cette configuration est à adapter en fonction de vos configurations réelles. En reprenant les configurations par défaut d’un site on ajoute les configurations pour interpréter le code PHP.

server {

	listen 80 ;

	root /var/www/html;

	index index.php index.html;

	server_name mon_domaine.fr www.mon_domaine.fr;

	access_log /var/log/nginx/mon_domaine.fr-access_log;

	error_log /var/log/nginx/mon_domaine.fr-error_log;

	location / {

		try_files $uri $uri/ /index.php?$args;

	}

	location ~ \.php$ {

		try_files $uri =404;

		fastcgi_index index.php;

		fastcgi_pass php5-fpm-sock;

		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

		include /etc/nginx/fastcgi_params;

	}

}

Créer ensuite un fichier php à la racine du répertoire de votre site :

echo "<?php phpinfo(); ?>" > /var/www/html/index.php

Redémarrer ensuite le service NGINX :

service nginx restart

Ensuite essayer d’accéder a votre site :  www.mon_domaine.fr vous aurez la page de PHP Version 5.6 suivant :

2

 6. Webographie

Le Blog Nicolargo

Le Blog de Guillaume