#devopsспитав_devopsвідповів
Чи можна робити back-up секретів та Lease у Vault?

Секрети у Vault можна бекапити в базі даних. Якщо Vault виходить з ладу, секрети можна відновити, окрім команд Lease. Стан Vault після припинення роботи та снепшота бази відрізняється від стану Vault, коли його піднято повторно. Зроблено unseal, тому деякі Lease вже застаріли й були відкликані.

Kubernetes Network Policies ー зручний спосіб налаштування доступу до кластерів у Kubernetes. Політики дозволяют власноруч визначати, які сервіси можуть комунікувати один з одним. Це не тільки оптимізує управління, але й суттєво підвищує рівень сек’юрності.

Досидь докладно про те, як працюють Kubernetes Network Policies та як їх налаштувати, у туторіалі.

Щось давно ми не збиралися на крутих івентах. Треба це терміново виправляти! Маємо цікавий варіант, як з користю провести вечір 💥

29 вересня відбудеться DevOps мітап від Profisea Labs на тему FinOps, AWS і Kubernetes.

На вас чекають:
- Виступ від Олексія Петричко з WePlay Esports про його досвід переходу на AWS та Kubernetes;
- Станіслав Коленкін з Profisea, який розкаже про можливості eBPF та його застосування з нетворк плагінами Calico та Cilium.

Також буде панельна дискусія, на якій обговоримо безпеку, продуктивність та масштабування Kubernetes разом з Григорієм Тациєм, CTO Raiffeisen Bank Ukraine, Денисом Ладіком, Head of the Software Systems Operation Department PrivatBank, Олексієм Петричко, Head of Engineering у WePlay Esports, Антоном Грішко, Chief DevOps Architect в Profisea Labs, та Станіславом Коленкіним, Senior Solutions Architect / DevOps Manager у Profisea.

Модератор: Андрій Бурлуцький, Head of Marketing Profisea Labs.

Коли? 29 вересня, з 19:00 до 21:30.

Якщо ви цікавитеся підходом GitOps, вам, напевно, буде корисна ця стаття. Автор розповідає, як застосовувати концепцію в роботі з кластером Kubernetes і порівнює два інструменти – Argo CD Flux для continuous deployment.

krunvm ー тул, що допомагає створювати мікро віртуальні машини з OCI images.

#devopsспитав_devopsвідповів
Terraform та AWS: у чому різниця?

AWS управляє лише ресурсами AWS. А Terraform може управляти і AWS, і Azure, і Docker. Внутрішні інструменти AWS працюють майже без вад і одночасно оновлюються. У ситуації з Terraform може спізнюватися провайдер, але є плюс – платформу підтримує ком'юніті.

CeresDB ー розподільча, високоефективна, schema-less та cloud native база даних, яка одночасно може обробляти навантаження з аналітики та часових рядків.

pre-commit
Фреймворк для управління та підтримки мультимовних pre-commit hooks.

Цікава стаття про деплоймент у Kubernetes: від самого початку до налаштування конфігурацій власноруч.
Рекомендуємо 👍

#devopsспитав_devopsвідповів
Terraform: інфраструктура є, а tfstate немає. Як бути?

Можна підтягувати як remote state, і він буде використовуватися в режимі read only. Можна створити користувача в консолі, з правами адміністратора. У тестовому режимі не потрібні дозволи – це нічого не порушить. Якщо є старий tfstate, використовуєте cli. Або можна зробити експорт ресурсів, наприклад, експорт інфраструктури. Потрібно вказати фільтр по ресурсу та запустити експорт. Використовується в режимі read only.

furiko ー cron-job платформа для Kubernetes. Базується в хмарах та підходить для рівня enterprise.

Брет Фішер розкриває тему поєднання Node.js і Docker у своєму виступі з DockerCon 2022 Talk. Пропонуємо послухати, як Node.js Rocks in Docker з прикладами. Буде цікаво тим, хто вже розбирається з обома платформами та хоче трохи магії.

