Dev // Ops
401 subscribers
86 photos
133 links
Канал для всіх, хто цікавиться DevOps філософією. Створений на основі досвіду компаній ZONE3000 і Namecheap. Тут ми ділимося корисним контентом і кейсами та відповідаємо на питання. Чекаємо ваші фідбеки, питання та рекомендації тут @educationzone3000
Download Telegram
☄️ ПРАВИЛЬНА ВІДПОВІДЬ
Методика допомагає інтегрувати оновлення в продукт і швидко розуміти, де відбувається збій у роботі.

Компанії відстежують метрики та ведуть журнали, щоб спостерігати за продуктивністю програми. Так вони збирають статистику взаємодії з користувачем. Аналізуючи дані, можна зрозуміти, які помилки повторюються, та покращити процес доставки оновлень.
👏5👍2
#devopsспитав_devopsвідповів
Навіщо запускати Jenkins у контейнері?

Jenkins можна запускати у контейнері, наприклад, щоб не ставити на машину Java чи не давати права доступу, тобто навантажувати комп'ютер непотрібними програмами.

Якщо не хочете, приміром, конфігурувати віртуальну машину або ICTU-машину, Instance в Azure, просто ставте Docker, розгортайте контейнер, і у вас – готовий Jenkins. По-перше, на це любо глянути, а ще це зручно і не потрібне адміністрування системи.

Якщо контейнер «помре», залишиться його volume, і з нього ми зможемо підняти такий самий новий Jenkins.
👍3🤔2
🚀 Безперервна доставка (CD) – ще одна методика DevOps. За будь-яких змін у програмному коді виконується автоматична збірка, тестування та підготовка до остаточного випуску.
👍2
☝️ А ось і правильна відповідь:

У розробників завжди є готовий до розгортання зібраний екземпляр ПЗ, що пройшов стандартизовану процедуру тестування.
Всі зміни коду після збірки розгортаються в тестовому або робочому середовищі. Це автоматизує тестування на рівні модулів та допомагає перевіряти програми перед тим, як надавати їх користувачам. Перевірка може включати тестування інтерфейсу користувача, завантаження, інтеграції, і, наприклад, надійності API.
👍1🤔1
Wiretrustee – Open-source VPN платформа, створена на WireGuard®. Дозволяє легко створювати приватні мережі для домашнього чи корпоративного використання.
👍4👎1
#devopsспитав_devopsвідповів
Чи потрібно додавати сертифікат SSL для Jenkins?

Добрий тон – додавати SSL-сертифікат до всього, інакше Chrome у якийсь момент просто перестане працювати з вашим ресурсом. У разі особистих потреб, наприклад, local host, можливо, сертифікат і не потрібен. Для невеликих команд це можна зробити через Google App Engine.

Якщо хостинг в ABC – через balancer. У Docker також можна додати, але немає сенсу додавати сертифікат на контейнер, який незабаром буде «знесено».
👍3
Новина для поціновувачів PHP ー The Definitive PHP 7.2, 7.3, 7.4, 8.0, and 8.1 Benchmarks (2022). Щорічне оновлення бенчмарків для різних PHP-платформ.
👍2
Хочете трохи відволіктись від роботи з користю? У цьому репозиторії зібрані різноманітні питання та врави з тематики DevOps та SRE, тож можна перевірити свої навички. Ну і, можливо, додасте собі в скарбничку щось нове.
👍5
Чи дійсно Kubernetes настільки складний, як багато-хто думає? 🤔

Наприклад, автор статті Kubernetes is so Simple You Can Explore it with Curl намагається довести протилежне. Він зовсім не принижує складної архітектури конфігурацій, але вважає, що в основі всього лежить проста, але геніальна ідея. Що ж, давайте поглянемо на думку автора.
👍3
#devopsспитав_devopsвідповів
Чи можна мігрувати контейнер із Jenkins на інший хост?

Мігрувати контейнер на інший хост неможливо, тому що це тільки контейнер і він не «підхопиться» через volume – може статися inconsistency.

Але якщо ми говоримо про перенесення поточних завдань на інший сервер, то в цьому випадку просто мігруємо Image. Jenkins має папку з даними, а самі контейнери нам не потрібні. Якщо говоримо про перенесення джоб, то вони лежать в іншій папці, і Docker нам не потрібен. Можна додати ще один volume: у ньому будуть дані Jenkins, і його можна мігрувати.
👍5
Ось воно, під’їхало цікавеньке! terraform-aws-s3-bucket ー модуль Terraform, що свторює S3 на AWS з майже усіма фічами від Terraform AWS.
🔥4
Чи встигли ви вже познайомитись з Grafana LOKI, новою системою збирання логів, яка пасує до всього (комп'ютери, хости, Docker-системи, кластери Kubernetes)? Якщо ні, радимо подивитись це відео та забрати цей тул собі до інструментарію. Автор досить непогано розказав, чому обрав саме цю систему для збирання логів.
👍4
Ще у далекому 2003 році Google привернули увагу до феномену Site Reliability Engineering (SRE). Компанія навіть випустила про це книгу, яка доступна широкому загалу. До речі, назва проста та одноймена ー Site Reliability Engineering. А ось у цій статті автор робить нам подорож до світу ієрархії SRE Google ー досить непоганий розбір, вартий уваги. Спойлер: є цікаві малюнки.
👍3
#devopsспитав_devopsвідповів
Як правильно видалити файл у Terraform?

У Terraform усі ресурси необхідно логічно розбивати по файлах. Найголовніше – ніколи не використовувати команду terraform destroy. Вона повністю знищує ресурси, описані в state.
👍4
mutagen 🔥
Інструмент для швидкої синхронізації файлів та перенаправлення мережі для віддаленого управління
👍2
🔥 Ми всі любимо Git та безмежно дякуємо Лінусу Торвальду за цей геніальний витвір. Але ж навіть найкраще можна покращити, принаймні, спробувати. У статті авторка надає 15 нетипових порад щодо роботи з цією системо.
👍31🔥1
💥 Корисне для моніторингу кластерів Kubernetes через Grafana ー grafana-dashboards-kubernetes. Набір сучасних дашбордів для роботи з кластерами.
👍5
#devopsспитав_devopsвідповів
Навіщо використовують Terraform remote_state? 🤔

Remote_state зазвичай використовують, коли в команді більше однієї людини, і в цілому він відмінно підходить для великих команд, які працюють з work spaces.

Якщо вас мінімум двоє, потрібно постійно корелювати та робити commit state у Git. Це завжди відбувається у два етапи – спочатку робимо pull request, після цього – state. Remote_state можна зберігати у таких базах даних як RDS, MongoDB, PostgreSQL та інших. Якщо ви зберігаєте в Amazon Simple Storage Service (S3), буде потрібна опція, яка відповідає за локи, наприклад, DynamoDB. Тут все зберігатиметься в одному місці – локи реалізовуватимуться як транзакція.
👍4
Перехід до крос-функціональних продуктових команд зазвичай може викликати проблеми з розподілом навантаження між інженерними департаментами. Ця проблема та пропозиції щодо її розв’язання вже була описана у книзі Team Topologies (Matthew Skelton and Manuel Pais).

Пропонуємо до прочитання блог, в якому автори діляться своїм досвідом застосування практик Мет’ю Скелетона та Мануеля Пеіс на прикладі департаменту зі 150 програмних інженерів.