Hébergement et langages multiples VPS (Scaleway)

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut à tous,

Ca fait un moment que je développe des prototypes de sites internet en local, et j’envisage d’héberger un ou plusieurs sites internet dans le futur.
J’ai repéré une offre d’hébergement qui me plaît beaucoup de par la liberté et la flexibilité qu’elle offre, néanmoins elle me fait poser de nombreuses questions.

L’offre en question est la série VPS chez Scaleway.
Après quelques recherches je suis tombé sur cette page qui indique qu’il n’est pas possible d’assigner plusieurs adresses IP (publiques) à un serveur.
Mon but étant de pouvoir éventuellement héberger plusieurs sites sur un seul serveur, j’ai appris en poursuivant mes recherches que je pouvais héberger plusieurs sites internet avec des noms de domaine différents sur une même machine à l’aide des hôtes virtuels (virtuahosts), comme en local en somme. :)

Néanmoins, ce qui me « chagrine » c’est qu’en continuant mes recherches dans ce sens, j’ai également lu qu’avec cette technique il n’était pas possible d’utiliser les certificats SSL.
Etant donné que je pensais utiliser Let’s Encrypt, je souhaiterais qu’on me confirme cette information, et si elle est exacte, j’aurais aimé savoir s’il n’y avait pas une astuce pour passer outre cet inconvénient. Autrement dit, héberger plusieurs sites internet avec 1 seul serveur, 1 seule adresse IP, et avec un cerificat SSL chacun.

Autre question, toujours dans la même optique, comme cet hébergement pourrait me servir à tester des frameworks et langages autres que PHP, qui requièrent pour certains un programme supplémentaire pour fonctionner, est-ce que cela pourrait poser problème ?
Concrètement pourrais-je, par exemple, héberger un site codé en PHP avec Symfony, Laravel etc., puis un autre en Ruby avec Ruby on Rails et qui utilise Phusion Passenger, Puma etc., et pourquoi pas encore un autre en Python avec Django et qui utiliserait Gunicorn (inspiration ZdS :D ) ?
J’imagine que oui dans la mesure où tous les sites utilisent, par exemple, Apache comme serveur web grâce aux hôtes virtuels.
Mais qu’en serait-il si certains utilisaient Apache et d’autres Nginx ? :-° Est-ce possible ?

Je suis bien évidemment aussi ouvert aux réponses incomplètes avec des liens ou toute ressource qui pourrait me mettre sur la piste.
Un grand merci d’avance à tous ceux qui prendront le temps de répondre (et à ceux qui ont lu mon petit « pavé »).

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut :)
Alors, je vais essayer de répondre à tout (il ce peut que j’oublie une réponse, je commence à fatiguer)
On peut héberger x sites et x domaines sur un serveur et surtout une même IP
De mon coté, j’ai une IP et 25 sites sur un même serveur, tous en HTTPS (et j’ai même un certificat let’s encrypt pour mon serveur mail, donc c’est aussi possible d’avoir autant de certificat que de domaine / sous domaine sur une même IP (OVH à fait comment sinon ? ^^ )
On peut, techniquement, héberger un reverse proxy en front (nginx notament), et des serveurs en back-end. Il suffit d’utiliser proxy pass. En terme de sécurité je sais pas comment ça ce passe, car si on ferme tout les ports via les iptables, est-ce que apache va tenter d’en ouvrir un port extérieur pour écouter quand même ou on peut le restreintre à rester en écoute en local… A voir
Tu peux utiliser plusieurs services, exemple : nginx en reverse proxy ecoute le port 80 et 443, apache écoute le port 127.0.0.1:8080 (si, comme ça c’est possible alors ! ), nginx 2 écoute le port 8081, redmine écoute le port 3000… Et avec proxy_pass de nginx tu fais proxy_pass 127.0.0.1:8080 (par exemple). EDIT : j’ai failli oublié, je sais pas si avec ton VPS ça sera possible, mais pour un projet comme le tiens, je te conseil Docker (après je ne l’ai testé que sur un serveur dédié ou une machine local, je sais pas si ça tourne sur un VPS )

Normalement, j’ai répondu à tout ce soir, ma prochaine réponse sera demain ;)

