DevOps

⚡️ 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/

📜 История 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. - Ключевая фишка — запросы выглядят почти как английские предложения: 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

✔️Y Combinator назвал главные тренды лета 2025 для стартапов. Y Combinator сделал ставку на ИИ-агентов, способных переосмыслить целые индустрии. Вместо точечных решений, основателям советуют создавать «полноценные ИИ-компании» - например, запускать собственные юридические бюро с ИИ-юристами вместо сотрудников. Такой подход позволяет обойти медлительных конкурентов, предлагая клиентам более дешевые и эффективные сервисы. Особый интерес к автоматизации рутины: персональные ассистенты, которые не просто напоминают о задачах, а самостоятельно отвечают на письма, планируют встречи и имитируют стиль общения пользователя. Y Combinator верит: будущее за командами, которые не просто внедряют ИИ, а перестраивают рынки с нуля, как это сделали Airbnb или Stripe. ycombinator.com ✔️ИИ помог создать синтетические ДНК-усилители для контроля генной экспрессии. Ученые из Центра геномной регуляции в Барселоне впервые применили генеративный ИИ для проектирования синтетических молекул ДНК, способных управлять активностью генов в здоровых клетках млекопитающих. Модель, обученная на данных тысяч экспериментов, генерирует последовательности «с нуля», задавая критерии. В качестве теста создали фрагменты ДНК, активирующие ген флуоресцентного белка в клетках крови мышей. Результаты совпали с прогнозами: синтетические усилители генной активности работали как «переключатели» в зависимости от типа клеток. Исследование открывает путь к персонализированным методам коррекции генов. По словам авторов, это похоже на «написание софта для биологии», где каждая инструкция для клетки становится программируемой. technologynetworks.com ✔️OpenAI запускает HealthBench. OpenAI представила HealthBench - бенчмарк для тестирования ИИ-систем в сфере здравоохранения. Разработанный при участии 262 врачей из 60 стран, он включает 5000 реалистичных диалогов, имитирующих общение пациентов и медиков. Каждый сценарий оценивается по индивидуальным критериям, созданным экспертами: точность данных или ясность ответов. Всего в бенчмарке 48 562 параметра оценки, что позволяет глубоко анализировать работу моделей. Особый упор сделан на надежность: даже один ошибочный ответ в медицине критичен. HealthBench включает подборки сложных кейсов (HealthBench Hard), где современные ИИ еще отстают. Все данные и методики уже доступны в GitHub-репозитории OpenAI . openai.com ✔️Google запускает фонд для стартапов. Google анонсировала AI Futures Fund — программу для поддержки ИИ-стартапов. Участники получат ранний доступ к моделям DeepMind (Gemini, Imagen и Veo). Кроме технологий, стартапы смогут консультироваться с инженерами и исследователями Google, а также получат облачные кредиты для обучения и масштабирования решений. Уже сейчас с фондом работают проекты из разных сфер: индийский Toonsutra внедряет Gemini для перевода комиксов, Viggle экспериментирует с генерацией мемов, а платформа Rooms тестирует интерактивные 3D-пространства. Программа открыта для стартапов из регионов, где доступен Gemini. Подать заявку можно на сайте фонда. Участники смогут претендовать не только на технические ресурсы, но и на прямые инвестиции от Google. blog.google ✔️Поддельные ИИ-инструменты распространяют стиллер Noodlophile. Злоумышленники активно используют популяризацию ИИ для распространения вредоносного стиллера 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

CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀 GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub. Почему это важно: Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег. 1. Кэшируй разумно Используй actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js: - uses: actions/cache@v4 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node- ⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий. 2. Делай job-ы параллельными Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй needs: там, где реально нужно, а не везде. 3. Matrix strategy — must-have Хочешь тестировать на разных версиях языка/ОС? Используй matrix: strategy: matrix: node-version: [16, 18, 20] Это масштабирует проверку без дублирования кода. 4. Отключи ненужные события Не запускай воркфлоу на каждом чихе. Используй on: грамотно: on: push: branches: - main pull_request: paths: - 'src/**' Это поможет не перегружать runners. 5. Используй workflow_dispatch для ручных запусков Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер: on: workflow_dispatch: 6. Логи и таймауты — твои друзья Добавляй timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли. Вывод: Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос. #devops#девопс

