Strategie deploymentu aplikacji – przykłady AWS

Strategie deploymentu aplikacji – przykłady AWS

W wielu materiałach dostępnych w internecie możemy przeczytać, że najczęściej wybieranymi strategiami używanymi przy deploymencie aplikacji są: recreate, rolling-update, canary, blue-green, A/B testing oraz nieco nowsza strategia shadow deployment. W poniższym wpisie omówię wymienione metody oraz pokażę kilka przykładów wykorzystując chmurę AWS.

Deployment co to takiego ?

Zacznijmy od początku: co to jest deployment? Mówiąc krótko jest to proces, w którym dostarczamy naszą aplikację na serwery hostujące i odpowiednio ją konfigurujemy na danym środowisku. Z kolei strategia deploymentu to sposób w jaki dostarczamy taką zmianę.

Punktując wyżej wymienione strategie w kolejności od najprostszej do najbardziej skomplikowanej w implementacji są to:

  • recreate
  • rolling-update
  • canary
  • blue-green
  • A/B testing
  • shadow

Zanim przejdę do definicji poszczególnych metod dodam, że będę je opisywać w wersjach podstawowych ponieważ niektóre z nich mają swoje odmiany. Niektóre strategie posiadają kilka nazw. Czasem dostawcy chmur rozszerzają te metody o dodatkowe funkcjonalności lub inaczej je nazywają.

Recreate deployment

Recreate deployment jest jedną z najstarszych metod dostarczania oprogramowania na serwery hostujące, jest to jedna z prostszych implementacji do przeprowadzenia i obarczona największymi wadami. Polega ona na tym, że przed wystartowaniem nowszej wersji aplikacji najpierw zatrzymujemy wersję poprzednią. Świetnie spisuje się na nie produkcyjnych środowiskach, gdzie nie musimy martwić się o niezadowolonych klientów lub możemy sobie pozwolić na chwilowy brak komunikacji ze współdziałającymi komponentami. Do jej przeprowadzenia nie potrzebujemy dodatkowej infrastruktury. Wadą, która dyskwalifikuje takie podejście w środowiskach produkcyjnych ( choć nie zawsze 🙂 ) jest całkowity brak obsługi klienta w czasie od zatrzymania poprzedniej wersji aplikacji do chwili uruchomienia nowszej wersji oprogramowania.

Zalety:

  • Łatwa do przeprowadzenia
  • Nie potrzebujemy dodatkowej infrastruktury

Wady:

  • Okno, w którym serwis nie obsługuje klientów

Rolling-update deployment

Rolling-update znany też jako Ramped lub Incremental deployment jest strategią, w której serwis jest dostępnym cały czas. W tym przypadku proces wprowadzenia nowej wersji wygląda następująco: definiujemy okno czyli ilość instancji, która zostanie podmieniona w trakcie jednego przejścia aktualizacji. Na przykład mamy dziesięć instancji z wersją pierwszą, nasze okno wynosi dwa, więc zatrzymujemy dwie instancje i uruchamiany dwa nowe node-y z wersją drugą. Następnie wykonuje się kolejne przejście. Zatrzymujemy dwie instancje aplikacji w wersji pierwszej i w ich miejsce odpalamy dwie z wersją drugą. Kontynuujemy ten proces aż zostanie tylko dziesięć instancji aplikacji z wersją drugą. W tej wersji rolling-update nie potrzebujemy dodatkowej infrastruktury.

Ruch do drugiej wersji aplikacji rośnie stopniowo, więc dzięki temu jeśli coś jest nie tak z tą wersją tylko mały procent użytkowników odczuje problem. Implementacja tej strategii jest dość prosta. Niestety przejścia są też największą wadą opisywanej metody ponieważ nie mamy wpływy na to jaką wersję aplikacji dostanie użytkownik. Zarówno rollback i rollout jest czasochłonny. Dodatkowo musimy wspierać dwie wersje oprogramowania na raz co może być kłopotliwe.

Zalety:

  • Łatwy proces deploymentu
  • Nie potrzebujemy dodatkowej infrastruktury (w wersji podstawowej)
  • Stopniowe przenoszenie klientów do drugiej wersji

Wady:

  • Czasochłonny rollback i rollout
  • Brak kontroli nad ruchem
  • Konieczność obsługi wielu wersji aplikacji

Canary deployment

