ecs-refarch-cloudformation VS django-step-by-step

I first started out with IaC following this project aws-samples/ecs-refarch-cloudformation (which is pretty old at this point) and wrote a lot of CloudFormation by hand. The pain of doing that lead me to explore the CDK with Python. I learned TypeScript by rewriting the Python CDK code I wrote in TypeScript. I later worked with a team that was more experienced in Terraform and learned how to use that. I feel like Pulumi takes the best of the two tools and has a really great developer experience. There is a little bit of a learning curve with Pulumi, and you give up some of the simplicity of Terraform.

Yes, deploy them as nested stacks inside a parent template. You can reference outputs via !GetAtt NestedStackX.Outputs.OutputName. see this repo for an example https://github.com/aws-samples/ecs-refarch-cloudformation

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.

I'm mostly using just EC2 instances running Docker Engine and Docker Compose (with configs and Compose projects in Git), but I'm starting to use CloudFormation and ECS more. I've taken a lot of inspiration from https://github.com/aws-samples/aws-refarch-shibboleth, https://github.com/awslabs/ecs-refarch-continuous-deployment, and https://github.com/aws-samples/ecs-refarch-cloudformation. At some point in the future, I plan to refactor my CloudFormation/ECS deployments into something more cloud agnostic using Terraform/Kubernetes.

If you need more options that is provided the Docker/ECS tool listed above you can roll your own using CloudFormation (the AWS deployment scripting tool). There's a good starter here.

Here's an example of a docker-compose file in my reference Django project: https://github.com/briancaffey/django-step-by-step/blob/main/docker-compose.yml

Mono repo with a sample Django micro blogging app (μblog) and frontend app (Vue SPA written with Quasar), GitHub Action workflows for infrastructure and (separate) application deployment pipelines, IaC code that consumes each of the libraries listed above, VuePress documentation site and miscellaneous items (k6 load testing scripts, Cypress tests, docker-compose, etc.): github.com/briancaffey/django-step-by-step

This project also uses a model manager to make it easy to show how many people like a post as well as if the current user likes the post or not https://github.com/briancaffey/django-step-by-step/blob/main/backend/apps/blog/managers.py.

Here's another repo that consumes these IaC libraries and deploys them through GitHub Actions pipelines: https://github.com/briancaffey/django-step-by-step

By ignoring changes here you don’t have to worry about infra upgrades pushing out application updates. And you can update your app with with a separate pipeline. My code uses AWS CLI to register new task definitions. Here’s an example of my pipeline that deploy the app: https://github.com/briancaffey/django-step-by-step/blob/main/.github/workflows/ad_hoc_update_backend.yml

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

Here is how I organize my modules for an example microblog app: https://github.com/briancaffey/django-step-by-step/tree/main/quasar-app/src/modules

Yes, this is possible. There are different ways to do this and it will depend on how and where you host your applications. Here's an example project of mine that I run on AWS that uses some the same URL with some routes for Django template-powered views, some views for a Vue app, some views for REST API and some views for GraphQL: https://github.com/briancaffey/django-step-by-step.

Here's an example of how I implement CI and CD with a Django project on AWS using GitHub Actions. I use ECS Fargate. https://github.com/briancaffey/django-step-by-step/blob/main/.github/workflows/backend_linting_and_unit_tests.yml