Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».
Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.
Почему я считаю важным уметь менять парадигму технологического мышления?
Самая сложная вещь для тех, кто давно работает в технологиях, — принять, что новый тренд стал постоянным. За 20 лет работы я видел, как приходили и уходили разные технологии, причем некоторые из них были «суперактуальны» целых несколько месяцев.
Я читал Джоэля Спольски про то, как Microsoft систематически придумывает новый стек для разработчиков для того, чтобы в целом не дать им возможность посмотреть на что-то иное. Как SRE, я вдвойне опасался каждой новой технологии: всё новое — сырое, всё сырое — нестабильное. Ну, а всё нестабильное приведёт к проблемам в продакшне, а стабильность продакшна — это главное.
Как программист и предприниматель, я хотел создавать продукт быстрее — всё новое надо изучать, изменять привычные подходы, а это значит — медленнее выкатывать фичи. Если какие-то новые технологии принимались быстро, то все связанное с микросервисно-ориентированной разработкой (давайте так назовем весь современный стек) нужно было учить. И с каждым годом учить все дольше; гораздо проще писать старым привычным методом и доставлять продукт быстрее.
Но факт остается фактом: иногда новые технологии остаются и меняют всю парадигму целиком. И тут возникает выбор: оставаться в старой парадигме или переходить в новую. Cobol-программисты до сих пор могут устроиться на работу, perl-разработчики помнят про booking, но альтернативных путей для этих людей становится всё меньше и меньше. И тогда «ретроградство» во имя стабильности становится ограничением. Со всем современным стеком, если вы не хотите себя ограничивать, время уже не то, что пришло, а мы уже отстаем. И, если мы не хотим застрять в «perl»-е, надо учиться. Это занимает продолжительное время. Попробую рассказать свой пошаговый опыт в обучении.
Поймите, как запускать приложения в докере. Прежде всего, ветеранам стоит понять, что способ «хранения» и «запуска» приложений изменился навсегда. Скорее всего, разработчик, который научился разработке в последние годы, вообще не представляет себе, как запускать приложение в продакшне без докера. В голове такого разработчика, вероятно, нет концепции «хранить файлы локально», кроме редких кейсов общего хранилища, но главное, что нужно понять «ветерану»: докер — это новый exe. У exe-формата, может быть, есть свои минусы, но никто уже об этом особо не думает.
Да, микросервисный подход стал стандартом. Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт; теперь таким же стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). Это разумно: при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое. Зачем и маленькие приложения писать микросервисно, можно поспорить, но и их в какой-то момент все стали писать в ООП-стиле— просто так привычно (см. выше про exe). Можно много рассуждать о том, что у межпроцессной коммуникации (особенно, построенной на TCP-стеке) существует миллион недостатков с точки зрения производительности (один сервис пойдет к другому по TCP вместо того, чтобы просто выполнить ассемблерный-call — вы представляете какая это разница в производительности?), но факт остается фактом — у микросервисов есть достоинства скорости разработки средних и больших проектов и они также стали стандартом. Поймите, как микросервисы между собой взаимодействуют (HTTP API, grpc, асинхронное взаимодействие через очередь — миллион способов), бонусом — поймите, что такое service mesh. (Минута гневного юмора: боже, ребята, они придумали разделить приложение, и оказалось, что коммуникация между разделенными приложениями — сложная шутка, поэтому они добавили еще один слой, чтобы облегчить межпроцессный ужас, за что это нам?)
Поймите, как управлять пачкой запущенных в докерах микросервисов. Итак, мы смирились, что приложения мы теперь запускаем в докере и что приложение мы разделяем на микросервисы. Теперь надо как-то управлять запущенными докерами. Можно делать это самому на выделенных серверах (и рулить, например Docker Swarm-ом, ну или собрать Kubernetes), а можно использовать сервисы, которые дают облака — контейнер-сервисы от AWS или Kubernetes. В использовании облаков есть одно очень большое преимущество. Вы, фактически, перестаете думать про слой, запущенный ниже менеджера контейнеров (SRE сейчас посмеются, но давайте признаемся — когда все стабильно, мы не лазим на ноды GKE руками в большинстве случаев). Таким образом, фактически, менеджер контейнеров, стандартом которого стал Kubernetes, превращается в операционную систему. В нём есть пакет-менеджеры, в него можно «ставить софт», в нём можно запускать «exe-шники» — докеры, в нём есть кронджобы. Kubernetes — это новая ОС.
Разберитесь, как докер-контейнеры надо будет доставлять. Выкладка простого сайта теперь занимает 5 минут, и люди считают это нормой. Надо собрать докер, протестировать, положить в registry и поместить в менеджер докеров (давайте будем говорить дальше Kubernetes). Это дикость (?), к которой все привыкли, это оптимизируется и это стандарт. CI/CD системы стали стандартом выкладки, и с ними надо разобраться. Также как и с GitOps.
Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое. Когда-то давно нормой было купить серверы, собрать их, привезти в ДЦ, поставить в колокейшн и скоммутировать. Даже для небольшого проекта. Потом на смену пришли Dedicated-серверы. Какому количеству людей приходит сейчас в голову на небольших и средних проектах мучаться, покупать и собирать железо? На смену Dedicated — на Западе уже сейчас, а в РФ скоро — придут облака. Об этом говорят сто лет, я использую AWS с 2008 года, и у него есть проблемы, но когда мы говорим о сервисе, который берёт на себя менеджмент Kubernetes (EKS, GKE, Kubernetes от Яндекса или Селектела), мне становится непонятно, зачем менеджить сам Kubernetes и дедики, если это делают другие ребята? Я же не меняю кулеры в дедиках больше… Вопрос распространенности on-premise дистрибуций Kubernetes в РФ — это вопрос курса доллара, закона о персданных и «молодости» российского клауд-хостинга. Рано или поздно это решится и on-premise станет дикостью, которую хотят энтерпрайзы и большие нагруженные проекты. С базами то же самое. Если мы говорим о большинстве приложений, которым не требуется супервысокая нагрузка или супермощный тюнинг, то облачный PostreSQL/MongoDB/MySQL дает огромное количество преимуществ. Не надо думать про тюнинг, не надо думать про бэкапы. Создать дев-сервер из продакшн-сервера — пара команд в облачной консоли. Я понимаю, что вся эта идея может вызывать гнев у админа: ребята, я и сам админ, но для большинства нехайлоад задач менеджмент баз, правда, не нужен. Возможно, AWS и GKE стоят дорого и недоступны нам из-за закона о персданных, но это лишь дополнительное время для отставания: рано или поздно те же фичи будут у Яндекса или Селектела, и парадигма сменится.
Поймите, что инфраструктуру теперь пишут. Я не любил IaaC, когда он был Chef-ом и Puppet-ом, но на смену им, слава богу, пришли более адекватные Terraform и Pulumi для описания того, что вы хотите поднять в кластере, и Ansible для работы внутри. Зайти и что-то поставить в шелл — теперь абсолютная дикость. Да, это быстрее и удобнее, но в новой парадигме — это дикость: вспомните про exe.
Каким я вижу конкретный технический путь для того, чтобы понять, как работать с современным стеком?
1) Сделать триальный аккаунт на клауд-хостинге. Их предоставляют все хостинги. Я начинал с GKE, но можно, например, взять аккаунт на российских хостингах, если вы ожидаете, что работать будете, скорее всего, на этой территории.
Если Terraform/Pulumi поддерживают ваш клауд — описать инфраструктуру, которую вы хотите создать в них. Если у вас есть навыки программирования, я рекомендую Pulumi: вместо собственного SDL Terraform-а вы сможете писать на привычных языках и конструкциях.
2) Найти приложение и упаковать его в докер. Что тут упаковывать — выбор за вами. Я внезапно обнаружил для себя, насколько стал распространен NodeJS, и решил заняться глубоким изучением его эксплуатации, поэтому дальнейшую работу веду с нодой. Вот, например, бложик на NodeJS, который можно поднять, но вообще все на ваше усмотрение.
3) Разобраться с базовыми конструктами (под, деплоймент, сервис) K8S и задеплоить приложение руками в кластер K8S.
4) Разобраться с Helm-ом, написать Helm-чарт, задеплоить приложение Helm-ом.
Взять бесплатный план на CircleCI как CI-ке, которую не надо ставить, и конфигурировать: конфиги будут похожи на остальные системы.
5) Задеплоить приложение через CI-ку.
Разделить CI (то, что собирает приложение) и CD. Сделать CD по GitOps (см, например ArgoCD).
Где-то с этого момента вы, в принципе, будете в курсе основных базисов современного стэка.
Куда можно пойти копаться дальше?
А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.
Почему я считаю важным уметь менять парадигму технологического мышления?
Самая сложная вещь для тех, кто давно работает в технологиях, — принять, что новый тренд стал постоянным. За 20 лет работы я видел, как приходили и уходили разные технологии, причем некоторые из них были «суперактуальны» целых несколько месяцев.
Я читал Джоэля Спольски про то, как Microsoft систематически придумывает новый стек для разработчиков для того, чтобы в целом не дать им возможность посмотреть на что-то иное. Как SRE, я вдвойне опасался каждой новой технологии: всё новое — сырое, всё сырое — нестабильное. Ну, а всё нестабильное приведёт к проблемам в продакшне, а стабильность продакшна — это главное.
Как программист и предприниматель, я хотел создавать продукт быстрее — всё новое надо изучать, изменять привычные подходы, а это значит — медленнее выкатывать фичи. Если какие-то новые технологии принимались быстро, то все связанное с микросервисно-ориентированной разработкой (давайте так назовем весь современный стек) нужно было учить. И с каждым годом учить все дольше; гораздо проще писать старым привычным методом и доставлять продукт быстрее.
Но факт остается фактом: иногда новые технологии остаются и меняют всю парадигму целиком. И тут возникает выбор: оставаться в старой парадигме или переходить в новую. Cobol-программисты до сих пор могут устроиться на работу, perl-разработчики помнят про booking, но альтернативных путей для этих людей становится всё меньше и меньше. И тогда «ретроградство» во имя стабильности становится ограничением. Со всем современным стеком, если вы не хотите себя ограничивать, время уже не то, что пришло, а мы уже отстаем. И, если мы не хотим застрять в «perl»-е, надо учиться. Это занимает продолжительное время. Попробую рассказать свой пошаговый опыт в обучении.
Направления глубокого погружения
Поймите, как запускать приложения в докере. Прежде всего, ветеранам стоит понять, что способ «хранения» и «запуска» приложений изменился навсегда. Скорее всего, разработчик, который научился разработке в последние годы, вообще не представляет себе, как запускать приложение в продакшне без докера. В голове такого разработчика, вероятно, нет концепции «хранить файлы локально», кроме редких кейсов общего хранилища, но главное, что нужно понять «ветерану»: докер — это новый exe. У exe-формата, может быть, есть свои минусы, но никто уже об этом особо не думает.
Да, микросервисный подход стал стандартом. Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт; теперь таким же стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). Это разумно: при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое. Зачем и маленькие приложения писать микросервисно, можно поспорить, но и их в какой-то момент все стали писать в ООП-стиле— просто так привычно (см. выше про exe). Можно много рассуждать о том, что у межпроцессной коммуникации (особенно, построенной на TCP-стеке) существует миллион недостатков с точки зрения производительности (один сервис пойдет к другому по TCP вместо того, чтобы просто выполнить ассемблерный-call — вы представляете какая это разница в производительности?), но факт остается фактом — у микросервисов есть достоинства скорости разработки средних и больших проектов и они также стали стандартом. Поймите, как микросервисы между собой взаимодействуют (HTTP API, grpc, асинхронное взаимодействие через очередь — миллион способов), бонусом — поймите, что такое service mesh. (Минута гневного юмора: боже, ребята, они придумали разделить приложение, и оказалось, что коммуникация между разделенными приложениями — сложная шутка, поэтому они добавили еще один слой, чтобы облегчить межпроцессный ужас, за что это нам?)
Поймите, как управлять пачкой запущенных в докерах микросервисов. Итак, мы смирились, что приложения мы теперь запускаем в докере и что приложение мы разделяем на микросервисы. Теперь надо как-то управлять запущенными докерами. Можно делать это самому на выделенных серверах (и рулить, например Docker Swarm-ом, ну или собрать Kubernetes), а можно использовать сервисы, которые дают облака — контейнер-сервисы от AWS или Kubernetes. В использовании облаков есть одно очень большое преимущество. Вы, фактически, перестаете думать про слой, запущенный ниже менеджера контейнеров (SRE сейчас посмеются, но давайте признаемся — когда все стабильно, мы не лазим на ноды GKE руками в большинстве случаев). Таким образом, фактически, менеджер контейнеров, стандартом которого стал Kubernetes, превращается в операционную систему. В нём есть пакет-менеджеры, в него можно «ставить софт», в нём можно запускать «exe-шники» — докеры, в нём есть кронджобы. Kubernetes — это новая ОС.
Разберитесь, как докер-контейнеры надо будет доставлять. Выкладка простого сайта теперь занимает 5 минут, и люди считают это нормой. Надо собрать докер, протестировать, положить в registry и поместить в менеджер докеров (давайте будем говорить дальше Kubernetes). Это дикость (?), к которой все привыкли, это оптимизируется и это стандарт. CI/CD системы стали стандартом выкладки, и с ними надо разобраться. Также как и с GitOps.
Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое. Когда-то давно нормой было купить серверы, собрать их, привезти в ДЦ, поставить в колокейшн и скоммутировать. Даже для небольшого проекта. Потом на смену пришли Dedicated-серверы. Какому количеству людей приходит сейчас в голову на небольших и средних проектах мучаться, покупать и собирать железо? На смену Dedicated — на Западе уже сейчас, а в РФ скоро — придут облака. Об этом говорят сто лет, я использую AWS с 2008 года, и у него есть проблемы, но когда мы говорим о сервисе, который берёт на себя менеджмент Kubernetes (EKS, GKE, Kubernetes от Яндекса или Селектела), мне становится непонятно, зачем менеджить сам Kubernetes и дедики, если это делают другие ребята? Я же не меняю кулеры в дедиках больше… Вопрос распространенности on-premise дистрибуций Kubernetes в РФ — это вопрос курса доллара, закона о персданных и «молодости» российского клауд-хостинга. Рано или поздно это решится и on-premise станет дикостью, которую хотят энтерпрайзы и большие нагруженные проекты. С базами то же самое. Если мы говорим о большинстве приложений, которым не требуется супервысокая нагрузка или супермощный тюнинг, то облачный PostreSQL/MongoDB/MySQL дает огромное количество преимуществ. Не надо думать про тюнинг, не надо думать про бэкапы. Создать дев-сервер из продакшн-сервера — пара команд в облачной консоли. Я понимаю, что вся эта идея может вызывать гнев у админа: ребята, я и сам админ, но для большинства нехайлоад задач менеджмент баз, правда, не нужен. Возможно, AWS и GKE стоят дорого и недоступны нам из-за закона о персданных, но это лишь дополнительное время для отставания: рано или поздно те же фичи будут у Яндекса или Селектела, и парадигма сменится.
Поймите, что инфраструктуру теперь пишут. Я не любил IaaC, когда он был Chef-ом и Puppet-ом, но на смену им, слава богу, пришли более адекватные Terraform и Pulumi для описания того, что вы хотите поднять в кластере, и Ansible для работы внутри. Зайти и что-то поставить в шелл — теперь абсолютная дикость. Да, это быстрее и удобнее, но в новой парадигме — это дикость: вспомните про exe.
Курс глубокого погружения
Каким я вижу конкретный технический путь для того, чтобы понять, как работать с современным стеком?
1) Сделать триальный аккаунт на клауд-хостинге. Их предоставляют все хостинги. Я начинал с GKE, но можно, например, взять аккаунт на российских хостингах, если вы ожидаете, что работать будете, скорее всего, на этой территории.
Если Terraform/Pulumi поддерживают ваш клауд — описать инфраструктуру, которую вы хотите создать в них. Если у вас есть навыки программирования, я рекомендую Pulumi: вместо собственного SDL Terraform-а вы сможете писать на привычных языках и конструкциях.
2) Найти приложение и упаковать его в докер. Что тут упаковывать — выбор за вами. Я внезапно обнаружил для себя, насколько стал распространен NodeJS, и решил заняться глубоким изучением его эксплуатации, поэтому дальнейшую работу веду с нодой. Вот, например, бложик на NodeJS, который можно поднять, но вообще все на ваше усмотрение.
3) Разобраться с базовыми конструктами (под, деплоймент, сервис) K8S и задеплоить приложение руками в кластер K8S.
4) Разобраться с Helm-ом, написать Helm-чарт, задеплоить приложение Helm-ом.
Взять бесплатный план на CircleCI как CI-ке, которую не надо ставить, и конфигурировать: конфиги будут похожи на остальные системы.
5) Задеплоить приложение через CI-ку.
Разделить CI (то, что собирает приложение) и CD. Сделать CD по GitOps (см, например ArgoCD).
Что дальше
Где-то с этого момента вы, в принципе, будете в курсе основных базисов современного стэка.
Куда можно пойти копаться дальше?
- Если вы ищете работу/хотите работать на Западе, можно пойти в углубление знаний по клаудам: сдайте на Cloud Architect сертификат Google-а или аналогичный от AWS (мы в ITSumma недавно получили 3 таких сертификата). Это даст представление о фичах, которые дают клауды, и поможет в них ориентироваться. Хороший курс на linuxacademy.
- Сдайте на CKA: это уже сложная тема, но стоит того. Подготовка к экзамену даст огромный пакет знаний.
- Научитесь программировать, если не умеете. Я сейчас пошел изучать фронт и поражен тем, как всё изменилось. Мои знания закончились где-то в 2012-м или даже раньше, еще на JQuery, люди смеются. Фронт сейчас стал сложнее, чем бэкэнд, там огромное количество application-логики и при этом совершенно непривычные для меня парадигмы. Очень интересно!
А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
