Skip to content

Commit

Permalink
CR updates 3
Browse files Browse the repository at this point in the history
  • Loading branch information
horsmand committed Jul 23, 2021
1 parent 9768af1 commit d57b59d
Show file tree
Hide file tree
Showing 3 changed files with 24 additions and 7 deletions.
1 change: 1 addition & 0 deletions packages/aws-rfdk/docs/upgrade/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,3 +5,4 @@ applications. The documentation is separated by RFDK versions that included pote
upgrading to (or beyond) a version listed below, you should consult the the linked upgrade documentation.

* [`0.27.x`](./upgrading-0.27.md)
* [`0.37.x`](./upgrading-0.37.md)
24 changes: 19 additions & 5 deletions packages/aws-rfdk/docs/upgrade/upgrading-0.37.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,14 @@ If you are already setting fields on the `RenderQueueExternalTLSProps` for the R

## Upgrading Farms Not Using TLS

### RenderQueue Changes
To upgrade your farm if it does not currently configure TLS for connections to the Render Queue, there are two options:

1. [Migrating to TLS](#migrating-to-tls) (recommended)
1. [Preserving plain HTTP](#preserving-plain-http)

### Migrating to TLS

#### RenderQueue Changes

Versions of RFDK prior to 0.37.0 had internal TLS between the load balancer and its backing services on by default. This is configurable with the `internalProtocol` field on the `RenderQueueTrafficEncryptionProps` interface. This default was left as-is, so upgrading RFDK will have no effect on the protocol those backing services were already using and they will not need to be replaced. The TLS being enabled by default is between the listener on the load balancer and any Deadline clients that are connecting to it, which is configurable with the `externalProtocol` property on the `RenderQueueTrafficEncryptionProps` interface.

Expand All @@ -18,13 +25,20 @@ There will be a few new constructs deployed to your farm:

These new constructs will require the Render Queue load balancer's listener to need replacing, but the load balancer itself and the backing services it redirects traffic to will not need to be changed.

### WorkerInstanceFleet Changes
#### WorkerInstanceFleet and SpotEventPluginFleet Changes

Since the endpoint and port the listener on the load balancer uses will be changed, and the TLS will require any clients connecting to verify its certificate, any stacks that contain dependencies on the Render Queue will first need to be destroyed. If you are using a tiered architecture similar to what we recommend in our documentation, this would include any `WorkerInstanceFleet` constructs that are in a separate stack from the `RenderQueue`. The `WorkerInstanceFleet` constructs configure their connection to the Render Queue during their start-up. Running `cdk destroy "ComputeTier"` (or whatever name you gave your stack containing the workers) to destroy any worker fleets before running `cdk deploy "*"` to redeploy the entire farm should
Since the endpoint and port the listener on the load balancer uses will be changed, and the TLS will require any clients connecting to verify its certificate, any stacks that contain dependencies on the Render Queue will first need to be destroyed. If you are using a tiered architecture similar to what we recommend in our documentation, this would include any `WorkerInstanceFleet` constructs or `SpotEventPluginFleet` and `ConfigureSpotEventPlugin` constructs. If you are not using a tiered architecture, we still recommend destroying these constructs since we're changing the endpoint that they need to connect to, and that configuration of the endpoint happens in the initialization script for an instance.

The script used to initialize any workers deployed by the farm will also be updated to change the endpoint and port that they use to connect to the Render Queue, and the workers will also need the certificate chain to verify the load balancer (in the default case the cerificate chain only includes the self-signed certificate).
To perform the removal of these constructs:
1. Suspend any jobs that are being run by workers that the constructs deployed.
1. If any spot instances are running, they will need to be terminated since their lifecycle is controlled by Deadline's Spot Event Plugin and not your RFDK app. Trying to destroy/remove the `SpotEventPluginFleet` construct will fail if these hosts are left running because the spot instances use the security group that the construct creates.
1. Next we have to destroy the constructs that are deploying workers, which could be done in a few ways:
1. If you can destroy the Stack that contains these constructs without destroying the rest of your app, then destroy it using the command `cdk destroy "ComputeTier"` (or whatever name you gave your stack).
1. If you cannot destroy a single stack or you are not using a tiered architecture, you can just comment out these constructs in your app, rebuild it, and then run `cdk deploy "*"` to perform the removal.
1. Now that we won't cause any dependency issues, we can update the version of RFDK in our app's `package.json`, install it, and then run the deployment. If worker constructs were commented out in the last step, they can be added back in here and redeployed during the upgrade.
1. Any jobs that were paused can be resumed after the deployment is complete. Any workers deployed with the `WorkerInstanceFleet` should be connecting through TLS now, and the Spot Event Plugin should be configured so that any new Spot instances it deploys will be properly configured as well.

## Disabling External TLS
### Preserving plain HTTP

While we strongly suggest farms be upgraded to use TLS, it is possible to override the new default and keep a farm using HTTP instead. To do this, there is an `enabled` field on the `RenderQueueExternalTLSProps` that can be set to false. This will prevent the farm from automatically upgrading the protocol until you decide you're ready. Here's an example of creating a Render Queue with TLS disabled:

Expand Down
6 changes: 4 additions & 2 deletions packages/aws-rfdk/lib/deadline/test/render-queue.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -1243,7 +1243,7 @@ describe('RenderQueue', () => {
},
],
},
'" --render-queue "http://renderqueue.renderfarm.local:8080" \n' +
`" --render-queue "http://renderqueue.${ZONE_NAME}:8080" 2>&1\n` +
'rm -f "/tmp/',
{
'Fn::Select': [
Expand Down Expand Up @@ -1414,7 +1414,7 @@ describe('RenderQueue', () => {
},
],
},
'" --render-queue "http://renderqueue.renderfarm.local:8080" 2>&1\n' +
`" --render-queue "http://renderqueue.${ZONE_NAME}:8080" 2>&1\n` +
'Remove-Item -Path "C:/temp/',
{
'Fn::Select': [
Expand Down Expand Up @@ -2092,6 +2092,7 @@ describe('RenderQueue', () => {
[false],
[true],
])('specified with TLS enabled == %s', (isTlsEnabled: boolean) => {
// GIVEN
const zone = new PrivateHostedZone(dependencyStack, 'Zone', {
vpc,
zoneName,
Expand All @@ -2115,6 +2116,7 @@ describe('RenderQueue', () => {
// WHEN
const renderQueue = new RenderQueue(isolatedStack, 'RenderQueue', props);

// THEN
const loadBalancerLogicalId = dependencyStack.getLogicalId(
renderQueue.loadBalancer.node.defaultChild as CfnElement,
);
Expand Down

0 comments on commit d57b59d

Please sign in to comment.