Demonstrating how to get ASP.NET Core and Django development environments up and running with Docker and Docker Compose.
There are slides I have prepared to go along with this repository. You can find it in the root project folder as Intro to Docker.pdf.
All commands below are executed from within the django folder unless noted otherwise.
-
docker-compose up -dto spin up the containers -
If this is the first time your containers have been built, you will have to apply database migration scripts before the app will function. To do that, run:
docker exec -it django_app_1 python manage.py migrateIf you're not sure whether you've run that command already, don't worry, it won't re-apply migrations you applied previously.
-
On your host machine, navigate to http://localhost:8000/api/ideas
If you make code changes to the Django project outside of the container, those changes will be reflected immediately. Sometimes, syntactical errors or Python exceptions may cause the django_app_1 container to stop. Simply run docker-compose up -d again to start it back up.
All commands below are executed from within the aspnetcore folder unless noted otherwise.
The source code in the aspnetcore directory is bind-mounted to the container's filesystem. This environment's app service runs a file watcher so that ASP.NET Core automatically reloads after code changes.
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -dto spin up the containers- There's no need to apply migrations manually here, as this project has been set up to apply migrations during app startup.
- On your host machine, navigate to http://localhost:8080/api/ideas
This is very much not a real production environment. There are online resources on getting your containers production-ready, which are beyond the scope of this project. A good place to start is Docker's own Use Compose in Production.
In this variation, we copy our source code into our own custom ASP.NET Core runtime image and compile it using a Release configuration. This custom image is given a name and a tag, which allows it to be pushed to a Docker image registry and re-used by others.
This variation does not auto-reload upon changes to the code in our host machine, because the building, compiling and running of our application is all part of the Docker image build process. If this was a real production image, this helps keep our image size small and focused solely on running in production.
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -dto spin up the containers. Note the use ofdocker-compose.prod.ymlas the follow-up Compose file instead of.dev.yml- There's no need to apply migrations manually here, as this project has been set up to apply migrations during app startup.
- On your host machine, navigate to http://localhost:8080/api/ideas
docker-compose stop: Stops the containers, you can think of it like suspending a virtual machine.
docker-compose start: Starts the containers you previously stopped
- To tear down your containers (effectively deleting them), navigate to the project you'd like to tear down and run
docker-compose down - Your database's volumes will be kept around, because volumes can be shared amongst containers (even those outside of your Compose file!). To remove volumes that aren't currently in use by a running container, run
docker volume prune
Please file issues to ask questions and provide constructive feedback. If you're feeling extra nice, I welcome pull requests too. My hope is that this repository becomes an even more useful teaching tool as time goes on.