​​Курс по документированию REST API на русском языке.

Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.

Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.

Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)

Факапы, история 3

Очередная история про гугл и k8s. Как вы помните, у гугла существуют maintaince window, во времена которых он без предупреждения может ради обновления версии куба просто положить весь ваш кластер. Да, чтобы вы понимали, не реже раза в месяц ваши ноды будут падать. Может быть все сразу, а может по очереди. Может сегодня одна, а завтра другая. Может она поднимется за 2 минуты, а может за 25. Вы можете заплатить чуть больше денег и разнести ноды по разным регионам, но в любом случае что-то когда-то будет падать. Поэтому делать решение без репликации никак не получится, всегда должна быть реплика, которая обслужит клиента.

Эта история будет про etcd кластер. В кубе etcd можно запускать при помощи etcd-operator. И довольно-таки ошибочно думать про такой кластер, как про кубовское решение с этими всеми его шедулерами. Т.е. чтобы вы понимали, когда устанавливается оператор - он делается по всем канонам куба. Вы выкатываете helm, создается deployment, куб будет следить сам за тем чтобы оператор работал. На этом всё. Вы спросите, а откуда же тогда берется кластер? Так вот, после выкатки оператора мы должны принести в кластер один или несколько объектов под названием EtcdCluster. В котором описывается название, размер и версия etcd кластера. Оператор перехватывает событие создания такого объекта, считывает параметры и создает поды нашего кластера в указанном количестве. Что здесь кажется странным? С точки зрения k8s поды без deployment\replicaset это просто некоторый висящий в воздухе контейнер, который можно убить и никто не заплачет. Вот и получается, что всю заботу о том чтобы контейнеры кластера работали берет на себя etcd-operator.

Теперь скрестим ситуацию из первого абзаца со вторым. Если гугл кладет все ноды, то у нас падают все поды кластера. И тут самый интересный момент. Их никто не переподнимет после того как ноды рестартанут. Почему? потому что в etcd-operator заложена такая логика. Нет персистенса - нет переподнятия. В итоге, для того чтобы избежать этой попоболи в CRD нужно добавлять примерно такие строки:

      kind: "EtcdCluster"
      spec:
        pod:
          persistentVolumeClaimSpec:
            storageClassName: XXXXXX
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: YYYYYYY

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

#fuckup

#infrastructure #devops
Инструкция как поднять пром с таносом и всем-всем-всем:
https://itnext.io/monitoring-kubernetes-workloads-with-prometheus-and-thanos-4ddb394b32c

Сегодня про Istio:

- Пошаговый гайд установки Istio (с помощью Helm)
- Istio оператор от Banzaicloud
- Обсуждение первой статьи на Reddit

- Сравнение Istio и Linkerd

#kubernetes #mesh #istio #linkerd

Поработал? Убери!

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

Делать это нужно так же, как в на верстаке в мастерской: поработал — убери. Оставляй после себя рабочее место чище, чем было до тебя. Видишь бумажку на полу — подбери и выкинь. Видишь говнокод — перепиши.

Если ваш ПР ничего не улучшает для других — это плохой ПР.

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

Если у вас на проекте все начнут следовать этому простому правилу, то ваша кодовая база начнёт ухудшаться гораздо медленнее.

Когда говорят, что механическая коробка передач авто позволяет лучше контролировать автомобиль и экономит топливо, имеют в виду -- обеспечивает возможность лучше контролировать и экономить. На практике 90% "ездоков" умеют на ней разве что на светофоре не глохнуть, а про экономию хорошо показывают тесты Mercedes - те и вовсе отказались делать "на ручке", потому что автомат пролезает в экологические нормы, а средний человек за баранкой - не очень.

Но почему-то про мир программистов так не размышляют.

Юнит-тесты не делают код надёжнее и дешевле вдолгую - они обеспечивают возможность это сделать. Но на практике 90% тестов проверяют "1+1=2" и такое похожее. 9 из 10 разработчиков не открыли НИ ОДНОЙ книги по разработке юнит-тестов.

Или ещё есть подход: комментарии зло, т.к. это значит, что код плохо понятен. На практике почему-то существует непоколебимая уверенность автора, что все (а уж автор - и подавно) умеют писать понятный и без комментариев код. И потому не оставляют комментариев!

Тысячи таких примеров.

