jj / iv Goto Github PK

Asignatura de infraestructuras virtuales para el Grado de Informática

Shell 0.10% Perl 62.15% JavaScript 21.52% Ruby 0.37% Go 0.16% R 1.12% Raku 0.33% Dockerfile 0.02% Python 0.29% HTML 13.78% CSS 0.17%

etsiit ugr hacktoberfest hacktoberfest2020 cloud hacktoberfest2023

iv's Introduction

Material docente para la asignatura Infraestructura Virtual

| |

Infraestructura virtual es una asignatura obligatoria de la rama "Tecnologías de la Información" del primer cuatrimestre del cuarto curso del Grado de Ingeniería Informática y optativa en otras ramas y en el Doble Grado de Informática y Matemáticas.

La asignatura en el curso 24-25 se imparte en el aula 1.3 los viernes de 12:30 a 14:30 (grupo conjunto) y en la -1.2 los jueves de 8:30 a 10:30 y de 12:30 a 14:30 (grupos divididos). Se recuerda a los estudiantes que en todas las clases será necesario llevar el portátil, ya que son siempre clases prácticas; por lo mismo, se recomienda encarecidamente la asistencia a todas las clases para realizar las prácticas in situ y que el profesor pueda ayudarles.

Las clases de cursos anteriores están grabadas, y puedes acceder a ellas en esta lista de reproducción de YouTube. Conviene que te refieras a ellas sólo para los conceptos, no para los temas administrativos.

Se usará GitHub para el proyecto, la forma principal de examinar la asignatura; cada una de las entregas representan haber alcanzado objetivos de aprendizaje, y por lo tanto se denominan objetivos.

Los materiales de la asignatura están enlazados desde abajo y disponibles con una licencia libre. Los fuentes de los mismos están en GitHub.

La temporización de la asignatura y los objetivos de cada sesión figuran en la bitácora de clase. Enlazaremos también en ese fichero las grabaciones que se hagan de las sesiones en vivo.

Estos son los objetivos de la asignatura, cuyas sesiones de clase se irán reflejando en un repositorio de GitHub.

En resumen, nuestra intención es que el estudiante al final de la asignatura sea capaz de hacer lo siguiente:

Definir el problema, entorno de trabajo y pruebas para desarrollo de una aplicación en particular y desplegarlo en un PaaS.
Usar ese entorno para configurar integración continua en una aplicación.
Crear un entorno virtual para desarrollar y alojar la aplicación y comprenda el soporte físico de las técnicas usadas para crear tal entorno virtual.
Entienda las técnicas de configuración automática de entornos virtuales y las sepa aplicar en los entornos anteriores.
Use lo aprendido para despliegue masivo de aplicaciones en la nube.

El objetivo del proyecto es que el estudiante se familiarice con la metodología usada habitualmente en desarrollo de aplicaciones (en la nube y cualquier otro tipo), por lo tanto, lo importante es que vaya, a través de la puesta en práctica en un proyecto propio, interiorizando las mejores prácticas en ingeniería de software.

Prácticas - Actividades académicas dirigidas en grupos divididos

Previo a la asignatura, es conveniente que consultes este curso, con material suplementario a lo que se imparte en la asignatura. Los temas relevantes se enlazarán en cada hito.

La parte práctica de esta asignatura consiste en la realización de un proyecto a lo largo de la misma, cubriendo diferentes objetivos de aprendizaje a la vez que se realizan diferentes productos mínimamente viables de ese proyecto. Los proyectos consisten en crear la infraestructura virtual junto con una aplicación desarrollada según el modelo DevOps. A grosso modo, los objetivos se organizarán de la forma siguiente.

Objetivo cero: Uso básico de herramientas, problema a resolver.
Historias de usuario y planificación.
Modelización del problema.
Automatización de las tareas.
Tests unitarios para la clase/s diseñadas.
Técnicas de virtualización: Contenedores para pruebas.
Integración continua.
Servicios esenciales.
REST.
Implementación de REST.

