Week 10 / 2023

Mohamed Saif published on
5 min, 915 words

Tags: rust postgresql nginx multi-tenancy python

EnabledCloud

Multi-tenancy

  • multi-tenant app
  • The idea of multitenancy is to give each customer (tenant) the illusion of their own separate workspace, while using the same backend and resources. Real world examples for this are Slack and Notion.
  • Django-Tenants will manage (in Postgresql Speak) the search path based on the URL one has made the request.
  • ..a combination of (ORM?) features (SQLAlchemy?) and Routing & Requesting capabilities (FastAPI)
  • ..to retrieve the tenant via the header
  • frappe bench multi-tenancy
  • fastapi discussion about multi-tenancy

Python

PostgreSQL

  • In PostgreSQL, a schema is a namespace that contains named database objects such as tables, views, indexes, data types, functions, stored procedures and operators.
  • In PostgreSQL, a database can contain one or multiple schemas and each schema belongs to only one database.
  • Schemas enable multiple users to use one database without interfering with each other.
  • PostgreSQL automatically creates a schema called public for every new database.
  • schema search path, is a list of schemas that PostgreSQL will search for objects. show search_path;
  • The first schema in the search path is called the current schema, select current_schema();.
  • CREATE SCHEMA creates a new schema in the current database. SET search_path TO schema_name, public; sets the current schema to the specified schema.
  • Users can only access objects in the schemas that they own.
  • The system determines which table is meant by following a search path, which is a list of schemas to look in. The first matching table in the search path is taken to be the one wanted. If there is no match in the search path, an error is reported, even if matching table names exist in other schemas in the database.
  • Therefore, in the default configuration, any unqualified access again can only refer to the public schema.

Nginx

  • docker run --name tfd-nginx -p 81:80 --hostname ng1 -d nginx:latest, this will run the nginx container in the background and map the container port 80 to the host port 81. Access the Nginx server by visiting http://localhost:81 or get Getaway ip from docker inspect tfd-nginx and visit http://<ip>:81
  • when you create or run a container using docker create or docker run, the container doesn’t expose any of its ports to the outside world. To make a port available to services outside of Docker, or to Docker containers running on a different network, use the --publish or -p flag.
  • chmod 644 index.html to make the file readable by everyone.
  • docker run --name tfd-nginx -p 81:80 --hostname ng1 -v /home/username/nginx:/usr/share/nginx/html -d nginx:latest to mount the local directory /home/username/nginx to the container directory /usr/share/nginx/html.
  • The reason you are seeing the error message "This site can’t be reached" when trying to access the FastAPI server from the host's browser is because you're trying to access it using the IP address 0.0.0.0, which is not a valid IP address for external communication.
  • In the Dockerfile, you have set the uvicorn server to bind to 0.0.0.0, which means it will listen on all available network interfaces. However, you should bind it to 0.0.0.0 only inside the container, and use the IP address of the container or localhost to access the server from the host's browser.
  • CMD ["uvicorn", "main:app", "--reload", "--host", "0.0.0.0", "--port", "8008"]
  • nginx has one master process and several worker processes. The main purpose of the master process is to read and evaluate configuration, and maintain worker processes.
  • Worker processes do actual processing of requests.
  • nginx employs event-based model and OS-dependent mechanisms to efficiently distribute requests among worker processes.
  • A signal may also be sent to nginx processes with the help of Unix tools such as the kill utility. In this case a signal is sent directly to a process with a given process ID. The process ID of the nginx master process is written, by default, to the nginx.pid in the directory /usr/local/nginx/logs or /var/run.
  • ps -aux | grep nginx to find the process ID of the nginx master process. -a to show processes for all users, -u to show processes for a specific user, -x to show processes not attached to a terminal.
  • nginx consists of modules which are controlled by directives specified in the configuration file.
  • Directives are divided into simple directives and block directives.
  • simple directive syntax: directive parameters;
  • block directive syntax: directive { ... }
  • context is a set of directives that can appear in a configuration file. context syntax: context { ... } like events { ... }, http { ... }, server { ... }, location { ... }
  • Generally, the configuration file may include several server blocks distinguished by ports on which they listen to and by server names. for example, server { listen 80; server_name example.com; ... }.