🐧Задача с подвохом: Странное поведение с `df` и `du` Условие: Вы замечаете, что на сервере /var/log неожиданно «занялось» много места. Проверяете это так: df -h /var И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log: du -sh /var/log — оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df. ❓Вопрос: Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер? 🔍Подсказка: На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились. --- ✅Разбор: 💥Подвох: Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске. Вот что происходит: - du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены). - df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами. 🚩 Это классическая ситуация после logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми. 🔧Как найти виновника: Используем lsof для поиска удалённых, но ещё открытых файлов: ```bash lsof | grep deleted ``` Вы увидите что-то вроде: ``` nginx 1234 ... /var/log/nginx/access.log (deleted) ``` 🛠Как исправить без перезагрузки: 1️⃣ Перезапустить приложение, которое держит файл открытым: ```bash systemctl restart nginx ``` 2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда). --- ✅Вывод: • df и du показывают разное, потому что считают разными методами: - df: что реально занято на диске (включая удалённые, но ещё открытые файлы) - du: что физически доступно через файловую систему • Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps! 💡Бонус-вопрос для гуру: Что произойдёт, если в lsof вы видите удалённый файл, но процесс — это docker? Как поступить в этом случае? 😉

🔥 Ошибка Therac-25: когда код убивает ▪ В 1980-х Therac-25 считался чудом медицины: новый линейный ускоритель для лечения рака с точной дозировкой радиации. Разработчики гордились: теперь всё управляет программное обеспечение — минимум ручной работы и максимум безопасности… казалось бы. Но вскоре пациенты начали получать смертельные дозы радиации. Люди приходили на лечение и получали 100-кратное превышение нормы буквально за секунды. Некоторые умирали мгновенно, другие — спустя несколько недель. Что же случилось? 👇 ▪ Гонка потоков (race condition) — незаметный баг в коде. Если техник слишком быстро переключал режимы лечения, программа не успевала правильно активировать защиту. Результат: машина включала мощнейший луч без блокировки и буквально сжигала пациентов. Разработчики уверяли, что код «идеален» и проблема не в них. Только после нескольких трагедий независимые эксперты нашли источник: баг проявлялся лишь при экстремально быстром вводе комбинаций клавиш — ситуация, которую никто даже не тестировал. 💥 Итог: Therac-25 стал примером того, что даже одна строка кода может убить, если игнорировать тестирование edge-case сценариев. Этот случай навсегда изменил стандарты разработки критически важных систем, введя новые международные нормы безопасности. 👉 Урок: Никогда не верь, что твой код «без ошибок». Особенно когда от него зависят жизни. #код#баги#историиИТ#therac25#разработка#тестирование#fail

🗺Google maps scraper Это Golang парсер, на основе фреймворка scrapemate который позволяет удобно парсить данные из Google Maps. Он автоматизирует просмотр веб-страниц и позволяет извлекать: имя, адрес, номер телефона, URL-адрес веб-сайта, рейтинг и количество отзывов для каждого выбранного вами места. Все данные сохраняются в файл CSV для удобства анализа и обработки. Содержит код для быстрого запуска с использованием Docker. ▪Github @devopsitsec

🖥Эта статья объясняет, как использовать инструмент K3D для запуска легковесных Kubernetes-кластеров K3S в контейнерах Docker! 🌟 В статье описываются шаги по установке и настройке K3D, создание кластеров, управление их состоянием и развертывание приложений. K3D идеален для локальной разработки, тестирования и CI/CD, благодаря своей простоте и низкому потреблению ресурсов. 🔗 Ссылка: *клик* @devopsitsec

