Хмарний вітрильник

🚨 Важлива уразливість в ingress-nginx (CVE-2025-1974) 🚨 Думаю на днях в деяких каналах бачили що в нжінкс з'явилась нова, дуже серйозна вразливість ❗️ У чому проблема: У ingress-nginx (це інструмент у Kubernetes, який керує трафіком до застосунків) знайшли слабке місце.В ingress-nginx до версії 1.9.4 неправильно оброблялися заголовки HTTP-запитів (наприклад, некоректно опрацьовувалася довжина тіла повідомлення). Через це зловмисник міг приховати частину свого шкідливого запиту всередині легітимного запиту, і ingress-контролер пересилав би цю приховану частину напряму до бекенду. В результаті зловмисник може сформувати спеціальний HTTP-запит, який «обдурить» ingress, дозволяючи непомітно переслати шкідливі запити до внутрішніх сервісів. Це називається HTTP request smuggling. ❗️ Чим це небезпечно: Через цю проблему атакуючий може обійти захист, отримати доступ до приватних даних, які мали б бути захищені, або навіть повністю перехопити контроль над вашим застосунком. Деталі про сам інцидент https://github.com/advisories/GHSA-mgvx-rpfc-9mpv Цікавий відос в додачу: https://www.youtube.com/watch?v=tmPvPnqldz0 ✅ Як вирішити: Потрібно терміново оновити ingress-nginx до версії v1.9.4 або новішої. А про інгреси, включаючи нжінкс, ми поговоримо вже на наступних кількох тижнях, час трошки повернутись до куберу😏 ☁️Хмарний вітрильник☁️

✅ DevPod або одне з рішень як позбутись проблеми "а на локалке все працює!" 💀Кожен розробник витрачає купу часу, щоб налаштувати зручне середовище для роботи. DevPod вирішує цю проблему, дозволяючи швидко створити готове до роботи середовище прямо в хмарі або локально. 🔹 Що він вміє? 1. Автоматично створює готове до роботи середовище (VS Code, термінал, Docker тощо). 2. Підтримує AWS, Google Cloud, Azure та локальне використання. 3. Дозволяє зберігати налаштування і ділитися ними з командою. # Встановлюємо DevPod CLI brew install devpod # Авторизуємося в AWS aws configure # Створюємо середовище в AWS за одну команду devpod provider add aws devpod create my-devpod --provider aws В результаті для вас буде збілджено, наприклад, віддалений сервер з вс кодом. Більше того, через devcontainer.json файлик можна засетапити додаткові плагіни, наприклад: { "name": "My DevPod Container", "image": "mcr.microsoft.com/devcontainers/python:3.11", "features": { "ghcr.io/devcontainers/features/git:1": {}, "ghcr.io/devcontainers/features/docker-in-docker:2": {} }, "extensions": [ "ms-python.python", "eamodio.gitlens" ], "postCreateCommand": "pip install -r requirements.txt", "remoteUser": "vscode" } А потім просто запустити наступною командою типу: devpod up --devcontainer-path .devcontainer/devcontainer.json 📚 Документація та детальніше: 1. Офіційний сайт: https://devpod.sh 2. Як почати з AWS: https://devpod.sh/docs/providers/aws ☁️Хмарний вітрильник☁️

