Categories
54cuatro

Herramientas para modelar Arquitecturas Empresariales

Quienes trabajamos como #EnterpriseArchitect sabemos de la necesidad de documentar lo que vamos creando. Necesitamos herramientas UML para poder bajar a detalle y crear un esquema visual de lo que luego se convertirá en un producto.

¿Qué es #UML?

Esquema de UML

UML es una técnica para la especificación sistemas en todas sus fases, un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory.

¿Cuales son las herramientas de UML?

Existen algunas herramientas tradicionalmente usadas para este tipo de trabajos. Tradicionalmente el #Visio de #Microsoft es de las más referenciadas.

En la actualidad existen muchas nuevas herramientas, algunas web, algunas open source, que permiten realizar el modelo de Arquitecturas Aplicativas o de IT en general.

El gran auge de la #nube, creó un sinfín de nuevas herramientas de modelado, algunas específicas para cada nube, como el caso de Cloud Craft que permite crear modelos basados en tecnología #AWS, y que además permite conectarse a la calculadora de #Amazon para realizar el presupuesto de lo que está definiendo.

Visual cloud designer
Captura de Cloud Craft

Sin dudas es una herramienta súper potente. Siguiendo dentro de la misma familia, existen algunas como Cloud Skew o Hava que nos permiten realizar el diseño no solo para AWS sino también para #Azure o #GCP.

Modelando en la web

No podemos dejar pasar por alto herramientas de mucha utilidad como LucidChart o Draw.io (ahora renombrada como Diagrams.net), que no solo son de utilidad para Arquitectos, sino para generar todo tipo de gráficos anidados con cierta lógica como Flujos de Procesos u Organigramas, como para mencionar algunos ejemplos.

Nuestra preferida: Archimate

Nuestra preferida es sin dudas #Archimate. Es quizás la herramienta hecha por y para Arquitectos Empresariales o Enterprise Architects, bajo el estándar abierto propuesto por Open Group.

Archi
Captura de Archimate

Archimate es una herramienta #OpenSource, que puede ser usada en #Windows, #Linux y #Mac, y que puede ser descargada desde la web archimatetool.com. Permite a los usuarios de esta tool, crear modelos basados en frameworks de arquitectura como #TOGAF. Dentro de una misma aplicación se pueden crear flujos de negocios, modelos de planificación de tipo Mind Mapping, modelos de interrelación aplicativa, y hasta planificaciones basadas en #Agile.

Sin dudas es la elegida por nuestro equipo, y la que recomendamos para llevar a cabo las tareas de planificación inherentes a un arquitecto.

¿Y tu equipo, qué herramienta utiliza?


[popup_anything id=”2076″]
Categories
54cuatro

Creando un Pipeline CI/CD DevOps

Creación de un pipeline CI/CD desde Azure DevOps a KongHQ

En este post Silvio Ricagno y Alejandro Orozco nuestros especialistas en Microservicios nos van a explicar cómo ejecutar una integración entre Azure DevOps, Docker hub, ArgoCD, Rancher y KongHQ.

Información útil sobre este ejemplo

  • La idea principal del ejemplo es resolver de una manera muy sencilla la comunicación entre estas herramientas usando varias características que nos facilita .Net sobre Visual Studio y Azure #DevOps.
  • Tanto KongHQ como Argo CD ya se encuentran instalados y configurados sobre Rancher.
  • El Framework del proyecto usado es .Net Core 3.1.
  • Es recomendable tener instalado y actualizado, en la PC donde estés trabajando con el Visual Studio, Docker Desktop.
  • El archivo .sln y .csproj deben estar en carpetas distintas.

Herramienta que usamos

En nuestra demo usamos la siguientes herramientas

Estructura de la solución

  • Para genera la configuración necesaria para contenedores, usamos la opción de “compatibilidad con orquestador de contenedores” disponible haciendo clic derecho en el nombre del proyecto en el submenú “agregar”. Aquí elegimos “Kubernetes/Helm”.
  • Es muy importante que el Dockerfile esté a la altura del .sln, esto nos ahorrará varios dolores de cabeza. Si bien en la siguiente imagen aparece a la altura del .csproj, éste no se usa.

Dockerfile

  • Debemos asegurarnos que la ruta del COPY del .csproj (en este caso en la línea 7) sea correcto, tiene como punto de vista la carpeta donde está el Dockerfile (aclarado en el apartado anterior).
  • En este caso la aplicación correrá sobre #Linux.

Código del Dockerfile

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["API_Test/API_Test.csproj", "API_Test/"]
RUN dotnet restore "API_Test/API_Test.csproj"
COPY . .
WORKDIR "/src/API_Test"
RUN dotnet build "API_Test.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "API_Test.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "API_Test.dll"]

Edición del Helm Chart

Value.yaml

Una gran facilidad que nos brinda esta herramienta es la posibilidad de establecer determinadas variables, para que en el CD (en esta caso con Argo) se genere dinámicamente el deploy, el service y el ingress.

Entonces cargamos el archivo de la siguiente manera.

fullnameOverride: api-test-k8s
replicaCount: 1

image:
  repository: docker.io/sricagno/test-api10
  tag: 35
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

deployment:
  containerPort: 80

ingress:
  enabled: true
  annotations: {}
  host: api-test-k8s.54cuatrocicd.10.63.32.30.xip.io
  path: /weatherforecast

Ingress.yaml:

Ahora editamos el ingress.yaml en la sección de rules del archivo.

El archivo original:

Finalmente lo dejamos así:

{{- end }}
  rules:
    - host: {{ .Values.ingress.host }}
      http:
        paths:
          - path: {{ $ingressPath }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: http
{{- end }}

Sacamos el “range” de la línea 34 y 42 (“{{- end}}”), ya que no queremos tener más de un host. Por último en host ponemos el nombre de la variable de host que vamos a usar en este caso .Values.ingress.host.

Pipeline CI en Azure DevOps

Creamos un pipeline en Azure DevOps, al crear un nuevo Pipeline en la parte inferior nos permite seleccionar “usar el editor clásico” y así es como continuamos: seleccionamos la rama del repositorio a implementar y elegimos “empty job”.

Nos mostrará una pantalla como las siguientes. Agregamos un por una las 3 tareas.

Tarea 1

Tarea 2

Tarea 3

Como repositorio de #Docker usamos Docker Hub.

Si no tenemos registrado en Azure DevOps el repositorio de Dockers, lo podemos administrar desde “Manage”, debemos dar de alta el repositorio donde almacenaremos la imagen Docker.

CD con ArgoCD

Como mencionamos al principio, teníamos instalado y configurado #ArgoCD sobre #Rancher.

Dentro de Argo, previamente, conectamos el repositorio de Azure.

Creamos una aplicación nueva

Establecemos los siguientes parámetros.

Nota

Si lo ingresado anteriormente está bien, se puede leer el Helm un poco más abajo. Como aparece a continuación.

Finalmente le damos a Create y luego sincronizamos.

Si todo se ejecutó de manera correcta se debería haber desplegado la imagen, creado un servicio y un ingress, en Rancher:

En Rancher

Despliegue

Servicio

Ingress

Probamos la aplicación

Finalmente accedemos a la aplicación, esto se rutea a través de KongHQ.

Respuesta

Video relacionado

[popup_anything id=”2076″]