Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/cloudy-sky-software/foldinginthecloud
Run [email protected] the cloud. https://dev.to/praneetloke/running-folding-home-in-the-cloud-56nc
https://github.com/cloudy-sky-software/foldinginthecloud
aws aws-lambda covid-19 foldingathome pulumi spot-instances
Last synced: 3 days ago
JSON representation
Run [email protected] the cloud. https://dev.to/praneetloke/running-folding-home-in-the-cloud-56nc
- Host: GitHub
- URL: https://github.com/cloudy-sky-software/foldinginthecloud
- Owner: cloudy-sky-software
- Created: 2020-04-29T04:59:15.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2024-06-16T19:46:52.000Z (7 months ago)
- Last Synced: 2025-01-11T09:53:03.611Z (11 days ago)
- Topics: aws, aws-lambda, covid-19, foldingathome, pulumi, spot-instances
- Language: TypeScript
- Homepage:
- Size: 483 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 4
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Folding In The Cloud
A Pulumi app for deloying Spot instances that run the [Folding@Home](https://foldingathome.org) client.
See https://foldingforum.org/viewtopic.php?f=24&t=32463&fbclid=IwAR1v8Z_2VbB__5izLF989xPRRg9WIYzbd9d5gkfAaP3jCPdkcJbeyUpIt-U.
## Introduction
There are two stacks:
- `aws`
- `azure`...for, you guessed it, deploying infrastructure on AWS and Azure respectively.
The architecture between the two stacks are kept as similar as possible. However, there are some differences.
### Difference 1 - VPC configuration
For example, in the AWS infrastructure, both the event handler (Lambda) and the EC2 Spot instance are in a VPC.
Whereas, in the Azure infrastructure, creating an Azure Functions app in a VNET requires a Premium plan.
So instead, the network security rules for the Azure Spot VM is restricted to only allow certain IP addresses
to connect via SSH port 22. This is still not entirely secure from a security standpoint because the Function App
IP addresses are not "dedicated" IP addresses. So technically any Function App also running on those hosts _could_
potentially try to connect to our Spot VM. However, the chances for that are really slim. In addition,
we are also using an SSH private key only we have access to.### Difference 2 - Event handling
> More details about this can be found in the [source code](https://github.com/praneetloke/FoldingInTheCloud/blob/master/azure/events.ts#L17).
In AWS, the Lambda handler can receive events from the EC2 service as well as the S3 bucket object change notification.
However, in Azure, there is no concept of "listening" to events from VM changes. Instead, there is a metadata service
called "Scheduled Events" that needs to be constantly monitored and is only accessible from within the VM. So the
event handler (Azure Functions) in the Azure infrastructure setup, only relies on Azure Storage blob notifications
through the use of Event Grid subscriptions.## Running the app
> :warning: Running the Pulumi app using your cloud credentials WILL cost you money. So use this at your own risk.
> The contributors/maintainers or anyone involved with this project is NOT responsible for any costs you may incur.First, fork this repo, delete the `Pulumi.aws.yaml` and `Pulumi.azure.yaml` files. Create your own stack, using `pulumi stack init`.
Next, generate an OpenSSH keypair for use with your server:
```
# The filename `rsa` is specifically git ignored so you don't have to worry about
# accidentally committing them to GitHub. If you use a different filename,
# be sure not to commit these files!ssh-keygen -m PEM -f rsa
```This will output two files, `rsa` and `rsa.pub`, in the current directory.
```
cat rsa.pub | pulumi config set publicKey --
cat rsa | pulumi config set privateKey --secret --
```If your key is protected by a passphrase, add that too:
```
pulumi config set privateKeyPassphrase --secret [yourPassphraseHere]
```Notice that we've used `--secret` for both `privateKey` and `privateKeyPassphrase`. This ensures their are
stored in encrypted form in the Pulumi secrets system.### Stack configuration
As noted above, the app supports creating cloud infrastructure to run Folding@Home on AWS and Azure.
The cloud provider the app uses depends on the configuration option `cloudProvider`. It defaults to `aws`.
Your stack name (the one you enter when you run `pulumi stack init`) can be whatever you choose.
It's the configuration values that change the controls the deployment to a cloud provider.See [`config.ts`](https://github.com/praneetloke/FoldingInTheCloud/blob/master/config.ts) for more configuration options.
### Cloud provider credentials
You will need an account with [AWS](https://portal.aws.amazon.com/billing/signup#/start) or [Azure](https://portal.azure.com) (or both :))
#### AWS Setup
Learn how to create [AWS Secret Keys](https://aws.amazon.com/premiumsupport/knowledge-center/create-access-key/). Read more about the [AWS setup for Pulumi](https://www.pulumi.com/docs/intro/cloud-providers/aws/setup/).
#### Azure Setup
Install the Azure CLI locally and log in to that. If you are planning to run this app on a CI/CD service,
then it is recommended that you use a [Service Principal](https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?view=azure-cli-latest).> A Service Principal is like a "bot" account that is meant to be used with non-interactive sessions such as a CI/CD service.
Read more about the [Azure setup for Pulumi](https://www.pulumi.com/docs/intro/cloud-providers/azure/setup/).
## Run it!
Run `pulumi up -s ` and select **Yes** when you see a prompt for confirmation.
Pulumi will run a `preview` first, which will mostly be uninteresting (because nothing already exists in your account for the stack).
However, you will notice that there are quite a bit of resources to be created. This is due to the nature of the network security setup.
Instead of using a default networking setup, the instance is setup to use a private and public subnet setup. If you don't understand what
that means, to put it simply, the virtual machine/instance is not exposed to the internet directly and instead go through a "router" of
sorts that masks the instance's real IP address. It's sort of like your home Wifi router setup.After the initial `pulumi up`, the preview will only show you the differences in what is already deployed on the cloud and what you've changed.