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

в 15:21, , рубрики: github, helm, prodaction, vpn, Блог компании Plarium, Программирование, советы, чарты

Перед вами перевод статьи 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. Продакшен — это миф

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

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

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

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

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

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

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

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

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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js