🐳 Как устроен Docker: что происходит «под капотом» Поговорим немного про базу. Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри. 1) Что такое контейнер? Контейнер — изолированная среда, где запускается приложение со всеми зависимостями. ⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию. 2) Основные компоненты • Docker Engine – Docker Daemon (`dockerd`) управляет контейнерами, образами, сетями – Docker CLI (`docker`) — интерфейс пользователя – REST API — взаимодействие CLI и Daemon 👉 Пример: docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс. 3) Namespaces Механизм изоляции в Linux, создающий для контейнера: • свой процессный ID (pid namespace) • файловую систему (mnt namespace) • сеть (net namespace) • hostname (uts namespace) • IPC (ipc namespace) 👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы. 4) Cgroups Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть). Пример: можно задать лимит 512 МБ RAM и 0.5 CPU. Если приложение превышает лимит — Docker его ограничит или остановит. 5) Union File Systems (OverlayFS) Docker использует многослойную файловую систему. Каждый шаг Dockerfile создаёт новый слой. При запуске контейнера создаётся верхний writable-слой, остальные read-only. 👉 10 контейнеров на одном образе разделяют слои → экономия места. 6) Container Runtime Docker использует runc для запуска контейнера (соответствует OCI Runtime Spec). Daemon вызывает runc, который через clone(), setns(), chroot() изолирует процесс. 7) Docker Images Образ — read-only слои, собранные в Union FS. Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой). Хранение: локально (`/var/lib/docker`) или в реестре (Docker Hub, GitLab Container Registry). 8) Docker Networking Docker создаёт виртуальные сети (bridge, overlay, host). По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула. 👉 Можно пробросить порты через -p, создать собственные сети, объединять контейнеры через docker network connect. В Swarm используется Overlay network (сеть между хостами). 9) Безопасность Docker использует: • seccomp (ограничение системных вызовов) • AppArmor / SELinux (контроль привилегий) • user namespaces (отображение UID контейнера в другой UID хоста) ⚠️ По умолчанию контейнеры имеют широкий доступ (например, /proc виден). Для production стоит ограничивать права (например, `--cap-drop`). 10) Что происходит при `docker run nginx`? 1. CLI отправляет запрос через API 2. Daemon ищет образ (локально или в registry) 3. Создаётся read-write слой контейнера 4. Создаются namespace (pid, net, mnt…) 5. Применяются cgroups 6. Вызывается runc для изоляции процесса 7. Контейнер подключается к сети 8. Запускается ENTRYPOINT/command Контейнер живёт, пока жив его процесс. 11) Почему Docker — не магия? Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс. Контейнер — просто изолированный процесс, а не полноценная VM. Поэтому Docker лёгкий, быстрый, удобный. 12) Заключение Под капотом Docker: • namespaces — изоляция • cgroups — контроль ресурсов • runc — запуск • overlayfs — многослойная ФС • REST API + Daemon + CLI — взаимодействие Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений. Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать. ➡️Подробнее @DevopsDocker

💻Kube-green — это оператор Kubernetes, разработанный для снижения углеродного следа кластеров! 🌟 Он позволяет приостанавливать модули, которые не используются, и уменьшать масштабирование кластера, что экономит ресурсы и снижает энергопотребление. В будущем планируется добавить "Green Dashboard" для мониторинга сбережений энергии и влияния на экологию. 🔐 Лицензия: MIT 🔗 Ссылка: *клик* 🖥Github @devopsitsec