Kanarkowy deployment polega na tym, że wprowadzenie nowej wersji aplikacji odbywa się w dwóch przejściach. W pierwszym mała część ruchu np. 5% kierowana jest do nowej wersji aplikacji. Sprawdzamy wówczas czy wszystko działa poprawnie i w kolejnym przejściu pozostała część ruchu jest przekierowywana do wersji drugiej. Ten typ deploymentu wybierany jest najczęściej jeśli mamy obawy przed stabilnością nowszej wersji lub nie jesteśmy przekonani do jakości przeprowadzonych testów.

W przypadku błędów z wersją drugą możemy szybko przekierować cały ruch z powrotem do wersji pierwszej. Kanarkowy deployment w porównaniu do rolling-update różni się znacząco czasem trwania – jest od niego szybszy. Nie mamy też okna, sterujemy w nim wielkością ruchu przekierowanego do drugiej wersji aplikacji.

Zalety:

  • Mały user impact w przypadku błędów w nowej wersji
  • Dobry do sprawdzenia wydajności i błędów
  • Szybki rollback

Wady:

  • Powolny rollout

Blue-Green deployment

Wybierając tą strategię musimy zduplikować swoje zasoby tak by druga wersja aplikacji mogła w jednej chwili przejąć cały ruch. Proces jest następujący: mamy np. dziesięć instancji aplikacji w wersji pierwszej, następnie stawiamy kolejne dziesięć instancji w wersji drugiej. W momencie gdy instancje w wersji drugiej są gotowe do przyjęcia ruchu cały ruch kierowany jest tylko do nich. Po deploymencie, klaster z nodami w wersji pierwszej czeka w pogotowiu gdyby coś poszło nie tak w drugiej wersji by w każdej chwili móc wykonać rollback i przyjąć ruch z powrotem.

Z powodu podwójnej infrastruktury jest to kosztowy deployment, ale dzięki temu daje też duże możliwości. Szybko się go przeprowadza, a w razie problemów sprawnie możemy się z niego wycofać. Wadą jest konieczność przeprowadzenia dobrych testów, bo w jednej chwili cały ruch wchodzi do nowej wersji więc ewentualne błędy będą miały wysoki user impact. Przy okazji warto wspomnieć, że tzw. blue to wersja zastępowana aplikacji, a green wersja zastępująca.

Zalety:

  • Natychmiastowy rollout i rollback
  • Jedna wersja aplikacji serwowana użytkownikowi

Wady:

  • Kosztowana z powodu podwojenia infrastruktury
  • Konieczność wykonania dobrych testów

A/B testing deployment ?

Moim zdaniem jest to najbardziej kontrowersyjny rodzaj deploymentu. Tak naprawdę nie uważam go za rodzaj deploymentu, a raczej za sposób testowania aplikacji. Dzięki niemu biznes dostaje informację czy wersja aplikacji, którą sprawdzamy spełnia obrane założenia. Niemniej postanowiłem go dodać do tej listy ponieważ w wielu źródłach jest wymieniana jako jedna ze strategii. Nie różniłby się on bardzo od canary release gdyby nie fakt, że jesteśmy w stanie precyzyjnie sterować ruchem. Możemy ustawić jaką wersję zaserwujemy użytkownikowi: np. użytkownik z Kanady otrzyma wersję pierwszą, a użytkownik mobilny dostanie wersję drugą.

Uzasadniając dlaczego nie traktuję A/B testów jako metody deploymentu. Po uzyskaniu wyników testów musi nastąpić decyzja czy dana wersja będzie implementowana na cały ruch. Jeśli decyzja jest pozytywna to i tak deployment używa mechanizmów takich samych jak przy canary relase, blue-green lub innych.

Więcej na temat A/B testing pisałem w moim poprzednim wpisie TESTY A/B Z CLOUDWATCH EVIDENTLY.

Zalety:

  • Pełna kontrola nad ruchem

Wady:

  • Skomplikowana implementacja
  • Czasochłonna

Shadow deployment

Najłatwiej będzie scharakteryzować shadow deployment za pomocą przykładu. W autonomicznych samochodach używa się tego typu deploymentu w celu sprawdzenia czy nowa wersja działa prawidłowo. W warunkach laboratoryjnych trudno jest przewidzieć wszelkie możliwe okoliczności jakie mogą wystąpić na drodze.

