How to apply changes to the Controller environment
Changes in the installation.yaml can be applied by running the install script or the upgrade script. Note that re-running the install script will delete any information that would have been stored previously.
Required fields in installation.yaml
|
Variable Name
|
Key Value
|
Explanation of the Variable and Key Values
|
controller.name |
String |
This will be the identifier used in the VF Server UI. So, this should be as precise a name as possible, e.g. "UAT Viper" or "Prod App1" |
controller.host |
String |
The controller.host is the address that the vFunction Server address with which the Controller will connect. The value needs to start with http:// or https://. The value can be an IP Address or a FQDN |
controller.org_id
controller.app_id
controller.client_id
controller.client_secret
|
Strings |
Once the Server is installed, the Admin can log into the UI and create the App. In the UI's Install Controller dialog box, the YAML values for the org_id, app_id, client_id and client_secret will be displayed. The values for this YAML file should be copied for the Server UI to here |
controller.type |
String |
"dotnet" |
viper.assemblies |
List of Strings |
Path(s) to the Monolithic Application's directory where the assemblies (DLLs, EXEs, Resource Files) are placed, such as the ..\bin directory |
Sample with required fields in installation.yaml
controller:
name: Prod App1
host: http://10.0.0.143
org_id: 3cf59199-0a0a-0a0a-0a0a-7c63ffac776e
app_id: 7b1ab58d-0a0a-0a0a-0a0a-098a113ad721
client_id: 20761b99-0a0a-0a0a-0a0a-94c2e0bc1859
client_secret: 6b5b7bc1-0a0a-0a0a-0a0a-2bd10db75e2f
type: dotnet
instrconf_additions:
inclusions:
exclusions:
server_application:
agent:
version: dotnet
environment: iis
viper:
port: 8091
assemblies:
- /opt/vfunction/assemblies/
Optional fields in installation.yaml
controller.instance_id
| Installation.yaml Configuration |
Details |
controller:
instance_id: containerized
|
- Used for containerized vFunction controllers
- Can be set to any String value (e.g., ID1234)
- Used to prevent an ongoing increase in the number of Down Controllers in the vFunction Server UI's Select Controllers page when Controllers are down
- Maps a restarted controllers (i.e., a container that went down and came back up) with a controller in the down state that has the same ID
|
viper.debug_mode
| Installation.yaml Configuration |
Details |
viper:
debug_mode: true
|
- Adds additional logging to the output of the vfviper.log
|
viper.jvm_memory_params
| Installation.yaml Configuration |
Details |
viper:
jvm_memory_params: "-Xms300m -Xmx4g -Xss50m"
|
-
By default, the Viper service is started with the Memory-related settings:
-Xms300m -Xmx3g -Xss50m
- For larger applications, this may cause the static analysis to run slowly
- Increase the Max Heap Size (Xmx setting) to speed up the static analysis
|
| Classes in Namespaces(s) |
Recommended RAM |
| Less than 8k |
2gb |
| 8k-20k |
4gb |
| 20k-100k |
8gb |
Global.yaml Settings
Overview
The installation.yaml defines the settings for individual instances. The global.yaml defines the settings for all instances in the environment. The settings in the global.yaml are distinct from the settings in the installation.yaml
Location of Global.yaml
- Root / Sudo Installation: /etc/sysconfig/vfunction/installation/global.yaml
- Sudoless Installation: BASE_DIRECTORY/vfunction/etc/sysconfig/vfunction/installation/global.yaml
Optional Global.yaml Settings
agent.use_java_6_or_7_jre
| Global.yaml Configuration |
Details |
agent:
use_java_6_or_7_jre: true
|
- Uncomment this value to change from the default value of "false"to the value "true"
- Setting this value to "true" will allow the installation to use a distinct vFunction Agent version intended for Applications that run on Java 6 or 7
- Leaving this value as "false" or commented out will allow the installation to use the vFunction Agent intended for Applications that run on Java 8, 11 or 17
|
controller.poll_interval_secs
| Global.yaml Configuration |
Details |
controller:
poll_interval_secs: 5
|
- By default, the vFunction Agents attempt to reach the vFunction Server every five seconds with an Alive message. This workflow helps the Server know which Agents are Up. And, the Server's response to this Alive message initiates the Learning process for the Agents
- The polling interval can be increased or decreased as desired
|
controller.upload_interval_secs
| Global.yaml Configuration |
Details |
controller:
upload_interval_secs: 15
|
- By default when in Learning, the vFunction Agent collects all traces from the Application and sends these traces to the vFunction Server every 15 seconds for analysis
- This upload interval can be increased or decreased as desired
|
general.custom_logs_folder
| Global.yaml Configuration |
Details |
general:
custom_logs_folder: /path/to/desired/folder
|
- By default, the vFunction Agent writes logs to (sudo) /var/log/vfunction/instances/$INSTANCE_NAME or (sudoless) $BASE_INSTALL_DIR/vfunction/var/log/vfunction/instances/$INSTANCE_NAME. The logging directory can be changed to a separate location as desired
|
general.sleep_after_service_start
| Global.yaml Configuration |
Details |
general:
sleep_after_service_starts:
|
- This setting is useful for Viper only. After running the installation / upgrade / restart script, the script and / or Service goes to sleep for 1 second by default. Then the Service attempts to connect to the vFunction Server. This setting adjusts the amount of time before the connectivity attempt is made
|
general.sleep_after_service_stop
| Global.yaml Configuration |
Details |
general:
sleep_after_service_stop:
|
- This setting is useful for Viper only. After running the installation / upgrade / restart script, the script and / or Service attempts to confirm that the Service is actually stopped. This setting adjusts the amount of time before the attempt is made to confirm that the Service was actually stopped
|
proxy.http_proxy
| Global.yaml Configuration |
Details |
proxy:
http_proxy:
|
- Ensures that all HTTP outbound requests from the vFunction Agent to the vFunction Server are routed through a proxy
- Formatting should include the protocol and port, e.g. http://proxy.address:2197
|
proxy.https_proxy
| Global.yaml Configuration |
Details |
proxy:
https_proxy:
|
- Ensures that all HTTPS outbound requests from the vFunction Agent to the vFunction Server are routed through a proxy
- Formatting should include the protocol and port, e.g. https://proxy.address:2198
|
proxy.no_proxy
| Global.yaml Configuration |
Details |
general:
no_proxy:
|
- This setting ensures that specific addresses are not routed through the HTTP_PROXY and / or HTTPS_PROXY address. This setting is useful if some traffic, such as to a logging processor, are routed internally rather than through a proxy
|
viper.use_machine_java_for_viper
| Global.yaml Configuration |
Details |
viper:
use_machine_java_for_viper: true
|
- With this value set to "false" or commented out, the vFunction installation installs its own version of Java in order for the Viper process to run
- If uncommented and set to "true", the vFunction installation will use the Java version running on the machine where the installation is run
|