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

Прошло уже почти 5 лет с тех пор, как я избрал Terraform в качестве одного из основных наборов инструментов DevOps и облачной инженерии для управления сервисами моих проектов на AWS, Azure, OpenStack, Github и Datadog. Его очень удобно использовать благодаря простому и понятному человеку синтаксису, а также огромному количеству модулей в реестре HashiCorp. Кроме того, множество поддерживаемых сервисов стали очень популярными среди DevOps и Cloud инженеров, ведь у вас в итоге может быть всего один инструмент для выполнения всех ваших ежедневных IaC рутин.

В этой статье я поделюсь своим опытом в отношении соглашений об именовании при написании стандартных блоков кода в Terraform. Некоторые из них стремятся улучшить стандартный файл Terraform, а некоторые необходимо учитывать из-за скрытых ограничений в соглашениях об именовании в API поставщиков, таких как AWS и Azure.

Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.

Сегодня состоялся долгожданный публичный Open Source-релиз нашей платформы для автоматизации обслуживания кластеров Kubernetes — Deckhouse. Этому предшествовало три с половиной года внутренней разработки и эксплуатации платформы на многочисленных и весьма разнообразных проектах. Сейчас с помощью Deckhouse мы обслуживаем в production более 170 кластеров (3500+ узлов), в которых развернуто около 3000 приложений. Deckhouse — это квинтэссенция нашего опыта в эксплуатации Kubernetes-кластеров и кульминация всей связанной с этим производственной деятельности последних лет.

Мы начали выдавать ранний доступ к платформе и демонстрировать её возможности ещё в мае, на конференции HighLoad++. Уже более 300 человек смогли самостоятельно попробовать Deckhouse. Пришло время поделиться нашим опытом автоматизации Kubernetes с более широким сообществом!

«Мне 34, и я 10 лет работаю в ИТ. Первый компьютер я увидел в каталоге OTTO, мне тогда было 5 лет, я жил в Германии. Это был ATARI. Меня сразу заинтриговал принцип его работы — мы вводим информацию и получаем ожидаемый результат на выходе. Круто, но события 90-х годов отодвинули мечту на много лет. И вот, наконец, в 2001-м у меня появился свой ПК. К слову, операционную систему я переустановил через 2 недели использования. С этого всё началось. Пока сверстники играли в ходилки и стрелялки, я методом научного тыка изучал устройство Windows 98. Потом вышла XP, был Dial-up в 56 kbps и долгие часы скачивания разнообразных программ, форумы, журналы CHIP и первый дистрибутив Alt Linux на CD.   

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

С такими мыслями я «собрал пожитки» и отправился прочь из зоны комфорта на поиск новых знаний в области инструментов концепции DevOps. Кто ищет ― тот найдёт, сказал я сам себе и спустя 10 минут заполнял анкету на поступление в DevOps-школу в EPAM»...  

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

0. Вступление

О Kubernetes и его роли в построении микросервисных приложений известно, пожалуй, большинству современных IT-компаний. Однако при его внедрении часто возникает вопрос — какой вариант установки выбрать: Self-Hosted или Managed-решение от одного из облачных провайдеров. О недостатках первого варианта, думаю, известно всем, кто проходил через ручное конфигурирование K8s: сложно и трудоемко. Но в чем лучше Cloud-Native подход?

Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу развертывание Kubernetes-кластера на базе облака Mail.ru Cloud Solutions. В этом цикле статей мы создадим MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube. 

Представьте, что у вас есть свой канал в телеге. Допустим, вы высказываете непопулярную политическую точку зрения и, соответственно, ловите хейт в личку со стороны читателей и проходящих мимо. Или вы продаете что-то через свой канал, но клиентов так много, что один продажник не справляется.

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

Я расскажу, как запустить такого бота бесплатно в 1 клик, и поделюсь кодом.

"The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code — not in reams of trivial code that bores the reader to death."
Guido van Rossum

Светлячок