Running the Cache ================= Installation ------------ If you are going to cache a Shotgun installation of any significant size, you should install the only non-Python dependency: `PostgreSQL `_ You will also need `virtualenv `_ for a non-system install (as is recommended). A typical install looks like:: # Grab the code git clone git@github.com:westernx/sgcache cd sgcache # Create a virtualenv, and install the Python dependencies virtualenv venv . venv/bin/activate pip install -r requirements.txt pip install -r requirements-westernx.txt Configuration ------------- Configuration is provided by a cascade of information sourced from: 1. the default config in ``sgcache/config.py``; 2. environment variables prefixed with ``SGCACHE_``; 3. colon-delimited list of Python files specified by :attr:`~sgcache.config.CONFIG` The recommended configuration setup is to write your own Python file with your configuration changes, and refer to it via ``$SGCACHE_CONFIG``. Database -------- SGCache generally operates with either of SQLite, or PostgreSQL (and maybe others, as it uses SQLAlchemy as its database access layer). SQLite is usually reserved for very small installations, or development. Production environments should use PostgreSQL. Schema ------ You must select the subset of the Shotgun schema that you want to cache, and set :attr:`~sgcache.config.SCHEMA` to point to the containing YAML file. The ``schema/keystone-basic.yml`` file demonstrates the format, and is generated from our live Shotgun and basic rules via:: ./schema/dump > schema/keystone-full.yml ./schema/filter --absent -f schema/basic-filters.txt schema/keystone-full.yml > schema/keystone-basic.yml Changes ....... To update the schema asserting the cache does not return invalid data, you must: 1. Update the schema YAML file. 2. Restart the event watcher and the periodic scanner. 3. Perform a complete scan of the modified types:: sgcache-scanner --full --scan-types Shot,Task 4. Restart the web server only once the full scan finishes. Restarting the web server prematurely will result in it assuming that the new fields are empty, and return incomplete data. Priming the Cache ----------------- SGCache assumes that it knows about every entity in your Shotgun, so in order to return correct results, you must perform a full scan:: sgcache-scanner --full If you are testing, you can specify individual projects to cache:: sgcache-scanner --full --scan-projects 66,67 Running the Daemons ------------------- The three primary daemons are ``sgcache-scanner``, ``sgcache-events``, and ``sgcache-web``. It is recommended to run them seperately, but for convenience there is a ``sgcache-auto`` which will run them all. All configuration options are exposed as command-line flags, but it is recommended to create a ``config.py`` file, and refer to it via ``$SGCACHE_CONFIG``. Reverse Proxying with Nginx --------------------------- It is recommended to run SGCache behind an Nginx reverse proxy. This allows Nginx to directly transfer of large files, as we have experienced trouble with getting the cache to upload massive files itself. Here is the Nginx config at Western Post:: server { listen 80; server_name sgcache.westernx; # Fails fast with file uploads without this. client_max_body_size 1G; # Pass large uploads/downloads to Shotgun. location ~ ^/(upload|thumbnail|file_serve) { proxy_set_header Host keystone.shotgunstudio.com; proxy_pass https://keystone.shotgunstudio.com; } # Everything else goes to SGCache. location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8010; } } Configuration Reference ----------------------- .. automodule:: sgcache.config