En estas prácticas se realizarán una serie de actividades para ayudar a interiorizar los conceptos.

Juego de rol: empatizar con el cliente para definir un problema.

Este último para crédito adicional:

PaaS.

Estas prácticas se han hecho otros años:

Provisionamiento de máquinas virtuales.
Virtualización de aplicaciones.
Sistemas serverless.
Creando microservicios.
Desplegando a la nube: Platform as a Service.

Material adicional

El temario está sólo como complemento, porque hay que partir de los objetivos de aprendizaje semanales y los objetivos a entregar. Esto se ha usado como material primario antes de 2021, pero ya no se considera material principal y está, en muchos casos, sin actualizar.

Introducción: conceptos y soporte físico. Esta introducción es cultura general; aunque conviene conocerlo, no es imprescindible para llevar a cabo, en general, el proyecto de la asignatura. Se aconseja vivamente, sin embargo, leerlo y llevar a cabo los ejercicios de autoevaluación.
Iniciación a DevOps: desarrollo basado en pruebas.
Usando contenedores.
Integración continua.
Breve introducción a REST.
Puesta en marcha de microservicios.
Platform as a Service.

Estos temas se pueden consultar como material adicional, han dejado de formar parte del temario de la asignatura:

Introducción e historia de los contenedores.
Técnicas de virtualización.
Aislamiento de recursos.
Almacenamiento virtual.
Gestión de configuraciones.
Computación serverless.

Seminarios

Material adicional interesante para la asignatura, que se impartirá (en todo caso) fuera del horario lectivo.

Tutorías virtuales

Las tutorías virtuales se realizarán preferiblemente a través del grupo de Telegram; habrá que solicitar al profesor ser añadido. Finalmente, el profesor está disponible por Telegram y Google Meet (en todos los casos: jjmerelo); para cualquier videotutoría se pide consultar con cierta antelación.

Criterios de evaluación

Los criterios de evaluación figuran en la ficha de la asignatura en la web del grado, y se especifican en el repositorio de la clase.

Convocatoria extraordinaria (AL FINAL DEL CUATRIMESTRE)

Si no se ha superado la asignatura en la convocatoria ordinaria, en la extraordinaria habrá que entregar los diferentes objetivos del proyecto no entregados, con fecha tope el día que se haya anunciado oficialmente para el examen.

iv's People

Contributors

Stargazers

Watchers

Forkers

josemlp91 elmendacorp josecolella melero90 juanafernandez angeljcc desmadrados victorcoronas potray jormaral nachobit dscdac hugobarzano rafaellg8 mabarrbai samuc adalsa91 ncortex neon520 jorgecasas elsudano marco-fp mariamma6 joaquinb25 icachurro fjfernandez93 antoniovj1 jurinco carlillostole adrichainz koltharius antonioalcm danjabad harvestcore alberturria luisbalru sergiocruzperez namasme antoniomg89 jojelupipa jotagalera terceranexus6 adriordi ivanpau pedroamador jesus-sheriff vperaltac lulivi nazaretrogue marquirj lcinder mariasanzs biilal1999 davidspace antoniogamiz albertolejarraga guillelpnz venrra bate-ye-edo aebm alexrodriguezlop manuasir mchc97 robertglez pramartinez pravila00 apenav jlortega00 olasergiolas paula1999 alexespana lmorillas emablanco mauronmp delightfulagony carlos-se arsa-dev pedrooot giorgiogiovanni evaalmansa asmit13 jorgeorlandu jaiderlearning

iv's Issues

Añadir en el capítulo de los contenedores la configuración específica de la UGR

Para que no haya problemas con el DNS

Corregir múltiples errores de la práctica 2.

KVM en manjaro

Hay problemas con el comando kvm-ok en manjaro.
Usando el comando :
LC_ALL=C lscpu | grep Virtualization

Se puede ver de todas formas.
He sacado al información de la página https://www.fosslinux.com/2484/how-to-install-virtual-machine-manager-kvm-in-manjaro-and-arch-linux.htm/

Error en el archivo de configuración de Ceph

En el archivo /etc/ceph/ceph.conf, si en la última línea (dentro de la configuración del dispositivo de objetos [osd.0]) ponemos devs = /dev/loop0, al ejecutar sudo /sbin/mkcephfs -a -c /etc/ceph/ceph.conf, cuando va a iniciar osd.0 nos dará un error diciendo que no tiene un tipo de sistema de archivos definido:

Para solucionarlo hay que cambiar la línea por xfs devs = /dev/loop0. Además, es necesario que el propio dispositivo /dev/loop0 haya sido formateado mediante el comando sudo mkfs.xfs /dev/loop0. Una vez hecho todo esto, desaparece ese problema:

Y aunque aparece otro error, si ejecutamos sudo ceph -s aparentemente todo funciona:

Errata con la orden jkinit

Creo que la orden que aparece en los apuntes jkinit -v -j /seguro/jaulas/dorada jk_lsh basicshell netutils editors debe ser jk_init

Enlace erroneo sitio web LXC

En el tema de contenedores, el enlace del sitio web de LXC del ejercicio 1 dirige a linuxcontainers.com el cual no existe. La URL correcta es linuxcontainers.org

Propuesta de Project Management

Problema

Según lo explicado para el hito 1, siempre se ha de trabajar con milestones e issues, además estas últimas deben de estar documentadas en un fichero hu.md para así llevar un control de versiones sobre ellas. En la mayoría de los casos, estas historias se acabarán convirtiendo en issues que habrá que desarrollar, así que probablemente se copiará la historia en el body de la issue correspondiente, acabando con la historia duplicada en 2 partes distintas del repositorio.

Propuesta

Las historias de usuario se redactan directamente como issues. Normalmente una issue suele tener varias tareas asociadas, para llevar un mejor seguimiento de esto, se puede linkear el PR de la tarea con la issue correspondiente y aparecerá un desplegable tal y como se muestra en la imagen. De esta forma se puede ver claramente la historia de usuario, sus tareas y a qué hito pertenecen, además de si ha sido revisado o si ha pasado los tests.

Todo esto se ve si se crea un proyecto dentro del repositorio, y se van añadiendo las issues a él.

Disculpa si no me he explicado bien, si tienes cualquier pregunta por favor no dude en hacerla.

Valoración de la implementación de la interfaz REST

En el guión del hito 3 indica que como objetivo secundario es la implementación de la interfaz REST. He realizado dicha implementación y el testeo correspondiente pero no tengo claro en qué apartado se puntúa dicho objetivo o si ni siquiera puntúa.

Revisar requisitos mínimos para el proyecto

Con un proyecto que incluye un servicio web sin ningún servicio adicional desplegado en una sola máquina virtual, es difícil que las recetas para instalación no sean calco unas de otras. Debería revisarse para que incluyera al menos un servicio adicional.
Considerar también la posibilidad de que usen grupos de escalado y otras características específicas, o despliegues mixtos contenedores/instancias.

Introducir serverless antes que PaaS

Al fin y al cabo, son un mínimo ejemplo de despliegue, tiene diferentes opciones (desde Firebase hasta vercel) y conceptualmente permite introducir cosas como arquitecturas reactivas y demás.
No está claro cómo se pueden integrar dentro de una arquitectura nube más completa, sobre todo teniendo en cuenta el proyecto. Pero se puede pensar tranquilamente qué se puede hacer.
Gracias a @angelhodar por la sugerencia.

Mejorar el apartado del Dockerfile

Este apartado se podría mejorar.

Añadir un (posiblemente mini) capítulo sobre microservicios

Para que se entienda de qué se trata.

Revisar capítulo 3

Revisión del capítulo relacionado con los PaaS: http://jj.github.io/IV/documentos/temas/PaaS

Modificar los tests actuales para que busquen historias de usuario con un formato determinado en issues

Por ejemplo, la etiqueta "hu".
Refs #97

Apuntes tema 4 - Contenedores: no existe la opción -notrunc de Docker

