View source for Installing Gaffer on AWS with EC2 Image Builder

This is a guide to setting up Amazon Web Services EC2 Image Builder with Gaffer. The EC2 Image Builder is a service from AWS that allows you to create an '''AMI''' (Amazon Machine Image) for use with EC2 with all the software and configuration needed to run jobs on AWS. An '''EC2 instance''' is a preset configuration of processor, memory and network resources made available by AWS - the virtual equivalent of hardware. An EC2 instance needs to be launched with an AMI that defines the virtual machine that will be running - the operating system and installed software.

This guide is intended for users with some AWS knowledge but not expert level. After completing this guide, you will have a Linux-based EC2 AMI available to your AWS users that can be run on any EC2 instance type for running Gaffer tasks, optionally including Arnold rendering. These instances can be launched manually through the AWS management console, via Python scripts or the AWS terminal, or from applications like Thinkbox's Deadline.

=== Overview ===
The EC2 Image Builder is split into a number of different parts. We need to work with three of those to create our Gaffer image. [https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html '''Image Pipelines'''] are run to create the AMI. With Image Pipelines, you determine the schedule with which it will be run (likely Manual for our purposes) and the Image Recipe that will be used to create the AMI.

An '''[https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-recipes.html Image Recipe]''' consists the the base image AMI that will be the starting point for the new AMI, optional additional storage to attach to the instance and a set of components that define the software to be installed.

A '''[https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html Component]''' is a YAML script describing the set of steps to be performed to install and configure some logical unit of software.

Image Recipes and Components are both versioned. When you save, that version becomes immutable and you will create a new version when making changes or fixes.

This guide will show you how to create Components that can be used to install any version of Gaffer and Arnold through the use of Component parameters. This means you can only have one version of Gaffer and Arnold installed on your AMI. Alternatively, you could create a new Component for each version of Gaffer / Arnold then choose multiple components to install on the same AMI.

=== Getting Started ===
To start, log into the AWS Console. Pay attention to the region you have set - this setting is in the top-right of the console. The EC2 Image Builder components as well as the generated AMIs (and therefore the EC2 instances you launch with them) are unique per-region.

Choose EC2 Image Builder from the Services menu in the top-left. You can navigate between Image Pipelines, Image Recipes and Components from the left-side menu.

=== Gaffer Component ===
From the navigation menu, choose Components to see a list of your customized components, which is empty if this is your first time using it.

# Choose "Create component".
# Keep "Component type" set to <code>Build</code>
# Set the Component Details
## Choose <code>Linux</code> as the "Image operating system". This indicates this recipe is compatible with Linux-based Image Pipelines. You determine the operating system for your AMI in the Image Recipe configuration.
## From "Compatible OS Versions", choose the Linux versions you intend for this recipe to be compatible with.
## Enter a Component name and optionally a description.
## Enter a Component version, such as <code>1.0.0</code>
# Set the Content. This is the YAML script that will be run to install Gaffer. The YAML script below will setup Gaffer.
# Finally, choose "Save Component" at the bottom of the screen to save it.

<syntaxhighlight lang="YAML">
name: Gaffer Component
description: Installs software needed for running Gaffer on AWS.
schemaVersion: 1.0

parameters:
  - gafferVersion:
      type: string
      default: '1.4.7.0'
      description: 'The Gaffer version to install.'
  - gccVersion:
      type: string
      default: '9'
      description: 'The gcc version to target for the Gaffer install.'

phases:
  - name: build
    steps:
      - name: DownloadGaffer
        action: WebDownload
        inputs:
          - source: https://github.com/GafferHQ/gaffer/releases/download/{{gafferVersion}}/gaffer-{{gafferVersion}}-linux-gcc{{gccVersion}}.tar.gz
            destination: /opt/gaffer-{{gafferVersion}}/gaffer-{{gafferVersion}}-gcc{{gccVersion}}.tar.gz

      - name: ExtractGaffer
        action: ExecuteBash
        inputs:
          commands:
            - tar xvzf {{build.DownloadGaffer.inputs[0].destination}} --strip-components=1 -C /opt/gaffer-{{gafferVersion}}
            - rm {{build.DownloadGaffer.inputs[0].destination}}
            - echo 'GAFFER_ROOT=/opt/gaffer-{{gafferVersion}}' >> .env
            - echo 'GAFFER_VERSION={{gafferVersion}}' >> .env

  - name: validate
    steps:
      - name: ValidateGaffer
        action: ExecuteBash
        inputs:
          commands:
            - source .env
            - $GAFFER_ROOT/bin/gaffer env python -c "print('Gaffer validated')"

