> > Yo vengo más de la parte de sistemas de la virtualización con experiencia > principalmente en ESXi y KVM. >
Creo que no nos conocemos personalmente, pero te tengo más o menos identificado y hemos intercambiado correos puntuales desde 2019 ;). Como co-gestiono una VM en la uni, recibo tus comunicaciones sobre infraestructura. Hace un par de meses te pregunté si teníamos que movernos de RHEL7, o si podíamos aguantar (por si no hubieras asociado los dos canales). A esto le sumo la gestión de la configuración con ansible, docker-compose, > dotfiles... > Para mí todo lo que es más de un contenedor de forma orquestada es una nebulosa (pun intended). Utilicé docker-compose y swarm en 2016-2017 para ver cómo era, porque hacía muy sencillo lo que desde mi punto de vista de electrónico era complicado. Pero hasta ahí. Como nunca tuve un caso de uso, se quedaron en varias tardes de curioseo. He mantenido algún Gogs/Gitea o GitLab en casa, pero no me aguantan más de dos meses. No tengo constancia para atenderlos. Cuando llegó Kubernetes, me pareció que para un solo equipo y para no correr ningún servicio web, era añadir capas innecesarias. Y con el boom, me alegro de haberlo sacado del radar. Demasiada carga cognitiva. En cuanto a Ansible, lo relaciono vagamente con Terraform, que me suena porque https://github.com/antmicro/runner lo utiliza. Lo asocio a crear y modificar máquinas virtuales en datacenters en base a ficheros parecidos a lo que los Dockerfiles son a las imágenes de contenedores. Pero así dicho, me parece que estoy hablando de Vargrant. Entiendo que cuando dices en casa "selfhosted", ¿te refieres a que tienes un equipo con servicios en la red local como, yo qué se, Jellyfin? ¿O te refieres a utilizar Kubernetes en el escritorio en sustitución de la CLI de docker o podman? Conozco gente que utiliza pods en el escritorio con minikube (https://minikube.sigs.k8s.io/docs/start/), pero siempre he pensado que era porque su exposición a los contenedores fue a través de kubernetes en el trabajo y en ese caso resulta natural. ¿Cómo lo ves? ¿Qué te aporta/dificulta? > En tu correo haz mezclado cosas de servidor como Proxmox como de > Escritorio. Mi email va más por la parte de "Linux en el Escritorio". Igual > este es el año de "Linux en el Escritorio" xDDD > Es que mi escritorio es un i5 de 2016 que tiene 4 cores y 32 GB de RAM (16 para contenedores y 16 para mi), sin hyperthreading. Al precio que están, estoy pensando en pasarme a un 5900X y 64 GB (u 80GB) de RAM. ¿Cómo haces uso de 12 cores y 24 hilos con un "Escritorio"? Incluso 8|16 me parece mucho. Lo único que se me ocurre es quitarme otros dos equipos (de 2012), virtualizarlos y así reducir el consumo. Pero no quiero que el Escritorio comprometa la estabilidad de esas dos máquinas. Hasta que me has hecho conocer QubesOS, sólo se me ocurría tratar el equipo como un servidor. > > - QubesOS apuesta por máquinas virtuales. Primero porque las máquinas > virtuales presentan un mayor aislamiento y seguridad que los contenedores > cuyo fin principal nunca ha sido la seguridad. > > Lo entiendo. Mi pregunta/plateamiento iba relacionado con "Necesitas un equipo hardware potente y con un hardware muy determinado". Si el mayor aislamiento y seguridad requieren mayor potencia de hardware, tiene sentido ofrecer las dos opciones: sandboxing con coste o aislamiento parcial a mucho menor coste. Se puede simplemente instalar podman y decidir qué lanzar en qubes y qué en contenedores, pero sería guay tenerlo en la misma aplicación de gestión. BTW, ¿a qué te refieres con muy determinado? Al tratar de hacer passthrough de algunos dispositivos usando Proxmox, he visto que los equipos "domésticos" de 2011-2013 no soportan IOMMU. ¿Van por ahí los tiros? ¿O incluso hablando de procesadores "actuales" tampoco sirve cualquiera? > > - El uso de Xen frente a KVM creo que es porque Xen al ser > para-virtualización se supone que obtiene un mejor rendimiento y por otro > lado porque con Xen es posible usar aplicaciones virtuales en el > dom0/hipervisor como si fuesen aplicaciones nativas. No a traves de la > consola de la máquina virtual. > > Eskerrik ako por la explicación. > > > - Define MV plantilla, que instancias varias veces. Por ejemplo MV > plantilla de desarrollos software que instancio una por cada proyecto > que > tengo. > > El concepto lo entiendo porque es similar a las imágenes (persistentes) de docker vs los contenedores (temporales). Pero no veo dónde/cómo están definidas esas plantillas. Leyendo https://www.qubes-os.org/doc/templates/, ¿parece ser que son binarios precompilados? Por una parte, me alegra no ver otro "marketplace" de recetas. Por otra parte, ¿cómo añades contenido a la plantilla para no tener que hacerlo cada vez que creas/arrancas un qube? Parece que las plantillas no tienen capas, sino que cada una es independiente. Aprovecho para responderme a lo que preguntaba sobre "VMs tradicionales": https://www.qubes-os.org/doc/standalones-and-hvms/ > > - Pero tiene handicaps: > - Necesitas un equipo hardware potente y con un hardware muy > determinado. > - El entorno gráfico es XFCE te guste o no. > > También me ha parecido leer, y me ha llamado la atención, que es single-user. > > - En general QubesOS me gusta por la seguridad y por la limpieza a la > que te obliga. No mezclaras tu vida personal con tu trabajo porque van > en > Qubes (máquinas virtuales) diferentes. Y no tienes otra, porque el > anfitrion/hypervisor no lo puedes tocar apenas. > > A mi me gusta porque todo eso es en un solo escritorio donde las ventanas están coloreadas para saber a que qube pertenecen. Porque sin eso todo lo demás es cojonudo, pero me reventaría el cerebro intentando usarlo. > Con toolbox/distrobox se pueden arrancar aplicaciones gráficas desde > contenedores. La verdad que creia que no era posible arrancar GUIs desde > contenedores. Y creo que es posible hacerlo incluso con docker/podman con > cierta configuración. > Sólo hay que compartir el socket X11: https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY Pero, si te preocupa la seguridad, hay mejores opciones: https://github.com/mviereck/x11docker ("Avoid X security leaks and enhance container security"). Así utilizo yo GUIs de Linux en Windows (con VcXsrv), de forma muy similar a como QubesOS muestra las ventanas de las VMs en el escritorio principal. La diferencia es que x11docker no colorea las ventanas, por lo que al abrir unas cuantas en varios contenedores, no es tan intuitivo recordar a cuál pertenece cada una. Especialmente cuando es el mismo programa y versión el que has abierto en dos contenedores. > Como soy usuario KDE, Fedora Kinoite me está convenciendo. Pero todavía no > tengo claro como trabajaría: > > - flatpak no me entusiasma, creo que todavía no esta madura y muchas > aplicaciones reciben demasiados permisos. > > podman; y para GUIs elige la solución que más te guste de las documentadas en x11docker ( https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#dependencies-of-all-x-server-and-wayland-options). No tienes por qué usar x11docker, ya que al fin y al cabo es "sólo" un script bash de doce mil líneas: https://github.com/mviereck/x11docker/blob/master/x11docker. Pero el README y la wiki valen oro. si flatpak no te convence por demasiados permisos/acceso, podman es el paso natural antes de pasar a VMs. En comparación con QubesOS, las diferencias principales que veo son: - El asilamiento (que con los contenedores no es tan estricto, aunque podman y x11docker se acercan). - La integración sobre todo del mantenimiento. x11docker tiene una GUI para lanzar contenedores, pero no para gestionar los que están arrancados o para "actualizar" un contenedor. Para eso, Docker Desktop ha ido mejorando bastante. Y de hecho, ahora que lo menciono, acabo de buscar https://podman-desktop.io/ y no entiendo por qué no he descubierto que existía hasta ahora... - Backups, que como has mencionado tienes que hacertelos tú. Pero, por otra parte, esto puedes empezar a hacerlo en Fedora o Debian o Arch, de forma que reduzcas el peso del sistema principal. Y de ahí, si te convence la forma de trabajar, el cambio a Kinoite, SilverBlue o QubesOS es directo, porque te llevas tus contenedores (imágenes) contigo. De hecho, puedes guardar los contenedores como imágenes, exportar todas las imágenes a un tarball, e importarlo todo de golpe en el sistema nuevo. > > - Para distribuir mis proyectillos de software con un entorno de > ejecución que no sea docker > > No entiendo esto. ¿Qué entorno de ejecución ofrece nix que no sea hacerlo de forma nativa o en un contenedor? Salud Unai >
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.eus/mailman/listinfo/itsas
