pisanie kodu aplikacji wyprzedza większość rozwiązań chmurowych—rozwiązania, które większość programistów aplikacji pisze specjalnie na te dni.
aby poradzić sobie z tym dysonansem, pojawiła się 12-czynnikowa metodologia aplikacji. The 12 factors to podejście, które pomaga programistom pisać nowoczesne aplikacje w deklaratywny sposób, korzystając z jasnych umów wdrażanych za pośrednictwem chmury.
w tym artykule przedstawię metodologię aplikacji 12-factor i przedstawię podsumowanie jej zasad na wysokim poziomie.
jaka jest metodologia aplikacji 12-Factor?
w 2012 roku programiści w Heroku zadebiutowali 12-Factor app methodology. Programiści ci opracowali i wdrożyli setki aplikacji, które napisały tę metodologię, czerpiąc z ich doświadczeń z postrzeganiem aplikacji SaaS „na wolności”.
Ta grupa uważa metodologię za triangulację:
- idealne praktyki wspierające tworzenie aplikacji
- dynamika, która występuje jako aplikacja rośnie organicznie
- relacje i współpraca między programistami baz kodowych
ich cele są dwojakie.:
- aby uniknąć kosztów erozji oprogramowania
- aby zwiększyć świadomość problemów systemowych, które obserwowali w tworzeniu nowoczesnych aplikacji
Grupa wskazuje na dwa inspirujące źródła, wzorce architektury aplikacji korporacyjnych i refaktoryzacji, oba autorstwa profesjonalnego programisty Martina Fowlera.
a teraz przedstawię każdy z 12 czynników.
zasada I. baza kodu
„jedna baza kodu śledzona w kontroli wersji, wiele wdrożeń”
twoja baza kodu powinna mieć logiczny system kontroli wersji, który jest łatwy do zrozumienia.
każde wdrożenie powinno mieć własne repozytorium kodu, które można wdrożyć w wielu środowiskach. Unikaj umieszczania wielu aplikacji w tym samym repozytorium. To sprawia, że kontrola wersji jest prawie niemożliwa do zrozumienia, a wersje zostaną zaplątane, co spowoduje pracę bez wartości dodanej.
zasada II. zależności
„jawnie deklaruj i izoluj zależności”
zasada ta utrzymuje, że nigdy nie należy polegać na domniemanym istnieniu pakietów systemowych. Zamiast tego ”
- upewnij się, że biblioteki specyficzne dla aplikacji są dostępne
- sprawdź, czy dostępne są potrzebne biblioteki systemowe, takie jak curl lub ImageMagick. (Nie ma gwarancji, że istnieją one na każdym systemie, w którym aplikacja może działać w przyszłości.)
Ogólnie rzecz biorąc, aplikacja 12-funkcyjna musi być samodzielna. Aplikacja powinna być wystarczająco izolowana, aby uniknąć interakcji z konfliktującymi bibliotekami, które są zainstalowane na komputerze-hoście.
spójrzmy na przykład. W Pythonie można uzyskać deklarację i izolację, używając odpowiednio Pip i Virtualenv. Aby spełnić tę zasadę, musisz zawsze używać zarówno deklaracji zależności, jak i izolacji. Zarządzaj zależnościami wewnątrz aplikacji, a nie z zewnętrznego źródła. Zależności powinny być hostowane w repozytorium w aplikacji
zasada III. Config
„przechowuj konfigurację w środowisku”
aplikacja i jej konfiguracja powinny być całkowicie niezależne. Ponadto należy całkowicie unikać ciągłego przechowywania configs w kodzie.
Twoje konfiguracje powinny mieć osobny plik i nie powinny być przechowywane w repozytorium kodu. Osobny plik konfiguracyjny ułatwia aktualizację wartości konfiguracyjnych bez dotykania rzeczywistej podstawy kodu, eliminując potrzebę ponownego wdrażania aplikacji po zmianie niektórych wartości konfiguracyjnych.
gdy konfiguracja znajduje się w środowisku, a nie w aplikacji, jako zmienne, możesz łatwo przenieść ją do innego środowiska bez dotykania kodu źródłowego. Aplikacje 12factor przechowują konfiguracje jako zmienne, dzięki czemu są” mało prawdopodobne, aby zostały przypadkowo sprawdzone w repozytorium”. Kolejny bonus: Twoje configs są niezależne od języka i systemu operacyjnego.
zasada IV. usługi wspierające
„traktuj usługi wspierające jako dołączone zasoby”
w aplikacji 12-funkcyjnej wszelkie usługi, które nie obsługują podstawowej aplikacji, muszą być dostępne jako usługa. Te podstawowe usługi mogą obejmować:
- bazy danych
- pamięć zewnętrzna
- kolejki wiadomości
- itp.
można je traktować jako zasób. Powinny one być dostępne jako usługa poprzez HTTP lub podobne żądanie, a następnie określone w konfiguracji. W ten sposób można zmienić źródło usługi bez wpływu na główny kod aplikacji.
na przykład aplikacja korzystająca z systemu kolejkowania wiadomości jest najlepsza, jeśli może łatwo zmienić z RabbitMQ na ZeroMQ na ActiveMQ, zmieniając tylko informacje konfiguracyjne.
zasada V. Build, release, run
„ściśle oddzielne etapy budowania i uruchamiania”
12-czynnik aplikacja jest ściśle o oddzielenie trzech etapów budowania, zwalniania i uruchamiania.
rozpocznij proces budowania, przechowując aplikację w kontroli źródła, a następnie zbuduj jej zależności. Oddzielenie informacji o konfiguracji oznacza, że możesz połączyć ją z kompilacją na etapie wydania—i wtedy jest gotowa do etapu uruchamiania. Ważne jest również, aby każde wydanie miało unikalny identyfikator.
zasada VI. procesy
„wykonaj aplikację jako jeden lub więcej procesów bezstanowych”
przechowuj wszelkie dane wymagane do zachowania w usłudze wspierającej stan, takie jak bazy danych. Chodzi o to, że proces jest bezpaństwowy i nie dzieli absolutnie nic.
podczas gdy wielu programistów jest przyzwyczajonych do „sticky sessions”, przechowywanie informacji w sesji oczekującej następnego żądania będzie z tego samego serwisu zaprzecza tej metodologii.
zasada VII. zasada wiązania portów
„eksport usług poprzez wiązanie portów”
aplikacje 12-funkcyjne muszą być zawsze niezależne od dodatkowych aplikacji. Każda funkcja powinna być własnym procesem – w pełnej izolacji.
w tradycyjnym środowisku Zakładamy, że różne procesy obsługują różne funkcjonalności. W związku z tym łatwo jest założyć, że te funkcje są dostępne za pośrednictwem protokołu internetowego, takiego jak HTTP, co sprawia, że prawdopodobnie aplikacje będą działać za serwerami internetowymi, takimi jak Apache lub Tomcat. Jest to jednak sprzeczne z metodologią 12-czynnikową.
zamiast tego dodaj bibliotekę serwera www lub podobną do podstawowej aplikacji. Oznacza to, że aplikacja może czekać na żądania na zdefiniowanym porcie, niezależnie od tego, czy jest to HTTP, czy inny protokół.
zasada VIII. współbieżność
„Skaluj za pomocą modelu procesu”
prawdziwa 12-funkcyjna aplikacja przeznaczona jest do skalowania. Twórz aplikacje tak, aby skalowanie w chmurze przebiegało bezproblemowo. Gdy opracujesz aplikację tak, aby była równoległa, możesz bez wysiłku tworzyć nowe instancje w chmurze.
aby zwiększyć pojemność (uruchomić dodatkowe procesy na dodatkowych maszynach), Twoja aplikacja powinna być w stanie dodać więcej instancji zamiast więcej pamięci lub procesora na komputerze lokalnym.
zasada IX. Disposability
„zmaksymalizuj wytrzymałość dzięki szybkiemu uruchamianiu i zgrabnemu zamykaniu”
koncepcja procesów jednorazowego użytku oznacza, że aplikacja może umrzeć w dowolnym momencie, ale nie wpłynie na użytkownika—aplikację można zastąpić innymi aplikacjami lub uruchomić ponownie. Budowanie jednorazowości do aplikacji zapewnia, że aplikacja wyłącza się z wdziękiem: powinien oczyścić wszystkie wykorzystane zasoby i zamknąć płynnie.
po zaprojektowaniu w ten sposób aplikacja szybko powraca. Podobnie, gdy procesy kończą pracę, powinny zakończyć bieżące żądanie, odrzucić każde przychodzące żądanie i zakończyć pracę.
zasada X. parytet Dev/prod
„utrzymuj rozwój, staging i produkcję tak podobne, jak to możliwe”
aplikacje wdrożone do rozwoju i produkcji powinny mieć parytet. Zasadniczo powinna istnieć tylko najmniejsza różnica między obydwoma wdrożeniami.
ogromna różnica może prowadzić do niezamierzonych problemów ze zgodnością między deweloperem a kodem produkcyjnym. Podczas tworzenia aplikacji 12-funkcyjnej usługi wspierające między dev i prod muszą być takie same; różnica tutaj może spowodować poważne problemy w dół linii.
zasada XI. Logi
„traktuj logi jako strumienie zdarzeń”
w przeciwieństwie do monolitycznych i tradycyjnych aplikacji, które przechowują informacje o logach w pliku, zasada ta utrzymuje, że powinieneś przesyłać logi do wybranej lokalizacji, a nie po prostu zrzucać je do pliku dziennika.
zazwyczaj dzienniki nie znajdują się w tym samym miejscu w środowiskach chmurowych po każdym wypaleniu. Gdy zaczną się nowe procesy lub aplikacja ulegnie awarii, logi będą dystrybuowane na kilku maszynach w chmurze; nie będą siedzieć na jednej maszynie lub hoście.
Rozwiąż ten problem, nazywając wspólne miejsce dla dzienników do przesyłania strumieniowego. W niektórych przypadkach możesz po prostu przekierować Stdout do pliku. Bardziej prawdopodobne jest jednak wdrożenie routera dziennika, takiego jak Fluentd, i zapisanie dzienników w Hadoop lub określonej usłudze, takiej jak Splunk.
zasada XII. procesy administratora
„uruchamianie zadań administratora/zarządzania jako procesów jednorazowych”
ostateczna 12-czynnik zasada aplikacji proponuje oddzielenie zadań administracyjnych od reszty aplikacji. Zadania te mogą obejmować migrację bazy danych lub inspekcję rekordów.
chociaż procesy administracyjne są oddzielne, musisz nadal uruchamiać je w tym samym środowisku i zgodnie z kodem podstawowym i konfiguracją samej aplikacji. Wysyłanie kodu zadań administratora wraz z aplikacją zapobiega dryfowi.
Related reading
- BMC DevOps Blog
- Agile vs Waterfall SDLCs: Jaka jest różnica?
- potoki wdrażania (CI/CD) w inżynierii oprogramowania
- czym jest programowanie Ekstremalne (XP)?
- Jak& dlaczego stać się fabryką oprogramowania
- najlepsze konferencje dotyczące programowania& tworzenie oprogramowania