</syntaxhighlight>The <code>name</code>, <code>description</code>, <code>schemaVersion</code> and the two items under <code>phases</code> are required. The <code>parameters</code> list is a helpful way of specifying variables. They can be referenced in multiple places, so they make your Components less error-prone. Their value can also be set from within an Image Recipe which makes for much fewer versions of your Component. Without <code>parameter</code> lists, you would need to version up your Component with each Gaffer version.

==== Build Phase ====
The first phase of a component build installs Gaffer. It first downloads Gaffer from the Github release URL. Then it extracts the archive to the <code>/opt</code> directory. Finally, an environment variable is set for other components to locate Gaffer's root directory.

The extraction step makes use of another helpful feature in Component scripts - referencing variables from a previous step. The <code><nowiki>{{build.DownloadGaffer.inputs[0].destination}}</nowiki></code> text indicates that the file path to extract is taken from the <code>DownloadGaffer</code> step of the <code>build</code> phase. This is another way to reduce errors from typos in your script.

Note that starting with Gaffer 1.4, a gcc11 and gcc9 build is available. Which of these archives you use depends on the Linux distribution you use as your base image (see "Choosing a base image below" for more information). If you're running on Amazon Linux 2, you should use the gcc9 build as the sample above does. If you're using the newer Amazon Linux 2023, you should use the gcc11 build. 

==== Validate Phase ====
The second phase is for verifying that your installation succeeded. For our purposes, running a short Python script from within Gaffer will prove that the installation succeeded and Gaffer is operable. Implementing this phase helps identify problems before the AMI is created. If any of the validation steps fail, the Image Pipeline will be stopped and an error raised.

