musisz znać się bardzo dobrze na Linuksie, jak działa komputer, vmki, sieci - to jest baza. Potem dochodzi cała wiedza specyficzna dla devopsa - sposoby deploymentu, monitoring troubleshooting i tak dalej. Powiedziałbym, że to chyba jedna z pozycji, na którą trzeba najwiecej wiedzy z IT. Imho ciężko bez dobrych studiów pojąć to wszystko

@@losiu998 jestem po studiach, kilka lat w it jednak to wlasnie sieci, administracja, infrastruktura it to jest co mnie zawsze jaralo.

Pozwól że rozwinę ten kilkuwyrazowy fragment o vmkach ("teraz w ogóle jeszcze vmki będziemy mieli w k8s"). Kubevirt potrzebował ponad 5 lat żeby wyjść z wersją 1.0 w 2023. Wersja ta oficjalnie jest production ready co otwiera jej drzwi dla dużo większej ilości użytkowników (poza grupą firm które już wcześniej się na to zdecydowały). To prawdopodobnie spowoduje znaczną popularyzację tego rozwiązania wśród mniejszych graczy.

@@mariuszdalewski5287 racja, ale jednak to zastosowania dosyć specyficzne, i akurat rozumiem firmy takie jak orange czy nvidia, a nawet jakiś współdzielony desktop. Ale znaczna popularyzacja? Zobaczymy co świat pokaże. Pewnie ktoś namówi jakies korpo, żeby sie do chmury prznosili w stylu shift and lift. P.S. kilka lat udzielałem się w projekcie kubevirt. Fajna zabawa. Ale wg. mnie całe to kubernetes to aktualnie strasznie skomplikowana maszyna. I jeszcze ta sieć. Niech zaczną pakiety ginąć. To się człowiek zastanawia czy to pod calico/istio padł, czy to się limity w OS wyczerpały czy to.... i kilka poziomów abstrakcji do sprawdzenia.

@BartoszRybacki0 patrząc na ruchy rynku wirtualizacji (VMware) i bardzo mocny kierunek definiowania wszystkiego jako kod, to niestety może pojawić się na to moda. K8s też widzi w tym sens, bo jako jeden z powodów dodania wsparcia dla swap podaje Kubevirta. Zobaczymy.

@BartoszRybacki0 odnośnie szukania pakietów, dosłownie wczoraj ich szukałem i powodem moich problemów było to, że Flannel użył złego interfejsu jako podstawowego do zbudowania swojego bridge'a ;-( W efekcie wszystko działało, ale sieć mi się segmentowała, bo komunikacja pomiędzy nodami szła po sieci lokalnej zamiast po overlayu. No i to jest sroga zabawa z tcpdumpem, niestety ;-(

na tym polegają takie spotkania, by dzielic się swoimi doświadczeniami :) I tak też zrobił, i dobrze mu wyszło.

nie krytykuje twojej wypowiedzi, po prostu chcac byc uczciwym zapytam: z czym konkretnie sie nie zgadzasz i jakie sa twoje odpowiedzi. Bo "Niestety ilość rzeczy z którymi się w tej prezentacji nie zgadzam (...) jest przytłaczająca" jest zwyczajnie slabe. Tak mozna powiedziec o wszystkim

Heja. Też bym z chęcią dowiedział się z czym się nie zgadzasz. Będzie okazja, to w kolejnej prezentacji coś poprawię :)

Wynik uruchomienia Docker compose to trochę taka najmniejsza jednostka orkiestrowalna przez K8s, czyli Pod. Wiadomo Kubernetes (skrótowo K8s) odpowiedzialny jest za zarządzanie tysiącami takich Podów, w tym pośrednio konfigurację sieci, wolumenów, praw dostępu itp itd. Jedynym pseudo konkurentem ze strony Dockera był Docker Swarm, jednak projekt dawno już nie żyje, I dobrze, bo tylko konteneryzacja ("there is no such thing as container!"), czyli namespacowanie podsystemów OS'a - np. sieci, listy procesów, mapowania pamięci itp., powinna być zadaniem dokera :), tak samo jak egzekucja zadań od Orkiestratora (k8s) realizowana jest przez aplikacje zewnętrzne przy pomocy API (provisionowanie wolumenów, ustawienia sieci, itp itd). Pozdrawiam 😛

@@mioszlinkiewicz4272 Kiedyś był bardzo fajny projekt, nadający się do (na moje oko) 80% projektów webowych - Rancher (1.6). W skrócie - api dla skalowalnego docker-compose, z natywnym wsparciem namespeców, z haproxy jako ingressem, jednocześnie banalnym w obsłudze wyklikiwalnym UI. W jego interfejsie każdy kto rozumiał podstawy docker-compose (wtedy jeszcze nie było docker compose) był w stanie uruchomić coś na serwerze, były gotowe aplikacje w "app storze" jak chociażby gitlab, była obsługa dowolnego stopnia skomplikowania routingów - automatycznych, manualnych, wreszcie można było wystawić port kontenera czy dowolną inną funkcję możliwą lokalnie. Oczywiście to wszystko było z wsparciem dla wielu node'ów, z systemem dostępów, kluczy api itp itd. Nigdy nie udało mi się nawet zbliżyć czasowo (code to prod) do tego co było w banalny sposób osiągalne z dawnym Rancherem.

Ale za to jaki ciekawy temat :) I fajnie, że w Polsce są startupy zajmujące się takimi sprawami.

Mam szklaną kulę na biurku :) - same zdania twierdzące pomijam, to dobra informacja ale jak przychodzi ktoś i pyta się "dlaczego nie działa mu <nazwa projektu>" zamiast opisać co konkretnie nie działa i co robią że im się wydaje że powinno to wtedy sięgam i szklaną kulę i mówię że zaraz znajdę rozwiązanie tego problemu - tylko 50% ludzi w tym momencie się rehabilityuje :)

Zgadza się, partner Apple dodaje urządzenia do naszego konta Apple Business Manager. Obecnie urządzenia można dodać samodzielnie, ale spełniające odpowiednie kryteria - informacje na stronie Apple. Miło, że ktoś wyłapał błąd i go skomentował :) Dzięki!