🏗️ Гайд: Эффективная оркестрация контейнеров с Docker в продакшн-среде Ниже — подробное руководство для продвинутых пользователей, с примерами из реальной практики, кодом и комментариями. 1️⃣ Выбор инструмента оркестрации Docker предоставляет базовые возможности, но для продакшн-оркестрации требуется полноценный движок: ✅Docker Swarm — встроенный, подходит для малых и средних проектов ✅Kubernetes (K8s) — промышленный стандарт, подходит для масштабных систем ✅Nomad (от HashiCorp) — легковесная альтернатива 👉 Для быстрого старта используй Swarm, для больших систем — Kubernetes. 2️⃣ Архитектура кластера Рекомендуемый минимум: • 3 manager-ноды (quorum, HA) • 2+ worker-ноды • overlay-сеть • load balancer (например nginx, HAProxy) • private registry (Harbor, GitLab Registry) Инициализация кластера: docker swarm init --advertise-addr MANAGER_IP docker swarm join --token <join-token> MANAGER_IP:2377 Создание overlay-сети: docker network create --driver overlay --attachable my-overlay --- 3️⃣ Развёртывание сервисов Пример docker-compose.yml (версии 3 для Swarm): version: '3.9' services: web: image: mycompany/webapp:latest replicas: 5 deploy: update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure networks: - frontend ports: - "80:80" networks: frontend: driver: overlay Запуск: docker stack deploy -c docker-compose.yml mystack --- 4️⃣ Zero-Downtime Updates Добавь healthcheck в Dockerfile: HEALTHCHECK --interval=30s --timeout=10s \ CMD curl -f http://localhost/health || exit 1 В docker-compose.yml уже используется update_config → обновления происходят без даунтайма (по 2 контейнера каждые 10s, с проверкой healthcheck). --- 5️⃣ Резервное копирование Полезные команды: docker swarm unlock-key docker swarm join-token manager docker node ls Бэкап Raft: docker container stop $(docker container ls -q --filter name=swarm) cp -r /var/lib/docker/swarm ~/swarm-backup 6️⃣ Мониторинг и логирование ✅Prometheus + Grafana — метрики ✅ELK Stack / Loki — логи Пример запуска cAdvisor: docker run -d \ -p 9323:9323 \ --name cadvisor \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:ro \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ google/cadvisor:latest 7️⃣ Безопасность • Запуск от непривилегированного пользователя: USER appuser • Read-only root filesystem: deploy: read_only: true • Ограничение capability: deploy: cap_drop: - ALL • Сканирование образов (Trivy): trivy image mycompany/webapp:latest • Не использовать latest тег: image: mycompany/webapp:1.3.2 8️⃣Оптимизация Dockerfile ✅multi-stage build ✅ минимизируй слои ✅ данные — во внешние volume Пример multi-stage: FROM node:18 AS build WORKDIR /app COPY . . RUN npm install && npm run build FROM nginx:alpine COPY --from=build /app/build /usr/share/nginx/html 9️⃣Управление секретами Создание секрета: echo "my-secret-value" | docker secret create db_password - Использование в docker-compose.yml: secrets: - db_password В контейнере доступно как /run/secrets/db_password. 🔟 CI/CD Пример пайплайна (GitLab): stages: - build - deploy build: stage: build script: - docker build -t registry.example.com/myapp:$CI_COMMIT_SHA . - docker push registry.example.com/myapp:$CI_COMMIT_SHA deploy: stage: deploy script: - docker service update --image registry.example.com/myapp:$CI_COMMIT_SHA mystack_web 🎯Заключение Эффективная оркестрация = ✅ грамотная архитектура ✅ rolling updates + healthchecks ✅ безопасность (secrets, cap_drop, read_only) ✅ мониторинг и логирование ✅ CI/CD интеграция ✅ регулярный бэкап 👉 Swarm = быстрый старт, Kubernetes = масштабирование.

👾eBPF вместо прокси: новый подход к масштабированию в Kubernetes. Инженеры WSO2 предложили нестандартное решение для scale-to-zero в Kubernetes — отказ от прокси в пользу eBPF. Они создали прототип, где eBPF-программа на уровне XDP перехватывает пакеты, инициируя масштабирование сервисов без промежуточного слоя. 🧑‍💻 Как это работает? — eBPF-драйвер отслеживает запросы к остановленным сервисам, временно блокируя их и запуская масштабирование — После готовности POD запрос проходит напрямую, минуя прокси — Подход работает для любых TCP-сервисов, включая базы данных Преимущества: — Работает для любых TCP-сервисов (не только HTTP) — Снижение latency на 30-50% по сравнению с прокси-решениями — Полная совместимость с существующими сетевыми политиками — Поддержка даже stateful-сервисов вроде PostgreSQL 🔗 Ссылка - *клик* @devopsitsec