OffVPSOFFSHORE VPSWsparcie

ŚCIEŻKA APLIKACJI

Przydziel swojemu pierwszemu API budżet zasobów i plan odzyskiwania.

Dla pierwszego offshore VPS zacznij od jednej zrozumiałej ścieżki aplikacji: HTTPS dociera do API, API odczytuje i zapisuje w swojej bazie danych, a Ty potrafisz wyjaśnić, jak wdrożyć i odzyskać oba elementy.

Pierwszy VPS Linux dla małego API: ograniczony zakup i ścieżka operacyjna.

To ilustracyjne API wychodzi od Build jako punktu odniesienia, Malezja/Rumunia/Szwajcaria jako wyraźny wybór trasy oraz obraz wybrany z obsługiwanych instrukcji środowiska uruchomieniowego aplikacji. Nie jest to twierdzenie o wydajności ani zainstalowana aplikacja.

Zaplanuj budżet dla API, bazy danych, proxy, logów i zapasu na wydania; zmierz te same ścieżki żądań i przechowywania przed zmianą zasobów. Przygotuj dostęp SSH przed zmianą uwierzytelniania, trzymaj bazę danych i pliki w osobnym zestawie kopii zapasowych i przetestuj odzyskiwanie do izolowanego celu.

Upublicznij nasłuch HTTPS tylko tam, gdzie wymaga tego aplikacja. Trzymaj bazy danych i prywatną administrację na zamierzonych, węższych ścieżkach; opublikowany port kontenera nie jest automatycznie prywatny.

ilustracyjny plan obciążenia · Sprawdzony · 5 min czytania

To ilustracyjny scenariusz planowania dla niezależnego budującego, a nie historia klienta ani zmierzony wynik wydajności. Aplikacja rejestruje wypożyczenia sprzętu dla małego klubu: uwierzytelniony członek może zobaczyć dostępne przedmioty, utworzyć wypożyczenie i je zwrócić. Rekord ma większe znaczenie niż wymyślny diagram wdrożenia, więc pierwszy projekt powinien ułatwiać badanie nieudanych zapisów i utraconych danych.

Wybierz minimalną użyteczną architekturę

Użyj jednego procesu API, jednej bazy danych i odwrotnego proxy dla publicznego punktu końcowego HTTPS. Utrzymuj bazę danych osiągalną tylko przez zamierzoną lokalną lub prywatną ścieżkę. Nadaj aplikacji własną tożsamość systemu operacyjnego z dostępem do potrzebnych plików. Trzymaj pliki wdrożenia oddzielnie od danych trwałych, aby wydanie nie zastąpiło bazy danych ani przesłanych plików.

Współdzielenie instancji utrzymuje konfigurację i badanie w ryzach przy pierwszym wdrożeniu. Wiąże też komponenty z tą samą granicą restartu, dysku i awarii. Zaakceptuj ten kompromis świadomie. Jeśli aplikacja wymaga niezależnego odzyskiwania albo baza danych stale konkuruje z API, rozważ ich rozdzielenie, zanim zwiększysz wszystko naraz.

Zaplanuj budżet na szczytowy moment

Nie planuj rozmiaru tylko dla bezczynnego procesu. Poniższy arkusz używa wymyślonych założeń planistycznych, aby zademonstrować obliczenia. Nie są to pomiary tej aplikacji, benchmarki ani minimalne wymagania. Zastąp je obserwacjami ze swojego środowiska uruchomieniowego i bazy danych, w tym z reprezentatywnego wdrożenia.

Ilustracyjny arkusz pamięci; zastąp każde założenie
Praca współdzieląca instancjęZałożenie planistyczneCo obserwować
System operacyjny i proxy300 MiBNormalna aktywność w tle i logowanie
Proces API350 MiBReprezentatywne żądania, nie tylko uruchomienie
Baza danych400 MiBPołączenia, zapytania i prace konserwacyjne
Zapas na wdrożenie450 MiBDowolny nakładający się proces lub krok budowy
Łączna koperta planistyczna1,500 MiBPorównaj z rzeczywistą dostępną pamięcią

Ten Zbuduj plan startowy obecnie określa 2 vCPU, 2 GB RAM i 50 GB SSD. Te liczby czynią go konfiguracją do zbadania dla tego arkusza, a nie dowodem, że stos się zmieści. GB w katalogu i odczyty MiB w narzędziu to różne jednostki; sprawdź rzeczywiste sumy systemowe. Szacunek dostępnej pamięci w Linux uwzględnia odpowiednią pamięć podlegającą odzyskaniu, więc sama niska wolna pamięć nie jest werdyktem o rozmiarze. Zobacz wyjaśnienie jądra dotyczące MemAvailable oraz przewodnik po pomiarach.

CPU i dysk wymagają osobnych decyzji. Zapisuj czasy trwania żądań i oczekiwania bazy danych, zanim dodasz vCPU. Zaplanuj dysk dla systemu operacyjnego, zachowanych wydań, wzrostu bazy danych, logów i tymczasowych prac odzyskiwania. Funkcja przesyłania tworzy inny problem z pamięcią niż mały rekord strukturalny; nadaj jej limit rozmiaru i decyzję o retencji.

