Что общего между чисткой яйца и DevOps?

Автор оригинала: Patrick Lee Scott
  • Перевод
Перед вами перевод статьи Patrick Lee Scott, размещенной на сайте hackernoon.com. Автор предлагает познакомиться с несколькими важными принципами, которые помогут вам прокачаться в DevOps.

image

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

Она взяла еще одно сваренное вкрутую яйцо и ударила его о разделочную доску, потом надавила на него и прокатила по столу. На чистку ушло всего 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. Продакшен — это миф


Это стало для меня настоящим откровением. Мне пришлось посмотреть на вещи под другим углом, так что слушайте внимательно.

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

Этой схеме я следовал год за годом и ни разу в ней не усомнился. Так было всегда.

А еще эта схема — очередной непродуктивный способ избавиться от скорлупы.

По сути чарт — это график зависимостей. Его можно использовать для представления среды, и тогда процесс развертывания в продакшене сводится к развертыванию одного чарта.

Если у каждой команды, проекта или связанной общим контекстом группы есть свой собственный чарт, появляется несколько окружений, которые позволяют группировать и обновлять все сервисы единой транзакцией.

Не воспринимайте продакшен как огромную всеохватывающую среду, на самом деле это много маленьких продакшенов.

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

К тому же, если все оформить в виде чартов, переменные будут выставлены наружу и могут быть изменены извне, единообразно. Например, чтобы подключить менее мощный 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 делает это на стадии продакшена: для него все — график зависимостей!

Заключение


Не отковыривайте скорлупу от яйца по кусочкам. Бейте и катите.
Plarium
134,75
Разработчик мобильных и браузерных игр
Поделиться публикацией

Комментарии 3

    +1

    Очень спорная статья. С одной стороны, автор прав. И действительно, те же trustless сети становятся мейнстримом. А с другой — он прям восхищается Helm, хотя он не является верхом инжинерии. И более того — автор лукавит, говоря, что все просто. Простые решения действительно лучше, чем сложные, т.к. их проще понять, они более предсказуемые. Но с приходом куба мы строим абстракции над абстракциями. Чарты? Операторы? Да, они позволяют свернуть горы, но нужно самому научиться их писать, нужно понимать всю глубину, все возможные граничные случаи. Как только ты публикуешь чарт — будь добр тащи теперь обратную совместимость. Ах, забыл? Ну, тогда получай при деплое сломанный набор ресурсов. А ещё вся эта "простота" в определенных случаях создаёт дополнительную работу. Например, зачем мне база в кубе, если я могу взять RDS? Короче, я расстроен. Запала было воооо, а вышел как всегда пшик

      0
      Посмотрите на kustomize.io, теперь из коробки kubectl
        +3
        Не отковыривайте скорлупу от яйца по кусочкам. Бейте и катите.

        Спорное утверждение. При таком способе есть угроза что мелкие осколки останутся в яйце и потом будут неприятно хрустеть на зубах.

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

        Самое читаемое