Forwarded from Machinelearning
Media is too big
VIEW IN TELEGRAM
Y Combinator сделал ставку на ИИ-агентов, способных переосмыслить целые индустрии. Вместо точечных решений, основателям советуют создавать «полноценные ИИ-компании» - например, запускать собственные юридические бюро с ИИ-юристами вместо сотрудников. Такой подход позволяет обойти медлительных конкурентов, предлагая клиентам более дешевые и эффективные сервисы.
Особый интерес к автоматизации рутины: персональные ассистенты, которые не просто напоминают о задачах, а самостоятельно отвечают на письма, планируют встречи и имитируют стиль общения пользователя. Y Combinator верит: будущее за командами, которые не просто внедряют ИИ, а перестраивают рынки с нуля, как это сделали Airbnb или Stripe.
ycombinator.com
Ученые из Центра геномной регуляции в Барселоне впервые применили генеративный ИИ для проектирования синтетических молекул ДНК, способных управлять активностью генов в здоровых клетках млекопитающих. Модель, обученная на данных тысяч экспериментов, генерирует последовательности «с нуля», задавая критерии.
В качестве теста создали фрагменты ДНК, активирующие ген флуоресцентного белка в клетках крови мышей. Результаты совпали с прогнозами: синтетические усилители генной активности работали как «переключатели» в зависимости от типа клеток. Исследование открывает путь к персонализированным методам коррекции генов. По словам авторов, это похоже на «написание софта для биологии», где каждая инструкция для клетки становится программируемой.
technologynetworks.com
OpenAI представила HealthBench - бенчмарк для тестирования ИИ-систем в сфере здравоохранения. Разработанный при участии 262 врачей из 60 стран, он включает 5000 реалистичных диалогов, имитирующих общение пациентов и медиков. Каждый сценарий оценивается по индивидуальным критериям, созданным экспертами: точность данных или ясность ответов.
Всего в бенчмарке 48 562 параметра оценки, что позволяет глубоко анализировать работу моделей. Особый упор сделан на надежность: даже один ошибочный ответ в медицине критичен. HealthBench включает подборки сложных кейсов (HealthBench Hard), где современные ИИ еще отстают. Все данные и методики уже доступны в GitHub-репозитории OpenAI .
openai.com
Google анонсировала AI Futures Fund — программу для поддержки ИИ-стартапов. Участники получат ранний доступ к моделям DeepMind (Gemini, Imagen и Veo). Кроме технологий, стартапы смогут консультироваться с инженерами и исследователями Google, а также получат облачные кредиты для обучения и масштабирования решений. Уже сейчас с фондом работают проекты из разных сфер: индийский Toonsutra внедряет Gemini для перевода комиксов, Viggle экспериментирует с генерацией мемов, а платформа Rooms тестирует интерактивные 3D-пространства.
Программа открыта для стартапов из регионов, где доступен Gemini. Подать заявку можно на сайте фонда. Участники смогут претендовать не только на технические ресурсы, но и на прямые инвестиции от Google.
blog.google
Злоумышленники активно используют популяризацию ИИ для распространения вредоносного стиллера Noodlophile, маскируя атаки под сервисы для генерации видео и изображений. Как сообщает Morphisec, фейковые страницы Luma Dreammachine Al и CapCut AI рекламируются через соцсети, собирая до 62 000 просмотров на пост. Пользователям предлагают скачать «ИИ-софт», но вместо этого загружается ZIP-архив с исполняемым exe-файлом.
Запуск файла активирует легитимный CapCut.exe, который загружает .NET-лоадер CapCutLoader. Тот, в свою очередь, запускает Python-скрипт, устанавливающий Noodlophile Stealer. Вредонос крадет пароли, данные кошельков и другую информацию, а в некоторых случаях дополняется трояном XWorm для удаленного доступа. Эксперты напоминают: атаки через ИИ-технологии стали трендом. Осторожность — лучшая защита.
thehackernews.com
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1🔥1
Media is too big
VIEW IN TELEGRAM
📜 История SQL — от лабораторной идеи до «языка данных» № 1
Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.
1. Всё началось с таблицы на бумаге
- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.
2. SEQUEL — «английский» запрос к таблицам
- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.
3. Почему SEQUEL стал SQL
- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*
4. Коммерческий взлёт
- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке
5. Стандартизация и эволюция
- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.
6. Забавные факты, которые украсят small talk 🍸
1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый
7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным.
7. Почему SQL живёт дольше модных NoSQL‑наследников
- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер
Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в
https://www.youtube.com/shorts/EuFjzuVHkHE
Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.
1. Всё началось с таблицы на бумаге
- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.
2. SEQUEL — «английский» запрос к таблицам
- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:
SELECT name, salary
FROM employees
WHERE dept = 'R&D';
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.
3. Почему SEQUEL стал SQL
- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*
4. Коммерческий взлёт
- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке
5. Стандартизация и эволюция
- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.
6. Забавные факты, которые украсят small talk 🍸
1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый
SELECT превращается в процедурный план. 7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным.
7. Почему SQL живёт дольше модных NoSQL‑наследников
- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер
SELECT ….Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в
FROM.https://www.youtube.com/shorts/EuFjzuVHkHE
👍12❤2
⚡️ Kubernetes устраняет проблему безопасности с приватными образами, которую не решали более 10 лет
Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа.
Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск.
Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения.
https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/
Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа.
Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск.
Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения.
https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/
👍17🔥3❤2
🧠 DevOps-задача: "Контейнер Шрёдингера"
Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но
Что известно:
- Docker-контейнер на основе
- Приложение запускается через
- Порт 8080 проброшен (`-p 8080:8080`)
-
-
-
Задача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.
📌 Разбор:
🕵️ Подвох №1: **приложение слушает127.0.0.1:8080 **, а не 0.0.0.0
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host
Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим ` 127.0.0.1:8080 ` — всё ясно: нужно слушать на ` 0.0.0.0:8080 `
🛠 Исправление:
1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3 app.py
```
и он слушает только на localhost? Добавь:
```bash
python3app.py --host= 0.0.0.0
```
2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на127.0.0.1
Проверь в настройках приложения или командной строке
🎯 Что проверяет задача:
• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но
docker exec показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа."Что известно:
- Docker-контейнер на основе
alpine:3.18- Приложение запускается через
CMD ["/bin/service-start"]- Порт 8080 проброшен (`-p 8080:8080`)
-
curl localhost:8080 внутри контейнера возвращает 200 OK-
curl localhost:8080 на хосте — зависает-
netstat -tulpn показывает, что порт 8080 прослушивается внутриЗадача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.
📌 Разбор:
🕵️ Подвох №1: **приложение слушает
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host
Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим `
🛠 Исправление:
1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3
```
и он слушает только на localhost? Добавь:
```bash
python3
```
2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на
Проверь в настройках приложения или командной строке
🎯 Что проверяет задача:
• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
🔥16👍7❤4👎2👏2🌚2
🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо.
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
👍6🔥5❤2
🌐 Задача-ловушка: Пропавший трафик после настройки iptables
Условие:
На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:
После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.
На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:
❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете
Дополнительно, если выполнить:
— сервер отвечает нормально. Но с других машин — нет.
❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?
🔍 Подсказка:
Docker использует nat таблицы и
✅ Разбор:
💥 Ловушка:
Ваш iptables-правила:
запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через
Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:
- Входящий пакет попадает в цепочку
- Потом через
И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:
Поэтому трафик до контейнера блокируется именно на этапе FORWARD.
🔧 Как проверить:
Запустить:
Вы увидите, что счётчик пакетов в
🛠 Как починить:
Добавить правило разрешения проброса пакетов для Docker:
Или (более строго):
✅ Вывод:
• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)
• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через
💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом
Условие:
На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.
На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:
docker run -d -p 8080:80 nginx
❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете
Connection refused. Но в ss -tlnp порт 8080 виден и слушает.Дополнительно, если выполнить:
curl http://localhost:8080
— сервер отвечает нормально. Но с других машин — нет.
❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?
🔍 Подсказка:
Docker использует nat таблицы и
PREROUTING`/`FORWARD цепочки для проброса портов.✅ Разбор:
💥 Ловушка:
Ваш iptables-правила:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через
INPUT, но это не так!Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:
- Входящий пакет попадает в цепочку
PREROUTING (nat) - Потом через
FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнераИ тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:
iptables -P FORWARD DROP
Поэтому трафик до контейнера блокируется именно на этапе FORWARD.
🔧 Как проверить:
Запустить:
iptables -L -v -n
Вы увидите, что счётчик пакетов в
FORWARD показывает дропы.🛠 Как починить:
Добавить правило разрешения проброса пакетов для Docker:
iptables -A FORWARD -o docker0 -j ACCEPT
Или (более строго):
iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT
✅ Вывод:
• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)
• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через
FORWARD, а не напрямую через INPUT.💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом
--network=host? Какие цепочки будут задействованы тогда?👍24❤7✍2🗿2👎1🔥1
🛠️ Отправка уведомлений Slack из shell-скриптов
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.
Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.
Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.
> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.
🔗 Webhook + curl: секретная связка
Slack позволяет использовать входящие Webhook-и для получения сообщений.
А
Принцип:
- Slack даёт вам URL вида
- Вы используете
⚙️ Как включить входящие Webhook в Slack
1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее
💬 Bash-скрипт для отправки уведомлений
Добавьте Webhook в
✅ Рекомендации
Не хардкодьте токены — используйте переменные окружения
Slack ограничивает частоту Webhook-запросов
Используйте уведомления только при необходимости (ошибки, алерты и т.п.)
Теперь вы можете:
- Добавить Slack-уведомления в свои cron-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.
Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.
Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.
> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.
🔗 Webhook + curl: секретная связка
Slack позволяет использовать входящие Webhook-и для получения сообщений.
А
curl позволяет отправлять эти сообщения через HTTP POST.Принцип:
- Slack даёт вам URL вида
https://hooks.slack.com/services/...- Вы используете
curl для отправки JSON с текстом сообщения.⚙️ Как включить входящие Webhook в Slack
1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее
💬 Bash-скрипт для отправки уведомлений
Добавьте Webhook в
.bashrc:
export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url"
Пример скрипта мониторинга:
#!/bin/bash
source ~/notify_slack.sh
disk_usage=$(df -h / | awk 'NR==2 {print $5}')
cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs)
hostname=$(hostname)
message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load"
notify_slack "$message"
✅ Рекомендации
Не хардкодьте токены — используйте переменные окружения
Slack ограничивает частоту Webhook-запросов
Используйте уведомления только при необходимости (ошибки, алерты и т.п.)
Теперь вы можете:
- Добавить Slack-уведомления в свои cron-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее
👍9🔥4❤2👎1
Forwarded from Machinelearning
🚀 VS Code трансформируется в опенсорнсый ИИ-редактор!
Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ.
Конкуренция - двигатели прогресса!Где-то напряглась команда Cursor 🤓
🔗 Подробности: aka.ms/open-source-ai-editor
#VSCode #OpenSource #ИИ #Разработка #Сообщество
Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ.
Конкуренция - двигатели прогресса!
🔗 Подробности: aka.ms/open-source-ai-editor
#VSCode #OpenSource #ИИ #Разработка #Сообщество
👍11👎6❤2🔥2🤔2
🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google
Контейнер — это не просто
⚫ Ограничь права контейнера
▪️
▪️
▪️
⚫ Установи лимиты CPU и памяти
▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах
▪️ Используй
⚫ Чисти от мусора
- Используй multi-stage builds — минимизируй размер образа
- Оставляй только необходимые бинарники и конфиги
- Пример:
⚫ Используй distroless или Alpine
- Образы типа
-
⚫ Пропиши healthcheck
▪️ Kubernetes будет перезапускать только при реальных сбоях
⚫ Подключи observability
- Встраивай Prometheus exporter
- Логи — в stdout/stderr (для
- Используй
⚫ Проверь, чем занят контейнер
▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через
💡 Эти практики критичны, если:
- Вы деплоите в прод с autoscaling
- Контейнеры крутятся в k8s или Fargate
- Вам важно сократить издержки на ресурсы и повысить безопасность
Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.
@devopsitsec
Контейнер — это не просто
Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров:⚫ Ограничь права контейнера
docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...
▪️
--read-only — защищает файловую систему ▪️
--cap-drop=ALL — удаляет лишние привилегии ▪️
no-new-privileges — запрещает повышение прав в процессе⚫ Установи лимиты CPU и памяти
docker run --memory="512m" --cpus="1.5" ...
▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах
▪️ Используй
cpu-shares, cpuset, ulimits для тонкой настройки⚫ Чисти от мусора
- Используй multi-stage builds — минимизируй размер образа
- Оставляй только необходимые бинарники и конфиги
- Пример:
FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app
FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]
⚫ Используй distroless или Alpine
- Образы типа
gcr.io/distroless/static — без шелла, package manager и мусора -
alpine — легче, но следи за совместимостью с glibc⚫ Пропиши healthcheck
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1
▪️ Kubernetes будет перезапускать только при реальных сбоях
⚫ Подключи observability
- Встраивай Prometheus exporter
- Логи — в stdout/stderr (для
kubectl logs и EFK/PLG стека) - Используй
otel, если нужен tracing⚫ Проверь, чем занят контейнер
docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>
▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через
/dev💡 Эти практики критичны, если:
- Вы деплоите в прод с autoscaling
- Контейнеры крутятся в k8s или Fargate
- Вам важно сократить издержки на ресурсы и повысить безопасность
Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.
@devopsitsec
👍20🔥6❤2
⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу.
Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.
🤖 GitHub
@devopsitsec
Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.
🤖 GitHub
@devopsitsec
👍13❤2🔥1
Шпаргалка_по_командам_Linux_для_среднего_и_продвинутого_уровня_1.pdf
149.2 KB
Сохраняйте себе, чтобы не потерять
📌 Полная версия онлайн
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍6❤1🤩1
🏰 SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа.
Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами.
🤖 GitHub
@devopsitsec
Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами.
🤖 GitHub
@devopsitsec
❤13🤔5👍1🔥1
🧠 Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с
💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus.
Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова.
🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ.
📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления.
🔍 Что можно вынести:
• Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть
• Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение
• Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке
📎 Оригинальный пост на Reddit
@devopsitsec
💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus.
Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова.
🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ.
📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления.
🔍 Что можно вынести:
• Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть
• Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение
• Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке
📎 Оригинальный пост на Reddit
@devopsitsec
🔥16❤5👍5😁3🤔2🥴2😴1
🌒 LunaTrace — бесплатный open-source инструмент для аудита безопасности зависимостей. Он автоматически сканирует зависимости в проектах, выявляет уязвимости и интегрируется с GitHub Pull Requests, чтобы предупреждать о рисках до деплоя.
Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем.
🤖 GitHub
@devsecops
Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем.
🤖 GitHub
@devsecops
👍5❤2🔥2
🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю.
🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами
🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое
🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда
📎 GitHub: https://github.com/GoogleCloudPlatform/khi
@devopsitsec
🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами
🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое
🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда
📎 GitHub: https://github.com/GoogleCloudPlatform/khi
@devopsitsec
👍17🔥4❤3
⚡️ Composerize — мгновенное преобразование docker run в docker-compose. Composerize решает проблему нечитаемых строк с десятками флагов одним движением — конвертирует запуск контейнера через CLI в аккуратный
Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.
🤖 GitHub
@DevopsDocker
compose.yaml. Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.
🤖 GitHub
@DevopsDocker
👍11
🗄 YTsaurus теперь как сервис в Yandex Cloud
Платформа для распределенной обработки и хранения данных, которую раньше использовали внутри Яндекса, теперь доступна внешним командам.
Поддерживает работу с эксабайтами, масштабируется до миллиона CPU, работает с ClickHouse, Spark, MapReduce. Можно строить пайплайны, гонять аналитику, собирать хранилища и обрабатывать логи - всё в одной системе.
Стриминговые, структурированные и неструктурированные данные - поддержка на уровне ядра. Подходит как для тяжёлых ML-задач, так и для типовых ETL-процессов.
Инфраструктура управляется как сервис - без ручного развертывания и поддержки.
@devopsitsec
Платформа для распределенной обработки и хранения данных, которую раньше использовали внутри Яндекса, теперь доступна внешним командам.
Поддерживает работу с эксабайтами, масштабируется до миллиона CPU, работает с ClickHouse, Spark, MapReduce. Можно строить пайплайны, гонять аналитику, собирать хранилища и обрабатывать логи - всё в одной системе.
Стриминговые, структурированные и неструктурированные данные - поддержка на уровне ядра. Подходит как для тяжёлых ML-задач, так и для типовых ETL-процессов.
Инфраструктура управляется как сервис - без ручного развертывания и поддержки.
@devopsitsec
❤5👍2
Media is too big
VIEW IN TELEGRAM
☸ История создания Kubernetes — от внутреннего инструмента Google до мировой революции
Когда в 2014 году Google выложил в открытый доступ свой внутренний проект под странным именем Kubernetes, мало кто осознал, что это начало настоящей контейнерной революции. Но за этой лаконичной оболочкой скрывалась мощь, проверенная на миллиардах пользователей Google Search, Gmail и YouTube.
🔥 Всё началось с Borg
Внутри Google уже с 2003 года существовала система управления контейнерами — Borg. Это был секретный, монструозный и невероятно мощный оркестратор, позволявший запускать сотни тысяч задач на десятках тысяч серверов. Но Borg был закрыт, сложный и не предназначен для внешнего мира.
💡 Факт: Borg умел автоматически лечить упавшие сервисы задолго до того, как "self-healing" стал модным словом в DevOps.
🚀 Почему Kubernetes?
Google хотел подарить миру упрощённую, но эффективную версию Borg — с понятным API, без проприетарных завязок и... с хорошим маркетингом. Так родился Kubernetes — проект с открытым исходным кодом, построенный на Go, и вдохновлённый Borg и его экспериментальным "младшим братом" — Omega.
🔷 Факт: Название "Kubernetes" пришло из греческого языка и означает "штурман". Это намёк: Kubernetes управляет "флотом" контейнеров как кораблями.
👨💻 Кто стоял у истоков?
Изначально за Kubernetes отвечали три инженера Google:
Joe Beda
Brendan Burns
Craig McLuckie
Позже к ним присоединился Brian Grant, архитектор Borg, и вскоре десятки инженеров со всего мира стали развивать проект под крылом Cloud Native Computing Foundation (CNCF).
🧨 Факт: Kubernetes стал самым активным проектом на GitHub в 2015 году — больше коммитов, чем у Linux!
🌐 Как Kubernetes завоевал мир?
🔄 Контейнеры стали стандартом благодаря Docker, но их нужно было как-то управлять — и тут вошёл Kubernetes.
🎯 Kubernetes оказался универсальным: он мог запускаться на ноутбуке, в дата-центре, в облаке, даже на Raspberry Pi.
💥 Все большие игроки — AWS, Azure, IBM, Red Hat — вынуждены были поддержать Kubernetes, иначе рисковали остаться вне игры.
📦 Экосистема вокруг Kubernetes выросла в десятки раз: Helm, Istio, Prometheus, ArgoCD, Knative — всё это родилось в его тени.
🛡 Факт: Kubernetes — это не просто оркестратор. Это операционная система для облака. Она изменила сам подход к разработке: теперь приложения проектируются "cloud-native", а не "серверные".
⚙️ Kubernetes сегодня
Сейчас Kubernetes:
Работает в каждом втором крупном enterprise-проекте
Поддерживается всеми облачными провайдерами
Является де-факто стандартом для микросервисной архитектуры
Вдохновил создание K8s-альтернатив: Nomad, OpenShift, K3s, и других
💡 Вывод
Kubernetes — это не просто проект, это движение, начатое с утечки идей из недр Google и переросшее в открытую революцию управления инфраструктурой. Как Git изменил подход к коду, так Kubernetes изменил подход к запуску программ. Сегодня без Kubernetes — ни один серьёзный DevOps не чувствует себя в безопасности.
Хочешь больше таких историй из мира технологий? 😉
https://www.youtube.com/shorts/CNVdG6LS9kE
Когда в 2014 году Google выложил в открытый доступ свой внутренний проект под странным именем Kubernetes, мало кто осознал, что это начало настоящей контейнерной революции. Но за этой лаконичной оболочкой скрывалась мощь, проверенная на миллиардах пользователей Google Search, Gmail и YouTube.
🔥 Всё началось с Borg
Внутри Google уже с 2003 года существовала система управления контейнерами — Borg. Это был секретный, монструозный и невероятно мощный оркестратор, позволявший запускать сотни тысяч задач на десятках тысяч серверов. Но Borg был закрыт, сложный и не предназначен для внешнего мира.
💡 Факт: Borg умел автоматически лечить упавшие сервисы задолго до того, как "self-healing" стал модным словом в DevOps.
🚀 Почему Kubernetes?
Google хотел подарить миру упрощённую, но эффективную версию Borg — с понятным API, без проприетарных завязок и... с хорошим маркетингом. Так родился Kubernetes — проект с открытым исходным кодом, построенный на Go, и вдохновлённый Borg и его экспериментальным "младшим братом" — Omega.
🔷 Факт: Название "Kubernetes" пришло из греческого языка и означает "штурман". Это намёк: Kubernetes управляет "флотом" контейнеров как кораблями.
👨💻 Кто стоял у истоков?
Изначально за Kubernetes отвечали три инженера Google:
Joe Beda
Brendan Burns
Craig McLuckie
Позже к ним присоединился Brian Grant, архитектор Borg, и вскоре десятки инженеров со всего мира стали развивать проект под крылом Cloud Native Computing Foundation (CNCF).
🧨 Факт: Kubernetes стал самым активным проектом на GitHub в 2015 году — больше коммитов, чем у Linux!
🌐 Как Kubernetes завоевал мир?
🔄 Контейнеры стали стандартом благодаря Docker, но их нужно было как-то управлять — и тут вошёл Kubernetes.
🎯 Kubernetes оказался универсальным: он мог запускаться на ноутбуке, в дата-центре, в облаке, даже на Raspberry Pi.
💥 Все большие игроки — AWS, Azure, IBM, Red Hat — вынуждены были поддержать Kubernetes, иначе рисковали остаться вне игры.
📦 Экосистема вокруг Kubernetes выросла в десятки раз: Helm, Istio, Prometheus, ArgoCD, Knative — всё это родилось в его тени.
🛡 Факт: Kubernetes — это не просто оркестратор. Это операционная система для облака. Она изменила сам подход к разработке: теперь приложения проектируются "cloud-native", а не "серверные".
⚙️ Kubernetes сегодня
Сейчас Kubernetes:
Работает в каждом втором крупном enterprise-проекте
Поддерживается всеми облачными провайдерами
Является де-факто стандартом для микросервисной архитектуры
Вдохновил создание K8s-альтернатив: Nomad, OpenShift, K3s, и других
💡 Вывод
Kubernetes — это не просто проект, это движение, начатое с утечки идей из недр Google и переросшее в открытую революцию управления инфраструктурой. Как Git изменил подход к коду, так Kubernetes изменил подход к запуску программ. Сегодня без Kubernetes — ни один серьёзный DevOps не чувствует себя в безопасности.
Хочешь больше таких историй из мира технологий? 😉
https://www.youtube.com/shorts/CNVdG6LS9kE
🔥15👍2❤1👎1
🌟 Selenium Docker Images — готовые контейнеры для автотестов
Для тех, кто устал настраивать Selenium Grid вручную, сообщество Selenium выкатило официальные Docker-образы. В одном контейнере уже собраны браузеры (Chrome, Firefox, Edge), VNC для отладки и сам Selenium Server — остаётся только запустить тесты.
Инструмент особенно удобен для CI/CD:
— Поддержка multi-arch (amd64, arm64)
— Готовые теги для beta-версий браузеров
— Встроенная запись видео тестов
Запуск элементарный:
🤖 GitHub
@DevopsDocker
Для тех, кто устал настраивать Selenium Grid вручную, сообщество Selenium выкатило официальные Docker-образы. В одном контейнере уже собраны браузеры (Chrome, Firefox, Edge), VNC для отладки и сам Selenium Server — остаётся только запустить тесты.
Инструмент особенно удобен для CI/CD:
— Поддержка multi-arch (amd64, arm64)
— Готовые теги для beta-версий браузеров
— Встроенная запись видео тестов
Запуск элементарный:
docker run -d -p 4444:4444 --shm-size=2g selenium/standalone-chrome
🤖 GitHub
@DevopsDocker
👍5🔥3❤2👏1
🚀 go-svelte-spa — простой шаблон для Go + Svelte SPA
🔗 https://github.com/joelseq/go-svelte-spa
Этот проект — минималистичный стартовый шаблон, который объединяет мощь Go и фронтенд на Svelte в одном репозитории. Отлично подойдёт для быстрого создания одностраничных приложений (SPA) с современным интерфейсом и надёжным сервером.
🧩 Что внутри:
✅ Go-сервер:
- Отдаёт статические файлы фронтенда
- Поддерживает SPA-маршруты через fallback на
✅ Svelte SPA:
- Структура с
- Лёгкий, быстрый и понятный фронтенд
✅ Makefile + Vite + Docker (опционально)
⚙️ Как запустить:
📦 Кому подойдёт:
- Go-разработчикам, которым нужен современный UI
- Тем, кто хочет обойтись без сложных фреймворков
- Для MVP, pet-проектов, админок и внутренних тулов
🔥 Если хочешь быстрый и удобный стек без лишнего —
📁 Репозиторий: https://github.com/joelseq/go-svelte-spa
🔗 https://github.com/joelseq/go-svelte-spa
Этот проект — минималистичный стартовый шаблон, который объединяет мощь Go и фронтенд на Svelte в одном репозитории. Отлично подойдёт для быстрого создания одностраничных приложений (SPA) с современным интерфейсом и надёжным сервером.
🧩 Что внутри:
✅ Go-сервер:
- Отдаёт статические файлы фронтенда
- Поддерживает SPA-маршруты через fallback на
index.html✅ Svelte SPA:
- Структура с
App.svelte, маршрутизацией и Vite - Лёгкий, быстрый и понятный фронтенд
✅ Makefile + Vite + Docker (опционально)
⚙️ Как запустить:
# Сборка фронта
cd frontend
npm install
npm run build
# Запуск Go-сервера
cd ..
go run main.go
📦 Кому подойдёт:
- Go-разработчикам, которым нужен современный UI
- Тем, кто хочет обойтись без сложных фреймворков
- Для MVP, pet-проектов, админок и внутренних тулов
🔥 Если хочешь быстрый и удобный стек без лишнего —
go-svelte-spa отличный выбор.📁 Репозиторий: https://github.com/joelseq/go-svelte-spa
👍2🔥1