10. Project components

This page intends to describe the different software projects and components used for ArmoniK internals. To learn how to install or use ArmoniK, please refer to these repositories:

• install: ArmoniK

• use: ArmoniK.Samples

10.1. Deployment topology

The following diagram shows a full local deployment (just build-deploy). Optional components are annotated; core components are always present.

        graph TB
    Client(["External Client<br/>(gRPC)"])

    subgraph Ingress ["Ingress<br/>(optional — ingress=true)"]
        nginx_http["nginx :5201 (HTTP)"]
        nginx_tls["nginx :5202 (TLS)"]
        nginx_mtls["nginx :5203 (mTLS)"]
    end

    subgraph Control ["Control Plane"]
        submitter["Submitter<br/>armonik.control.submitter<br/>1080→5001 gRPC | 1081→5011 metrics"]
        metrics["Metrics Exporter<br/>armonik.control.metrics<br/>1080→5002"]
    end

    subgraph Compute ["Compute Plane (× replicas)"]
        pa["PollingAgent<br/>armonik.compute.pollingagentN<br/>1080→998N health"]
        worker["Worker<br/>armonik.compute.workerN<br/>1080→108N"]
        pa <-->|"Unix socket / TCP"| worker
    end

    subgraph Storage ["Storage"]
        queue[("Queue<br/>ActiveMQ / RabbitMQ<br/>NATS / SQS / Pub/Sub")]
        db[("MongoDB<br/>:27017")]
        obj[("Object Storage<br/>Redis / MinIO / GCS<br/>/ Local / Embed")]
    end

    subgraph Monitoring ["Monitoring"]
        fluent["Fluent Bit<br/>:24224 (always)"]
        seq["Seq :4080<br/>(seq=true)"]
        prom["Prometheus :9090<br/>(prometheus=true)"]
        grafana["Grafana :3000<br/>(grafana=true)"]
        otel["OpenTelemetry Collector<br/>:4317 (tracing optional)"]
        zipkin["Zipkin :9411<br/>(tracing optional)"]
    end

    Client --> Ingress
    Ingress --> submitter
    submitter --> queue
    submitter --> db
    submitter --> obj
    pa --> queue
    pa --> db
    pa --> obj
    metrics --> db
    metrics --> queue
    prom --> metrics
    prom --> pa
    grafana --> prom
    fluent --> seq
    otel --> zipkin
    

Container count for a default deployment (replicas=3): ~16 containers (3 PollingAgents + 3 Workers + Submitter + Metrics + MongoDB + Queue + ObjectStorage + FluentBit + Seq + Prometheus + Grafana + Ingress).

All containers share the armonik_network Docker bridge network (or nat on Windows).

10.2. Common Library

• ArmoniK.Core.Common provides the components required by all the other components of ArmoniK.

• ArmoniK.Core.Base provides the classes and interfaces to create plugins that can be dynamically loaded at ArmoniK startup. It allows to remplace the plugins provided by default by more adapted solutions. For more information, see Plugins.

• ArmoniK.Core.Utils provides some simplifiaction methods that are commonly used in ArmoniK.Core projects.

10.3. Control

Different projects are available in the control plan:

• ArmoniK.Control.Submitter is a web server providing the gRPC services to interact with ArmoniK. It provides the following gRPC services defined in ArmoniK.Api:

  • Tasks Service: Provides APIs to perform actions on tasks like submission, monitoring and cancellation.

  • Results Service: Provides APIs to perform actions on results like creation, data upload and download, monitoring, deletion, etc…

  • Partitions Service: Provides APIs to perform actions on partitions like creation and monitoring.

  • Sessions Service: Provides APIs to perform actions on sessions like creation, monitoring, cancellation, closing, deletion of data, etc…

  • Authentication Service: Manages users and their permissions when submitting tasks and accessing data in ArmoniK.

  • Applications Service: List applications defined by ArmoniK.Extensions.Csharp.

  • Events Service: Provides streaming APIs to listen to Tasks and Results related real time events.

  • Versions Service: Provides the current version of ArmoniK internal components.

  • Health Checks Service: Provides health status for ArmoniK dependant services.

• ArmoniK.Control.Metrics is a web server that exposes Prometheus metrics related to the number of tasks per status in each partition. These information can be used to determine the number of compute plane instances required on the grid. In addition, these metrics can be used by Kubernetes to start/stop compute PODs and nodes (on elastic configurations such as managed Kubernetes services on cloud).

10.4. Compute Plane Components

From a software enginnering point of view, the compute plan relies on three components:

• ArmoniK.Compute.PollingAgent implements a ArmoniK.DevelopmentKit.Gridlib.GRPC client. It acts as a proxy between the gridlib agent container and the rest of the ArmoniK system. Using such a proxy agent allows all the ArmoniK logic to be implemented independantly of the Gridlib agent. Hence handling an new agent to handle new languages will be easier.

• Other companion containers for the gridlib agent container Such cantainers could provide the following services:

  • setting up secrets for the POD

  • forward the logs to a log cypher (ex: ELK or a cloud equivalent)

  • host a cache on each node used (required a deamon set to be really efficient)