[JavaDevMatt]

Dla tych, którzy ogarniają kontenery.
Co Wam lepiej pasuje w koncepcie karty DevOps Engineer?
Robot, czy koleś na wielorybie?

#programowanie #devops #karciankait #grybezpradu

[Lipathor]

@JavaDevMatt: połknięty przez wieloryba :P

[harakiri888]

@JavaDevMatt: nie ogarniam kontenerów, ale wieloryb lepszy.

[S.....s]

@JavaDevMatt niebieski wieloryb to bardzo groźna zabawa

[ManamanaTuriruriru]

@JavaDevMatt: docker jest przereklamowany

[uketrab]

@ManamanaTuriruriru: jak te wszystkie „nowoczesne” technologie

[ManamanaTuriruriru]

@uketrab: nie wszystkie, ale nie rozumiem zachwytu nad czymś co sobie nie radzi z utrzymaniem przywilejów między hostem a kontenerem 乁(⫑ᴥ⫒)ㄏ

[dog_meat]

@ManamanaTuriruriru: bo kontenery to nie wirtualizacja tylko separacja procesów

[ManamanaTuriruriru]

@dog_meat: Co nie zmienia faktu, że brakuje tam uprawnień i przy np. takim tar, który pakuje z uprawnieniami userów wyjdzie Ci buba straszna, druga sprawa volume's... ajj długo pisać

[y.....l]

@ManamanaTuriruriru: W sensie w jaki sposób sobie nie radzi?

[ManamanaTuriruriru]

@yggdrasil: czysto teoretycznie:
- kontener operuje w środku z UID 0 więc jeśli podepniesz mu volume w trybie binda z dyskiem to zapisze Ci tam z UID i GID roota więc jako user hosta nie będziesz miał tam dostępu
- działa to też w drugą stronę, bindowane zasoby mają UID i GID z hosta więc jako user stworzony w kontenerze tez nie będziesz miał dostępu, musisz więc tworzyć usera zgodnego z

[dog_meat]

@ManamanaTuriruriru: ale jaka buba wyjdzie? Spakuje z uprawnieniami użytkownika w kontenerze. No chyba że odpalasz kontenery z uprawnieniami roota to się nie dziw

[y.....l]

@ManamanaTuriruriru: To oznacza ze złe uzywasz. Używanie roota w kontenerze jest antypatternem. Jeżeli montujesz zasoby do środka to musisz zadbać o odpowiedni uid i gid.

[ManamanaTuriruriru]

@dog_meat: @yggdrasil: ja to wiem, że nie powinieneś używać roota i się tego trzymam, ale ciągle do tego dążę, że uid i gid z hosta powinien być remapowalny na inny uid i gid z kontenera by właśnie oszczędzić mieszania z userem i force'owania entrypoint przez gosu czy inny wrapper. Wyobraźcie sobie usera o nazwie docker w każdym kontenerze o stałym UID/GID np. 9000:9000 i mapowanie przez argument przy docker start,

[dog_meat]

@ManamanaTuriruriru: przede wszystkim nie powinniśmy używać tu terminu "z hosta". Kontenery to nie maszyny wirtualne, filozofia jest zupełnie inna. Większość problemów wynika z tego, że ludzie traktują kontenery jako maszyny wirtualne

[ManamanaTuriruriru]

@dog_meat: sama dokumentacja dockera używa słowa "host" więc to tylko czepianie się o nazewnictwo, ale powiedz, czy nie było by prościej jak by to działało tak jak opisałem wyżej? ;)

[dog_meat]

@ManamanaTuriruriru: no ale jakby to miało działać? Przecież już teraz możesz uruchomić kontener z uidem użytkownika na którym aktualnie siedzisz

[ManamanaTuriruriru]

@dog_meat: przykładowo mam obraz, w którym pliki są już na jakimś userze z jego uid i gid, chciał bym by mój uid i gid był zmieniany w locie na ten usera by nie robić chown, nadal nie wiesz o co chodzi?

[dog_meat]

@ManamanaTuriruriru: no nie wiem właśnie. Jak masz pliki wewnątrz obrazu, to uruchom kontener jako ten właśnie użytkownik i nie będziesz musiał robić chown

[ManamanaTuriruriru]

@JavaDevMatt: no to teraz dodaj do tego bind volume I będziesz miał niezgodność gid uid

[jaxon9000]

@JavaDevMatt na pewno nie wieloryb, DevOps przecież nie zajmuje się tylko konteneryzacją, a poza tym kto wie czy docker za kilka lat nie odejdzie do lamusa. Mnie najbardziej by pasowała mała dziewczynka z chińskiej porno bajki xD Z jakiegoś powodu większość devopsów z którymi miałem styczność, właśnie takie ma upodobania