Вживання російської мови може призвести до катастрофічних наслідків, радимо переходити на українську.

Как работает TuchaKube — первая украинская DevOps/Hosting-платформа

  1. Главная
  2. Блог
  3. Облачные сервисы
  4. Как работает TuchaKube — первая украинская DevOps/Hosting-платформа
Категории

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

Как автоматизируются 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, который тоже принадлежит клиенту.

Docker-контейнер

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

Docker Registry

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

После того как контейнер собран, происходит доставка его в 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. Запросы не поступают.

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

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

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

Ситуация 2. Даем один поток запросов.


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

Нагрузка начинает расти. Поскольку этот показатель измеряется 1 раз в 5 минут, на самом деле он растет не так постепенно, как отображает график, а немного быстрее.

Итак, после того как увеличилось количество запросов в секунду, приложение начало прорабатывать эти запросы. Встроенный сервер метрик показывает определенное количество времени, необходимое для обработки одного запроса.

Ситуация 3. Даем еще один поток запросов.


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

Нагрузка начинает расти, и система это отслеживает. Также она видит, что количество запросов в секунду увеличилось. Теперь система запускает второй контейнер (красные столбики на графике).

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

Ситуация 4. Даем большее количество запросов.


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

Продолжаем добавлять третий поток запросов. Система наблюдает, что нагрузка растет, и запускает еще один контейнер. Возросло количество запросов в секунду. При этом снова на небольшое время возросла задержка, но затем ее показатель снова снизился.

Продовжуємо додавати третій потік запитів

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

Ситуация 5. Выключаем все запросы.

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

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

Ситуация 6. А если включить сразу все 4 потока запросов?

Такую процедуру тоже можно выполнить. Платформа обработает их точно так же: сначала немного возрастут показатели нагрузки, но система сразу заметит это и быстро запустит все 4 контейнера.

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

Вот так происходит горизонтальное масштабирование, которое можно мониторить.

Несколько слов о базах данных

В основном базы данных у нас являются отдельными кластерами, которые работают вне Kubernetes на отдельных серверах, — виртуальных или физических. Но между ними и приложением есть кольцо из прокси-контейнеров, которые выполняют роль балансировщиков запросов между приложением заказчика и кластером баз данных. Базы данных могут быть разными.

Декілька слів про бази даних

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

Несколько слов о технической поддержке

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

Несмотря на то, что служба поддержки Tucha работает по достаточно жесткому регламенту, главное для нас — полное удовлетворение клиента услугами, которые он заказывает. Поэтому мы внимательно и ответственно относимся к задачам заказчиков и действительно заинтересованы в их быстром и добросовестном решении. Это одно из главных свойств нашей службы технической поддержки, которая позволяет приносить клиентам максимум пользы от сотрудничества.

Итоги

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

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

Если у вас есть веб-проект, который уже работает и для которого были бы полезны возможности платформы, приглашаем к ее тестированию! А если вы хотите узнать больше о сервисе или у вас есть реальные задачи для нас, звоните по телефону +380 44 583-5-583 или пишите по электронному адресу support@tucha.ua. Мы всегда на связи, готовы ответить на ваши вопросы и подобрать наилучшее облачное решение. Обращайтесь!

Поделиться:
Статьи по теме

Друзья, если вы разрабатываете собственные веб-приложения, функционал и код которых постоянно меняется, сервис TuchaKube обязательно вам пригодится.

Отныне всем пользователям доступна услуга по запуску приложений в облаке контейнеров от Tucha. Эту возможность реализует платформа TuchaKube, что ...

Приглашаем на вебинар Встречайте важную новость! До недавнего времени услуга контейнерной инфраструктуры от Tucha.ua была доступна ...

Я — Владимир Мельник, технический директор Tucha. Хочу поделиться современным подходом к созданию безопасной работы онлайн-сервисов, а именно ...

Серия вебинаров о функционале сервиса предоставления контейнерной инфраструктуры и автоматизации CI/CD-процессов TuchaKube продолжается. Так, 11 октября 2019 состоялся ...

Закрыть
Заказать обратный звонок

Пожалуйста, проверьте правильность заполнения поля с номером телефона

Поля обязательные для заполнения.

Мы используем cookies.

Мы используем файлы cookies, чтобы обеспечить основные функциональные возможности на нашем сайте и собирать данные о том, как посетители взаимодействуют с нашим сайтом, продуктами и услугами. Нажимая Принять или продолжая использовать этот сайт, вы соглашаетесь с тем, что мы используем эти инструменты для рекламы и аналитики согласно «Политике про файлы сookies»

ПринятьОтказаться