В чому різниця між системним адміністратором і системним інженером? Яким чином пов’язані DevOps і Agile? Як і для чого використовуються такі інструменти як Docker і Jenkins? Де шукати допомоги DevOps спеціалісту-початківцю і які ресурси читати? Розбираємося разом зі старшим системним інженером Віктором Вороніним.
Цього року Віктор відзначає професійний юбілей — 20 років роботи в ІТ-сфері. Зараз він працює старшим системним інженером у рязанському офісі ЕРАМ. А ще допомагає у професійному розвитку кільком спеціалістам компанії, виконуючи роль їх ресурсного менеджера, приймає участь в організації рязанського DevOps-ком’юніті та допомагає навчати спеціалістів-початківців у тренінг-центрі.
Про особливості роботи за методологією DevOps, специфіку входу до професії, завдання та інструменти системного інженера — в розповіді Віктора.
Завдання DevOps-інженерів
Devops-спеціалісти або просто Devops-и, як найчастіше нас називають, беруть участь майже у всіх стадіях життєвого циклу продукту, починаючи з розробки. DevOps — це не назва посади, а методологія. Ідея, покладена в її основу — скоротити час, за який програмний продукт потрапить до кінцевого користувача. Так що всі програмісти, які розробляють програмний продукт, певною мірою DevOps-інженери.
Коли в проект заходять розробники і починають писати програму, вони радяться з Devops-ами про те, в якому середовищі працюватиме код. DevOps-інженери надають цю інформацію та коригують моменти, пов’язані з конкретною специфікою середовища. Після того, як робота програміста завершена, і код написано, Devops має довести його до клієнта: організувати компіляцію, збирання, тестування, розгортання в тестових середовищах. У цій частині роботи спеціаліст заглиблюється в процеси ручного і автоматизованого тестування. Таким чином, Devops приймає участь в усіх стадіях життєвого циклу проекту і знає трохи більше за інших учасників.
А ще в спеціальності багато програмування. До завдань Devops-інженера входить написання великої кількості коду. Але цей код пишеться не на класичних мовах, а на скриптових, наприклад Python, GoLang або Bash.
Ролі спеціалістів у середовищі DevOps
DevOps — це поєднання слів Development and Operations, розробка і функціонування. Відповідно, Devops-спеціаліст може мати нахил до підтримки розробки. В цьому випадку він забезпечує розробникам інформацію щодо платформи: компіляцію, збирання продукту, тестування і так далі. А є спеціалісти з нахилом в Operations, тобто, в роботу самого продукту. Вони відповідають за розгортання продукту в різноманітних середовищах, стабільність роботи, наявність необхідних ресурсів для роботи додатку. Проте в компанії цей розподіл не зафіксовано офіційно, керівники просто знають, хто до чого тяжіє. Взагалі, передбачається, що Devops має однаково орієнтуватися в обох сферах.
Різниця між системним адміністратором і системним інженером
Щоб з’ясувати, чому системний адміністратор — не системний інженер, потрібно уточнити звідки беруться DevOps-и. Якщо відкрити Google і пошукати ІТ-курси, то більшість з них буде пов’язано з розробкою або тестуванням. Курси DevOps зараз знайти можна, але вони будуть у меншості, а десь 2 роки тому їх практично не було. Навчання повноцінного, серйозного Devops-спеціаліста — складна задача. Правильно буде сказати, що кращі DevOps-інженери виходять або з системних адміністраторів, яких цікавить програмування і застосування автоматизації до задач, або з програмістів, які не тільки писали код, але й намагалися налаштувати середовище, щоб він правильно працював. Тому більшість системних інженерів, враховуючи, що це молодий напрямок, прийшли з системних адміністраторів і програмістів.
Про поєднання методологій DevOps та Agile на проекті
DevOps і Agile пов’язує те, що їх часто використовують разом. Самі по собі вони різні, тому можуть існувати й окремо одна від одної. Мета Agile — це поступове впровадження змін, розподіл процесу розробки на невеликі етапи. За результатами кожного з етапів раз на два-три тижні ми отримуємо код, який може бути доставлено клієнту. А DevOps створена для того, щоб максимально швидко доставляти код. Код можна впроваджувати за Agile-методологією без DevOps або в DevOps.
Застосування DevOps-методології в робочому процесі стає важливим, коли зростає кількість розробників на проекті та його трудомісткість. Якщо ти єдиний розробник і зберігаєш код правильно, знаєш, де і які зміни внесені, то можеш спокійно його розробляти і продавати без DevOps. Тут DevOps впроваджувати зарано і понадміру. Але у великій команді працюють десятки розробників і десятки тестувальників. В такому випадку без DevOps буде складно, тому що є велика кількість середовищ. Код краще розробляти так, щоб зміни різних розробників не конфліктувати і проходили максимально швидко чи максимально ефективним шляхом.
CI/CD як частина DevOps
CI/CD — це концепції DevOps, які розшифровуються як Continuous Integration і Continuous Delivery.
Continuous Integration полягає в тому, що зміни, які розробники вносять в код, повинні якомога частіше потрапляти в загальний репозиторій. В такому режимі командам максимально зручно працювати. Розробник відразу бачить зміни, зроблені колегами і відповідно до них коригує чи розробляє свій код. За ідеальною методологією СІ розробники розміщують частину написаного коду раз на день — це вважається необхідним мінімумом. Але в реальності можливі різні варіанти: як 30 раз на день, так і раз на тиждень. Останні 2 роки на моєму проекті СІ побудовано не за класичною схемою. Я міг коммітити код в репозиторії до 10 разів на день і більше. Це відбувалося у відокремлених гілках[YY(1] і розділених задачах. Кожні мої 20 коммітів на день призводили до компіляції, тестування та отримання результату про те, наскільки код нормальний.
Continuous Delivery — це друга частина процесу, доставка коду клієнту у вигляді працюючого додатку. В ідеальній DevOps-структурі вважається, що протестована частина коду відразу потрапляє до клієнта на робочий додаток. Я пока не зустрічав подібного на практиці, але, кажуть, що такі гіганти, як Netflix, саме так і працюють.
Розповідаючи про CI/CD, також важливо окремо згадати Pipeline. В перекладі це слово означає «труба» або «трубопровід». У Devops-світі так називають процес, за яким обробляється ПЗ, якраз, щоб пройти CI-цикл або CD-цикл. Наприклад, розробник пише Java-додаток. Під час перевірки його працездатності, додаток компілюється, проходить модульні тести, збирається, запускається і автотестується — так виглядає СІ-цикл для цього додатку. Ці операції збираються і кожна являє собою окремий крок Pipeline-у. А разом вони становлять своєрідну трубу, через яку «пролетів» додаток. Якщо на одній зі стадій виникла проблема, ми це побачимо. Якщо додаток пройшов весь Pipeline, то він вважається робочим.
Контейнеризація, віртуалізація та Docker
Віртуалізація, контейнерізація та Docker скорочують накладні витрати на запуск додатку, що допомагає відмовитися, приміром, від різних операційних систем.
Контейнер — це механізм, який дозволяє використовувати максимальну частину техніки для запуску конкретних додатків, а не для обслуговування операційних систем чи чогось подібного. Він являє собою легковагу структуру, яка містить в собі додатки і системні бібліотеки. Зробивши віртуальним фізичний сервер, на якому працює один додаток, можна одночасно запустити 10. Якщо встановити там ще й Docker, то максимальна кількість збільшиться до 20. Контейнери гарно поєднуються з DevOps, оскільки оновити додаток «безшовно» для клієнта набагато простіше, ніж на фізичному сервері. Зараз величезна кількість програм, наприклад Gmail, так працює, а користувачі про це навіть не здогадуються.
Docker — найбільш популярний, проте не единий засіб для запуску додатків у контейнерах. Це програмне забезпечення більше підходить для роботи з операційною системою Linuх. Повноцінний Docker під Windows ще розробляється, і в якості продукту для широкого загалу поки не доступний. Тому, поки що, спеціаліст, який знає Linux має більше можливостей, ніж DevOps, який знає тільки Windows.
Застосування Jenkins в Devops-інфраструктурі
DevOps-інфраструктуру часто будують навколо центрального компоненту, який забезпечує CI/CD-процеси. Таким систем безліч, але найпопулярніша з них —Jenkins. Це один з найстаріших інструментів, тому для нього вже існує велика кількість плагінів. Оскільки він безплатний, DevOps-початківець може ним користуватися без обмежень, саме тому більшість новачків у DevOps бачили або знають, що таке Jenkins. Недолік цієї безкоштовної системи в тому, що немає кому висунути претензії, якщо вона працює погано — доводиться шукати рішення проблеми самостійно. З цієї причини в Jenkins і з’явилися платні конкуренти, які надать підтримку. Практично всі великі гравці ІТ ринку пропонують подібні програми: TeamCity, GitLab CI, Bitbucket CI, Azure CI, AWS CI.
DevOps-інфраструктура працює, як конструктор. В Jenkins багато інструментів для тестування, збирання, перевірки коду. Для зберігання вихідного коду до Jenkins можна додати GitLab, а можна і власний Git-сервер. Потім потрібно обрати збиральник. Можна запускати його на Jenkins, прикрутити до нього виконавці, на яких проходитиме збирання. Далі знадобиться сховище для артефактів, тобто того, що вийшло в результаті збирання коду. При збиранні Java-додатку отримуємо JAR-файл, для Windows – exe-файл або dll. До Jenkins можливо також під’єднати Nexus або Artifactory, в які потраплять файли, отримані після збирання. Таким чином складається СІ-процес, з інструментів, які зручніші в користуванні.
Про складні завдання і пошук рішень
Останній складний кейс на проекті виник буквально 3 тижні тому, коли мені потрібно було пристосувати для Azure open-source рішення, яке було реалізовано для хмарного провайдера AWS. Я адаптував його, що допомогло команді з розгортанням середовища і одночасним запуском 150 серверів у хмарі Microsoft Azure. Завдяки цьому час запуску скоротився з 4,5 годин до 30 хвилин.
В нестандартних ситуаціях в ЕРАМ допомогає система юнітів, підрозділів. Тобто, ми намагаємося об’єднувати в підрозділи співробітників з однаковою експертизою. DevOps-и спілкуються один з одним, і більш досвідчені працівники допомагають новачкам, як ресурсні менеджери. Перша людина, до якої можна прийти — це колега в юніті. Далі слід звернутися до DevOps-практики — це всі DevOps-и в EPAM в країні. Якщо й там ніхто не зміг допомогти, можна піти в центр компетенцій DevOps — це об’єднання DevOps-ів EPAM у всьому світі.
Якщо говорити про спеціаліста-початківця, який поки в нашій компанії не працює, але хоче бути DevOps-інженером, то можна проконсультуватися на форумах, наприклад, спитати поради на GitHub або GitLab. Проекти, які викладають на цих сайтах, доступні будь-якому зареєстрованому користувачу. Там є розділ «проблеми», куди можна написати і отримати рішення або обговорити завдання з іншими людьми. Ми часто так робимо, звертаючись на цьому ресурсі до тих, хто володіє найбільшим досвідом. Такого поняття, як глобальне DevOps-ком’юніті немає, але часто ПЗ розробляє велика кількість ентузіастів, які готові безкоштовно відповідати на питання на GitHub чи інших форумах.
Ресурси для DevOps інженерів-початківців
Спочатку DevOps інженер-початківець може сміливо заходити на такий ресурс, як Habr і читати там DevOps-розділ. Потім варто пошукати навчальні відео на YouTube. З гарним анлійським можна користуватися такими ресурсами, як PluralSight і Linux Academy. Враховуючи те, що DevOps складається з великої кількості проектів з відкритим кодом, шукайте інформацію у вигляді подкастів та статтей. Основна частина з них, звичайно, англійською, але й російською теж багато матеріалів. Також можна пройтися по великим гравцям (Microsoft, Google, Oracle) і подивитися, що є у них. Компанія Microsoft нещодавно зрозуміла, що людей потрібно навчати користуватися своїми продуктами і зробила багато тренінгів. З Azure Cloud матеріали безкоштовні та доступні російською і англійською мовами. Якщо раніше компанії просили за тренінги чималі гроші, то зараз вони існують у вільному доступі, тому що конкуренція стала високою, і потрібно активно залучати людей до свого продукту.
Підсумовуючи, починайте з Хабру і YouTube. Обирайте цікаві матеріали з DevOps і читайте все, що є в них за посиланнями. Дивіться відео, які викладають офіційні джерела і DevOps-ентузіасти.
