Як працює TuchaKube — перша українська DevOps/Hosting-платформа

Продовжуємо знайомитися з потужними можливостями сервісу TuchaKube та особливостями її роботи. У попередній статті ми писали про те, як виникла ідея створити платформу для автоматизації CI/CD-процесів, хостингу додатків та їх даних у хмарі контейнерів, а також з чого вона складається та які задачі вирішує. Наразі розповідаємо та показуємо, як саме працює інноваційне рішення.

Процес автоматизації CI/CD-процесів здійснюється за певними напрацьованими нами шаблонами, які є гнучкими та можуть налаштовуватися під потреби конкретного замовника.

Крок 1. Розробник спочатку робить commit в локальний git-репозиторій, а потім — push у віддалений git-репозиторій в окремому GitLab, що надається клієнту. Ця дія і є тригером для початку процесу збірки, якщо не задані інші параметри. Якщо ж у розробника немає прав деплоїти у поточну гілку, тоді розробник здійснює merge request, котрий обробляється тим, хто має такі права.

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

Крок 2. Далі автоматично створюються контейнери на базі наших Docker-файлів. Оскільки ми вже маємо певну накопичену бібліотеку стандартних Docker-файлів, для використання у роботі вони потребують найменшого доопрацювання.

Створення контейнерів обумовлене безпосереднім функціонуванням платформи: вона потребує того, щоб всі додатки та компоненти програмного забезпечення замовника виконувалися саме у контейнерах.

Контейнер пушиться в який-небудь репозиторій — локальний (наприклад, репозиторій контейнерів у наданого клієнтові GitLab) або віддалений (наприклад, Docker Hub або будь-який інший docker registry).

Крок 3. Після цього виконується тестування. Це означає, що система в одному із «закуточків» хмари запускає один або декілька контейнерів та виконує з ними те, що прописано розробником у програмі автоматичного тестування. Зазначимо, що алгоритми складаються виключно замовниками (власноруч або за допомогою QA-інженерів).

Крок 4. Далі відбувається процес видалення зайвих даних. В окремих випадках відбувається перекомпіляція. Також після цього іноді ще раз виконується тестування.

Крок 5. Наступний крок — доставка нової версії бепосередньо у staging-середовище. Цей процес відбувається так: спочатку запускаються контейнери з новою версією. Потім, коли система переконалася у тому, що контейнери запрацювали належним чином (зазвичай виконуються так звані readiness probes, які дозволяють визначити, чи коректно Pod відповідає на запити), вона перемикає трафік на нові контейнери, а старі поступово вимикає.

Таким чином, відбувається автоматичне оновлення в staging-середовищі.

1.    Замовник робить певний коміт.

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

Інакше кажучи, як тільки замовник зробить коміт, що відповідає певним заданим критеріям (вони визначаються DevOps-інженером в конфігураційному файлі CI/CD-процесів конкретного проєкту), одразу будуть автоматично виконуватися дії в декілька етапів. Ці етапи задаються нами на базі побажань замовника:

1)    Збірка (компіляція) проєкту.

Проєкт компілюється таким чином, щоб спочатку можна було подивитися, чи є певні закешовані з попередньої компіляції бібліотеки, які можуть нам стати у пригоді, адже компіляція (як і всі подальші процеси) відбуваються в окремих контейнерах. Оскільки контейнер є «чистою» системою, всередині якої ще нічого немає, при виконанні кожного кроку він бере з нашого локального S3-сумісного сховища ті дані, які збереглися з попередніх відпрацьовувань. Цей процес необхідний тому, що проєкту, який буде компілюватися, необхідно зібрати велику кількість бібліотек та розподіли їх. Таким чином, робочі дані та бібліотеки зберігаються у S3-сумісному сховищі для того, щоб потім можна було їх використовувати. 

Окрім цього, також зберігаються артефакти (будь-які файли, які розробник хоче зберегти після збірки), котрі потім ми можемо використовувати для роботи.