🧠 Що може піти не так при тренуванні ML-моделей? 🤓В минулому пості ми говорили про те, які параметри взагалі існують в машинному навчанні, але окрім цього варто знати і про негативні явища в машинному навчанні. Тож давайте пройдемося по порядку які ж це негативні явища: 1️⃣ Overfitting Модель занадто добре навчається на тренувальних даних і погано узагальнює на нових. 🔸 Приклад: нейромережа, яка ідеально визначає котів на тренувальному датасеті, але помиляється на реальних фото через занадто дрібні деталі, що не мають значення. 2️⃣ Underfitting Модель не здатна вловити закономірності навіть у тренувальних даних. 🔸 Приклад: лінійна регресія для складних нелінійних даних, яка видає погані прогнози на будь-якому наборі. 3️⃣ Data Drift Тут з часом може бути зміна розподілу даних, через що подальше прогнозування моделі може бути неправильним. 🔸 Приклад: модель прогнозування попиту, яка перестає коректно працювати після економічних змін або сезонних перепадів. 4️⃣ Concept Drift Таке відбувається коли суть (контекст) задачі поступово змінюється і модель вже не може ефективно використовуватись у продакшні. 🔸 Приклад: модель визначення спаму, яка починає помилятись через появу нових типів повідомлень, які раніше не були класифіковані як спам. 5️⃣ Selection Bias Це ситуація, коли тренувальні данні підібрані, оброблені неправильно або ж їх просто недостатньо. Через це модель не може коректно визначити правильні результати на більшій вибірці у реальних кейсах. 🔸 Приклад: розпізнавання облич, яке погано працює на певних групах людей через нерівномірний розподіл у тренувальних даних. ⌨️Взагалі всі ці проблеми виникають виходячи з контексту задачі, яку ставлять моделі. Десь може бути головною проблемою оверфітинг, а десь може бути і концепт дрифт, тут краще завжди мати руку на пульсі з колегами дата-сайнтистами та бізнесом. ⚠️З іншої сторони, такі проблеми можна відслідкувати якщо при побудові процесів налаштувати правильно моніторинг, аби він міг відловлювати метрики як під час тренування так і в продакшні ☁️Хмарний вітрильник☁️