Pokrycie testami w takich sztucznych warunkach byłoby niewystarczające, a konsekwencje wadliwego oprogramowania katastrofalne. Dlatego nową wersję aplikacji wysyła się do autonomicznych samochodów i pracuje ona w tle. Odbiera wszystkie dane tak samo jak wersja główna, pracuje na tych samych produkcyjnych danych i podejmuje decyzje na ich podstawie, ale nie egzekwuje ich. Wersja druga dostarcza informacji, które sprawdzane są pod kątem poprawności. Jeśli kryteria są spełnione sprawdzana wersja może zastąpić wersję pierwotną.

Jest to jeden z najbardziej wymagających implementacyjnie dyplomantów ponieważ wymaga podwojenia infrastruktury by dwie wersje mogły działać równolegle. Jej niezaprzeczalną zaletą jest sprawdzenie nowej wersji w warunkach produkcyjnych i wdrożenie następuje tylko wtedy, gdy spełnione są kryteria. Użytkownik nie ma pojęcia o drugiej wersji oprogramowania. Jednak mimo, że w pewnej części sprawdzona jest funkcjonalność nowej wersji nie jest to kompletny test. W powyższym przykładzie wersja shadow nie może działać bezpośrednio z użytkownikiem z oczywistych względów więc test ten jest niepełny.

Zalety:

  • Rollout tylko w momencie gdy wersja jest sprawdzona
  • Brak user impact
  • Test na danych produkcyjnych

Wady:

  • Kosztowana z powodu podwójnej infrastruktury
  • Skomplikowana implementacja
  • Niepełny test

Przykłady w AWS

Do zademonstrowania działania opisanych strategii użyję następujących serwisów AWS. W przypadku recreate będzie to AWS Elastic Beanstalk. Dla rolling-update użyję odpowiedniej UpdatePolicy z AWS CloudFormation. Następnie canary release zademonstruję używając dwóch serwisów: Amazon API Gateway i AWS Lambda. Blue-green deployment przygotuję w Amazon ECS i wdrożę nową wersję za pomocą AWS CodeDeploy. W przypadku A/B testing jeszcze raz odsyłam do wpisu TESTY A/B Z CLOUDWATCH EVIDENTLY. Shadow deployment niestety nie zobaczycie w tym wpisie, ponieważ jest to na tyle skomplikowany strategia, że można by na ten temat przygotować osobną publikację.

Recreate w AWS Elastic Beanstalk

Kod pobrałem z strony AWS Getting started with Node.js on Elastic Beanstalk i delikatnie przerobiłem tak by otrzymać dwa pliki zip z spakowanymi aplikacjami. Są to proste statyczne strony internetowe. Zaczynamy tworzenie nowej aplikacji w Elastick Beanstalk, dodajemy nową nazwę środowiska, wybieramy platformę i źródło kodu. Wrzucamy pierwszą wersję aplikacji z lokalnej maszyny.

Następnie musimy chwilę poczekać gdyż serwis tworzy za nas sporo komponentów m.in. instancje, load balancery, seciurity grups, auto scaling group itd. Po kilku chwilach klikając w DNS ELB powinniśmy zobaczyć naszą stronę internetową w wersji pierwszej.

Mamy zatem pierwszą wersję działającą, następnie używając strategii recreate podmienimy naszą aplikację na wersję drugą. Wchodzimy do zakładki Elastic Beanstalk > Environments > Recreate-env i klikamy „Upload and Deploy”

Teraz wybieramy z lokalnej maszyny nową wersję aplikacji. W celu odwzorowania działania metody recreate wybieramy Deployment policy „All at once”. Oznacza to, że wszystkie instancję zostaną zatrzymane, a w ich miejsce zostaną postawione nowe instancje, z wersja którą wybierzemy. W naszym wypadku jest to tylko jedna instancja.

Tym razem jeśli chcemy zobaczyć co się stanie gdy odświeżymy stronę z aplikacją musimy się pośpieszyć. DNS od ELB powinien zwrócić na kilka chwil kod 502.

Jest to spowodowane tym, że zatrzymane zostały instancje wcześniejsze, a ALB nie kieruje jeszcze ruchu do wersji drugiej. Jest to moment, w którym serwis całkowicie nie obsługuje naszego ruchu. W tym wypadku brak obsługi trwał tylko kilka sekund, ale w normalnych warunkach aplikacje są dużo bardziej skomplikowane i ich czas rozruchu może być znacząco dłuższy.

Po chwili oczekiwania powinniśmy zobaczyć działającą drugą wersję aplikacji.

