briancaffey / django-step-by-step Goto Github PK

Remove support for building with Heroku

• requirements.txt file in root directory
• Procfile
• runtime.txt
• Documentation in VuePress

Both the frontend and backend applications are upgraded via AWS CLI calls.

The frontend application upgrade script looks like this:

TASK_FAMILY=$WORKSPACE-$TASK

  # save the task definition JSON to a variable
  TASK_DESCRIPTION=$(aws ecs describe-task-definition \
    --task-definition $TASK_FAMILY \
  )

echo $TASK_DESCRIPTION | jq -r \
  .taskDefinition.containerDefinitions \
  > /tmp/$TASK_FAMILY.json

# write new container definition JSON with updated image
echo "Writing new $TASK_FAMILY container definitions JSON..."

# replace old image URI with new image URI in a new container definitions JSON
cat /tmp/$TASK_FAMILY.json \
  | jq \
  --arg IMAGE "$NEW_FRONTEND_IMAGE_URI" '.[0].image |= $IMAGE' \
  > /tmp/$TASK_FAMILY-new.json

# Get the existing configuration for the task definition (memory, cpu, etc.)
# from the variable that we saved the task definition JSON to earlier
echo "Getting existing configuration for $TASK_FAMILY..."

MEMORY=$( echo $TASK_DESCRIPTION | jq -r \
  .taskDefinition.memory \
)

CPU=$( echo $TASK_DESCRIPTION | jq -r \
  .taskDefinition.cpu \
)

ECS_EXECUTION_ROLE_ARN=$( echo $TASK_DESCRIPTION | jq -r \
  .taskDefinition.executionRoleArn \
)

ECS_TASK_ROLE_ARN=$( echo $TASK_DESCRIPTION | jq -r \
  .taskDefinition.taskRoleArn \
)

# check the content of the new container definition JSON
cat /tmp/$TASK_FAMILY-new.json

# register new task definition using the new container definitions
# and the values that we read off of the existing task definitions
echo "Registering new $TASK_FAMILY task definition..."

aws ecs register-task-definition \
  --family $TASK_FAMILY \
  --container-definitions file:///tmp/$TASK_FAMILY-new.json \
  --memory $MEMORY \
  --cpu $CPU \
  --network-mode awsvpc \
  --execution-role-arn $ECS_EXECUTION_ROLE_ARN \
  --task-role-arn $ECS_TASK_ROLE_ARN \
  --requires-compatibilities "FARGATE"

While this works, there is an easier way to write this using the --cli-input-json flag from the register-task-definition AWS CLI command.

Both the frontend and backend application update scripts should be re-written to use this argument instead of reading out memory, CPU, execution-role-arn, task-role-arn individually.

1. Change 'Django viesw' to '... views.':
2. Fix link to STEP BY STEP.MD:

ad hoc environments create a database in the shared RDS instance named {ad-hoc-env-name}-db this should be preserved by default when destroying an ad hoc environment in case it needs to be used again. There should be an option that allows a developer to destroy the ad hoc environment

Currently the API calls are scattered in different files and when refactoring the structure of backend URLs it is difficult to find and edit URLs. Defining all URLs in one file will simplify FE / BE configuration.

For updating the frontend:

• updating the new image is all that it is needed

For updating the backend

• the task definition must be updated
• the migrate and collectstatic commands must run with the new task definition / container image

First of all, thanks for this awesome project! I've learned a lot :)

I noticed in settings base.py, ALLOWED_HOST=['*'] which is a huge security risk in production.
In production, I tried setting this to [.domain.com]. The issue I encountered is that django gunicorn ECS service keeps complaining that I need to add 10.0.x.x to ALLOWED_HOSTS.
ERROR 2023-04-11 21:50:35,430 exception 20 140390254044992 Invalid HTTP_HOST header: '10.0.x.x:8000'. You may need to add '10.0.x.x' to ALLOWED_HOSTS.

Any suggestions on how to fix this issue? I tried following this post https://stackoverflow.com/questions/49828259/when-deploying-django-into-aws-fargate-how-do-you-add-the-local-ip-into-allowed but so far unsuccessful.

Appreciate your help!

1. Add navigation link at end of "Diagram of JWT authentication with HttpOnly cookies" page to beginning of "A guide to this VuePress site."
   

Old references to remove:

• "Use Nuxt for SSR"
• "Django Doctor"
• "constance"
• Raspberry Pi
• DigitalOcean
  • [ ]❓ Include removal of doctl?
• Docker Swarm on EC2
• Remove dead link to GitLab CI
• Remove gitlab-ci.yml file

Other things to consider (refinement/confirmation needed):

• Consider removing this section/page Step by Step Guide » What is a Django Application? as it's too long and probably not something to include in the docs.
• Bitbucket Pipelines?

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Hi @briancaffey,

Were you able to get the adhoc environment work? I didn't see the adhoc pipeline run on this project.

When I look at your github action workflow, the adhoc base create/update (spinning up new bastion host and new RDS) looks almost identical with the the prod base create/update, that means it doesn't seem to use shared resources. Can you help me understand this?
I was reading this documentation: https://hackernoon.com/ad-hoc-environments-for-django-applications-with-ecs-terraform-and-github-actions
Btw loved the detailed explanations!
Looking forward to hearing from you!

2 Parts to this issue:

Part 1

It seems the latest idiomatic way to define dependencies is:

[tool.poetry.group.dev.dependencies]

instead of:

[tool.poetry.dev-dependencies]

See: "A note about defining a dev dependencies group" here

Part 2

To separate dev and test dependencies—after the above change is made—we would simply need to move some items in the pyproject.toml into a new [tool.poetry.group.test.dependencies] group. I have found it helpful to separate out the test dependencies for github actions / CI purposes.

I tried to pass Github secrets to terraform using TF_VAR_variable_name, then use as an environment variable for Gunicorn task, but so far it has not been successful.
I saw in your terraform-aws-django modules/prod/app module "api" there is a variable called extra_env_vars. What is the use case for this? Can we actually use this variable to pass secrets from Github?

I would appreciate if you have any suggestions on how to pass extra environment variables to django.

Thanks!

The GitHub Actions for Terraform and other IaC tools should use the following pattern:

• terraform init + plan
• manual review (using environment set on the job)
• terraform apply

We can use artifacts to pass the terraform plan file available from the init + plan job to the apply job

This has already been successfully implemented for the Terraform prod base create/update and prod base destroy workflows. Here's an example:

The other Terraform workflows need to be updated using the same pattern:

• prod base create/update

• prod base destroy

• prod app create/update

• prod app destroy

• ad hoc base create/update

• ad hoc base destroy

• ad hoc app create/update

• ad hoc app destroy

Some links and issues:

• the actions/upload-artifact / actions/download-artifact actions do not preserve the permissions of the files, so executable permissions need to be set manually using chmod
• I set the working-directory default for run, but this does not apply to the artifact jobs, so artifacts need to be set relative to the root of the repo (not relative to the root of the default working directory) see this issue for more
• I'm following the recommendations from the document Running Terraform in Automation from the Terraform docs, which recommends artifacting not only the tfplan file, but also the .terraform directory. This allows us to run terraform init only once in our workflow.

cc @codyfletcher

The Makefile has a lot of targets that are no longer used. Remove unused targets and improve targets for working with virtual environments

https://www.postgresql.org/docs/14/index.html

Make and test updates for postgres in:

• RDS
• docker compsoe
• docker swarm
• CI builds
• local environment

I was having some trouble getting things to work out of the box. I think this repo got out of sync with the terraform-aws-django repo (but I could totally be wrong).

Comparing /terraform/live/prod/app/main.tf in this repo to the example in the terraform-aws-django repo.

See diff here from recent changes.