Contenidors Linux per a entorns de ciència i enginyeria

Texto completo

(1)Contenidors Linux per a entorns de Ciència i Enginyeria Àngel Linares Zapater Enginyeria Informàtica, 2n. cicle Administració de Xarxes i Sistemes Operatius Eduard Marco Galindo Pierre Bourdin 7 de Juny de 2017.

(2) GNU Free Documentation License (GNU FDL) Copyright © 2017 Àngel Linares Zapater Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License"..

(3) FITXA DEL TREBALL FINAL Títol del treball:. Contenidors Linux per a entorns de Ciència i Enginyeria. Nom de l’autor: Àngel Linares Zapater Nom del consultor/a: Eduard Marco Galindo Nom del PRA: Pierre Bourdin Data de lliurament (mm/aaaa): 06/2017 Titulació o programa: Enginyeria Informàtica, 2n. cicle Àrea del Treball Final: Administració de xarxes i sistemes operatius Idioma del treball: Català Paraules clau Linux, containers, scientific computing Resum del Treball: Tot i que el concepte de contenidor existeix des de fa molt temps en diferents sistemes operatius (Solaris zones, AIX WPARs, BSD jails, Linux containers, etc.), i s’ha emprat com a mètode per a aïllar diferents entorns concurrents en un mateix computador, ha estat la seva utilització recent com a tècnica de desplegament conjunt d’aplicacions i les seves llibreries el que ha popularitzat el seu ús entre els enginyers de software i els de sistemes. Per altra banda, en el comunitat científica i tècnica, on els treballs estan cada cop més basats en mètodes computacionals (càlcul numèric, processament de dades, etc.), el concepte de reproductibilitat dels resultats numèrics per tercers està esdevenint cada cop més important per tal de validar els experiments computacionals i els resultats obtinguts. L’aplicació del contenidors en entorns científics i tècnics podria esdevenir una pràctica potencialment important, tant per al desenvolupament i desplegament dels experiments numèrics i les solucions desenvolupades com per a facilitar la reproducció del seus resultats en entorns informàtics de tercers. En aquest treball s’analitzen les característiques principals dels entorns informàtics per al treball científic i tècnic en l’àmbit del desenvolupament d’aplicacions i experiments computacionals en general, i en l’aspecte de la reproducció d’aquests resultats per tercers en particular. Per a validar les solucions disponibles basades en contenidors es dissenya i implanta un cas pràctic d’un entorn representatiu i s’hi apliquen algunes d’aquestes solucions de contenidors Linux per a poder valorar la idoneïtat del seu ús en aquest tipus d’entorns. Es pot comprovar que els contenidors Linux faciliten els treballs del cicle de la producció i la distribució de soluciones científiques i d’enginyeria i que poden ajudar a millorar la reproductibilitat computacional.. i.

(4) Abstract: Although the concept of container can be found, since long time ago, in different operating systems (Solaris zones, AIX WPAR, Jail BSD, Linux containers, etc.), and has been used as a method to isolate different concurrent environments in a single computer, it has been its use as a recent technique for joint deployment of applications and their libraries what has popularized its use among software and systems engineers. On the other side, in the scientific and technical community, where tasks are increasingly based on computational methods (numerical computation, data processing, etc.), the concept of reproducibility of the numerical results by third parties is becoming increasingly important in order to validate the computational experiments and its results. The application of containers in scientific and technical environments could potentially become an important practice for both the development and deployment of numerical experiments and developed solutions, and to facilitate the reproduction of results in third party environments. This document analyzes the main characteristics of scientific and technical environments, when Linux containers are used, in the development of applications and computational experiments in general, and in the aspect of reproduction of these results by third parties in particular. In order to validate the available, based on containers solutions a design and implementation is done for a case study of a representative environment and some of these Linux containers solutions are then applied to assess the appropriateness of its use in such environments. It can be shown that Linux containers facilitate the work cycle of production and distribution of scientific and engineering solutions and can help in improving the reproducibility of computational results.. ii.

(5) Índex 1 Introducció......................................................................................................1 1.1 Context i justificació del Treball...................................................................1 1.2 Objectius del Treball....................................................................................2 1.3 Enfocament i mètode seguit........................................................................2 1.4 Planificació del Treball.................................................................................3 1.4.1 Descomposició del Treball...................................................................3 1.5 Restriccions del projecte.............................................................................4 1.5.1 Restriccions tecnològiques..................................................................4 1.5.2 Restriccions culturals...........................................................................4 1.6 Planificació temporal...................................................................................4 1.6.1 Riscos en el calendari..........................................................................5 1.6.2 Diagrama de Gantt...............................................................................5 1.7 Breu sumari de productes obtinguts............................................................7 1.8 Breu descripció dels altres capítols de la memòria.....................................7 2 Estudi Teòric...................................................................................................8 2.1 Estudi de Necessitats..................................................................................8 2.1.1 Caracterització dels entorns STEM.....................................................8 2.1.2 Identificació dels actors i els rols.........................................................9 2.1.3 Selecció dels rols característics.........................................................12 2.1.4 Les necessitats generals dels entorns STEM....................................13 2.1.5 Les necessitats particulars dels entorns STEM.................................14 2.1.6 Necessitats particulars dels «desenvolupadors»...............................15 2.1.7 Necessitats particulars dels «administradors»..................................18 2.1.8 Necessitats particulars dels «autors»................................................21 2.1.9 Necessitats particulars dels «revisors».............................................23 2.2 Estudi de Solucions amb Contenidors......................................................25 2.2.1 Solucions basades en el propi sistema.............................................25 2.2.2 Solucions basades en màquines virtuals...........................................26 2.2.3 Solucions basades en contenidors....................................................27 2.2.4 Anàlisi de les alternatives basades en contenidors...........................29 2.2.5 Comparativa de les solucions alternatives........................................35 3 Aplicació Pràctica.........................................................................................37 3.1 Disseny d’un Cas Representatiu...............................................................37 3.1.1 Definició d’un cas representatiu.........................................................37 3.1.2 Selecció d’una alternativa basada en contenidors............................38 3.1.3 Disseny de l’aplicació pràctica...........................................................39 3.2 Implantació del Cas...................................................................................41 3.2.1 Estació de treball Debian amb Docker..............................................41 3.2.2 Contenidors Docker per a alternar compiladors................................46 3.2.3 Contenidors Docker per a alternar llibreries......................................55 3.2.4 Contenidors Docker per a alternar aplicacions..................................60 3.2.5 Contenidors Docker per a execucions en paral·lel............................64 3.2.6 Servidor Ubuntu compartit amb LXC/LXD.........................................67 3.2.7 Repositori públic.................................................................................76 3.2.8 Ús de contenidors Docker en Linux...................................................81 3.2.9 Ús de contenidors Docker en Windows.............................................83 3.2.1 0Ús de contenidors Docker en macOS.............................................86 4 Anàlisi dels Resultats...................................................................................89 4.1 Anàlisi del cas particular............................................................................89 iii.

(6) 4.1.1 Resultats del cas................................................................................89 4.1.2 Valoració econòmica..........................................................................90 4.2 Anàlisi del cas general...............................................................................91 4.2.1 Valoració de les solucions basades en contenidors..........................91 4.2.2 Aplicació dels contenidors a la reproductibilitat.................................92 5 Conclusions..................................................................................................93 5.1.1 El treball realitzat................................................................................93 5.1.2 El treball futur.....................................................................................94 6 Glossari..........................................................................................................95 7 Bibliografia....................................................................................................96 7.1 Llibres i articles acadèmics.......................................................................96 7.2 Recursos multimèdia a Internet.................................................................96 8 Annexos.........................................................................................................98 8.1 GNU Free Documentation License...........................................................98. iv.