Bonne soirée / nuit :)

Édité par Dryusdan

+3 -0
Auteur du sujet

Déjà, ça me rassure déjà d’être certain que c’est possible.

Maintenant je n’ai plus qu’à lire "L’administration système pour les nuls". :lol:
Plus sérieusement, c’est sûr que tout ça va être compliqué à mettre en place, mais je ne m’attendais pas à quelque chose de simple, et je pense que le jeu en vaut la chandelle.

Concernant Docker, ça fait maintenant plusieurs mois que je vois cet outil revenir systématiquement dans les discussions concernant le développement. Jusqu’à maintenant, je n’ai pas pris le temps de m’y intéresser plus que ça, mais de ce que j’en ai compris jusqu’ici il s’agit d’un logiciel permettant de créer des conteneurs (une sorte d’équivalent aux machines virtuelles bien que différents dans leur fonctionnement), conteneurs qui contiennent les différents environnements de travail/développement, indépendants les uns des autres, mais qui peuvent partager des fichiers en commun.
C’est bien ça ?
Sinon, oui il est bien supporté par l’hébergeur en question, il me semble d’ailleurs qu’il recommande aussi son utilisation. :)

Donc en résumé, en terme d’infrastructure on aurait la chose suivante :
- le serveur matériel avec une adresse IP publique,
- sur ce serveur il faudrait installer Docker (après le système d’exploitation bien sûr :D )
- il faudrait créer plusieurs conteneurs Docker pour chaque environnement dédié à PHP, à Ruby, à Python, et associés
- tous ces conteneurs partageraient Nginx (qui servirait de "reverse proxy"), et Apache en tant que serveur web

Schématiquement (et grossièrement) :
requête web –> IP publique du serveur –> Nginx redirige vers le nom de domaine concerné par la requête –> (dans un conteneur Docker) application web –> Phusion/Puma/Gunicorn pour du Ruby/Python avec tous les outils nécessaires –> (hors conteneur Docker)Apache prend le relais en tant que serveur web.

Je suis dans le juste, seulement à peu près ou totalement à côté de la plaque ?

Ca fait beaucoup de récapitulatifs, mais je pense que c’est primordial, sans comprendre le fonctionnement théorique, aucune chance d’arriver à mettre le tout en place. :pirate:

+0 -0

C’est exactement ça ! Après l’utilisation de docker n’est pas forcé, tu peux utiliser un simple reverse proxy vers les différentes appli, mais si l’une consomme elle pénalise les autres. Sur Docker tu peux configurer ça ;)

+1 -0
Auteur du sujet

Je suis déjà bien content d’avoir compris la théorie, maintenant reste la mise en pratique, et là ça risque d’être une autre paire de manches. :pirate:

Merci pour ces éclaircissements, je passe le sujet en résolu.
Cela dit si quelqu’un a des liens expliquant les manipulations à effectuer je suis toujours preneur. :)

+0 -0
Auteur du sujet

Pour ce qui est de Docker, j’ai justement jeté un coup d’œil en début d’après-midi, elle m’a l’air effectivement très claire et bien conçue.
Il me semblait avoir vu un tutoriel sur Grafikart il y a quelques temps mais j’avais un doute, je comptais justement vérifier. :)

