How do you deploy a django application to a server?

Question

Django

Hello, I've been developing with django for a few years now. And still there is a feeling that I do not know something.
Recently I asked myself the question, but am I effectively deploying the application to the server?
From the arsenal, I use fabric, vagrant.
With the help of fabric, I assemble the project, clean up the unnecessary, tag, archive, start a new server, copy and deploy the environment, raise the project, and update the DNS of the server.
Previously, I had the practice of constantly raising a new server from 0 when I launch a new version, but when the database, nginx and everything related to the project are on the same server, it became not very cool to synchronize constantly.
I started looking towards Docker or running all this goodness on several servers to make the update easier.
I don't use Heroku, I run everything on a regular dedicated server.
Write how do you do it?
What tools do you use, and what disadvantages do you see.
If you need more details, I will describe my approach.

Answer 1

Based on your question - "deploy" is a turn of the server from scratch to a working state.
It all depends on the number of deployments:
1. If it's enough for you to deploy 1 server and forget about it, it's easier to pick it up with your hands.
2. If you are constantly deploying > 2 servers - you definitely need to use automated tools.
Let's consider several popular tools:
1. Ansible - in my opinion, the most convenient tool for fast and convenient work with a fleet of servers, installs all the software and settings on your VPS.
2. Docker- allows you to create another virtual machine on your VPS with predefined settings and software, it is also sometimes used to run several databases / web servers in parallel, etc.
3. There is also Puppet, Chef, Salt - I did not use them.
Let's consider another interpretation of the word "deploy" - uploading project changes to a server that is in working order (i.e. there is already a working project)
It all depends on the size of the project:
1. If the project is small / medium fabricdoes a good job of pulling changes from the repository / collecting statics / reloading nginx, etc., but using it to rotate the server is hard work that is easier to do with other tools (described above). I myself also use fabric to update my sales.
2. If the project is large and is approaching a highload, then you need to use Continuous Integration , this will allow you to do an automated layout of the code on the production server - for example, push commits to the repository on github, the hook works, Jenkins starts working, tests run, if successful tests are updated prod.
There are many tools for CI:
1. Jenkins - simple and free, with a bunch of extensions and other goodies.
2. Travis-CI - free for open source, paid for private projects ($69 minimum plan).
3. Buildbot, tox - did not use.
PS I think that the concept of "deploy" is the laying out of changes on the production server. What you are doing - creating a new server, deploying the environment - is closer to deploying the server. If this is done every time changes are made to the combat server, the workflow must be changed.

Answer 2

Deployed django+uwsgi+nginx
On locale - all branches and all push to master.
On VPS - git pull, makemigrations, migrate, collectstatic, touch uwsgi.ini
<30 sec

Answer 3

well, you understand that there can be no universal way - it all depends on the size of the project , the
main question to which the answer is sought during deployment is "does everything work", from where there are two steps 1) updating the code 2) testing
with (1) there are no problems: we have Ansible, but I think, at least fabric, at least the admin with the command line (although this should be avoided due to the inexpressibility of experience), the code will be updated
, but with (2) ... all the problems: for example, on tests, the base stub, and that's it works, but on the production some new autoincrement / sequence and hello ...
therefore, such a distributed zoo of production and testing machines can only be supported automatically + keeping the same Ansible configs in the turnip
plus the main pain - which areas to write tests for, there will never be enough time for "everything where you want" not Bamboo (Bamboo too, but occasionally), but Jenkins - with it there are simply more able testers, i.e. it’s not so easy for people to master new tools.
All this pays off when the project is large, with a weak dependence on staff, no need to remember “how it was”, etc., but this time is worth it, a lot of time, a lot of paid time
. immutability of code sections, which, of course, is very difficult for large projects.
Therefore, the only thing that is useful for you from this topic is the recommendation to use Ansible
as for Docker - then, of course, no Dockers on Proda,
however, if, perhaps, in your practice, images are used as a way to quickly restore and projects are small - then why not No