[GCP] Cloud Run – uruchomienie usługi w wielu regionach

W zeszłym tygodniu GCP wprowadziło funkcję umożliwiającą uruchamianie Cloud Run w wielu regionach za pomocą jednego polecenia.

Krótko mówiąc, obsługa usługi w wielu regionach oznacza, że mamy np. regiony w Seulu, Londynie i Las Vegas.

Wcześniej, aby wdrożyć usługę w wielu regionach, należało użyć skryptu do wdrożenia w każdym regionie osobno. Nowa funkcja pozwala na wdrożenie w wielu regionach za pomocą jednego skryptu.

W rzeczywistości, czytając dokumentację przed premierą usługi, bardzo jej się spodziewałem, ale w pewnym sensie się zawiodłem.

Wdrożenie za pomocą skryptu, nawet jeśli pozwala na jednoczesne wdrożenie w wielu regionach, i tak działa równolegle, więc nie spodziewałem się znaczącej różnicy w czasie. Jednakże, głównym problemem jest to, że nie można ustawić różnych zmiennych środowiskowych dla poszczególnych regionów.

Dlatego często korzystałem z funkcji pozwalającej poszczególnym instancjom Cloud Run w różnych regionach korzystać z różnych wartości do łączenia się z różnymi bazami danych lub GCS. Niestety, ta funkcja przestała działać poprawnie.

Drugim problemem jest to, że podczas wielokrotnego wdrażania, czasami chcemy usunąć poprzednie wersje, ale nie można tego zrobić indywidualnie. Starsze wersje są blokowane w trybie tylko do odczytu, uniemożliwiając ich usunięcie.

Mimo wielu wad, zaletą jest możliwość "złożenia" wielu instancji Cloud Run w jedną.

W naszej usłudze, korzystamy z wielu instancji Cloud Run i wielu regionów. Obecnie mamy około 50 instancji, a po zakończeniu bieżących prac liczba ta wzrośnie do około 100. Korzystanie z usługi wieloregionowej pozwoli nam zredukować tę liczbę do 10-20. (Po prostu ukrywa je.)

Skrypt wygląda następująco:

Po uruchomieniu powyższego skryptu, wdrożenie wygląda następująco:

Cloud Run o tej samej nazwie jest wdrażany w każdym regionie, a na najwyższym poziomie tworzony jest folder (?) o tej samej nazwie.

Złożony widok wygląda następująco:

W przypadku małej liczby regionów, korzyści są niewielkie. Jednakże, jeśli założymy wdrożenie w 40 regionach, korzyści są ogromne. (Chociaż niekoniecznie aż tak wiele...)

W większości przypadków, próba modyfikacji czegokolwiek kończy się komunikatem o trybie tylko do odczytu. Dokumentacja wspomina o dostępności funkcji, ale wydaje się, że API ma problemy i nie działa poprawnie.

Odnośnik do dokumentacji:

Dokumentacja gcloud znajduje się tutaj. Obecnie obsługiwane są tylko wersje alfa/beta, a wersja stabilna nie jest jeszcze obsługiwana. Co więcej, opcja --regions, wspomniana powyżej, nie jest nawet opisana w dokumentacji. (Prawdopodobnie wkrótce zostanie zaktualizowana.)

Chciałbym, aby PORT był domyślnie dostępny jako zmienna środowiskowa, tak jak teraz. Wiem, że metadane serwera dostarczają różnych informacji, ale pobieranie ich za pomocą Fetch jest niewygodne. (Dodatkowo, to też zużywa zasoby...)

To wciąż wersja zapoznawcza, więc mam nadzieję, że ulegnie poprawie. (Narzekanie zaraz po premierze to trochę przesada...)