Wpis z mikrobloga

@normanos: Docker.

1. Napisz aplikację.
2. Skompiluj ją do portowalnego byte-code'u, który trzeba uruchamiać na wirtualnej maszynie (np JVM).
3. Wirtualna maszyna działa w zwirtualizowanym środowisku Dockera
4. Docker działa na wirtualnych serwerach w chmurze.

Wincyj warstw wirtualizacji!

Andrzej, to jebnie.


Osobiście uważam Dockera (i jemu podobnych) za jedną z większych pomyłek w IT od jakiegoś czasu. I to jeszcze do "micro" serwisów jest używane... Eh.
vipe - @normanos: Docker.

1. Napisz aplikację.
2. Skompiluj ją do portowalnego by...

źródło: comment_1613992846Rm3xaNjt2lkHwOkATumtK2.jpg

Pobierz
  • Odpowiedz
@vipe: nic nie jebnie. Technicznie to dodatkowa warstwa abstrakcji ale w praktyce to jedyna która, Cie interesuje jako deva (no chyba, że tak jak mówisz masz JVM albo inne cudo w kontenerze. Przynajmniej wiesz jaką wersję JVM masz w kontenerze i jak sobie chcesz zmienić wersję to robisz to bez problemu, ale to już niuanse javy).
Wydajniościowo to jest prawie zerowy nakład a ułatwia bardzo dużo.
No ale zobaczymy, IMO może
  • Odpowiedz
@vipe: rozważ srodowisko heterogeniczne zbudowane na kilkudziesięciu komponentach pisanych przez lata we wszystkich możliwych wersjach pythonów, pehapów, nodejsów i dżavów, gdzie niektóre z tych komponentów muszą się dynamicznie skalować a wszystkie są mission critical (na zasadzie: nie ruszaj gówna póki nie śmierdzi). Zaproponuj rozwiazanie inne niż kontenery i jakiś Kubernetes, które nie rozwali połowy systemu przy nieudanym upgrade silnika któregoś z języków i jednocześnie będzie efektywne kosztowo (nie będzie wymagało ciągłej
  • Odpowiedz
@vipe: chroot nie załatwi sprawy autoscalingu.
Weź też pod uwagę aspekt QA - mając obrazy kontenerów testerzy mogą sobie je składać do kupy jak klocki przy testach integracyjnych używając tych samych binarek które za chwilę polecą na produkcję, co mocno oszczędza czas.
No ale co kto woli.
  • Odpowiedz
@novicky99: Zgadza się. Jednak budując umiejętnie środowisko można je łatwo (jednym kliknięciem) odtworzyć, włącznie z wariacjami testerskimi, developerskimi, preprodukcyjnymi, itd. Tylko to wszystko wymaga trochę wysiłku i umiejętności. Łatwiej jest zrzucić wszystko na maszynę, tylko że potem się okazuje, że jakaś funkcjonalność mająca przerzucić kilka jsonów z jednego miejsca w drugie wymaga 500MB dysku i 1GB ramu, bo ludzie są leniami i palcem i się kiwnąć nie chce, są zapatrzeni w
  • Odpowiedz
@novicky99: Aha - co do autoscalingu, to wystarczy taki "Kubernates" odpalający tyle procesów/instancji ile trzeba - nie musi to siedzieć w dockerze. To co robi Kubernates samo w sobie nie jest złe.
  • Odpowiedz
No ale zobaczymy, IMO może się pojawić coś co zastąpi dockera ale ta warstwa abstrakcji już z nami zostanie.


@bmLq: podman

Zaproponuj rozwiazanie inne niż kontenery i jakiś Kubernetes, które nie rozwali połowy systemu przy nieudanym upgrade silnika któregoś z języków i jednocześnie będzie efektywne kosztowo (nie będzie wymagało ciągłej żonglerki VMkami na jakimś xenie czy vmware).


@novicky99: języki kompilowane do statycznie linkowanych binarek, odpalane we własnych nejmspejsach i cgrupach
  • Odpowiedz
języki kompilowane do statycznie linkowanych binarek, odpalane we własnych nejmspejsach i cgrupach jak przez systemd-run


@nunczako: nie zapomnij zaimplementować w każdym języku podobnego do dockerowego mechanizmu warstw, który sprawia, że przy dobrze złożonym dockerfile warstwy systemowych zależności się nie zmieniają, nie zajmują miejsca * ilosć wersji, i można je cache'ować
  • Odpowiedz
@nunczako: miałem na myśli legacy którego strach dotknąć żeby zrobić upgrade silnika jezyka czy tam jądra a co dopiero przepisywać.

Takie czasy że taniej pogodzić się z kosztami ramu i cpu niż płacić ludziom żeby optymalizowali aplikacje.

Podman wygląda ciekawie ale póki co żyje chyba tylko w universum redhata. Poczekamy, może będzie to alternatywa dla kontenerów w user space.
  • Odpowiedz