(7) Llista de figures 1 Estructura de descomposició del treball...........................................................3 2 Diagrama de Gantt de la planificació inicial.....................................................6 3 MATLAB i Octave (en un contenidor) executant simultàniament el mateix codi font..........................................................................................................63 4 El contenidor publicat apareix en una cerca pública a DockerHub................80. v.

(8) Contenidors Linux per a entorns de Ciència i Enginyeria. 1 Introducció 1.1 Context i justificació del Treball Els contenidors Linux han rebut en els darrers anys un impuls important en els entorns de desenvolupament de software i en els processos de desplegament associats, especialment des de l’aparició, popularització i amplia disponibilitat d’eines multiplataforma com ara Docker que faciliten enormement la seva utilització. De fet, el concepte de contenidor (container) existeix des de fa força temps i ha estat implantant amb èxit en diferents sistemes operatius (Solaris zones, AIX WPARs, BSD jails, Linux containers etc.) com una tècnica fonamental per a organitzar i aïllar diferents entorns d’execució concurrents en un mateix computador. Ha estat, però, la seva utilització recent com a tècnica de desplegament de les aplicacions conjuntament amb les seves llibreries associades, sobretot en entorns d’informàtica en núvol, que ha popularitzat el seu ús entre els enginyers de software i els de sistemes. Per altra banda, en el comunitat científica i tècnica, on els treballs estan cada cop més basats en mètodes computacionals (des del càlcul numèric i les simulacions al tractament estadístic de grans volums de dades, etc.), el concepte de reproductibilitat (reproducibility) dels resultats està esdevenint cada cop més un requisit important per a seguir complint amb un principi bàsic del mètode científic com és la repetició dels experiments de forma independent [Nat2016a]. L’aplicació de la tecnologia de contenidors en entorns científics i tècnics, l’àmbit anomenat STEM (science, technology, engineering and mathematics), seguint el camí iniciat en els entorns de desenvolupament de software i el desplegament conjunt d’aplicacions i llibreries, pot esdevenir una pràctica important. Tot i que les diferents aplicacions dels ordinadors als problemes científics i tècnics són molt diverses, moltes d’aquestes aplicacions es podrien beneficiar fàcilment de la tècnica de contenidors. Tant pel que fa al desenvolupament en estacions de treball dels experiments numèrics i el seu posterior desplegament en els centres de càlcul propis o aliens, com per a facilitar la distribució i reproducció d’aquests experiments en entorns informàtics de tercers que puguin validar els resultats, la tecnologia dels contenidors podria ajudar en aquest repte. A més, les branques computacionals de les ciències adquireixen, cada cop més, una importància similar a les branques experimentals, p.e. per a simular determinats experiments que serien impossibles de realitzar en un laboratori. I en l’àmbit de les aplicacions comercials, que es basen en algorismes cada cop 1.

(9) Contenidors Linux per a entorns de Ciència i Enginyeria. més sofisticats (molts cops sense que es pugui comprendre amb detall com els models generen les seves decisions finals, p.e. en el cas de les xarxes neuronals [Mit2016a]), només serà possible validar la seva idoneïtat general per la via de la replicació per tercers en entorns independents. És en aquesta direcció que pren sentit analitzar com aquesta tecnologia de virtualització mitjançant contenidors que s’ha popularitzat recentment, especialment degut al fenomen Docker, pot tenir un ús efectiu en els entorns de ciència i enginyeria, tot validant-ne la seva utilitat mitjançant una aplicació pràctica en un entorn d’avaluació representatiu.. 1.2 Objectius del Treball La finalitat d’aquest treball es estudiar l’aplicació dels contenidors Linux als entorns STEM i, addicionalment, la viabilitat de l’ús d’aquesta tecnologia com una eina que pugui proporcionar o millorar la desitjada reproductibilitat de resultats computacionals. Aquest objectiu principal es compon dels següents objectius parcials: •. Identificar la casuística principal per a l’administració d’un entorn informàtic de caire científic o tècnic.. •. Comparar les alternatives de software lliure basades en contenidors Linux, tot analitzant la seva aplicabilitat a la casuística de l’entorn STEM.. •. Definir un cas particular que pugui ser representatiu. Dissenyar i construir en entorn informàtic d’avaluació de la solució elegida aplicada al cas representatiu.. •. Implantar una solució pràctica per a poder analitzar i extreure conclusions, a partir de la seva aplicació al cas representatiu prèviament definit.. •. Valorar la viabilitat dels contenidors com a eina per a facilitar la feina STEM i millorar la reproductibilitat d’experiments computacionals.. 1.3 Enfocament i mètode seguit La finalitat del projecte és fonamentalment de naturalesa qualitativa, en estudiar el paper que poden tenir les solucions de contenidors Linux per a entorns STEM. Malgrat això, es dissenyarà i implantarà una aplicació pràctica que demostri els conceptes analitzats i l’aplicació d’alguna de les solucions alternatives analitzades. Això ha de permetre fer aquesta validació tècnica de la solució elegida quan s’aplica en aquests entorns, així com una anàlisi mes quantitativa, si s’escau, d’aquesta aplicació concreta. 2.

(10) Contenidors Linux per a entorns de Ciència i Enginyeria. De l’anàlisi dels resultats en el cas particular, que haurà de ser mínimament representatiu, es podran extrapolar conclusions al cas general, si més no de forma qualitativa.. 1.4 Planificació del Treball 1.4.1 Descomposició del Treball El treball total a desenvolupar en el projecte es pot descompondre en 3 blocs de treball: l’Estudi Teòric, l’Aplicació Practica i l’Anàlisi de Resultats, organitzats segons es mostra en la següent figura i descrits a continuació:. Figura 1: Estructura de descomposició del treball. Un Estudi Teòric, que es compondrà de dues parts diferenciades: •. Una anàlisi de les necessitats pròpies dels entorns STEM i les seves casuístiques principals, identificant els actors involucrats com ara els enginyers i científics que han de desenvolupar aplicacions o també els administradors del sistema que han de donar suport.. •. La identificació, anàlisi i comparativa de diverses alternatives de solucions de software lliure que, utilitzant tecnologies de contenidors, siguin d’aplicació a les necessitats anteriorment detectades, com LXC/LXD, Docker o CoreOS/rkt.. Una Aplicació Practica, a partir de l’estudi anterior, per a obtenir resultats concrets per a la seva posterior anàlisi i valoració, tot fent:. 3.

(11) Contenidors Linux per a entorns de Ciència i Enginyeria. •. Primer, una definició d’un cas particular que sigui prou representatiu dels entorns STEM, per a elegir-ne una alternativa, i un disseny detallat de la seva aplicació.. •. Segon, la implantació de la solució elegida entre les alternatives abans estudiades. Per a dur a terme això, serà necessari: ◦ construir un entorn d’avaluació que representi l’entorn en estudi ◦ implantar en aquest entorn els casos amb les solucions basades en contenidors elegides. Una Anàlisi de Resultats, basada en l’aplicació pràctica anterior, formada:. •. Per una anàlisi i valoració dels resultats i de l’aplicació de la solució al cas particular.. •. Una valoració dels resultats extrapolats, en la mesura del possible, al cas general.. 1.5 Restriccions del projecte 1.5.1 Restriccions tecnològiques •. El sistema operatiu de treball en l’entorn d’avaluació haurà de ser una distribució Linux.. •. Les alternatives de solucions basades en contenidors que s’analitzaran hauran de ser de codi obert.. •. Al menys s’inclouran en l’anàlisi d’alternatives els productes Docker, LXC/LXD i CoreOS/rkt que són les més populars en sistemes Linux.. 1.5.2 Restriccions culturals •. La Memòria del projecte, la Presentació, així com la resta de qüestions acadèmiques relacionades amb el treball, es faran en català.. •. El codi font informàtic dels lliurables intermedis (incloent els seus comentaris) que s’hagin de desenvolupar en l’aplicació pràctica i la documentació tècnica associada es farà en anglès.. 1.6 Planificació temporal El calendari detallat mostra la seqüenciació temporal de les tasques planificades en les fases d’Estudi Tècnic, Aplicació Pràctica i Anàlisi de Resultats en que s’executa el projecte.. 4.

