Jak działa współbieżność gitlab runner?

Question

Jak działa współbieżność gitlab runner?

Q1: Jaka jest różnica między

concurrent = 3

[[runners]]
  ..
  executor = "shell"

I

concurrent = 3

[[runners]]
  ...
  executor = "shell"

[[runners]]
  ...
  executor = "shell"

[[runners]]
  ...
  executor = "shell"

Q2: czy to ma sens, do...

Mieć 3 executory (workers) tego samego typu na jednym runerze z globalnym concurrent = 3? Czy pojedynczy executor z globalnym concurrent = 3 może bezpiecznie wykonywać wiele zadań równolegle?

P3: jak są ze sobą spokrewnieni...

runners.limit z runners.request_concurrency i concurrent

Thanks

21

gitlab gitlab-ci gitlab-ci-runner

Author: Community, 2019-02-05

Source

1 answers

score 28 · Accepted Answer

Dokumentacja Gitlab na temat biegaczy opisuje je jako:

(...) izolowane (wirtualne) maszyny, które odbierają zadania za pośrednictwem coordinator API GitLab ci

Dlatego każdy runner jest odosobnionym procesem odpowiedzialnym za odbieranie żądań wykonania zadań i radzenie sobie z nimi zgodnie z wstępnie zdefiniowanymi konfiguracjami. Jako odizolowany proces, każdy biegacz ma możliwość tworzenia "pod-procesów" (zwanych również maszynami) w celu uruchomienia miejsc pracy.

Gdy zdefiniujesz w swoim config.toml a [[runner]] Sekcja , konfigurujesz runner i ustawiasz, jak powinien radzić sobie z żądaniami wykonania zadania. W swoich pytaniach wymieniłeś dwa z tych ustawień" jak radzić sobie z żądaniem wykonania zadania":

limit: "Ogranicz liczbę zadań, które mogą być obsługiwane jednocześnie". Innymi słowy, ile "podprocesów" może być utworzonych przez runner w celu jednoczesnego wykonywania zadań; {]}
request_concurrency: "Limit number of równoczesne żądania nowych zadań z GitLab". Innymi słowy, ile żądań wykonania zadań może pobierać runner z kolejki zadań GitLab CI jednocześnie.

Istnieją również pewne ustawienia , które odnoszą się do maszyny globalnie. W swoim pytaniu wspomniałeś o jednym z nich:

concurrent: "Ogranicz liczbę zadań na świecie, które mogą być uruchamiane jednocześnie. Jest to najbardziej górna granica liczby zadań przy użyciu wszystkich zdefiniowanych biegaczy". Innymi słowy, ogranicza maksymalną ilość "podprocesy", które mogą jednocześnie uruchamiać zadania.

Tak więc, mając na uwadze różnicę między runner jego pod-procesy, a także różnicę między konkretnymi ustawieniami runner a globalnymi ustawieniami maszyny:

Q1:

Różnica polega na tym, że w twoim pierwszym przykładzie masz jednego biegacza, a w twoim drugimprzykładzie masz trzech biegaczy. Warto wspomnieć, że w obu przykładach twoja maszyna pozwoliłaby tylko na uruchomienie 3 zadania jednocześnie.

Q2:

Nie tylko pojedynczy biegacz może bezpiecznie uruchamiać wiele zadań jednocześnie, ale także może kontrolować liczbę zadań, które ma obsłużyć (używając wyżej wymienionego ustawienia limit).

Nie ma również problemu, aby podobne biegacze biegali w tej samej maszynie. To, jak zdefiniujesz konfiguracje biegacza, zależy od Ciebie i Twoich możliwości infrastruktury.

Zwróć również uwagę, że an executor tylko / align = "left" / Nie jest to jedyna rzecz, która definiuje biegacza i nie jest synonimem słowa "pracownik". Te, które działają, to twoi biegacze i ich podprocesy.

Q3:

Podsumowując: można zdefiniować jednego lub wielu pracowników na tej samej maszynie. Każdy z nich jest odosobnionym procesem. Runner ' s limit to liczba podprocesów procesu runner, które można utworzyć w celu jednoczesnego uruchamiania zadań. Runner ' s request_concurrency to ile żądań może obsłużyć runner z kolejki zadań Gitlab ci. Na koniec, ustawienie wartości na concurrent ograniczy liczbę zadań, które mogą być wykonywane na maszynie w tym samym czasie w jednym lub kilku biegaczach uruchomionych na maszynie.

Referencje

Dla lepszego zrozumienia, naprawdę polecam przeczytać o algorytmie Autoscalingu i parametrach.

Wreszcie, myślę, że to pytanie, jak uruchomić runnery równolegle na tym samym serwerze może okazać się przydatne.