Ollama DeProxy або як отримати локальний доступ до віддаленої Ollama

Ollama DeProxy

Я маю віддалений сервер із GPU, на якому запущена Ollama.

Водночас середовище розробки зазвичай очікує, що Ollama доступна локально - наприклад, за адресою http://localhost:11434 або в межах локальної мережі (http://192.168.0.111:11434).

Класичні рішення

Найпростіший варіант — SSH-тунель:

ssh remote@server -L 11434:localhost:11434

Після цього локальний localhost:11434 проксуватиметься на віддалений сервер.

Якщо ж розробників декілька і вони працюють з різних офісів або через інтернет — можна використати VPN. Це теж робоче рішення, але воно потребує додаткової інфраструктури та адміністрування.

Проблема з авторизацією

У моєму випадку Ollama використовується разом із OpenWebUI, який проксіює доступ до Ollama через власний API з токен-авторизацією.

Однак більшість застосунків, що інтегруються з Ollama, очікують простий доступ до http://localhost:11434 без жодної авторизації. Через це вони не можуть напряму працювати через OpenWebUI.

Рішення — Ollama DeProxy

Щоб спростити інтеграцію, я написав невеликий застосунок - Ollama DeProxy.

Windows Docker. Virtual image file just only grow size of .vhds file.

Куди зникає місце на диску?

Docker у Windows працює через WSL (Windows Subsystem for Linux), яка в свою чергу використовує віртуалізацію Hyper‑V. Це означає, що всі дані зберігаються у файлах образів віртуальних дисків .vhdx.

З часом диск починає стрімко розростатися, і рано чи пізно місце на системному SSD закінчується. Тоді виникає питання: куди ж воно поділося?

На допомогу приходить утиліта WinTree (diskanalyzer.com), яка дозволяє швидко побачити, що саме займає простір.

Саме так я й з’ясував, що проблема була у Docker. Але коли перевірив сам Docker - там усе вже очищено, а файл .vhdx продовжував залишатися гігантським.

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          2         2         329.2MB   0B (0%)
Containers      3         0         2B        2B (100%)
Local Volumes   62        1         2.309GB   2.125GB (92%)
Build Cache     0         0         0B

Чому VHDX росте безконтрольно.

Реальний розмір віртуального тому завжди більший за фактичні дані. Це відбувається тому, що .vhdx‑файл у WSL та Docker може лише збільшуватися у міру потреби. 

Коли ти видаляєш образи чи очищаєш дані, простір всередині Linux‑файлової системи звільняється, але сам файл на диску не стискається автоматично. 

Тому він продовжує залишатися гігантським, навіть якщо даних там майже немає. 

Docker .vhdx before compact

Стискаємо образ диску 

Виходимо з застосунку "Docker Desktop" та робимо завершення "WSL":

wsl --shutdown

Стискаємо VHD файл відкриваючи консоль PowerShell як Administrator.

Optimize-VHD -Path "$env:LOCALAPPDATA\Docker\wsl\disk\docker_data.vhdx" -Mode Full

Тепер набагато краще.

Docker .vhdx after compact

 

pfSense + HAProxy + ACME: HTTP-01 validation without using port 80

Вступ

У багатьох інсталяціях pfSense використовується не лише як firewall, а і як точка термінації HTTPS для внутрішніх вебсервісів. Типовий стек виглядає так:

• pfSense - firewall та reverse-proxy
• HAProxy - маршрутизація HTTP/HTTPS трафіку
• ACME (Let’s Encrypt) - автоматична генерація HTTPS сертифікатів
• Внутрішні вебсервери - працюють по HTTP у локальній мережі
  

У цій публікації як розгляну як коректно пройти ACME HTTP-01 валідацію, коли порт 80 вже зайнятий HAProxy, без зупинки сервісів і без DNS-01.

Docker Port Is Busy on Windows? Fix for: bind: An attempt was made to access a socket in a way forbidden by its access permission.

If you're getting a Docker error like:

(HTTP code 500) server error - ports are not available: exposing port TCP 0.0.0.0:8182 -> 127.0.0.1:0: listen tcp 0.0.0.0:8182: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

But nothing is using the port, it’s likely because Windows has excluded the port dynamically, especially after Docker was previously using it. 

 

(HTTP code 500) server error - ports are not available

1. Verify Nothing Is Listening on the Port

netstat -aon | findstr :8181

If you see no output, the port is not in use by any application.

2. Check Excluded Port Ranges:

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      6575        6674
      7162        7261
      7262        7361
      7362        7461
      7462        7561
      7562        7661
      7681        7780
      7781        7880
      7881        7980
      7981        8080
      8081        8180
      8181        8280
      8281        8380
      8381        8480
      8481        8580
     30604       30703
     49690       49789
     49790       49889
     49890       49989
     50000       50059     *
     50160       50259
     50360       50459
     50460       50559
     50660       50759
     50760       50859
     50860       50959
     51064       51163
     51243       51342
     51344       51443

You’ll notice 8182 falls within the 8181–8280 range - without a * at the end, meaning it's a dynamically excluded port.

You cannot remove dynamic exclusions manually.

