Sky-arkitekt advarer: Containere bliver nemt det eneste søm i værktøjskassen

Og mange af dem rækker langt ud over teknologiens indre kvaliteter. Et gennemgående godt råd er KISS (Keep It Simple Stupid) - simpelt hen for at undgå at skulle have for mange forskelligartede værktøjer i produktion og for at undgå at have for mange forskellige slags skills i udviklernes hoveder. Hvis containere er godt til at dække 80% af behovet 80% af tiden er de fleste nok bedst tjent med at slå alle sømmene i med samme hammer. PS: Det er lidt underfundigt at netop en Microsoft arkitekt angiver licensproblematik som et eksempel på et problem med K8/Docker :-)

hvor visse licenser var bundet op omkring MAC-adresser. Da Kubernetes uddeler vilkårlige MAC-adresser ved opstart af containerne, måtte appen i sidste ende droppes.

For at kunne afvikle containere og virtuelle maskiner generelt på Windows kommer man let i konflikt med netop licenser. Det problem har man bare ikke på Linux.

Som er blevet forfiinet og kraftigt forbedret.. chroot var smart da det blev opfundet og pga. sikkerhedsbehov såsom isolering fra resten af maskinen / resource-begrænsningskrav osv. (som man jo altid har) - vil docker/podman etc. teknologier der er low-overhead isolation af processeser ALTID være relevant.. medmindre ens process SKAL eje hele den fysiske maskine (hvor docker/VM så bliver unødvendigt overhead - men stadigvæk kan være smart pga. nemheden ved recovery/re-install). Har man specielle behov (såsom MAC eksemplet) - så kan det være man skal smide den i en VM istedet.. Men det er ikke meget tilbage, og VMs har et helt del større overhead... Men også statistisk større sikkerhed (fordi de har deres egen kerne - så isolationen fra hardwaren er større).

Man hører mere og mere om at mange kører docker, inde i en VM - for at øge sikkerheden. Hvis man f.ex. godt vil have k8s controlplane (der styrer hele clusteret og man skal have 3 af) på samme hardware som nogle af sine k8s worker noder (der kører "farligt indhold") - så kan man øge sikkerheden omkring det ved at køre k8s-workeren på samme hardware - men inde i en VM (så en angriber skal få en shell på servicen, derefter undslippe docker og så OGSÅ undslippe VM'en- for at "owne dig").

Docker kan faktisk godt sætte MAC addressen - så hvorfor udvidede de ikke bare k8s - så den tillod at videregive den setting til den underliggende docker? Det burde ikke være den svære udvidelse af k8s at lave, hvis man har behovet.

Licens baseret på MAC addr. pinning er bare en uskik, og var da også et issue da man startede bare med eks. vmware.

Har mange gange hørt på producenter sige "Vores app kan ikke virtualiseres, og selvom den kan vil vi ikke understøtte den". Medmindre bundet til noget specifikt hardware, kunne langt det meste lade sig gøre. Det er efterhånden også min erfaring med containers.

Udtalelsen "Hvis man kan slippe for containere skal man gøre det, og kun anvende dem, når der er en klar grund til det, lyder det afsluttende fra Alaa Tadmori." - Den virker ikke synderlig innovativ.