Gitlab i uruchamianie skryptów

Pytanie z ciekawości o ogólne zasady, nie o szczegóły.
Jak wygląda przygotowanie środowiska przez devopsa do uruchamiania skryptów?

Wgrywam na Gitlaba skrypt, np. JS-owy, uruchamiany pod Node.js., do tego yml.
W pipeline ustawiam, że ma być uruchamiany cyklicznie.Wiem już, że jest uruchamiany pod Dockerem i że Gilab ma gotowe obrazy różnych kontenerów.

Czy devops instaluje kontener pod mój projekt, konfiguruje tam to co jest potrzebne, czy może są konfigurowane automatycznie, czy np. firma wykupiła jakąś pulę dockerów i moje zadanie korzysta z jednego z nich?
Co się dzieje z Dockerem po zakończeniu działania skryptu?
Jeśli mój skrypt sięga do zasobów (bazy/storage) na zewnętrznym serwerze lub w chmurze to devops musi to wiedzieć i zrobić wyjątek na firewallu?

Jeśli chodzi o agenty / runner'y na których wykonywany jest konkretny job z pipeline'a, to sprawa wygląda tak:

• Agent może być zarządzany przez GitLab'a lub może być to Twój własny serwer, na którym zarejestrowałeś gitlab-runner'a
• Na agencie job może być wykonany bezpośrednio na nim (wtedy musisz zadbać o to, żeby znalazły się tam wymagane zależności, zainstalować je - wyjątkiem tu są agenty zarządzane przez GitLab'a, z tego co pamiętam są to tymczasowe VM, tworzone i usuwane adhoc na czas wykonania job'a) lub jako kontener (wtedy wystarczy, że na agencie masz Docker'a, reszta zależności będzie się znajdowała wewnątrz obrazu, który wyspecyfikowałeś)
• Dla każdego uruchomienia job'a przygotowywane jest środowisko (environment) i czyszczone po jego zakończeniu. Jeśli chcesz, żeby wynik uruchomienia job'a przetrwał, to w większości przypadków korzysta się z artefaktów, które są opublikowane pod koniec lub własnoręcznie możesz zadbać o upload artefaktów do jakiegoś miejsca
• Jeśli potrzebujesz bezpośredniego połączenia z agenta do prywatnej usługi to jest kilka sposobów, żeby to zrealizować - ja najczęściej robię to w taki sposób, że agent, z którego korzystam znajduje się w tej samej sieci co ta usługa i ma do niego bezpośredni dostęp (tu nie trzeba wystawiać agent'a do świata zewnętrznego - agent odpytuje serwer GitLab'a, czy są dla niego joby do uruchomienia a nie że serwer mu zleca uruchomienie job'a - serwer nie musi mieć bezpośredniego dostępu do agenta. Wszystko jest prywatne). Innym sposobem by było zrobienie jakiegoś peering'u pomiędzy agent'ami w sieci a usługą. Edit: jeśli chodzi o sam sposób łączenia się z agent'a do konkretnego serwera, aby wrzucić tam jakiś plik / uruchomić komendę, to wystarczy, że wygenerujesz parę kluczy ssh, dodasz publiczny jako autoryzowany po stronie serwera i agent będzie korzystał z prywatnego, żeby tam się połączyć.

Dzięki za obszerne objaśnienia.

Gdyby ktoś potrzebował więcej to fajny opis jest na stronie:
https://docs.gitlab.com/runner/
Tam są jeszcze odsyłacze do executora no i dalej, docker, VM...

Intryguje mnie tylko info o VM, bo w pierwszym zdaniu mam: ....which is cloned and used to run your build.
A 3 zdania niżej: GitLab Runner connects to the (brak cloned) virtual machine and runs the build on it
Gdybym miał ją on infrastructure that you own or manage - to moja VM tez będzie klonowana za każdym razem?
Domyślam się, że, jak pisze kolega wyżej, dotyczy to VM uruchamianych bezpośrednio na GitLab-ie.

Rozpisuję się, bo GitLab kojarzył mi się tylko z repozytorium kodu.