Sinon, pour les liens, je ne pensais pas seulement à Docker, mais aussi et surtout pour la mise en place de l’hébergement de plusieurs sites internet avec un certificat SSL chacun sur une seule IP (avec ou sans Docker, je pourrais toujours m’adapter) via la solution que tu m’as indiqué.
Je suis tombé sur ce petit tuto, mais je ne sais pas ce qu’il vaut, et l’utilisation de certificats SSL n’est pas abordée.
J’ai aussi vu celui-ci qui a l’air de davantage correspondre à ce que je souhaite, néanmoins il s’agit de certificats SSL auto-signés, sais-tu s’il y a une différence avec la mise en place de certificats SSL "normaux" ?
Un avis sur ces liens ? Ou des sources que tu as toi-même utilisé pour mettre en place ton architecture ?

+0 -0

Cette réponse a aidé l’auteur du sujet

Je sais plus trop où est-ce que j’ai vu pour générer des certificats SSL
Mais j’utilise nginx en front qui route les accès au dossier .acme- sur le container letsencrypt
Mon architecture je l’ai monté à la main avec des connaissances acquises chez Olympe ^^

En gros mon fichier nginx en front ressemble à ça :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
server {
    #listen 4430 http2;
    listen [::]:4430 ipv6only=off http2;
    server_name www.dryusdan.fr;

    ssl on;
    ssl_certificate /certs/www.dryusdan.fr/fullchain.pem;
    ssl_certificate_key /certs/www.dryusdan.fr/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_dhparam /certs/private/dhparam.pem;

    fastcgi_keep_conn on; # < solution

    proxy_buffering off;
    include /conf.d/headers.conf;
    location /.well-known/acme-challenge {
        proxy_pass http://172.20.200.3:443;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
    proxy_next_upstream error timeout invalid_header http_502 http_504;
        proxy_pass http://172.20.200.32:8000;
    proxy_read_timeout  3600;
        include /conf.d/proxy-params.conf;
    }

}

Mais je viens de trouver un tuto qui t’aiderai ;)

+1 -0
Auteur du sujet

Carrément le ton fichier de configuration, je n’en attendais pas tant. :D

Je vais quand même prendre le temps d’étudier tout ça tranquillement parce que ça fait beaucoup d’informations et de connaissances à acquérir puis à mettre en place.
Je ferai probablement des retours de mes "expériences" ici.

En tout cas un énorme merci pour toute ton aide.

+0 -0

Si tu veux que je t’explique certaines chose, dis moi, j’ai envoyé le fichier conf sans aucune explication, j’avoue que j’aurai du attendre un peu, je cuisinais x)
Allez hop, on recommence :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
server {
    listen [::]:8000; #écoute le port 8000 pour l'ipv6 (mon image docker est faite comme ça)
    listen 8000; #écoute le port ,8000 pour l'ipv4    
    server_name www.dryusdan.fr; #il s'agit d'ici du nom du "virtualost" (comme apache appel ça)
    include /conf.d/headers.conf; #j'inclue quelques paramètres)
    large_client_header_buffers 4 32k; #pour éviter certaines erreurs de header trop lourd, notamment pour le cloud

    location /.well-known/acme-challenge { #nous y voilà ! Letsencrypt cherche un fichier .well-know/acme-challenge dans mon site web, je le redirige donc vers son conteneur
        proxy_pass http://172.20.200.3:80;
    proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;       
    include /conf.d/proxy-params.conf;
    }

    location / { #et ça c'est pour afficher le site normal
    #proxy_pass http://172.20.200.32:8000;
        #proxy_read_timeout  3600;
        #include /conf.d/proxy-params.conf;
    return         301 https://$server_name$request_uri;
   }

   location /assets/{ #pour autre chose
    return 301 https:/$server_name$request_uri;
   }

}