У сховищі артефактів є можливість зазирнути до артефактів для кожного окремого білда та подивитися, що лежить у сховищі артефактів для кожного окремого ідентифікатора. Кожен коміт містить свій унікальний ідентифікатор.

2)    Тестування.

Цей процес також відбувається із зазначенням унікального ідентифікатора. Так само відбувається відновлення артефактів (важливо) та відновлення робочих даних (не завжди є необхідним).

Після того, як відбулося автоматичне тестування, настає час для повторного збереження робочих даних, якщо у цьому є потреба. Зазначимо, що після тестування артефакти зазвичай не змінюються.

3)    Контейнеризація.

З тим самим ідентифікатором ми збираємо контейнер на базі Docker-файлу, який створили для компоненту цього проєкту.

Зібраний Docker-контейнер зберігається у нашому локальному сховищі, Docker Registry, який теж належить клієнту.

Замовник може зазирнути до нього та подивитися, які контейнери існують, які версії вони мають та що міститься всередині, а також видалити деякі дані, якщо це потрібно. Також можна задавати алгоритми автоматичного видалення (зазвичай дані зберігаються впродовж 14 діб).

4)    Доставка контейнеру в staging-середовище.

Після того, як контейнер зібрано, відбувається доставка його в staging-середовище. Рекомендуємо все ж спочатку виконати ці дії у staging-середовищі, для того щоб за окремою адресою особисто переконатися, як працює нова версія.

Далі зазвичай створюється деплоймент маніфест для Kubernetes, який теж містить у собі ідентифікатор цього коміту (водночас це й ідентифікатор Docker-образу, який потім буде використовуватися).

Тобто автоматично створюється маніфест, який має в собі цей ідентифікатор. Реквізити доступу, необхідні для авторизації у сховищі, зазвичай зберігаються всередині Kubernetes-кластеру у вигляді спеціальних сутностей під назвою «secret».

Далі все це деплоїться в staging-середовище як окрема версія того самого деплойменту, але з оновленими контейнерами всередині Pod.

Спочатку здійснюється запуск Pod-ів із контейнерами в потрібній кількості у Kubernetes-кластері, але трафік на них не постачається. Трафік починає надходити до них тоді, коли Kubernetes переконається в тому, що цей трафік буде оброблятися коректно. Тобто він робить тестування: наприклад, перевіряє доступність додатку всередині по порту, на якому він працює. Якщо реакція буде такою, на яку очікується, Kubernetes починає перемикати на нього трафік.

5)    Оновлення у production-середовище.

Цей етап відбувається після того, як ми переконалися, що у staging-середовищі все працює належним чином, а QA-команда обробила свої алгоритми з мануального тестування та задовільнилася результатами.

Під час оновлення у production-середовище відбувається та ж дія, що і під час доставки контейнеру в staging-середовище, — виконується merge в гілку, яка є майстер-гілкою або однією з них. Є лише одна невелика різниця: виконання фінального етапу здійснюється у ручному режимі. Тобто після того, як розробник або інші уповноважена особа переконається, що все добре працює у staging-середовищі, він просто запускає цей етап натисканням кнопки Play у пайплайнах. Тобто завершальна дія виконується вручну, а не автоматично.

Для можливості здійснення моніторингу та горизонтального масштабування нам потрібно було забезпечити збір різноманітних даних: як від додатку, котрий розробляє замовник, так і від системи Kubernetes. Зазвичай через Metrics-сервер це потрапляє в Prometheus, і той вже зберігає інформацію про всі метрики. Надалі користувач може переглядати їх за допомогою Grafana.

Розглянемо на прикладі конкретного додатку.

Ситуація 1. Запити не надходять.

Ми вивели на Grafana 3 метрики, які моніторяться у платформі TuchaKube:

1. завантаження центрального процесору (блакитні стовпчики);
2. кількість запитів у секунду, що надходять на цей сервіс (жовті стовпчики);
3. затримка, яка виникає під час обробки одного запиту (зелені стовпчики).

Ситуація 2. Надаємо один потік запитів.

