- Docker and Docker Compose
And that should be it. That's the beauty of containerization.
Django, Vue and PostgreSQL images will be downloaded and laoded into seperate containers.
For Django all the requirements are specified in Pipfile created by pipenv and in Vue's case
it's package.json created by yarn.
For more details check Pipfile and package.json.
When first time building a project run
docker-compose build && docker-compose up -d
This will create and initialize containers with all necessarry services for development. You can now
check your localhost:8080 for running Vue server. The same goes for localhost:8000, where Django
should be accessible. You'll see an error page that says "TemplateDoesNotExist at /". It's
because Django is configured to serve a template file at '/' in the production environment, but it's missing since it's the development environment. You can check '/admin' for the admin login page.\
If you want to launch already built containers just run
docker-compose up -d
where -d means it runs in the background. Otherwise all the logs from the containers would end up
in you stdout. If you want to access the logs just run
docker-compose logs -f [SERVICE_NAME]
You can find yourself in need to access the container itself. You can do that with
docker-compose exec [SERVICE_NAME] bash // or some other shell used by the container*
If you want to stop and remove containers created by up you can simply run
docker-compose down
When rebuilding it's a good idea to add these flags to the build command:
docker-compose build --force-rm --no-cache && docker-compose up -d
For more info visit official Docker docs here.
Once the containers are up you usally want to visit localhost:8080. That's where Vue development server is running. Thanks to the config in vue.config.js every request at "/api/" is redirected to django:8000, so in other words container with Django development server.
You can easily develop your app outside the containers since almost every change will be automatically applied inside them. The only exception is when you change something in the development configuration, then you should rebuild the containers.
TODO
Starting and removing containers for production is basically the same thing with one small difference:
You can do this using -f flag, see example below.
docker-compose -f docker-compose.prod.yml up -d
(By default Docker Compose will use docker-compose.yml that's why you didn't have to do this for
development environment.)
Although container related commands are quite similar, the way the production build works couldn't
be any more different from development one.
First of all there is an Nginx web server running in a container. This is like a gateway from the internet to the backend. All the requests on the site will go through this web server and its job is
to find requested resources and send them back to the user.
Django is run by Gunicorn, which is a web server gateway interface (WSGI).
It's kind of a middleman between a web server (Nginx) and WSGI app (Django) that makes them work together. For more info see here.
So the Nginx is listening on localhost:80 and passes requests to Gunicorn which is running in Django's container on port 8000, so in other words django:8000. Of course the production build is not meant to
be run on your local machine but rather on some remote Virtual Machine like those on DigitalOcean or Heroku so the localhost will be
replaced by the address of your remote server.