Введение: Five Brothers, профессиональная сервисная платформа для стальных изделий, совместно созданная China Minmetals и Alibaba, предоставляет конечным пользователям возможность совершать покупки в одном месте, объединяя преимущества Alibaba в области больших данных, платформы электронной коммерции и технологии интернет-продуктов. Эта статья посвящена исследованию и применению контейнерной технологии Docker в процессе непрерывной доставки технической группой по эксплуатации и обслуживанию Five Brothers.В настоящее время разрешение на выпуск и развертывание было открыто владельцу разработки приложений для достижения 7 * 24 «одна остановка» непрерывная доставка., общее улучшение потенциала доставки процесса НИОКР компании.
предисловие
Как стартап-компания и DevOps-инженер, мы столкнулись с такими проблемами:
-
Проблема использования аппаратных ресурсов приводит к потере некоторых затрат. Различные бизнес-сценарии в функциях веб-сайта включают вычисления, чтение и запись ввода-вывода, сеть и память. Централизованное развертывание приложений приведет к использованию ресурсов. Необоснованный вопрос. Например, все службы, развернутые на машине, интенсивно используют память, поэтому ресурсы ЦП легко тратятся впустую.
-
Несколько приложений на одном физическом компьютере не могут быть эффективно изолированы, что приводит к вытеснению приложений и взаимному влиянию на ресурсы. Запуск нескольких приложений на одном физическом компьютере не может ограничивать использование ЦП, памяти и процессов. Проблема вытеснения вызовет цепную реакцию и в конечном итоге привести к недоступности некоторых функций сайта.
-
Среда и управление версиями сложны, а процесс онлайн-развертывания отсутствует, что увеличивает сложность устранения неполадок.Из-за нерегулярности внутреннего процесса разработки некоторые элементы конфигурации и системные параметры произвольно настраиваются во время тестирования кода или онлайн-процесса. В случае возникновения проблемы тестируемый код будет несовместим с кодом, работающим в сети, что увеличивает риск перехода службы в режим «в сети» и затрудняет устранение неполадок онлайн-службы.
-
Среда нестабильна, стоимость миграции высока, а онлайн-риск повышен.В процессе разработки происходит параллельная разработка нескольких проектов и сервисных зависимостей.Из-за высокой сложности среды и версии невозможно быстро создавать и мигрировать среду, что приводит к невозможности тестирования среды Невозможно смоделировать онлайн-процесс для тестирования, и многие студенты тестируют в онлайн-среде, что сопряжено с высокими потенциальными рисками и снижает эффективность разработки.
-
Традиционные виртуальные машины и физические машины занимают много места, медленно запускаются и сложны в управлении Традиционные виртуальные машины и физические машины загружают ядро в процессе запуска, выполняют ядро и инициализацию, которые занимают много времени во время запуска процесса, а процесс управления занимает много времени.Возникнет множество проблем управления.
На основе контейнерной технологии Docker техническая группа по эксплуатации и техническому обслуживанию разработала контейнерную облачную платформу веб-сайта Wuage. 95 % сервисов приложений через облачную платформу контейнеров были развернуты в контейнерах. Эти приложения поддерживают расширение бизнеса по запросу, масштабируются за считанные секунды, обеспечивают удобный процесс взаимодействия, стандартизируют процесс выпуска тестирования и производства, освобождают студентов, занимающихся разработкой и тестированием, от настройки и выпуска базовой среды, а также позволяют им больше сосредоточиться на своих собственных задачах. Разработка и тестирование проекта.
В этой статье, объединяющей практику контейнерной облачной платформы WuAge и контейнерной технологии Docker, сначала рассказывается, как реализовать 7*24-часовую непрерывную доставку «одного окна» и реализовать запуск продукта. Для ознакомления с облачной платформой контейнеров, пожалуйста, следуйте: https://zhuanlan.zhihu.com/devops
Стандартизация образов Docker
Как мы все знаем, образы Docker многослойны. Примите соглашение о наслоении изображения:
-
Первый уровень — это уровень операционной системы, который состоит из базовых образов, таких как CentOS/Alpine, и устанавливает некоторые общие базовые компоненты;
-
Второй уровень — это уровень промежуточного программного обеспечения.В соответствии с различными приложениями установите различные промежуточное программное обеспечение и зависимые пакеты, которые они должны использовать при запуске, такие как nginx, tomcat и т. д.;
-
Третий уровень — это прикладной уровень, который содержит только упакованный код приложения.
Рисунок 2. Соглашение о многоуровневом образе Docker
Краткий опыт: как уменьшить размер изображения и увеличить скорость загрузки?
-
Dockerfile создает образы приложений. При обнаружении некоторых программных пакетов, которые необходимо установить на уровне промежуточного программного обеспечения, используйте инструменты управления пакетами (такие как yum) или загрузите исходные пакеты в режиме клонирования git как можно больше для установки. Цель состоит в том, чтобы скопировать и установить пакеты программного обеспечения.Управление находится на том же уровне.После успешного развертывания программного обеспечения некоторые бесполезные пакеты rpm или пакеты с исходным кодом удаляются, чтобы уменьшить размер базового образа.
-
В образе Java-приложения пакет jdk не включен в образ, и jdk развертывается на каждом хосте.При запуске образа домашний каталог java на хосте монтируется в указанный каталог контейнера путем монтирования каталога . Потому что он будет поддерживать очень большое базовое изображение;
-
При построении образа приложения Docker кэширует два слоя и использует их напрямую, а уровень приложения воссоздает только с изменениями кода, что повышает скорость построения образа приложения и скорость его отправки на зеркальный склад после завершения построения. Общий процесс повышает эффективность развертывания приложения.
Управление оркестрацией контейнеров
Выбор инструментов оркестровки:
Графический интерфейс управления Rancher, простой и удобный в развертывании, может быть интегрирован с AD, LDAP, GITHUB, контролем доступа на основе пользователей или групп пользователей, быстрым обновлением инструмента системной оркестровки до Kubernetes или Swarm, а также наличием профессиональной технической команды для поддержки, сокращения сложность начала работы с контейнерной технологией.
Основываясь на вышеуказанных преимуществах, мы выбираем Rancher в качестве инструмента оркестрации нашей облачной платформы контейнеров.При выполнении унифицированной оркестровки и планирования экземпляров контейнеров приложений с помощью компонента Docker-Compose операции планирования могут выполняться на нескольких хостах одновременно. В то же время, когда доступ к сервису достигает максимума или минимума, уникальный файл rancher-compose.yml используется для вызова функции «МАСШТАБ» для динамического расширения и сжатия кластера приложений, что позволяет приложению обрабатывать различные запросы по мере необходимости. https://zhuanlan.zhihu.com/p/29093407
Выбор модели контейнерной сети:
Поскольку внутренняя разработка основана на платформе Alibaba HSF, сеть между производителями и потребителями должна быть доступна, а требования к сети относительно высоки.Регистрация и получение услуг должны выполняться с реальными IP-адресами. Поэтому при выборе контейнерной сети мы используем режим Host, в процессе запуска контейнера будет выполняться скрипт для проверки хоста и назначения контейнеру независимого порта во избежание конфликтов.
Непрерывная интеграция и непрерывное развертывание
-
Непрерывная интеграция, отслеживание статуса отправки кода, выполнение непрерывной интеграции кода, выполнение модульных тестов в процессе интеграции, выполнение статического сканирования кода Sonar и инструментов безопасности, уведомление о результатах разработчиков и развертывание интегрированной среды, запуск автоматизированных тесты (автоматические тесты) после успешного развертывания.Тестовая часть будет обновлена позже https://zhuanlan.zhihu.com/devops).
Рисунок 7: Принципиальная схема непрерывной интеграции
Результат статического сканирования:
-
Непрерывное развертывание — это очень важная возможность быстрого развертывания пакета там, где вы хотите. Платформа использует распределенное построение и развертывание.Главный узел управляет несколькими подчиненными узлами, и каждый подчиненный узел принадлежит к другой среде. Устанавливайте и обновляйте плагины на мастере, создавайте задания и управляйте разрешениями для каждой команды разработчиков. slave используется для выполнения заданий.
Рисунок 9: Схема архитектуры непрерывного развертывания
Основываясь на приведенной выше архитектуре на рис. 9, мы определяем спецификацию процесса непрерывного развертывания:
(1) Разработчик отправляет код в gitlab; (2) Извлекает код проекта и файлы элементов конфигурации и выполняет задачу компиляции; (3) Извлекает базовый образ, помещает скомпилированный пакет приложения в последний образ приложения и отправляет его в зеркальное хранилище; (4) настроить сгенерированный файл docker-compose.yml в соответствии с текущим приложением и средой, к которой он принадлежит, выполнить команду rancher-compose на основе этого файла и развернуть образ приложения на предварительном производственная среда (выпуск тестовой среды перед производством, соответствующая конфигурация, зависимости службы соответствуют производственной среде). (6) После прохождения предварительного тестирования среды разверните образ приложения в онлайн-среде и уведомите слушателей внутреннего тестирования о результатах теста.
Управление контейнерной операцией
Теперь, когда контейнер приложения развернут в онлайн-среде, необходимо решить следующие две проблемы на протяжении всего жизненного цикла контейнера:
(1) Как сохранить рабочие журналы и другие бизнес-журналы, созданные приложением; (2) Как nginx может автоматически обнаруживать и завершать обновление конфигурации после изменения серверной службы.
управление журналом
Во время выполнения контейнер создает слой для чтения и записи поверх слоя только для чтения, где выполняются все операции записи в приложение. При перезапуске контейнера данные (включая журналы) на уровне чтения-записи также будут очищены. Хотя такие проблемы можно решить путем подключения каталога журналов в контейнере к хосту, когда контейнер часто перемещается между несколькими хостами, каждый хост будет иметь несколько журналов с именем приложения, что увеличивает число разработчиков для просмотра, сложность поиск проблемы.
Подводя итог, можно сказать, что платформа службы журналов, как хранилище журналов веб-сайта WuAge, единообразно хранит журналы, созданные в процессе работы приложения, и поддерживает различные операции запросов.
Настроив путь сбора журналов в интерфейсе управления службы журналов, развернув агент в контейнере для единообразной доставки журналов приложений в хранилище журналов, а затем настроив полнотекстовый индекс и средство разбиения по словам в хранилище журналов, чтобы разработчики могли искать и запрашивать нужные данные по ключевым словам содержание журнала.
Обобщение опыта: Как избежать проблемы повторного сбора логов?
-
Агент службы журналов должен добавить параметр конфигурации "check_point_filename" в файл конфигурации "ilogtail_config.json", указать абсолютный путь, сгенерированный файлом контрольной точки, и смонтировать путь к каталогу хоста, чтобы гарантировать, что файл контрольной точки не будет теряется при перезапуске контейнера, проблем с дублированием сбора не будет.
регистрация услуг
etcd — это хранилище ключей и значений с высокой доступностью и строгой согласованностью.Он использует древовидную структуру, похожую на файловую систему, и все данные начинаются с «/». Данные etcd делятся на два типа: ключ и каталоги, где в ключе хранятся отдельные строковые значения, а в каталогах хранятся наборы ключей или другие подкаталоги.
В среде Wuage каждая служба приложения, зарегистрированная в etcd, имеет корневой каталог с
”/${APP_NAME}_${ENVIRONMENT}”скопировать кодназвание. Ключевая информация каждого экземпляра приложения хранится в корневом каталоге, и все они начинаются с « IP — {ПОРТ}».
На следующем рисунке показана структура данных экземпляра приложения, хранящегося в etcd, с использованием приведенного выше соглашения:
Видно, что я использую метод get для отправки запроса к etcd, а запрос представляет собой службу поиска (search), развернутую в предпроизводственной среде (PRE); в ее корневом каталоге «/search_PRE» находится только одно приложение хранится информация о экземпляре, ключ этого экземпляра — «172.18.100.31-86», соответствующее значение — «172.18.100.31:86», а весь процесс регистрации выглядит следующим образом:
① Создайте случайный порт для приложения-контейнера с помощью кода, сравните его с портом, используемым хостом, и напишите файл конфигурации программы, убедившись, что порт не конфликтует; ② Интегрируйте инструмент регистрации службы, написанный модулями python и etcd. в скрипт, передать IP-адрес и случайный порт, полученные на предыдущем шаге, инструменту регистрации службы в качестве параметров; ③ После полного запуска приложения инструмент регистрации службы запишет экземпляр приложения в кластер etcd с согласованными данными структура для завершения работы по регистрации службы; ④ Контейнер периодически отправляет пульс в etcd, чтобы сообщить о выживании и обновить время ttl; ⑤ Сценарий контейнера захватывает ранчо и отправляет его на сигнал экземпляра приложения. Сигнал терминала отправляет запрос на удаление в etcd для удаления данных экземпляра после получения сигнала.
Примечание: добавлена функция активной очистки на основе ttl.При нормальном выпуске сервиса регистрационная информация на etcd может быть очищена сразу, не дожидаясь времени ttl.
Краткий опыт: когда контейнер перезапускается или случайно уничтожается, давайте посмотрим, что контейнер и реестр делают во время этого процесса?
Приложение имеет атрибут тайм-аута ttl, когда регистрация содержит ключ и значение, что означает, что когда экземпляр в сервисном кластере выйдет из строя, информация, зарегистрированная в etcd, также станет недействительной. будет Мусорные данные всегда сохраняются, и инструмент управления конфигурацией будет читать их как обычные данные и записывать в файл конфигурации веб-сервера. Чтобы гарантировать, что данные, хранящиеся в etcd, всегда действительны, необходимо разрешить etcd активно выпускать неверную информацию об экземпляре.Давайте посмотрим на механизм обновления реестра.Код представлен непосредственно:
#!/usr/bin/env pythonimport etcdimport sys arg_l=sys.argv[1:] etcd_clt=etcd.Client(host='172.18.0.7')def set_key(key,value,ttl=10): try: return etcd_clt.write(key,value,ttl) except TypeError: print 'key or vlaue is null'def refresh_key(key,ttl=10): try: return etcd_clt.refresh(key,ttl) except TypeError: print 'key is null'def del_key(key): try: return etcd_clt.delete(key) except TypeError: print 'key is null'if arg_l: if len(arg_l) == 3: key,value,ttl=arg_l set_key(key,value,ttl) elif len(arg_l) == 2: key,ttl=arg_l refresh_key(key,ttl) elif len(arg_l) == 1: key=arg_l[0] del_key(key) else: raise TypeError,'Only three parameters are needed here'else: raise Exception('args is null')скопировать код
обнаружение службы
confd — это облегченный инструмент управления конфигурацией, который поддерживает etcd в качестве внутреннего источника данных.Чтение данных источника данных гарантирует актуальность локального файла конфигурации, кроме того, он также может проверять файл конфигурации. синтаксис действителен после обновления свойств файла конфигурации для перезагрузки приложения, чтобы конфигурация вступила в силу. Здесь следует отметить, что хотя confd поддерживает rancher в качестве источника данных, в конечном итоге мы выбрали etcd из соображений простоты использования и масштабируемости.
Как и большинство методов развертывания, мы развертываем confd на ECS, где расположен веб-сервер, чтобы confd мог своевременно обновлять файлы конфигурации и перезапускать программы после отслеживания изменений данных. Связанные файлы конфигурации и файлы шаблонов confd развернуты в пути по умолчанию /etc/confd, а структура каталогов выглядит следующим образом:
/etc/confd/ ├── conf.d├── confd.toml└── templatesскопировать код
confd.toml — это основной файл конфигурации confd, написанный в формате TOML, потому что etcd — это развертывание кластера с несколькими узлами, и я не хочу делать инструкции confd вонючими и длинными, поэтому я пишу такие параметры, как interval и узлов в этот файл конфигурации.
В каталоге cond.d хранятся исходные файлы конфигурации шаблона веб-сервера, которые также написаны в формате TOML. Этот файл используется для указания пути к файлу конфигурации шаблона приложения (src), пути к файлу конфигурации приложения (dest), информации о ключах источника данных (keys) и т. д.
В каталоге templates хранятся файлы конфигурации шаблонов каждого приложения на веб-сервере. Он написан в формате текста/шаблона, поддерживаемом Go. После того, как confd прочитает последнюю информацию о регистрации приложения из etcd, он запишет следующий оператор в файл конфигурации шаблона:
{{range getvs "/${APP_NAME}/*"}}
server {{.}};{{end}}скопировать код
Управляйте процессом confd через супервизора. После запуска confd будет опрашивать etcd каждые 5 секунд. Когда K/V службы приложения будет обновлено, confd прочитает данные, хранящиеся в etcd приложением, запишет их в файл конфигурации шаблона и сгенерирует его. файл и, наконец, запишите файл конфигурации по целевому пути с помощью confd и перезагрузите программу nginx, чтобы конфигурация вступила в силу. (Пожалуйста, обратитесь к: https://zhuanlan.zhihu.com/devops для кода)
Суммировать
Эта статья посвящена исследованию и применению контейнерной технологии Docker в процессе непрерывной доставки технической группой по эксплуатации и обслуживанию Five Brothers.В настоящее время разрешение на выпуск и развертывание было открыто владельцу разработки приложений для достижения 7 * 24 «одна остановка» непрерывная доставка., общее улучшение потенциала доставки процесса НИОКР компании.
Далее мы продолжим оптимизировать различные сценарии, возникающие в процессе непрерывной доставки, постепенно улучшать облачную платформу контейнеров, и в то же время мы продолжим делиться различными функциями облачной платформы контейнеров, опытом и извлеченными уроками, а также дать вам ссылку в вашей работе.Избегайте повторных "обходных путей".
Об авторе: Лю Сяомин, руководитель отдела технологий эксплуатации и обслуживания платформы электронной коммерции Wuage Steel (wuage.com), имеет 10-летний опыт разработки, эксплуатации и обслуживания Интернета. Он занимается разработкой инструментов для эксплуатации и технического обслуживания и продвижением экспертных услуг по эксплуатации и техническому обслуживанию, что способствует развитию и постоянному повышению эффективности исследований и разработок.
Эта статья взята из оригинальной статьи «Программист», пожалуйста, откажитесь от перепечатки, если вы хотите подписаться, нажмите здесь (редактор/Вэй Вэй)
PS: Рекомендую прямую онлайн-трансляцию контейнерных технологий.Лекторами являются 6 ведущих экспертов, включая Tencent, Huawei, Cisco, 58.com, Mogujie, Dangdang и т. д. Темы охватывают новейшие практики, такие как контейнерное облако, микросервисы, servicemesh и т. д. Добро пожаловать, чтобы отсканировать QR-код ниже, чтобы зарегистрироваться.