Just wanted to ask if this was an 'acceptable' use of the django sites framework and heroku - and if there would be any trouble running the two sites:
Main differences between sites will be templates, and some objects only published to one or other (or both) sites - notably users should be able to use both sites using their single account.
I have my one codebase. Any change in my settings.py file is dealt
with by using heroku config variables.
I set up database that can be shared (either on an EC2 or using
Heroku dedicated dbs)
I git push my code to two different Heroku Apps
Hey presto - one codebase, two running instances of Django, two separate sites.
Any issues with that?
I went into great depth to answer this question in another thread, you can see my answer here: Multiple Django sites with shared codebase and DB
The short answer is NO, don't use the sites framework, use git branches.
Related
I am using Django as the back end and Nuxt as the front end, with Postgres as the database. I would like to have different tables/databases for each domain.
The Django code and the Nuxt code will be the same for all sites.
The way the app is set up, it requires different domains to have different databases or at least different tables.
At the moment, I am thinking I need to create a separate installation of Django/Nuxt for each domain. But I am wondering if there is a better way?
Setting up different Code bases for every domain is not a good idea at all. I had an app that was set up that way and soon we were struggling to maintain the same code and DB structure for all the different domains. After a few domains, it will become tricky.
I would suggest developing a multi-tenant SAAS based app, where you can have multiple tenants running the same Django/Nuxt code but having different schemas in the Postgres, So your database for different domains will be completely separate from each other. I would suggest using django tenant schemas for this. Even if it takes you some time to set it up, I would suggest doing it. It will save a great deal of time for you in the future.
So, I am new to this "monolith vs microservices" architecture debate and I have pretty much understood most of it. From my limited understanding I get it that in microservice architecture each feature(lets say) is a separate app. Now I need some clarification with respect to django for implementing microservices. Heres my question
Should I make every microservice aka the app a different django project altogether OR should I make every app aka the microservice inside one django project and keep them isolated (as in loosely coupled) ?
Microservice architecture simply states that your each service should be independent of each other.
Its also not necessary to create one micro-service in java and one in python since they are not related.
So yes, ideally your each micro-service is a separate django project.
The best way to break this, first list down all the possible modules in your site or app.
Then go through :
https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
These are two recommended pattern of how you should divide modules / domain into micro-services.
well, you can use database routers in django ... that does the trick ... one wSGI file per app communicating with your NGINX server
The main purpose of micro service is to serve the specific business, for example you are running a cloud kitchen then Django project can have many sub projects under one master project or you can run each project as separate service, it up to you.
Service
backoffice
finance
rider
kitchen
now we will set the url for each service like
Endpoints
backoffice.mycompany.com
finance.mycompany.com
rider.mycompany.com
kitchen.mycompany.com
Once our app is up the service load will not effect other service.
The microservice should be completely independent so it should not belong to one Django project. You should be able to deploy each service independently with its own database, so even you split the project into separate apps they still share one physical database and you can not deploy them separately. Therefore, you could potentially create separate Django project for each 'microservice' but this does not make much sense. You put lot of overhead for creating a microservice and also using Django framework is not a best choice for MSA , have a look at Flask.
I try use dokku for my web projects - deployment become cool. But I can't find information about two things.
Can I autocreate database from dokku-util? How?
How and where store media files without using AWS? I want use only my vps'.
P.S. Or may be you see good materials about full workflow for dokku?
You can add plugins to dokku. Connect to your VPS, go to the /var/lib/dokku/plugins folder and then you can 'git clone' various plugins from github. There are a list of plugins on the dokku site that will create mysql, postgresql, redis, and other databases.
While the plugins work great, I prefer to run a second VPS that just hosts databases.
There isn't really a good way of serving static files directly from django--even when it's under docker. There is an app called dj-static that will help, but the author appears to be slow to update it for newer django releases. (https://github.com/kennethreitz/dj-static)
Let's imagine I have two sites foo.com and bar.com. They both are on the same server and now running separate Django instances and apache to serve it. Of course each Django instance eats the memory.
While mainly those sites are the same systems, but with different apps loaded - maybe it is possible somehow to have for example one Django instance running and have multiple sites using it? Then I will save memory for the one instance in a particular example.
It is possible to have different sites with their url.py files, loaded apps and so on? And if this is the right way to go?
Any tips, ideas are welcome.
Thanks,
Ignas
Yes it is definitely possible to have different sites with different urls.py and shared apps.
I had to share a backend data between multiple sites. I just created 2 wsgi config files. And 2 settings files. The sites are very smiliar and didn't warrant two seperate projects. This allows me to use one django project and backend between multiple sites. I don't quite know if this is what you were asking though...
My own research today on the same topic leads me to the conclusion that you'll most likely have to have only one settings.py per Django instance/process. And the sticking point there is only one MEDIA_URL and one MEDIA_ROOT, which means all your projects media will have to be in the same location. And actually Django 1.3 has a new static file process that just goes through all the media of your seperate apps and puts them in one spot because for some reason it demands that. If you're using earlier versions I guess you can do it by hand.
https://docs.djangoproject.com/en/dev/howto/static-files/
uWSGI can serve more applications from one instance.
See "Two Pinax site in two virtualenv in two virtualhost with only one uWSGI instance" in uWSGI examples and VirtualHosting Mode.
I have multiple sites for the same client, on the same server, running django, e.g. fooplumbing.com and bazheating.org. These two sites would each have different django apps, that is the plumbing site shouldn't be able to access the heating apps, and vice versa. There are no objects shared between the two sites, and each needs its own separate admin site.
Is this possible through something like the sites framework, or would I need to have two separate apache instances running the sites? (Yes, I need to use apache - no choice)
It's a Linux server, so is there some clever way of using symlinks to do this? I'm pretty experienced with basic django development, but I have no clue when it comes to server management.
The sites framework won't help you - they should be served as completely separate WSGI applications.
But there's no need for separate Apache instances. Just configure Apache to serve separate VirtualHosts, each with its own WSGI file.