Turn off external IPs #54
Conversation
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 6ff39d6 |
FYI, I did a run based off of your branch yesterday and it also ran successfully! |
Have you thought about doing this for post-processing? On one hand, scope creep; on the other, it seems easy enough. |
I don't think Cloud Run jobs get external IPs by default? If they do (and it's a problem), I'll handle that separately. |
| no_external_ip_address=True, | ||
| ) | ||
| ] | ||
| ), |
There was a problem hiding this comment.
This looks great! Thanks, Natalie! Just a question here: once we eliminate the use of external IPs, I assume we can not simply SSH into machines for any reason like what you did earlier to confirm the remaining docker images? Are there alternatives? I don't think this would be a big issue but still trying to understand if this would impose any limitations.
There was a problem hiding this comment.
You can still SSH in as usual, via the GCP console or the gcloud command, since those go through Google's internal network, not the external IP.
There was a problem hiding this comment.
ok, great! for some reason I though we are SSHing to external IPs but this makes sense!
| logger.error( | ||
| f"Error ({op.error_code}) updating subnet settings to allow private Google access: {op.error_message}" | ||
| ) | ||
|
|
There was a problem hiding this comment.
Removing the external IP limitation of 128, do we have any similar limitation with private IPs? I am trying to understand how many concurrent simulations can we achieve with eliminating the use of external IPs
There was a problem hiding this comment.
Looking through the relevant quotas here, I think the relevant ones are high enough (e.g. the Instances per VPC network limit is 15,000) that we're more likely to hit limits on general compute resources (e.g. total number of CPUs) first. (Note that we're not using static internal IPs, so those limits don't apply here.)
Most of these quotas also apply per-region, so if needed we could also start running jobs in different regions. (Other regions also have different quotas and prices, so this might be worth looking into anyway.)
There was a problem hiding this comment.
This great! right and general compute resources have much higher (compared to 128) quota limits, so we should be good on that part then.
Agreed! I think it would be worth looking into quotas and costs for other regions to see if switching to those would make sense
| no_external_ip_address=True, | ||
| ) | ||
| ] | ||
| ), |
There was a problem hiding this comment.
ok, great! for some reason I though we are SSHing to external IPs but this makes sense!
| logger.error( | ||
| f"Error ({op.error_code}) updating subnet settings to allow private Google access: {op.error_message}" | ||
| ) | ||
|
|
There was a problem hiding this comment.
This great! right and general compute resources have much higher (compared to 128) quota limits, so we should be good on that part then.
Agreed! I think it would be worth looking into quotas and costs for other regions to see if switching to those would make sense
Configure our Compute Engine VMs (created via Batch) to not use external IPs. We don't need them, and we're hitting quota limits on the number of external IP addresses in use.
Also ensure that the relevant subnet has Private Google Access enabled so the jobs can access Google APIs. (This is using the default VPC network, which has a subnet in every region.)
Testing: Successfully ran a test job and confirmed that the created VMs did not have external IPs:
