Páginas

Windows Server Core ltsc2019 Docker image on Windows 10 1803: no matching manifest for windows/amd64 10.0.17134 in the manifest list entries


I'm trying to create a Windows Server Core ltsc2019 Docker image on Windows 10 1803 and when trying to get the docker image from the registry I'm getting

$ docker run mcr.microsoft.com/windows/servercore:ltsc2019
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2019' locally
ltsc2019: Pulling from windows/servercore
docker: no matching manifest for windows/amd64 10.0.17134 in the manifest list entries.

Searching the Internet I came with the solution, "your pulling image must match the version of Windows that you're runninghttps://github.com/docker/for-win/issues/3761#issuecomment-498315046 

And the explanation is simple (and also on that thread) "the version must match the Windows kernel version you're running on. Unlike Linux, the Windows kernel does not have a stable API, so container images running on Windows must have libraries that match the kernel on which they will be running to make it work (which is also why those images are a lot bigger than Linux images).https://github.com/docker/for-win/issues/3761#issuecomment-484131393 

Aplicando practicas modernas de desarrollo a proyectos hosteados en TFS / legacy

Si me preguntan cuáles son las prácticas que deberían aplicarse a un proyecto de desarrollo de software hoy en día, sin importar su tamaño, yo rápidamente respondería:

  1. Utilización de containers para levantar entornos de trabajo. 
  2. Código versionado en herramienta moderna. Hoy en día el estandar de la industria es GIT
  3. Aplicar refactorización a ese código.
  4. Que ese código tenga una buena cobertura.
  5. Integrar las modificaciones al código continuamente y que un server compile el código y verifique que no haya roto nada.
  6. Hace un análisis de mi código que me asegure que sigo standard, que me de métricas sobre mi código, etc.
  7. Test automatizados
  8. Delivery / deploy automatizado y continuo

Y si me apuran aún mas, respondo "como mínimo integrar las modificaciones al código continuamente y que un server compile el código y verifique que no haya roto nada" aunque a veces en mucho pedir.

Ahora, déjenme que les cuente una historia a ver si les suena familiar.

Este año me sume a trabajar a un equipo que desarrollaba una aplicación web para un cierto cliente. El código ha sido tocado por mucha gente, de distintos senorities y ni hablar de los errores inexplicables que se encuentran  o del código dulpicado que hay.

El código fuente del proyecto estaba hosteado en el TFS del cliente con un Jenkins build server y deploy server (que no controlamos). Este build server no está configurado como integración continua

El Jenkins ejecuta un análisis de código con SonarQube aunque tampoco tenemos acceso. El acceso a los análisis de SonarQube nos serviría para tener métricas de nuestro código, ver como evoluciona / involuciona y ayudaría a los desarrolladores más juniors a que aprendan y mejoren.

A pesar que no hacemos TDD (y que la arquitectura de app no lo permite), hay algunos unit test escritos que nunca se ejecutan.

Conclusión: casi ninguno de los puntos nombrados al principio se cumplen.

¿Seguimos desarrollando así? la respuesta es muy simple NOOOOOOOOOOOO
¿Qué opciones tengo? ahi la cosa es más compleja pero nada complicado gracias a la cantidad de herramientas con las que contamos hoy en día:

  1. Utilizar un GIT controlado por nosotros y luego integremos los cambios en el TFS. Esto es facil de hacer con GIT TFS, un comando que nos permite clonar en un repo GIT el código fuente hosteado en un TFS y tener una comunicación bidireccional. Una vez que controlamos el repo, el resto es más facil!
  2. Como integración continua podemos usar algo como Azure DevOPS para que buildee el código continuamente y ejecute las tareas que necesitamos:

Ya con el hecho de usar GIT TFS y Azure DevOPS junto a los Unit Test y SonarQube logramos tener mucho más de lo que originalmente teníamos y hemos mejorado notablemente nuestra calidad.

Asp.Net Core + GraphQL + Docker + Github + AzureDevOps + SonarQube

This project was created to learn about GraphQL and to spread the learnings. You can find the related PPT http://bit.ly/NeorisGraphQLPPT

Project source code: https://github.com/vackup/AspNetCoreGraphQL/

The app runs on 2 docker containers, one for the React frontend and one for the Asp.Net Core GraphQL backend
The project is being built using Azure Devops build pipelines (http://devops.azure.com)




Continuous Code Inspection is being done by SonarQube (https://www.sonarqube.org/).
AspNetCoreGraphQL SonarCloud Dashboard https://sonarcloud.io/dashboard?id=vackup_AspNetCoreGraphQL


What's GraphQL?

GraphQL (https://graphql.org/) is a data query language and specification developed internally by Facebook in 2012 before being publicly open sourced in 2015.

It provides an alternative to REST-based architectures with the purpose of increasing developer productivity and minimizing amounts of data transferred.

GraphQL is used in production by hundreds of organizations of all sizes including Facebook, Credit Karma, GitHub, Intuit, PayPal, the New York Times and many more. https://graphql.org/users/

Some post for building GraphQL APIs with ASP.NET Core