Rolling-update za pomocą AWS CloudFormation

Kolejną strategię przedstawię za pomocą CloudFormation. Przechodzimy więc do serwisu i klikamy „Create stack” w sekcji Prepare template. Wybieramy „Template is ready” ponieważ mamy już przygotowany template, który znalazłem na tej stronie. Dajemy next, wybieramy VPC i subnets, do której chcemy dodać nasze zasoby. Następnie mamy input o nazwie VersionParameter. Jest to wartość, która będzie się wyświetlała po przejściu do strony aplikacji. Ustawiamy ją na 1.

Cały stack możecie znaleźć we wcześniejszym linku. Poniżej wskażę kilka najważniejszych fragmentów kodu. Stack tak naprawdę wykonuje bardzo podobne działania co w przykładzie z ElastikBeanstalk. Cloud Formation tworzy Autoscalig Group, kilka Seciurity groups, Load balancer, LaunchConfiguration itp. We fragmencie LaunchConfiguration umieszczonym poniżej widzimy, że w User Data instaluje na instancji httpd serwis. Do index.html wrzucamy nasz input VersionParameter. Następnie startujemy serwis httpd.

        "UserData": {"Fn::Base64": {"Fn::Join": ["", [
          "#!/bin/bash -ex", "\n",
          "yum -y install httpd", "\n",
          "chkconfig httpd on", "\n",
          "echo \"Version ", {"Ref": "VersionParameter"}, "\" >> /var/www/html/index.html", "\n",
          "service httpd start", "\n",
          "/opt/aws/bin/cfn-signal -e 0 --region ", {"Ref": "AWS::Region"}, " --stack ", {"Ref": "AWS::StackName"}, " --resource AutoScalingGroup", "\n"
        ]]}}

W kolejnym fragmencie możemy znaleźć UpdatePolicy ustawioną na AutoScalingRollingUpdate czyli dokładnie taką strategię jakiej potrzebujmy.

"UpdatePolicy": {
        "AutoScalingRollingUpdate": {
          "MaxBatchSize": "2",
          "MinInstancesInService": "1",
          "PauseTime": "PT10M",
          "SuspendProcesses": ["AlarmNotification"],
          "WaitOnResourceSignals": true
        }
      }

Następnie klikamy „next”, a pozostałe parametry zostawiamy domyślne. Czekamy chwilę aż wszystkie komponenty się stworzą. W miedzy czasie możemy w eventach sprawdzić na jakim etapie jest nasz stack.

Po zakończeniu działania naszego stack-a w sekcji Outpusts dostaniemy adres URL naszego ELB. Wchodząc na niego powinniśmy zobaczyć wersję pierwszą aplikacji.

Świetnie, wszystko działa jak należy. Wracamy do naszego stacka i klikamy Update. Wybieramy „Use current templayt” i tym razem Versions Parameter ustawiamy na wartość 2. Pozostałe opcje zostawiamy domyślne.

CloudFormation wprowadzi zmiany do AutoScalingGroup oraz LunchConfiguration. Na czas updat-u „desired capasity instaces” zostanie zwiększone o jeden tak by odpalić nową instancję aplikacji z nową lunch configuration. Gdy nowa instancja wstanie i zarejestruje się w ELB pierwsza instancja z wersją pierwszą aplikacji zostanie zamknięta. W naszym przykładzie okno wynosi jeden dlatego wstanie tylko jedna nowa instancja.

Warto zwrócić uwagę, że gdybyśmy mieli dwie działające instancje w wersji pierwszej, cloud formation zamknąłby jedną z nich i w jej miejsce uruchomił nowa wersję. Ze względu na to, że musi zapewnić ciągłość serwisu nie może zatrzymać jedynej działającej instancji, więc najpierw musi zarejestrować nową instancję by ściągnąć starą.

W opisywanym przykładzie serwis będzie cały czas dostępny, a użytkownicy przez moment będą mogli trafić do instancji zarówno z wersją pierwszą jak i drugą. Po odświeżeniu kilka razy przeglądarki powinniśmy zauważyć, że tak się dzieje. Na koniec zostanie tylko aplikacja z nową wersją.

Canary release z użyciem Amazon API Gateway i AWS Lambda

Kanarkowy release zaczniemy od stworzenia funkcji lambda, która będzie zwracać prostą widomość. Zaczniemy od stworzenia funkcji. W zawansowanych ustawieniach wybieramy „Enable function URL” by funkcja była dostępna przez adres ULR. „Auth Type” dajemy NONE aby nie komplikować przykładu.

