Как добавлять location в server из командной строки или генерировать конфиг динамически?

Question

[historydev]

Есть апи поддомен, хочу реализовать версионирование по типу api.domain.com/project_name/v0.0.2-4 в nginx конфиге.

Нужна возможность заменять location NAME { proxy_pass http://x.x.x.x:port; }

Будут меняться порты и url.

Как такое можно реализовать?

Для примера:

server { server_name api.domain.com; listen 80; location /project_name/v2.2.2-0 { proxy_pass http://0.0.0.0:6666; } }

Answer 1

[Сергей Соловьев]

Это можно реализовать с помощью скрипта по типу такого питонвского скрипта:

import os
import signal
import random


def get_versions_with_addresses():
    # Надо уметь получать новые версии
    return [
        ('1.0.1', '0.0.0.0:6665'),
        ('1.1.0', '0.0.0.0:2222')
    ]


def generate_config():
    config = '''
server {
    server_name api.domain.com;
    listen 80;
    '''
    for version, address in get_versions_with_addresses():
        config += f'''
    location /project_name/{version} {{
        proxy_pass http://{address}
    }}
        '''
    config += '\n}'
    return config


def notify_nginx():
    nginx_pid = ...  # Находим PID nginx
    os.kill(nginx_pid, signal.SIGHUP)


def update_config(config):
    with open('/etc/nginx/nginx.conf', 'w') as file:
        file.write(config)


def main():
    config = generate_config()
    update_config(config)
    notify_nginx()

    pass
if __name__ == '__main__':
    main()

Здесь осталось понять как находить PID nginx и как определять адреса редиректа для версий.

ИМХО: я считаю что такие вещи должны обрабатываться самим приложением, т.к.
1. Некоторые разницы в версиях должны обрабатываться на стороне приложения, например, при миграции нужно использовать новую таблицу, а создавать триггеры и поддерживать их до конца плохая затея, либо генерация событий в очередь сообщений
2. Тебе придется запускать постоянно новые процессы или держать каждый инстанс на отдельной машине, что немного ресурсоемко
3. На мой взгзляд, версионирование API должно быть по типу v1, v2, v3, а не такая гарнулярная как сематическое версионирование. Это не гит и новые версии, которые ты публикуешь надо поддерживать долго + в данном случае, список свободных адресов скоро закончится
4. Тебе придется поддерживать дополнительную инфраструктуру по отслеживанию новых версий приложения