(12) Contenidors Linux per a entorns de Ciència i Enginyeria. La càrrega de treball planificada durant aquestes fases és de 16 hores setmanals, d’acord amb els 9 crèdits ECTS del Pla Docent, que representa un total de 224 hores de treball. No es mostren en el diagrama de Gantt la resta de tasques acadèmiques associades al Projecte de Final de Carrera, com ara la preparació de la Presentació o la discussió posterior amb el Tribunal. Les principals fites del projecte es mostren en relació amb les fites acadèmiques en la següent taula: Setmana. Activitat. 1. 27 feb. - 5 mar. Definició de la Proposta. 2. 6 mar. - 12 mar. Estudi de les necessitats. 3. 13 mar. - 19 mar. Estudi d’alternatives. 4. 20 mar. - 26 mar.. 5 6. 3 abr. - 9 abr. 10 abr. - 16 abr. Creació de l’entorn d’avaluació. 8. 17 abr. - 23 abr.. 9. 24 abr. - 30 abr. Implantació de la solució. 11. Memòria: Estudi Teòric. 1 mai. - 7 mai. 8 mai. - 14 mai. Anàlisi de resultats. 12. 15 mai. - 21 mai.. 13. 22 mai. - 28 mai. Revisió final de la memòria. Memòria: Aplicació Pràctica. 14. 29 mai. - 4 jun. Preparació de la presentació. 15. 5 jun. - 11 jun. Entrega del PFC. 16. Pla de Treball. 27 mar. - 2 abr. Disseny del cas particular representatiu. 7. 10. Memòria. Memòria final Presentació. 12 jun. - 18 jun. Debat. 1.6.1 Riscos en el calendari Per la naturalesa de les activitats a realitzar l’ordenació de les tasques és força seqüencial, la qual cosa significa que totes les tasques formen part del camí crític. Existeix doncs el risc, a l’estar la data final fixada, que qualsevol retràs en alguna activitat pugui afectar el resultat final. Per a gestionar aquest risc, la col·lecció de casos d’ús a implantar en l’aplicació pràctica es mantindrà prou flexible per així permetre afegir o treure casos i poder respondre a les desviacions que puguin aparèixer, sense afectar però a l’estructura i finalitat del treball.. 1.6.2 Diagrama de Gantt El Diagrama de Gantt corresponent a les fases d’execució del treball es mostra en la següent imatge:. 5.

(13) Contenidors Linux per a entorns de Ciència i Enginyeria. Figura 2: Diagrama de Gantt de la planificació inicial. 6.

(14) Contenidors Linux per a entorns de Ciència i Enginyeria. 1.7 Breu sumari de productes obtinguts El treball del projecte no genera un lliurable principal, com ara un aplicació o un sistema instal·lat. Amb tot, es produeixen un seguit de lliurables intermedis que poden tenir el seu valor en el context adient. Especialment rellevant és la col·lecció dels principals casos d’ús particulars dels entorns STEM, en forma d’històries d’usuari, que són la base de treball per a l’avaluació de les solucions basades en contenidors en el cas pràctic desenvolupat.. 1.8 Breu descripció dels altres capítols de la memòria El cos de la Memòria s’organitza seguint les etapes de l’execució del projecte. En el següent capítol s’analitzen les necessitats dels entorn STEM i les possibles alternatives basades en contenidors aplicables, tot comparant-ne les seves característiques. Un capítol a continuació descriu una aplicació pràctica dels contenidors a un cas particular que pugui ser representatiu d’un entorn STEM. Finalment es dedica un capítol apart a la valoració dels resultats i les conclusions finals del projecte.. 7.

(15) Contenidors Linux per a entorns de Ciència i Enginyeria. 2 Estudi Teòric 2.1 Estudi de Necessitats 2.1.1 Caracterització dels entorns STEM En l’àmbit de la Ciència i l’Enginyeria, els ordinadors han jugat un paper molt important ja des de les seves primeres implantacions realment operatives a finals de la primera meitat del segle XX. El seu ús s’ha estès fins a tal punt que és difícil imaginar un projecte científic o tecnològic sense la participació dels ordinadors. Entre la diversitat d’usos i necessitats que hi podem trobar en un entorn STEM, n’hi ha per una banda aquells que són comuns a altres àmbits, com ara l’ús dels ordinadors per a crear documentació o per a comunicar-se per correu electrònic a Internet, i n’hi ha també aquells més propis d’aquests entorns cientificotècnics com poden ser el càlcul numèric, les simulacions, la recopilació i tractament de grans volums de dades i de sèries temporals (p.e. de sensors), etc. Per altra banda, els entorns STEM poden també ser molt diversos sigui en mida i sigui en complexitat. Així es pot trobar des de l’escenari de l’investigador individual fins als grans laboratoris científics amb xarxes distribuïdes a escala global. Classificació dels entorns Per tal de poder fer un estudi de les necessitats dels participants en aquests entorns, elegirem com un primer classificador dels entorns STEM la dimensió de la xarxa d’ordinadors i el nombre d’actors implicats en el projecte. Atenent aquest criteri, podem definir tres tipus d’entorns, que anomenarem: •. l’entorn STEM individual: característic d’un ús personal del sistema informàtic per part del científic/a o enginyer/a, per exemple, per a fer recerca matemàtica amb càlcul simbòlic, per a la resolució d’un problema numèric concret en enginyeria, per a la simulació d’un ambient biològic, etc. treballant de forma individual.. •. l’entorn STEM d’equip: resultat de la necessitat de compartir dades, algorismes i resultats entre membres d’un mateix equip en un projecte de més gran abast que l’individual. En aquest entorn també hi ha, a més, la necessitat de compartir els recursos informàtics comuns disponibles en la xarxa d’ordinadors, o fins i tot els servidors de càlcul numèric en un centre de càlcul.. 8.

(16) Contenidors Linux per a entorns de Ciència i Enginyeria. •. l’entorn STEM obert: propi dels projectes, siguin individuals o d’equip, que faran una distribució de les seves solucions d’enginyeria o dels seus resultats científics, que es proporcionaran a terceres pel seu ús o la seva revisió.. Com és evident, els entorns STEM reals són una combinació d’aquestes classes ideals. En cada moment, i segons la perspectiva adoptada, aquests entorns reals poden presentar les característiques d’uns o altres entorns ideals. Aquesta classificació servirà, però, per a poder fer un estudi més sistemàtic dels participants i els implicats en aquests entorns i per tant per a la comprensió de les seves necessitats i els rols que s’hi desenvolupen. Per a enfocar l’anàlisi i centrar l’abast, en la resta del treball no tindrem en compte aquelles necessitats en entorns STEM que poden ser comunes amb altres més entorns més genèrics1. Així no tindrem en compte, entre d’altres necessitats: •. disposar d’eines per a la redacció de textos, documentació, presentacions, etc. conegudes habitualment com eines d’ofimàtica, ni tampoc les solucions de tipografia científica com ara LaTex.. •. l’ús i accés genèric a internet amb navegadors, aplicacions de correu electrònic, etc. Tampoc l’administració i gestió genèrica de servidors web o de correu electrònic.. •. la instal·lació de maquinari i dels sistemes operatius per a l’equip del projecte que són de propòsit general, com ara impressores compartides, emmagatzemament per a ús personal o per a còpies de seguretat, etc. (La instal·lació i configuració dels runtimes de contenidors en el sistema operatiu o del software i llibreries científiques pròpies de l’entorn sí que són objecte d’estudi).. 2.1.2 Identificació dels actors i els rols El nombre d’actors implicats en els entorns STEM pot variar molt: des de la persona que fa un treball estrictament individual fins a agrupacions d’equips en institucions arreu del mon. En qualsevol cas aquests actors assumiran diferents rols, sigui com a usuaris sigui com a administradors de les xarxes i sistemes involucrats. Deixant de banda, com hem dit, els rols d’usuari genèric d’ordinador i també el d’administrador de la xarxa, comuns a altres entorns genèrics, i atenent a la classificació plantejada en el punt anterior es poden identificar els següents actors i els seus diferents rols.. 1. Per a un exemple d’ús individual però genèric d’eines en entorn STEM veure [Kit2013a]. 9.