3. Restart winnat Service to Clear Dynamic Exclusions: 

This step clears dynamic port reservations created by services like Docker: 

net stop winnat
net start winnat

* Run the above in Administrator Command Prompt 

 

4. Recheck Excluded Ports:

netsh int ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
     50000       50059     *

* - Administered port exclusions.

If 8182 is no longer in the list, you're good to go.

🚀 Docker-Compose Generator for ElasticSearch Cluster

Are you tired of manually configuring docker-compose.yml files for Elasticsearch clusters? Say hello to this easy-to-use Python script that automates the process! 🐍

📌 What it does:

This script generates a docker-compose.yml file for setting up an ElasticSearch cluster using template files and environment variables. It creates a cluster with Docker containers, including:

• ElasticSearch nodes with different roles (master, data, ingest, coordinator)
• Kibana for visualization
• Additional service containers

🔧 How it works:

• Configure your cluster setup using a .env file.
• Run the script, and voilà! Your docker-compose.yml is ready.

📶 Test Environment:

The generated cluster was tested on a TrueNAS SCALE 24.10.2 server, deployed as a custom application by importing the YAML file. Storage was configured using ZFS Datasets, ensuring reliability and scalability.

💡 Why it’s awesome:

• Saves time and reduces errors in manual configuration.
• Flexible and customizable for different cluster setups.
• Perfect for DevOps engineers and developers working with ElasticSearch.

🔗 Script: https://github.com/lexxai/es_cluster_docker_helper
🔗 Prototype: https://github.com/evermight/elastic-cluster-docker-compose

Google Learning path: "Machine Learning Engineer Learning Path" - Completed

Нарешті в останній день дії кредитів на навчання отримав сертифікат "Responsible AI for Developers: Privacy & Safety" від Google, чим і завершив довгий, з вересня 2023, Google Learning path: "Machine Learning Engineer Learning Path".

 

Responsible AI for Developers: Privacy & Safety

Progress "Machine Learning Engineer Learning Path"

 

 

Machine Learning Engineer Learning Path

Machine Learning Engineer Learning Path

A Machine Learning Engineer designs, builds, productionizes, optimizes, operates, and maintains ML systems.

21 activities 

A Machine Learning Engineer designs, builds, productionizes, optimizes, operates, and maintains ML systems. This learning path guides you through a curated collection of on-demand courses, labs, and skill badges that provide you with real-world, hands-on experience using Google Cloud technologies essential to the ML Engineer role. Once you complete the path, check out the Google Cloud Machine Learning Engineer certification to take the next steps in your professional journey.

Proxmox VE, firewall, nf_conntrack_max, nf_conntrack_count

Є Hypervisor, Proxmox VE з ввімкненим firewall на рівні Proxmox, через те, що запущені VM з Proxy сервером "Squid", і бажано обмежити доступ до потенційного доступу до локальної мережі.

Але за великої кількості підключень спрацьовують  обмеження на кількість одночасних сесій підключень.

Proxmos VE, Shell, dmesg

Для стандартних рішень з Ubuntu є змінна файлу з додавань певних рядків у  /etc/sysctl.conf, але усі значення перевизначаються і бачимо постійно значення за замовчуванням.

Not help, /etc/sysctl.conf

Але знайшов давній пост де є пропозиція використати налаштування GUI Proxmox. І це допомогло.

Proxmox VE, GUI, Node, Firewall. Options. nf_conntrack_max

Моніторинг значень - nf_conntrack_count: "watch -n 1 "cat /proc/sys/net/netfilter/nf_conntrack_count"

watch -n 1 "cat /proc/sys/net/netfilter/nf_conntrack_count"

 

Нотатка. Python. functools.partial.

🔨 functools.partial(func, /, *args, **keywords)

functools.partial

📍 Повертає новий частковий об’єкт, який під час виклику поводитиметься як func, що викликається з позиційними аргументами args і ключовими аргументами keywords. Якщо до виклику надається більше аргументів, вони додаються до args. Якщо надаються додаткові ключові аргументи, вони розширюють і замінюють ключові слова.

📌 Примітка. Більшість функцій планування asyncio не дозволяють передавати ключові аргументи. Для цього скористайтеся functools.partial():

# will schedule "print("Hello", flush=True)"
loop.call_soon(
   functools.partial(print, "Hello", flush=True)
   )

🎧 Використання часткових об’єктів зазвичай зручніше, ніж використання лямбда-виразів, оскільки asyncio може краще відтворювати часткові об’єкти в повідомленнях про налагодження та помилки.

# лямбда-вираз
loop.call_soon(
   lambda : print("Hello")
   )

Як завершити async-завдання, створене з функції що блокує через asyncio.to_thread(): експеримент та рішення.

Маленький експеримент як завершити async task якщо вона була створена з функції що блокує.

Тобто створена з не асинхронної функції (proc2) за допомогою asyncio.to_thread().

Як видно з результатів без використання threading.Event(), програма буде постійно працювати навіть після закінчення всіх асинхронних функцій в async loop, тому що окремий потік породжений у цій програмі ще не завершився й async loop буде чекати на нього.