server {
    #listen 4430 http2; 
    listen [::]:4430 ipv6only=off http2; #pour ipv4 et ipv6
    server_name www.dryusdan.fr;

    ssl on; #activation du ssl
    ssl_certificate /certs/www.dryusdan.fr/fullchain.pem; #chemin d'un fichier généré par letsencrypt
    ssl_certificate_key /certs/www.dryusdan.fr/privkey.pem; #chemin d'un autre fichier
    ssl_session_timeout 5m; #hum... Copié collé
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #on accepte tous ces protocoles tls
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; #courbe de chiffrage (ou cryptage :-° )

    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_dhparam /certs/private/dhparam.pem; #clé privée généré avec openssl

    fastcgi_keep_conn on; # heu...

    proxy_buffering off; #heu...
    include /conf.d/headers.conf;
    location /.well-known/acme-challenge {
        proxy_pass http://172.20.200.3:443;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
    proxy_next_upstream error timeout invalid_header http_502 http_504;  #pour router sur des pages jolies d'erreur 502 / 504
        proxy_pass http://172.20.200.32:8000;
    proxy_read_timeout  3600;
        include /conf.d/proxy-params.conf;
    }

}

Wala ^^

+1 -0
Auteur du sujet

Si je comprends bien tes explications et le fichier :
- l’adresse IP publique est 172.20.200.32
- Nginx agit en tant que serveur frontal/reverse proxy
- le certificat SSL est "placé" sur l’adresse IP du serveur frontal
- dès que Nginx capture une requête sur l’adresse IP il la renvoie vers un autre serveur web (et le nom de domaine correspondant mais ici il n’y en a qu’un) qui écoute le port 8000 de l’adresse IP 172.20.200.32
- ton application et le serveur web font le traitement, renvoie le résultat au Nginx frontal qui le renvoie au client

Est-ce juste ?

Il y a quand même plusieurs choses que je ne comprends pas, et que je trouve curieuses.

Le fait qu’il y ait deux "server", j’imagine que c’est pour traiter deux cas, le premier celui où le navigateur du client ne supporte pas le http2, et le second a contrario si le navigateur le supporte. J’en conclus que la requête est redirigée sur un port différent selon le cas.

Ensuite dans le premier "server" les lignes censées renvoyer le site sont toutes commentées, il y a # devant, j’ai l’impression que ça devrait systématiquement retourner une erreur 301.
Idem pour les "assets".
J’imagine donc que j’ai loupé quelque chose. :)

Enfin, je ne comprends pas que les deux "server" ne contiennent pas les mêmes instructions, le deuxième en comportant beaucoup plus, mais n’en pas d’autres, cependant c’est peut-être lié à ma remarque précédente, et à l’élément qui m’a échappé.

Autre chose sur laquelle j’ai un doute soudain, le serveur web de l’application, il est dans le conteneur Docker ?

+0 -0

Cette réponse a aidé l’auteur du sujet

l’adresse IP publique est 172.20.200.32

Faux, les adresses privée vont de 172.16.0.0 a 172.31.255.255. Il s’agit donc d’une adresse privée, c’est à dire un serveur / container situé sur un réseau interne et fermé à l’extérieur.

Nginx agit en tant que serveur frontal/reverse proxy

Exact

le certificat SSL est "placé" sur l’adresse IP du serveur frontal

Vrai et faux ^^ les certificats SSL sont lié à un domaine / sous domaine. Exemple : j’ai un certicat pour www.dryusdan.fr et un autre pour git.dryusdan.fr, ils sont tous les deux sur la même IP et pas sur le même domaine ;) Cependant, le serveur frontal récupère le traffic en HTTPS et renvoie les données via cette connexion, mais il demande aux serveurs en back (le fameux 172.20.xxx.xxx) des données non chiffré.

dès que Nginx capture une requête sur l’adresse IP il la renvoie vers un autre serveur web (et le nom de domaine correspondant mais ici il n’y en a qu’un) qui écoute le port 8000 de l’adresse IP 172.20.200.32

ton application et le serveur web font le traitement, renvoie le résultat au Nginx frontal qui le renvoie au client

Oui, il n’y a que le serveur frontal qui écoute l’extérieur (en réalité il écoute le port 80 et docker redirige le port 80 vers le port 8000 de ce serveur ;)
Et oui, dès que Nginx récupère une requête via un nom de domaine, il la transmet au bon serveur qui va traiter pour la renvoyer au serveur frontal qui va la renvoyer au client

