Pues despues de la conversión creo que voy a dar una oportunidad a las distro inmutables y "me has puesto" unos cuantos deberes: - profundizar en contenedores para lanzar aplicaciones con entorno gráfico - aprender nix para distribución del proyectos software y para crearme un entorno de desarrollo personal que me lo pueda llevar de equipo en equipo (https://www.youtube.com/playlist?list=PL1C97G3GhlHdANMFUIXTcFr14R7b7EBj9) (https://ghedam.at/24353/tutorial-getting-started-with-home-manager-for-nix)
Más abajo te respondo a algunas cosas. Saludos! El sáb, 22 abr 2023 a las 1:40, Unai Martinez (<[email protected]>) escribió: >> >> 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). > Disculpa soy bastante malo para los nombres :) >> 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? > Con selfhosted me refiero a que tengo un pequeño servidor en casa donde despliego algunos servicios mios como un nextcloud propio, jellyfin, ttrss... - Empecé con ansible para gestionar la configuración del host y los contenedores - Luego pasé a ansible para gestionar la configuración del host y a docker-compose para los despliegues de los contenedores Con un Intel Atom y 4GB de RAM tengo más de 20 contenedores corriendo y dándome servicio. Como dices, se de gente que usa minikube para desplegar pods/contenedores con configuración de kubernetes. Pero no le veo sentido para un setup pequeño en 1 nodo cuando no tienes orquestación de contenedores en varios nodos. A no ser que quieras correr una configuración kubernetes (deployments, services...) y no quieras "traducirla" a docker/docker-compose. Se de gente que por no traducir usa el minikube en 1 nodo. Minikube lo veo muy práctico para aprender kubernetes y probar configuraciones antes de desplegar en un clúster kubernetes. Y más que minikube si usas Linux recomiendo kind. Es mucho más potente. >> >> 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. > Bueno sin QubesOS siempre puedes instalar un Debian liviano y con Virtualbox/Virt-Manager usarlo solo para desplegar máquinas virtuales. Para un escritorio me parece más comodo que desplegar un entorno servidor como Proxmox o ESXi. Pero si que es verdad que tener una distro normal, es propenso a que ya que estamos y tengo prisa me instalo la paquetería en el host. >> >> 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? A nivel de hardware si que tiene unos requisitos que otras distros no tienen https://www.qubes-os.org/doc/system-requirements/ y eso hace que tengan una BBDD de Hardware recomendado/testado https://forum.qubes-os.org/t/community-recommended-computers/5560 >> >> 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. > Las plantillas se arranca y puedes instalar software en ellas. Tienen un procedimiento para eso. Y para evitar que las plantillas se comprometan, limitan bastante la conexión a internet de esas plantillas. Una vez que has instalado software en una plantilla, todas las MV que se basan en esa plantilla disponen de ese software instalado. Por ejemplo, hacer "apt-get install vim" en tu plantilla debian para desarrollo de software, hace que todas tus máquinas de desarrollo basadas en esa plantilla dispongan de vim. También lo que se actualiza con parches de seguridad son las plantillas. Y todas las MV basadas en esa plantilla ya disponen del parche de seguridad. >> 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? Pues que no es un contenedor :D. Que puedes distribuir tu proyecto Git con un fichero "shell.nix" para que los desarrolladores y finalmente la ejecución sea en un mismo entorno https://www.codesuji.com/2020/10/25/Nix-For-Development/. Y no estamos hablando de un Dockerfile en el que tienes que tener instalado Docker en tu equipo (nix se instala en Linux y Mac con un comando), que tienes que hacer docker build para hacer la imagen, docker run para correr el contenedor y saber/conocer de docker para interactuar (lo deben de conocer todos los desarrolladores). De esta forma usar nix es como lanzar un shell adicional y el entorno de ejecución esta listo. No se si me explico... Nix me recuerda a virtualenvwrapper, pyenv, poetry de Python... pero agnóstico del lenguaje de programación... Pero bueno es la idea que me hecho después de leer un poco sobre él... -- Christian Pinedo PGP key ID: 0x9306dfd0cde4b542 _______________________________________________ ITSAS mailing list [email protected] http://list.ehu.eus/mailman/listinfo/itsas