🚀 prowler ー open-source інструмент безпеки для платформи AWS. Він допомагає розкрити всі потужності AWS на максимумі: найкращі практики з оцінки, аудиту, повідомлення про інциденти, моніторинг тощо. Містить в собі більше 240 фіч: CIS, PCI-DSS, ISO27001, GDPR, HIPAA, FFIEC, SOC2, AWS FTR, ENS та кастомні налаштування фреймворків.

Непоганий розбір Prometheus Querying ー стаття рекомендована до прочитання.

#devopsспитав_devopsвідповів
Чи можна робити roll back у Terraform?

Версії в Terraform – умовні, але можна повернутись до попередньої версії, на попередній стан коду. Немає такого поняття як previous state або журнал стейтів. Існує політика back up – можна встановити, що зберігається попередня версія. Але це є максимум.

Чудові новини до Дня української писемності та мови від Grammarly Ukraine! 🇺🇦

Компанія виклала у вільний доступ UA-GEC 2.0 – другу версію анотованого GEC-корпусу української мови. Версія містить майже 34 000 речень, і її можна завантажити прямо зараз на GitHub.

UA-GEC – волонтерський проєкт зі створення набору даних, точніше, анотованих GEC-корпусів (GEC – grammatical error correction). Цей ресурс може бути корисним для обробки природної мови, досліджень та Machine Learning. Наприклад, GEC-корпус англійської містить 1 млн 167 тис. речень, німецької – 25 тис. речень, української (UA-GEC) – 33 735 речень.

Над проєктом працюють понад 800 волонтерів. Тож подякуємо цим людям за можливість практично досліджувати українську та покращувати програмні інструменти для роботи з нею!

Радимо практичний посібник з управління інцидентами 💥

#devopsспитав_devopsвідповів
Як зробити scale services через таргет-групу?

Розберемо ситуацію: робимо scale services на основі метрик у VCS, використовуючи два інстанси та різні task definitions. Прописуємо в task definitions контейнери, і виходить, що вони нічого не знають. Фактично доводиться використовувати хард-код, щоб зв'язати їх між собою по internal IP ec2-машинах. Питання: як можна по-іншому реалізувати процес, щоб уникнути хард-коду?

Відповідь: через таргет-групи. У цій ситуації послуги і не повинні знати один про одного. Є autodiscover таргет-групи, а скейлити повинна і таргет-група, і автоскейлінг-група. Наприклад, якщо кластеру не вистачає ресурсів, підключається автоскейлінг-група.

Таким чином, скейлінг може дати нову ноду. І якщо на новій ноді розгортається новий інстанс сервісу, на основі чого решта сервісу знатиме, що це новий контейнер і туди подаватиме трафік? В такому випадку таргет-група робить autodiscover сервісів.

Є варіант із SRV-записом, але він не найкращий – ви змушені перескакувати через таргет-групу. Так задумано, що весь трафік йде через таргет-групу, таргет-група робить discover сервіси і сервіси починають приймати трафік. Можна рано посилати трафік, або сервіс вже помер, а ви все ще намагаєтеся послати трафік. Тому і рекомендуємо робити все через таргет-групи.

💥 Дуже цікаві роздуми про те, що прогрес у технологіях та інженерне масштабування ー це постійне зростання ризиків відмов. Що більше ми винаходимо, тим більше створюємо проблем на інженерному рівні. Статтю можна прочитати або послухати.

Можна вічно дивитись на вогонь, воду та як ком’юніті сперечається, хто ж такий DevOps 🤔 Є думка, що в культурі DevOps можна виділити такі ролі:

✔️ Build Engineer – спеціаліст, що відповідає за збірку коду (підтягування залежностей, розбір конфліктів у коді тощо).
✔️ Release Engineer – відповідальний за доставку коду від розробки до продакшену (гілки, білди тощо).
✔️ Automation Engineer – людина, що автоматизує все (збірка при пуші в Git, прогон тестів, деплой на стейджингу та в продакшен тощо).
✔️ Security Engineer – фахівець, що працює з безпекою (тести, вразливість компонентів тощо).

На вашу думку, чи можна ці ролі віднести до DevOps? Пишіть в обговорені 👇

Using Kubectl Scale ーTutorial and Best Practices. Kubectl Scale ー один з інструментів, що допомагає керувати деплойментами в Kubernetes. Дізнайтеся, як це робити на прикладах best practices.