Modifications pour le document Mettre en place un sous-domaine

Résumé

• Propriétés de la Page (1 modifications, 0 ajouts, 0 suppressions)
• Pièces jointes (0 modifications, 0 ajouts, 1 suppressions)
  • reverse-proxy-arch.png

Détails

Propriétés de la Page

Contenu

...	...	@@ -1,45 +1,6 @@
1	1	Lorsqu'une VM est mise en place, et que le service qu'elle doit héberger est installé, il est grand temps de rendre ce service accessible à l'extérieur du réseau d'ATILLA.
2	2
3		-{{toc/}}
4	4
5		-=Idée générale=
	4	+Dans l'infra d'ATILLA, les connexons à un service web (members.atilla.org, learn.atilla.org, …) passent en grande majorité par Bill, qui acte comme d'un frontal web : c’est lui qui réceptionne les connexions HTTP(s) et qui les renvoie aux bons services internes par la suite. On dit également que Bill joue le rôle de //reverse-proxy//.
6	6
7		-Avant de suivre les étapes de mise en place, c’est intéressant de comprendre ce qu’on va faire ^^.
8		-
9		-Dans l'infra d'ATILLA, les connexions à un service web (members.atilla.org, learn.atilla.org, …) passent en grande majorité par Bill, qui acte comme d'un frontal web : c’est lui qui réceptionne les connexions HTTP(s) et qui les renvoie aux bons services internes par la suite. On dit également que Bill joue le rôle de //reverse-proxy//.
10		-
11		-En plus de cela, Bill gère la terminaison des connexions HTTPs : c’est à dire que lorsqu’une connexion HTTPs arrive sur Bill, elle est déchiffrée, puis renvoyée en HTTP à la machine virtuelle qui correspond. Cela permet de ne pas complexifier l’installation des services, et d’avoir un endroit central ou gérer les certificats SSL.
12		-
13		-[[image:reverse-proxy-arch.png]]
14		-
15		-En pratique, Bill dispose d'un serveur Nginx, qui va avoir réceptionner toute requête HTTP(s) sur un des sites d'ATILLA et qui transfère cette requête à la VM qui héberge le service correspondant.
16		-
17		-=Enregistrement du sous-domaine=
18		-
19		-La première chose à faire est de déclarer au monde que le domaine sur lequel vous souhaitez déployer votre service existe. Il n’y a pas de convention à proprement parler sur le choix du sous-domaine. Si vous déployez un service de gestion de tickets (par exemple, GLPI), le domaine auquel ce service pourra être accessible peut très bien être ##glpi.atilla.org## ou même ##tickets.atilla.org##.
20		-
21		-Pour déclarer ce domaine, rendez-vous sur la machine qui sert de DNS dans l’infra (aujourd’hui, il s’agit de Bill). Deux fichiers devront être édités :
22		-* ##/etc/bind/internal/db.atilla.org## : les entrées DNS qui sont exposées à tous les utilisateurs au sein du réseau d’ATILLA et de l’EISTI
23		-* ##/etc/bind/external/db.atilla.org## : les entrées DNS qui sont exposées à tous les utilisateurs venant de l’extérieur
24		-
25		-Dans ces deux fichiers, rajoutez une ligne comme celle-ci :
26		-
27		-{{code language="none"}}
28		-monservice IN CNAME bill
29		-{{/code}}
30		-
31		-… puis redémarrez le serveur DNS :
32		-
33		-{{code language="none"}}
34		-systemctl restart bind9
35		-{{/code}}
36		-
37		-Cela aura pour effet de déclarer le sous-domaine ##monservice.atilla.org##.
38		-
39		-Si vous devez déclarer un service sur ##*.eistiens.net##, il faudra éditer les fichiers ##db.eistiens.net## dans les dossiers ##internal## et ##external## de la configuration du DNS.
40		-
41		-=Mise en place des certificats SSL=
42		-
43		-
44		-
45		-=Mise en place de la configuration Nginx=
	6	+Cette machine dispose d'un serveur Nginx, qui va avoir comme boulot de réceptionner toute requête HTTP sur un des sites d'ATILLA et de transférer cette requête à la VM qui héberge le service correspondant.

reverse-proxy-arch.png

Auteur

...	...	@@ -1,1 +1,0 @@
1		-XWiki.aubincleme

Taille

...	...	@@ -1,1 +1,0 @@
1		-17.5 KB

Contenu