Про метрики у Machine Learning 🗒Взагалі кажучи в цьому пості буде мало про девопс, але насправді тема метрик під час навчання моделей є дуже важлива. Особливо це стосується ситуацій, коли ви впроваджуєте continuous training + monitoring, коли треба швидко та динамічно відстежувати метрики точності моделі. 😐Наприклад, ось основні з них: Перед цим, давайте для пояснення наших метрик уявімо що наша модель має вирізнити, чи є у пацієнта, наприклад, рак 📌 Accuracy — загальна правильність моделі. Тобто як часто модель правильно дає діагнози. 📌 Precision — частка правильно визначених позитивних результатів від усіх результатів, позначених як позитивні. Тобто це частка пацієнтів, яким модель поставила позитивний діагноз (рак), і вони дійсно мають рак. 📌 Recall — частка правильно визначених позитивних результатів від усіх реально позитивних (true positive) результатів. Тобто це частка всіх пацієнтів, які справді мають рак, яких модель змогла виявити. Високий Recall означає, що модель майже не пропускає реальних випадків захворювання, знижуючи ризик не помітити хворобу у справді хворих. 📌 F1-Score — гармонічне середнє між Precision та Recall, використовується, коли важливий баланс між ними. Фактично на мові ML інженерів це «золота середина» між Precision та Recall. Він важливий, коли потрібно знайти оптимальний баланс між тим, щоб уникнути хибних діагнозів (не лякати здорових людей без необхідності), і водночас не пропустити реальних хворих. 📌 ROC-AUC — метрика якості, що оцінює здатність моделі розрізняти класи. Це по суті метрика, яка демонструє здатність моделі розрізняти хворих та здорових пацієнтів незалежно від конкретного порогу рішення (threshold). 🤓Взагалі кажучи, а що ці метрики дають? Наприклад, є такі два негативні явища при навчанні моделі як overfitting (коли модель просто запам'ятала тренувальні дані і не робить на їх основі коректні висновки по новим даним) та data-shift (коли зміна вхідних даних по якості може погіршувати точність моделі), і ось як їх можна помітити по моніторингу: 1️⃣Оверфітинг помітний, коли Loss та Accuracy значно краще на тренувальних даних порівняно з тестовими. Це свідчить, що модель «запам'ятала» тренувальні дані замість узагальнення. 2️⃣Дата-шифт можна виявити за погіршенням метрик Precision, Recall або ROC-AUC з часом, особливо коли модель починає обробляти нові набори даних, які відрізняються від початкових. А які метрики використовуєте ви для моніторингу ML-моделей або які ми не написали? Діліться досвідом 👇 P.S.: ось кілька класний джерел де можна детальніше про метрики почитати: 1. Пояснення метрик від гугла 2. Непоганий гайд не медіумі ☁️Хмарний вітрильник☁️

Між іншим, приблизно так може виглядати один з можливих ML пайплайнів який побудований суто на AWS Сорс тут ☁️Хмарний вітрильник☁️

🧠 Що таке AWS Sagemaker? Отже, прийшов час трохи поговорити про клауд рішення для MLOps Спочатку був Jupyter, на якому люди писали нотбуки (пітонівський код який можна покроково запускати), далі захотілось створити єдине середовище для команди дата сайнтистів і вигадали JupyterHub, а потім... А потім девопси, млопси та сисадміни трохи втомились налаштовувати на залізі цю платформу, бо то ресурсів не вистачало, то навпаки — простоювали, то треба було контролювати аксес, а переїзжати на кубфлоу запарно (про нього трохи згодом) З тих пір і з'явився AWS SageMaker. Взагалі ця тула це швейцарський ніж у області дата сайнсу і трануванні ML моделей як таких. 🤔AWS SageMaker спрощує цей процес, пропонуючи готові інструменти для розгортання та управління ML-моделями без зайвого клопоту з інфраструктурою ☁️ 😎У свою чергу AWS Sagemaker дозволяє позбавлятись потреби самостійно зводити складні середовища для обчислень, адже це все відбувається практично «з коробки»: піднімаєш інстанс який тобі треба, піднімаєш на ньому кернел (в цей кернел доречі можна кастомні налаштування через докер імедж прокидувати), можна налаштувати своє SSO, тож питання з безпекою буде простіше і окрім того в нього є ще інтеграція з MLFLow. 😎Ну і зрозуміло, що сам по собі AWS Sagemaker може умовно легко інтегруватись з іншими елементами амазону по типу Step Functions, Lambda або S3. У підсумку, якщо хочете використати наповну потужність амазону, і при цьому зменшити операційні витрати на обслуговування інфри на це діло — сейджмейкер ваш бро 👍 ☁️Хмарний вітрильник☁️

🙏Що таке DVC (Data Version Control)? 😠Якщо ти коли-небудь працював з моделями машинного навчання або обробляв великі обсяги даних, то знаєш, що версіонувати їх так само, як код, майже нереально. Дані займають багато місця, їх не запушиш у репозиторій Git, а кожна зміна може вносити хаос. Без DVC доводиться або зберігати купу копій файлів, або придумувати костилі з хешами і папками типу dataset_v1, dataset_v2_final, dataset_v2_final_really_final 😅. DVC (Data Version Control) — це як Git, але для даних. 🥰DVC вирішує цю проблему, додаючи систему контролю версій для великих файлів, моделей та артефактів обчислень. Він працює подібно до Git: ти додаєш файли, створюєш коміти, відстежуєш зміни. Але замість того, щоб зберігати великі дані в репозиторії, він лише записує їхні хеші та метадані, а самі файли можуть зберігатися в S3, Google Drive чи навіть на локальному диску. Наприклад, щоб додати великий датасет у DVC, ти просто виконуєш: dvc add data.csv Це створить спеціальний .dvc файл, який фіксує зміни. Далі пушиш його на віддалене сховище (наприклад, S3): dvc push А твій колега потім може відновити дані командою: dvc pull DVC буде корисним, якщо ти працюєш з машинним навчанням, великими логами або будь-якими файлами, які змінюються, і ти хочеш трекати їх, як код. Він допоможе синхронізувати дані між командами, економити місце і уникати хаосу з версіями. Тепер можна забути про датасети з купою _final_v2_latest у назві, бо DVC все контролює сам 😎. ☁️Хмарний вітрильник☁️

Що таке MLFlow? Привіт усім! Сьогодні хочемо розповісти про один з корисних інструментів для роботи з моделями машинного навчання – MLFlow 🚀. Якщо ви займаєтесь розробкою або експериментами в сфері ML, цей інструмент стане вам у пригоді. 😎MLFlow – це платформа з відкритим кодом, яка допомагає управляти життєвим циклом моделей. Він дозволяє відслідковувати експерименти, зберігати метрики та артефакти, а також спрощує процес деплойменту моделей. За допомогою MLFlow можна зручно порівнювати різні варіанти навчання та легко відновлювати запуск попередніх експериментів 😊. ⌨️Однією з головних проблем, які вирішує MLFlow, є відсутність централізованої системи для зберігання інформації про експерименти. Він допомагає усунути хаос у версіюванні моделей, забезпечуючи відтворюваність результатів та спрощуючи командну роботу над проектами в сфері машинного навчання. 😐Існують різні варіанти налаштування MLFlow. Його можна встановити локально за допомогою pip або розгорнути на віддаленому сервері для колективної роботи, також він представлений у AWS Sagemaker. Наприклад, щоб запустити MLFlow вручну через скрипт, можна використати наступну команду: mlflow server --backend-store-uri sqlite:///mlflow.db --default-artifact-root ./mlruns --host 0.0.0.0 --port 5000 Ця команда запускає MLFlow сервер, який використовує SQLite для зберігання даних експериментів та локальну папку для зберігання артефактів. Це чудовий приклад для старту, який ви можете модифікувати під свої потреби 🤖. Це один з часто використовуваних інструментів в MLOps і треба, між іншим, правильно ще й задати архітектуру того ж бекенду. Наприклад, можна використовувати як казали вище просто локальну папку з SQLite, але в комерційних випадках це як правило S3+PostgreSQL, і треба, якщо експерименти часто робляться, проводити моніторинг та перевірку роботи саме бази даних, а ще моніторити чи не забагато непотрібних версій моделей летять на бакет, бо це також влітає в копійчину. Детальніше можете подивитись туть В цілому можемо сказати, що цей інстурмент дуже хороший для трекінгу та проводження експериментів моделей, тому і часто зустрічається на ML проектах. ☁️Хмарний вітрильник☁️

Що таке MLOps та з чим його їдять 🤖 ✋Всім привіт, нарешті поступово будемо говорити про MLOps) ✋MLOps – це підхід, який допомагає автоматизувати всі етапи роботи з машинним навчанням. Коли дата-сайентисти створюють модель, MLOps дозволяє швидко і надійно розгорнути її в реальному середовищі, постійно відслідковувати її роботу та оновлювати, якщо дані змінюються. DevOps, натомість, орієнтований на автоматизацію розробки та розгортання програмного забезпечення, керуючи кодом і інфраструктурою. У MLOps додаються додаткові процеси, як-от контроль якості даних, версіювання експериментів і моніторинг точності моделі. 👷Наприклад, MLOps дозволяє вирішувати такі задачі: 1. Розробка та впровадження автоматизованих пайплайнів для підготовки даних, тренування, тестування та розгортання моделей. 2. Постійний моніторинг продуктивності моделей у виробничому середовищі, виявлення зниження точності (model drift) та організація перетренування у разі потреби. 3. Забезпечення належної інфраструктури для масштабування, високої доступності та безпеки ML‑систем, співпраця з IT- та DevOps-командами для підтримки інфраструктурних рішень. Стосовно стеку, який треба знати, насправді на ринку ІТ MLOps має знати все те саме що і девопс на базовому рівні, але: 1. Треба вміти сетапити та підтримувати середовище розробки для дата сайнтистів: Jupyterlab, Kubeflow, AWS Sagemaker 2. Також треба вміти працювати з DVC (Data Version Control) і в принципі з різними платформами для дата пайплайнів аля Apache Airflow або Apache Spark 3. Також треба вміти працювати з відеокартками — хоча там сетапити драйвера не складно, але на клауд солюшнах треба знати як це діло автоматизувати (наприклад через Packer або gpu-operator куба) 4. Власне, треба вміти працювати з інструментами моніторингу та розгортання ML моделей типу MLFlow або Bento ML 🤯Насправді тулів тут вагон і ціла тележка, і насправді як в девопсі від вакансії до вакансії стек може разюче відрізнятись, так і з MLOps — десь все побудовано на AWS Sagemaker + Bedrock, а десь треба все по шматочкам на дедікейтед серверах білдити на ансіблі. Головне тут — розуміти яку саме задачу вирішують MLOps інжененери і відносно цього, якщо є бажання, спробувати зробити пет проект. Але про це та про конкретні інструменти та процеси MLOps трошки пізніше))) ☁️Хмарний вітрильник☁️

П’ять бест-практіс GitLab-пайплайнів 👩‍💻 🤩Ви чекали, а ми приїхали! Підготували для вас 5 базових порад як білдити гілтаб пайплайнів) П’ять бест-практик GitLab-пайплайнів для DevOps із прикладами коду 1. Розділення пайплайна на окремі стадії Логічно структуруйте процес на кроки, як-от build, test, deploy. Завдяки цьому помилки виявляються на ранніх етапах, а ресурси використовуються ефективніше. Приклад: stages: - build - test - deploy build_job: stage: build script: - echo "Build stage..." - mvn package test_job: stage: test script: - echo "Test stage..." - mvn test deploy_job: stage: deploy script: - echo "Deploy stage..." - ./deploy.sh 2. Використання кешування (caching) для швидшої збірки Зберігайте залежності (npm, pip, Maven та ін.) у кеші, щоб уникнути повторного завантаження при кожному запуску пайплайна та суттєво скоротити час збірки. Приклад: build_job: stage: build cache: key: ${CI_COMMIT_REF_SLUG} paths: - .m2/repository script: - mvn package 3. Паралельні джоби (parallel jobs) для прискорення виконання Якщо у вас багато різних тестів або окремих перевірок, ви можете запустити їх одночасно на різних раннерах. Це зменшує загальний час виконання пайплайна. Приклад: test_job_a: stage: test script: - echo "Running Test A..." - mvn test -Dtest=TestA test_job_b: stage: test script: - echo "Running Test B..." - mvn test -Dtest=TestB 4. Захист секретів і керування змінними середовища Замість зберігання паролів або токенів у відкритому вигляді, використовуйте GitLab CI/CD Variables (зокрема Protected або Masked). Це дає змогу безпечно передавати конфіденційні дані у скрипти. Приклад: deploy_job: stage: deploy script: - echo "Deploy to prod with token: $DEPLOY_TOKEN" - ./deploy.sh only: - main Тут змінна DEPLOY_TOKEN зберігається в налаштуваннях репозиторію (Settings -> CI/CD -> Variables). 5. Використання ручних етапів (manual jobs) та політик схвалення Для важливих розгортань у продакшн можна додати ручну перевірку (manual job), що дає змогу уникнути випадкового або передчасного релізу. Також не забувайте про Merge Request Approvals для контролю якості коду. Приклад: deploy_production: stage: deploy script: - echo "Deploying to production..." - ./prod_deploy.sh when: manual only: - main Дотримуйтеся цих практик, аби налаштувати GitLab CI/CD максимально надійно та ефективно. Так ви пришвидшите випуск нових версій, забезпечите прозорість процесів і мінімізуєте ризик помилок. Це базові речі, але якщо хочете якихось додаткових фішок — ставте вподобайку❤️

Всім привіт!❤️ Хотіли б для вас на наступному тижні розписати деталі по бест практісам для CI/CD пайплайнам, тому перед цим буде повторення по одному з відомих ранерів — GitLab🙂 👩‍💻Що таке гітлаб? Сьогодні поговоримо про GitLab — потужну😎 платформу для спільної розробки та керування кодом. GitLab об'єднує в собі інструменти для версіонування, спільної роботи та має вбудовану систему автоматизації процесів розробки — CI/CD. 🚗Серед популярних фреймворків для CI/CD є Jenkins, Travis CI, CircleCI та GitHub Actions. Однак GitLab CI/CD вирізняється тим, що він інтегрований безпосередньо в GitLab, спрощуючи налаштування та використання. 🤯Як правило гітлабом можна користуватись або в клауді (використовуючи гітлаб як SaaS) або самостійно підняти свій ранер (де буде працювати CI/CD) і з нього все менеджити. Для того щоб написати пайплайн, використовуються декларативні файли формату yaml, наприклад: stages: - build - deploy variables: IMAGE_NAME: myapp:${CI_COMMIT_SHORT_SHA} build: stage: build script: - docker build -t $IMAGE_NAME . - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY - docker push $IMAGE_NAME deploy: stage: deploy only: - main script: - ssh user@server 'docker pull $IMAGE_NAME && docker-compose up -d' 😁В цьому прикладі ми просто білдимо автоматично імедж, пушимо його і деплоїмо через ссш з докер компоузу на якийсь віддалений сервер. 💪Взагалом дуже проста штука як для девопсів так і для девелоперів (точно простіше ніж дженкінс зі своїм груві), однак простота в порівнянні з тим же дженкінсом компенсується меньшою гнучкістю (не можна наставити 250 плагінів), однак, для загальних потреб це не настільки критично P.S.: фан факт — не дивлячись на те що гітлаб це продукт з Нідерландів, його основополжниками є українці, так що в якійсь мірі це навіть наше досягнення в ІТ індустрії ☁️Хмарний вітрильник☁️