Blogger to GitHub Pages Sync Tool (blog2ghp)

Навіщо?

Я вирішив отримати практичний досвід роботи з GitHub Actions та GitHub Pages.

Мій блог має RSS-стрічку, і це дало ідею: якщо автоматично обробляти RSS-сторінки, можна отримати повну резервну копію блогу у форматі Markdown.

А вже цей Markdown легко опублікувати в репозиторії GitHub Pages / Jekyll.

Таким чином я отримую:

• автоматичний бек-ап контенту
• контроль над контентом у Git
• можливість міграції з Blogger без втрат
• статичну версію блогу

Приклад використання

Блоґ котрий копіюється

Результат копіювання на GitHub pages

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