Hébergement et langages multiples VPS (Scaleway)

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 ) ?
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é »).

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".
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 )
- 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.

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

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.

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.

Je te conseil :
- La docs Docker (très explicite, j’ai appris dessus, mais pas que )
- Les tutoriels de Grafikart
- Internet

Wala

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 ?

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

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.

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

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 ?

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.

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.

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