=== Arnold Component ===
Creating the Arnold Component is much like the Gaffer Component, with one significant difference. Arnold's installer is not available publicly so you will need to upload it to a location that EC2 Image Builder can access. It should be kept private to your organization, which makes AWS S3 a good solution. '''S3''' is a storage repository you can manually or programmatically upload to. EC2 Image Builder Components have an action for downloading from S3, which makes it easy to incorporate into Components.

# Upload the Arnold Linux archive to a bucket in your S3 storage and note it's URL. It will start with <code>s3://</code>.
# Choose "Create Component" to start a new Component.
# Set the Component details as you did with the Gaffer Component.
# An example Component Content script is below.
<syntaxhighlight lang="YAML">
name: Arnold Component
description: Installs Arnold for AWS.
schemaVersion: 1.0

parameters:
  - arnoldVersion:
      type: string
      default: '7.2.5.3'
      description: 'The Arnold version to install.'

phases:
  - name: build
    steps:
      - name: DownloadArnold
        action: S3Download
        inputs:
          - source: s3://hypotheticalinc-image-sources/Arnold-{{arnoldVersion}}-linux.tgz
            destination: /opt/arnoldRoot/arnold-{{arnoldVersion}}.tgz

      - name: ExtractArnold
        action: ExecuteBash
        inputs:
          commands:
            - mkdir /opt/arnoldRoot/{{arnoldVersion}}
            - tar xvzf {{build.DownloadArnold.inputs[0].destination}} -C /opt/arnoldRoot/{{arnoldVersion}}
            - rm {{build.DownloadArnold.inputs[0].destination}}
            - echo 'export ARNOLD_ROOT=/opt/arnoldRoot/{{arnoldVersion}}' >> .env

  - name: validate
    steps:
      - name: ValidateGafferArnold
        action: ExecuteBash
        inputs:
          commands:
            - source .env
            - $GAFFER_ROOT/bin/gaffer env python -c "import GafferArnold;GafferArnold.ArnoldLight()"

</syntaxhighlight>The Arnold component is similar to the Gaffer Component. Instead of downloading from a publicly available Github release, we get the Arnold archive from our S3 upload. This method can be used for other private archives you may need to install, such as non-public Gaffer extensions.

The validation phase once again runs a Python script in Gaffer. Here we simply import <code>GafferArnold</code> and attempt to create an <code>ArnoldLight</code> to verify it is working.

=== Gaffer Prerequisites Component ===
Depending on the which Linux distribution you are using as the base image for your Image Pipeline, you may need some additional packages installed to run Gaffer. The Amazon Linux 2 base image, for example, needs <code>mesa-libGL</code> and <code>mesa-libGLU</code> to run Gaffer tasks. These can be installed with the following Component.<syntaxhighlight lang="YAML">
name: Gaffer Prerequisites
description: Required components to run Gaffer.
schemaVersion: 1.0

phases:
  - name: build
    steps:
      - name: installPackages
        action: ExecuteBash
        inputs:
          commands:
            - yum install -y mesa-libGL mesa-libGLU
</syntaxhighlight>

=== Image Recipe ===
With your Components defined, you can now create the Image Recipe for generating your AMI. Choose "Image Recipes". The Recipe list will be empty if you haven't created on yet.

# Choose "Create image recipe".
# Enter a name for your Recipe and optionally a description.
# Enter a version number, such as <code>1.0.0</code>.
# Select an AMI to use as the base image for the Recipe. See the section below for more information about choosing a base image.
# Enable your <code>Gaffer</code>, <code>Arnold</code> and <code>GafferPrerequisites</code> Components you created above. You may need to change the search filter to <code>Owned by me</code>.
# As you enable each Component, it will be added to the "Selected Components" section.
# The Components will be added in the order they are listed. Make sure the <code>GafferPrerequisites</code> Component is first, followed by <code>Gaffer</code> and then <code>Arnold</code>. If they are not in the correct order, validation will fail.
# You can modify the version number to install in the "Selected Components" section. This is also where you can change the installed versions when making a new version of this Image Recipe for future releases.
# It is also a good idea to change the "Versioning Options" of your Components to <code>Use latest available component version</code>. This will ensure the latest component is used without needing to create new Image Recipe versions each time a Component is modified. Using the version variables in your Component allows you to update new software versions without needing to change the Component, only the Recipe.
# If you need to attach additional storage, you can do that in the "Storage (volumes)" section. This can be useful for storing assets on the instance.
# Choose "Create Recipe" to complete the Recipe.

==== Choosing a base image ====
The base image is the AMI that will be used as the starting point for your customized AMI. It is booted first, your components are added to it, and a snapshot is taken to be used as your custom AMI.

The Image Recipe creation wizard allows you to choose a variety of standard Linux distributions, images you've subscribed to from the AWS Marketplace, or a manually entered AMI ID.

If you are using Deadline, entering an AMI ID can be helpful for identifying the AMI provided by AWS / Thinkbox that has the needed Deadline components preinstalled. One way of finding this ID is to launch a Deadline worker from the AWS Portal in the Deadline Monitor. There are various options for AMIs with DCC software preinstalled. You can choose the generic Linux worker for a clean base AMI. Once the machine has started, go to your EC2 Instances in the AWS Web Console, locate the running instance and note its AMI ID.

=== Image Pipeline ===
The final step is to create an Image Pipeline. Choose Image Pipelines from the navigation menu to see the list of Pipelines, which is empty if this is your first time using it.

# Choose "Create Image Pipeline" to get started.
# Enter a name for the pipeline and optionally a description.
# Change the schedule option to "Manual" so it will only run when you trigger it.
# Proceed to the next step, to configure the Recipe.
# Choose the Recipe you created above.
# Proceed through the remaining wizard screens, accepting the default values.
When you are finished, refresh the Image Pipeline list. Select your new Pipeline and choose "Run Pipeline" from the "Actions" menu. Choosing the Pipeline in the list will take you to a list of Pipeline runs, your new submission should be in the <code>Building</code> status.

Once the image has been built and validated, it will be available in your EC2 AMI list for use!

=== Debugging ===
If your AMI is not successfully built, you can view the log stream for a detailed description of the steps EC2 Image Builder performed, including the results of your Component validation steps. This can be useful for finding what went wrong and making corrections to your Components.

=== Updating Installed Versions ===

# Select your Image Recipe.
# Choose "Create new version".
# Enter the new version numbers in the Component settings.
# Either create a new Image Pipeline for your new Image Recipe, or modify the existing Image Pipeline to use it in place.

=== GafferDeadline Component ===
Though it isn't necessary for using Gaffer on AWS, if you are using Deadline to queue jobs to AWS, you will also need to have GafferDeadline installed. The following script can be used as a Component for GafferDeadline.<syntaxhighlight lang="YAML">
name: GafferDeadline Component
description: Installs GafferDeadline for AWS.
schemaVersion: 1.0

parameters:
  - gafferDeadlineVersion:
      type: string
      default: '0.58.0.0b2'
      description: 'The GafferDeadline version to install.'

phases:
  - name: build
    steps:
      - name: DownloadGafferDeadline
        action: WebDownload
        inputs:
          - source: https://github.com/hypothetical-inc/GafferDeadline/archive/refs/tags/{{gafferDeadlineVersion}}.tar.gz
            destination: /opt/GafferDeadline/gafferDeadline{{gafferDeadlineVersion}}.tar.gz

      - name: ExtractGafferDeadline
        action: ExecuteBash
        inputs:
          commands:
            - tar -xvzf {{build.DownloadGafferDeadline.inputs[0].destination}} --strip-components=1 -C /opt/GafferDeadline
            - rm {{build.DownloadGafferDeadline.inputs[0].destination}}

  - name: validate
    steps:
      - name: ValidateGafferDeadline
        action: ExecuteBash
        inputs:
          commands:
            - source .env
            - export GAFFER_EXTENSION_PATHS=/opt/GafferDeadline
            - $GAFFER_ROOT/bin/gaffer env python -c "import GafferDeadline;print(help(GafferDeadline))"

</syntaxhighlight>