-Welcome to Arvados!
+Welcome to the Arvados Project!
-The main Arvados web site is
+Arvados is an open source distributed computing platform for bioinformatics,
+data science, and high throughput analysis of massive data sets. Arvados
+supports a variety of cloud, cluster and HPC environments. Arvados consists of
+a content-addressable storage system "Keep" for managing and storing large
+collections of files; a containerized workflow engine "Crunch" designed for
+versioning, reproducibilty, and provenance of computations; and a variety
+related services and components including APIs, SDKs, and visual tools.
+
+The main Arvados web site is
https://arvados.org
-The Arvados public wiki is located at
+The Arvados public wiki is located at
https://dev.arvados.org/projects/arvados/wiki
-The Arvados public bug tracker is located at
+The Arvados public bug tracker is located at
https://dev.arvados.org/projects/arvados/issues
-For support see
+For support see
http://doc.arvados.org/user/getting_started/community.html
-Installation documentation is located at
+Installation documentation is located at
http://doc.arvados.org/install
-If you wish to build the documentation yourself, follow the instructions in
-doc/README to build the documentation, then consult the "Install Guide".
+To try out Arvados quickly, you can use Arvbox, which provides Arvados
+components pre-installed in a Docker container (requires Docker 1.9+). After
+cloning Arvados:
+
+ $ cd arvados/tools/arvbox/bin
+ $ ./arvbox start localdemo
+
+See http://doc.arvados.org/install/arvbox.html for details and documentation.
+
+If you wish to build the Arvados documentation yourself, follow the
+instructions in doc/README to build the documentation, then consult the
+"Install Guide".
See COPYING for information about Arvados Free Software licenses.
title: Arvados-in-a-box
...
-Arvbox is a Docker-based self-contained development, demonstration and testing
-environment for Arvados. It is not intended for production use.
+Arvbox is a Docker-based self-contained development, demonstration and testing environment for Arvados. It is not intended for production use.
-## Quick start
+h2. Quick start
-```
+<pre>
arvados/tools/arvbox/bin$ ./arvbox start localdemo
-```
+</pre>
-## Usage
+h2. Usage
-```
+<pre>
Arvados-in-a-box
arvbox (build|start|run|open|shell|ip|stop|reboot|reset|destroy|log|svrestart)
log <service> tail log of specified service
sv <start|stop|restart> <service> change state of service inside arvbox
clone <from> <to> clone an arvbox
-```
+</pre>
-## Requirements
+h2. Requirements
* Linux 3.x+ and Docker 1.9+
* Minimum of 3 GiB of RAM + additional memory to run jobs
* Minimum of 3 GiB of disk + storage for actual data
-## Configs
-
-### dev
-Development configuration. Boots a complete Arvados environment inside the
-container. The "arvados", "arvado-dev" and "sso-devise-omniauth-provider" 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 (sso, api,
-workbench). This can be used to test out API server settings or point
-Workbench at an alternate API server.
-
-### localdemo
-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.
-
-### test
+h2. Configs
+
+h3. dev
+
+Development configuration. Boots a complete Arvados environment inside the container. The "arvados", "arvado-dev" and "sso-devise-omniauth-provider" 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 (sso, api, workbench). This can be used to test out API server settings or point Workbench at an alternate API server.
+
+h3. localdemo
+
+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.
+
+h3. test
+
Run the test suite.
-### publicdev
-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. WARNING! The public arvbox configuration
-is NOT SECURE and must not be placed on a public IP address or used for
-production work.
+h3. publicdev
+
+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. WARNING! The public arvbox configuration is NOT SECURE and must not be placed on a public IP address or used for production work.
+
+h3. publicdemo
-### publicdemo
-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. 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. WARNING! The public arvbox configuration is NOT SECURE and must not be placed on a public IP address or used for production work.
-## Environment variables
+h2. Environment variables
+
+h3. ARVBOX_DOCKER
-### ARVBOX_DOCKER
The location of Dockerfile.base and associated files used by "arvbox build".
default: result of $(readlink -f $(dirname $0)/../lib/arvbox/docker)
-### ARVBOX_CONTAINER
+h3. ARVBOX_CONTAINER
+
The name of the Docker container to manipulate.
default: arvbox
-### ARVBOX_BASE
+h3. ARVBOX_BASE
+
The base directory to store persistent data for arvbox containers.
default: $HOME/.arvbox
-### ARVBOX_DATA
+h3. ARVBOX_DATA
+
The base directory to store persistent data for the current container.
default: $ARVBOX_BASE/$ARVBOX_CONTAINER
-### ARVADOS_ROOT
+h3. ARVADOS_ROOT
+
The root directory of the Arvados source tree
default: $ARVBOX_DATA/arvados
-### ARVADOS_DEV_ROOT
+h3. ARVADOS_DEV_ROOT
+
The root directory of the Arvados-dev source tree
default: $ARVBOX_DATA/arvados-dev
-### SSO_ROOT
+h3. SSO_ROOT
+
The root directory of the SSO source tree
default: $ARVBOX_DATA/sso-devise-omniauth-provider
-### ARVBOX_PUBLISH_IP
-The IP address on which to publish services when running in public
-configuration. Overrides default detection of the host's IP address.
+h3. ARVBOX_PUBLISH_IP
+
+The IP address on which to publish services when running in public configuration. Overrides default detection of the host's IP address.
-## Notes
+h2. Notes
-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 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.
+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.
projects / arvados.git / commitdiff