Dockerowe nowości — Offload, A2A, MCP i Compose z turbo 🐳🚀

Więc nie wyjdziemy sobie gdzieś indziej. No tak, tu przyznaję wada jednak, mimo wszystko. Aczkolwiek podejrzewam, że dużo więcej pracy i dużo więcej zachodu i dużo więcej kombinowania wymagałoby na przykład to, jakbyśmy sobie chcieli to zrobić ten offload, nie wiem, do GCP albo do jakiegokolwiek innego clouda, bo to jednak Docker w swoim tym Obrębie, może sobie to w jakiś tam sposób ładnie zrobić. Więc to jest jedna rzecz. To zaraz pokażemy, jak to działa. Albo, wiesz co, pokażmy od razu, bo tą drugą część to sobie będziemy musieli pokazać troszeczkę inaczej. Jak widzicie, tutaj mój ekran jest już widoczny, prawdopodobnie.

No i teraz też się zmienił ten kolor tutaj na niebieski i ten przełącznik tutaj, tym system tutaj możemy sobie to przełączać. Więc tak, odpalmy to. A, zanim. Dobra, na razie to zabiję. W sensie Dwie kolejne rzeczy, które się pojawiły, to przede wszystkim pojawiło się coś takiego, co się nazywa MCP Gateway. I to jest ciekawe, ponieważ jeżeli mamy wiele agentów, z których chcemy korzystać, MCP Gateway pozwala nam je zamknąć za gatewayem, czyli za jednym takim powiedzmy proxy.

Wysyłać requesty do tych agentów poprzez to proxy. Oczywiście, jeżeli chodzi o architekturę, dodaje nam to kolejny komponent, ale z drugiej strony pozwala nam lepiej, moim zdaniem, lepiej zaplanować tą architekturę tych wszystkich rozwiązań, które tutaj mamy. Więc to jest takie dosyć ciekawe rozwiązanie. Ja jeszcze w to głębiej nie wchodziłem na ten moment, Odpaliłem sobie jednego takiego MCP Gateway, jak to wygląda. Działa to nawet. Tyle mogę powiedzieć na ten moment. Natomiast drugim elementem, który jest z tym związany, jest modyfikacja Composa.

Ponieważ w Compose dzisiaj możemy w bardzo ładny sposób na tym najwyższym poziomie tak naprawdę definiować właśnie agenty, definiować MCP Gateway itd. To już nie wchodzimy poniżej, tylko mamy ten poziom, ten tutaj jeden tak naprawdę poziom, tak jak Tak definiujemy sobie poszczególne kontenery de facto. A, jeszcze do offloadu. Wszystko, co jest związane z komendami dockerowymi, robimy w Cloudzie. Wszystko, co nie jest związane z komendami dockerowymi, np. właśnie Compose itd., edytowanie plików, robimy lokalnie.

Tego bodajże tak. Ta aplikacja działa w ten sposób. To jest piękny rysunek, gdzieś narysowany. Trochę niżej. Użytkownik zadaje pytanie. To idzie przez audytora, który odpytuje coś, co się nazywa Critic Agent, które używa MCP Gateway właśnie do połączenia z DuckDuckGo, wyszukania odpowiedzi na pytanie. Później, jak dostaje tą odpowiedź, przechodzi przez Revisera, Który używając Docker Model Runera jakby konkluduje tą odpowiedź i zwraca do pytającego.

Więc tak to wygląda tutaj. Więc te elementy tutaj mamy, tak naprawdę mamy taki kontener, mamy ten Auditor, mamy Critic, mamy Revizer. Więc wróćmy sobie do naszych tych, więc tak naprawdę mamy tutaj te kontenery. Mamy Auditor, Critic, Revizer, co jest nudna część akurat. Ale tak, mamy zdefiniowanego też MCP Gateway'a, w ten sposób. Czyli stosunkowo proste, bym powiedział. Nie ma nic jakiegoś nie wiadomo jak skomplikowanego. No i tak jak mówiłem, na najwyższym poziomie deklarujemy też modele. To jest zmiana, która się pojawiła w Compose właśnie teraz.

Można było definiować te modele na poziomie tak, jak mieliśmy zdefiniowane MCP Gateway, ale to też od jakiegoś czasu, to nie od dłuższego czasu, od jakiegoś miesiąca, dwóch może, coś tego typu. No dobra, mamy mamy tego I teraz tak, ten Compose on się odpali na moim PC, ale nie przejdzie. Pomimo tego, że jest stosunkowo mały model. Natomiast my sobie tutaj odpalimy coś większego. Tutaj gdzieś powinno być. Tak, odpalimy sobie to. Czyli odpalam Compose'a z tym DMR-em, którego Wam pokazałem i Compose'em Offload.

Mamy MCP Catalog, tego modula runnera. Ciekaw jestem, jak to rozwijało, bo już o tym rozmawialiśmy. Więc to jest fajne. Tam są opcje przerzucenia całego ekosystemu Dockera w coś większego. I widać, że to się rozwija. Tylko brakuje mi takich opcji, które są super, hyper, enterprise, trendy. Gdzieś właśnie czegoś takiego, o czym rozmawialiśmy w jednym z pierwszych naszych odcinków, że brakuje tego kolejnego kroku wyżej, takiego production ready, nazwijmy to, takiego właśnie enterprise'owego. Pomimo tego, że to jest niejako celowane w enterprise, no bo to inaczej.

Critic się go odpytał poprzez tooling MCP. To widzimy właśnie tutaj. Mamy ten taki... Z tej linii można się tego mniej więcej dowiedzieć. Po czym mamy Auditor, który zaczął kombinować, jak odpowiedzieć, budować tą odpowiedź, taką przedefiniowaną. I teraz mamy tak, tu mamy odpowiedź z Kritika, a tu mamy odpowiedź z Auditora. Jest troszeczkę przebudowana. Tutaj widać, że to jest ewidentnie Wikipedia, gdzie są odnośniki.

Wiadomo. To dopiero co powstało. Myśmy to testowali jako kapitanowie 2-3 dni przed oficjalnym release'em. Więc tak naprawdę to jest, można powiedzieć, świeżynka. Ale teraz jak wezmiemy sobie, zrobimy tak, muszę zatrzymać, więc zatrzymam sobie te kontenery. Tutaj je będę miał. Fajnie widać, że mamy jakiś agent, mamy MCP Gateway, gdzie to wszystko nam się gdzieś tutaj potworzyło. Jak zrobimy docker offload stop?

Jeżeli to będzie ładnie rozpracowane i nawet zostanie zrobione jakieś CSI, CNI itd. Na CNI być może też. CSI niekoniecznie, ale jakieś shim albo cokolwiek dockerowe, co by się spinało z tym całym containerd. Albo gdyby docker znowu do containerd i dorzucił te komendy, co nie sądzę, żeby CNCF to dopuścił, ale może. Może, zobaczymy. No to było super. Jeszcze jedną rzecz chcę Ci pokazać. W jednym z tych projektów tutaj dostępnych, to projekt się nazywa ADK, jest też Compose do uruchomienia w GCloudzie, GCP.

Tam też możesz sobie stworzyć właśnie MCP Gateway i wypuścić to na Natomiast inaczej tracisz. Nie zyskujesz tego całego dobra, które może dać Offload. To jest wtedy faktycznie uruchomione gdzieś. Tak, tak, tak. Pozbawiamy się wszystkiego tego. Maszynki przesiadkowe, komendy. Czyli tak naprawdę Od Tokera dostajemy cały wrapper z nowym ekosystemem, który traktuje tylko offloady i to chmurę jako trzydatkowego i ładnie to opakowuje. OK, fajne to.