(17) Contenidors Linux per a entorns de Ciència i Enginyeria. Entorn STEM individual L’entorn individual es caracteritza per una sola persona que fa un treball cientificotècnic, però que a la vegada realitza personalment les tasques d’administració i configuració del seu sistema. Estem davant del científic o enginyer que programa aplicacions com part de la seva recerca o desenvolupament i que es configura l’ordinador personal per a aquestes tasques. Aquest individu assumeix tres rols addicionals als genèrics respecte al seu sistema informàtic, que anomenarem: •. desenvolupador: entès en el sentit més ampli del terme per incloure tasques des de la concepció del model, a l’anàlisi i el disseny i la programació i prova de l’aplicació. En qualsevol cas, el resultat final és que es genera un codi font que es traduirà a codi objecte per a la seva utilització executant-lo en el mateix o en un altre ordinador.. •. administrador: qui apart de les tasques comunes amb qualsevol administrador de sistemes (instal·lació del SO, configuració de la xarxa, etc) necessita instal·lar en el sistema operatiu les aplicacions, compiladors i intèrprets, així com llibreries i entorns de treball, que són propis i necessaris del seu àmbit de treball científic o tècnic.. •. revisor: com a científic o enginyer especialitzat en el seu propi àmbit de coneixement, la mateixa persona s’encarrega de comprovar i revisar els resultats que s’obtenen de la seva solució prèviament desenvolupada.. El rol del desenvolupador no es restringeix només al codificador de programes en llenguatges de programació com C, Java o Python sinó que s’estén a llenguatges específics de domini com MATLAB, R o SPSS i a la programació d’aplicacions i entorns com SPICE o SeSam. En tots els casos existeix un codi font que es desenvolupa i després de ser processat genera uns resultats concrets sobre el problema en estudi. Cal observar també que el rol d’usuari d’una aplicació d’enginyeria, com ara un sistema CAD/CAM, queda fora de l‘estudi doncs es pot considerar un usuari genèric com ho seria un usuari d’una aplicació d’edició de vídeo o un usuari d’un simulador d’un sistema logístic en altres àmbits. Entorn STEM d’equip L’entorn d’equip es caracteritza per un conjunt de persones que col·laboren en un projecte científic o tècnic usant un sistema informàtic compartit. Aquest escenari inclou des del petit equip de dos o tres enginyers o científics fins als equips multidisciplinaris en grans laboratoris, centres de recerca o en els departaments de desenvolupament en empreses i organismes.. 10.

(18) Contenidors Linux per a entorns de Ciència i Enginyeria. En aquesta classe d’entorns es pot observar que els actors involucrats poden, o bé assumir diferents rols vers el sistema, o bé algunes d’aquestes persones en l’equip s’especialitzen en unes tasques determinades. Podem identificar, però, els mateixos rols que en l’entorn individual malgrat que tant la quantitat com la qualitat de les tasques realitzades per cada persona poden ser diferents en cadascun dels aspectes. Així, s’identifiquen els següents rols: •. desenvolupadors: de nou entès en el sentit més ampli del terme incloent tots els rols possibles en l’àmbit del desenvolupament de software: analistes, programadors, provadors, etc. En aquest cas més d’un desenvolupador poden treballar de forma coordinada. Només ens interessen les seves necessitats en les vessants tècniques o científiques, i no considerarem d’altres més propis del àmbit del desenvolupament de programar com els repositoris de codi, els sistemes de control de versions, etc... •. administradors: que han de proporcionar als desenvolupadors i revisors el programari especialitzat del seu domini: compiladors i intèrprets, llibreries a entorns de treball específics, etc. Quan el rol correspon a una persona especialitzada ho haurà de fer de forma més professionalitzada i automatitzada que en l’entorn individual degut al major nombre de recursos compartits a administrar com servidors de càlcul, d’emmagatzemament, etc. pel conjunt dels membres de l’equip.. •. revisors: que han de fer una feina especialitzada de revisió i validació del funcionament de la solució desenvolupada per altres rols i des resultats obtinguts però des de la perspectiva cientificotècnica del seu àmbit i no del estricte desenvolupament de codi.. Entorn STEM obert Un cop es traspassa l’àmbit de l’equip que, per gran que sigui, fa un treball principalment enfocat a proporcionar resultats d’ús intern, sorgeix la necessitat de que aquest treball i els seus resultats es puguin comunicar de forma oberta a tercers. En aquest escenari més ampli direm que estem en un entorn STEM obert. La característica fonamental de l’entorn obert és la presència una part aliena a l’individu o l’equip: els tercers. En aquest entorn les dues parts, equip intern i tercers, operen sota el paradigma de productor/consumidor. L’equip (o l’individu, si és el cas) produeix uns resultats que un tercer consumeix posteriorment. Normalment aquesta comunicació es voldrà fer de manera indirecta, és a dir, la comunicació no és punt a punt entre el productor i el consumidor sinó que els resultats del treball es dipositen i comparteixen en algun repositori o sistema intermedi accessible i, de forma asíncrona, seran recollits pel consumidor. 11.

(19) Contenidors Linux per a entorns de Ciència i Enginyeria. Aquestes parts poden ser, cadascuna d’elles, bé grups d’individus o bé estar formades per una sola persona, però de cara a l’anàlisi de la seva interacció els poden sintetitzar en dos rols: •. autors: que dins de l’equip productor s’encarreguen d’empaquetar, fer públics i distribuir els resultats i la resta dels lliurables que s’obtenen de la feina interna del projecte. Aquest rol aïlla doncs tant l’individu com tot un equip i la seva estructura interna, i s’encarrega de presentar a l’exterior el resultats de forma desacoblada a través d’un repositori accessible, sigui públic o privat.. •. revisors: en aquest cas els actors que assumeixen aquest rol no pertanyen a l’equip productor sinó que obtenen dels autors, a través del repositori intermedi, les aplicacions o els resultats del treball científic o tècnic per al seu ús o revisió especialitzat en el seu propi entorn tercer... Cal notar que el rol del revisor és lleugerament diferent del rol d’usuari genèric d’una aplicació STEM especialitzada doncs té unes necessitats específiques; concretament, en l’àmbit STEM, la necessitat de poder reproduir i obtenir els mateixos resultats en el seu entorn particular que els presentats per l’equip productor. És en aquest sentir que resulta d’interès poder comprovar si els contenidors Linux poden aportar algun benefici a aquesta dinàmica, que està més enllà de la tècnica informàtica i és la base del mètode científic, entre els productors de contingut cientificotècnic i els tercers revisors.. 2.1.3 Selecció dels rols característics Qualsevol entorn STEM real es trobarà, òbviament, en algun punt intermedi d’aquest continu d’entorns individual-equip-obert. En qualsevol cas, però, podem veure que sempre trobarem alguns dels següents rols, que seleccionarem com a rols característics d’un entorn STEM. •. desenvolupadors: encarregats de desenvolupar els algorismes, experiments o aplicacions científiques i/o emprar les aplicacions especialitzades de l’àmbit d’enginyeria corresponent per a obtenir uns determinats resultats que representin una nova aportació a la comunitat cientificotècnica.. •. administradors: encarregats de proveir, mantenir i configurar els equips de la xarxa pel que fa al programari tècnic i científic que es pugui necessitar en el domini especialitzat.. •. autors: encarregats d’empaquetar, publicar i distribuir el programari i/o els resultats per a tercers en un entorn STEM obert. 12.

