Installing CloudShark via Docker
CloudShark in Docker
Starting with CloudShark 3.9.0, users are able to deploy in a Docker environment. This document provides an overview of the environment and a sample docker-compose.yaml file that may be used as a starting point for your own deployment. These settings are intended to be used as an example for your container management platform of choice.
The CloudShark Base Image
All of the CloudShark services run on top of our base image. A download link to this image must be provided to you by Technical Support. Once you have downloaded it, it can be loaded into your docker environment.
$ docker load < cloudshark-3.9.0-05192021.tar.gz
The following services are run from this one image:
The CloudShark services all must share the following volume in order for them to store and have access to the underlying pcap data.
Additionally, the license file and an auto-import directory should be made available across all the CloudShark services:
The CloudShark services use the following environment variables to control how they talk to each other, and how they connect to the required 3rd-party services outlined below.
3rd-Party / Open Source Services
The following 3rd-party or Open Source services are required for CloudShark to run. These may be replaced with vendor-specific instances that are compatible. For example, you may replace MariaDB with Amazon AuroraDB as long as it is compatible with MariaDB/MySQL.
The database service must have a database created that has full read-write permissions for the user specified in the environment variable above.
There are a few known issues and environment-specific things that need to be done outside of this guide.
After adding or removing an Auto-Import location from within the CloudShark web interface, the `auto-import` service must be restarted from the container management system for the changes to take effect.
In order for Auto-Delete and Quota Reset to happen automatically, periodic jobs must be scheduled to run from outside the container. These are currently not available and are returning in CloudShark 3.9.1.
Below is our sample docker-compose.yaml file showing how to configure all of these services together. While Docker does not recommend using compose in production, it still serves as a concrete, easy to translate example of how all the service interact.
Note, we've used YAML anchors to extract the shared environment and volumes sections.
entrypoint: ["/usr/cloudshark/ruby/bin/ruby", "/usr/cloudshark/app/bin/search-worker"]
entrypoint: ["/usr/cloudshark/app/bin/autoimport", "--sock", "web:9292"]
entrypoint: ["/usr/cloudshark/bin/tf_service", "-sharkd", "/usr/cloudshark/bin/sharkd", "-path", "/usr/cloudshark/data", "-profiles", "/usr/cloudshark/data", "-idle", "55s", "-addr", ":6783"]
If you are using the above with docker-compose, the first time you start the environment, you will need to run the MariaDB container first by itself.
$ docker-compose up --no-start
$ docker-compose start mariadb
Once it is running, the default database name will be automatically created. Then you can start the rest:
$ docker-compose up