Kod funkcji w wersji pierwszej będzie zwracać prosty tekst „Hello from Version1”.

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Version 1'),
    };
    return response;
};

Dla wersji drugiej zmienimy tylko wysyłaną wiadomość na „Hello from Version 2”. Publikujemy obie wersje.

Przechodzimy do API Gateway. Wybieramy REST API i klikamy Build. Dla „Create new API” wybieramy New API, a nasze API nazywamy „Canary”. Następnie dodajemy nową metodę GET i uzupełniamy pola jak na zdjęciu niżej. Pole Lambda function wskazuje na naszą funkcję Canary w wersji pierwszej.

W kolejnym kroku z poziomu zasobów wykonujemy deploy naszego API. Stage nazywamy „prod”. Po chwili powinniśmy otrzymać działający URL zwracający „Hello from Version 1”.

By wykonać Canary deployment wracamy do widoku Stages naszego API i klikamy zakładkę „Canary”, po czym Create Canary. Powinniśmy zobaczyć opcję rozkładu ruchu między nasze wersje. Ustawiamy ruch 50% dla wersji pierwszej i 50% dla wersji drugiej by zaobserwować jak wersje zmieniają się między sobą. Na środowisku produkcyjnym do wersji testowej wysyłalibyśmy tylko drobny ułamek całego ruchu.

Zatwierdzamy rozkład ruchu i przechodzimy do zasobów. Dla naszej metody GET musimy zmienić Integration Request tak by wskazywała na nową wersję funkcji lambda – wersję drugą.

Jeszcze raz wdrażamy nasz zasób. Tym razem powinniśmy zauważyć, że przy naszym stage pojawił się opis Canary Enabled.

Po tym zabiegu gdy będziemy odświeżać nasz adres prowadzący do funkcji możemy zobaczyć, że losowo zwracane jest „Hello from Version 1” lub 2. Jeśli jesteśmy pewni, że aplikacja z nową wersją działa prawidłowo możemy ją wypromować i wtedy cały ruch będzie przekazywany do nowej wersji lub skasować Canary co spowoduje powrót do wersji pierwszej. W przypadku tego deploymentu nie mamy okresu niedostarczania serwisu. Musimy jednak mieć na uwadze, że dwie wersje aplikacji są utrzymywane.

Promujemy wersję canary. Po walidacji naszego wyboru przez AWS po kilku sekundach widzimy, że otrzymujemy kod tylko z drugiej wersji aplikacji.

Blue-Green deployment w Amazon ECS i AWS CodeDeploy

Ze względu na ilość komponentów, które trzeba przygotować wcześniej pominę ich konfigurację i pokażę sam proces update aplikacji. Wspomnę tylko, że stworzyłem już klaster o nazwę Blue-Green, na którym będą pracowały nasze kontenery. Przygotowałem też dwa obrazy dockerowych kontenerów, które będą na porcie 80 zwracały stronę z treścią „Version 1 (lub 2) is working OK”. Obrazy wrzuciłem na dockerhub pod adresem jaroslawczerwinski/my-apache2. Na postawie tych obrazów stworzyłem dwie rewizje Task Definition o nazwie httpd-service.

Poniżej umieściłem kontener użyty w httpd-service:1. Dla httpd-service:2 wykorzystałam obraz my-apache2:version2.

Obecnie serwis, w którym pracuje nasz kontener ma użytą rewizję pierwszą z task definition. Przed uruchomieniem serwisu trzeba jeszcze stworzyć load balancer, target group oraz seciurity group, jak również inne komponenty, które są wykorzystywane w trakcie działania serwisu. Po wejściu na adres DNS naszego ALB otrzymujemy taką informację jak poniżej.

Pora wdrożyć nową wersję aplikacji z użyciem CodeDeploy. Wchodzimy do CodeDeploy po czym wyszukujemy aplikację. Jest to APPECS-Blue-Green-httpd. Wybieramy deployment group i na koniec Create deployment.

Do wyboru mamy kilka opcji. Ja skorzystam z AppSpec editior i przygotowanego wcześniej yaml-a, który będzie zawierał instrukcje jak CodeDeploy ma zastąpić task defitionion nowszą wersją. Poniższy obraz przedstawia wspomnianego yaml-a.

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:eu-central-1:177460403479:task-definition/httpd-service:2"
        LoadBalancerInfo:
          ContainerName: "httpd-v2"
          ContainerPort: 80

Nie ma w nim większych fajerwerków. Yaml wskazuje na ARN do nowego Task Definition i podaje informację dla load balancera. Pozostałe ustawienia zostawiamy domyślne i klikamy „Create deployment”. Zostaniemy przeniesieni do dashbordu, na którym będziemy widzieć kroki naszego wdrożenia oraz rozkład ruchu. Na początek cały ruch będzie skierowany do oryginalnego zadania czyli naszego pierwszego kontenera.

W międzyczasie startuje drugi kontener stawiany z obrazu, który zdefiniowaliśmy dla drugiej rewizji. Gdy drugi kontener poprawie zarejestruje się w naszym ALB cały ruch zostanie przeniesiony do niego. Poniżej możemy zobaczyć, na jakim etapie jest proces stawiania nowego kontenera. Gdy lifecycle events dojdzie do AllowTraffic powinniśmy otrzymywać już inną wiadomość z ALB.

W AppSpec możemy ustawić dodatkowe zadania, które mają się wykonywać w widocznych powyżej momentach cyklu pracy deploymentu. My nic takiego nie definiowaliśmy dlatego po Install pozostałe etapy powinny szybko się zakończyć. Po kilku chwilach load balancer zwróci poniższą wiadomość.

Obecny rozkład ruch widzimy poniżej.

Warto wrócić do panelu wdrożenia i sprawdzić, na którym kroku jesteśmy. Jest to Step 3. Zastosowaliśmy większość ustawień domyślnych. Z tego powodu przez jedną godzinę nasz pierwszy kontener cały czas będzie w gotowości by w razie problemów z drugą wersją aplikacji móc przyjąć ruch z powrotem.

Jeśli chcemy porzucić wdrożenie i wrócić do poprzedniej wersji możemy kliknąć „Stop and roll back deployment” lub jeśli nie chcemy czekać godziny w stand-by klikamy „Terminate orginal task set”.

Inne strategie deploymentu

Podczas pracy z AWS Elastic Beanstalk możemy zauważyć, że do wyboru mamy kilka odmian strategii, o których nie mówiłem. Są to „Traffic splitting” oraz „Immutable”.

Traffic splitting działa dokładnie jak canary realease. Określamy rozkład ruchu dla nowej wersji i czas, po którym pozostała część ruchu zostanie skierowana do nowej wersji.

Strategia Rolling została omówiona w części dotyczącej CloudFormation, ale chcę zwrócić uwagę na różnice między nią, a Rolling with additional batch. Additional batch oznacza, że odwracamy kolejność stawiania instancji. Zanim ściągniemy aplikację w wersji pierwszej najpierw wdrażamy tę w wersji drugiej o ilość zdefiniowaną w oknie. Następnie zatrzymujemy dokładnie tyle samo node-ów wersji pierwszej i tak postępujemy aż do momentu wymiany wszystkich instancji.

Immutable deployment może mylić się z blue-green. Polega ona na tym, że instancje z drugiej wersji aplikacji są rejestrowane do load balancera, który rozrzuca ruch na obie wersje. W momencie gdy ilość nowych instancji zrówna się z starymi, są one wyrejestrowywane i cały ruch trafia do nowszych węzłów.

Używając AWS CodeDeploy dla ECS mamy do wyboru kilka predefiniowanych strategii. ECSLinear10ProcentEvery5Minutes oznacza, że co 5 minut kolejne 10% ruchu będzie kierowane do drugiej wersji aplikacji albo ECSCanary10Precent15Minutes czyli 10% ruchu trafi do nowej wersji i po 15 minutach cała pozostała część ruchu zostanie tam skierowana.

Jesteśmy też w stanie stworzyć swoją własną konfigurację do wdrożenia klikając przycisk „Create deployment configuration”.

Podsumowanie strategii deploymentu

Informację znajdujące się we wpisie są wstępem do dostępnych metod wdrożeń aplikacji i nie wyczerpują tematu. Przy wyborze strategii deploymentu musimy wziąć pod uwagę szereg wytycznych by optymalnie dobrać metodę do naszych oczekiwań. Najlepszym sposobem na porównanie różnic wynikających z każdej opisanej przeze mnie strategii będzie umieszczenie ich charakterystycznych cech w tabeli.

Materiały dodatkowe

Comments are closed.