Na początek trochę teorii. Co się stało ?
W prostych słowach dokument ten ma na celu uproszczenie tworzenia aplikacji SaaS, pomagając poprzez informowanie programistów i inżynierów DevOps o problemach i praktykach najczęściej spotykanych przy tworzeniu nowoczesnych aplikacji.
Dokument został stworzony przez twórców platformy Heroku.
Aplikację Twelve-Factor można zastosować w aplikacjach napisanych w dowolnym języku programowania i korzystających z dowolnej kombinacji usług pomocniczych (bazy danych, kolejki komunikatów, pamięci podręczne itp.).
Krótko o czynnikach, na których opiera się ta metodologia:
- Baza kodu – Jedna baza kodu śledzona w kontroli wersji – wiele wdrożeń
- Zależności – Jawnie deklaruj i izoluj zależności
- Konfiguracja – Zapisz konfigurację w czasie wykonywania
- Usługi wsparcia – Traktuj usługi pomocnicze jako zasoby wtyczek
- Kompiluj, wydawaj, uruchamiaj – Ściśle oddzielić etapy montażu i wykonania
- Procesy – Uruchom aplikację jako jeden lub więcej procesów bezstanowych
- Wiązanie portów – Eksportuj usługi poprzez wiązanie portów
- Współbieżność – Skaluj swoją aplikację za pomocą procesów
- Jednorazowość – Maksymalizuj niezawodność dzięki szybkiemu uruchamianiu i prostemu wyłączaniu
- Parytet rozwoju aplikacji/operacji – Staraj się, aby środowiska programistyczne, testowe i produkcyjne były jak najbardziej podobne
- Logowanie – Wyświetl dziennik jako strumień zdarzeń
- Zadania administracyjne – Wykonywanie zadań administracyjnych/zarządzających przy użyciu procesów ad hoc
Więcej informacji na temat 12 czynników można uzyskać z następujących zasobów:
- - musisz to przeczytać
- — oficjalne tłumaczenie
- - świeże spojrzenie na 12 czynników w celu ich ulepszenia.
Na czym polega wdrożenie Blue-Green?
Wdrożenie Blue-Green to metoda dostarczania aplikacji do produkcja w taki sposób, aby klient końcowy nie zauważył żadnych zmian z jego strony. Innymi słowy, wdrożenie aplikacji z zerem przestojów.
Klasyczny schemat BG Deploy wygląda jak ten pokazany na obrazku poniżej.
- Na starcie są 2 fizyczne serwery z absolutnie tym samym kodem, aplikacją, projektem i jest router (balancer).
- Router początkowo kieruje wszystkie żądania do jednego z serwerów (zielony).
- W momencie kiedy trzeba ponownie wypuścić cały projekt jest aktualizowany na innym serwerze (niebieski), który obecnie nie przetwarza żadnych żądań.
- Po włączeniu kodu niebieski serwer jest całkowicie zaktualizowany, router otrzymuje polecenie przełączenia zielony na niebieski serwer.
- Teraz wszyscy klienci widzą wynik działania kodu niebieski serwer.
- Na jakiś czas, zielony serwer służy jako kopia zapasowa w przypadku nieudanego wdrożenia niebieski serwer, a w przypadku awarii i błędów router przełącza z powrotem przepływ użytkowników zielony serwer ze starą, stabilną wersją, a nowy kod zostaje przesłany do sprawdzenia i przetestowania.
- Na koniec procesu jest on aktualizowany w ten sam sposób zielony serwer. Po aktualizacji router ponownie przełącza przepływ żądań zielony serwer.
Wszystko wygląda bardzo dobrze i na pierwszy rzut oka nie powinno być z tym żadnych problemów.
Ale ponieważ żyjemy we współczesnym świecie, opcja z fizycznym przełączaniem, jak wskazano w klasycznym schemacie, nam nie odpowiada. Na razie zapisz informacje, wrócimy do tego później.
Zła i dobra rada
Odpowiedzialność: Poniższe przykłady pokazują narzędzia/metodologie, których używam, możesz użyć absolutnie dowolnych alternatyw z podobnymi funkcjami.
Większość przykładów będzie w ten czy inny sposób krzyżować się z tworzeniem stron internetowych (to niespodzianka), z PHP i Dockerem.
Poniższe akapity zawierają prosty, praktyczny opis użycia czynników na konkretnych przykładach; jeśli chcesz poznać więcej teorii na ten temat, skorzystaj z powyższych linków do oryginalnego źródła.
1. Baza kodu
Użyj FTP i FileZilla, aby przesłać pliki na serwery pojedynczo, nie przechowuj kodu nigdzie indziej niż na serwerze produkcyjnym.
Projekt powinien mieć zawsze jedną bazę kodu, czyli cały kod pochodzi z jednej git magazyn. Serwery (produkcyjne, staging, test1, test2...) wykorzystują kod z gałęzi jednego wspólnego repozytorium. W ten sposób osiągamy spójność kodu.
2. Zależności
Pobierz wszystkie biblioteki w folderach bezpośrednio do katalogu głównego projektu. Dokonuj aktualizacji po prostu przenosząc nowy kod do folderu z aktualną wersją biblioteki. Zainstaluj wszystkie niezbędne narzędzia bezpośrednio na serwerze hosta, na którym działa 20 kolejnych usług.
Projekt powinien zawsze mieć jasno zrozumiałą listę zależności (przez zależności mam na myśli także środowisko). Wszystkie zależności muszą być jawnie zdefiniowane i izolowane.
Weźmy jako przykład Komponować и Doker.
Komponować — menedżer pakietów umożliwiający instalowanie bibliotek w języku PHP. Composer umożliwia ścisłe lub luźne określenie wersji oraz ich jawne zdefiniowanie. Na serwerze może znajdować się 20 różnych projektów i każdy będzie miał osobistą listę pakietów i bibliotek, niezależnych od siebie.
Doker — narzędzie umożliwiające zdefiniowanie i wyizolowanie środowiska, w którym aplikacja będzie działać. Odpowiednio, podobnie jak w przypadku kompozytora, ale dokładniej, możemy określić, z czym aplikacja współpracuje. Wybierz konkretną wersję PHP, zainstaluj tylko pakiety niezbędne do działania projektu, bez dodawania czegokolwiek dodatkowego. A co najważniejsze, bez ingerencji w pakiety i środowisko hosta oraz inne projekty. Oznacza to, że wszystkie projekty na serwerze uruchamiane za pośrednictwem Dockera mogą korzystać z absolutnie dowolnego zestawu pakietów i zupełnie innego środowiska.
3. Konfiguracja
Przechowuj konfiguracje jako stałe bezpośrednio w kodzie. Oddzielne stałe dla serwera testowego, osobne dla produkcji. Powiąż działanie aplikacji w zależności od środowiska bezpośrednio w logikę biznesową projektu za pomocą konstrukcji if else.
Konfiguracje - to jedyny sposób, w jaki wdrożenia projektów powinny się różnić. W idealnym przypadku konfiguracje powinny być przekazywane poprzez zmienne środowiskowe (env vars).
Oznacza to, że nawet jeśli przechowujesz kilka plików konfiguracyjnych .config.prod .config.local i zmienisz ich nazwę w momencie wdrożenia na .config (główny plik config, z którego aplikacja odczytuje dane) - nie będzie to właściwe podejście, ponieważ w takim przypadku informacje z konfiguracji będą publicznie dostępne dla wszystkich twórców aplikacji, a dane z serwera produkcyjnego zostaną naruszone. Wszystkie konfiguracje muszą być przechowywane bezpośrednio w systemie wdrożeniowym (CI/CD) i wygenerowane dla różnych środowisk z różnymi wartościami niezbędnymi dla konkretnego środowiska w momencie wdrożenia.
4. Usługi stron trzecich
Bądź ściśle powiązany ze środowiskiem, używaj różnych połączeń dla tych samych usług w określonych środowiskach.
W rzeczywistości ten punkt mocno pokrywa się z punktem dotyczącym konfiguracji, ponieważ bez tego punktu nie można utworzyć normalnych danych konfiguracyjnych i ogólnie możliwość konfiguracji spadnie do zera.
Wszystkie połączenia z usługami zewnętrznymi, takimi jak serwery kolejek, bazy danych, usługi buforowania, muszą być takie same zarówno dla środowiska lokalnego, jak i środowiska zewnętrznego/produkcyjnego. Innymi słowy, zmieniając w dowolnym momencie parametry połączenia, mogę zastąpić wywołania bazy nr 1 bazą nr 2 bez zmiany kodu aplikacji. Lub patrząc w przyszłość, na przykład podczas skalowania usługi, nie będziesz musiał w żaden specjalny sposób określać połączenia dla dodatkowego serwera pamięci podręcznej.
5. Zbuduj, wypuść, wykonaj
Miej tylko ostateczną wersję kodu na serwerze, bez możliwości wycofania wydania. Nie ma potrzeby zapełniania miejsca na dysku. Każdy, kto myśli, że może wypuścić kod do produkcji z błędem, jest złym programistą!
Wszystkie etapy wdrażania muszą być od siebie oddzielone.
Masz szansę się wycofać. Twórz wydania ze starymi kopiami aplikacji (już zmontowanymi i gotowymi do walki) zapisanymi w szybkim dostępie, aby w przypadku błędów móc przywrócić starą wersję. Oznacza to, że warunkowo istnieje folder komunikaty i folder aktualne, a po pomyślnym wdrożeniu i złożeniu folderu aktualne połączone symbolicznym linkiem do nowego wydania, które znajduje się w środku komunikaty z konwencjonalną nazwą numeru wydania.
W tym miejscu pamiętamy wdrożenie Blue-Green, które pozwala nie tylko przełączać się między kodem, ale także przełączać się między wszystkimi zasobami, a nawet środowiskami z możliwością przywrócenia wszystkiego.
6. Procesy
Przechowuj dane o stanie aplikacji bezpośrednio w samej aplikacji. Użyj sesji w pamięci RAM samej aplikacji. Korzystaj z możliwie najszerszego udostępniania między usługami stron trzecich. Polegaj na tym, że aplikacja może mieć tylko jeden proces i nie pozwala na skalowanie.
Jeśli chodzi o sesje, przechowuj dane tylko w pamięci podręcznej kontrolowanej przez usługi stron trzecich (memcached, redis), więc nawet jeśli masz uruchomionych 20 procesów aplikacji, każdy z nich po uzyskaniu dostępu do pamięci podręcznej będzie mógł kontynuować pracę z klientem w ten sam stan, w jakim użytkownik pracował z aplikacją w innym procesie. Dzięki takiemu podejściu okazuje się, że niezależnie od tego, z ilu kopii usług obcych skorzystasz, wszystko będzie działać normalnie i bez problemów z dostępem do danych.
7. Powiązanie portów
Tylko serwer WWW powinien wiedzieć, jak współpracować z usługami stron trzecich. Albo jeszcze lepiej, zainstaluj usługi stron trzecich bezpośrednio na serwerze internetowym. Na przykład jako moduł PHP w Apache.
Wszystkie Twoje usługi muszą być dla siebie dostępne poprzez dostęp do jakiegoś adresu i portu (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), czyli z nginx mogę uzyskać dostęp zarówno do php-fpm, jak i do postgres i od php-fpm do postgres i nginx i właściwie z każdej usługi mogę uzyskać dostęp do innej usługi. W ten sposób rentowność usługi nie jest powiązana z rentownością innej usługi.
8. Równoległość
Pracuj z jednym procesem, w przeciwnym razie kilka procesów nie będzie mogło się ze sobą dogadać!
Zostaw miejsce na skalowanie. Docker Swarm świetnie się do tego nadaje.
Docker Swarm to narzędzie do tworzenia i zarządzania klastrami kontenerów zarówno pomiędzy różnymi maszynami, jak i grupą kontenerów na tej samej maszynie.
Korzystając z roju, mogę określić, ile zasobów przydzielę każdemu procesowi i ile procesów tej samej usługi uruchomię, a wewnętrzny balanser, odbierając dane na danym porcie, automatycznie będzie je proxy do procesów. Zatem widząc, że obciążenie serwera wzrosło, mogę dodać więcej procesów, zmniejszając w ten sposób obciążenie niektórych procesów.
9. Jednorazowość
Nie używaj kolejek do pracy z procesami i danymi. Zabicie jednego procesu powinno mieć wpływ na całą aplikację. Jeśli jedna usługa przestanie działać, wszystko przestanie działać.
Każdy proces i usługę można wyłączyć w dowolnym momencie i nie powinno to mieć wpływu na inne usługi (oczywiście nie oznacza to, że dana usługa będzie niedostępna dla innej usługi, ale że inna usługa nie zostanie wyłączona po tej). Wszystkie procesy należy zakończyć elegancko, aby po ich zakończeniu żadne dane nie uległy uszkodzeniu, a system działał poprawnie przy następnym włączeniu. Oznacza to, że nawet w przypadku awaryjnego zakończenia dane nie powinny zostać uszkodzone (tutaj sprawdza się mechanizm transakcyjny, zapytania w bazie działają tylko w grupach, a jeśli choć jedno zapytanie z grupy zakończy się niepowodzeniem lub zostanie wykonane z błąd, wówczas żadne inne zapytanie z grupy ostatecznie nie zakończy się niepowodzeniem).
10. Parytet rozwoju aplikacji/działania
Wersja produkcyjna, staging i lokalna aplikacji muszą być różne. W produkcji używamy frameworka Yii Lite, a lokalnie Yii, dzięki czemu na produkcji działa szybciej!
W rzeczywistości wszystkie wdrożenia i praca z kodem powinny odbywać się w niemal identycznym środowisku (nie mówimy o sprzęcie fizycznym). Ponadto każdy pracownik programistyczny powinien być w stanie w razie potrzeby wdrożyć kod na produkcję, a nie specjalnie przeszkolony dział devops, który tylko dzięki specjalnym silom jest w stanie przenieść aplikację na produkcję.
Docker również nam w tym pomaga. Jeśli zachowane zostaną wszystkie poprzednie punkty, zastosowanie dockera sprowadzi proces wdrażania środowiska zarówno na produkcji, jak i na maszynie lokalnej, do wpisania jednego lub dwóch poleceń.
11. Dzienniki
Zapisujemy logi do plików i baz danych! Nie czyścimy plików i baz danych z logów. Kupmy po prostu dysk twardy z 9000 bajtów Peta i będzie dobrze.
Wszystkie logi należy traktować jako strumień zdarzeń. Sama aplikacja nie powinna być zaangażowana w przetwarzanie logów. Logi powinny być wyprowadzane na standardowe wyjście lub przesyłane protokołem np. udp, aby praca z logami nie stwarzała żadnych problemów dla aplikacji. Graylog jest do tego dobry. Graylog odbierający wszystkie logi poprzez udp (protokół ten nie wymaga oczekiwania na odpowiedź o pomyślnym przyjęciu pakietu) w żaden sposób nie ingeruje w działanie aplikacji a jedynie zajmuje się strukturowaniem i przetwarzaniem logów. Logika aplikacji nie zmienia się, aby pracować z takimi podejściami.
12. Zadania administracyjne
Do aktualizacji danych, baz danych itp. należy użyć oddzielnie utworzonego punktu końcowego w API, wykonanie go 2 razy z rzędu spowoduje zduplikowanie wszystkiego. Ale nie jesteś głupi, nie klikniesz dwa razy i nie potrzebujemy migracji.
Wszystkie zadania administracyjne należy wykonywać w tym samym środowisku co cały kod, na poziomie wydania. Oznacza to, że jeśli będziemy musieli zmienić strukturę bazy danych, to nie zrobimy tego ręcznie, zmieniając nazwy kolumn i dodając nowe za pomocą niektórych wizualnych narzędzi do zarządzania bazą danych. Do takich rzeczy tworzymy osobne skrypty – migracje, które są wykonywane wszędzie i we wszystkich środowiskach w ten sam sposób, ze wspólnym i zrozumiałym skutkiem. W przypadku wszystkich innych zadań, takich jak wypełnienie projektu danymi, należy zastosować podobne metodyki.
Przykładowa implementacja w PHP, Laravel, Laradock, Docker-Compose
PS Wszystkie przykłady zostały wykonane na MacOS. Większość z nich jest również odpowiednia dla systemu Linux. Użytkownicy Windowsa, wybaczcie, ale dawno nie pracowałem z Windowsem.
Wyobraźmy sobie sytuację, w której nie mamy zainstalowanej żadnej wersji PHP na naszym komputerze i w ogóle nic.
Zainstaluj najnowsze wersje dockera i docker-compose. (można to znaleźć w Internecie)
docker -v &&
docker-compose -v
1. Kładziemy
git clone https://github.com/Laradock/laradock.git &&
ls
Odnośnie Laradock'a powiem, że jest to bardzo fajna rzecz, która zawiera mnóstwo pojemników i rzeczy pomocniczych. Ale nie polecałbym używania Laradock jako takiego bez modyfikacji w produkcji ze względu na jego redundancję. Lepiej stworzyć własne kontenery na podstawie przykładów w Laradocku, będzie to znacznie bardziej zoptymalizowane, bo nikt nie będzie potrzebował wszystkiego, co tam jest na raz.
2. Skonfiguruj Laradock do uruchomienia naszej aplikacji.
cd laradock &&
cp env-example .env
2.1. Otwórz katalog habr (folder nadrzędny, do którego sklonowany jest laradock) w jakimś edytorze. (W moim przypadku PHPStorm)
Na tym etapie nadajemy projektowi jedynie nazwę.
2.2. Uruchom obraz obszaru roboczego. (W Twoim przypadku tworzenie obrazów zajmie trochę czasu)
Workspace to specjalnie przygotowany obraz do pracy z frameworkiem na zlecenie dewelopera.
Wchodzimy do wnętrza pojemnika za pomocą
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalacja Laravela
composer create-project --prefer-dist laravel/laravel application
2.4. Po instalacji sprawdzamy czy katalog z projektem został utworzony i zabijamy kompilację.
ls
exit
docker-compose down
2.5. Wróćmy do PHPStorm i ustawmy poprawną ścieżkę do naszej aplikacji laravel w pliku .env.
3. Dodaj cały kod do Git.
W tym celu utworzymy repozytorium na Githubie (lub gdziekolwiek indziej). Przejdźmy do katalogu habr w terminalu i wykonajmy poniższy kod.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Sprawdźmy, czy wszystko jest w porządku.
Dla wygody polecam użycie jakiegoś interfejsu wizualnego dla Gita, w moim przypadku tak . (tutaj link polecający)
4. Uruchommy!
Przed rozpoczęciem upewnij się, że nic nie zawiesza się na portach 80 i 443.
docker-compose up -d nginx php-fpm
Zatem nasz projekt składa się z 3 odrębnych usług:
- nginx – serwer WWW
- php-fpm - php do odbierania żądań z serwera WWW
- workspace - php dla programistów
Na ten moment udało nam się stworzyć aplikację spełniającą 4 punkty na 12, a mianowicie:
1. Baza kodu — cały kod znajduje się w jednym repozytorium (drobna uwaga: poprawne może być dodanie okna dokowanego wewnątrz projektu laravel, ale nie jest to istotne).
2. Zależności - Wszystkie nasze zależności są jawnie zapisane w pliku application/composer.json i w każdym pliku Dockerfile każdego kontenera.
3. Usługi wsparcia — Każda z usług (php-fom, nignx, workspace) żyje własnym życiem i jest połączona z zewnątrz, a podczas pracy z jedną usługą nie będzie to miało wpływu na drugą.
4. Procesy — każda usługa to jeden proces. Żadna z usług nie utrzymuje stanu wewnętrznego.
5. Wiązanie portów
docker ps
Jak widzimy, każda usługa działa na własnym porcie i jest dostępna dla wszystkich innych usług.
6. Współbieżność
Docker pozwala nam odradzać wiele procesów tych samych usług z automatycznym równoważeniem obciążenia między nimi.
Zatrzymajmy kontenery i przepuśćmy je przez flagę --skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Jak widzimy, utworzono kopie kontenera php-fpm. Nie musimy nic zmieniać w pracy z tym kontenerem. W dalszym ciągu mamy do niego dostęp także na porcie 9000, a Docker reguluje za nas obciążenie pomiędzy kontenerami.
7. Jednorazowość - każdy pojemnik można zabić bez szkody dla drugiego. Zatrzymanie lub ponowne uruchomienie kontenera nie będzie miało wpływu na działanie aplikacji podczas kolejnych uruchomień. Każdy kontener można także w dowolnej chwili podnieść.
8. Parytet rozwoju aplikacji/operacji - wszystkie nasze środowiska są takie same. Uruchamiając system na serwerze produkcyjnym, nie będziesz musiał niczego zmieniać w swoich poleceniach. Wszystko będzie oparte na Dockerze w ten sam sposób.
9. Logowanie — wszystkie logi w tych kontenerach trafiają do strumienia i są widoczne w konsoli Docker. (w tym przypadku w przypadku innych domowych pojemników może tak nie być, jeśli się tym nie zajmiesz)
docker-compose logs -f
Istnieje jednak pewien haczyk, że wartości domyślne w PHP i Nginx również zapisują logi do pliku. Aby spełnić 12 czynników, jest to konieczne wyłącz zapisywanie logów do pliku w konfiguracjach każdego kontenera osobno.
Docker udostępnia także możliwość wysyłania logów nie tylko na standardowe wyjście, ale także do takich rzeczy jak Graylog, o którym wspomniałem powyżej. Natomiast wewnątrz Grayloga możemy dowolnie operować logami i nasza aplikacja w żaden sposób tego nie zauważy.
10. Zadania administracyjne — wszystkie zadania administracyjne są rozwiązywane przez laravel dzięki narzędziu rzemieślniczemu dokładnie tak, jak chcieliby tego twórcy aplikacji 12-czynnikowej.
Jako przykład pokażę, jak wykonywane są niektóre polecenia.
Wchodzimy do kontenera.
docker-compose exec workspace bash
php artisan list
Teraz możemy użyć dowolnego polecenia. (pamiętaj, że nie skonfigurowaliśmy bazy danych i pamięci podręcznej, więc połowa poleceń nie zostanie wykonana poprawnie, ponieważ są zaprojektowane do pracy z pamięcią podręczną i bazą danych).
11. Konfiguracje i 12. Kompiluj, wydawaj, uruchamiaj
Chciałem poświęcić tę część Blue-Green Deployment, ale okazała się ona zbyt obszerna na ten artykuł. Napiszę o tym osobny artykuł.
W skrócie koncepcja opiera się na systemach CI/CD takich jak Jenkins и Gitlab CI. W obu przypadkach można ustawić zmienne środowiskowe powiązane z określonym środowiskiem. Zatem w tej sytuacji spełniony zostanie punkt c Konfiguracje.
I o to chodzi Kompiluj, wydawaj, uruchamiaj jest rozwiązywany przez wbudowane funkcje o nazwie Rurociąg.
Rurociąg pozwala podzielić proces wdrożenia na wiele etapów, podkreślając etapy montażu, wydania i wykonania. Również w Pipeline możesz tworzyć kopie zapasowe i właściwie wszystko. To narzędzie o nieograniczonym potencjale.
Kod aplikacji znajduje się pod adresem .
Nie zapomnij zainicjować podmodułu podczas klonowania tego repozytorium.
PS: Wszystkich tych podejść można używać z dowolnymi innymi narzędziami i językami programowania. Najważniejsze, że esencja się nie różni.
Źródło: www.habr.com