(20) Contenidors Linux per a entorns de Ciència i Enginyeria. •. revisors: aquells actors, siguin interns a l’equip o tercers, interessats en obtenir els resultats publicats i/o obtenir el programari creat per usar-los o per a validar-los en el seu propi sistema informàtic. Respecte al paper dels revisors es pot veure que en entorns compartits de certa dimensió i experiència és molt probable que la revisió interna dels resultats s’estructuri com si els revisors interns fossin tercers aliens. És a dir, un cop proveïda la infraestructura necessària (pel rol administrador) per a la distribució de la solució (pel rol autor) els revisors interns podrien actuar com a tercers, tot obtenint la versió empaquetada del repositori i instal·lant-la en el seus ordinadors. D’aquesta manera, no només es validaran els resultats tècnics del projecte sinó que s’utilitza i per tant es valida la infraestructura de distribució a tercers.. 2.1.4 Les necessitats generals dels entorns STEM Tots aquests rols característics s’afegiran als altres rols comuns amb altres entorns més genèrics, com el rol d’usuari d’ofimàtica, que evidentment també es donaran de forma simultània en un entorn cientificotècnic. Així, altres necessitats generals en els entorns STEM seran les mateixes que les que es donen en altres entorns que també considerarem genèriques. Per exemple, els algorismes que es desenvolupen en entorns STEM poden processar dades que no estan ubicades en el node processador, sigui per motius de capacitat, d’ubicació de la font que els genera, etc. Cal donar accés des del node computador a les bases de dades del node d’emmagatzemament. Exemples en serien les aplicacions que processen dades en temps real, com ara solucions de Big Data sobre dades en xarxes socials, o les aplicacions financeres que operen directament sobre el propi mercat, o les aplicacions d’aprenentatge computacional (machine learning) sobre grans conjunts de dades. Altres casos són per exemple, en el cas de desenvolupament d’aplicacions científiques i tècniques, l’ús d’eines de control de versions del codi font, seguint les pràctiques del desenvolupament de software comunes. O en el cas de l’administració de xarxes, l’administració de còpies de seguretat o la gestió de la xarxa local entre els nodes que executen un càlcul. Veiem, per tant, que aquesta caracterització no és totalment diferent a la que podríem trobar en altres àmbits diferents als estrictament científics com per exemple el desenvolupament d’aplicacions per a telèfons mòbils, o la producció de contingut multimèdia, on podríem identificar rols força similars. És, de fet, aquest similitud que hi ha entre els entorns STEM i els entorns de desenvolupament de software que origina la tesi de partida d’aquest treball en formular la hipòtesi de que les pràctiques recents en l’ús de contenidors es poden traslladar i ser d’aplicació útil en entorns STEM.. 13.

(21) Contenidors Linux per a entorns de Ciència i Enginyeria. Per a poder comprovar aquesta tesi cal doncs aprofundir en la casuística concreta que diferencia un entorn STEM dels altres entorns coneguts i així confirmar o no la hipòtesi sobre l’aplicabilitat dels contenidors en aquest àmbit particular.. 2.1.5 Les necessitats particulars dels entorns STEM Els entorns de ciència i enginyeria es caracteritzen principalment per l’ús intensiu dels recursos computacionals disponibles. Per a comparar i prenent com exemple una solució de comerç electrònic, que si bé aquesta ha d’estar dissenyada per atendre puntes de gran demanda, aquí cada transacció individual requereix normalment d’un processament poc complex i poc intens computacionalment. En canvi en els tractaments tècnics o científics les dades poden ser objecte d’intenses computacions quan no força complexes. La necessitat d’un ús, tant intens com precís, del càlcul numèric en els problemes cientificotècnics pot estar també acompanyada de la necessitat de processar un gran volum de dades o de llargues sèries temporals, siguin aquestes generades per la pròpia solució o recollia de fonts externes. Addicionalment, pot existir la necessitat de distribuir els càlculs a realitzar entre multitud de nodes de la xarxa, sigui per aplicar una solució de computació paral·lela a un problema complex, sigui perquè la pròpia naturalesa del problema requereix una arquitectura distribuïda per a la seva simulació o resolució. Veiem doncs que les demandes del sistema informàtic que fan les aplicacions STEM són, al menys en alguns casos, diferents de la demanda que plantegen altres àmbits. Així les aplicacions HPC (High Performance Computing) esperen que el sistema amfitrió (que pot ser en la pràctica tot un clúster de gran capacitat) comparteixi i ofereixi la majoria de les seves capacitats i recursos a l’aplicació. En canvi, en l’àmbit de l’enginyeria del software, tendències recents com la arquitectura basada en micro-serveis es caracteritzen per instanciar un gran nombre de petits processos independents (micro-serveis), de caràcter efímer, només quan sigui necessari per a que col·laborin a proporcionar la funcionalitat esperada. Aquesta distinció és important, doncs la recent difusió i expansió de l’ús dels contenidors es realimenta fortament d’aquestes arquitectures (on cada microservei s’implanta com un contenidor diferent). Si a això li sumen que els proveïdors de servis al núvol el que volen és maximitzar la compartició de recursos disponibles per tal de poder allotjar el major nombre de contenidors possible en un mateix sistema amfitrió, però que sense que s’impactin entre ells, veiem que poden haver requisits no funcionals força diferents en els entorns STEM als que originen actualment la difusió massiva de la tecnologia dels contenidors. 14.

(22) Contenidors Linux per a entorns de Ciència i Enginyeria. Per tant, de les necessitats pròpies dels entorns STEM veurem també que algunes es podran beneficiar de la tecnologia de contenidors mentre que altres no n’obtenen cap avantatge significatiu del seu ús. Especificació de les necessitats en forma d’històries d’usuari Un cop identificats els actors principals i més concretament els rols que aquests actors poden assumir en els entorns STEM, es por iniciar un recull i inventariat de les seves necessitats de forma més sistemàtica. Podem usar les tècniques d’Enginyeria de Requisits per a fer un estudi d’aquestes necessitats. Tractant-se en primer lloc d’identificar les necessitats més bàsiques en entorns STEM, utilitzarem la tècnica simple però eficaç de les histories d’usuari. Així per a cada possible necessitat que es podria plantejar per un rol determinat, especificarem una història d’usuari que la descrigui, tot indicant els criteris d’acceptació per a poder validar la seva implantació.. 2.1.6 Necessitats particulars dels «desenvolupadors» El rol de desenvolupador en un entorn STEM té com a principal objectiu resoldre un problema determinat mitjançat la programació, en algun tipus de llenguatge d’alt nivell, d’un algorisme, computació o d’una simulació. El codi creat s’haurà d’executar en el seu entorn corresponent. Aquest entorn d’execució pot ser auto-contingut però moltes vegades farà ús de llibreries compartides instal·lades en el sistema operatiu. Acabada l’execució de la simulació o l’algorisme s’obtenen una sèrie de resultats que poden ser l’objectiu final o bé formar part d’un treball més ampli. Durant el temps que el desenvolupador treballa en desenvolupar aquesta solució o aplicació pot trobar-se en determinades situacions que requeriran de la seva actuació en tasques més enllà del propi problema en el seu àmbit de coneixement. Alternança de compiladors o intèrprets En ocasions pot ser necessari provar el codi d’una aplicació o una computació amb una nova versió del compilador o intèrpret del llenguatge de desenvolupament, sempre i quan després es pugui tornar a usar la versió anterior sense problemes. Exemples en serien: •. ha sortit la nova versió 7 del compilador gcc i es vol provar un algorisme desenvolupat amb la versió 6.. •. es va desenvolupar fa temps una solució usant la versió 2.7 de l’intèrpret de Python i es vol provar l’algorisme en la nova versió 3.6 del llenguatge.. Alternança de llibreries científiques De vegades el que canvia és una de les llibreries de base que usa el llenguatge o l’aplicació especialitzada i es vol actualitzar a una nova versió o bé substituir-. 15.

