#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.

DevOps…Такий нескінченний, такий незрозумілий 😎

DevOps – це про більш ефективну спільну роботу. Саме культура взаємодії команд розробки та експлуатації лежить в основі цієї філософії. Команди несуть спільну відповідальність та працюють спільно. При цьому підвищується їхня ефективність, а витрати на розробку знижуються.

Погоджуєтесь? 😉

😳А ви знали, що cтандартне ядро Linux сьогодні має понад 10 000 000 рядків коду, і ця цифра щорічно зростає на 10%?

Це відбувається через те, що до ядра додається близько 4500 рядків коду, й щодня змінюється 1500 рядків. Для порівняння: у 1991 році версія ядра Linux 0.01 містила 10239 рядків.

Критичні помилки системного адміністратора

❌ Покладатися на систему резервного копіювання.
✅Бажано періодично перевіряти бекапи мануально.

❌ Відсутність документації.
✅Всі зміни у налаштуваннях інфраструктури мають бути зафіксовані.

❌ Відсутність планування.
✅Сисадмін повинен мати як довго- й середньострокові плани, так і сценарії оперативного розв’язання задач.

❌ Пласка побудова мережі.
✅Краще сегментувати мережу та використовувати VLAN.

❌ Однотипне ПЗ.
✅Рекомендовано використовувати в інфраструктурі альтернативні операційні системи, якщо це можливо.

А як у вас із цим? Обговоримо у коментарях ⬇️

Плагін helm-dashboard

Цей плагін дозволяє переглядати встановлені Helm Charts (Helm – пакетний менеджер для Kubernetes, Charts – спеціальний формат пакетів у Helm). З його допомогою є можливість аналізувати історію та відповідні ресурси k8s. Також доступні прості дії, як от повернення до попередньої версії або оновлення.

🤔 Про вічне: стосунки девів та опсів. Чи є у них майбутнє? Цікавий огляд панельної дискусії The New Stack.

Проводимо коротеньке опитування: чи може System administrator вирости до DevOps?

👌 Так, але треба багато чому навчитися
⛔️ Не думаю, що адміну буде легко зробити шифт до DevOps
😎 Та всі девопси виростають з адмінів!

Діліться своєю думкою у коментарях ⬇️

DevSecOps дедалі стає активною та невід'ємною частиною процесу розробки за принципами DevOps. Безпека вбудовується в продукт за допомогою активних перевірок і тестування безпеки у робочих процесах. Безпека – важлива частина конвейєру Continuous Integration and Continuous Delivery 👌

💥CRDs-catalog – корисний репозиторій Kubernetes CRDs (CustomResourceDefinition) у форматі JSON. У каталозі знайдете понад 100 популярних CRD. Ці схеми можна використовувати в різних інструментах на кшталт Datree, Kubeconform, Kubeval як альтернативу kubectl --dry-run. Можна виконувати валідацію на кастомних та оригінальних ресурсах Kubernetes.