ark_helm_charts

ArkCase Development Integration

This document describes the model and configuration for developers to integrate their local development environments with an ArkCase Helm chart deployment. As with any community-release project, Issues and PRs are always welcome to help move this code further along.

The ArkCase helm chart supports enabling development mode by way of a map whose fully-populated structure matches the following:

global:
  dev:
    # Enable or disable development mode, explicitly ... if the global.dev map is not empty,
    # and this flag is not explicitly set to false, development features will be enabled.
    enabled: true

    # Use the given WAR files or exploded WAR directories listed for execution. The path must be
    # an absolute path. If the path specification has a "path:" prefix, it's assumed to be a
    # local directory containing an "exploded WAR" directory structure.
    #
    # To indicate a file (i.e. an actual WAR file), you must use the prefix "file:".
    #
    # This will result in the use of a hostPath volume by the core pod(s) that will point to
    # either the given file or directory.
    #
    # Directories will be directly accessible by the Tomcat runtime, while files will instead
    # be treated like normal artifacts and be extracted and deployed during the deployment phase.
    wars:
      arkcase: "path:/mnt/c/Users/developer/workspace/ArkCase/WAR"
      foia: "file:/mnt/c/Users/developer/workspace/ArkCase/foia.war"
      # another#war: "file:/mnt/c/Users/developer/workspace/ArkCase/some/other/path.war"

    # Use the ArkCase configuration zip file or exploded zip directory at this location for execution.
    # the syntax and logic is identical for the war component, except this is for the .arkcase configuration
    # file set.
    #
    # This will result in the use of a hostPath volume by the core pod(s)
    conf: "path:/mnt/c/Users/developer/.arkcase"
    # conf: "file:/mnt/c/Users/developer/workspace/ArkCase/target/.arkcase.zip"

    # This section allows you to modify existing loggers, or add new ones.  The format
    # is a map, where the key is the name of the logger, and the value is the Log4J level
    # (for safety, quote both strings ... we've had some strange behavior with unquoted
    # strings).
    #
    # Importantly, a master flag (enabled) is supported, and can be used to turn on or off
    # all the custom logs at once. Its value is assumed as "true" if it's not specified.
    logs:
      # enabled: true
      "my.new.logger": "debug"
      "org.eclipse.persistence.logging.metadata": "off"
      # ... etc

    # The settings in this map govern the debugging features
    debug:
      # Whether to enable or disable debugger features. Debugger features will be enabled if the debug map
      # is not empty, and the enabled flag is not explicitly set to "false"
      enabled: true

      # The port to listen on for JDB connections. If not specified, the default of 8888 is used.
      port: 8888

      # This setting governs the "suspend" setting in the debugger configuration for the JVM, and is useful
      # to stop execution of any code until and unless a debugger connects to the instance (i.e. for
      # debugging bootup issues). The default value is "false".
      suspend: true

Enabling Host Path Persistence

Among the helm charts available for deployment is the arkcase/hostpath-provisioner chart. This chart will deploy a CSI provisioner service that will allow the use of HostPath volumes backed by a cluster node’s local filesystem. This provisioner should only be used in single-node cluster environments (i.e. development environments) since the provisioner doesn’t fully support multi-node clusters. In particular: when a volume is provisioned by this component, even though it’s visible to the entire cluster, only one of the nodes will contain the data (the node on which the provisioner is running), and this data will only be accessible to pods running on that node.

Hence, why it’s only appropriate in single-node clusters: no such discrepancy will arise.

In order to deploy the provisioner, you may use the following command:

$ helm install --create-namespace --namespace hostpath-provisioner hostpath-provisioner arkcase/hostpath-provisioner

The provisioner has many available configurations. The most important one is the value hostPath, which indicates the place within the node’s filesystem the volumes will be provisioned (the default is /opt/app):

# Set the host path to /k8s/hostPath
hostPath: "/k8s/hostPath"

The path must normalize (i.e. after removing . and .. components) to an absolute path, or an error will result. The component creates a storageClass with the name hostpath (this name is configurable via the storageClass.name value), which can also be earmarked as the default storage class for the cluster (this behavior can be overridden with the value storageClass.defaultClass).

Developer Workstations

This documentation will be added soon

Developer Ingress

For development mode, the Ingress that’s normally created for production access is also created, with some key additions: