Arvbox is a Docker-based self-contained development, demonstration and testing environment for Arvados. It is not intended for production use.
$ git clone https://github.com/arvados/arvados.git $ cd arvados/tools/arvbox/bin $ ./arvbox start localdemo $ ./arvbox adduser demouser email@example.com
You can now log in as
demouser using the password you selected.
$ arvbox Arvados-in-a-box https://doc.arvados.org/install/arvbox.html start|run <config> [tag] start arvbox container stop stop arvbox container restart <config> stop, then run again status print some information about current arvbox ip print arvbox docker container ip address host print arvbox published host shell enter shell as root ashell enter shell as 'arvbox' psql enter postgres console open open arvbox workbench in a web browser root-cert get copy of root certificate update <config> stop, pull latest image, run build <config> build arvbox Docker image reboot <config> stop, build arvbox Docker image, run rebuild <config> build arvbox Docker image, no layer cache checkpoint create database backup restore restore checkpoint hotreset reset database and restart API without restarting container reset delete arvbox arvados data (be careful!) destroy delete all arvbox code and data (be careful!) log <service> tail log of specified service ls <options> list directories inside arvbox cat <files> get contents of files inside arvbox pipe run a bash script piped in from stdin sv <start|stop|restart> <service> change state of service inside arvbox clone <from> <to> clone dev arvbox adduser <username> <email> add a user login removeuser <username> remove user login listusers list user logins
Arvbox creates root certificate to authorize Arvbox services. Installing the root certificate into your web browser will prevent security errors when accessing Arvbox services with your web browser. Every Arvbox instance generates a new root signing key.
chrome://settings/certificatesin the URL bar.
about:preferences#privacyin the URL bar and then choosing “View Certificates…”.
The certificate will be added under the “Arvados testing” organization as “arvbox testing root CA”.
To access your Arvbox instance using command line clients (such as arv-get and arv-put) without security errors, install the certificate into the OS certificate storage (instructions for Debian/Ubuntu):
Development configuration. Boots a complete Arvados environment inside the container. The “arvados” and “arvados-dev” code directories along data directories “postgres”, “var”, “passenger” and “gems” are bind mounted from the host file system for easy access and persistence across container rebuilds. Services are bound to the Docker container’s network IP address and can only be accessed on the local host.
In “dev” mode, you can override the default autogenerated settings of Rails projects by adding “application.yml.override” to any Rails project (api, workbench). This can be used to test out API server settings or point Workbench at an alternate API server.
Demo configuration. Boots a complete Arvados environment inside the container. Unlike the development configuration, code directories are included in the demo image, and data directories are stored in a separate data volume container. Services are bound to the Docker container’s network IP address and can only be accessed on the local host.
Starts postgres and initializes the API server, then runs the Arvados test suite. Will pass command line arguments to test runner. Supports test runner interactive mode.
Starts a minimal container with no services and the host’s $HOME bind mounted inside the container, then enters an interactive login shell. Intended to make it convenient to use tools installed in arvbox that don’t require services.
Publicly accessible development configuration. Similar to ‘dev’ except that service ports are published to the host’s IP address and can accessed by anyone who can connect to the host system. See below for more information. WARNING! The public arvbox configuration is NOT SECURE and must not be placed on a public IP address or used for production work.
Publicly accessible development configuration. Similar to ‘localdemo’ except that service ports are published to the host’s IP address and can accessed by anyone who can connect to the host system. See below for more information. WARNING! The public arvbox configuration is NOT SECURE and must not be placed on a public IP address or used for production work.
The location of Dockerfile.base and associated files used by “arvbox build”.
default: result of $(readlink -f $(dirname $0)/../lib/arvbox/docker)
The name of the Docker container to manipulate.
The base directory to store persistent data for arvbox containers.
The base directory to store persistent data for the current container.
The root directory of the Arvados source tree
The root directory of the Arvados-dev source tree
The IP address on which to publish services when running in public configuration. Overrides default detection of the host’s IP address.
The Arvbox section of Hacking Arvados has information about using Arvbox for Arvados development.
In “dev” and “localdemo” mode, Arvbox can only be accessed on the same host it is running. To publish Arvbox service ports to the host’s service ports and advertise the host’s IP address for services, use
$ arvbox start publicdemo
This attempts to auto-detect the correct IP address to use by taking the IP address of the default route device. If the auto-detection is wrong, you want to publish a hostname instead of a raw address, or you need to access it through a different device (such as a router or firewall), set
ARVBOX_PUBLISH_IP to the desire hostname or IP address.
$ export ARVBOX_PUBLISH_IP=example.com $ arvbox start publicdemo
Note: this expects to bind the host’s port 80 (http) for workbench, so you cannot have a conflicting web server already running on the host. It does not attempt to take bind the host’s port 22 (ssh), as a result the arvbox ssh port is not published.
Services are designed to install and auto-configure on start or restart. For example, the service script for keepstore always compiles keepstore from source and registers the daemon with the API server.
Services are run with process supervision, so a service which exits will be restarted. Dependencies between services are handled by repeatedly trying and failing the service script until dependencies are fulfilled (by other service scripts) enabling the service script to complete.
The content of this documentation is licensed under the
Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.