Le fait qu’il y ait deux "server", j’imagine que c’est pour traiter deux cas, le premier celui où le navigateur du client ne supporte pas le http2, et le second a contrario si le navigateur le supporte. J’en conclus que la requête est redirigée sur un port différent selon le cas.

Le 1er est le port 80 (redirigé vers le port 8000 par docker), le port HTTP, le second est le port 443 (redirigé vers le port 4430 par docker), le port HTTPS. Le HTTP2 signifie que si le client accepte l’HTTP2, on lui ouvre une connexion HTTP2

Ensuite dans le premier "server" les lignes censées renvoyer le site sont toutes commentées, il y a # devant, j’ai l’impression que ça devrait systématiquement retourner une erreur 301. Idem pour les "assets".

Tu as l’oeil ;) En réalité elles renvoient un code http 301 et redirige le site vers l’HTTPS. Cependant, Asset est buggué, il n’a qu’un / a http:/ ;) donc tu n’as rien loupé

Enfin, je ne comprends pas que les deux "server" ne contiennent pas les mêmes instructions, le deuxième en comportant beaucoup plus, mais n’en pas d’autres, cependant c’est peut-être lié à ma remarque précédente, et à l’élément qui m’a échappé.
Le 1er comporte peu d’instruction car il sert juste a rediriger vers l’HTTPS
Le 2ème serveur définit les clés des certificats, les paramètres du proxy ETC…

Autre chose sur laquelle j’ai un doute soudain, le serveur web de l’application, il est dans le conteneur Docker ?

Tous, je te fais un schéma dans quelques minutes ;)

Désolé pour la qualité, j’ai pas encore trouvé de bon éditeur d’image sur debian ^^ docker_explain

Édité par Dryusdan

+2 -0
Auteur du sujet

Je comprends un peu mieux, en fait quelques éléments m’avaient échappé jusque là.
Super utile le schéma, même s’il est basique et pas très esthétique, il permet de beaucoup mieux comprendre l’architecture utilisée et le fonctionnement de tout ça. :D

En fait absolument tout est dans un conteneur Docker, je pensais que le serveur frontal était en dehors.
Après quelques recherches, il me semble avoir compris qu’un conteneur ne contient pas tous les outils nécessaires au bon fonctionnement d’une application, mais que chaque outil occupait un conteneur différent.
Pour prendre un cas concret, si on a plusieurs sites qui utilisent PHP, mais pas forcément tous la même version, on pourrait avoir un conteneur qui contient juste PHP7, un autre juste PHP5 etc., et les conteneurs qui contiendraient l’application web feraient appel (je ne sais pas encore comment on fait ça en pratique, mais c’est l’idée) à la version de PHP souhaitée et donc au conteneur adéquat.
Par contre si tous les sites utilisent MySQL ou tout autre BDD, MySQL aura un conteneur qui lui sera propre, et qui sera utilisé/partagé par toutes applications situées dans les autres conteneurs.
C’est bien ça ou je fais à nouveau fausse route ?

Sinon, pour avoir testé, si on tape directement l’adresse IP de ton serveur dans un navigateur, on est dirigé vers un sous-domaine (bin). Néanmoins j’imagine qu’on pourrait tout fait configurer pour être redirigé sur le nom de domaine. :)

+0 -0

Mais il est très bien mon schéma ! xD J’arrivais pas a faire un rectangle avec Gimp donc j’ai cherché un paint sous Linux… ^^

Tu ne fais pas fausse route, et pour respecter le "concept" de docker, il faut que chaque image est une chose, cependant tu remarqueras que certaine embarque apache et php par exemple ;)

Pas faux, j’ai pas fait de fichier de redirection donc nginx prend le premier fichier de configuration qui lui tombe sous la main, et comme c’est une redirection… Je corrige ça vite fait ;)

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte