Unai, lo primero que he pensado al ver tu email ha sido: "esto me pasa por
preguntar" jaja Pero ahora fuera bromas, mila esker por tu detallada respuesta.
Pero has abierto un melón enorme que es muy difícil de partir.
Creo que tienes una experiencia enorme en el empaquetado y distribución de
aplicaciones. Yo vengo más de la parte de sistemas de la virtualización con
experiencia principalmente en ESXi y KVM. Y desde hace unos años me pego con
los contenedores, desde hace años con docker tanto en casa "selfhosted" como en
el trabajo y últimamente con Kubernetes. A esto le sumo la gestión de la
configuración con ansible, docker-compose, dotfiles... Y un poco de
empaquetado/distribución de python pero en pequeños proyectillos con
venvwrapper, pyenv y poetry. No he hecho mucho, pero a poco que tocas en Linux,
al final te metes en varios charcos...
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
Te comento un par de cosas sobre QubesOS que he ido probando:
* 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.
* 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.
* Además QubeOS ha pensado muy bien como gestionar todo este pool de MV:
* Hay MV especiales para networking, firewall, USB... Y algunas de estas
son disposable (lo comento más abajo).
* Define MV plantilla, que instancias varias veces. Por ejemplo MV
plantilla de desarrollos software que instancio una por cada proyecto que tengo.
* Cuando actualizo las plantillas (yum update), se me actualizan todas
las instancias!
* La actualización de las plantillas, se hace desde el gestor de
máquinas virtuales. Le das a actualizar todas las plantillas y se pone a ello.
* Tienen una herramienta de backup, para poder hacer backup de los datos
y las MV.
* Tienen el concepto de MV disposable, que es como un livecd, que pierde
el estado cuando la apagas y se arranca como recien instalada. Por ejemplo, si
recibes un fichero sospechoso, lo abres en una MV disposable y tras reiniciar
la MV, esta como recien instalada.
* Integran WhonixOS en 2 máquinas virtuales para la navegación Tor
segura. Y usa máquinas disposables por si te hackean durante la navegación.
* Pero tiene handicaps:
* Necesitas un equipo hardware potente y con un hardware muy determinado.
* El entorno gráfico es XFCE te guste o no.
* Es muy interesante ver como proponen usar QubesOS por diferentes perfiles
de usuarios: hacktivista, desarrollador de software, financiero...
https://www.qubes-os.org/doc/how-to-organize-your-qubes/
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.
En este aspecto, los sistemas operativos inmutables, te fuerzan a algo similar.
Es dificil instalar, o no óptimo, instalar software en el sistema operativo
base. Tienes que usar aplicaciones de flatpak, snap, appimage o nix. O
directamente contenedores con podman/distrobox/toolbox.
He estado probando Fedora Kinoite y la filosofía sería la siguiente, si
necesito instalar una aplicación:
1. Preferentemente flatpak/snap/appimage si es GUI
2. Si es CLI tienes que is a toolbox/distrobox o directamente crear una
imagen/contenedor.
3. El último supuesto es instalar algo en el sistema base
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.
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.
* la actualización se complica:
* actualizas el sistema base con rpm-ostree
* actualizas los flatpaks
* tienes que actualizar con "yum update" los toolbox que tengas y con el
correspondiente comando los distrobox o podmans
* el backup... no es como QubesOS que te ofrece una herramienta... también
te lo haces (yo hasta ahora usaba borg y btrfs)
Y a este mar de dudas, he descubierto nix (el gestor de paquetes no NixOS) y la
verdad que lo que veo me gusta.
* Para generarme un entorno CLI de trabajo independientemente del Linux o
MAC en el que me encuentre.
* Para distribuir mis proyectillos de software con un entorno de ejecución
que no sea docker
* Para incluso gestionar mis dotfiles con "nix home-manager".
No se estoy por seguir testando Fedora Kionite y descubriendo Nix.
Saludos!
--
Christian Pinedo <[email protected]> [+34 94 601 2156]
Sistemas/Sistemak, Vicegerencia TIC/IKZ Gerenteordetza, UPV/EHU
PGP fingerprint: A895 7C11 84F6 30B4 4938 32A4 9306 DFD0 CDE4 B542
________________________________
De: ITSAS <[email protected]> en nombre de Unai Martinez
<[email protected]>
Enviado: viernes, 21 de abril de 2023 18:24
Para: Grupo Itsas para la promocion del software libre en la UPV/EHU
<[email protected]>
Asunto: Re: [Itsas] distros inmutables y otras por ahi
Ahora si, entremos :D
Llevo varios años dándole vueltas a ese tipo de distribuciones, y planteándome
usarlas como plataforma principal, pero por razones puramente pragmáticas,
siendo muy ignorante en cuanto a seguridad.
El tema toca el empaquetado y distribución de software, y también los
contenedores, porque aunque hablamos de distribuciones, nix, flatpak, etc.
Tengo varias cuantas cosas acumuladas en la cabeza en este sentido. De hecho,
estoy en proceso de escribir un artículo|paper más bien divulgativo al respecto
(el uso de contenedores en escritorio y para desarrollo, muy al margen de todo
el ruido de la nube).
Espero me permitas responder con un artículo de blog, más que un correo.
Puede que quieras leer las secciones en orden inverso (y en cualquier caso en
diagonal), ya que al final hablo de hipervisores, anstes de distribuciones
inmutables, antes de nix, y las secciones anteriores (las primeras) son para
explicar cómo llego yo a esas conclusiones (más bien cómo mis premisas me
condicionan).
TL;DR:
- nix guay; nixOS no sé yo.
- CoreOS o SilverBlue worth a try como alternativa a Ubuntu Server o Fedora
Server. Para Workstation, casi que lo mismo da.
- Totalmente de acuerdo en que empezar a entender cómo y a aislar las
aplicaciones, los datos, el sistema, la capa de usuario, etc. siempre bien, por
razones de seguridad pero también pragmáticas (la estabilidad de nuestra
infraestructura "personal" a lo largo de los años) cada cual con las
herramientas que menos disrupción le supongan.
- QubesOS MUY interesante.
# Contexto
Utilizo 4-6 equipos diferentes en mi día a día, con Windows 10, Fedora, Red
Hat, Debian o Ubuntu. La primera vez, es divertido y didático cacharrear con
las particularidades de cada sistema, con la configuración de las herramientas
y el escritorio, etc. Con el tiempo, la diversión pasa a ser trabajo, y a
generar cierta ansiedad el no poder trabajar en otras cosas más excitantes sino
tener que pelear con X característica/configuración otra vez más.
Por eso, he acabo reduciendo el host a:
- Vim, git y openSSH y Docker|Podman.
- Si tiene escritorio:
- Firefox (con "sincronización" de pestañas; a ver cuándo se pueden
sincronizar contenedores tambíén).
- VSCode|VSCodium y LibreOffice.
- Gimp, Inkscape, Meld (en GNU/Linux) o WinMerge (en Windos).
- Steam y Godot (que es estático).
Todo lo demás lo uso a través de contenedores: GCC, LLVM, Go, NodeJS, LaTeX,
Sphinx, asciidoctor, pandoc, Matlab, Octave, Vivado, ModelSim/QuestaSim, EDA
open source (simulación, síntesis y/o implementación), Jellyfin, qbittorrent,...
También en los sistemas ARM que soportan docker|podman. Curiosamente, en
Raspbian de 32 bits se pueden|podían ejecutar contenedores de 64 bits porque si
CPU lo soporta (Pi 3), aunque el sistema (host) sea de 32 bits¿?.
Así, no me importa en qué ordenador estoy, y tampoco me importa si el
escritorio que estoy usando está en una CPU "pobre". Los contenedores son los
mismos independientemente del sistema, y lo mismo me da ejecutarlos de forma
local o, si tengo conexión, remota (por SSH o utilizando integración continua).
Si tengo que usar el ordenador de otra persona, sé que con borrar la carpeta
local y los contenedores que haya usado no estoy dejando basura.
Si el sistema en el que estoy casca por una actualización puñetera, a malas
puedo arrancar una LiveCD de Ubuntu o Fedora y salvar el día para pelear con el
host en otra ocasión.
En clases de máster uso Gitpod, a falta de ganas para gestionar la instalación
de software en los equipos de aula de la uni que són exclusivamente Windows.
Quienes asisten con su portátil pueden instalar las herramientas de forma
nativa, sea en GNU/Linux o en Windows, si quieren.
A lo que voy: lo que me interesa es la inmutabilidad de la capa de aplicación,
que es con la que más interactúo como usuario doméstico, profesor e
investigador que desarrolla hardware/software. El sombrero de administrador de
sistemas prefiero ponermelo lo justo y necesario porque es otro pozo sin fondo
y tengo tendencia a asomarme con demasiado ímpetu. Del sistema sólo me
interesan el kernel, y los drivers para el hardware que esté conectado; y por
salud sólo quiero que me interese que funcionen.
# Contenedores, snap, flatpak, appimage, Conda...
La razón principal por la que decidí migrar todas las aplicaciones a
contenedores es que en 2016-2017 Windows Subsystem for Linux (WSL) no existía
de forma usable pero Docker for Windows sí funcionaba sobre HyperV. Combiné (y
combino) MSYS2 con Docker en Windows para utilizar los mismos scripts y
Makefiles que desarrollo en GNU/Linux.
En comparación con snap/flatpak/appimage, los contenedores GNU/Linux
funcionaban y funcionan "exactamente" igual en cualquier sistema GNU/Linux,
Windows o macOS. La experiencia que tengo con snap/flatpak/appimage es que
funcionan en GNU/Linux, pero no siempre, y no lo hacen en Windows. WSL2 no es
Windows, sino una VM/contenedor, por lo que lo considero equivalente a usar
Docker for Windws.
Y aislan, pero no del todo. Porque si dependen de, por ejemplo, Python, pueden
usar el python del sistema, que puede no ser el mismo dependiendo del host.
Tampoco parece conceptualmente razonable meter una instalación de python en
cada snap/flatpak/appimage, porque no comparten contenido entre si.
Si combinamos snap/flatpak/appimage con venvs de Python, nos acercamos a
reinventar Conda (ver más abajo).
Son soluciones pensadas para aislar excepcionalmente algunas librerias del
sistema, pero no todo el sistema de ficheros.
Por contra, los contenedores son soluciones paara aislar todo el sistema de
ficheros, con honrosas excepciones.
Por eso, no he tenido interés particular por entender cómo funcionan y por qué
no lo hacen a veces. Si en cualquier caso voy a tener que meter las
herramientas en un contenedor para usarlas en Windows o macOS, me sobra la capa
de abstracción que me ofrecen. No considero que nix esté exactamente en la
misma categoría, lo cual es mi motivación para responder a este hilo :D. Ver
más abajo.
Conda (Anaconda, Miniconda, Mamba...)... menudo pastel, eh! La idea no es mala:
tener un conjunto de librerías para cada una de las plataformas y compilar las
herramientas contra esas librerías. De forma similar a snap/flatpak/appimage,
el sistema de ficheros no está del todo aislado. Básicamente se manipulan las
PATH y LD_LIBRARY_PATH, construyéndose sobre los venv de Python, pero por lo
demás es una aplicación nativa normal y corriente.
Conda tiene mucha tracción en el mundo académico, y en general en áreas donde
la gente trabaja con software pero no son usuarios avanzados de sistemas. Es
decir, no conocen multiples gestores de paquetes, y si lo hacen no quieren
dedicar tiempo a utilizarlos. Conda ofrece una solución que a ojos del usuario
funciona igual, por lo que no tienes que complicarte la vida si el portatil de
tu compañero de laboratorio es un macbook o usa ArchLinux mientras que en el
labo todo es Windows. Lo hace a costa de transferir la complejidad a los
empaquetadores.
De facto, Conda es una distribución que es a su vez tres distribuciones en una.
Es decir, para empaquetar una herramienta nueva en conda, hay que triplicar el
esfuerzo en comparación con lo que supondría empaquetarla sólo para deb, rpm o
msys2.
Por lo tanto, si el objetivo es empaquetarla de forma "nativa" para dos o tres
plataformas, puede merecer la pena invertir el esfuerzo en aprender Conda en
vez afrontar las particularidades de cada entorno y comunidad.
Pero, por otra parte, podemos compilar las herramientas una sola vez para por
ejemplo Debian y meterlas en un contenedor para poder usarlas en "cualquier"
plataforma. La comunidad de empaquetadores de Debian (o la de Fedora, o
ArchLinux) es mucho más madura y numerosa que la de Conda.
Anaconda se lanzó (2012) apenas un año antes de que Docker surgiera (2013).
Tuvieron muy mal timing. Si no hubieran surgido los contenedores, posiblemente
el ecosistema de Conda habría recibido mucha más financiación y cariño. Pero
todos los grandes se pusieron muy en serio con los contenedores, y en apenas
3-4 años se comieron los mercados que mueven dinero, y de ahí en cascada. El
comunicado de Docker hace un par de años (después de vender la división cloud)
de "vamos a volver a centrarnos en los desarrolladores". No exactamente ellos,
pero Microsoft, RedHat, etc. ya han fijado rumbo y estos no paran.
Si los recursos que se destinan al desarrollo de snap, flatpak, appimage y
Conda se unificaran, podría sugir algo que compitiera con los contenedores por
ser más fácil de usar (al no tener que entender que el sistema de ficheros esté
aislado por defecto). Pero no suele ser esa la dinámica del bazar.
Hace un par de años, tuve el placer de conversar con Ray Donnelly
(https://github.com/mingwandroid), un desarrollador de Conda que también era
co-fundador y empaquetador en MSYS2. MSYS2 es un sistema para disponer de una
shell bash y el gestor de paquetes pacman en sistemas Windows, pero generando
binarios nativos de windows. Naturalmente, se nutre mucho de las recipes de
ArchLinux, tanto que se comparan las versiones para no quedarse atrás:
https://packages.msys2.org/outofdate.
Desde 2013 hasta 2020 no creció mucho, pero a partir de 2020 está creciendo
bastante. Ya tiene varios miles de paquetes disponibles.
La idea de Ray era hacer que todos esos paquetes estuvieran disponibles a
través de Conda: https://anaconda.org/msys2/repo.
Por desgracia, el trabajo de Ray se vió ralentizado por el cáncer, y falleció
en 2021.
Es una historia que me resulta muy dolorosa por empatía, pero también muy
didáctica.
Creo que Conda podría crecer si se pudieran reutilizar las recetas de MSYS2
para Windows y las de ArchLinux para Linux; pero objetivamente puede que no sea
razonable el esfuero necesario ya que quienes empaquetan en Conda lo hacen
precisamente para evitar tener que gestionar el empaquetado en otras
plataformas más asentadas.
# Empaquetado y distribución de herramientas open source para EDA
Desde principios de 2022, por las mañanas soy investigador en la UPV/EHU y por
las tardes trabajo de forma remota para Antmicro, una empresa polaca con Google
como uno de los clientes principales. Desde 2019-2020 estoy implicado en varios
proyectos donde participan gente de Antmicro y Google, impulsados por el foco
que ha puesto Google (bueno, cierta gente dentro) para eventualmente dejar de
depender de software no libre (ejem no gratis) para fabricar sus chips.
Los conocimientos y opiniones (naturalmente my own) que estoy exponiendo
proceden principalmente de mi implicación en https://github.com/hdl/, de la que
soy co-creador, "owner" (admin) y mantenedor/desarrollador de varios
repositorios. Los reseñables en este hilo son:
- https://github.com/hdl/packages
- https://github.com/hdl/conda-eda
- https://github.com/hdl/bazel_rules_hdl
- https://github.com/hdl/containers
El "problema" que estamos tratando de resolver es la distribución de
herramientas FLOSS para EDA (tanto simulación, como síntesis e implementación
sea para FPGAs o para ASICs). Para algunos usuarios, las FPGA son el objetivo
final, sobre todo porque tradicionalmente la fabricación de chips era
prohibitivamente cara. Sin embargo, dentro de la estrategia de Google de
"democratizarlo", llevamos varios años con 2-3 tiradas anuales en las que se
fabrican chips gratis siempre que el diseño sea open source:
https://opensource.googleblog.com/2022/10/announcing-globalfoundries-open-mpw-shuttle-program.html.
Por lo tanto, el interés de Google ya ha pivotado hacia los ASICs como
objetivo.
No somos tontos; resulta evidente que a Google le sale más rentable financiar
gente suelta por el mundo siempre que lo que hagan sea Apache (no GPL), y les
interesa fabricar diseños arbitrarios en tecnologías "baratas" (para sus
escalas) para poner a prueba las herramientas.
Como resultado, hoy en día cualquiera de nosotros puede diseñar por ejemplo un
RISC-V utilizando sólo herramientas libres, subirlo a un repositorio y en 6-12
meses tener de vuelta 100-500 chips físicos gratis. En los siguientes enlaces
podéis ver los diseños:
- https://efabless.com/open_shuttle_program
- https://platform.efabless.com/projects/shuttle/11
Si tenéis un mes de tardes libres (ja), o algún estudiante inquieto/a que
quiera hacer un TFG diferente, es gratis y el viaje merece la pena. Hay diseños
complejos, pero también hay pruebas tan sencillas como generar un patrón por
una salida VGA (que son dos contadores anidados y un puñado de comparadores).
No merece la pena complicarse, lo bonito es el camino.
Volviendo al empaquetado y distribución, "las herramientas open source para
EDA" son 40, 60, 100, 150? Cada día crece la lista. No son todas nuevas. La
mayoría han estado debajo de una piedra 10, 15, 20 años, desarrolladas en
silencio y soledad por un tío de Lyon, Kentucky o Dresden. Las recetas eran
inexistentes. Cada uno usaba un Makefile o CMake, o lo que más le gustaba y que
funcionara en su ordenador. Llega Google con su inyección en 2016-2019, y
veinte años de desarrollo de software nos explotan en la cara.
De repente la gente empieza a utilizar todas esas herramientas, a reportar
bugs, pedir características,... Ver por ejemplo
https://github.com/ghdl/ghdl/graphs/contributors. Ese es sólo uno de las
decenas de proyectos, y ese en particular no ha sido financiado y no está en el
radar por ser GPL. Aún así, el efecto de "cualquiera puede fabricar un chip con
herramientas libres" ha tenido un eco muy notable. Naturalmente, hay otros
muchos factores geopolíticos y económicos, como las CHIPS Act en las que andan
EU y EEUU, pero espero se entienda la simplificación. Pero, en esencia,
llevábamos desde finales de los 90 esperando a que la revolución de Linux
llegara a nuestro campo.
Así, la comunidad se enfrentó (y se está enfrentando todavía) a la necesidad de
usar docenas de herramientas que tienen que funcionar de forma coordinada pero
se desarrollan independientemente de forma muy old school, y cada una de ellas
recibe varios commits diarios. Eso es muchísima basura. Es basura para los
desarrolladores, pero también para los usuarios. Si reportan un bug y en 24-48
horas está solucionado, quieren poder usarlo ya. Aunque les evitemos el
esfuerzo de compilar usando CI, tienen que estar instalando y desinstalando
versiones. Conste que es algo invaluable, porque estamos acostumbrados a una
quasi-monopolica industria que cobra miles en licencias e ignora bugs durante
años.
Las distribuciones tradicionales no encajan. Idealmente, todas esas
herramientas estarían empaquetadas de forma canónica en Debian y en Fedora.
Poco a poco, eso se está consiguiendo. Pero tarda años. Aun en el supuesto en
el que los empaquetadores tienen comunicación con los desarrolladores y
cualquiera que quiera hacer un deb o rpm lo haga upstream (que es una quimera),
los procesos de actualización son semestrales o anuales porque la estabilidad y
los tests son importantes en esas distribuciones, y dichos tests suelen incluir
múltiples arquitecturas (amd64, arm, aarch64, s390x, ppc64, riscv...). Arch
tiene un ciclo mucho más corto (immediato), pero se aplica a todo el sistema,
no sólo a las herramientas de la última capa de usuario. Más allá, suficiente
esfuerzo nos sigue constando que los compañeros usen Ubuntu (no Linux). No creo
que Arch pueda ayudar en esos casos.
El primero de los repositorios que he enlazado
(https://github.com/hdl/packages) es un listado de las estrategias por las que
ha optado la comunidad. Desde paquetes para distribuciones tradicionales
(pkgbuild, ebuild, deb, rpm) hasta WebAssembly, desde compilaciones estáticas
hasta bazel. Curiosamente, nadie ha decidido hacer "una distribución".
https://fedoraproject.org/wiki/Electronic_Lab dejó de actualizarse hace una
década. ¿Han cambiado los tiempos? Sí hay iniciativas como
https://copr.fedorainfracloud.org/coprs/rezso/HDL/ o el Electronics Team de
Debian (https://salsa.debian.org/electronics-team).
De todas esas estrategias, la única cercana a estar "completa" (en cuanto a
número de herramientas) es la de Conda. Principalmente porque, que yo sepa, es
la única que ha recibido financiación durante varios años para que hubiera
varias personas dedicándose a ello. El resto de iniciativas son voluntarias y
generalmente con menos gente dedicada. La motivación para crear
github.com/hdl<http://github.com/hdl> en 2019 fue que esas personas al menos se
comunicaran, ya que están enfrentándose a los mismos problemas cada cual en su
entorno.
Se unieron en la organización los contenedores que yo había estado manteniendo
en otro sitio, los repositorios de conda que estaban en litex, se creó el repo
de Bazel, etc.
Fue entonces cuando valoré dejar de mantener/usar los contenedores en favor de
Conda. Pero, por las razones expuestas, me pareció y me parece pan para hoy y
hambre para mañana. Está muy bien que las corporaciones|empresas y los tiempos
modernos tengan aspiraciones que exceden la realidad, pero hacer las cosas de
forma medianamente sostenible require esfuero y tiempo.
# Contenedores, deb, y nix
La estrategia que decidí mantener es https://github.com/hdl/containers. Son una
serie de contenedores que incluyen una o varias herramientas EDA para simular,
sintetizar, programar|ejecutar, etc. Habrá unas cincuenta en total, de las que
unas 30 tienen recetas individuales
(https://hdl.github.io/containers/ToolsAndImages.html). Cada herramienta se
compila por separado y se guarda en un contenedor vacío (scratch), como si
fuera un tarball o un zipfile. Las imágenes que contienen varias herramientas
se "componen" copiando los "paquetes" pre-compilados y añadiendo las
dependencias "runtime" definidas en las recetas.
Empecé, como casi todos al comenzar con contenedores, instalando todas las
herramientas en un solo Dockerfile y tratándolo como una VM. Si necesitaba
varios contenedores con algunas herramientas iguales y otras diferentes,
recompilaba las herramientas. No era óptimo, pero funcionaba. Con el precio que
tienen los megabytes hoy en día, las velocidades de conexión y los multicores,
era pragmático.
Conforme fui conociendo mejor cómo funcionan los contenedores, empezó a
escocerme un poco más. Sí, las horas de pensar de un ingeniero cuestan más que
estar moviendo contenedores de un lado al otro. Pero que podamos gastar
recursos no implica que esté bien desperdiciarlos.
Lo primero que hice fue utilizar una sola imagen base con las dependencias
comunes. Como las imágenes de contenedores funcionan por capas, si cada
herramienta está en una imagen/contenedor diferente pero todas ellas están
basadas en la misma, no hay overhead (ni en espacio en disco, ni en consumo de
red). Para cada herramienta sólo nos descargamos lo que ocupen ella y sus
dependencias.
Decidí utilizar Debian como imagen base (Stretch, Buster, Bullseye).
Valoré Fedora, pero `dnf update` deja mucha más basura que `apt update`, a
pesar de borrar la cache.
Valoré alpine (que estuvo muy de moda), pero musl y ash son (eran) demasiado
esfuerzo para el objetivo.
Valoré Arch, pero quien decidiera diseñar la CLI de `pacman` no tuvo un buen
día.
En realidad, nunca quise desarrollar/mantener esos contenedores per se. Lo hice
primero para mejorar la CI de un proyecto concreto, y después para satisfacer
mis propias necesidades de desarrollo y docencia. Mi intención era
eventualmente escribir recetas deb "correctas" y upstreamearlas de forma que la
única diferencia entre Debian y mis versiones fuera que ellos usen una version
tagged y yo uso master|main.
Con esa idea, en conjunto con la estructura modular y el uso de una base común,
acabé aterrizando en una solución que tiene el siguiente aspecto:
-
https://github.com/hdl/containers/blob/main/debian-bullseye/boolector/Dockerfile
- https://github.com/hdl/containers/blob/main/debian-bullseye/boolector/HDLC
Un Dockerfile genérico con tres stages (compilar, empaquetar, runtime), y una
receta (en realidad más inspirada en PKGBUILD que en la recetas de Debian) que
contiene las dependencias de compilación, las instrucciones y opcionalmente las
dependencias de ejecución. Los diagramas de
https://hdl.github.io/containers/dev/Graphs.html ilustran qué imágenes y
paquetes se generan con qué dockerfiles/recetas y cuáles son las dependencias
de las imágenes que se componen de varias herramientas.
Un proyecto relacionado que mantengo desde 2019 es https://github.com/dbhi/qus,
que utiliza un contenedor de docker para configurar QEMU static en memoria de
forma que puedan ejecutarse otros contenedores de arquitecturas diferentes.
Anecdóticamente, es de "mis" repositorios el que más estrellas tiene, y me
sorprende para qué lo usa la gente (ejecutar Steam en RPi, o todo tipo de
software en M1). Yo lo uso en hdl/containers para compilar las herramientas y
hacer contenedores para aarch64 (y s390x y ppc64 si no me cuesta esfuerzo) en
integración continua (ya que los runners gratuitos de GitHub son x86; GitLab
creo que tiene alguno para ARM) y también de forma local para compilar para
aarch64 sin tener que cambiar los scripts para hacer compilación cruzada.
Otra característica que añadí el año pasado, es hacer explícita la versión de
cada herramienta en el nombre del contenedor (la imagen, se entiende):
https://github.com/hdl/containers/blob/main/debian-bullseye/gtkwave/Dockerfile#L38-L39.
Como en la industria/comunidad hay cierto a apego a CentOS 6 y 7 (cosa que no
acabo de entender), la estructura del repositorio está pensada para varias
"colecciones" de imágenes, siendo una colección todas aquellas que comparten la
misma base (debia, centos, ...).
Todo lo hago con la integración continua gratuita de GitHub (Actions). Las
imagenes las subo a docker.io<http://docker.io>, ghcr.io<http://ghcr.io> y
gcr.io<http://gcr.io>. Los dos primeros también de forma gratuita, y el tercero
con acceso explícito (aunque desconozco si hay servicio gratuito).
Las imágenes de docker permiten hacer variantes de forma que las capas acaban
formando un arbol. Pero no es posible unir (mergear) las ramas para componer
una nueva images. Por eso, para gestionar la compilación y publicación de
varias imágenes, hay un paquete de Python:
https://github.com/hdl/containers/tree/main/utils.
Hay proyectos de terceros que proveen soluciones para utilizar herramientas
nativas o contenedores de forma "transparente" para el usuario:
https://github.com/olofk/edalize/blob/main/scripts/el_docker o
https://github.com/edaa-org/pyEDAA.CLITool/blob/main/pyEDAA/CLITool/Docker.py.
Los que conocéis o habéis leído sobre nix, supongo que estaréis levantando la
ceja. ¿Estoy/estamos reinventando nix? Tengo la sensación de que parcialmente
sí. Desde luego,
https://github.com/hdl/containers/blob/main/debian-bullseye/gtkwave/HDLC se
parece mucho más a
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/electronics/gtkwave/default.nix
que a https://salsa.debian.org/electronics-team/gtkwave/-/tree/master/debian.
# nix para no morir en el intento?
Mantener hdl/containers ya me lleva más tiempo no pagado del que quiero dedicar.
No sé si es que me estoy haciendo mayor, pero como que empieza a resultarme
igual o más gratificante pasear o estar con la familia.
Es un proyecto muy chulo y se podrían hacer muchas mejoras muy divertidas, pero
ya tiene 5 años y hay que decidir qué batallas no se van a poder librar.
Veo muchas similitudes entre lo que nix puede hacer y lo que yo necesito para
mantener un entorno de trabajo basado en contenedores sin tener que desarrollar
yo mismo la infraestructura de compilación.
Parece que utilizan contenedores para aislamiento al compilar los paquetes y
también como base para después instalarlos con el gestor.
Pero me cuesta mucho entender qué no es nix. Parece ser un sistema
(distribución), un gestor de paquetes (que puede usarse en cualquier otro
sistema), un reemplazo para las Dockerfile (que no sé si es el mismo lenguaje
que el de las recetas, o si ese lenguaje tiene algún otro uso), una solución
para usar contenedores ligeros en la nube... Me da la sensación de que intenta
abarcar demasiado en un mismo paraguas. O son genuinamente brillantes, o están
cogiendo uno o varios atajos de los que o no son conscientes o no los están
explicando de forma que yo pueda entenderlo.
Por ejemplo, no quiero instalar nix en un contenedor para después instalar
paquetes con ello. Quiero que nix genere un contenedor con esos paquetes y que
nix no esté instalado en el contenedor.
https://nix.dev/tutorials/building-and-running-docker-images tiene muy buena
pinta, pero no parece posible especificar la imagen base del contenedor. Viendo
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/docker/examples.nix,
sí parece posible especificar cualquier imagen base, pero es un ejemplo de 850
líneas...
Si intento leer https://nixos.org/guides/how-nix-works.html, la segunda frase
me tumba: "This means that it treats packages like values in purely functional
programming languages such as Haskell — they are built by functions that don’t
have side-effects, and they never change after they have been built". Toda la
explicación posterior me suena muy bien, si estuviera buscando un reemplazo
para apt o dnf que pueda gestionar multiples versiones de las
herramientas/librerías, de forma similar a Conda o los venv. Pero no es eso lo
que estoy buscando. Me falta la parte de que una herramienta sea un contenedor
en vez de una carpeta local.
En cuanto a NixOS, me resulta temerario. Jugar con contenedores y aplicaciones
en la carpeta de usuario guay, pero toquetear el sistema base :S. El sistema
puede y debe ser robusto/estable, porque de ello dependen poder jugar con el
resto. Debian hace un muy buen trabajo de filtro paso bajo para tratar de
garantiarlo. Cuestiones como
https://lists.debian.org/debian-devel/2008/12/msg01027.html son las que me
gusta saber que plantea quien desarrolla/mantiene el sistema base.
# Sistemas inmutables
La primera vez que leí sobre el concepto fue por CoreOS. Lo que vagamente
recuerdo es que proponían que todo el sistema operativo estuviera basado en
contenedores. El kernel sólo, y todo, hasta systemd, en contenedores. Era
2014-2015 y me pareció una alucinación, una sobreexcitación con el juguete
nuevo.
Creo que llegué a probarlo porque si no me equivoco el concepto usaba alpine
como base.
Posteriormente, he intentado buscar sobre el concepto varias veces, pero no lo
he encontrado.
En 2018 Red Hat compró CoreOS
(https://www.redhat.com/es/technologies/cloud-computing/openshift/what-was-coreos),
por lo que todo aquello ha acabado en las herramientas y engines de
contenedores de segunda generación. El nombre CoreOS en sí acabó asociado a una
distribución liviana pensada para ejecutarse en VM en la nube, sobre la que
correr contenedores. Pero creo que la idea de que el sistema en si fuera basado
en contenedores no cuajó. En 2020 RedHat abandonó el proyecto, pero sigue
existiendo https://fedoraproject.org/es/coreos/.
Fedora SilverBlue parece ser lo mismo que CoreOS, pero aplicado al escritorio:
https://silverblue.fedoraproject.org/about. Es decir, la "inmutabilidad" se
basa en que el sistema base es tan pequeño que te resulta más fácil borrarlo
todo y bajarte una versión nueva completa, que intentar actualizar el que
tienes. Tratar el sistema base del equipo de escritorio como si fuera el
sistema base de una VM donde lo único que se van a ejecutar son contenedores.
Puede que no consiguieran aislar systemd del sistema base (o que no tuviera
sentido al fin y al cabo) por lo que la solución es que la única diferencia
entre el sistema base y los contenedores sea que el primero tenga systemd "y
poco más".
Pero me pierdo con dónde queda la detección de hardware y los drivers. Entiendo
toda la configuración de escritorio, configuraciones de usuario, aplicaciones,
sistema de ventanas, etc. Entiendo que el kernel es el kernel. Pero, entre
arrancar un kernel de una versión nueva del sistema y acceder/utilizar todas
esas configuraciones, ¿la detección y configuración de hardware? ¿Son sólo
ficheros de configuración también? ¿No hay que descargar contenido al sistema
base que no esté aislado (como sí lo están las aplicaciones) rompiendo la
inmutabilidad? He de decir que tengo un poco de cacao en este sentido porque sé
que NVIDIA permite usar una GPU en un contenedor con unos drivers que estén en
otro contenedor, pero tampoco acabo de entender cómo funciona. Igual SilverBlue
es "casi" inmutable ya ya esta.
A diferencia de NixOS, sí confio en la propuesta de Fedora/CoreOS. Herramientas
como podman han se han nutrido de ese germen, y poder ejecutar contenedores sin
un servicio con permisos de root supuso un punto de inflexión en la viabilidad
de los contenedores donde la seguridad es relevante (aunque creo que sigue sin
ser un sandbox). Fedora tiene un ancho de banda mayor que Debian, y estas
herramientas se han probado ahí.
Pero, a efectos prácticos, utilizo Fedora en el escritorio de la uni y en el
portátil desde el que escribo. En este portátil tengo la misma instalación
desde 2017, y no hay casi basura precisamente porque empecé usando contenedores
aquí.
SilverBlue me propone utilizar flatpak o contenedores en vez de dnf o
contenedores. Yo ya utilizo contenedores principalemente, por lo que flatpak o
dnf para las 4 cosas básicas lo mismo me da.
En tema de hardware y drivers, no veo qué me da.
Lo único que sí me ha hecho pensar es lo de aislar el navegador. Puede que sí
tenga sentido empezar a enjaular Firefox, ya que cada vez más aplicaciones
dependen del navegador.
No obstante, cuando empecé a usar software libre, me resultó muy difícil
cambiar de Windows, Office y Explorer, a Ubuntu, OpenOffice y Firefox.
Lo intenté varias veces y no pude. Al final, lo que hice fue cambiar las
aplicaciones primero. Empecé a usar OpenOffice y Firefox en Windows. Cada ve
que tenía que usar una nueva aplicación, buscaba una alternative libre, en
Windows.
Al cabo de unos años, cuando todas las aplicaciones que usaba/uso eran software
libre, cambié el sistema porque ya lo único que me quedaba por aprender era el
escritorio.
Del mismo modo, para quien no ha utilizado nunca (o poco) venv, snap, appimage,
conda, contenedores, etc. utilizar por ejemplo flatpak en fedora o snap en
ubuntu creo que puede ser didáctico para exponerse al "aislamiento" de las
aplicaciones y datos de forma paulatina y empezar a pensar en terminos de ¿y si
no tuviera que formatear el sistema nunca? ¿y si considerara esa tarea vintage?
# Hipervisores, VMs, LXC, docker|podman
A mayores, CoreOS sí lo veo interesante como sistema base para VMs en sistemas
con hipervisor.
Llevo varios meses utilizando Proxmox en un par de máquinas del laboratorio y
una en casa, y estoy encantado.
Tanto que me planteo usarlo como sistema base en mi equipo principal (cuando
tenga más de cuatro cores), y virtualizar el sistema de escritorio.
Básicamente es Debian con QEMU KVM y una capa de software (en perl) que provee
una GUI web.
Soporta VMs y contenedores LXC, además de opcionalmente backups y agregación de
varios nodos en clusters.
Yo lo uso sólo como gestor de VMs y contenedores por ahora.
En 2-3 días, conseguí crear una VM con Windows 11, otra con Ubuntu,y configurar
una GPU para que la ignore el sistema base y se conecte a una de las VMs.
Llevamos meses utilizándolo intensivamente sin problemas.
En Proxmox, los contenedores que pueden ejecutarse de forma nativa son LXC, no
los OCI (docker|podman).
Por lo tanto, lo más immediato para ejecutar multiples contenedores OCI es
crear una VM y utilizar podman ahí.
En esa VM tiene sentido utilizar CoreOS, en vez de Alpine o Ubuntu Server.
El Debian base no tiene entorno gráfico, por lo que puede hacerse tediosa la
gestión de ficheros.
Si la VM tiene SilverBlue en vez de CoreOS, se puede utilizar nautilus o el
explorador que se desee para organizar el contenido.
Así, de Proxmox me parece interesante poder tener:
- Debian como base.
- Un Windows y un Linux como sistemas principales que pueden o no ejecutarse
concurrentemente.
- Una máquina auxiliar con linux para tener "servicios" (e.g. bittorrent,
jellyfin) ejecutados con contenedores.
- Poder crear o clonar VMs puntualmente para hacer pruebas y después borrarlas,
sin que nada de ello tenga que ver con el escritorio (windows y/o linux).
- Igualmente, poder usar contenedores en VMs temporales.
- Curiosidad por aprender cuáles son las diferencias entre LXC y OCI.
Eso para un sistema con >=6 cores y >=16 GB de RAM no es carga. La VM auxiliar
puede usar 1-2 cores y 2-4 GB, por lo que la principal (que viene a ser el
escritorio) sigue siendo un pepino de al menos cuatro cores y 12 GB.
Es decir, la inmutabilidad en este caso es que el sistema base y el escritorio
no son el mismo. Todas las otras soluciones que estamos comentando presuponen
que el sistema principal es donde están las X (Wayland) y tratan de aislar todo
lo demás. Por mi experiencia, las X (y los drivers de las GPUS, y Wayland) son
una fuente relevante de inestabilidad y/o problemas tras actualizaciones.
Pero soy muy consciente de que roza el límite del pragmatismo. Es una solución
razonable si sé que voy a usar siempre al menos 2 o 3 VMs (o contenedores).
Pero es, de facto, como tener y mantener 2/3 ordenadores (sistemas), cosa que
razonablemente la mayoría de usuarios no quieren hacer. Yo lo veo natural
porque como digo ya utilizo al menos 4 equipos a diario.
La razón por la que no he dado el paso en mi equipo principal aún es porque no
quiero tener dos juegos de teclado y ratón conectados al equipo (uno para el
host y otro para la VM de escritorio). He resuelto que el host utilice uno
monitor y la VM gestione el resto. También que un hub USB vaya a la VM (para
pendrives, discos externos, etc.). Pero todavía tengo que mirar cómo de
complicado y sobre todo reliable es utilizar una combinación de teclas para
cambiar los periféricos de un sistema a otro.
Por la tecnología que usa, creo que Proxmox entra en la categoría de
https://katacontainers.io/ y QubesOS.
karacontainers en vez de ejecutar un contenedor directamente, crea una VM con
QEMU KVM, instala un sistema mínimo y ejecuta el contenedor ahí. Lo hace
mediante el runtime de los contenedores, por lo que esa es la diferencia con
respecto a Proxmox o la utilización explícita de QEMU. El usuario ejecuta los
contenedores usando los mismos comandos que usaría en una instalación de docker
normal, pero por debajo de forma transparente kata hace y destruye la VM.
Anecdóticamente, lo descubrí porque un servidor de la Universidad de Manchester
se comportaba raro con algunos contenedores y resultó ser que el demonio estaba
configurado para usar kata por defecto.
Siempre me ha parecido que es interesante para datacenters donde es importante
el aislamiento entre usuarios.
Pero para mis casos de uso no veo ventaja. Yo no ejecuto nada en contenedores
que no ejecutaría nativamente en el host. No los utilizo para seguridad, sino
como herramienta de empaquetado y distribución de entornos de software
"ready-to-use".
A mayores, cuando katacontainers surgió, podman estaba muy verde. Hoy en día no
sé si podman resuelve ya los problemas que katacontainer intenta atajar
incluyendo QEMU en el stack.
En cuanto a QubesOS, me está haciendo pensar, mucho. No entiendo qué diferencia
hay entre KVM y Xen, pero si la UX es parecida tampoco me importa. Me gusta
mucho que en https://www.qubes-os.org/intro/ haya una GuiVM, una sys-usb VM y
una sys-net VM con el logo de Fedora. Parece que han resuelto que las ventanas
de multiples VMs se muestren en el mismo escritorio
(https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_security_domains.png).
Con Proxmox, cada VM tiene un monitor virtual (en la VM QEMU), al que luego el
host permite acceder por VNC. O, si la máquina es Windows, se puede usar RDP
exponiendo el puerto (o tunelándolo). Por eso, de facto, hace falta varios
monitores si se utilizan GUIs en varias máquinas; o xpra.
Al usar contenedores (docker o podman) el tema de las GUI es algo que suele
echar atrás. Por defecto, no se pueden usar GUIs porque no hay monitor ni
gráfica dentro del contenedor. De las varias soluciones (instalar SSH o VNC
dentro del contenedor, que la GUI sea web y se use con un navegador en el host,
etc.) la que más me gusta es https://github.com/mviereck/x11docker. Como se
indica en https://github.com/mviereck/x11docker#features, el desarrollador
tiene interés notable en la seguridad, por lo que además de permitir ejecutar
GUIs en contenedores usando el escritorio del host, aplica muchas opciones para
limitar el alcance de los contenedores. Como en el desarrollo hardware es
habitual utilizar GUIs, estoy acostumbrado a tener múltiples ventanas en el
escritorio, cada una proveniente de un contenedor. De hecho, así es como uso
varias herramientas de Linux en un escritorio Windows. Hay un GIF/grabación en
https://hdl.github.io/containers/ug/GUI.html. Una referencia obligada es
https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ (nótese la
fecha).
En este sentido, QubesOS parece ofrecer una UX muy similar, pero con VMs en vez
de contenedores.
Me surgen varias dudas:
- ¿Por qué VMs y no podman? Que los qubes se puedan crear sobre Xen o como
contenedores en la AppVM principal.
- ¿Es possible hacer passthrough de discos, GPUs u otros periféricos a una
AppVM con Windows 10|11? Entiendo que la AppVM 1, la principal, no puede ser.
Esa tiene que ser linux (en el diagrama Debian), del mismo modo que el host de
Proxmox es Debian. Que el diagrama muestre el logo de Windows 7 mosquea un poco.
- ¿Cómo de fácil es hacer una VM "tradicional"? Me refiero a una que no esté
integrada en el sistema, como el resto. Sino simplemente asignar número de
CPUs, cantidad de RAM, periféricos (virtuales o físicos) y tratarlo como una
caja cerrada. Si todas las VMs se consideran parte del sistema, entiendo que en
principio no estáran limitadas en cuanto a recursos (en
https://www.qubes-os.org/attachment/doc/r4.0-qubes-manager.png sólo se muestra
el disco), pero para otros servicios auxiliares es importante. De hecho, en
Windows utilizo Docker con HyperV y huyo de WSL2 porque HyperV permite limitar
las cpus y memoria, pero WSL2 no.
Mayo viene cargadito, pero sin duda tomo nota de QubesOS para probarlo en
verano.
Eskerrik asko por sacar el tema, espero que algo de esto te/os resulte
interesante/útil y mesedez comentanos si decides probar alguna!
Salud
Unai
El jue, 20 abr 2023 a las 7:58, Christian Pinedo Zamalloa
(<[email protected]<mailto:[email protected]>>) escribió:
Aupa,
llevo muchos años ya siendo fiel a ArchLinux pero con el tiempo tanto las
rolling release como las distros clásicas basadas en releases se convierten en
un pequeño estercolero con restos de todas las pruebas que has ido realizando,
cambios de configuración, entornos gráficos, lenguajes de programación,
ajustes... Esto me genera dos preocupaciones en el día a día:
1. la estabilidad del sistema operativo
2. la seguridad del sistema operativo
Para (1) haces apaños como btrfs con snapshots. Para (2) actualizas, firewall,
luks, pruebas firejail/bwrap para hacer una "jaula" a firefox y otros...
Pero da la sensación que todo lo complicas más.
En este aspecto las nuevas distros inmutables como Fedora Silverblue/Kinoite,
OpenSUSE MicroOS y VanillaOS parece que son un aire fresco. Tengo un sistema
base "inmutable" al que después de actualizar puedo hacer rollback. Esto mejora
la estabilidad del sistema operativo, tambien la limpieza porque se complica
instalar software nuevo en esa capa base de sistema operativo, la gestión de la
configuración es otro mundo (creo que no la abordan) y te obliga a instalar
aplicaciones con flatpak/appimage/snap/nix o directamente a usar contenedores
con toolbox/distrobox. Creo que es un sistema más complejo pero te obliga a un
workflow en el que el sistema operativo base lo tocas lo mínimo, todo más
limpio. Y creo que mejora la seguridad (menos aplicaciones en el sistema
operativo base, en Fedora Silverblue/Kinoite viene SELinux activado...).
En general es como tener un sistema operativo "hipervisor" "base" que es más
robusto y tocas lo menos posible.
Aqui tambien podría entrar en juego QubesOS que esta muy enfocado a la
seguridad. Pero tiene ese concepto de sistema operativo base hipervisor limpio
y seguro. Y todo tu trabajo lo realizas con Máquinas Virtuales que vas creando
y destruyendo. Ahora bien necesitas un pepinaco de PC en CPU, RAM y SSD/NVMe
para que las aplicaciones se arranquen ligeramente. Y la usabilidad y libertad
esta muy mermada por su forma de uso. Yo con mi thinkpad x250 se me hacia muy
lento...
Por otro lado, estan distros como NixOS y Guix que aqui ya me pierdo. Que deben
tener peculiaridades con esas distros inmutables (Fedora Silverblue/Kinoite,
MicroOS...) pero que no aportan exactamente lo mismo. Me pierdo aqui...
¿Tenéis experiencia con distros inmutables? ¿las recomendais?
¿Alguno ha dado el paso hacia NixOS/Guix? ¿Que aportan? ¿ventajas
inconvenientes? Incluso, aunque solo sea al gestor de paquetes ¿nix?
¿Somos de la vieja escuela y seguimos con Debian, Ubuntu, ArchLinux? :-D
Saludos!
--
Christian
PGP fingerprint: A895 7C11 84F6 30B4 4938 32A4 9306 DFD0 CDE4 B542
_______________________________________________
ITSAS mailing list
[email protected]
http://list.ehu.eus/mailman/listinfo/itsas
_______________________________________________
ITSAS mailing list
[email protected]
http://list.ehu.eus/mailman/listinfo/itsas