(23) Contenidors Linux per a entorns de Ciència i Enginyeria. la per una altra sense canviar de compilador i intèrpret i, sobretot, sense haver de recompilar l’aplicació de la que potser no es té el codi font. Exemples serien: •. es vol provar la llibreria del projecte openBLAS2 en substitució de les llibreries BLAS3 estàndard en el sistema disponible. •. es vol canviar la versió de les llibreries numèriques NumPy4 o SciPy5. Alternança de programari especialitzat Molta feina de caire científic i d’enginyeria es fa usant programari especialitzat, desenvolupat per tercers, que l’administrador instal·la en la estació de treball i el desenvolupador treballa sobre aquesta eina. Quan apareix una aplicació alternativa, p.e. una solució open source, es pot necessitar poder avaluar-la però sense alterar equip que ja té aplicacions potser comercials i de pagament instal·lades que no s’haurien d’alterar. Exemples serien: •. s’està usant l’aplicació comercial MATLAB6 per a un desenvolupament específic i es vol avaluar l’alternativa de codi obert GNU Octave7. •. s’està usant SPSS8 per tractament estadístic de dades del problema i es vol avaluar l’alternativa de codi obert GNU PSPP9. Execucions en paral·lel Molts desenvolupaments específics dels entorns STEM requereixen d’una gran capacitat de processament numèric que tenen una solució més òptima, quan no més natural, de caire paral·lel. És a dir, l’algorisme que resol el problema es descompon en subproblemes menors que es distribueixen en un nombre gran de nodes per a obtenir la capacitat de computació agregada. Exemples serien:. 2 3 4 5 6 7 8 9. •. una aplicació que ha de processar un gran nombre de dades però que el càlcul sobre cada dada és majorment independent de la resta de dades. Cada subcàlcul sobre un element de dades es pot executar en un node diferent i en paral·lel per a recollir i agregar a posteriori els resultats parcials.. •. un algorisme per a un sistema distribuït format per diversos nodes o bé una simulació sobre un conjunt d’agents d’intel·ligència artificial que han d’operar independentment tot i que es comuniquen entre ells per a generar un comportament emergent propi.. http://www.openblas.net http://www.netlib.org/blas http://www.numpy.org https://www.scipy.org https://www.mathworks.com/products/matlab.html https://www.gnu.org/software/octave https://www.ibm.com/analytics/us/en/technology/spss https://www.gnu.org/software/pspp. 16.

(24) Contenidors Linux per a entorns de Ciència i Enginyeria. Si bé aquesta necessitat pot ser compartida amb altres àmbits, existeix tot un conjunt de desenvolupaments derivats de les aplicacions cientificotècniques sota aquest paradigma de processament en paral·lel. Un estàndard derivat d’aquest requisit és el Message Passing Interface (MPI) que té diverses implantacions com MPICH10 o Open MPI11. El desenvolupador pot tenir la necessitat de simular o crear multitud de nodes sense la càrrega de recursos que això representa. Històries d’usuari dels «desenvolupadors» Aquestes necessitats pels desenvolupadors es poden formalitzar en aquest conjunt d’històries d’usuari: DEV01. Alternança de compiladors o intèrprets. Com a desenvolupador de software científic i tècnic vull poder alternar el compilador o intèrpret sense alterar l’entorn inicial per tal de poder comprovar el codi usant una versió diferent del llenguatge Criteris d’acceptació: es verifica que s’ha actualitzat la versió del compilador o intèrpret es pot provar el codi amb el nou compilador o intèrpret es pot retornar a la configuració inicial. DEV02. Alternança de llibreries. Com a desenvolupador de software científic i tècnic vull poder actualitzar una llibreria o canviar a una compatible per tal de poder disposar de versions més recents o versions més optimitzades sigui pel meu algorisme o el meu software instal·lat Criteris d’acceptació: es verifica que s’ha actualitzat la llibreria a la nova versió es pot comprovar si hi ha canvis en el funcionament del programari es pot tornar a la llibreria anterior sense canvis en l’entorn inicial. DEV03. Alternança de programari. Com a desenvolupador de software científic i tècnic vull poder instal·lar, executar i desinstal·lar programari alternatiu 10 http://www.mpich.org/ 11 https://www.open-mpi.org/. 17.

(25) Contenidors Linux per a entorns de Ciència i Enginyeria. per tal de poder avaluar la seva conveniència sense alterar el meu entorn inicial de treball Criteris d’acceptació: es pot avaluar el nou programari es pot retornar al programari inicial sense pèrdua de configuració. DEV04. Execucions en paral·lel. Com a desenvolupador de software científic i tècnic vull poder executar la meva aplicació en múltiples sistemes per tal de aprofitar el paral·lelisme del càlcul en varis sistemes concurrents Criteris d’acceptació: es pot desplegar un executable i una configuració de nodes en paral·lel es pot comprovar que s’executa en paral·lel en diversos nodes. 2.1.7 Necessitats particulars dels «administradors» El rol d’administrador en un entorn STEM es troba amb necessitats addicionals a les pròpies de l’administrador genèric de xarxes degut a l’especialització de les eines tècniques del usuaris i dels desenvolupadors que demanen siguin resoltes per l’administrador. Hi ha doncs dues classes de necessitats: les demandades per la resta de rols per a les seves respectives funcions (que fan referència al procés creatiu dels desenvolupadors i de distribució dels autors) i les pròpies de l’administrador per a la seva gestió del sistema dels entorns STEM (més pròpies de l’administració de les xarxes i els centres de càlcul com proveïment de clústers, accés a recursos de computació de l’amfitrió com GPUs dedicades, etc.). Ens centrarem més en les necessitats STEM més properes al cicle de desenvolupament i publicació de solucions per tercers que no als processos dels serveis interns de proveïment i administració d’entorns d’alt rendiment o altament compartits, com els sistemes HPC (que primen usar tots els recursos del host) o els serveis Cloud (que primen compartir al màxim els recursos del host) A part, doncs, d’haver d’administrar la xarxa i de proveir els seus usuaris de maquinari de requisits específics, els administradors es poden trobar amb aquestes necessitats particulars:. 18.

