Feda /dev/ - No Javascript allowed

#44848 Para empezar deberiamos analizar los problemas que Docker y los "contenedores" resuelven.

• problemas de gestion de infra
• problemas de gestion del software

Sobre la gestion de infra. Los contenedores para empezar son un fracaso. Hemos fracaso en hacer software reproducible en distintas maquinas y por tanto reproducimos la maquina.

Gestion de software. En general todos los sistemas de distribucion estan todos rotos. Desde apt, yum a cualquier repositorio como pypi, cargo etc. https://www.youtube.com/watch?v=Wt6rZTijfpk

Estos son mis dos mayores problemas en general.

En especifico no voy a entrar por pereza. Solo la mierda de systemd vs docker si quieres googlear algo. Panda de anormales.

En general estoy en contra de toda la cultura de gestion de procesos del siglo XXI. No tiene sentido tener que usar contenedores y luego orquestradores y luego una capa encima y asi. La gente ha re-inventado la reuda mal, 10 veces, al mismo nivel.

Es lo que pasa cuando tienes 10 empresas, con 10 productos distintos, que quieren atraparte en su ecosistema, que no hacen herramientas interoperables y se follan el user space por el culo para luego cagarte en el pecho mientras tu gritas "si papito, dame mas kubernetes".

Por aqui tienes bastantes tontos que cada dia van a trabajar en su "service mesh" como si estuviesemos en los años 80. Pero eh, luego no saben decirte que casos de uso resuelven.

Replanteo la pregunta porque no encuentro un término exacto para lo que pensaba

¿Qué recursos recomendarías para repasar/expandir los conocimientos necesarios para enter/aplicar la explicación que aportas en ese artículo en su totalidad?

#44852

Es que yo siempre lo he visto como un modo de ahorrar recursos en los entornos cloud porque antiguamente tenías VMs que no sólo tardaban un año en encenderse sino que escalables eran hasta cierto punto. Por tanto, es muy posible se haya quedado desfasado ya por cómo ha evolucionado el cloud y la gestión de los servicios, pero en su momento fue un soplo de aire fresco en entornos de sysadmin remeros (al menos en España).

Son cosas que por cómo se han diseñado chocan a veces, pero son complementarias en mi opinión. Y ojo que docker en sí me parece una mierda, pero la tecnología de contenedor sí me parece un buen concepto. Cuando se creó systemd tampoco estaba pensado para lanzar aplicaciones (servicios es otra cosa) y se usa bastante, pero es un puto jaleo andar con cgroups y chuminadas para cerrar el entorno.

Qué propones tú para atomizar entornos con el mínimo uso de recursos (para mantener microservicios no eh) y permisos sin pasar al userspace del OS?

#44861

Eres una empresucha con tu hierro en co-location y cada día te cobran más por las máquinas. Tienes el vsphere echando humo y la factura no para de subir.

AWS, GCP y Azure están en pañales (por eso te hablo del contexto de cuando se creó docker, no del hoy día, que creo que estamos de acuerdo) Ni RDS ni EKS ni mierdas.

#44863 He visto listines telefónicos más pequeños. Pero qué mierda hay en ese libro para que sea así de gordo.

#44863

Es que de aquellos barros estos lodos. Por eso no existía el concepto serverless, porque no había oferta ninguna. De Borg nació Kubernetes, no sé si por aprovechar el momento o porque no había competencia.

Sobre el networking estoy de acuerdo, pero es que se tendría que actuar en concordancia con los estándares RFC incluso. Al final siempre hacen falta infra extra sólo para el networking, sin entrar en cybersec. De todos modos, ahí me imagino que hablas de tu caso personal porque lo que dices ya se hace. Hay algunos proveedores de servicio que montan unas cosas muy locas en ipv6 exclusivamente. Si no se ha extendido de forma masiva y a más bajo nivel, sólo se me ocurre que pueda ser por deuda técnica de nuevo. Te reto a que migres toda tu red de casa a ipv6. Móntate una vm con pfsense y haz un bridge pa probar.

