Documento original Publicado el 6 de Febrero de 2019
Ver link a IOHK de Rodney Lorrimar, Ingeniero DevOps
Ver Documento Original aquí.
IOHK tiene un historial de poner en práctica grandes investigaciones. Esto incluye el uso de lenguajes de programación funcionales, la adopción de métodos formales y, por supuesto, la implementación de nuestra propia investigación revisada por pares (peer-reviewed) en algoritmos de consenso de cadenas de bloques (blockchain).
Abordamos el problema de la implementación de software de forma similar, utilizando ideas que han surgido de trabajos académicos recientes. Este sistema aplica los principios de programación funcional al ámbito de la gestión de paquetes de software y de la administración de sistemas.
En este breve artículo técnico describiré cómo utilizamos Nix en IOHK, y compartiré algunos de nuestros planes para el futuro.
¿Qué son Nix, Nixpkgs y NixOS?
NixOS es una distribución Linux construida sobre el gestor de paquete Nix.
Lo que personalmente me gusta del gestor de paquetes Nix es su capacidad de instalar múltiples versiones del mismo paquete, o de aplicar fácilmente una modificación de código fuente a un paquete. Para el desarrollo de Haskell en particular, hay paquetes binarios para un número impresionante de compiladores, herramientas y paquetes Hackage disponibles.
Lo que distingue a NixOS es su sistema de configuración. Incluye una gran colección de módulos de alta calidad que se configuran de forma declarativa y uniforme. Esto es una ventaja para los administradores de sistemas que necesitan aplicar la misma configuración a muchos sistemas o integrar una amplia variedad de software en un solo sistema.
Debajo del gestor de paquetes Nix y NixOS se encuentra el lenguaje Nix - un lenguaje específico de dominio, puramente funcional, evaluado perezosamente (lazily-evaluated) para la configuración e implementación de software.
El artículo NixOS: Una distribución Linux puramente funcional es una excelente introducción. Establece claramente los problemas que NixOS intenta resolver, muchos de los cuales serán familiares para los usuarios técnicos.
¿Quién está detrás del proyecto NixOS?
NixOS fue creado en 2003 en la Universidad de Utrecht como proyecto de investigación de Eelco Dolstra, formando parte principal de su tesis doctoral. Quince años después, el proyecto NixOS se ejecuta en GitHub con cientos de colaboradores involucrados, y la base de código está mejorando a un ritmo de unos 500 git cometidos (commits) por semana.
La comunidad también se comunica a través de un canal activo de IRC en Freenode, un foro de discusión, una conferencia anual (aproximadamente) y reuniones regulares.
Además, varias empresas ofrecen servicios de consultoría Nix, como Tweag I/O y Mayflower.
¿Por qué Nix?
Hay muchos sistemas existentes para la gestión de la configuración de software, algunos con muchos más usuarios que Nix. Sin embargo, creemos que Nix tiene la mejor implementación disponible de `Infraestructura como código’, no sólo en términos de características, sino también en su diseño y potencial.
Si trata su implementación como un programa escrito en un lenguaje funcional, entonces obtendrá las ventajas de la programación funcional como transparencia referencial, reutilización segura de código y la capacidad de probar su implementación en forma unitaria. En su esencia, la’derivación’ de Nix abstrae los detalles y permite que los módulos de software se construyan y usen más o menos de la misma manera, independientemente de su idioma de origen.
Una derivación es una función que toma código fuente, construye herramientas y dependencias de librerías, y produce un paquete de software inmutable; debido a que Nix es puro (en el sentido de programación funcional), si alguna de las entradas cambia, entonces el resultado es un paquete de software diferente. Alternativamente, si una derivación con exactamente las mismas entradas ya ha sido construida en otra parte (por ejemplo, por integración continua (CI)), Nix simplemente descargará ese paquete, en lugar de construir la derivación en sí misma, reduciendo la duplicación del trabajo.
La forma en que Nix calcula si una entrada de derivación ha cambiado es tomando su hash (velocidad a la que una computadora completa una operación ) criptográfico. Las dependencias son recursivas, así que este hash es en realidad un hash de hashes - un concepto poderoso que es reconocido instantáneamente por los entusiastas de las blockchains.
Cómo usamos Nix
Aquí hay algunos ejemplos de cómo estamos usando Nix en IOHK.
1. Despliegue de la red de Cardano SL
(SL =Settlement Layer = Capa de Contabilidad)
Realizamos alrededor de 200 nodos de cálculo en AWS para las diferentes redes de prueba, la red principal de Cardano SL Byron, y el despliegue de la puesta en marcha de Cardano SL (un entorno utilizado para probar las actualizaciones).
Estos son todos los sistemas NixOS desplegados con NixOps.
Hemos escrito una herramienta llamada iohk-ops, que genera una red NixOps a partir de una descripción topológica abstracta. La descripción de la topología describe el número de nodos de retransmisión de Cardano SL, en qué centro de datos están alojados y las rutas estáticas entre pares. iohk-ops llama a NixOps para ejecutar la implementación.
La misma herramienta permite el despliegue de ‘grupos de desarrolladores’ más pequeños que se utilizan para actividades de prueba. Estos clústeres comparten el mismo código de implementación y versiones de software idénticas, pero son más pequeños y pueden iniciarse y detenerse según sea necesario.
Las características de reducción de NixOS y NixOps ya han demostrado ser invaluables varias veces en nuestros despliegues de puesta en escena: toda la red puede ser redesplegada con un sólo comando, o sólo con nodos específicos.
Con NixOps tenemos la capacidad de aplicar ajustes de configuración y parches de código, luego reconstruir en el momento de la implementación, confiando en que el resultado será idéntico a lo que viene de CI, y se puede deshacer sin dejar un lío atrás.
2. Despliegue reproducible
Las medidas extremas, como la modificación del código de tiempo de implementación, no suelen ser necesarias, ya que el entorno de implementación puede reproducirse y probarse localmente, lo que garantiza que cualquier problema se detecte con suficiente antelación.
Como se mencionó anteriormente, una derivación de Nix es una función pura. El código puede ejecutarse localmente con exactamente el mismo entorno y las mismas bibliotecas (hasta el núcleo de Linux) que se utilizan en producción.
3. Rápidas reconstrucciones de imágenes Docker
Los puntos fuertes de Docker incluyen su inmutabilidad, encapsulación y reproducibilidad, rasgos que comparte Nix. Sin embargo, está severamente limitado por su modelo de datos y su DSL restringido.
La estructura de las dependencias de software es un árbol, no una secuencia de capas, tal y como ha sido modelada por Docker. Una molestia típica cuando se construyen imágenes Docker con un archivo Docker es que si cambia una capa cerca de la parte inferior, entonces todo lo anterior debe ser reconstruido. Además, a menos que se tomen medidas para utilizar varias etapas de construcción, los productos intermedios de construcción de capas inferiores se incluirán en la imagen final.
En cambio, un paquete Nix sólo se reconstruirá si sus dependencias (o sus dependencias) han cambiado. El cierre mínimo de un paquete Nix contiene sólo lo necesario para ejecutar ese software.
De esta manera podemos generar imágenes Docker a partir del cierre de las derivaciones de Nix que son mínimas y de rápida reconstrucción. El proceso de construcción también puede ser parametrizado definiéndolo como una función en el lenguaje Nix.
4. Despliegue declarativo de los esclavos (slaves) de construcción de macOS
Para producir los paquetes de instalación de macOS de Daedalus, mantenemos una pequeña colección de sistemas macOS (alojados en MacinCloud). Estos sistemas eran bastante tediosos de mantener hasta que empezamos a usar nix-darwin. Nix-darwin permite la configuración declarativa de sistemas macOS de forma similar a NixOS.
Escribimos un guión para configurar el Mac a través de SSH. Todas las cosas se gestionan a través del código Nix, incluyendo el entorno de construcción, la monitorización y el acceso SSH.
5. Compilación cruzada de Cardano SL para Windows
Para producir los paquetes de instalación de Windows de Daedalus, necesitábamos confiar en las instancias de compilación de recursos limitados de los proveedores de CI, o mantener una pequeña colección de sistemas Windows. La infraestructura de Windows CI ha sido una fuente constante de problemas para nosotros.
Sin embargo, ahora podemos compilar código Haskell para Windows en Linux! La siguiente versión principal de Daedalus para Windows incluirá un cardano-node.exe que fue construido con Nix en Linux.
Debido al tamaño de Cardano SL, esto es todo un logro, y el resultado de varios meses de duro trabajo.
6. Entornos de desarrollo
Con nix-shell, podemos proporcionar entornos de desarrollo que contengan todas las herramientas y librerías necesarias para construir un proyecto, anclado a versiones definidas con precisión.
En cardano-sl, la concha (shell) de Nix soporta tanto el flujo de trabajo de la pila, como el de cabal de nueva construcción con dependencias preconstruidas de Haskell descargadas desde la caché binaria de IOHK.
En el daedalus, la concha Nix proporciona hilo, y un método de funcionamiento de una blockchain de Cardano SL y billetera a nivel local.
Los desarrolladores y usuarios que no están familiarizados con las herramientas de construcción de otros lenguajes como Cabal, Stack (Haskell), NPM, Yarn (Javascript), o Cargo (Rust), todavía pueden reconstruir (o descargar una construcción en caché desde CI), simplemente ejecutando nix build.
Existen otras herramientas para proporcionar entornos de desarrollo reproducibles, como Apache Maven o Docker, pero no son fáciles de componer. Debido a que Nix es un lenguaje funcional, los entornos de desarrollo son la aplicación de funciones que pueden ser compuestas. Así que con Nix puedes escribir una función que combine entornos de desarrollo, o sólo las partes que necesites.
Orientaciones futuras
2019 será un año emocionante para IOHK, con varios proyectos ambiciosos en preparación. Anticipamos que Nix jugará un papel importante en el éxito de estos proyectos. Algunas de las cosas que hemos planeado son:
Construcción Daedalus Pura
Actualmente construimos los instaladores de Daedalus para Windows y macOS usando un script de Haskell. Esto es más lento de lo necesario y necesita ejecutarse en un sistema Windows o MacOS: preferiríamos construir sobre Linux con Nix para que los componentes de software puedan ser almacenados en caché según sea necesario.
iohk-nix
IOHK está dividiendo la base de código de Cardano SL en módulos independientes, que deben ser integrados en la construcción del producto final. Hemos iniciado un repositorio de código Nix iohk-nix común que puede ser reutilizado por cada subproyecto de Cardano SL.
Como con todos los idiomas, el código Nix puede ser escrito de una manera hermosa o horrible - y como Nix no tiene un sistema de tipo estático, el código horrible es realmente malo. Así que parte de este proyecto será un esfuerzo para mejorar la legibilidad y documentación de nuestro código Nix para que sea fácil de entender y mantener.
Herramientas para desplegar un nodo o un pool de participación (stake pool)
En 2019, Cardano SL será descentralizada. Nos gustaría hacer que sea súper fácil para los usuarios técnicos desplegar uno o más nodos de Cardano SL, u operar un stake pool.
Esto incluirá:
-
Alisar las esquinas ásperas de los iohk-ops para que estén listos para el uso público.
-
Proporcionar una variedad de opciones de construcción como imágenes Docker o ejecutables totalmente enlazados estáticamente.
-
Utilizar las herramientas disponibles en NixOS para proporcionar una configuración de monitorización llave en mano para todas las métricas necesarias a nivel de aplicación.
nix-tools Haskell Builder
La infraestructura de construcción de Nix Haskell requería de una revisión significativa para poder compilar Haskell de forma cruzada con Windows, principalmente para rastrear más información sobre las banderas y dependencias del compilador.
El resultado es un constructor Haskell más potente, y una nueva implementación de stack2nix que corre más rápido, entre otras cosas. Esta infraestructura de Haskell se llama nix-tools. Nuestro objetivo es rellenar las partes que faltan y enviarlas a Nixpkgs el año que viene.
Este tema es tan interesante que merece su propia entrada en el blog, que esperamos publicarlo pronto.
Conclusión
Este fue un rápido repaso de cómo usamos Nix para ayudar a desarrollar e implementar Cardano.
No todo es excelente, por supuesto. Los usuarios encuentran que Nix tiene una curva de aprendizaje empinada, y que la comunidad es relativamente pequeña. También tenemos nuestra propia lista de deseos de características y correcciones de errores para Nix que aún no han sido implementadas.
Si está interesado en aprender más sobre Nix, visite el sitio web de NixOS. Si te gusta la codificación o la administración de sistemas, es muy fácil empezar a contribuir al proyecto NixOS. Toma un poco de tiempo orientarse con el lenguaje Nix, pero entonces encontrarás que casi todo lo que necesitas saber está en un solo repositorio git.
En IOHK contribuimos regularmente al proyecto NixOS. Estas contribuciones incluyen mejoras a los paquetes y módulos de NixOS, y la contratación de desarrolladores para hacer mejoras más grandes. Además, simplemente utilizando NixOS a gran escala en proyectos de investigación y comerciales, contribuimos al ecosistema - publicando nuestro código fuente bajo una licencia libre, enviando informes de errores o compartiendo nuestras experiencias con la comunidad.
Estamos contratando
El equipo de IOHK está creciendo, y estamos buscando a las personas adecuadas para unirse a nosotros. Si ayudarle a desarrollar una plataforma de blockchain más avanzada que cualquier otra es algo que le interesa, entonces revise nuestros listados de empleos y póngase en contacto con nosotros.
Material gráfico, Mike Beeple