(26) Contenidors Linux per a entorns de Ciència i Enginyeria. Actualització coordinada del sistema operatiu Un cop s’han instal·lat les estacions de treball especialitzades i s’hi ha instal·lat el programari necessari per l’entorn específic, l’administrador ha de mantenir aquests sistemes actualitzats moltes vegades de forma sincronitzada per tots els equips. Més enllà de les tasques genèriques d’actualització del sistema operatiu hi ha determinats components del sistema que, pel seu impacte en les aplicacions científiques, són d’especial interès pel rol d’administrador STEM. Exemples serien: •. gestionar l’actualització del kernel Linux en totes les estacions. Aquest nucli que com es veurà està compartit per tots els contenidors ubicats dins d’un mateix amfitrió, i podria estar optimitzat per a la feina pròpia del servidor, i per tant l’impacte de la seva actualització és immediat en tots els contenidors.. •. actualitzar de forma sincronitzada un conjunt d’estacions que han de mantenir els mateixos components del sistema operatiu i les mateixes versions, p.e. scripts del sistema d’inici o de tasques programades.. Actualització coordinada de llibreries científiques De la mateixa manera, en determinats escenaris el manteniment sincronitzat de llibreries compartides en totes les estacions i servidors cau sota la responsabilitat del rol administrador. Exemple seria: •. el rol desenvolupador, després d’alternar llibreries determina que cal actualitzar totes les estacions dels membres del projecte a un conjunt de llibreries alternatives, p.e. OpenBLAS.. Desplegar aplicacions en el centre de computació En entorns d’equip és habitual que es dediquin recursos especialitzats a l’execució i els càlculs de les aplicacions desenvolupades pels equips dels projectes. Aquestes aplicacions un cop desenvolupades en les estacions de treball en despleguen en entorns de producció de major capacitat. Exemples serien: •. el desplegament de solucions i experiments numèrics en centres de supercomputació en la xarxa interna de l’equip. •. el desplegament de les aplicacions desenvolupades en proveïdors externs al núvol com Amazon AWS12 o Google CloudPlatform13 pel seu ús públic. 12 https://aws.amazon.com 13 https://cloud.google.com. 19.

(27) Contenidors Linux per a entorns de Ciència i Enginyeria. Orquestrar conjunts de contenidors Quan es comencen a usar contenidors, especialment quan es fa un ús intensiu dels mateixos, sigui en una solució específica aplicant arquitectura basada en micro-serveis o en un centre de computació que executi centenars, sinó milers, de contenidors, apareix una nova necessitat pels administradors: la de manegar conjuntament, sigui en la seva creació, distribució en diferents nodes de computació, configuració simultània, etc., tots aquests contenidors. Tot un conjunt d’eines s’han anat desenvolupant per a resoldre aquesta necessitat derivada de la popularització dels contenidors, com Kubernetes14 de Google o Docker Swarm15 de Docker. Aquesta necessitat però no és pròpiament una característica dels entorns STEM sinó una necessitat compartida amb altres entorns, de forma anàloga com ho seria la necessitat d’accedir a grans volums de dades en aplicacions científiques. Per tant no la considerarem a l’hora de definir les històries d’usuari particulars dels administradors en entorns STEM. Històries d’usuari dels «administradors» Aquestes necessitats dels administradors es poden formalitzar en aquest conjunt d’històries d’usuari: ADM01. Actualització coordinada del sistema operatiu. Com a administrador del sistema vull poder actualitzar el sistema operatiu d’un conjunt d’estacions o de servidors de la xarxa de forma simultània i coordinada per tal de poder mantenir la xarxa segura i actualitzada Criteris d’acceptació: es verifica que s’ha fet l’actualització al conjunt es verifica que cada nou node que s’executa està actualitzat. ADM02. Actualització coordinada de llibreries científiques. Com a administrador del sistema vull poder actualitzar llibreries de programari científic dels equips de la xarxa per tal de que els usuaris disposin de la darrera versió més actualitzada Criteris d’acceptació: es verifica que s’ha fet l’actualització al conjunt es verifica que cada nou node que s’executa està actualitzat 14 https://kubernetes.io/ 15 https://docs.docker.com/swarm. 20.

(28) Contenidors Linux per a entorns de Ciència i Enginyeria. ADM03. Desplegar aplicacions en el centre de computació. Com a administrador del sistema vull poder desplegar aplicacions en el centre de computació per tal de que es executar en un entorn de major capacitat Criteris d’acceptació: l’aplicació s’instal·la i executa en el centre de computació el desenvolupador pot recollir els resultats de l’execució. 2.1.8 Necessitats particulars dels «autors» Quan en un projecte STEM s’han completat els desenvolupaments interns i es volen publicar els seus treballs per a fer-los disponibles a tercers, el rol d’autor té la necessitat d’empaquetar aquesta solució i distribuir-la. La estratègia més adient és desacoblar el lliurament a tercers en el temps, de manera que la solució es fa disponible en un repositori intermedi, sigui d’accés públic o restringit, per tal de que els tercers revisors l’obtinguin a la seva conveniència. Empaquetar aplicacions, llibreries i dades Sigui amb l’objectiu de la portabilitat o potser més específicament de la reproductibilitat de resultats, l’autor està interessant en generar un paquet únic amb l’aplicació i les seves llibreries. El format del contenidor i el seu sistema d’arxius associar permet distribuir tots els elements necessaris: codi objecte o codi font, llibreries compartides i fins i tot dades per als càlculs, de forma que sigui transportable entre sistemes. Un exemple paradigmàtic es: •. s’ha desenvolupat una aplicació que resol un problema tècnic i es vol oferir a la comunitat per a que la utilitzi. Els autors volen empaquetar la seva solució fins al punt que sigui distribuïble com una sola unitat.. Publicar aplicacions i resultats Un cop creats aquests paquets de distribució, aquests també es poden fer arribar als tercers que correspongui. En el cas d’entorns compartits es poden fer arribar als revisors interns per a l’avaluació en el seu àmbit de coneixement. En el cas dels entorns oberts, es fan públics i disponibles els paquets de forma estandarditzada per a la seva descàrrega posterior. Exemples serien: •. en el cas d’entorn STEM d’equip, els contenidors (les seves imatges, de fet) es poden deixar en un repositori comú intern com una unitat de disc de la xarxa, etc.. 21.

(29) Contenidors Linux per a entorns de Ciència i Enginyeria. •. en el cas d’entorn STEM obert, és una pràctica habitual deixar els paquets en un repositori estàndard (com per exemple, DockerHub16) amb tota la meta-informació necessària per a descriure i documentar el paquet de cara a tercers.. Si un equip implanta les eines necessàries per fer públics els paquets en un repositori obert serà força habitual que s’acabi utilitzant el mateix sistema per a la distribució interna als revisors de l’equip. Històries d’usuari dels «autors» Aquestes necessitats dels autors es poden formalitzar en aquest conjunt d’històries d’usuari: AUT01. Empaquetar aplicacions i resultats. Com a autor d’aplicacions STEM vull poder empaquetar les aplicacions i dades per tal de transferir-los a un repositori intermedi estandarditzat Criteris d’acceptació: els conjunt quedi disponible per al públic elegit els tercers no hauran d’instal·lar components addicionals. AUT02. Publicar aplicacions i resultats. Com a autor d’aplicacions vull poder publicar les aplicacions per tal de que tercers les puguin obtenir i usar en els seus sistemes Criteris d’acceptació: els tercers poden usar el seu sistema operatiu encara que sigui diferent Com podem veure en aquest cas, per a validar l’empaquetat és possible que sigui necessari poder-lo publicar i descarregar-lo de nou pels mateixos autors. Les històries d’usuari de desenvolupadors i autors s’encadenen i, de fet, moltes vegades és el mateix actor que va assumint diferents rols en el cicle. Això és propi dels entorns STEM sobretot individuals, i aquí és on la tècnica dels contenidors hauria d’aportar més beneficis a aquests actors: els científics i enginyers que volen centrar-se en la seva feina principal i simplificar els processos auxiliars i que no són especialistes en distribució i desplegament de software. 16 https://hub.docker.com. 22.

