Deadline Docker Container

Hey Thinkbox folks,

Any plans for building this on your end, possibly even for D8?


Hey Joe!

Indeed, containers are the greatest thing since sliced bread. We don’t have any immediate plans to post official Thinkbox container images on DockerHub, but this may eventually happen. However, if you or others are interested, I could post an example Dockerfile and some instructions to our GitHub repository.

+1 for docker support


Is this sample available somewhere ? Can’t find it on your github :slight_smile:

I can also lend a hand as I’ve been playing with Docker lately on my time off. Here are the relevant goods: … iderations (for port exports) … stallation (silent install for clients) … stallation (silent install for repo)

I’ll poke James and we’ll do a little discussing.

Hey All,

We’ll get some examples posted next week.

I’ve put up some basic examples of building containers for Deadline on GitHub. … Ops/Docker

Is there any official docker container for Deadline 10 ?

This is a snippet of the dockerfile i created, , based on the examples to run deadeline10 on a centos7.
hopefully it can give you some hits as to what you may need to change, im not using the latest deadline10 version:

FROM centos:7

# 1. Use your own e-mail for the maintainer.

# Perform a general update of the OS.
RUN yum -y upgrade

# Add requirements for Deadline 8 headless Slave.
RUN yum -y install redhat-lsb \
 && yum -y install bzip2  \
 && yum -y install cifs-utils

RUN mkdir /tmp/thinkboxsetup/
COPY /tmp/thinkboxsetup/
#COPY DeadlineClient-8.* /tmp/thinkboxsetup/

# copy network share data.
RUN mkdir /mnt/deadline10
RUN echo "/the_server/mount_point /mnt/deadline10 cifs    credentials=some cool things here" >> /etc/fstab

# setup ulimit, super hi:
RUN ulimit -n 64000

# Copy over the installer.
# 2. Be sure the installer .run file has been placed in the same folder as the Dockerfile.
RUN mkdir /tmp/thinkboxsetup/
COPY /tmp/thinkboxsetup/

# Run the installer.
# 3. Replace the name of the license server after --licenseserver below with that of your actual license server.
RUN chmod +x /tmp/thinkboxsetup/
RUN /tmp/thinkboxsetup/ \
    --mode unattended \
    --unattendedmodeui minimal \ 
    --repositorydir /mnt/deadline10 \ 
    --licenseserver @lic-thinkbox \ 
    --noguimode true \ 
    --restartstalled true 

WORKDIR /opt/Thinkbox/Deadline10/bin/
# ENTRYPOINT ["/opt/Thinkbox/Deadline10/bin/"] # this guy wraps the launcher command, with some additional network mounts, and statistics gathering setup. 

I ended out going a little further with my internal docker file, to include a shell script to launch the launcher.
I added a little more info, as i choose to point the repo to a network mount, so so i have included the example to update your fstab, to set that network path. Not the docker way, but it works :wink:

hope this helps point you in the right direction.


1 Like

I would love to figure out how to automatically download deadline as a part of this, perhaps using 0Auth2 would be great.

We keep track of who’s downloaded Deadline for a number of reasons, but I’ve made a note to raise this with the right people on our side. Actually, @Andrew_Graham I know your use case, but is it problematic for individual users to download Deadline in your case? It’s been awhile since I’ve created an Amazon account. I’m assuming it’s a large barrier to entry for some.

I missed a notification for this, apologies for not replying.

My goal is for Open Firehawk to approach being as close to a turnkey solution as possible. Currently downloading the Deadline DB/client installer is the only component that makes the process clunkier than I’d like, because In the next phase of the project where we build all the AMI’s in the user’s account and deploy them in cloud, we need the processes to be parallel. My best approach is to get the user to manually place it in an s3 bucket for their own use.

Perhaps a simple solution would be if all your installers are available in an S3 bucket that you allow downloads from other AWS account holders to directly request the download from the bucket. I’m thinking this would be the quickest way to do it, and allow you to track downloads from the bucket with any AWS account ID’s that request the download. I think this would be my first preference.

The next best solution would be to use Oauth, similar to the example in Side Effect’s implementation which is great.
You would just need to provide us with a section in our Thinkbox account to generate the Oauth key.

Actually, that’s exactly what we did! We have a master list of the downloads at this URL:

Then you can pull them with this command:

aws s3api get-object --bucket thinkbox-installers --key Deadline/ DeadlineClient-

So adjust “Windows” and the versions in the path as needed and you should be in business.


Amazing, you guys are great! Thanks so much for making this happen!

I was trying to use the sync operation to keep previously used installers onhand for logging/auditing. your operation worked, but sync doesn’t because of a permission issue.

admin:~/environment/firehawk-main-rollout/firehawk-main/modules/deadline-db-ami ((6f05a9f…)) $ aws s3 sync s3://thinkbox-installers/Deadline/ s3://
fatal error: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Is it possible somehow? This would alleviate repeated downloads, and sync is handy because a partial file that doesn’t match exactly will still correctly get overriden.

Offhand, I don’t think it’s possible without changes on our side.

We’d prefer repeated downloads instead of people pulling all the installers in the bucket. We use the download metrics and (on rare occasions) notify customers of potential critical problems.

Sure thing, actually I was only pulling a single tar to sync in my own private bucket for tracking AMI builds and only pulling when necesary.

I’m working on deadline DB packer AMI’s presently, which while not docker, share a change in the silent install workflow to become a part of immutable infrastructure.

The certs shouldnt live in the image, so on boot we need to generate them in the user data. This should come in handy for that, thanks for your work on it! GitHub - ThinkboxSoftware/SSLGeneration: A simple python script for generating openssl certificates.

I wanted to suggest a feature to aid solving the problem for the DB / RCS to not depend on state.
The database could be persisted in S3, so when the DB instance is terminated it can launch from the AMI again and acquire that state. It would also be helpful for offsite backup - to persist to S3 as a storage backend.

Hashicorp Vault is an example of an encrypted DB that does this amazingly well which I’m using and also works with High Availability.

This would be a great thing to solve not just for docker, but for building Deadline DB AMI’s for general use, and HA too.

Curiously, the request I have been testing on an instance all day and was working just stopped working and I dont know why.

aws s3api get-object --bucket thinkbox-installers --key "Deadline/" "Deadline-"

Is there any reason why that could happen? I just get permission denied. Request limit perhaps?

Probably related: Access to all installers prior to 10.1.13 has been removed. If you check the downloads site, only 10.1.13 and 10.1.14 are currently accessible, and the 10.1.13 download windows tells you to talk to Support if you need an older installer.

Privacy | Site terms | Cookie preferences