What is the right way to handle a production and development website on the same server? the development code shouldn't be available until it's used for production.
I'm using Apache and Django and VPS hosting.
What should I configure? Apache- so it will have a special prefix for development stuff, Django- and have some URL mangling in the urlconf, or just get another VPS for development?
Find an old computer and stick it in your basement. you really don't need tons of horsepower for a dev machine & should be able to do it for a couple hundred bucks.
The problem with developing on a production machine is that you could crash processes [apache?] with some 'not quite debugged yet' code and affect live services, even if you have configured separate subdomains or virtual hosts.
never never never develop live.
-sean
PS> another VPS is a workable solution if 'spare hardware' is not available. However you could have availability issues.
Related
A bit of background
I work for a little company as Django developer. The previous developer left the company and I am the only developer (that is the reason they were looking for a Django developer). The company has a simple web application that needs to be mantained and scaled. It seems that the company is getting sales and incomes are increasing. There is a possibility to hire another developer in the short or mid-term. Right now I am analizing possible improvements. This is my first professional job as Django developer, but I achieved to deploy some little personal projects in the past. As you can imagine I am not an expert at all.
The issue
We use a Ubuntu VPS for development, using Django's integrated web server. And another Ubuntu VPS for production, using Nginx+Gunicorn. We use git for version control. The only user we use (for everything) in both VPS is root. I don't work locally in my computer, but connected via ssh to the servers. These are my insights about the structure:
Use of root is unsafe. No doubt about it and we should change this.
What if another developer is hired? Could we work together in the development server?
The question
As the title says, I want to know which would be the perfect working structure for a developers team. After googling a few hours my approach would be something like this:
Production server.
Testing server (replicating as much as possible the production server).
Development environment. Every developer should work and test their code locally in their computers before testing it in the Testing server.
Use of Git for version control.
Use of non-root users for both testing and production servers.
This is just my point of view and I haven't even tried it. I would appreciate you to share your knowledge and experiences.
Thanks in advance!
I have a site that I want to expose to a bunch of colleagues that serves as an interface for some Machine learning tools.
I’ve made the site in Django 2.0 and would like to serve it from a small windows PC under my desk, and then from a more dedicated server once it’s operational.
I’ve had a look around and it looks like my options are using uWSGI or Django it self to serve the site. Obviously Django is mich slower, but on a PC with an i5 i recon it should be able to handle a couple of requests a minute, which is the peak traffic I’m expecting.
FastCGI appears to be depreciated, so what other options, prioritizing ease of confit on my part are there?
So anyone in a similar situation:
I ended up using waitress as the server and whitenoise to serve the static files.
This appears to work sufficiently fast and requires little configuration, once you have have worked out how to get the static files going with whitenoise.
Django itself can serve pages to other machines on your network. SImply start the local server with this command
python manage.py runserver 0.0.0.0:8000
Then, you can access the local website by requesting http://<dev_machine_ip>:8000. Obviously, this is a very simple and inefficient solution if you want to provide this website to many users connected all at the same time. But for tests/demo purpose, it is very handy
To this point, I just created and played my Django server in my localhost, like setting up a basic server Linux distro on my another device and testing etc.
However, I also heard of server applications like apache2 or nginx. The thing I wonder about is: Do I really need to use one of them in production? I want to buy (or rent?) a VPS service, then deploy (or publish?) my project on that server. The questions on my head are:
Running server with manage.py runserver 0.0.0.0:80 means it does not make my application worldwide? An server application (or whatever it is) makes it accessible outside?
Or a server application is simply needed for better performance, optimization etc. ?
Simply, why do I need to use apache2 or nginx to deploy my project?
It's a long story. In few words:
Running your project on localhost surely wont make it worldwide accessible, since at least you need a public address for your server, but not a local one.
Speaking honestly it is not a problem to run a site in pro using django built-in server. But, as you can read in docs, it is strongly NOT recommended. Why? Because it was developed specially for testing. It is written in python (slow enough for web server) and not suitable for handling multiple queries to the server and it is only a matter of time when it will crash. Of course, there are plenty of other reasons like cache and access settings, redirects and others.
What is to stop you using a WAMP server (or similar) to run single-user business database applications day-to-day?
I read everywhere that WAMP and the like are intended for the development of web apps, but why can't they be used to deploy desktop apps - what're the downsides?
Personally I think WAMP/MAMP/LAMP are great applications that CAN be used for production servers.
I have started doing this myself as I do not have the complete knowledge in server administration on the linux end and my PHP applications are not compatible with IIS.
If you are a small operation than it should save you time then go for it.
If your business grows and you can afford to put on staff to manage dedicated servers with the Apache, PHP ect all installed separately then I also recommend this.
The main difference I can see is that WAMP probably wont be as scalable as the preferred setup. The binaries are all integrated and sometimes I have had issues trying to figure out which php.ini file the system is using.
WAMP is just as secure as any other server as long as you know how to do so, is provides a UI layer which cost CPU time but like I said if you are only serving small web sites/apps than this should be just fine.
My other recommendation is to install it on a Server (Windows 2008 RS or 20012) Windows servers are more reliable and powerful than the Windows User version. Just remember to turn off IIS and any other roles not used by the Windows Server.
Make sure you your WAMP folder backed up regularly!
Good luck
I haven't found one yet. I guess the speed won't be as good as a 'pure' setup, but it sounds like that isn't an issue.
I run an epos web app for a photo studio no problem at all!
WAMP usually stands for Windows, Apache, Mysql, PHP or whatever your particular choice for P is. It describes a stack meant for specifically for deploying/developing web applications and is a rough equivalent to LAMP. Most things that would be considered desktop applications wouldn't use a webserver and more than likely would not be written in PHP.
The issue is not so much one of downsides as it is Apples and Oranges: Desktop applications are usually built with a less web centric stack.
Actually i used with wamp for many purposes; I used it with VB.NET apps, PHP, etc...but I think if you want to use it for deployment, you should start by configuring it to do so.
For example, for PHP deactivation errors display in php.ini, start listening on all allow all in httpd.conf, activating safe mode, setting a password for MySQL; and many other options that have to be configured.
I personally prefer because it is a quick and lightweight tool.
Concerning the built in debugging server started with the manage.py runserver command, the Django docs state, "DON’T use this server in anything resembling a production environment."
If I wanted to develop a Django application over ssh on a remote machine, would using Nginx as a proxy to a running Django debug server be a reasonable thing to do? Is the Django debug server insecure, or just not built to handle large amounts of traffic?
From the Django docs:
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that's how it's gonna stay. We're in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)
So, that answers the latter two questions. As for the former, it depends on how your debug server is set up. If your server is exposed to the public Internet, doesn't have a firewall blocking port 8000, and you intend to use runserver with something other than the default 127.0.0.1 address, set up a more 'proper' application stack.
If you're going to use nginx, why not just use the suggested FastCGI configuration so that your debug environment will be more similar to the future production environment?
Modern web servers have all sorts of features, related to both security and performance, that the Django development server does not. It is a stripped-down, very basic, single-threaded server for the purposes of development. Hence why the docs say to not use it in a production setting.
However, people get way to afraid of this statement. The key defining point is that it's for development. Whether that development takes place on your local machine or a remote VPS or an entire cluster is besides the point.
If the server is publicly available, it will be open to hacking, breaches, DoS attacks, etc. But, if what's there isn't of any importance, just a development site running on dummy data, it doesn't matter. So, yes, you can use the development server on your remote server for development purposes. There's nothing at all wrong with that. My only caution would be to avoid using production data (such as using a dump from your production database to develop against) because that data could be compromised. Otherwise, it's no big deal.
Is the Django debug server insecure, or just not built to handle large amounts of traffic?
IT IS BOTH INSECURE AND NOT INTENDED FOR HEAVY TRAFFIC!
It might take care of a few of the issues by hiding the testing server behind a proxy, but if you're going to that much trouble you've done about the same amount of work as you need to do it right... right being WSGI. Use mod_wsgi, gunicorn, or check this out for more bleeding-edge solution: http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html. Whatever you do.... DON'T USE THE DJANGO TEST SERVER FOR PRODUCTION ENVIRONMENTS!