(30) Contenidors Linux per a entorns de Ciència i Enginyeria. 2.1.9 Necessitats particulars dels «revisors» Des del punt de vista del revisor (sigui intern o extern) interessat en obtenir una aplicació publicada pels autors per a usar-la en el seu sistema o per a reproduir un resultat computacional, el paradigma del repositori públic de contenidors simplifica també molt les seves necessitats. Obtenir aplicacions de repositoris El fet d’estandarditzar els repositoris i usar aquests com a mecanisme de transport de solucions unifica i simplifica les necessitats dels revisors, que són d’una mateixa classe però també poden concretar-se de forma diferent per a cada autor. En conèixer el format del paquet distribuït en un repositori i disposar de metainformació en la publicació, la tasca d’obtenir però sobretot d’instal·lar la solució la pot arribar a realitzar el propi revisor sense haver de necessitar la intervenció d’un administrador especialitzat en el seu propi entorn. Un exemple característic seria: •. un revisor interessat en una determinada publicació de recerca es connecta al repositori on ha estat publicat un contenidor Docker amb el codi i les dades proporcionades pels autors i n’obté una còpia de la imatge del contenidor.. Reproduir els resultats publicats per tercers Per altra banda, el fet de descarregar un desenvolupament de tercers genera unes noves necessitats en haver d’adaptar els seus sistemes als requisits de l’aplicació. Un exemple seria: •. el revisor crea un nou contenidor en el seu propi sistema que el permet executar el codi publicat en la imatge de contenidor que l’autor abans ha descarregat del repositori.. Un requisit essencial, però, és que el sistema del revisor tingui instal·lat el runtime de contenidors capaç d’executar el paquet descarregat. Com que el revisor es podria trobar amb publicacions en diversos sistemes no compatibles, la pressió de la comunitat cientificotècnica anirà en el sentit de simplificar el nombre de formats disponibles. També en aquest punt, on la gamma d’implantacions, per a múltiples sistemes operatius, ofertes per una solució de contenidors ha de jugar a favor de elegir finalment un sistema de facto o un altre, si es vol tenir la llibertat d’elegir el sistema operatiu a l’hora d’usar i validar una solució prèviament publicada.. 23.

(31) Contenidors Linux per a entorns de Ciència i Enginyeria. Històries d’usuari dels «revisors Aquestes necessitats dels autors es poden formalitzar en aquest conjunt d’històries d’usuari: REV01. Obtenir aplicacions de repositoris. Com a revisor i usuari d’aplicacions de tercers (o de l’equip) vull poder obtenir aplicacions de repositoris externs (o interns) per tal de d’executar-les en el sistemes d’avaluació Criteris d’acceptació: es pot obtenir l’aplicació del repositori es pot instal·lar i executar l’aplicació sense instal·lacions addicionals. REV02. Reproduir els resultats publicats. Com a revisor de resultats computacionals vull poder obtenir aplicacions i dades corresponents a uns resultats per tal de poder replicar les computacions i replicar-ne els seus resultats Criteris d’acceptació: es pot obtenir l’aplicació del repositori public es pot instal·lar i executar l’aplicació sense instal·lacions addicionals es pot verificar la reproductibilitat dels resultats publicats. 24.

(32) Contenidors Linux per a entorns de Ciència i Enginyeria. 2.2 Estudi de Solucions amb Contenidors 2.2.1 Solucions basades en el propi sistema La primera aproximació per donar solució a aquestes necessitats consisteix en modificar el propi sistema. Aquesta és la solució natural especialment en un entorn individual on el científic o enginyer no està especialitzat en l’administració de sistemes i molt menys en la tecnologia dels contenidors. En aquesta situació, les actuacions directes sobre el sistema són les que aniran causant la problemàtica i dificultats que van originar el naixement dels contenidors i el posterior desenvolupament de solucions més complexes i automatitzades per a gestionar-los. Poden ser problemes típics, que es donarien en prendre aquesta aproximació: •. La modificació del sistema principal de treball provoca la desconfiguració del mateix de manera que no es pot seguir usant com anteriorment al canvi, amb l’impacte sobre la feina inicial del científic o enginyer.. •. El sistema de treball no té prou capacitat de càlcul per resoldre el problema en estudi per la qual cosa no es pot concloure si la solució desenvolupada és correcte o no.. •. El servidors dedicats a executar la càrrega de treball en estudi s’han d’instal·lar i configurar expressament per a cada problema o experiment limitant-ne la seva capacitat de reutilització en entorns compartits.. •. Els resultats obtinguts tenen una forta dependència de la estació de treball o els servidors de càlcul emprats, dificultat la posterior reproductibilitat d’aquests per tercers.. Tots aquests problemes són els que generen la necessitat de buscar i construir altres solucions L’operació chroot Una de les primeres solucions per a intentar disposar de múltiples entorns aïllats i independents va ser el desenvolupament, en els sistemes UNIX, de l’operació chroot (abreviació de change root filesystem). Mitjançant aquesta operació es pot canviar el sistema de fitxers arrel d’un procés per a que no sigui el mateix que el del procés pare. Així, si per exemple es té disponible una imatge d’un sistema d’arxius en un subdirectori (p.e. per a un sistema encastat), després de fer chroot a aquest subdirectori el procés pensa que aquest subdirectori és l’arrel del sistema d’arxius per la qual cosa ja no pot canviar de directori de treball cap a directoris que estiguin en un nivell superior. Aquesta tècnica s’usa com mecanisme de seguretat, p.e, per aïllar usuaris en 25.

(33) Contenidors Linux per a entorns de Ciència i Enginyeria. els servidors FTP, que un cop connectats només es poden moure pel seu directori i pels subdirectoris però no accedir a directoris del sistema amfitrió. El principal inconvenient és que aquests usuaris sí que comparteixen la resta d’espais de noms com usuaris, processos, etc. i un error (p.e. en el procés servidor FTP) o una incorrecta configuració en el sistema amfitrió podria iniciar un escalat de privilegis no desitjat.. 2.2.2 Solucions basades en màquines virtuals Una segona aproximació més complexa consisteix en usar màquines virtuals. Una màquina virtual és una simulació parcial o total d’un nou ordinador feta per una aplicació especialitzada anomenada hipervisor. Aquesta aplicació emula el maquinari d’un sistema de manera que el codi binari que s’hi executa en aquesta màquina no distingeix que està essent interpretat per un software doncs funciona igual que si s’estès executant en un processador físic. Els inconvenients de les màquines virtuals es poden resumir en dos aspectes: •. Els hipervisors fan una simulació per software del hardware virtualitzat. Això significa que cada instrucció màquina de la solució executada ha de ser interpretada i emulada en el processador de l’equip amfitrió amb la pèrdua directa i important de rendiment final per l’aplicació emulada.. •. La simulació d’una nova màquina virtual requereix una còpia completa no només del sistema d’arxius sinó també del nucli del sistema operatiu simulat. En el cas d’haver de simular un nombre elevat de màquines la suma d’espai en disc necessari creix ràpidament. No menys important des del punt de vista de l’administrador és l’increment de la complexitat d’haver de mantenir tot el programari (aplicacions i llibreries, o el propi sistema operatiu) en un nombre elevat d’equips.. Les solucions basades en màquines virtuals poden ser útil en entorns individuals o en equips de reduïda dimensió però són poc escalables quan l’equip ha de créixer en nombre de participants o quan les solucions s’han de compartir i distribuir a tercers. Tot un conjunt d’eines han aparegut per tal de permetre administrar grans conjunts de màquines virtuals i tots els recursos associats, però en alguns escenaris això representa una sobrecàrrega que podria ser innecessària i contraproduent (p.e. en un solució basada en microserveis). Durant anys, però, aquesta ha estat i segueix sent una solució prou emprada i que funciona adequadament en determinats escenaris. És quan cal distribuir aquestes màquines virtuals, sigui per executar-les en servidors compartits o sigui per compartir-les amb tercers per la seva avaluació quan es manifesten aquests problemes d’escalabilitat en espai i també de velocitat.. 26.