Discussion :

[DonKnacki]

Bonjour à tous

Je viens ici pour des conseils quant à la façon de gérer mes services OVH

En effet, j'ai pris un domaine + un hébergement chez eux
J'ai donc un site monsite.com.


j'ai aussi pris un VPS sur lequel j'ai installé un serveur WEB j'ai donc en localhot un second site.
J'ai également créé une redirection site1.monsite.com vers l'IP du VPS.

pour gérer les certificats SSL, je me débrouille avec certificate the web vu que mon serveur WEB est basée sur IIS

Problème; je souhaite prendre un dédié et peut être un second VPS. J'aurai encore des appli web dessus ; il faudra donc gérer les HTTPS pour chacune d'entre elles
Parfois avec certificate the web parfois avec keytool à priori... c'est assez laborieux
il n'y a pas mieux à faire ?

[gabriel21]

Vu que tu es sous Windows, je peux pas trop t'aider. En effet, toute mon infrastructure est sous Linux, je n'utilise que certbot et Let's Encrypt.
Par contre, je sais qu'OVH fournit un service SSL Gateway (https://www.ovh.com/fr/ssl-gateway/)automatisé pour les VPS et les hébergements dédiés.
La version de base est gratuite, voir si cela convient. J'avais hésité à la prendre avant de me lancer dans l'installation de certbot.

[DonKnacki]

le lien semble pas très bien fonctionner

concernant les sous domaines, c'est possible de rediriger un port vers un sous domaine ?
pour l'instant j'ai une appli web sur le port 80/443, une sur 8000, une 8080 et 8090 et enfin 8443 : je deviens fou
idéalement faudrait que je puisse utiliser un sous domaine pour chacun de ces ports
et pour chacun, il me faudrait un https ....

[Ti-Slackeux]

Ca sent l'usine à gaz pour moi >.<
Pourquoi pas un apache en frontal et les sous-domaines en vhost tout simplement ?
et comme le disait gabriel21, sous linux et avec Let's Encrypt ça roule tranquille.
Je me vois pas faire un serveur web sous iis >.<

hth,

[gabriel21]

le lien semble pas très bien fonctionner

Effectivement, j'ai un affichage pourri aujourd'hui, ce qui n'était pas le cas y hier. Et vu qu'OVH est entrain de fusionner plusieurs de leurs sites et services... J'étais chez Kimsufi et le passage au système de paiement commun à Kimsufi, soyoustart et OVH est quelque peu chaotique.

concernant les sous domaines, c'est possible de rediriger un port vers un sous domaine ?
pour l'instant j'ai une appli web sur le port 80/443, une sur 8000, une 8080 et 8090 et enfin 8443 : je deviens fou
idéalement faudrait que je puisse utiliser un sous domaine pour chacun de ces ports
et pour chacun, il me faudrait un https ....

Personnellement, j'ai un serveur apache avec plusieurs domaine et sous domaine.
Pas besoin de faire de redirection de port, juste configurer apache pour qu'il réponde à un sous domaine (Notion de Vhost).
Je suis entrain de terminer un tutoriel sur mon site qui aborde ce sujet : Multisite et SSL. Il paraitra probablement lundi prochain. Il fait la suite à une installation d'un Ubuntu server et à sa sécurisation. Le but de cette série est comment monter un ou plusieurs site web sur un serveur Linux en ne fournissant que l'indispensable.

[DonKnacki]

Oui c'est l'usine à gaz

J'ai suivi ton conseil et installé apache

Je commence à configurer le vhost

Code apache :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<VirtualHost *:8080>
    DocumentRoot "C:\Program Files\app1\***"
    ServerName app1.site.com
</VirtualHost>
 
<VirtualHost *:8080    
    DocumentRoot "C:\Program Files\app2\***"
    ServerName app2.site.com
 
</VirtualHost>

app1.site.com et app2.site.com doivent être déclaré chez OVH ? Je les dirige vers l'IP du serveur:8080 ?

[Ti-Slackeux]

ben moi je verrais pas çà sous cet angle mais plutôt comme çà.
Déjà pour rester propre, un fichier de conf par (sous)domaine et (imho) pas en Program Files.
Du coup par exemple, app-site1.conf

Code apache :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Virtualhost *:80
DocumentRoot "c:\le_rep_qui_va bien\app1
ServerName app.site1.com
/VirtualHost

et idem pour les autres.

site.com, app.site.com, app1.site.com pointent tous sur la même IP du serveur apache. Il faut bien les déclarer dans le DNS.

[gabriel21]

Oui c'est l'usine à gaz

J'ai suivi ton conseil et installé apache

Euh, comment as tu fais ?
WAMP et XAMP ne sont pas conseillé en production. Leurs performances sont clairement plus faible ainsi que la fiabilité. Ils sont avant tous prévu pour faire du développement.

Je commence à configurer le vhost
...
app1.site.com et app2.site.com doivent être déclaré chez OVH ? Je les dirige vers l'IP du serveur:8080 ?

Pourquoi diable veux tu absolument passer par des ports différents?
Si tu as une url du type app1.site.com, tu peux rester sur le port 80 pour tout tes sites. Apache redirigera automatiquement en fonction de la directive ServerName sur le bon répertoire.
Si tu mets en place le SSL, ce sera sur le port 443.
Le fait de rester sous Windows va maintenir une complexité pour la gestion des clés, vu qu'il y a peu de client pour Let's Encrypt voir la page https://letsencrypt.org/docs/client-options/ tu as un paragraphe Windows vers la fin de la page. Je n'ai testé aucun d'entre eux. Donc je ne sais pas qu'est ce qu'ils valent. Vu que la majorité des utilisateurs sont sous Linux, l'aide risque d'être plus complexe à obtenir.
Bon courage.

[DonKnacki]

Merci pour votre aide
Vous l'avez compris, je suis vraiment novice dans ce domaine et je tâtonne beaucoup.

Euh, comment as tu fais ?
WAMP et XAMP ne sont pas conseillé en production. Leurs performances sont clairement plus faible ainsi que la fiabilité. Ils sont avant tous prévu pour faire du développement.


Pourquoi diable veux tu absolument passer par des ports différents?

J'ai télécharger les binaires sur Apache Lounge.

Pourquoi ne pas prendre le port 80? Je suis contraints d'utiliser IIS pour mon appli principal donc c'est lui qui prend pour l'instant le port 80 et 443.
Après j'utilise beaucoup d'application qui "s'installe toute seule" et qui integre Apache/Tomcat, MySQL et autre... Du coup, est ce que je peux quand même utiliser mon Apache + vhost?

ben moi je verrais pas çà sous cet angle mais plutôt comme çà.
Déjà pour rester propre, un fichier de conf par (sous)domaine et (imho) pas en Program Files.
Du coup par exemple, app-site1.conf
...

Donc suffit que le fichier ait une extension .conf pour être pris en compte ? Et que le format soit correct bien sûr