Quizás es problema de las versiones más modernas, pero en Ubuntu 16+ la opción es --no-trunc.

Añadir markdownlint a la integración continua

¿Qué te parecería añadir markdownlint a la integración continua del repositorio? Creo que sería una gran mejora. Esta herramienta asegurará la correcta escritura en Markdown de toda la documentación.

Tema gestión de configuraciones: Vagrant. Problemas con el plugin libvirt

Siguiendo las instrucciones del profesor se ha instalado la versión descargable en la página de vagrant en lugar de la instalada por el gestor de paquetes de mi distribución (apt).

Esto ha desembocado en que máquinas que había probado con la versión de apt dejasen de funcionar al probar la versión de la página de vagrant. El problema estaba en el plugin de vagrant libvirt.

Al intentar “lanzar” la máquina con vagrant up devolvía el siguiente error:

>$ vagrant up 
The provider 'libvirt' could not be found, but was requested to
back the machine 'default'. Please use a provider that exists.

Vagrant knows about the following providers: virtualbox, hyperv, docker

Lo cual sugería que faltaba dicho elemento. He probado a instalarlo con vagrant plugin install libvirt pero devuelve un problema de dependencias:

>$ vagrant plugin install libvirt
Installing the 'libvirt' plugin. This can take a few minutes...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

conflicting dependencies ffi (~> 0.6.3) and ffi (= 1.9.25)
  Activated ffi-1.9.25
  which does not match conflicting dependency (~> 0.6.3)

  Conflicting dependency chains:
    ffi (= 1.9.25), 1.9.25 activated

  versus:
    libvirt (> 0), 0.1.0 activated, depends on
    ffi (~> 0.6.3)

Por lo cual no he podido comprobar si el problema es del plugin en sí, que está algo desactualizado y por tanto debería buscar alguna vagrantbox que no requiera de este plugin, pero entre enlaces rotos y problemas de almacenamiento no he encontrado si esto es una solución.

Si en algún momento encuentro algo de información al respecto lo iré añadiendo aquí.

Poner requisitos sobre el lenguaje de los proyectos

Ahora mismo el 90% usan Python y al usar el mismo lenguaje hay una cierta cantidad de plagio y simplemente usar lo mínimo necesario. Ver la posibilidad de usar otros lenguajes

Hablar de Flatpak

Para distribución de aplicaciones en cualquier distro Linux.

Arreglar enlace del Tema 2 a su práctica correspondiente

El segundo tema tiene un bloque repetido del primero

Reescribirlo y añadir conceptos de arquitecturas modernas de software basados en microservicios.
Relacionado con #26

No se encuentra mocha para ruby

No hemos encontrado mocha para ruby, el único que hemos encontrado con ese nombre no lo hacemos funcionar.

Error en los enlaces entre temas

Cuando accedes al tema 2, el enlace superior de la página al tema anterior te lleva al tema 4, en vez de enlazarte al tema 1.

Sustituir Fabric por Invoke

Al parecer está deprecated.

Corrección texto entrega práctica

Corregir la siguiente linea eliminando la posibilidad de entregar la documentación como wiki.

" Esta documentación se incluirá en ficheros de texto junto con la aplicación o en páginas wiki dentro de las que proporciona GitHub. "

Hacer un símil del ejercicio 3 del tema 2 en python

Eliminar Vagrant

Según el consenso general en los grupos de Telegram de DevOps, parece que ya su uso es residual y para casos muy específicos. Sustituirlo por Terraform o alguna otra cosa.

Enlace roto en el hito 2

En la documentación del hito 2 el enlace que aparece en el apartado "Entrega de la práctica" está roto, creo que debería apuntar a:
https://github.com/JJ/IV16-17/blob/master/practicas/2.md

Revisión del segundo tema de desarrollo basado en pruebas

Sobre desarrollo basado en pruebas https://github.com/JJ/IV/blob/master/documentos/temas/Desarrollo_basado_en_pruebas.md Igual que en el caso anterior, comprobar enlaces, añadir el material, comprobación ortográfica y gramatical general, y sugerencias sobre nuevos contenidos.
Posibles mejoras:

Añadir ejemplos en otros lenguajes
Revisar el código existente para errores, mejoras, o mejores prácticas.

Error en los apuntes del tema 6

Aunque en la aprte de chef si esta bien descrita la estructura de los archivos, no viene indicado que el archivo default.rb debe estar dentro de la carpeta recipes en su carpeta de la receta.
ejemplo: cookbooks/emacs/recipes/default.rb.

En mi ejercicio 2 del tema 6 lo explico también y se ve que funciona.
https://github.com/torresj/IV-GII-13-14/blob/master/ejerciciosT6-1.md

Erro enlace practica 2

http://jj.github.io/IV/documentos/practicas/2.Jaulas error 404

Propuestas de mejora para curso 2020-2021

Algunas notas a vuela pluma para intentar mejorar en años sucesivos, a la vista de los resultados de este año, que muestran sobre todo una caída muy grande en entregas (y aprobados) al pasar del hito 1 al hito 2.

Este es el hito 1. Es un hito bastante simple, casi extensión del 0, que lo que pide es prácticamente que se entiendan como usar los hitos e issues y poco más. Es instrumental, más que conceptual (aunque en parte es conceptual). La fecha de entrega es el 30 de septiembre, comienzo de la cuarta semana de clase, 11 días después de la entrega del hito 0, 17 días después del comienzo de las clases.
Este es el hito 2. Es un hito que introduce principalmente el concepto de desarrollo basado en test, pero adicionalmente hay que saber cómo configurar 2 sistemas de integración continua. La fecha de entrega es algo más amplia, 10 días (hasta el 10 de octubre), pero tampoco es tanto.
El siguiente hito tiene hasta el 24 de octubre, 14 días, da un poco de margen para reentregar, pero no tanto.

Diagnóstico

Es posible que haya muy poco tiempo para este hito, teniendo en cuenta sobre todo que los anteriores, que prácticamente no tienen contenido conceptual, tienen tres días menos. 10 días pueden no ser suficiente, pero además es cuando se empieza a tener que programar, con lo cual la carga de trabajo puede ser excesiva para el tiempo que se le dedica. Es también un concepto fundamental, TDD, que habría que introducir desde el principio, quizás desde el hito 0, posiblemente con la comprobación de ortografía, que ya puestos podíamos incorporarla a esto. (Adicionalmente se podía introducir una plantilla de repositorio que incluyera ya esto del tirón, o también el markdown, por ejemplo) En todo caso, CI se puede separar de TDD introduciendo CI desde el principio, para que el hito 2 se centre más en TDD

Posibles propuestas

Usar CI desde el primer hito usando una plantilla de repo
Introducir parte del desarrollo del programa en el hito 1, para que la programación se extienda un poco más. Adicionalmente, un seminario sobre desarrollo en capas, TDD y principios solid.
Retrasar la entrega del hito 2, al menos dos semanas en vez de los 10 días actuales.

Añadir introducción a conceptos generales de la nubes públicas

Tales como grupo de recursos o suscripción, así como una intro a la línea de órdenes de lo smismos.

Explicar conceptos generales de despliegue

Qué tipo de tareas serían las suyas y cuales son las mejores prácticas en los mismos.

Problemas con cgroup

Siguiendo los apuntes de la asignatura, intentando hacer el ejercicio 7 nos encontramos con un problema con las nuevas versiones de Debian y Ubuntu.

Por lo visto la estructura de organizar el cgroup ha cambiado y ahora se organizan los grupos en función del recurso. En vez de crear una carpeta para el grupo en /sys/fs/cgroups deberíamos crear una en /sys/fs/cgroups/cpu, por ejemplo. No podremos crear nuevos ficheros puesto que se trata de una carpeta montada por systemd en un sistema de archivos temporal que no podemos tampoco desmontar de ninguna manera.

Si alguien sabe cómo cambiar la configuración para que el sistema de cgroup se use de forma clásica que lo haga y si no habrá que adaptarse a los cambios.