Skip to content

Install for Evaluation

Getting a single-node Stroom running in Docker, pre-loaded with content and already processing data.

Running Stroom in Docker is the quickest way to see it work: no Java to install, no MySQL to configure, nothing to tune. This is for evaluation only, and nothing on this page is production configuration.

Which stack

Stroom ships several predefined Docker stacks, each a set of containers wired together. For this walk-through use stroom_core_test.

It is the right one for two reasons. It comes with an admin account already created, and it is pre-loaded with content and configured to start processing on boot, so there is real data to look at within minutes of starting it.

The other stacks create no accounts at all, and need an administrator to be created from the command line first.

Install and start

bash <(curl -s https://gchq.github.io/stroom-resources/v7.14/get_stroom.sh)
cd stroom_core_test*
./start.sh

If piping a downloaded script into bash is not something you are willing to do, fetch the release archive yourself from the gchq/stroom-resources releases, extract it, and run ./start.sh from the extracted directory. Pick the version you want rather than the one the script chooses.

How long: not immediate

Allow a few minutes on first run. Stroom builds its database schemas when it first starts, and nothing responds until that finishes.

start.sh prints the URLs it has set up when it is done.

Check it worked

Open https://localhost in a browser and sign in with username admin and password admin. You will have to accept the self-signed certificate.

Then, in the explorer tree on the left, double-click System to see every stream Stroom holds. There should already be some: the stack runs a log sender that forwards Stroom's own application, user and request logs back into Stroom, and processing is on by default.

The check that matters most

Streams are listed under System, with create times from the last few minutes.

That one screen proves more than it looks: the database is up, the UI can reach it, data is being received, and processing is running. If you see streams, the whole stack works.

This does not prove it worked

The login page rendering is not proof the stack is up. Stroom will serve its UI while the database is still building its schemas, and the first thing you do will fail.

An empty stream list is not necessarily a failure, if you got there within a minute or two of starting. Wait, then look again.

Destroys data

This stack is for evaluation, and the credentials are published.

admin/admin is in every copy of these instructions, the certificate is self-signed, and the configuration is tuned for starting quickly rather than for keeping anything safe.

Do not put real data in it, and do not expose it beyond your own machine.

If it isn't working

In order. Each step rules out a class of cause, so don't skip ahead.

  1. Is it still starting? First run builds the database. Give it a few minutes before concluding anything.
  2. Did start.sh report errors? Read its output. Port clashes on 443 are the usual cause, if something else on the machine is already serving HTTPS.
  3. Are the containers running? docker ps should show several. One that keeps restarting is the one to look at, with docker logs.
  4. Is there enough disk and memory? The stack runs Stroom, two proxies (local and remote), a log sender, nginx and MySQL together, and MySQL in particular fails in confusing ways when it cannot write.
  5. Does the browser refuse the certificate outright? Some browsers will not let you past a self-signed certificate on localhost without an explicit exception. Try another browser before assuming Stroom is down.

Next

The stack is already processing its own logs. Next, send it something of your own.

All documentation