BLOG Мои нотатки

[fantom]

В первую очередь создаю для себя, так как стало сложно как то организовать методологию хранения и структурирования информации.
В последнее время я сильно ударился головой в архитектуру сложных масштабированных приложений, и существует множество паттернов, и тулзов для их решения.
Наверно я начну с тулинга. Первым о чем хотелось бы поделится, так это о контейнеризации наших приложений. Это проблему уже давно и успешно решает docker. До этого был vagrant со своим оверхедом на виртуалку. Для чего это нужно. Ну, во-первых, вы из коробки получаете единственную среду как локально, так и на проде/деве/стейджею А во-вторых у вас деплоймент процесс становится значительно проще. Ведь все что вам нужно, так это собрать образ и раскатать его по вашим нодам в облаке/сервере (это намного проще чем каждый раз качать исходники, их компилить/транспилить, и запускать). Ну а в-третьих у вас все таки как-никак, а бонусом изоляция, что означат то, что один процесс не может повлиять на работу другого (банально запись в один и тот же файл. Тупой пример, но что пришло в голову). И так, для начала хотел бы поделиться сериею видео о внутреннем устройстве докера, что это и как оно работает:

11 Окт 2020

Следующим тулингом будет оркестрация этих самых докер образов. Их запуск, discovery, добавление/удаление контейнеров, zero downtime deployment и много других ништяков, о которых можно легко нагуглить. Сейчас парадом рулит Kubernetes. Я давно нашел очень прекрасную презентацию, но увы k8s (Kubernetes сокращенно) настолько часто изменяется, что в нем важно лишь концепции. А именно с рассказом о концепции это видео справляется на ура. Также не стоит забывать, что k8s немного разный везде, и имеет свои тонкости при конфигурировании (у AWS, GCP и Azure он немного разный). Собственно само видео:

Также для того, чтобы не заниматься копипастом и рутиной используют Helm (шаблонизатор для k8s конфигов):

 

[fantom]

Теперь я бы поговорил о секретах. Секрет - это токены к сервисам, соль для хэшей, доступы к базе и все такое, что должно остаться в тайне и охраняться за семью замками. Для этого используют Hashicorp Vault. На эту тему у ребят из Авито есть интересный доклад. Рекомендую к просмотру. Тут рассказано как они его готовят и есть несколько интересных мыслей.

11 Окт 2020

Следующим звеном во всем этом театре, это мониторинг. Это prometheus. Интересный доклад на этому тему. Тут рассказано о том, зачем это нужно и как готовить.

 

[fantom]

Логи. Это неотъемлемая часть любого приложения. Коротко о главном рассказывают ребята из Яндекс-а. Из главного могу отметить, что тут показано что и как нужно логировать.

В дополнение к теме о логах, также стоит упомянуть об opentracing, а именно об Zipkin и Jaeger. Позже найду в истории видео об Jaeger.

 

[SergeyShorokhov]

Благодарю тебя за информацию, она мне оказалась полезной.
Хотелось бы от тебя прочитать мнение о Ansible.
Он упрощает разворачивание ПО, автоматизируя, требуя иногда лишь доступ по SSH на сервере, имея удобные конфигурации и гибкую систему с модулями. Допустим, с его помощью можно за 1мин развернуть и включить новый игровой сервер (из практики).

Если соотносить к highload - для шустрого масштабирования инфраструктуры.

Так же по теме сборки логов. Интересно твоё мнение, про обработчики (Fluentd), про работу с брокерами месседжей (Kafka, RabbitMQ, etc..), возможно, имел дело с amqp приёмниками для очередей, и про то, как эти логи грамотно создавать (на примере, одной из верных концепций - Стажёр Вася и его истории об идемпотентности API).

 

[fantom]

Хотелось бы от тебя прочитать мнение о Ansible.

Я им не пользовался, но насколько я знаю это "автоустановщик". И насколько я понял, то по сути докер + к8с заменяют его с головой. Плюс изоляция.

Так же по теме сборки логов

Скажу так, есть разные сервисы для сбора логов. И это реально удобно чем читать файлики. Банально групировка ошибок. Это нереально полезная вещь. Ведь ты можешь заметить что у тебя часто валится код в этом вот месте. А значит требует неотложенного вмешательства. Также они позволяют отображать трейсы, уровни, окружения и прочего. В общем очень удобно. Но как правило все они платные. Популярное решение ELK, но я так и не увидел плюсов для себя пока что.

работу с брокерами месседжей

С имел дело, а вот с кафкой не разу. Есть видео кратко объясняющее различия. И казалось что один что второй брокер, и они такие одинаковые, но на самом деле они разные. И если как роутить в рабите я понял, то вот как это делать в кафке я не до конца понимаю (просто нет опыта). Но скажу сразу, они очень легко масштабируемые. А количество сообщений которые они могут обработать невероятное. Увы везде свои подводные камни. В rabbitMQ есть подтверждение доставки. Крутая фича, но в то же время сильно снижает количество ивентов (что логично). Также есть 2 варианта: хранение в памяти и память + сброс на диск. Во втором случае вопрос что будет если оно упадет между интервалами сброса на диск. В кафке как говорил я не понял как плодить сложній роутинг, и как сделать подписку на ивент многих консьюмеров.

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