Bonjour,
J'envisage de louer un serveur sur digitalocean (1 core CPU, 1 GB Memory / 25 GB Disk / AMS3 - Debian 11 x64 à 5$/mois).
J'ai une appli qui tourne sur 2 containers dockers (edit : 1 pour django et 1 pour nginx, la bdd est une sqlite incluse dans le container django). Je m'interroge sur le nombre de paires de containers dockers que je pourrais faire tourner sur la machine sans la saturer. Il s'agit d'une appli permettant de faire des blogs qui n'auront quasiment pas de traffic (ou tres peu).
Est ce que vous avez une idée à la louche? Si je veux tester, à partir de quel % utilisation cpu et % utilisation mémoire on considere que cest saturé?
(javais pour projet de publier des sites django sur aws lambda a des coûts défiant toute concurrence avec une bdd unique en commun sur un seul serveur mais je n'ai pas réussi à bien gérer les images sur aws lambda donc je me rabbat sur l'option multi containers sur un serveur)
Merci
# Une paire max
Posté par _kaos_ . Évalué à 3. Dernière modification le 29 mai 2022 à 08:16.
Hello,
L'offre a 5$ semble déjà une VM, le core CPU est un vCPU donc tu seras à mon avis en permanence à changer de contexte entre django, node.js, le système hôte et la bdd (si elle est là dessus aussi). Je ne sais pas si la mémoire sera suffisante également pour tout ça.
Après, je peux me tromper, mais je tablerai pas à plus haut (si tant est que ça passe, ce dont je doute un peu).
J'ai l'impression que ton appli est plutôt faite pour être instanciée façon kube. Si c'est ça, il faut probablement doubler la taille du serveur (et pas sur des vCPU) pour avoir le minimum pour une infra basique simple nœud master kubernetes.
Matricule 23415
[^] # Re: Une paire max
Posté par kr1p . Évalué à 1.
ok merci pour ce retour. As tu des métriques que je pourrais surveiller pour tester? A partir de quelle % de charge cpu ou mémoire on considere que cest saturé?
[^] # Re: Une paire max
Posté par xandercagexxx . Évalué à 3.
Au dela de la charge CPU/RAM, je pense qu'il est utile de monitorer le temps de réponse du/des blog.
Car cest ce qui va rendre le public satisfait ou non.
[^] # Re: Une paire max
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Je pense que mesurer CPU, RAM et temps de réponse permettront effectivement d'identifier à quel moment ton service se dégrade trop.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# revoir l'archi
Posté par NeoX . Évalué à 5.
j'imagine que le NGINX sert à recevoir les requetes de l'utilisateur, puis en fonction du domaine, l'envoyer au docker django.
1°) mettre nginx dans la machine principale (en evitant ainsi les surchouches docker
2°) faire des dockers de django, autant par applis souhaitées
en fait, la limite sera celle de tes besoins ?
si ton site genere des milliers de visites, que tu as plusieurs milliers d'utilisateurs simultanés, ce n'est pas la meme chose que si c'est juste ton CRM avec ton acces principal et un client de temps en temps qui vient consulter ses factures.
c'est donc bien l'usage de tes sites qui te permettra de savoir de combien tu as besoin.
[^] # Re: revoir l'archi
Posté par kr1p . Évalué à 2.
oui cest ca! en fait jai configuré les instances django pour fonctionner sur des ports differents car je veux que les blogs puissent fonctionner sans enregistrer un nom de domaine préalablement…
[^] # Re: revoir l'archi
Posté par NeoX . Évalué à 4.
s'il n'y a pas de domaine, alors le nginx n'est pas necessaire
tu as juste besoin d'un port de ta machine principale qui redirige vers le conteneur qui va bien et ca, c'est au lancement du conteneur que tu le determines
[^] # Re: revoir l'archi
Posté par kr1p . Évalué à 1.
oui en principe cest ca, mais je réutilise du code libre avec un container backend django, et un container frontend basé sur nginx (car le frontend react est "buildé" dans des fichiers statiques). je ne veux pas m'embeter dans un premier temps à changer tout le code pour avoir un seul container nginx pour tous les blogs, je vais rester par paires de containers pour chaque blog dans un premier temps.
[^] # Re: revoir l'archi
Posté par François GUÉRIN (Mastodon) . Évalué à 2.
J'héberge pas mal d'applis django sur des serveurs debian, voici comment je procède :
Pas de docker avec des virtualenv et gunicorn pour la partie WSGI.
Les applis sont accessibles par des virtual hosts, à travers nginx ou apache, selon les serveurs.
La communication entre le serveur web et django passe par un socket unix, à un emplacement "bien choisi", par exemple
/run/django/<vhost>.socket
Les logs sont redirigés par le fichier de conf nginx / apache dans le dossier de log de l'appli.
Courage !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.