feat(examples): local zones examples #314
Conversation
horsmand
force-pushed
the
local-zones
branch
from
3a516d5 to
e741894
Compare
| # to pin to. Some examples of pinned version values are "10", "10.1", or "10.1.13" | ||
| self.deadline_version: Optional[str] = '10.1.13.1' | ||
|
|
||
| # A map of regions to Deadline Client Linux AMIs.As an example, the Linux Deadline 10.1.13.1 AMI ID |
There was a problem hiding this comment.
Nit: Missing space between period and 'As'.
|
|
||
| from aws_cdk.core import ( | ||
| Stack, | ||
| Construct |
| # It is being deployed into the standard availability zones, but has access to the worker | ||
| # instances that get deployed into a local zone. Not a critical component of the farm, so | ||
| # this can be safely removed. | ||
| self.bastion = BastionHostLinux( |
There was a problem hiding this comment.
Mentioned elsewhere, but mentioning here: we should always recommend using SSM over Bastions (where possible!)
examples/deadline/Local-Zone/python/package/lib/compute_tier.py
Outdated
Show resolved
Hide resolved
examples/deadline/Local-Zone/python/package/lib/network_tier.py
Outdated
Show resolved
Hide resolved
examples/deadline/Local-Zone/python/package/lib/network_tier.py
Outdated
Show resolved
Hide resolved
examples/deadline/Local-Zone/python/package/lib/network_tier.py
Outdated
Show resolved
Hide resolved
| availabilityZones: config.availabilityZonesLocal, | ||
| renderQueue: service.renderQueue, | ||
| workerMachineImage: MachineImage.genericLinux(config.deadlineClientLinuxAmiMap), | ||
| keyPairName: config.keyPairName ? config.keyPairName : undefined, |
There was a problem hiding this comment.
nit: can this be simply:
keyPairName: config.keyPairName,| @@ -0,0 +1,39 @@ | |||
| # RFDK Sample Application - Local Zones | |||
There was a problem hiding this comment.
This example does a great job of showing how to deploy the Workers to a local zone - great work!
I think one thing that might be missing though is an explanation of why this is important/useful. RFDK users want this so they can have a low-latency connection between their AWS infrastructure and their infrastructure hosted outside AWS. It might help to spend some time at the beginning of this README setting the stage here. It may also help to add some guidance, links, and next steps to point users in the right direction for how they'd take this example and proceed to the next step of connecting their infrastructure outside of AWS.
One good resource we could link to is our developer guide documentation on connecting to a RFDK render farm
There was a problem hiding this comment.
Thanks for adding documentation for this in the top-level README.
As discussed offline, let's add a "next steps" section to the Python/TS READMEs that list the steps required to connect an on-premise networked file-system to the Workers. Even if we don't have all of the steps completely detailed, for now having a checklist would help guide readers to research and complete them. These are the steps that I foresee here:
- Follow the connecting to your render farm dev guide page to modify the
NetworkTierwith the the VPN connection. - Ensure there is a route from the worker subnet to the on-prem file-system
- Ensure the VPN endpoint's security group has ingress rules to allow NFS port traffic from the Workers
- Add user-data to mount the NFS on the compute tier
- (optional) set up path mapping rules in Deadline
Fixes #313
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license