Pues aquí no estoy de acuerdo. A Google no le soluciona el contexto, a Google le viene bien "solucionar" ese contexto. Son ellos quienes sacan provecho de su cloud teniendo Kubernetes como orquestador para todo el mundo. Dile a Google que se empiece de cero teniendo su software en el 99% de empresas tech medio grandes y una instancia de las más usadas incluso en AWS. Si quitas esas capas, quitas 300 productos del cloud.

Pues lo primero matar a jenkins de una puta vez. Eso es bien fácil xd. Pero del stack empezaría a usar podman en vez de docker, si usas kubernetes no hay razón para no hacerlo. Si hubiese un orquestador de lxc's igual es mejor idea. Al final es igual que hace 10 años, quieres reducir complejidad y quizás costes, por qué cosa fácil optas? Pues en 10 años volveremos a tener el mismo debate y seguirán reinando tecnologías que convienen a algunos exclusivamente.

#44869 Si claro. Yo soy un futurista.

Gamozo(https://gamozolabs.github.io/) se hizo su propio orquestrador de VMs. Levantaba 400 vms corriendo windows, en 20 hosts fisicos distintos, o un numero asi, en 50 milisegundos? O 100 ms? No me acuerdo. Eran buenos numeros para un test.

Solo se que levantar lo mismo en AWS eran 40 segundos. Tampoco me acuerdo, pero de 10 a 100 veces.

Vamos, el trabaja para Msft como security engineer, y me acuerdo que dijo.

"Como puedo yo hacer en un par de streams, de 8h, algo mejor que Azure??? Si no soy ni ingeniero de software, que yo hago seguridad. MSFT llamame que te re-hago Azure".

Yo cuando hago un deploy tengo que esperar MINUTOS a que mi instancia en ec2 este activa y funcional. Entre las mil historias que hay que hacer y lo que tarda en levantarse.

Sobre la deuda tecnica el otro dia lei este: https://mjg59.dreamwidth.org/66109.html Madre mia. Quiero matar puta gente.

Tambien sobre tema futurista, yo me encuentro con muchos problemas en tema pull vs push sobre TCP. Por ejemplo: https://news.ycombinator.com/item?id=35613454 es una idea interesante que comparto y en este hilo he explicado mil veces como usar colas desde nivel kernel a nivel de sistema distribuido y no hay manera... La gente NO SABE QUE ES UN COLA NI COMO FUNCIONA.

Dicho esto y que nadie me cite, ando implementando algoritmos distribuidos, el log de kafka en concreto ahora y estoy sufriendo XD No digo que sea facil. Hay que ponerse. Al menos se como funciona la teoria.

Una de las ventajas de los contenedores es poder escalar horizontalmente bajo demanda. Te permite replicar tu aplicación o desplegar en diferentes sitios sin mucha preocupación.

Una vm tradicional consume mas recursos que un contenedor, realmente lo único que necesitas es tener tu aplicación aislada en un entorno controlado. Tener todo bajo un único sistema suele traer otros problemas, dependencias cruzadas, distintas versiones etc etc.

#44874W0rd:

realmente lo único que necesitas es tener tu aplicación aislada en un entorno controlado

los contenedores no aislan subnormal, que vas a aislar compartiendo kernel.

para asilar minimo necesitas una vmm encima de una kvm y ahi tirar tu runc o una gvisor o lo que te saga de las pelotas si quieres aislamiento.

Otro dia programando, otro dia que encuentro algo imposible / errores de diseño en el kernel.

Que ademas si es windows o unix sera distinto el comportamiento...

Hoy me he encontrado que para tener "mandatory locking" en linux tienes que hacer piruetas.

Es decir, no tienes una manera directa (como un flag en open(3)) de hacer el acceso a un fd multiprocess safe.

Si corres N procesos que intentan leer el mismo archivo, no tienes un puto lock...

Ridiculo.

Lo que quiero:

$ process file_a.txt
$ process file_a.txt
$ process file_a.txt

Y que cada process escriba y lea de file_a.txt de manera atomica.