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

 

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

Автор: admin от 14-07-2019, 15:05, посмотрело: 19

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



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



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



Она взяла еще одно сваренное вкрутую яйцо и ударила его о разделочную доску, потом надавила на него и прокатила по столу. На чистку ушло всего 3 секунды. А я-то стоял и снимал скорлупу кусочек за кусочком.



Что я хочу этим сказать: мы преувеличиваем значение приложенных усилий.

https://v3.helm.sh/ [/i]



С помощью Helm вы можете легко искать себе готовые велосипеды.



Давайте вернемся в прошлое, когда я только начинал программировать. В 9 классе я выучил свой первый «настоящий» язык — QBasic. До этого я уже пару лет делал сайты на HTML и CSS. Тогда интернет был в новинку, и, хотя люди умели создавать пакеты, они не делились ими, как мы сейчас. Обычно для хранения я пользовался дискетами — было бы здорово найти их вместе с игрой типа арканоид, которую я написал на Java Swing в 11 классе…



Все, чем я тогда пользовался, — это стандартные библиотеки, детка! По крайней мере, в свои 13 я знал только о них. Хотя уверен, что некоторые java-профи (привет, Влад и Ник!) уже тогда были круты. ;)



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



Было бы здорово, если бы существовал инструмент, позволяющий использовать и устанавливать полностью функционирующие подсистемы, правда? Нужна база данных? [i]install database[/i]



Хорошие новости: такой инструмент существует! С помощью 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. Позвольте разработчикам быть максимально продуктивными



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



Тада-а-ам! Нашел! Пофиксил!



Я сидел за перегородкой на своем рабочем месте в залитой солнцем комнате и кричал остальным: «Я исправил баг!»



В следующий вторник, когда пользователи увидят релиз, они точно оценят мои старания! Но для этого нам придется собраться и попытаться сдвинуть с места релиз… Может, у нас и получится, если ничего не произойдет…



Ну окей, [i]если[/i] релиз все-таки будет в следующий вторник, пользователи точно оценят!



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



С тех пор многое изменилось.



Сейчас я использую trunk-based development и разворачиваю модули много раз за день. Когда я отправляю Pull Request, бот постит соответствующий комментарий с код ревью с собранным окружением после того, как прошли тесты и билды собраны.



Сегодня вам не надо кричать через перегородку в офисе.



Чем больше свободы вы даете программистам — свободы контролировать необходимые им части инфраструктуры — тем легче вам работается в качестве DevOps-инженера.



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



Логика примерно такая: я не могу угадать, сколько памяти или какие настройки CPU потребуются для нового сервиса (и думаю, что не я один такой). Поэтому я также развертываю мониторинг и оповещения с правилами, по которым я и моя команда будем проинформированы в Slack, что эти настройки нужно подкрутить. То есть система сообщит о необходимых настройках, когда мы ее развернем. Раньше я часами сидел, отправляя запросы через Prometheus и подгоняя настройки, прямо как когда-то отковыривал скорлупу. А теперь я научился делать все с умом.



Я уже слышу, как вы говорите: «Звучит слишком сложно!» Нет. Просто установите чарт.



Если вы можете автоматизировать или упростить что-то — вперед. Например, что если можно было бы назначить путь DNS, просто развернув сервис с лейблом «expose: true»? Вот тут появляются операторы. Это более продвинутый инструмент Kubernetes, и с ним стоит познакомиться. Но давайте не будем слишком погружаться в детали.



Урок 3. Продакшен — это миф



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



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



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



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



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



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



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



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



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



Урок 4. Перенесите все в кластер и забэкапьте целиком



Так, с продакшеном разобрались. А что делать с базами данных? С Kafka? С вопросами безопасности?



Если вы читали внимательно, то вспомните: я писал, что базы данных можно включить в пакет чарта.



В Kubernetes существует отдельный API для запуска баз данных и других stateful-приложений в удобной форме — [i]StatefulSets.[/i]



Сама суть существования Kubernetes заключается в том, чтобы повысить надежность запуска контейнеров. С ним и с помощью инструмента Velero (устанавливается через Helm Chart) можно создать бэкап всего кластера Kubernetes, вместе с прикрепленными к нему дисками, например теми, что были созданы StatefulSet, и восстановить все одной командой. Кроме того, легко настроить автоматический бэкап по расписанию.



Бэкапы, восстановления в одну команду и менеджер Kubernetes помогут развернуть совершенно новый кластер и восстановить его бэкап с помощью всего двух команд. Максимум трех, если сперва вы захотите создать новый бэкап.



Вместо того чтобы мыслить серверами, вы сможете оперировать целыми кластерами.



Препродакшен раздражает? Уберите его с глаз долой — на расстояние бэкапа, восстановления и смены DNS.



Урок 5. VPN — это слишком сложно, есть решения проще



[i]Вы когда-нибудь пользовались VPN с удовольствием?[/i]



Нет, серьезно. [i]Это вообще возможно?[/i]



У Google была такая попытка. Но пару лет назад компания объявила, что не будет использовать VPN. Думаю, они тоже не получили удовольствия.



Google переключились на trustless-сети. В них нет отмычки, которая подходит для любой сети, но на входе у каждого сервиса лежит ключ в виде SSO-экрана входа. Хотите зайти в службу мониторинга? Войдите, используя логин и пароль компании.



Нужен лишь небольшой сдвиг: вместо того чтобы использовать VPN для авторизации, используйте прокси.



Также VPN размещает ссылку на управление Kubernetes в частной сети, а SSO — нет. Зато у них есть свой механизм авторизации. В случае с Google Cloud и AWS это Identity and Access Management (IAM) и возможность вносить IP-адреса в белый список.



Если есть возможность работать с менее громоздкой архитектурой без особых потерь, почему нет? Будьте как Google: переходите от VPN к системам «без доверия».



Урок 6. Систематизируй, автоматизируй и властвуй



Ах, вам кажется, что систематизировать — долго? Глупости! В будущем это сэкономит вам часы, дни и даже недели. За работу!



Систематизация — это единственный реалистичный способ воссоздать инфраструктуру не единожды.



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



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



Я и мой друг Мэтт занимаемся созданием инструмента под названием [i]meta[/i], который поможет сделать это на стадии разработки. Helm делает это на стадии продакшена: для него все — график зависимостей!



Заключение



Не отковыривайте скорлупу от яйца по кусочкам. Бейте и катите.

Источник: Хабр / Интересные публикации

Категория: Программирование

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *