terraform-aws-django
cdk-django
Our great sponsors
terraform-aws-django | cdk-django | |
---|---|---|
8 | 10 | |
27 | 46 | |
- | - | |
0.0 | 5.1 | |
over 1 year ago | 6 days ago | |
HCL | TypeScript | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terraform-aws-django
-
My Infrastructure as Code Rosetta Stone - Deploying the same Django application on AWS ECS Fargate with CDK, Terraform and Pulumi
terraform-aws-django
-
This is how you want to manage your Terraform modules
+1 for release-please. Here's an example of how I maintain my module's changelog with 13 lines of yaml in a GitHub Action using release-please: https://github.com/briancaffey/terraform-aws-django/blob/main/.github/workflows/release-please.yml
-
Scenario based question for DevOps Engineers out there
Here are some other questions that would be good to ask about the infrastructure: * What AWS account will this run in? Who has access to that account? Are SSO permission sets used? * What DNS records will be used to access the frontend and the backend? Are these two services accessed via the same record URL? For example, all do you to only send example.com/api/* traffic to the backend and then send all other example.com/* to the Angular frontend? Or do you want to use api.example.com for all API traffic and example.com for the Angular site. What about non-prod environments? Will you use alpha.example.com for a staging environment for a non-prod environment named alpha? * You mentioned that the team will be using Terraform heavily, how will you be splitting up your modules? When you run Terraform's apply command, does it update a single set of infrastructure for your entire application, or do you run terraform apply several times for different groups of resources, such as a networking stack (with VPC), data stack (with RDS) and application stack (for ECS resources), for example? You will probably use terraform remote state to manage these different logical components and the data dependencies they have between each other. * Another related question is how you are running pipelines for Terraform? I would use something like GitHub Actions. When a pipeline runs, you should see the output of a terraform plan stage and then the pipeline should pause for manual approval after the changes have been reviewed. This can be done with GitHub environments, for example, and other CI/CD tools can also do this. * What happens when you need to change an environment variable? This can be a complicated question. Environments that are not secrets might be stored in a terraform.tfvars file, or might be stored in environment variables in your pipeline in the form of TFVAR{name}, so this implies that changing an environment variable is an infrastructure change. You want to keep your infrastructure deployments separate from your application deployments. If you are using ECS, you probably want to use ignore_changes for the task definitions referenced by the services. This will create a new task definition, but it will not be used by the new services. When you do an application update, the service may use this new task definition with the updated environment variable. * Another question: does anyone on the team need direct access to the database? Is there a bastion host used in the infrastructure that can people can connect to the DB with via port forwarding? I hope these questions are helpful. I have thought about a lot of these and have been exploring their answers with an open source project focused on a containerized, database-backed Python web app (made with Django) that I deploy on AWS with ECS Fargate, and I have another repo with Terraform modules for deploying application infrastructure. Here's the application repo: https://github.com/briancaffey/django-step-by-step and here is the Terraform module repo: https://github.com/briancaffey/terraform-aws-django. Please let me know if you have any questions
-
The appropriate way to deploy full stack app on ECS
Here's the Terraform code: https://github.com/briancaffey/terraform-aws-django
-
Django Docker Containers and good example projects
Here's one of my practice projects that I use for learning and practicing deployments. It is a simple microblogging application that implements the application both using the MTV paradigm and the REST/SPA paradigm. My deployment efforts are narrowly focused on ECS Fargate, one of several ways to run containers on AWS, and I also focus on using Terraform and GitHub Actions to both build infrastructure and deploy new versions of the application. terraform-aws-django is repo that contains all of the Terraform code that is used to build the application. Happy to answer any questions about these repos!
-
Best practices for manually accessing interactive shells and databases for web apps running on ECS Fargate
Here is the repo where I have things set up in Terraform: https://github.com/briancaffey/terraform-aws-django/tree/main/modules/internal/bastion
-
Setting up ad hoc development environments for Django applications with AWS ECS, Terraform and GitHub Actions
terraform-aws-django
-
Having issues running terraform init in a directory containing only a tfvars file that references remote git repo source
source = "git::https://github.com/briancaffey/terraform-aws-django.git?ref=v0.0.2" region="us-east-1" ...
cdk-django
-
My Infrastructure as Code Rosetta Stone - Deploying the same Django application on AWS ECS Fargate with CDK, Terraform and Pulumi
cdk-django
-
My Infrastructure as Code Rosetta Stone - Deploying the same web application on AWS ECS Fargate with CDK, Terraform and Pulumi
CDK Construct Library: github.com/briancaffey/cdk-django
-
Django AWS CDK deployment
- Another aspect of my approach that I prefer over the other one is using a high-level construct that you publish and then consume in your project. This requires that you write a construct in TypeScript and then publish it to npm or PyPI. I'm working on a construct library for deploying Django apps with CDK called djagno-cdk, and one of the constructs in it uses ECS Fargate: https://github.com/briancaffey/django-cdk/blob/main/src/django-ecs.ts. Ideally you don't have everything in a single construct though, so I like how Mariano is doing that in his project. My Terraform project does a better job at separating layers of the application, so I need to apply that same principle to django-cdk when I get around to working on that project again.
-
My approach to building ad hoc developer environments using AWS ECS, Terraform and GitHub Actions (article link and diagram description in comments)
Sure. My IaC journey actually started out with CloudFormation, and I learned a lot from this reference project: aws-samples/ecs-refarch-cloudformation. Then I picked up CDK when that became available and migrated a project from CloudFormation to CDK. It sounded like a nicer way to handle stacks in a familiar language with lots great one-liners and utility functions and constructs, and it definitely is. I have a similar project written in CDK that is an application/framework-first (Django) approach to learning and doing IaC that you can find here: https://github.com/briancaffey/django-cdk. This implements both ECS and EKS, but my attempts at learning EKS sort of fizzled out for now as I don't have the need to use it, and for the task at hand (running a monolithic Django application on AWS) I think ECS makes a LOT more sense.
-
Basic questions about Django app deployment on AWS
I have an example of doing this here, and I posted about this earlier on this sub https://www.reddit.com/r/django/comments/rj7sj2/deploying_django_applications_to_a_singlenode/
-
Deploying Django applications to a single-node docker swarm cluster on EC2 with AWS Cloud Development Kit (CDK) and GitHub Actions (description, repo links + full article in comments)
I'm not sure what you mean by "architecture", and I'm not sure what is wrong with trying to save money while learning how to do IaC and CI/CD. My thinking is that I can use some of what I learned here in a more robust setup of a Django app that uses ECS, I'm working on that here: https://github.com/briancaffey/django-cdk/blob/main/src/django-ecs.ts.
-
Any examples of custom ecs constructs which builds on the top of ecs patterns
Here is on that I’m working on: https://github.com/briancaffey/django-cdk
-
Ask r/kubernetes: What are you working on this week?
Here's a link to the repo: https://github.com/briancaffey/django-cdk. This library currently offers high level constructs for EKS as well as ECS. I have previously used ECS for most of the containerized web apps I have worked with, so I'm hoping to use this as a way to compare the two orchestration tools for my use case and gather some best practices. This project includes a companion repo that is included as a git submodule that I have been to do live tests/deployments using my construct library.
What are some alternatives?
terraform-aws-ecs-alb-service-task - Terraform module which implements an ECS service which exposes a web service via ALB.
aws-cdk - The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
pulumi-aws-django - A Pulumi package for deploying Django applications to AWS using ECS Fargate and other managed services
pulumi-quickstart - Pulumi best practices
terraform-aws-ad-hoc-environments - Shared resources for supporting multiple ad hoc environments in an AWS account for software development teams
preview-environments - Quickly create temporary preview environments
briancaffey
knboard - Kanban boards with React & Django.
ps-menu - Simple powershell menu to render interactive console menu
actions - A collection of GitHub Actions to run Pluralith in CI and automate infrastructure documentation generation
release-please - generate release PRs based on the conventionalcommits.org spec
ctk - Visual composer for container based workloads