Следующий человек, который скажет: «Контейнеры Linux решат все наши проблемы», его вытащат и расстреляют. Это верный способ заставить меня поверить в то, что вы на самом деле ничего не понимаете в контейнерах или реальной проблеме развертывания распределенных систем и управления ими в большом масштабе.

Определения

Давайте сначала договоримся о некоторых определениях, потому что слово «контейнер» уже чертовски перегружено:

  • контейнер: функциональность, предоставляемая ядром Linux через контрольные группы и пространства имен, которая позволяет набору процессов иметь собственную изоляцию на уровне ресурсов (процессор, память, io)
  • lxc: набор инструментов и библиотек командной строки для управления контейнерами
  • контейнер приложения / службы: метод распространения приложения или службы, при котором все ресурсы, необходимые для работы в производственной среде, объединены вместе. Примеры включают: статический двоичный файл, файл JAR, сжатый архив, образ файловой системы, системный пакет со связанными зависимостями.
  • Платформа: система, которая позволяет создавать, упаковывать, тестировать, предоставлять, развертывать, настраивать, защищать, отслеживать, оркестрировать приложения или службы и использовать их в производственной среде. Практически все этапы SDLC (жизненного цикла разработки программного обеспечения), а затем некоторые
  • docker: платформа для контейнеров и поддерживаемая ими

Сами по себе контейнеры очень мощные, но платформа - нет. Я собираюсь предположить, что когда большинство людей говорят о том, как контейнеры решают все их проблемы, они на самом деле имеют в виду платформу, поддерживаемую контейнерами, которая решит все их проблемы.

Если это правда, то почему их волнует, использует ли платформа, которую они хотят, контейнеры вообще? Контейнеры - это еще одна технология, это решение проблемы. Вы можете легко создать платформу, построенную на виртуальных машинах или файлах JAR. На самом деле индустрия делает это уже много лет! Если вам действительно нужна платформа, то вам все равно, какие технологии она использует для решения вашей проблемы, только то, что она решает вашу гребаную проблему !!!

Проблема

Итак, если мы действительно пытаемся решить проблему, тогда что это? Называть вещи и определять проблему - две из самых сложных вещей, которые мы делаем в вычислениях. Стартапы потратят годы и кучу инженерных часов, просто пытаясь определить, в чем проблема. Как только вы это сделаете, легко придумать решение.

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

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

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

Случаи применения

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

1) Разворот службы с отслеживанием состояния

Давайте использовать MySQL в этом примере. У меня есть типичная установка с одним главным устройством, которое обрабатывает записи, и несколькими подчиненными устройствами, доступными только для чтения. Само собой разумеется, что я смогу запускать базы данных на своей платформе. Управление сервисами с отслеживанием состояния должно быть основой любой платформы. Если ваша платформа сегодня не может управлять сервисами с отслеживанием состояния, то угадайте, что это не платформа. Тебе должно быть стыдно за себя. Вы решили только проблему, которую я мог решить сам за два дня с помощью bash-скрипта.

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

2) Обновление службы с отслеживанием состояния

Продолжая пример MySQL выше, должно быть возможно выполнять такие действия, как выполнение обновления MySQL с моей платформой. Если бы я хотел сделать что-то вроде обновления версии MySQL с 5.5 до 5.6, позволяет ли мне это сделать моя платформа?

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

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

На самом деле становится сложнее, если я хочу сделать что-то вроде изменения схемы, но рабочий процесс остается прежним. Загрузите новые подчиненные базы данных, выполните какое-либо обновление DDL или ALTER TABLE, проверьте, а затем выполните поворот.

3) Реагирование на Heartbleed

Боль от сердечного кровотечения все еще свежа в моей памяти. Итак, давайте представим сценарий Heartbleed 2.0. Вы используете 500 сервисов в 10 000 сервисных контейнеров, и объявлена ​​уязвимость OpenSSL. Вам необходимо немедленно обновить OpenSSL во всем кластере и повторно выпустить двадцать сертификатов.

Как моя платформа сможет это сделать? Необходимо:

  • Сообщите мне все службы, у которых есть libssl в качестве зависимости и которые используют испорченный сертификат SSL
  • Позвольте мне создать новый пакет libssl и сделать его доступным. Иногда мои репозитории пакетов ОС могут быть недостаточно быстрыми
  • Перестройте каждый сервисный контейнер, связанный с новым пакетом libssl, который мы только что создали.
  • Разверните все затронутые мной сервисные контейнеры в моих тестовых и промежуточных средах и запустите их через полный набор тестов, гарантируя отсутствие неожиданного поведения.
  • Заменить все затронутые мной сервисные контейнеры в моей производственной среде. Это могут быть тысячи сервисных контейнеров. Нам потребуется тесная координация и сопоставление зависимостей, поскольку мы начали заменять и обновлять гигантские фрагменты нашей инфраструктуры как можно быстрее.
  • Выявление любых служб, использующих испорченные сертификаты SSL, и обновление их сертификатов путем повторного развертывания или обновления конфигурации.

Насколько легко это сделать на моей платформе? Последний «Heartbleed» заставил всех вздрогнуть, давайте попробуем не повторять этого снова.

4) Тестирование с помощью зависимых служб

В мире сервисов и микросервисов мне нужно понимать свои зависимости и уметь их выражать и проверять. Большинство сервисов не существуют изолированно. Точно так же, как пакет уровня ОС, такой как Nginx, может иметь зависимость от libc и libssl, моя служба имеет те же типы зависимостей от других служб и ресурсов, которые необходимо выразить.

Подумайте о чем-то столь же простом, как служба API. Служба API может не иметь состояния, но, вероятно, зависит от службы учетных записей, которая содержит бизнес-логику для аутентификации клиента. Служба учетных записей может зависеть от другой службы MySQL или напрямую взаимодействовать с MySQL. Мне нужно иметь возможность выразить эту взаимосвязь и запустить все эти компоненты вместе в моей тестовой среде и убедиться, что они работают. Я не тестирую простую службу изолированно, теперь я проверяю функциональность кластера служб как логической единицы.

api зависит от account-service ›= 2.1, который зависит от accounts-db› 4.21

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

В связи с этим, насколько легко было бы использовать мою платформу, чтобы развернуть точную копию того, что у меня есть в производстве - в том виде, в котором она существовала месяц назад? Что, если бы я хотел раскрутить десять копий этой среды. Пятьдесят?

5) Загрузочный Apache Hadoop

Само собой разумеется, могу ли я легко загрузить чудовище, известное как Apache Hadoop, с помощью моей платформы. У Hadoop есть множество безумных зависимостей и скоординированных шагов, которые необходимо предпринять для запуска кластера, а также у него есть состояние!

В итоге

Это только начало того, что я хотел бы увидеть решенным в моей идеальной платформе. Я многое упустил, но если мы хотим решить проблему управления распределенной системой (микро) сервисов, это первый уровень. Это проблемы и проблемы, которые есть у многих из нас сегодня!

Знаете ли вы, что даже с учетом всех достижений в области технологий количество времени, которое домохозяйка тратит на ведение домашнего хозяйства сегодня, точно такое же, как и в 1950-х годах! У нас есть все эти технологии, но они не упростили задачу. То же самое можно сказать и об облаке - в нем было реализовано множество удивительных вещей, но лишь немногие из них стали проще. Я бы хотел увидеть больше!

Также будьте осторожны - я понятия не имею, о чем говорю. Отнеситесь ко всему в этой статье с недоверием. Это сообщение самоуничтожится.

Также я еще не уверен, что определил проблему, но мне нужна платформа, которая управляет (микро) сервисами.