Install Context Containers with 'drpcli'¶
A Context Container is used by Digital Rebar Platform (DRP) with a Runner (drpcli/agent) running in it to execute control and commands against services that do not have an embedded Runner. This extends DRP based Automation and Orchestration capabilities to APIs, services, and other platforms.
A specific context container will include the RackN Runner (drpcli/agent) along with any other specific libraries, tools (binaries), etc. that are necessary to interact with those services. However, these containers need to be installed on the DRP Endpoint and installed in the backing Context service (eg Docker or Podman).
This document describes how to install/setup a Context Container on a
DRP Endpoint utilizing the drpcli
command line tool.
Note that during a new/initial installation of a DRP Endpoint, the
install.sh
script can bootstrap the system and install the container
manager and setup the Context containers. This Knowledge Base article
defines how to use drpcli
to perform these tasks if there are no
Bootstrap helpers for the Context Containers.
This solution assumes that the operator has the drpcli
command setup
and successfully operating with your DRP Endpoint. To verify this,
please run the following drpcli
API check and test:
You should receive a response similar to { "active": true }
. In
addition; running drpcli info get | jq '.id'
will return the DRP
Endpoint ID that you are connected to.
This solution specifies use of the jq
binary. Please install it if you
do not have it. The drpcli
binary can also operate as a jq
substitute if you can not install jq
. Simply do:
Prerequisites¶
- docker or podman installed on the DRP Endpoint system
- the RackN
docker-context
plugin is installed - DRP V4.8.0 or newer
drpcli
is setup and authenticating to the DRP Endpointjq
is available- a Content Bundle is installed with a specific Context container reference the operator is trying to setup
- the
dev-library
Content Bundle is installed for thehello-world
test
Solution¶
In this example, we will be working with the RackN provided Context
named govc
. Please substitute the correct Context name in the CTX
shell variable appropriately.
Overview of the steps:
- Set/Get the Context Name and container Image name
- Upload the Context container to the DRP Files service location
- Load the container in to the container manager (Docker or Podman)
- Testing the Context
- Cleanup
We will use the CTX
shell variable to make the Documentation easier,
adjust it to the Name of the specific Context Container being setup.
Set/Get the Context Name and container Image name¶
# the name of the Context - change this to match your Context
export CTX="govc"
# the specified container image in the Context
export IMG=$(drpcli contexts show "$CTX" | jq -r .Image)
Upload the Context container to the DRP Files service location¶
This step uploads the Context Container artifact in to the DRP Endpoint
Files service space. This is required by the docker-context
plugin.
RackN defined Context containers are staged in an S3 bucket with the
name get.rebar.digital
. For non-RackN Contexts, you will need to
specify the correct URL path where the container image is stored.
The constructed URL to get the Context container image for a RackN context is as follows:
# RackN hosted context containers location
export URL=https://get.rebar.digital/containers/${IMG}.tar.gz
# due to firewall/domain whitelisting; some environments may need to use URL:
# https://s3.us-west-2.amazonaws.com/get.rebar.digital/containers/$IMG.tar.gz
The DRP Endpoint Files storage location should be used as follows for
any Contexts used by the docker-context
plugin:
# default DRP install file path resolves to /var/lib/dr-provision/tftpboot/files/$FILE
export FILE="contexts/docker-context/$CTX"
Now that we have the URL and FILE location, lets upload the Context container.
Load the container in to the container manager (Docker or Podman)¶
Once the Context image has been staged on the DRP Endpoint Files
server space; you then need to push the image in to the Image management
component of Docker or Podman. This is performed with the drpcli
runaction helper on the docker-context
plugin.
# loads the Image from the DRP File server path to the Docker/Podman manager
drpcli plugins runaction docker-context imageUpload \
context/image-path "files/contexts/docker-context/$IMG" \
context/image-name "$IMG"
Testing the Context¶
To test the newly installed Context, create a Machine with the
.Meta.BaseContext
set to the Context name. Then; run a Pipeline,
Workflow, Stage, or Workorder on the Context Container backed Machine to
test the Runner in the container. This test uses the hello-world
workflow in the dev-library
content pack.
### assumes CTX is still set in the environment to the name of the context (eg 'govc')
# create a Machine backed by the new Context:
drpcli machines create '{ "Name": "'$CTX'-test", "Meta": { "BaseContext": "'$CTX'" } }'
# install the 'dev-library' content if not installed already
drpcli catalog item install dev-library
# set the new Machine to run the 'hello-world' workflow
drpcli machines workflow Name:$CTX-test hello-world
Once the Workflow (hello-world
) has run, you can show the Job Log
output to verify the job was successful.
# gets the most current Job Log of the Machine we created and ran the workflow on
drpcli jobs log $(drpcli machines show Name:$CTX-test | jq -r '.CurrentJob')
The returned data should show some echoed hello_world output, with an output status of "Command exited with status 0".
Cleanup¶
To remove the test machine, simply run:
Additional Information¶
Additional resources and information related to this Knowledge Base article.
See Also¶
Versions¶
DRP v4.8.0 and newer
Keywords¶
contexts, containers, docker, podman, bootstrap, drpcli