Poznaj koszt z góry

Poniższy przykład używa Build z domyślnymi zasobami i bez dodanych opcji cyklicznych. Jego miesięczna suma częściowa wynosi $14.00 USD. Wartości są generowane z bieżącego katalogu konfiguratora, więc tabela cen podąża za kasą.

Domyślna konfiguracja Build; cały okres jest opłacany jednorazowo
Okres usługiPrzed zapisaniemZapisanoZapłać raz
1 miesiąc$14.00$0.00 (0%)$14.00 USD
3 miesięcy$42.00$0.00 (0%)$42.00 USD
6 miesięcy$84.00$23.52 (28%)$60.48 USD
12 miesięcy$168.00$84.00 (50%)$84.00 USD

Okres sześciomiesięczny lub roczny obniża całkowitą kwotę z góry w tym katalogu w porównaniu z płaceniem nieprzecenionej miesięcznej sumy częściowej za tę samą liczbę miesięcy. Nie dodaje zasobów, nie ustala ceny odnowienia ani nie czyni nieprzetestowanej architektury odpowiednią. Wybierz okres, do którego możesz się zobowiązać, przejrzyj szczegóły usługi i rozliczeń, i uwzględnij osobno domenę, wszelkie usługi zewnętrzne i opłaty sieciowe.

Zweryfikuj jedno pełne żądanie

Przed otwarciem aplikacji dla docelowych użytkowników potwierdź dostęp do serwera i dostęp do odzyskiwania, zainstaluj obsługiwane środowisko uruchomieniowe i zapisz wydanie, które wdrażasz. Definicja usługi powinna wskazywać plik wykonywalny, katalog roboczy i użytkownika środowiska uruchomieniowego. Systemd Restart= ustawienie kontroluje określone zachowanie przy awarii; pętla restartów nadal wymaga diagnozy. Zobacz podręcznik usługi oraz instrukcją wdrażania.

Najpierw przetestuj lokalnie, a następnie przez rzeczywistą nazwę HTTPS z innego połączenia. W Caddy automatyczne zarządzanie certyfikatami zależy od prawidłowej konfiguracji nazwy i działającej metody walidacji; typowe wyzwania HTTP i TLS-ALPN wymagają osiągalnych portów przychodzących odpowiednio 80 i 443. Zobacz wymagania wstępne Caddy dla HTTPS. Sukces lokalny nie wyklucza problemu z DNS lub proxy, co wyjaśnia przewodnik po ścieżce żądania .

Sprawdź aplikację w konkretny sposób: utwórz jednorazowy przedmiot wyposażenia, wypożycz go, potwierdź, że drugie żądanie widzi zapisany wynik, a następnie zwróć go. Sprawdź autoryzację oraz prosty punkt końcowy kondycji. Zapisz oczekiwane odpowiedzi przed testowaniem i trzymaj poświadczenia oraz dane członków poza logami udostępnianymi do rozwiązywania problemów.

Udowodnij małe odzyskiwanie

Wykonaj kopię zapasową bazy danych metodą odpowiednią dla silnika i celu odzyskiwania. PostgreSQL opisuje oddzielne podejścia logiczne, systemowe i ciągłego archiwizowania; właściwy wybór zależy od tego, jak potrzebujesz odzyskiwać dane. Zobacz jego omówienie kopii zapasowych. Jeśli przesyłane są zdjęcia przedmiotów, uwzględnij te pliki i ich powiązanie z rekordami bazy danych.

Przeprowadź ćwiczenie odtwarzania do oddzielnej bazy danych testowej i katalogu. Znajdź znany przedmiot i odpowiadający mu plik, a następnie sprawdź, czy aplikacja może odczytać oba. Zapisz wybraną kopię zapasową, znacznik czasu danych, wymagane kroki i rzeczywisty wynik. Przewodnik po pierwszym odtwarzaniu rozwija to ćwiczenie. Opcjonalny wybór kopii zapasowej katalogu nie dowodzi, że to odzyskiwanie na poziomie aplikacji działa.

Podejmij kolejną decyzję na podstawie dowodów

Pozostań przy prostym projekcie, dopóki jego zmierzone zachowanie i wymagania dotyczące odzyskiwania są odpowiednie. Zbadaj zatrzymaną aplikację lub ostrzeżenia o zasobach zanim założysz, że odpowiedzią jest większy plan. Wybierz Malezję, Rumunię lub Szwajcarię dla serwera, a następnie potwierdź alokację zasobów, lokalizację kopii zapasowych i zakres usług. Ten scenariusz nie ustanawia żadnego obiektu, pojemności żądań ani czasu dostawy.

Skonfiguruj Build i przejrzyj każdą opcję. Link otwiera plan początkowy; przed kontynuowaniem sprawdź wybrany okres i wszelkie zapisane wybory. Pobranie danych płatności nie instaluje aplikacji do wypożyczania wyposażenia.

Wykorzystana dokumentacja

Główne źródła dla tej strony. Sprawdź dokumentację wersji zainstalowanej we własnym środowisku.