Hi,
My IT Management asked me to think about grouping the next services offered to the laboratory in a single website for users - IT tools. As I’m still junior with no experience in multiple services architecture grouped to a place i’m coming here to ask for advices.
I thought on doing a single webserver with multiple django apps, sharin a common navigation bar to easily switch from a tool to another one.
To keep repositories and dependancies appart, it seemed to me that having an architecture like this would be ok : (Debian/apache server)
/var/www/it-service-website/
| — Project 1
| — Project 2
…
| — Shared Navbar. (we are using a menu.py file generating data for templates that are duplicated through projects)
This way, each project can have it’s own “menu.py” file in it’s repository for dev set up, and when going into test/prod, the process replace the menu.py file for a slink pointing on shared navbar (which would require it’s own repository, or a script collecting all sub menu.py to concatenate them into one).
Apache set up would redirect /project-X/ to corresponding folder, where django take over url dispatching.
Considering all this would work correctly, i’m facing a design problem :
How does django in app1 would know about urls from app 2 when trying to use things like {% url %}, reverse… ? Thus can each application really render a common navbar pointing to each other ? Or do I need to keep a list of absolute urls in menu.py ?
I know this sucks, but if i go with a repository and manual update of the menu links, the job would have to be done anyway. If i go with automatic collection of submenus, this would likely not work.
If you have any tips on how to build such an interface (sticking to django here) while keeping dependancies splitted, aside my question you got me intrigued
I have a couple thoughts and questions here to try and better understand the situation.
When you’re talking about multiple independent apps, are you talking about “Apps” as Django defines the term or “Apps” as in separate and independent projects?
Other than URL references, is there any data being shared between these apps? (This would include things like user accounts.) If there is, then there is a strong case that could be made for making these as Django apps and not Django projects.
Next, I want to make sure you’re clear that the physical directory structure of how your projects exist in the file system of the server has nothing to do with its logical location within the URL structure. Do not make the mistake of thinking that there is any relationship between the two when talking about Django projects.
Specifically, when referring to a Django deployment, you do not want to deploy your Django code into a directory that Apache will serve directly. (In the example you show, it would be a grave mistake to deploy “Project 1” in /var/www/it-service-website/.)
This can only be answered after the first question above is answered. If these are Django apps, it’s trivial. If these are actually separate Django projects, it doesn’t. This is not something that Django is going to support natively. (I can think of some ways to work around this, but it’s not going to be trivial, or easy.)
I was thinking about independant projects. As in :
An application to display status of CEPH stockage (quota, filling …)
An application to request the creation of a new project => will require creating teams in LDAP/AD, attributing quota…
Potential future applications
It can be seen as django apps in the way those are somehow connected to IT system handling but that’s not eternal. They are definitly not django apps like “user management” “payment”. So it’s more like independant projects I believe, thus my inquiry for communicating between the projects and splitting the gits.
I have handled users accounts through LDAP + User model in my projects up to now. Indeed, logging for every application would be cumbersome, and making django apps looks great here.
Are my concerns of splitting repositories usefull here ? (Onboarded with a biology team that more or less built all their webservices in a single repository and it was a mess to fix.) Can’t say for sure the extent of applications that this website will host, but it’s likely to be small services like <5 page or API UI per app
Yes, I believe I’m good with this,thanks, but when coming to this part :
I’m a bit confused. Up to know the projects we host are located in /var/www/project, with apache pointing to the folder and to wsgi.py (for python, but similar architecture for PHP services)
We have something like this :
/var/www/
|— Project/
|---- | ---- Settings/wsgi.py
|---- | ---- Apps/
|---- Media
Would you explain a bit how is this a bad pattern, and is it specifically tied to django ?
Again - this is another topic that is pretty much irrelevant to all the other topics being discussed here. How you organize your projects in your repositories does not necessarily relate to how they’re being deployed.
Really BAD
Python-code deployments are not PHP deployments and should not be treated the same way. There is no need or benefit to having Apache have direct access to your python code, and potentially opens up any number of possible (or even likely) security vulnerabilities.
The last thing you want to have happen is for someone to be able to craft and submit an http request to Apache that results in Apache returning any part of your source code or configuration files. Keep your code out of any Apache root or home directory.
Apache is not running Django - In most “proper” Django deployments in Apache, Apache is running mod_wsgi in daemon mode. When Apache receives a request that is to be directed to Django, the request is forwarded as a wsgi request to that daemon. Apache itself has no part in processing that request.