Навантаження починає зростати. Оскільки цей показник вимірюється 1 раз на 5 хвилин, насправді воно зростає не так поступово, як відображає графік, а трішки швидше.

Отож після того, як збільшилась кількість запитів на секунду, додаток почав опрацьовувати ці запити. Вбудований сервер метрик демонструє певну кількість часу, яка потрібна для обробки одного запиту.

Ситуація 3. Надаємо ще один потік запитів.

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

Розглянемо цей процес детальніше. Спочатку відбулося ось що: затримка для відпрацьовування одного запиту трішки зросла, але це одразу було збалансовано завдяки ще одному контейнеру, який запустився.

Ситуація 4. Надаємо більшу кількість потоків запитів.

Продовжуємо додавати третій потік запитів. Система спостерігає, що навантаження зростає, і запускає ще один контейнер. Зросла кількість запитів на секунду. При цьому знову на невеликий час зросла затримка, але потім її показник знову знизився.

Четвертий потік запитів система «переживає» так само чудово, адже при цьому знову запустився контейнер. Спочатку показники затримки трішки зросли, але потім вони знову дійшли до потрібного нам рівня.

Ситуація 5. Вимикаємо всі запити.

Після того, як ми вимикнули всі запити (це задається окремими налаштуваннями), бачимо, що навантаження впало. Далі зайві контейнери видаються з Kubernetes для того, аби не створювалося додаткове навантаження для клієнтів та не відбувалася тарифікація за ті ресурси, які клієнту не потрібні.

Ситуація 6. А якщо увімнкути одразу всі 4 потоки запитів?

Таку процедуру теж можна виконати. Платформа обробить їх так само: спочатку трішки зростуть показники навантаження, але система одразу помітить це та швидко запустить всі 4 контейнери. 

Ось так відбувається горизонтальне масштабування, яке можна моніторити.

Здебільшого бази даних у нас є окремими кластерами, які працюють поза Kubernetes на окремих серверах, — віртуальних або фізичних. Та між ними і додатком є кільце з проксі-контейнерів, які виконують роль балансувальників запитів між додатком замовника та кластером баз даних. Бази даних можуть бути різними.

Замовник може керувати базами даних, наприклад, за допомогою phpMyAdmin, якщо йдеться про MySQL-сумісні бази даних, які ми теж для нього встановлюємо та налаштовуємо. Зазвичай ми створюємо кластер серверів баз даних для забезпечення безперебійності та відмовостійкості.

Надійна технічна підтримка — важливий компонент платформи TuchaKube. Наша команда фахівців працює 24×7 і докладає всіх зусиль, аби кожен клієнт отримував якісний сервіс та кваліфіковану допомогу у вирішенні хмарних задач.

Попри те, що служба підтримки Tucha працює за доволі жорстким регламентом, головне для нас — цілковите задоволення клієнта послугами, які він замовляє. Саме тому ми уважно та відповідально ставимося до задач замовників і дійсно зацікавленні у їх швидкому та сумлінному вирішенні. Це одна з головних властивостей нашої служби технічної підтримки, яка дозволяє приносити клієнтам максимум користі від співпраці.

Платформа TuchaKube — інноваційне рішення, яке значно спрощує процеси розробки програмних продуктів, допомагає будувати високонавантажені ІТ-системи та автоматизувати CI/CD-процеси.

Унікальність сервісу полягає у поєданні одразу багатьох компонентів та купі потужних можливостей: горизонтальне масштабування, моніторинг, збирання та зберігання статистичних даних, кластеризація та інші. А головна перевага — це найкраща підтримка з боку досвідчених DevOps-інженерів Tucha.

Якщо у вас є вебпроєкт, який наразі працює та для якого були б корисні можливості платформи, запрошуємо до її тестування! А якщо ви бажаєте дізнатися більше про сервіс або маєте реальні задачі для нас, телефонуйте +380 44 583-5-583 або пишіть на електронну адресу support@tucha.ua. Ми завжди на зв’язку, готові відповісти на ваші запитання та підібрати найкраще хмарне рішення. Звертайтеся!