#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 4
Никогда не удаляйте старый код! Обросшая ненужным функционалом, распухшая до пары десятков гигобайт кодовая база выглядит гораздо солиднее чем эти ваши хайповые микросервисы! А какое уважение внушает 20минутный билд! Просто упиваешься этим трепетом и ужасом в глазах коллег!
Зачем вообще что-то удалять?! Если не нужно, то, вообще-то, человечество изобрело комментарии. Вдруг потомкам пригодится! VCS есть? Ну и что?! Это еще надо искать потом, ветки переключать! А тут все рядом. Ваще, лучшая документация -- код, это всякий подтвердит, а еще лучше, если это будет вся история кода с 1947года!
Кароч сарказм-сарказмом, но корреляция между хреновым кодом и кол-вом брахла в кодовой базе явно имеется. Так что, коллега прав: поработал -- убери!

​​Написал тут небольшую заметочку (очень общую) о своём опыте приседаний с Kubernetes

Из первых рук, так сказать

#kubernetes

11 советов для тех, кто использует Redux при разработке React-приложений

https://habr.com/ru/company/ruvds/blog/456336/

Крутой сборник SQL запросов для мониторинга и проерки здоровья Postgres.

Какой index hit rate, статистика вакуума, неспользуемые индексы и тд.

https://github.com/lob/pg_insights

От себя еще добавлю полезный репозиторий с кучей крутых утилит: https://github.com/dataegret/pg-utils

A deep dive into Linux namespaces

Подробно про линукс неймспейсы.

http://ifeanyi.co/posts/linux-namespaces-part-1

#arch #microservices
На волне популярности микросервисов все стремятся окрестить свое детище микросервисной архитектурой, но почему-то у большинства это все вырождается в распределенный монолит с кучей chatty-коммуникаций между сервисами, jira ping-pong между командами при багфиксе и разработке новых фич и каскадные отказы на проде. Поэтому, специально для мамкиных архитекторов:
1. Если ваши сервисы не имеют смысла без остального ландшафта(не решают отдельную бизнес-задачу)
2. Синхронный обмен данными между сервисами — скорее правило, чем исключение

то, спешу обрадовать, у вас не микросервисы. Совсем. Ни по одной из известных(мне) таксономий.
При этом, если ваши сервисы спроектированы для минимального дублирования кодовой базы и функционала, то у вас скорее всего SOA(что не плохо), если нет, то поздравляю! Вы гордый родитель distributed monolith(а вот это уже беда).
Что бы не верить мне на слово предлагаю почитать Сэма Ньюмена, Марка Ричардса и Фаулера

#linux
Если что, cgroups и namespaces — фундамент контейнеризации, поэтому, что бы лучше вникнуть, вот еще коротенькая статья с основами и видос по сабжу

Вопрос: что разработчик должен знать о дизайне? А тимлид?

Если разработчик занимается интерфейсами, то базовые вещи вот такие:
— Теория близости и Закон Фиттса
— Анимация в интерфейсах
— Как писать тексты в интерфейсах

Идеально — освоить какой-нибудь дизайнерский инструмент, к примеру Фигму.

Когда закончите с технологиями, почитайте о продукте и результате:
— Понятие «боли» и «мира клиента», Джим Кэмп
— jobs-to-be-done или любая другая методика проектирования
— Психбольница в руках пациентов
— Intercom on Product Magement

Это был традиционный вопрос по понедельникам. Задать свой — @fedor_borshev, посмотреть другие ответы — #вопрос

Egor Rogov начал новую серию статей. На этот раз герой статей - WAL. Первая статья посвящена буферному кешу. https://habr.com/ru/company/postgrespro/blog/458186/?fbclid=IwAR2JxwviUYaIRy3GrK3pcLlu-qVmp1a4Q5-wQb7z1CJjOmk9hAhVEXjbwtY

Без лишних слов, сравнение Thanos vs VictoriaMetrics

https://medium.com/@valyala/comparing-thanos-to-victoriametrics-cluster-b193bea1683

Очередной консольный GUI к Docker — настоящий хит последних дней в мировом около-DevOps-сообществе. Рассказали об утилите в своем блоге: https://habr.com/ru/company/flant/blog/446700/

Тут у Nginx'а вебинар по ServiceMesh'ам наклевывается. Присоединяйтесь

Нарезали вам все видео с @Kubernetes Meetup #3.