README.md

   1 # Arvados-in-a-box
   2
   3 Self-contained development, demonstration and testing environment for Arvados.
   4
   5 ## Quick start
   6
   7 ```
   8 $ bin/arvbox reboot localdemo
   9 ```
  10
  11 ## Usage
  12
  13 ```
  14 Arvados-in-a-box
  15
  16 arvbox (build|start|run|open|shell|ip|stop|reboot|reset|destroy|log|svrestart)
  17
  18 build <config>      build arvbox Docker image
  19 start|run <config>  start arvbox container
  20 open       open arvbox workbench in a web browser
  21 shell      enter arvbox shell
  22 ip         print arvbox ip address
  23 stop       stop arvbox container
  24 restart <config>  stop, then run again
  25 reboot  <config>  stop, build arvbox Docker image, run
  26 reset      delete arvbox arvados data (be careful!)
  27 destroy    delete all arvbox code and data (be careful!)
  28 log       <service> tail log of specified service
  29 svrestart <service> restart specified service inside arvbox
  30 clone <from> <to>   clone an arvbox
  31 ```
  32
  33 ## Requirements
  34
  35 * Linux 3.x+ and Docker 1.9+
  36 * Minimum of 3 GiB of RAM  + additional memory to run jobs
  37 * Minimum of 3 GiB of disk + storage for actual data
  38
  39 ## Configs
  40
  41 ### dev
  42 Development configuration.  Boots a complete Arvados environment inside the
  43 container.  The "arvados", "arvado-dev" and "sso-devise-omniauth-provider" code
  44 directories along data directories "postgres", "var", "passenger" and "gems"
  45 are bind mounted from the host file system for easy access and persistence
  46 across container rebuilds.  Services are bound to the Docker container's
  47 network IP address and can only be accessed on the local host.
  48
  49 ### localdemo
  50 Demo configuration.  Boots a complete Arvados environment inside the container.
  51 Unlike the development configuration, code directories are included in the demo
  52 image, and data directories are stored in a separate data volume container.
  53 Services are bound to the Docker container's network IP address and can only be
  54 accessed on the local host.
  55
  56 ### test
  57 Run the test suite.
  58
  59 ### publicdev
  60 Publicly accessible development configuration.  Similar to 'dev' except that
  61 service ports are published to the host's IP address and can accessed by anyone
  62 who can connect to the host system.  WARNING! The public arvbox configuration
  63 is NOT SECURE and must not be placed on a public IP address or used for
  64 production work.
  65
  66 ### publicdemo
  67 Publicly accessible development configuration.  Similar to 'localdemo' except
  68 that service ports are published to the host's IP address and can accessed by
  69 anyone who can connect to the host system.  WARNING! The public arvbox configuration
  70 is NOT SECURE and must not be placed on a public IP address or used for
  71 production work.
  72
  73 ## Environment variables
  74
  75 ### ARVBOX_DOCKER
  76 The location of Dockerfile.base and associated files used by "arvbox build".
  77 default: result of $(readlink -f $(dirname $0)/../lib/arvbox/docker)
  78
  79 ### ARVBOX_CONTAINER
  80 The name of the Docker container to manipulate.
  81 default: arvbox
  82
  83 ### ARVBOX_BASE
  84 The base directory to store persistent data for arvbox containers.
  85 default: $HOME/.arvbox
  86
  87 ### ARVBOX_DATA
  88 The base directory to store persistent data for the current container.
  89 default: $ARVBOX_BASE/$ARVBOX_CONTAINER
  90
  91 ### ARVADOS_ROOT
  92 The root directory of the Arvados source tree
  93 default: $ARVBOX_DATA/arvados
  94
  95 ### ARVADOS_DEV_ROOT
  96 The root directory of the Arvados-dev source tree
  97 default: $ARVBOX_DATA/arvados-dev
  98
  99 ### SSO_ROOT
 100 The root directory of the SSO source tree
 101 default: $ARVBOX_DATA/sso-devise-omniauth-provider
 102
 103 ### ARVBOX_PUBLISH_IP
 104 The IP address on which to publish services when running in public
 105 configuration.  Overrides default detection of the host's IP address.
 106
 107 ## Notes
 108
 109 Services are designed to install and auto-configure on start or restart.  For
 110 example, the service script for keepstore always compiles keepstore from source
 111 and registers the daemon with the API server.
 112
 113 Services are run with process supervision, so a service which exits will be
 114 restarted.  Dependencies between services are handled by repeatedly trying and
 115 failing the service script until dependencies are fulfilled (by other service
 116 scripts) enabling the service script to complete.