Ceci est un scénario de planification illustratif pour un constructeur indépendant, et non un témoignage client ni un résultat de capacité mesuré. L'application enregistre les prêts de matériel pour un petit club : un membre authentifié peut voir les articles disponibles, créer un prêt et le retourner. Un enregistrement compte plus qu'un schéma de déploiement sophistiqué, donc la première conception doit rendre les écritures échouées et les données perdues faciles à analyser.
Choisir l'architecture minimale utile
Utilisez un processus API, une base de données et un proxy inverse pour le point de terminaison HTTPS public. Gardez la base de données accessible uniquement via le chemin local ou privé prévu. Donnez à l'application sa propre identité de système d'exploitation, avec accès aux fichiers dont elle a besoin. Gardez les fichiers de déploiement séparés des données persistantes afin qu'une release ne remplace pas la base de données ni les téléversements.
Partager une instance garde la configuration et l'analyse gérables pour un premier déploiement. Cela lie aussi les composants à la même frontière de redémarrage, de disque et de panne. Acceptez ce compromis délibérément. Si l'application exige une récupération indépendante ou si la base de données entre constamment en concurrence avec l'API, envisagez de les séparer avant d'augmenter tout d'un coup.
Budgéter pour le moment de pointe
Ne dimensionnez pas uniquement pour un processus au repos. La feuille de calcul ci-dessous utilise des marges de planification inventées pour démontrer le calcul. Ce ne sont pas des mesures de cette application, des références de performance ni des exigences minimales. Remplacez-les par des observations issues de votre runtime et de votre base de données, y compris un déploiement représentatif.
| Partage de l'instance | Marge de planification | Ce qu'il faut observer |
|---|---|---|
| Système d'exploitation et proxy | 300 Mio | Activité de fond normale et journalisation |
| Processus API | 350 Mio | Requêtes représentatives, pas seulement le démarrage |
| Base de données | 400 Mio | Connexions, requêtes et travaux de maintenance |
| Marge de déploiement | 450 Mio | Tout processus ou étape de build qui se chevauche |
| Enveloppe de planification combinée | 1,500 Mio | Comparer avec la mémoire réellement utilisable |
Le Plan de départ Build spécifie actuellement 2 vCPU, 2 GB de RAM et 50 GB SSD. Ces chiffres en font une configuration à examiner pour cette feuille de calcul, et non la preuve que la pile tient. Les Go du catalogue et les relevés en Mio d'un outil sont des unités différentes ; inspectez les totaux réels du système. L'estimation de mémoire disponible de Linux tient compte de la mémoire récupérable pertinente, donc une faible mémoire libre seule n'est pas un verdict de dimensionnement. Voir l'explication du noyau concernant MemAvailable et les guide de mesure.
Le CPU et le disque nécessitent des décisions distinctes. Enregistrez les durées de requête et les attentes de la base de données avant d'ajouter des vCPU. Budgétez le disque pour le système d'exploitation, les releases conservées, la croissance de la base de données, les journaux et les travaux de récupération temporaires. Une fonctionnalité de téléversement crée un problème de stockage différent d'un petit enregistrement structuré ; donnez-lui une limite de taille et une décision de rétention.
Connaître le coût initial
L'exemple suivant utilise Build avec ses ressources par défaut et aucune option récurrente ajoutée. Son sous-total mensuel est de $14.00 USD. Les valeurs sont générées à partir du catalogue actuel du configurateur afin que le tableau des prix suive le passage en caisse.
| Période de service | Avant l'enregistrement | Enregistré | Payer une fois |
|---|---|---|---|
| 1 mois | $14.00 | $0.00 (0%) | $14.00 USD |
| 3 mois | $42.00 | $0.00 (0%) | $42.00 USD |
| 6 mois | $84.00 | $23.52 (28%) | $60.48 USD |
| 12 mois | $168.00 | $84.00 (50%) | $84.00 USD |
Une période semestrielle ou annuelle réduit le total initial de ce catalogue par rapport au paiement du sous-total mensuel non remisé pour le même nombre de mois. Cela n'ajoute pas de ressources, n'établit pas de prix de renouvellement et ne rend pas une architecture non testée appropriée. Choisissez une période dans laquelle vous pouvez vous engager, consultez les détails du service et de la facturation, et prévoyez séparément un domaine, d'éventuels services externes et des frais de réseau.
Vérifier une requête complète
Avant d'ouvrir l'application à ses utilisateurs prévus, confirmez l'accès au serveur et l'accès à la récupération, installez un runtime pris en charge et enregistrez la release que vous déployez. Une définition de service doit identifier l'exécutable, le répertoire de travail et l'utilisateur du runtime. Le paramètre Restart= de Systemd contrôle le comportement d'échec spécifié ; une boucle de redémarrage nécessite toujours un diagnostic. Voir le manuel du service et les tutoriel de déploiement.
Testez d'abord localement, puis via le véritable nom HTTPS depuis une autre connexion. Avec Caddy, la gestion automatique des certificats dépend d'une configuration de nom valide et d'une méthode de validation fonctionnelle ; les défis HTTP et TLS-ALPN courants nécessitent respectivement des ports entrants accessibles 80 et 443. Voir les prérequis Caddy HTTPS. Un succès local ne peut pas exclure un problème de DNS ou de proxy, comme l'explique le guide du chemin de requête .
Rendez le test applicatif spécifique : créez un article d'équipement jetable, prêtez-le, confirmez qu'une seconde requête voit le résultat stocké, puis retournez-le. Vérifiez l'autorisation ainsi qu'un simple point de terminaison de santé. Enregistrez les réponses attendues avant le test et gardez les identifiants et les données des membres hors des journaux partagés pour le dépannage.
Prouver une petite récupération
Sauvegardez la base de données avec une méthode adaptée au moteur et à l'objectif de restauration. PostgreSQL documente des approches logiques, de système de fichiers et d'archivage continu distinctes ; le bon choix dépend de la façon dont vous devez récupérer. Voir sa présentation des sauvegardes. Si des photographies d'articles sont téléchargées, incluez ces fichiers et la relation avec leurs enregistrements de base de données.
Réalisez un exercice de restauration dans une base de données et un répertoire de test séparés. Trouvez un article connu et son fichier correspondant, puis vérifiez que l'application peut lire les deux. Notez la sauvegarde sélectionnée, l'horodatage des données, les étapes nécessaires et le résultat réel. Le premier guide de restauration développe cet exercice. Une sélection facultative de sauvegarde du catalogue ne prouve pas que cette récupération au niveau de l'application fonctionne.
Prendre la décision suivante à partir des preuves
Restez sur la conception simple tant que son comportement mesuré et ses exigences de récupération conviennent. Examinez une application arrêtée ou avertissements de ressources avant de supposer qu'un plan plus important est la solution. Choisissez la Malaisie, la Roumanie ou la Suisse pour le serveur, puis confirmez l'allocation des ressources, l'emplacement de sauvegarde et la portée du service. Ce scénario n'établit ni installation, ni capacité de requêtes, ni délai de livraison.
Configurer Build et examiner chaque option. Le lien ouvre le plan de départ ; vérifiez la période sélectionnée et les choix enregistrés avant de continuer. La saisie des détails de paiement n'installe pas l'application de prêt d'équipement.
Documentation utilisée
Références principales pour cette page. Consultez la documentation de la version installée dans votre propre environnement.