How to use DRP as an HTTP/S File Server
This document describes how to use the Digital Rebar Platform (DRP) built in HTTP (and HTTPS) File Services.
All DRP Endpoints have a built in HTTP File Server service which can be used to stage files, artifacts, etc. for use in Workflow Stages, Tasks, and Templates. In addition, the HTTP File Server space is available via the HTTPS API port.
In this document, we will assume that the DRP Endpoint installed base
directory is the default production location (
If you have installed in the Isolated (with the
--isolated flag at
install time), or you have moved the base directory with the
--drp-home-dir flag, please adjust accordingly.
You can copy files in to the filesystem path that is the designated HTTP Root, on the DRP Endpoint. You will find the HTTP Root filesystem path at:
However, you can use the API, CLI, or Portal to also stage and manage files in this space.
To save files to the HTTP file server path with the
drpcli client, you
can use the following command:
Thi will uploaded (assuming default production install paths) to:
If you pass the
--explode argument on the end of the command, then any
tar zip files will automatically be unzipped, and untarred in the
directory you specify. The constituent files in the zipped tarball will
be directly available.
You can use the
drpcli client to download files from the DRP Endpoint,
with the following syntax:
Additionally, any standard HTTP compliant tool can be used (eg
# wget the HTTP file server path location wget http://drp:8091/files/bar/baz/foo.tgz # get via HTTPS API port path, via wget or curl - note that it may be necessary # to ignore the TLS certificate - shown in these examples wget --no-check-certificate https://drp.example.org:8092/files/bar/baz/foo.tgz curl -k https://drp.example.org:8092/files/bar/baz/foo.tgz
This is best/easiest done with the
drpcli tool. Use of
can be achieved, but appropriate REST headers and authentication have to
be passed in.
In workflow Stages/Tasks/Templates, the following golang templating constructs can be used to build up the appropriate HTTP/S paths, unique to the DRP Endpoint you are working with.
This is extremely usefully for Multi-Site Manager endpoints, as the Files server artifacts can be automatically replicated/synchronized to downstream managed DRP Endpoints. As such, you may not know the DRP Endpoints IP address information in your content packs. Additionally, the HTTP File server port, or the HTTPS API port will be dynamically added to the rendered string as well (these can change between deployments).
The template expanded IP Address will be the one that is in use by the given Machine at the time the Template is rendered. There may be multiple interfaces on a DRP Endpoint, and the templating system will use the one that is in use for communication between the DRP Endpoint and the Machine.
It is always recommended to use the
drpcli client when possible, along
with the Template constructs to build up the correct URL reference
paths. This helps to ensure that your Content can be moved between
different DRP Endpoints as your use of the product/service grows in your
Additional resources and information related to this Knowledge Base article.
- rs_data_render (Provisioner items)
All DRP Versions
http, https, fileserver, document root, curl, wget, drpcli, files, artifacts