Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Gateway has infrastructural support for optional features and extensions (such as Video Clipping for Partial File Restorethat you can drop into your Swarm implementation as desired. (v6.1)

Installing Dynamic Features

After you obtain the optional package for your feature, you can install it on your Gateways, along with any supporting frameworks needed, such as FFmpeg, which DataCore provides preconfigured within a Docker container.

Best practice

Use Docker and install DataCore's provided container; this spares you dealing with third-party repo choices, their dependencies, and resource reconfiguration required to protect Gateway's performance. Installing without the container requires assistance from DataCore Support. 

  1. Copy the package for the feature to a server that is running Content Gateway: 
    caringo-FEATURE-VERSION.noarch.rpm
  2. If the server is running RHEL/CentOS 6.x, upgrade to RHEL/CentOS 7 (required by Docker).
  3. If it is running Content Gateway 6.0 or earlier, upgrade Gateway (versions 6.1 and higher support drop-in features such as video clipping).
    See Gateway Installation.
  4. If Content UI is version 6.1 or earlier, upgrade it to support this feature. 
    See Content UI Installation.
  5. Install the package. 

    yum install caringo-FEATURE-VERSION.noarch.rpm

    The installation creates a features.d directory under /etc/caringo/cloudgateway/, which is where Gateway detects optional, dynamic features.

  6. Install any additional frameworks, such as multimedia support via FFmpeg, which DataCore provides preconfigured in a Docker container. 
    From an Internet-connected machine: 
    1. Check whether Docker is installed: docker info
      If not, install the Docker package, then start the daemon, check its status, and enable it system-wide. See docs.docker.com/install/linux/docker-ce/centos/ 

    2. Verify Docker by running a container test:

      docker run hello-world
    3. Load the provided container: 

      docker load < caringo-gateway-VERSION.feature.FEATURE.via.docker.VERSION.x86_64
  7. Gateway will create the following directory for spooling content: /var/spool/caringo/cloudgateway/features
    If it cannot create this directory, Gateway will refuse to start.
  8. In setting  iptables rules, Docker closes external TCP access to port 80 (although ping and ssh still work); be sure to explicitly open port 80 again so that clients can access Gateway. 

    firewall-cmd --add-port=80/tcp --permanent
    firewall-cmd --reload
    systemctl restart docker
  9. Repeat the above process on any remaining Content Gateway servers.
  10. Restart the Gateway(s).
    On reboot, Content Gateway detects the feature; on a page refresh, Content UI displays the additional functionality, such as the clipping control for video content.

Metrics for Feature Usage

Dynamic features include a set of metrics that can give you visibility into how each feature is being used. (v6.2)

These are the Prometheus Node Exporter and Grafana metrics you can see about your dynamic features:

curl http://GATEWAY:9100/metrics -s | grep -i feature
caringo_gateway_feature_install_countHow many dynamic features are installed currently.
caringo_gateway_feature_invocation_countHow many times was the feature called, since the last Gateway restart.
caringo_gateway_feature_invocation_latencyHow much time, on average, did successful calls for that feature take, since the last Gateway restart. For video clipping, this will vary relative to the size of the clips being created.
caringo_gateway_feature_errors_countHow many times did the feature call fail, since the last Gateway restart.

See Prometheus Node Exporter and Grafana.

Audit Logging for Features

Each dynamic feature logs operations to provide auditing. When you create a video clip, for example, Gateway handles it asynchronously and acknowledges the request with an INVOKE message, which will appear first in your audit log. That acknowledgement references the future JSON result object. When that JSON result later posts, it reports the outcome of the clipping request, such as the ffmpeg exit code and the duration, capturing the same information that you would get back on the response if it were synchronous.

2019-08-22 14:32:04,991 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping INVOKE user1 (none) 200 0 149 38.00 d1.example.com bucket1 inputMovie.mp4
2019-08-22 14:32:15,022 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping POST user1 (none) 201 641705 46 0.09 d1.example.com bucket1 outputClip.mp4
2019-08-22 14:32:15,061 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping POST user1 (none) 201 149 46 0.04 d1.example.com bucket1 inputMovie.mp4.F38143E84D3EC62E.json

All JSON result objects are temporary, by default: they are created with a lifepoint that triggers deletion after 5 days. You can change the default in the Gateway Configuration, gateway.cfg ([dynamic_features] resultObjectLifetime=5).

See Gateway Audit Logging.

  • No labels