Gdzie Umieścić Konfiguracje? – Prosty przewodnik w węźle.JS
tl;dr: Sprawdź repo kodu pod adresem https://github.com/teamzerolabs/config-service-reference.
najprawdopodobniej tak. Dopóki program łączy się lub wykonuje połączenia ze zdalnymi punktami końcowymi, musi skądś uzyskać poświadczenia bezpieczeństwa.
istnieje wiele różnych sposobów załadowania tych poświadczeń do programu:
Poziom 1: Utwórz kod w samym pliku tekstowym — zwykle dzieje się to w piątek lub dla osób dopiero zaczynających. Reference repo powinno pomóc ci mieć kod, który możesz ściągnąć, aby użyć zamiast tego.
Poziom 2: ładowanie go z procesu.obiekt env w miejscu, w którym następuje połączenie-jest to lepsze niż twarde kodowanie, ale z czasem sprawia, że zmienna środowiskowa jest nieco trudna do wyśledzenia. Ponieważ nie można przejść do jednego pliku, aby znaleźć wszystkie powiązane zmienne środowiskowe.
Poziom 3: załaduj wszystkie konfiguracje środowiska z jednego pliku-jest to przewidziane w tym artykule i przykładzie kodu! Daje to korzyści z wiedzy, gdzie iść, aby wyszukać konfiguracje i pozwolić programowi na wcześniejsze niepowodzenie, jeśli złe wartości zostały dostarczone.
Poziom 4: Zamień skrypt konfiguracyjny w usługę-dzięki temu zyskujemy możliwość robienia innych ciekawych rzeczy: sprawdzania załadowanych wartości typu oraz ładowania dodatkowych konfiguracji z S3 lub bazy danych, przed uruchomieniem innego kodu inicjalizacyjnego.
zanim zaczniesz
- miej węzeł.Js runtime ready (Wersja > 10)
- Pobierz listonosza, jeśli nie — Alternatywnie możesz użyć przeglądarki lub curl, aby nacisnąć Api.
- Sprawdź https://github.com/teamzerolabs/config-service-referencew swojej lokalnej przestrzeni.
- Uruchom MySQL: włączyłem plik docker-compose w folderze
db-setup
, możesz go uruchomić, przechodząc tam i uruchamiającdocker-compose up -d
.
szybki przykład-usługa Minimum Book, która zwraca książki zapisane w bazie MySQL
w pierwszym folderze node-starthere
mamy dwa pliki:
- główna.js-to tutaj ustawiamy serwer
express
, aby obsłużyć żądanie nalocalhost:3000/books
- models/index.js-połączymy się z MySQL przez
mysql2
isequelize
. - Uruchom
yarn start
, aby rozpocząć.
możesz zobaczyć, jak dane uwierzytelniające bazy danych są obecnie przechowywane w models/index.js
:
minusem twardego kodowania danych uwierzytelniających bazy danych
- nie jest to bezpieczne — każdy, kto sprawdza publiczne repozytorium, będzie teraz wiedział za dużo, zwłaszcza jeśli twoja instancja bazy danych jest publiczna, jest teraz odsłonięta.
- trudno jest pracować w różnych środowiskach — jeśli chcesz połączyć ten kod z wdrożeniami testowymi lub produkcyjnymi, nie chcesz wprowadzać zmian w kodzie tylko na potrzeby wdrożenia.
Krok#1 — załaduj każdą ze zmiennych środowiskowych
możesz przeczytać więcej o zmiennych środowiskowych tutaj. Istotą tego jest to, że możesz przekazać wartości do uruchomionego programu w ten sposób
to podejście jest w porządku, jeśli masz małą liczbę konfiguracji, ale jak wszyscy wiemy, wszelkie projekty, które przetrwały pierwszy miesiąc użytkowania, zaczną integrować się z większą liczbą usług. (Ostatni 4-miesięczny projekt ma 40 zmiennych! Wyobraź sobie wpisanie ich do powyższej instrukcji yarn start, to za dużo).
Krok#2-Załaduj zmienne środowiskowe w czasie wykonywania dla lokalnego rozwoju przed użyciem.
na szczęście istnieje pakiet, który pozwoli nam uniknąć wpisywania zmiennych w kółko. Nazywa się dotenv
. Używasz dotenv w ten sposób:
Umieść swój kod pod src i stwórz folder config, a w nim plik .env
:
DATABASE_URL=localhost
DATABASE_PORT=3306
DATABASE_USERNAME=root
DATABASE_PASSWORD=dIKnUfyfUPURi9irSplTOqGO4OtE0
DATABASE_NAME=configexample
i dotenv.config
załaduje zmienne w plikach tekstowych do process.env
, teraz możesz pominąć wpisywanie zmiennych w yarn start
!
Krok#3 — wygoda metody do parsowania wartości i zakończyć wcześnie, jeśli ich brakuje
jedyną rzeczą bardziej niebezpieczną niż źle skonfigurowany program jest źle skonfigurowany program uruchomiony na koniec miesięcy.
jeśli zapomnieliśmy zrobić plik .env
lub włożyć do niego złe wartości, najlepiej chcemy wiedzieć jak najwcześniej. Uruchomienie kodu z niekompletną lub nieprawidłową konfiguracją utrudnia rozwiązywanie problemów.
jeśli spojrzysz na drugi folder node-with-config-service
, zobaczysz, że do parsowania zmiennych są dodawane następujące metody narzędziowe:
i przepisujemy sekcję połączenia z bazą danych do tego:
program zakończy działanie wcześniej z błędami, jeśli brakuje zmiennych środowiskowych, a Ty możesz polegać na statycznym obiekcie konfiguracyjnym istniejącym z dowolnego miejsca w programie!
istnieją jeszcze dwa rozszerzenia tego podejścia — możesz zastosować te same wzorce w maszynopisie i wyjść o krok dalej, konfigurując rzeczywistą usługę pomocniczą w NestJS. Oba są zawarte w repo git. Omówimy je w przyszłym artykule maszynopis+NestJs!