Kiedy zrzucam runtime, a kiedy zostaję przy daemonie
Jest 15 lipca. Od kwietnia 2021 mam lokalne Testcontainers i od listopada 2021 Dockera na agencie Azure. W 2023 Cloud był świadomie poza blogiem: publiczna beta AtomicJar poszła 25 stycznia, a ja nie miałem jeszcze powodu pisać o usłudze, której nie płaciłem jako procesu. 11 grudnia 2023 Docker kupił AtomicJar. Dziś, półtora roku po becie i pół roku po przejęciu, pytam o jedną rzecz: kiedy zrzucam runtime kontenerów do chmury, a kiedy zostaję przy daemonie na laptopie i na hostowanym agencie.
Moja teza na lipiec 2024 jest wąska. Testcontainers Cloud jest na tyle dojrzały jako usługa Dockera, że mogę zrzucić runtime z laptopa i z agenta CI bez przepisywania testów ContainerBuilder. To nie zastępuje lekcji z 2021. Lokalny daemon i socket na Azure nadal są kanonem. Cloud jest opcją, gdy CPU, RAM albo Docker-in-Docker na runnerze boli.
Nie znam osobnego ogłoszenia GA sprzed 15 lipca i nie wymyślam daty. Nie opisuję cennika unified plans, który Docker zapowie na jesieni. Płacę za produkt, który jest, nie za plan z grudnia.
Stan warsztatu. NuGet Testcontainers to 3.9.0 z 17 czerwca. Aplikacja jest na .NET 8. Playwright w tle to 1.45.1 z 2 lipca; 1.45.2 jest jutro i nie pinuję go. GPT-4o mini nie istnieje jeszcze jako pin tego wpisu.
Co to jest, a czego nie
Te same testy OSS. Java, .NET Testcontainers 3.9, Node. Cloud to worker w chmurze plus Testcontainers Desktop na laptopie albo agent w CI z tokenem service account. To nie jest nowy framework i nie jest “Testcontainers 4.x”. Biblioteki zostają darmowe. Płacę za runtime.
Nie przepisuję intro MSSQL z 2021. Nie uczę YAML-a socketu od zera z listopada 2021. Sierpień 2022 zostaje tym samym pomysłem pipeline’u: kod testów ten sam, inny runtime.
Desktop vs CI
Na laptopie Desktop zdejmuje lokalny daemon z CPU i RAM, kiedy suite stawia Postgres, kolejkę i fake SMTP naraz. Na CI agent nie musi być privileged i nie muszę montować /var/run/docker.sock tak, jak w 2021. Token service account idzie do sekretu, nie do repozytorium.
Kontrast jest runtime’em, nie API. new ContainerBuilder().WithImage("postgres:16") zostaje. Zmienia się to, gdzie proces Dockera stoi.
Kiedy nie włączam
Mała suite, jeden Postgres, hosted ubuntu z Dockerem wystarcza. Cloud płaci minutami. Nie wrzucam go na każdy PR, bo strategia CI nadal dzieli bramkę, main i nightly. Izolacja z października 2021 nie znika, bo kontener wstał w chmurze. Nadal nie dzielę bazy między workerami.
Pułapki lipca
Sieć do workera jest dodatkową falą flaków, której lokalny daemon nie ma. Pull obrazu w chmurze nie korzysta z cache warstw na agencie, który znam z Azure. DNS potrafi się rozjechać między laptopa a workera. Sekret service account wycieka tymi samymi drogami co każdy inny token w Actions.
Demo: syntetyczny test .NET 8, Testcontainers 3.9.0, Postgres. Raz DOCKER_HOST wskazuje lokalny daemon. Raz Desktop albo agent Cloud. Asercja SELECT 1 jest ta sama. Nie wklejam tokena. Nie nazywam orga.
Model LLM nie jest tematem lipca. GPT-4o istnieje od maja. Nie mieszam go z runtime kontenerów.
Podsumowanie
Cloud jest narzędziem na ciężkie zależności i ciasny runner. Kanon bloga zostaje: kod definiuje kontener, izolacja najpierw, trigger potem.
Trzy zdania na rok. Testy 3.9.0 nie zmieniają się, kiedy runtime idzie do Cloud po przejęciu AtomicJar. Nie mam daty GA do wpisania i nie mam grudniowego cennika w lipcu. Socket na Azure i lokalny daemon zostają, gdy suite jest mała.
Czego z tego nie wynika. Nie wynika, że kasuję Docker na agencie. Nie wynika, że Compose z lutego 2021 jest zbędny. Nie wynika, że bez Dockera na CI “nie potrzebuję izolacji”.
Warunek: dwa przebiegi, lokalny i Cloud, na tym samym ContainerBuilder dają ten sam SELECT 1 bez ręcznego mapowania portu. Do tego czasu Cloud włączam tam, gdzie runner nie ciągnie obrazów, i zostawiam kanon 2021 tam, gdzie ciągnie.