Що треба знати Software Engineer з DevOps-інструментів
Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!
Автори статті: Микола Орлов, Head of DevOps office у компанії ELEKS. Понад 14 років досвіду в IT-сфері, зокрема робота з проєктами в банківській сфері, e-commerce, health care, мультимедіа тощо. У резюме успішні сетапи інфраструктури з нуля та управління девопс-командами різних розмірів.
Станіслав Міщишин, Senior Software Engineer у компанії ELEKS, де працює на одному з проєктів як Back-end Node.js Developer, брав участь у багатьох Devops-задачах на проєкті.
Якщо проєкт стартує без DevOps-спеціаліста, то найчастіше його завдання виконує інженер. Ця стаття про те, які DevOps-завдання вирішує девелопер, які речі є критичними для становлення проєкту і на що потрібно звернути особливу увагу, які тулзи потрібно знати, щоб впроваджувати девопс-методологію на проєкті. А також про низку практик, які потрібно підучити програмісту, щоб стати конкурентним на ринку, підвищити ефективність робочих процесів чи якість продукту.
Цей матеріал буде корисним також для тих розробників, які хочуть спробувати займатись DevOps-задачами на проєкті.
Ілюстрація Анастасії Авдєєвої
Коли розробник виконує DevOps-роботу
Коли проєкт занадто малий для залучення повноцінного девопса або всі девопси зайняті іншими задачами, девелопер виконує його функції. Спершу — це конфігурація локального розгортання проєкту: вибір інструментів, їх конфігурація, написання скриптів.
У 2017 році ми запустили проєкт, на який було виділено три девелопери. Проєкт був на стадії PoC, і у нас не було девопса. Нам було необхідно засетапити деякі критичні для девелопменту процеси, наприклад Gitflow, базову конфігурацію локального середовища.
Пізніше до проєкту долучились тестери, і потрібно було зробити процеси для розгортання продукту на ремоутний сервер. Для цього ми використали локальний Jenkins, написали декілька пайплайнів для збирання контейнерів (проєкт був базований на докері, тому також провели роботу з написання базових докер-файлів), підняли декілька віртуальних машин для тестування і створили ще пайплайн для, власне, самого деплойменту.
Цей підхід був дещо примітивний, але успішно пропрацював до залучення професійного девопса на проєкт.
Загалом для initial project setup необхідними знаннями буде, наприклад, docker/docker-compose, bash scripts, vagrant, etc. Інструменти можуть бути загально вживаними (наприклад, docker) або специфічні до стеку проєкту (npm, maven, ant gradle, webpack).
Наступною фазою може бути впровадження VCS version control system, вибір Gitflow, інтеграція зі встановленими SDLC-процесами на проєкті. Наприклад, введення policies на VCS-провайдері щодо обмежень на мержу процесу перегляду пулу запитів.
Налаштування CI/CD
Під час активного розвитку і масштабування проєкту важливим є етап continious integration/continious deployment. Особливо коли потрібно автоматизувати SDLC-процеси.
Ще один кейс — відточення
На наших проєктах CI, як правило, охоплює налаштування інструментів для перевірки і вимірювання метрик code quality (наприклад, використовуючи SonarQube), юніт-тести, code coverage, створення і пабліш білд-артефактів.
Коли на проєкті є Automation QA, їм також може бути необхідна підтримка з DevOps-питань, наприклад, щодо інтеграції з інфраструктурою.
Над CI зазвичай працюють і девелопери, і девопси. Розробка continuous integration flows на проєкті відбувається постійно, оскільки будь-які зміни вимагають і зміни
Створення ремоутного середовища
Створення ремоутного середовища критично важливе завдання на початковій стадії проєкту. Його зазвичай виконує девопс, але якщо на проєкті його немає, то це завдання розробників.
Трапляється, що середовище створюють вручну, без застосування автоматизованих скриптів, тоді існує велика ймовірність, що у майбутньому будуть складнощі з правильною побудовою deployment-процесів.
Інструменти можна обирати для цих процесів будь-які, зважаючи на проєкт та побажання клієнта: cloud або on-premise solution, віртуальна машина або лямбда-сервіси.
Найбільш поширеними cloud-провайдерами є AWS, Azure, GCP. Також є проєкти, які повністю побудовані на cloud-технологіях, тому навіть розробникам необхідно орієнтуватися, як це працює на ремоуті і як розгорнути це локально.
Для автоматизованого деплою є широкий вибір інструментів для різних цілей: Terraform, Helm, Ansible playbooks, Chef, Puppet.
Часто необхідно вносити зміну в наявні схеми деплою. Найпоширенішим кейсом є додавання/зміна environment variables.
Ще одне девопс-завдання, яке часто виконує девелопер — конфігурація вебсервера (NGINX, Apache, IIS). Це актуально для вебпроєктів, зокрема, фронтендщикам. Натомість для бекенд-розробників актуальна конфігурація вебсервера як реверс-проксі, якщо, наприклад, використовується Kubernetes — це інгрес. Також можна використовувати і cloud specific solution.
Нерідко виникають задачі, які містять конфігурацію NGINX — наприклад, конфігурації кешування, роутингу, інші параметри.
Фейли на проєкті, коли не було девопса
Якщо на проєкті немає девопса, його задачі часто падають на девелоперів як на «технічних» людей, які «гіпотетично можуть замінити девопса». Звичайно, усе залежить від проєктних знань і конкретних хардскілів розробника, який виконуватиме цю роботу.
Але проблема у тому, що розробник не завжди бачить картину проєкту повністю, а у його зоні відповідальності, до якої він звик, — конкретний функціонал. А тут ще додається інфраструктура, CI/CD тощо.
Звісно, є ризик, що він чогось не враховує чи не побачить, чогось не знає. Тоді найкраще радитись з архітектором.
У випадках, коли проєкт стартує без девопса, трапляються спроби вирішити поточні таски «тут і зараз»: «зробити щонайскоріше, а далі розберемося». Так цілей, можливо, і досягають швидко, але стратегічно це призводить до проблем із залежностями у майбутньому. Це очікувано: рішення, які робляться «на коліні» складно масштабувати.
Хороший DevOps-спеціаліст має у своєму арсеналі кілька варіантів вирішення тої чи іншої задачі та пропонує найоптимальніший з них, зваживши всі плюси й мінуси реалізацій. Розробники не завжди мають достатню широту знань, щоб вибирати з-поміж кількох оптимальний шлях для досягнення мети.
Девопс має бути таким собі «цементувальним елементом» у команді, тією людиною, яка має знання різних девелоперів і інженерів якості. Мета девопса — скоротити час виходу продукту на ринок, знизити частоту відмов нових релізів, підвищити продуктивність та ефективність.
Чим займається Head of DevOps office
До мене, як правило, надходять запити на навчання чи тренінги від цілих проєктів або від інженерів, які хочуть змінити напрям кар’єри та перейти в наш офіс.
Запити від проєктів можна розділити на два види. Перший — це випадки, коли на проєкті DevOps-задачі загалом закриті й необхідні речі вже налаштовані, а сам продукт потребує мінімальних покращень чи не дуже глобальних змін. Скоупа на повноцінного девопса немає, а час на долучення нової людини до проєкту, її «розкачку» і навчання є невиправдано великим.
Або ж навпаки (другий випадок), якщо на проєкті задач стає дедалі більше і команда бачить потенціал в ефективному девелопменті, естимації та плануванні, в обізнаності з девопс-інструментами.
В обох кейсах запити, як правило, дуже конкретні і ми їх можемо закрити відносно швидко. Основне завдання — зрозуміти, які задачі в інженерів і як їм можна допомогти з навчанням, потребу, створити план і якнайшвидше взятися до його імплементації.
Одного разу був кейс, коли один з проєктів потребував підвищення рівня кваліфікації працівників в ІІS + Windows administration. Інші були зацікавлені у тому, щоб команда отримала курс і прокачування скілів з Active Directory. Треті намагались оптимізувати Jenkins CI/CD пайплайни тощо.
Запити всі доволі різні, проте в усіх випадках вирішенням був аналіз поточної потреби, складання списку інструментів, в яких потрібно прокачатись, а потім викристалізовувався список лекцій, практикумів, які необхідно провести.
Так, менеджер проєкту може створити реквест на кшталт «отримати курси з інфраструктури як код, з конфігураційного менеджменту та оркестрації контейнерів... та й загалом по всьому», а вишенькою на торті додати коментар «і бажано в стислі терміни». Але й тоді я намагаюсь з’ясувати, які задачі ставлять менеджери перед своїми командами, і здебільшого з’ясовується, що в таких випадках обсяги робіт досить великі. Тоді ми пропонуємо повноцінного девопс-спеціаліста на проєкт.
З персональними реквестами від працівників, коли, до прикладу, спеціалісти з інших департаментів хочуть перейти у девопс-офіс, працюють дещо інші механізми. Насамперед з такими інженерами ми проводимо оцінку їхніх поточних знань, виявляємо білі плями, критичні технології чи знання, які відсутні і які необхідно закрити, щоб відповідати девопс-позиції певного рівня. Далі розробляємо план навчання. За потреби надаємо ментора, який навчає і може допомогти, коли виникають труднощі. Тоді це вже не точкове вирішення конкретної проблеми, а ціль зробити так, аби новий девопс-інженер відповідав своїй позиції за знаннями і навичками. В цій ситуації топіки, які перевіряємо, є стандартні та охоплюють:
- Знання операційних систем.
- Знання мережевих технологій.
- Конфігураційний менеджмент і IaC.
- Віртуалізація.
- Контейнеризація.
- Скриптинг.
- Моніторинг і логування.
- CI/CD.
Висновок
Звісно, для виконання проєктних девопс-задач потрібно мати девопс-спеціаліста, оскільки він має необхідні знання і навички та може справитись із завданнями швидко і якісно або запропонувати хороші альтернативні рішення. Але ми живемо в реальному світі, де часом це неможливо, і якщо девелопер володітиме потрібним функціоналом, він може впоратися з тими чи іншими девопс-задачами.
А все-таки є необхідність отримати базові скіли з DevOps-сфери для розробника незалежно від того, є на проєкті девопс чи ні.
- Для більш якісного і швидкого девелопменту.
- Для можливості побудови складних частин, які містять development i DevOps.
- Для кращого розуміння проєкту.
- Для вирішення задач різноманітними інструментами.
32 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів