Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Перед вами перевод статьи Patrick Lee Scott, размещенной на сайте hackernoon.com. Автор предлагает познакомиться с несколькими важными принципами, которые помогут вам прокачаться в DevOps.
Пару дней назад я пытался почистить яйцо дурацким способом, и моя девушка Анжели спросила меня, зачем я это делаю.
Она взяла еще одно сваренное вкрутую яйцо и ударила его о разделочную доску, потом надавила на него и прокатила по столу. На чистку ушло всего 3 секунды. А я-то стоял и снимал скорлупу кусочек за кусочком.
Что я хочу этим сказать: мы преувеличиваем значение приложенных усилий.
Лучшие решения — простые и эффективные. Сложно ли почистить ржавый болт? Наверное, да. Но только если вы не знаете, что это можно сделать с помощью Кока-колы. Все еще сложно? Нет. Вам нужно лишь положить болт в стакан и подождать.
Не зная простых техник, вы не можете применять их. Вместо реализации вы проводите эксперименты, вместо репликации занимаетесь исследованиями.
Если в программировании вы используете какой-то подход снова и снова, потому что он позволяет упростить решаемую проблему, этот подход становится шаблоном или так называемой лучшей практикой.
Несмотря на сложные и пугающие названия вроде Command Query Responsibility Segregation (CQRS) или Event Sourcing (ES), эти практики помогают в решении проблем. Особенно тех, что возникают при построении распределенных систем.
Если посмотреть на разработку в целом, мы увидим, что существуют более универсальные принципы, например «Keep it Simple, Stupid» (KISS) и «Don’t Repeat Yourself» (DRY). Я бы хотел поговорить о подобных шаблонах и принципах применительно к DevOps.
DevOps часто представляют как землю обетованную, на которой поют птички и светит солнышко. Но без использования правильных методов DevOps превратится в ад, а вы исколете себе все пальцы скорлупой (как я).
Создавая DevOps-системы, я нашел для себя несколько решений в дополнение к универсальным принципам вроде KISS и DRY. Пока их нельзя назвать шаблонами, но они помогут вам быстро почистить яйцо. Вот эти решения (в произвольном порядке):
Если у вас есть возможность приобрести готовый продукт или в открытом доступе есть необходимый и удобный инструмент, воспользуйтесь этим.
Не изобретайте велосипед — купите его.
Вы знали, что можно пользоваться тем же почтовым сервером, который применяют в Craigslist? И что это бесплатно? Нужен почтовый сервер — не создавайте новый, работайте с уже существующим.
Мне нравится искать инструменты в списках awesome-self-hosted или использовать для этого Helm Hub.
Несмотря на то, что Helm — достаточно новый инструмент для поиска программного обеспечения, уже был создан вот такой сайт: https://v3.helm.sh/
С помощью Helm вы можете легко искать себе готовые велосипеды.
Давайте вернемся в прошлое, когда я только начинал программировать. В 9 классе я выучил свой первый «настоящий» язык — QBasic. До этого я уже пару лет делал сайты на HTML и CSS. Тогда интернет был в новинку, и, хотя люди умели создавать пакеты, они не делились ими, как мы сейчас. Обычно для хранения я пользовался дискетами — было бы здорово найти их вместе с игрой типа арканоид, которую я написал на Java Swing в 11 классе…
Все, чем я тогда пользовался, — это стандартные библиотеки, детка! По крайней мере, в свои 13 я знал только о них. Хотя уверен, что некоторые java-профи (привет, Влад и Ник!) уже тогда были круты. ;)
Сейчас все не так. Сегодня вы можете найти целые библиотеки UI. Можете найти библиотеку, чтобы элегантно и легко расправляться с датами с помощью одной команды.
Было бы здорово, если бы существовал инструмент, позволяющий использовать и устанавливать полностью функционирующие подсистемы, правда? Нужна база данных? install database
Хорошие новости: такой инструмент существует! С помощью Helm вы также можете устанавливать полностью функционирующие подсистемы, упакованные и готовые к использованию.
Принцип тот же, что у NPM и Gradle, но пакеты, которыми мы управляем в Helm, называются чартами. Чарты размечают контейнеры так, что они запускаются в Kubernetes разными способами.
Получается готовое решение, покупка велосипеда. Чарты — это руль, а контейнеры с описаниями, которые запускаются внутри Kubernetes, — это колеса.
Что крутого в чартах, так это возможность упаковать сервисы и запускать их в любом кластере Kubernetes и даже делиться ими с другими людьми, если захотите.
Это значит, что вы можете описать целую среду с помощью кода:
Нужно обновить marketing-site до 1.2.0? Просто внесите изменения и закоммитьте.
Сидел я как-то за столом, смотрел в свой код и пытался отследить баг. Пользователи жаловались на него уже несколько недель, и наконец у меня выдалось немного свободного времени, чтобы погеройствовать.
Тада-а-ам! Нашел! Пофиксил!
Я сидел за перегородкой на своем рабочем месте в залитой солнцем комнате и кричал остальным: «Я исправил баг!»
В следующий вторник, когда пользователи увидят релиз, они точно оценят мои старания! Но для этого нам придется собраться и попытаться сдвинуть с места релиз… Может, у нас и получится, если ничего не произойдет…
Ну окей, если релиз все-таки будет в следующий вторник, пользователи точно оценят!
Вот так я и занимался развертыванием на моей первой после колледжа работе, будучи на должности джуниор-программиста.
С тех пор многое изменилось.
Сейчас я использую trunk-based development и разворачиваю модули много раз за день. Когда я отправляю Pull Request, бот постит соответствующий комментарий с код ревью с собранным окружением после того, как прошли тесты и билды собраны.
Сегодня вам не надо кричать через перегородку в офисе.
Чем больше свободы вы даете программистам — свободы контролировать необходимые им части инфраструктуры — тем легче вам работается в качестве DevOps-инженера.
В первом уроке мы с вами увидели, что для обновления в продакшене достаточно изменить одну цифру и закоммитить. В идеальном мире, в котором мы упаковываем приложения в чарты, у каждого программиста в команде появляется возможность влиять на то, как инструмент работает на стадии продакшена. Kubernetes понимает чарты как описание контейнеров, и именно поэтому в них описываются требования к ресурсам.
Логика примерно такая: я не могу угадать, сколько памяти или какие настройки CPU потребуются для нового сервиса (и думаю, что не я один такой). Поэтому я также развертываю мониторинг и оповещения с правилами, по которым я и моя команда будем проинформированы в Slack, что эти настройки нужно подкрутить. То есть система сообщит о необходимых настройках, когда мы ее развернем. Раньше я часами сидел, отправляя запросы через Prometheus и подгоняя настройки, прямо как когда-то отковыривал скорлупу. А теперь я научился делать все с умом.
Я уже слышу, как вы говорите: «Звучит слишком сложно!» Нет. Просто установите чарт.
Если вы можете автоматизировать или упростить что-то — вперед. Например, что если можно было бы назначить путь DNS, просто развернув сервис с лейблом «expose: true»? Вот тут появляются операторы. Это более продвинутый инструмент Kubernetes, и с ним стоит познакомиться. Но давайте не будем слишком погружаться в детали.
Это стало для меня настоящим откровением. Мне пришлось посмотреть на вещи под другим углом, так что слушайте внимательно.
Больше десяти лет я думал, что на свете есть только несколько типов окружения. При самом простом раскладе есть стейджинг и продакшен окружения. Сперва развернул в продакшене, потом затестил, перешел на следующий этап, развернул, затестил и так далее. Как только все задеплоилось вместе — сынтегрировалось — можно переходить в продакшен.
Этой схеме я следовал год за годом и ни разу в ней не усомнился. Так было всегда.
А еще эта схема — очередной непродуктивный способ избавиться от скорлупы.
По сути чарт — это график зависимостей. Его можно использовать для представления среды, и тогда процесс развертывания в продакшене сводится к развертыванию одного чарта.
Если у каждой команды, проекта или связанной общим контекстом группы есть свой собственный чарт, появляется несколько окружений, которые позволяют группировать и обновлять все сервисы единой транзакцией.
Не воспринимайте продакшен как огромную всеохватывающую среду, на самом деле это много маленьких продакшенов.
Крупные изменения пугают своей масштабностью. А если у вас несколько маленьких сред разработки, вам удастся изолировать изменения и сделать систему более гибкой.
К тому же, если все оформить в виде чартов, переменные будут выставлены наружу и могут быть изменены извне, единообразно. Например, чтобы подключить менее мощный kafka-кластер на препродакшен, где он не требуется, нужно просто изменить конфигурацию.
Так, с продакшеном разобрались. А что делать с базами данных? С Kafka? С вопросами безопасности?
Если вы читали внимательно, то вспомните: я писал, что базы данных можно включить в пакет чарта.
В Kubernetes существует отдельный API для запуска баз данных и других stateful-приложений в удобной форме — StatefulSets.
Сама суть существования Kubernetes заключается в том, чтобы повысить надежность запуска контейнеров. С ним и с помощью инструмента Velero (устанавливается через Helm Chart) можно создать бэкап всего кластера Kubernetes, вместе с прикрепленными к нему дисками, например теми, что были созданы StatefulSet, и восстановить все одной командой. Кроме того, легко настроить автоматический бэкап по расписанию.
Бэкапы, восстановления в одну команду и менеджер Kubernetes помогут развернуть совершенно новый кластер и восстановить его бэкап с помощью всего двух команд. Максимум трех, если сперва вы захотите создать новый бэкап.
Вместо того чтобы мыслить серверами, вы сможете оперировать целыми кластерами.
Препродакшен раздражает? Уберите его с глаз долой — на расстояние бэкапа, восстановления и смены DNS.
Вы когда-нибудь пользовались VPN с удовольствием?
Нет, серьезно. Это вообще возможно?
У Google была такая попытка. Но пару лет назад компания объявила, что не будет использовать VPN. Думаю, они тоже не получили удовольствия.
Google переключились на trustless-сети. В них нет отмычки, которая подходит для любой сети, но на входе у каждого сервиса лежит ключ в виде SSO-экрана входа. Хотите зайти в службу мониторинга? Войдите, используя логин и пароль компании.
Нужен лишь небольшой сдвиг: вместо того чтобы использовать VPN для авторизации, используйте прокси.
Также VPN размещает ссылку на управление Kubernetes в частной сети, а SSO — нет. Зато у них есть свой механизм авторизации. В случае с Google Cloud и AWS это Identity and Access Management (IAM) и возможность вносить IP-адреса в белый список.
Если есть возможность работать с менее громоздкой архитектурой без особых потерь, почему нет? Будьте как Google: переходите от VPN к системам «без доверия».
Ах, вам кажется, что систематизировать — долго? Глупости! В будущем это сэкономит вам часы, дни и даже недели. За работу!
Систематизация — это единственный реалистичный способ воссоздать инфраструктуру не единожды.
Если каждый элемент настройки можно улучшить, изменив и закоммитив что-то в git, по сути вся ваша технологическая организация декларативна. Любой девелопер с доступом в git с легкостью может поддерживать в рабочем состоянии любую систему.
Для этого используйте несколько мелких репозиториев. Monorepos заставляют людей срезать углы и зависеть от структуры с искусственной важностью. Вместо них лучше использовать много маленьких репозиториев, которые можно связать позже.
Я и мой друг Мэтт занимаемся созданием инструмента под названием meta, который поможет сделать это на стадии разработки. Helm делает это на стадии продакшена: для него все — график зависимостей!
Не отковыривайте скорлупу от яйца по кусочкам. Бейте и катите.
Пару дней назад я пытался почистить яйцо дурацким способом, и моя девушка Анжели спросила меня, зачем я это делаю.
Она взяла еще одно сваренное вкрутую яйцо и ударила его о разделочную доску, потом надавила на него и прокатила по столу. На чистку ушло всего 3 секунды. А я-то стоял и снимал скорлупу кусочек за кусочком.
Что я хочу этим сказать: мы преувеличиваем значение приложенных усилий.
Лучшие решения — простые и эффективные. Сложно ли почистить ржавый болт? Наверное, да. Но только если вы не знаете, что это можно сделать с помощью Кока-колы. Все еще сложно? Нет. Вам нужно лишь положить болт в стакан и подождать.
Не зная простых техник, вы не можете применять их. Вместо реализации вы проводите эксперименты, вместо репликации занимаетесь исследованиями.
Если в программировании вы используете какой-то подход снова и снова, потому что он позволяет упростить решаемую проблему, этот подход становится шаблоном или так называемой лучшей практикой.
Несмотря на сложные и пугающие названия вроде Command Query Responsibility Segregation (CQRS) или Event Sourcing (ES), эти практики помогают в решении проблем. Особенно тех, что возникают при построении распределенных систем.
Если посмотреть на разработку в целом, мы увидим, что существуют более универсальные принципы, например «Keep it Simple, Stupid» (KISS) и «Don’t Repeat Yourself» (DRY). Я бы хотел поговорить о подобных шаблонах и принципах применительно к DevOps.
DevOps часто представляют как землю обетованную, на которой поют птички и светит солнышко. Но без использования правильных методов DevOps превратится в ад, а вы исколете себе все пальцы скорлупой (как я).
Создавая DevOps-системы, я нашел для себя несколько решений в дополнение к универсальным принципам вроде KISS и DRY. Пока их нельзя назвать шаблонами, но они помогут вам быстро почистить яйцо. Вот эти решения (в произвольном порядке):
- Не делайте то, что другие сделали до вас.
- Позвольте разработчикам быть максимально продуктивными.
- Продакшен — это миф.
- Перенесите все в кластер и забэкапьте целиком.
- VPN — это слишком сложно, есть решения проще.
- Систематизируй, автоматизируй и властвуй!
Урок 1. Не делайте то, что другие сделали до вас
Если у вас есть возможность приобрести готовый продукт или в открытом доступе есть необходимый и удобный инструмент, воспользуйтесь этим.
Не изобретайте велосипед — купите его.
Вы знали, что можно пользоваться тем же почтовым сервером, который применяют в Craigslist? И что это бесплатно? Нужен почтовый сервер — не создавайте новый, работайте с уже существующим.
Мне нравится искать инструменты в списках awesome-self-hosted или использовать для этого Helm Hub.
Несмотря на то, что Helm — достаточно новый инструмент для поиска программного обеспечения, уже был создан вот такой сайт: https://v3.helm.sh/
С помощью Helm вы можете легко искать себе готовые велосипеды.
Давайте вернемся в прошлое, когда я только начинал программировать. В 9 классе я выучил свой первый «настоящий» язык — QBasic. До этого я уже пару лет делал сайты на HTML и CSS. Тогда интернет был в новинку, и, хотя люди умели создавать пакеты, они не делились ими, как мы сейчас. Обычно для хранения я пользовался дискетами — было бы здорово найти их вместе с игрой типа арканоид, которую я написал на Java Swing в 11 классе…
Все, чем я тогда пользовался, — это стандартные библиотеки, детка! По крайней мере, в свои 13 я знал только о них. Хотя уверен, что некоторые java-профи (привет, Влад и Ник!) уже тогда были круты. ;)
Сейчас все не так. Сегодня вы можете найти целые библиотеки UI. Можете найти библиотеку, чтобы элегантно и легко расправляться с датами с помощью одной команды.
Было бы здорово, если бы существовал инструмент, позволяющий использовать и устанавливать полностью функционирующие подсистемы, правда? Нужна база данных? install database
Хорошие новости: такой инструмент существует! С помощью Helm вы также можете устанавливать полностью функционирующие подсистемы, упакованные и готовые к использованию.
Принцип тот же, что у NPM и Gradle, но пакеты, которыми мы управляем в Helm, называются чартами. Чарты размечают контейнеры так, что они запускаются в Kubernetes разными способами.
Получается готовое решение, покупка велосипеда. Чарты — это руль, а контейнеры с описаниями, которые запускаются внутри Kubernetes, — это колеса.
Что крутого в чартах, так это возможность упаковать сервисы и запускать их в любом кластере Kubernetes и даже делиться ими с другими людьми, если захотите.
Это значит, что вы можете описать целую среду с помощью кода:
- name: backup
repository: http://jenkins-x-chartmuseum:8080
version: 0.0.2
- name: monitor
repository: http://jenkins-x-chartmuseum:8080
version: 0.0.3
- name: marketing-site
repository: http://jenkins-x-chartmuseum:8080
version: 1.1.10
- name: denormalizer-service
repository: http://jenkins-x-chartmuseum:8080
version: 1.0.0
- name: mongo
repository: https://kubernetes-charts.storage.googleapis.com/
version: 1.0.0Нужно обновить marketing-site до 1.2.0? Просто внесите изменения и закоммитьте.
Урок 2. Позвольте разработчикам быть максимально продуктивными
Сидел я как-то за столом, смотрел в свой код и пытался отследить баг. Пользователи жаловались на него уже несколько недель, и наконец у меня выдалось немного свободного времени, чтобы погеройствовать.
Тада-а-ам! Нашел! Пофиксил!
Я сидел за перегородкой на своем рабочем месте в залитой солнцем комнате и кричал остальным: «Я исправил баг!»
В следующий вторник, когда пользователи увидят релиз, они точно оценят мои старания! Но для этого нам придется собраться и попытаться сдвинуть с места релиз… Может, у нас и получится, если ничего не произойдет…
Ну окей, если релиз все-таки будет в следующий вторник, пользователи точно оценят!
Вот так я и занимался развертыванием на моей первой после колледжа работе, будучи на должности джуниор-программиста.
С тех пор многое изменилось.
Сейчас я использую trunk-based development и разворачиваю модули много раз за день. Когда я отправляю Pull Request, бот постит соответствующий комментарий с код ревью с собранным окружением после того, как прошли тесты и билды собраны.
Сегодня вам не надо кричать через перегородку в офисе.
Чем больше свободы вы даете программистам — свободы контролировать необходимые им части инфраструктуры — тем легче вам работается в качестве DevOps-инженера.
В первом уроке мы с вами увидели, что для обновления в продакшене достаточно изменить одну цифру и закоммитить. В идеальном мире, в котором мы упаковываем приложения в чарты, у каждого программиста в команде появляется возможность влиять на то, как инструмент работает на стадии продакшена. Kubernetes понимает чарты как описание контейнеров, и именно поэтому в них описываются требования к ресурсам.
Логика примерно такая: я не могу угадать, сколько памяти или какие настройки CPU потребуются для нового сервиса (и думаю, что не я один такой). Поэтому я также развертываю мониторинг и оповещения с правилами, по которым я и моя команда будем проинформированы в Slack, что эти настройки нужно подкрутить. То есть система сообщит о необходимых настройках, когда мы ее развернем. Раньше я часами сидел, отправляя запросы через Prometheus и подгоняя настройки, прямо как когда-то отковыривал скорлупу. А теперь я научился делать все с умом.
Я уже слышу, как вы говорите: «Звучит слишком сложно!» Нет. Просто установите чарт.
Если вы можете автоматизировать или упростить что-то — вперед. Например, что если можно было бы назначить путь DNS, просто развернув сервис с лейблом «expose: true»? Вот тут появляются операторы. Это более продвинутый инструмент Kubernetes, и с ним стоит познакомиться. Но давайте не будем слишком погружаться в детали.
Урок 3. Продакшен — это миф
Это стало для меня настоящим откровением. Мне пришлось посмотреть на вещи под другим углом, так что слушайте внимательно.
Больше десяти лет я думал, что на свете есть только несколько типов окружения. При самом простом раскладе есть стейджинг и продакшен окружения. Сперва развернул в продакшене, потом затестил, перешел на следующий этап, развернул, затестил и так далее. Как только все задеплоилось вместе — сынтегрировалось — можно переходить в продакшен.
Этой схеме я следовал год за годом и ни разу в ней не усомнился. Так было всегда.
А еще эта схема — очередной непродуктивный способ избавиться от скорлупы.
По сути чарт — это график зависимостей. Его можно использовать для представления среды, и тогда процесс развертывания в продакшене сводится к развертыванию одного чарта.
Если у каждой команды, проекта или связанной общим контекстом группы есть свой собственный чарт, появляется несколько окружений, которые позволяют группировать и обновлять все сервисы единой транзакцией.
Не воспринимайте продакшен как огромную всеохватывающую среду, на самом деле это много маленьких продакшенов.
Крупные изменения пугают своей масштабностью. А если у вас несколько маленьких сред разработки, вам удастся изолировать изменения и сделать систему более гибкой.
К тому же, если все оформить в виде чартов, переменные будут выставлены наружу и могут быть изменены извне, единообразно. Например, чтобы подключить менее мощный kafka-кластер на препродакшен, где он не требуется, нужно просто изменить конфигурацию.
Урок 4. Перенесите все в кластер и забэкапьте целиком
Так, с продакшеном разобрались. А что делать с базами данных? С Kafka? С вопросами безопасности?
Если вы читали внимательно, то вспомните: я писал, что базы данных можно включить в пакет чарта.
В Kubernetes существует отдельный API для запуска баз данных и других stateful-приложений в удобной форме — StatefulSets.
Сама суть существования Kubernetes заключается в том, чтобы повысить надежность запуска контейнеров. С ним и с помощью инструмента Velero (устанавливается через Helm Chart) можно создать бэкап всего кластера Kubernetes, вместе с прикрепленными к нему дисками, например теми, что были созданы StatefulSet, и восстановить все одной командой. Кроме того, легко настроить автоматический бэкап по расписанию.
Бэкапы, восстановления в одну команду и менеджер Kubernetes помогут развернуть совершенно новый кластер и восстановить его бэкап с помощью всего двух команд. Максимум трех, если сперва вы захотите создать новый бэкап.
Вместо того чтобы мыслить серверами, вы сможете оперировать целыми кластерами.
Препродакшен раздражает? Уберите его с глаз долой — на расстояние бэкапа, восстановления и смены DNS.
Урок 5. VPN — это слишком сложно, есть решения проще
Вы когда-нибудь пользовались VPN с удовольствием?
Нет, серьезно. Это вообще возможно?
У Google была такая попытка. Но пару лет назад компания объявила, что не будет использовать VPN. Думаю, они тоже не получили удовольствия.
Google переключились на trustless-сети. В них нет отмычки, которая подходит для любой сети, но на входе у каждого сервиса лежит ключ в виде SSO-экрана входа. Хотите зайти в службу мониторинга? Войдите, используя логин и пароль компании.
Нужен лишь небольшой сдвиг: вместо того чтобы использовать VPN для авторизации, используйте прокси.
Также VPN размещает ссылку на управление Kubernetes в частной сети, а SSO — нет. Зато у них есть свой механизм авторизации. В случае с Google Cloud и AWS это Identity and Access Management (IAM) и возможность вносить IP-адреса в белый список.
Если есть возможность работать с менее громоздкой архитектурой без особых потерь, почему нет? Будьте как Google: переходите от VPN к системам «без доверия».
Урок 6. Систематизируй, автоматизируй и властвуй
Ах, вам кажется, что систематизировать — долго? Глупости! В будущем это сэкономит вам часы, дни и даже недели. За работу!
Систематизация — это единственный реалистичный способ воссоздать инфраструктуру не единожды.
Если каждый элемент настройки можно улучшить, изменив и закоммитив что-то в git, по сути вся ваша технологическая организация декларативна. Любой девелопер с доступом в git с легкостью может поддерживать в рабочем состоянии любую систему.
Для этого используйте несколько мелких репозиториев. Monorepos заставляют людей срезать углы и зависеть от структуры с искусственной важностью. Вместо них лучше использовать много маленьких репозиториев, которые можно связать позже.
Я и мой друг Мэтт занимаемся созданием инструмента под названием meta, который поможет сделать это на стадии разработки. Helm делает это на стадии продакшена: для него все — график зависимостей!
Заключение
Не отковыривайте скорлупу от яйца по кусочкам. Бейте и катите.
