Install vFunction Server into AWS ECS?

Installing the vFunction Server into Amazon Web Services’s (AWS) Elastic Container Service (ECS) is not supported.

vFunction does not support running the Docker Containers of the vFunction Server in the ECS infrastructure.

The vFunction Server is packaged and validated for deployment via Kubernetes, OpenShift or as a standalone host installation. All of these deployment workflow assume a standard Kubernetes API or a persistent host with direct filesystem and process control. ECS’s task-based orchestration model doesn’t provide the same primitives (e.g., native Helm chart support, StatefulSet-style persistent volumes, and Kubernetes-native service discovery) that the vFunction Server’s installation and upgrade tooling depends on.

Installing the vFunction Server as an Elastic Compute Cloud (EC2) Linux Host or in an Elastic Kubernetes Service (EKS) Cluster is supported.

Install vFunction Server as an Operator or via Helm in Kubernetes?

For Kubernetes, our first and strongly preferred recommendation is to install the vFunction Server with our Kubernetes Operator. It’s the most complete way to run vFunction on Kubernetes:

We only move to the Helm-based installation if the Operator isn’t technically possible since the Operator registers a Custom Resource Definition and cluster-level RBAC. So, the Operator requires ClusterAdmin access.

If we do move to Helm, we’ll need to use the vFunction installation & upgrade scripts and installation.yaml. Deploying the chart through third-party tooling such as Argo with a chart hosted in GitHub is not supported. Our scripts handle config merging and validation, secrets, initialization and, most importantly, upgrades between versions. We can’t support the environment or confirm upgrades are successful if done outside of the vFunction scripts.

Hosted Helm Charts for vFunction Server via Helm?

vFunction does not publish a hosted Helm repository. Both the online and offline vFunction Helm packages are TGZs that include the chart together with the vFunction installer. This is intentional to ensure the vFunction scripts are used to handle config merging and validation, secrets, initialization and, most importantly, upgrades between versions.

Can a

How many Agent and Viper instances?

Quick Answer:

1 Viper, As-Desired Agents

Explanation:

Only one Viper instance should be installed per vFunction Applications. If the assemblies / binaries are distinct across running JVMs / CLRs, bring all of the assemblies / binaries to one machine where Viper can run.

As many Agents as desired can be run to profile an application. If the application is load-balanced across multiple instances, the vFunction Agent is only required on one instance. If the application has multiple instances that each perform their own function, the Agent should be installed on each instance.

How to profile multiple Instances on the same Application Server or Windows Server?

Quick Answer:

1-to-1 vFunction instance with Application instance

Explanation:

A separate vFunction Agent needs to be installed for each instance of an application that needs to be profiled. This includes circumstances where the instances are running on the same Application Server or Windows Server. For example, these scenarios would require multiple vFunction Agent installations:

1. The .NET Application runs as multiple IIS Sites on the same Windows Server
2. The .NET Application runs as multiple Windows Services on the same Windows Server
3. The Java Application runs as multiple Tomcat instances on the same Application Server

To plan for this type of installation:

1. Run the create-instance script for each required instance

2. Modify the installation.yaml for each instance. Note that the Ports used for communication are iterated for each new instance if you’re planning to just copy-and-paste installation.yaml files from one instance to another.

3. Run the installation script per instance. Note that the Agent Mode flag is being used to avoid running multiple instances of Viper.

Install vFunction Agent with other Agents?

Quick Answer:

Java supports multiple Agents simultaneously, .NET supports one Agent at a time.

Explanation:

Java Agents

Java applications support multiple Agents simultaneously. You can install the vFunction Agent for your Monolithic Application and / or the Open Telemetry Agent for Distributed Applications as well as any third-party applications. When adding new Agents, be mindful of compatibility issues and gather logs if you find any issues. There are no known compatibility issues between the vFunction Agent and third-party Agents.

.NET Agents

.NET applications support only one enabled Agent at a time as a Microsoft limitation. If there is a need to use the vFunction Agent as well as an additional Third-Party Agent, vFunction recommends to deploy the application with an IF / ELSE statement with a flag that enables one component and disables another when the application starts. This will allow you to switch back-and-forth between the Agents as desired. For example:

if ($VF_ON=0) {
  ### Add Environmental Variables for Third-Party Agent

}else{
  $env:VF_AGENT_CONF_LOCATION='C:\vfunction\config\agent\instances\default-dotnet\conf.json'
  $env:CORECLR_PROFILER_PATH_64='C:\vfunction\agent\vfagent.net.dll'
  $env:CORECLR_PROFILER_PATH_32='C:\vfunction\agent\vfagent.net.x86.dll'
  $env:CORECLR_ENABLE_PROFILING = '1'
  $env:CORECLR_PROFILER = '{cd7d4b53-96c8-4552-9c11-6e41df8eab8a}'
  $env:DOTNET_TailCallOpt = 0
}
& 'C:\path\to\run\app.exe'

Processes or Services on Windows?

Quick Answer:

Services if Admin Access

Explanation:

The default vFunction Controller Installation on a Windows Server is to use Services. This requires Administrator access to create and start the services. As a benefit, these services will be restarted if the Windows Server is restarted.

Alternatively, the vFunction Controller Installation can be completed without Administrator access by running the Controller and Viper as processes.

Use the -runAsServices false flag when running the install.ps1 script to switch from the default Services to processes.

Viper as a Process or Viper in the CICD?

Quick Answer:

Process for Modernization, CICD for Observability

Explanation:

Viper can be integrated into an organization’s CICD. In this flow, a script runs that creates a Full Graph JSON of the dependency structure for a binary or assembly. This Full Graph JSON is then uploaded to the vFunction Server to help analyze how an application changes across releases. Viper in the CICD is perfect for architectural observability and maintaining low technical debt and high visibility of the application’s architecture.

When run as a process, Viper also creates a Full Graph JSON each time the binaries or assemblies for the application change. Additionally, Viper gets the compiletime information for each Domain to ensure that a Domain can be extracted as a runnable Service with all required components. Therefore, Viper running as a process is required for organizations that intend to modernize their application.