mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-06-08 11:17:27 +00:00
301 lines
11 KiB
Markdown
301 lines
11 KiB
Markdown
# Backend
|
|
|
|
This is the api service that will supply the frontend with the insights that are driven by the machine
|
|
learning and data modelling services.
|
|
|
|
# Usage
|
|
|
|
## Prerequisites
|
|
|
|
Python 3.8+
|
|
Poetry for managing project dependencies and virtual environment.
|
|
|
|
## Installation and setup
|
|
|
|
1. Clone this directory and navigate into the project directory.
|
|
|
|
```commandline
|
|
git clone https://github.com/Hestia-Homes/Model.git
|
|
cd backend
|
|
```
|
|
|
|
2. For environment management, I'm using conda with pycharm which is a convenient setup for development
|
|
on a mac M1 however using tools such as poetry or pipenv is also fine.
|
|
|
|
For example, to install conda and create a virtual environment for this project, run the following commands:
|
|
|
|
```commandline
|
|
conda create -n backend python=3.10
|
|
conda activate backend
|
|
```
|
|
|
|
then enter the virtual environment and install the dependencies using conda.
|
|
|
|
```commandline
|
|
conda install --file requirements/base.txt
|
|
```
|
|
|
|
3. Duplicate .env.example and rename it to .env
|
|
|
|
```commandline
|
|
cp .env.example .env
|
|
```
|
|
|
|
4. Open .env and fill in the required environment variables.
|
|
|
|
## Running the Application
|
|
|
|
from within the application you can run with the following command:
|
|
|
|
```commandline
|
|
uvicorn app.main:app --reload
|
|
```
|
|
|
|
You application will be available at the designated url
|
|
|
|
## API Documentation
|
|
|
|
FastAPI automatically generates interactive API documentation for your application. To access the docs, start your
|
|
server and visit <yourlocalurl>/docs in your browser. Alternatively, you can go to
|
|
<yourlocalurl>/redoc to view the documentation in the ReDoc format.
|
|
|
|
## Building the backend docker image locally
|
|
|
|
To build the backend docker image locally, run the following command from the root of the project directory:
|
|
|
|
```commandline
|
|
docker build -t fastapi-lambda-image:latest -f backend/docker/lambda.Dockerfile .
|
|
```
|
|
|
|
To check the size of the resulting image, run the following command:
|
|
|
|
```bash
|
|
docker images | grep fastapi-lambda-image
|
|
```
|
|
|
|
To run a shell inside the Docker container to inspect its contents, run:
|
|
|
|
```commandline
|
|
docker run -it fastapi-lambda-image:latest /bin/bash
|
|
```
|
|
|
|
## Testing
|
|
|
|
To run tests, run the following command from the root of the project directory:
|
|
|
|
```commandline
|
|
pytest
|
|
```
|
|
|
|
## Local Development
|
|
|
|
During local development, you may need to generate and use a dummy JWT to
|
|
test protected endpoints of the application.
|
|
|
|
# Generating a Dummy JWT
|
|
|
|
FastAPI provides a convenient way to generate a dummy JWT for testing.
|
|
To generate a dummy JWT, follow the steps below:
|
|
|
|
Make sure your application is running in a local environment.
|
|
The dummy token endpoint is only available in a local environment.
|
|
|
|
While your application is running, visit the /dummy-token endpoint using a tool
|
|
like curl or any HTTP client like Postman.
|
|
|
|
For instance, if your server is running locally on port 8000, you can use curl
|
|
to get a dummy token:
|
|
|
|
```commandline
|
|
curl http://localhost:8000/dummy-token
|
|
```
|
|
|
|
You will receive a response containing the dummy JWT
|
|
|
|
```json
|
|
{
|
|
"dummy_token": "<Your Dummy Token>"
|
|
}
|
|
```
|
|
|
|
### Using the Dummy JWT
|
|
|
|
Once you've obtained a dummy JWT, you can use it to make requests to
|
|
protected endpoints in your application:
|
|
|
|
1. When making a request, include an Authorization header with the value Bearer
|
|
<Your Dummy Token>. Replace <Your Dummy Token> with the token you
|
|
received from the /dummy-token endpoint.
|
|
|
|
2. Now you can make requests to the protected endpoints of the application.
|
|
|
|
Remember, the dummy JWT is meant for testing purposes only and should not be
|
|
used in production environments. The /dummy-token endpoint is not available
|
|
in non-local environments.
|
|
|
|
# Custom Domain Setup for AWS API Gateway
|
|
|
|
Before you deploy your Serverless application for the first time, you need to set up a custom domain for AWS API
|
|
Gateway. This is done using the sls create_domain command, which creates a custom domain in API Gateway that your
|
|
services can use.
|
|
|
|
To set up a custom domain, use the following command:
|
|
|
|
```bash
|
|
sls create_domain --stage dev --aws-profile DevAdmin --verbose
|
|
```
|
|
|
|
Replace dev with the name of the stage you're deploying to. This command only needs to be run once per custom domain,
|
|
and not every time you deploy your application. After running this command,
|
|
you can associate your AWS Lambda functions with this domain using the customDomain
|
|
configuration in your serverless.yml file.
|
|
|
|
This command requires the Serverless Domain Manager plugin,
|
|
so make sure you have it installed and properly configured in your serverless.yml file.
|
|
|
|
Please note that the process of creating and associating a custom domain can take up to 40 minutes.
|
|
Once the custom domain is created, it's immediately available for use in your Serverless applications.
|
|
|
|
Remember to replace DevAdmin with the profile that has appropriate permissions in your AWS account.
|
|
The `--verbose` flag is optional and is used to print detailed logs to the console.
|
|
|
|
# Creating a CNAME Record in Google Domains
|
|
|
|
After deploying the AWS Lambda function for the first time, you need to set up a
|
|
CNAME record in Google Domains to route traffic from your custom domain to
|
|
the CloudFront distribution created by API Gateway. This will re-route traffic from
|
|
your custom domain to the CloudFront distribution created by API Gateway, and
|
|
therefore to your lambda.
|
|
See [here](https://docs.aws.amazon.com/amplify/latest/userguide/to-add-a-custom-domain-managed-by-google-domains.html)
|
|
for AWS' documentation on this.
|
|
|
|
You can find the CloudFront
|
|
domain by going to the API Gateway console and clicking on Custom Domain Names.
|
|
|
|
Here are the steps to create a CNAME record:
|
|
|
|
1. Log in to Google Domains.
|
|
2. Select the name of your domain.
|
|
3. Open the menu, if it's not already open.
|
|
4. Click "DNS."
|
|
5. Scroll down to the "Custom resource records" section.
|
|
6. In the "Name" field, enter your subdomain (e.g., api if your API is available at api.example.com).
|
|
7. In the "Type" dropdown menu, select "CNAME."
|
|
8. In the "TTL" field, enter 1H to set it to 1 hour (or another suitable value).
|
|
9. In the "Data" field, enter the CloudFront domain that was created by API Gateway (you can find this in the API
|
|
Gateway console, under Custom Domain Names).
|
|
10. Click "Add."
|
|
|
|
This will direct any traffic from your custom domain to your AWS CloudFront
|
|
distribution. Please note that DNS changes might take some time (up to 24-48
|
|
hours in some cases) to propagate across the internet.
|
|
|
|
Also, please make sure that your CloudFront distribution is configured to
|
|
accept your custom domain as a valid domain name. In AWS API Gateway,
|
|
under Custom Domain Names, make sure that your custom domain is listed and
|
|
mapped to the appropriate API stage.
|
|
|
|
Remember to replace api and the CloudFront domain with your actual subdomain
|
|
and CloudFront domain.
|
|
|
|
Certainly! Here's a detailed documentation for your README:
|
|
|
|
* * *
|
|
|
|
Deployment Troubleshooting for `fastapi-lambda`
|
|
-----------------------------------------------
|
|
|
|
### Context:
|
|
|
|
When deploying the `fastapi-lambda` using Serverless Framework, you may encounter issues related to domain management,
|
|
especially if you're using a custom domain for your API. This documentation provides troubleshooting steps and details
|
|
on how to resolve potential conflicts.
|
|
|
|
### Potential Issues & Solutions:
|
|
|
|
#### 1\. Conflict with Existing CloudFront Distribution:
|
|
|
|
**Error Message**:
|
|
|
|
csharpCopy code
|
|
|
|
`One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution.`
|
|
|
|
**Cause**: This can occur if there's an existing CNAME record in your DNS provider pointing to a CloudFront
|
|
distribution.
|
|
|
|
**Solution**:
|
|
|
|
* Check your DNS provider (e.g., Google Domains) and verify the CNAME record for `api.dev.hestia.homes`.
|
|
* Temporarily remove or update the conflicting CNAME record.
|
|
* Run the `sls create_domain` command again.
|
|
* Update the DNS settings in your DNS provider based on the new configuration provided by
|
|
the `serverless-domain-manager` plugin.
|
|
|
|
#### 2\. Conflict with Route53:
|
|
|
|
**Error Message**:
|
|
|
|
csharpCopy code
|
|
|
|
`Deleting RestApi failed. Please remove all base path mappings related to the RestApi in your domains.`
|
|
|
|
**Cause**: This can occur if there are residual AWS configurations, especially in Route53, from previous deployments.
|
|
|
|
**Solution**:
|
|
|
|
* Navigate to the AWS Route53 Console.
|
|
* Identify and delete any residual Hosted Zones or Record Sets related to `api.dev.hestia.homes`.
|
|
* Ensure that you have backed up any necessary configurations before deleting.
|
|
|
|
#### 3\. Other AWS Resources Conflicts:
|
|
|
|
You might encounter issues where AWS resources, such as S3 buckets or CloudFront distributions, are not properly deleted
|
|
or are conflicting with new deployments.
|
|
|
|
**Solution**:
|
|
|
|
* Navigate to the respective AWS service dashboard.
|
|
* Manually identify and rectify any conflicting resources. This might involve emptying S3 buckets or deleting CloudFront
|
|
distributions.
|
|
* Ensure backups and proper precautions before deleting any resources.
|
|
|
|
### Additional Notes:
|
|
|
|
* **Backup Configurations**: Always backup your configurations before making changes. This ensures that you can revert
|
|
to a previous state if needed.
|
|
* **DNS Propagation**: Remember that DNS changes can take some time to propagate globally. After making DNS changes, you
|
|
might not see immediate effects.
|
|
* **CloudFront Distributions**: If you can't find a CloudFront distribution in the AWS CloudFront console, it's possible
|
|
that it was automatically created by another AWS service like API Gateway. It might need to be managed or deleted from
|
|
that service's dashboard.
|
|
|
|
### After succesfully running creating the custom domain
|
|
|
|
After successfully creating the custom domain with the `serverless-domain-manager` plugin, you should add back the CNAME
|
|
record into Google Domains (or whatever platform is being used to manage domains now)
|
|
to ensure that the custom domain properly points to the CloudFront distribution managed by
|
|
AWS.
|
|
|
|
Here's what you should do:
|
|
|
|
1. **Log in to Google Domains**:
|
|
|
|
* Go to [Google Domains](https://domains.google.com/).
|
|
* Navigate to the management page for `hestia.homes`.
|
|
2. **Add/Update the CNAME Record**:
|
|
|
|
* Find the section for custom resource records.
|
|
* Add (or update if it already exists) a CNAME record for `api.dev`.
|
|
* Point it to the CloudFront distribution domain name (e.g., `d2d269kjy1nyhz.cloudfront.net.`). Ensure you include
|
|
the trailing dot at the end. This can be found in API gateway
|
|
3. **Check DNS Propagation**:
|
|
|
|
* Keep in mind that DNS changes might take some time to propagate. You can use online tools
|
|
like [DNS Checker](https://www.dnschecker.org/) to verify the propagation status worldwide.
|
|
* Test your API endpoint `api.dev.hestia.homes` to ensure it's resolving correctly and accessing your Lambda
|
|
function.
|
|
|
|
By following these steps, you should have your custom domain properly configured and pointing to your AWS Lambda
|
|
function via the CloudFront distribution.
|
|
|