Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
Пользователь
Деплоим проект на Kubernetes в Mail.ru Cloud Solutions. Часть 2: настройка и запуск приложения для транскрибации видео
Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу все этапы разработки Cloud-Native приложений на K8s: от запуска кластера до построения CI/CD и разработки собственного Helm-чарта.
Напомню, что в первой части статьи мы выбрали архитектуру приложения, написали API-сервер, запустили Kubernetes c балансировщиком и облачными базами, развернули кластер RabbitMQ через Helm в Kubernetes. Сейчас во второй части мы настроим и запустим приложение для преобразования аудио в текст, сохраним результат и настроим автомасштабирование нод в кластере.
Деплоим проект на Kubernetes в Mail.ru Cloud Solutions. Часть 1: архитектура приложения, запуск Kubernetes и RabbitMQ
О Kubernetes и его роли в построении микросервисных приложений известно, пожалуй, большинству современных IT-компаний. Однако при его внедрении часто возникает вопрос — какой вариант установки выбрать: Self-Hosted или Managed-решение от одного из облачных провайдеров. О недостатках первого варианта, думаю, известно всем, кто проходил через ручное конфигурирование K8s: сложно и трудоемко. Но в чем лучше Cloud-Native подход?
Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу развертывание Kubernetes-кластера на базе облака Mail.ru Cloud Solutions. В этом цикле статей мы создадим MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
«Не жалко людей, которых уволили благодаря твоей работе?» — интервью с Андреем Маркеловым, инженером Atlassian
Андрей Маркелов работает в компании Atlassian над продуктом Confluence Cloud. В прошлом работал в Mail.ru, был аутсорсером в NFL.com, работал в advertising-стартапе. Много времени отдал компании Infobip.
Андрей в индустрии с 2007 года. Больше 5 лет занимался аутсорсом для IBM, когда десктопные приложения были еще очень популярны. Там он делал DB2 Recovery Expert for Multiplatforms и другие странные продукты, которые до сих пор существуют, но не имеют широкой популярности. Сейчас переехал жить в Долину.
Мы поговорили с Андреем про то, как сделать себе имя, разрабатывая плагины на голом энтузиазме, почему опытные разрабы мучаются от синдрома самозванца, каково работать над продуктом, которым пользуется половина индустрии, и куда движутся технологии.
«Представь, что ты нашел решение, про которое можешь сказать: оно лучшее в мире» — интервью с создателем ClickHouse
Алексей Миловидов работал инженером в Яндекс.Метрике, и перед ним стояла непростая задача.
Яндекс.Метрика работала с петабайтами данных — это был третий по популярности сервис веб-аналитики в мире. Для него нужна была база данных, которая может обрабатывать огромное количество данных в реальном времени, очень быстро, при этом не сжигая миллиарды денег.
Долгое время такая СУБД разрабатывалась только для внутренних нужд — но в 2016 вышла в опенсорс под названием ClickHouse, и сообщество встречает инструмент по-разному.
Мы поговорили с Алексеем о том, как он стал разработчиком, почему ClickHouse намного быстрее всех аналогов и как так получилось, какова цена производительности, почему ClickHouse стал опенсорсным и куда вообще движется индустрия.
Три года назад нужно было изучать Docker, два года назад — Kubernetes. Сейчас — Serverless
Антон Черноусов — developer advocate — пришел в Yandex.Cloud, чтобы заниматься микросервисами, популярными в индустрии Docker и Kubernetes . Но главная его профессиональная страсть — это Serverless. Мы поговорили с Антоном, и он объяснил, почему бессерверные платформы ждет большое будущее.
Почему язык Go стал стандартом для DevOps-инженеров
Иногда вещи находят себе применение неожиданно и не в том, для чего их задумывали.
В 1960-е годы Кен Томпсон — легенда программирования — написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix.
Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык — так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.
Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang — один из самых популярных языков последнего времени.
Разрабы становятся админами, а админы — разрабами. Интервью с инженером Uber, где разделение исчезло совсем
Данила Мигалин (@miga) живет в Вильнюсе и работает инженером в Uber.
Давным-давно контора, которая занималась русификацией игр, не взяла его работать переводчиком. На следующий день он устроился админом, потому что в школе увлекался программированием. «Русское IT — это большая деревня, одни и те же люди переходят из компании в компанию. До Uber я успел поработать в Яндексе и Майкрософте», — говорит Данила.
С 2006 года он занимался ip-телефонией и админской работой. В свободное время писал на Перле, затем на Питоне, делал свои пет-проекты. Некоторые из них даже пошли в продакшн и в Яндексе, и в Майкрософте. Писать по-серьезному в продакшн он начал, только когда пришел в Uber. «Место, которое мне предложили в компании, предполагало знание Golang. Меня не смутило то, что я иду админом на позицию разработчика. Я думал: отлично, наконец-то можно будет завязать с админским делом и спокойно писать код».
Неужели нельзя обойтись без кафок и рэббитов, когда принимаешь 10 000 ивентов в секунду
Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!»
Очень смешно, но давайте я все-таки объясню.
Ультимативный гайд по собеседованию DevOps-инженеров — что спрашивать и к чему готовиться
Я начал заниматься сетями еще в школе, а работаю за деньги больше 16 лет. Я много куда устраивался, в большие компании и маленькие, потом открыл свой бизнес и регулярно сам нанимаю людей. С годами и опытом у меня, да и у многих, вырабатывается интервьюшная интуиция.
Это когда никакого четкого алгоритма нет. Ты просто разговариваешь с человеком и что-то для себя понимаешь. Спрашиваешь, что кандидат делал на прошлой работе, цепляешься за тему — и вот вы уже просто обсуждаете инженерные темы, примерно на том же уровне, что и с коллегами. Если беседа клеится и человек нравится, то все хорошо.
Такой интуиции вряд ли научишься по книгам и текстам, она приходит сама с опытом. Вместе с ней в мышление просачиваются фразы вроде «мне не так важны конкретные знания, как общий кругозор, способность искать информацию, понимание, сработаемся ли» и все такое.
Но иногда, чтобы не терять хватку, надо все же напоминать себе, какими знаниями должен обладать инженер и какими вопросами можно максимально объективно оценить человека, которого видишь впервые в жизни.
Я занялся преподаванием и не бросил работу. Совмещать — офигенно
В 11 классе я пошел на курсы для сертификации CISCO. Я, как всегда и везде, был самый молодой в группе. Вокруг сидели дядьки — руководители IT-отделов, а мне было 16 лет.
У нас был очень крутой инструктор – Сергей Петухов. Мы хорошо с ним общались, и он рассказывал про то, как трудно получить последний уровень ССIE. Его сдают в Брюсселе, в лаборатории. Привозят туда на 8 дней, дают огромный тест на теорию и реальную задачу: «Вот железо, настрой вот такую схему, делай, как считаешь правильным».
Сергей жаловался, что в России тяжело набраться практики в работе с сетевыми железками. Они дорого стоят, и тогда были только у крупных операторов большой тройки. Если ты работаешь с сетями там, то сможешь набрать необходимый уровень знаний и опыта. Не работаешь — не сможешь.
У Сергея был друг, который работал в МТС, и он постоянно говорил: «Серега, проблема в том, что ты преподаешь. Ты хорошо знаешь только теорию». Друг был наоборот — первоклассным практиком.
Тогда мне казалось, что это и правда вопрос выбора — что ты хорош либо в теории, либо в практике, что ты либо работаешь сам, либо учишь других.
Но соль в том, что поехать и сдать CCIE не смог ни тот, ни другой.
Пока все праздновали мой день рождения, я до утра чинил кластер — а разрабы валили на меня свои ошибки
Вот история, которая навсегда перевернула мой подход к работе девопса. Еще в доковидные времена, задолго-задолго до них, когда мы с парнями только задумывали свое дело и фрилансили на случайных заказах, мне в телегу упало одно предложение.
Компания, которая написала, занималась аналитикой данных. Ежедневно она обрабатывала тысячи запросов. К нам они пришли со словами: ребят, у нас есть ClickHouse и мы хотим автоматизировать его настройку и установку. Хотим Ansible, Terraform, Докер и чтобы это все хранилось в гите. Хотим кластер из четырех нод по две реплики в каждой.
Стандартная просьба, каких десятки, и нужно такое же хорошее стандартное решение. Мы сказали «окей», и через 2-3 недели все было готово. Работу они приняли и начали переезжать на новый кластер Кликхауса с помощью нашей утилиты.
В Tarantool можно совместить супербыструю базу данных и приложение для работы с ними. Вот как просто это делается
Ради любопытства я решил вернуться к нему, протестировать последнюю версию — и на этот раз проект мне очень понравился. Сейчас я покажу, как написать в Tarantool простое приложение, нагружу его и проверю производительность, и вы увидите, как там все легко и круто.
Восторг безопасника — технология для шифрования образов контейнеров
Принимаем 10 000 ивентов в Яндекс.Облаке. Часть 2
Давайте вспомним план, по которому мы с вами двигаемся:
1 часть. Мы определились с ТЗ и архитектурой решения, написали приложение на golang.
2 часть (вы сейчас здесь). Выливаем наше приложение на прод, делаем масштабируемым и тестируем нагрузку.
3 часть. Попробуем разобраться, зачем нам нужно хранить сообщения в буфере, а не в файлах, а также сравним между собой kafka, rabbitmq и yandex queue service.
4 часть. Будем разворачивать Clickhouse кластер, писать стриминг для перекладывания туда данных из буфера, настроим визуализацию в datalens.
5 часть. Приведем всю инфраструктуру в должный вид — настроим ci/cd, используя gitlab ci, подключим мониторинг и service discovery с помощью consul и prometheus.
Ну что, переходим к нашим задачкам.
Принимаем 10 000 ивентов в Яндекс.Облаке. Часть 1
* Эта статья написана по мотивам открытого практикума REBRAIN & Yandex.Cloud, если вам больше нравится смотреть видео, можете найти его по этой ссылке — https://youtu.be/cZLezUm0ekE
Недавно нам представилась возможность пощупать вживую Яндекс.Облако. Поскольку щупать хотелось долго и плотно, то мы сразу отказались от идеи запуска простого wordpress блога с облачной базой — слишком скучно. После непродолжительных раздумий решили развернуть что-то похожее на продакшн архитектуру сервиса для приема и анализа ивентов в near real time режиме.
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Works in
- Date of birth
- Registered
- Activity