Сейчас начинается самый продуктивный сезон сбора грибов. В этой статье я расскажу о технически успешной попытке сделать "оффлайновый" SMS-локатор, и о том, почему проект "не взлетел". И о том, при чём тут грибы :)

Начну издалека. С пяти лет я начал ходить в лес, чуть позже - на рыбалку, ещё позже, во взрослом возрасте — на охоту, а где-то с 2014-го года более-менее регулярно езжу искать потерявшихся в природной среде людей. Были и успешные поиски, и случаи, когда находили потерявшихся слишком поздно, и когда не находили совсем — причем, во многих случаях, у потерявшихся людей были с собой сотовые телефоны.

В 2017 мне в голову пришли мысли: ну хорошо, я сам пока здоровый, и хожу в лес один, наматывая с ружьем десяток километров за раз, но вот если со мной что-то случится - то как меня найдут? Да и чтобы близкие не беспокоились — можно ли их как-то держать в курсе? Есть ли надежные способы давать весточку о своем местонахождении?

Эта статья родилась случайно. Слоняясь по книжному фестивалю и наблюдая, как дочка пытает консультантов, заставляя их искать Иэна Стюарта, мой глаз зацепился за знакомые буквы на обложке: "Nginx".

Надо же, на полках нашлось целых три книги - не полистать их было бы преступлением. Первая, вторая, третья... Ощущение, будто что-то не так. Ну вроде страниц много, текст связный, но каково содержание? Установка nginx, список переменных и модулей, а дальше docker, ansible. Открываем вторую: wget, лимиты запросов и памяти, балансировка, kubernetes, AWS. Третья: GeoIP, авторизация, потоковое вещание, puppet, Azure. Ребята, а где про то, как вообще работает nginx? На кого рассчитаны ваши книги? На состоявшегося админа, который и так знает архитектуру этого веб-сервера? Да он вроде с базовыми настройками и сам справится. На новичка, который не знает как пользоваться wget? Вы уверены, что ему знание о существовании ngx_http_degradation_module и тем паче "облака" важнее порядка прохождения запроса?

Итак. О чем не пишут в книгах.
(здесь и дальше мы говорим только о NGX_HTTP_)

У меня возникла задача настроить отказоустойчивый Bare Metal кластер для комплексного приложения, в связи с чем и возникла данная статья. Сразу хочу сказать, что не являюсь экспертом в K8S, однако имею опыт развертывания продуктовых кластеров DC/OS (экосистемы, основанной на Apache Mesos).

Долгое время K8S меня отпугивал тем, что, при попытке его изучения, тебя закидывают кучей концепций и терминов, отчего мозг взрывается.

Представляю программу Тюремных Тренировок Пола Уэйда. Начнём с серии классических упражнений со своим весом для верхней части тела — отжиманиям.

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

Серия сосредоточена на цепочке из 10 последовательных упражнений. Когда освоите одно упражнение, то перейдёте к следующему и так далее…
Мы называем базовые упражнения как «10 уровней», и достигнув 10 уровня, вы станете сильнейшим настолько, насколько это возможно для человека в этих движениях. По этой причине, последняя ступень именуется «уровнем мастера». Вам станет понятнее, как это работает, если дополнительно ознакомитесь с книгой Тренировочная Зона (Издательство Питер).

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

Я занимаюсь автоматизацией тестирования в Яндексе с 2013 года. Из них более четырёх лет автоматизирую тестирование REST API-сервисов. На Heisenbug я рассказал об использовании OpenAPI-спецификации как основы для приёмочных тестов, а также о том, как легко поддерживать автотесты на огромное количество REST API-сервисов и добавлять автотесты на новые проекты.

Под катом — видеозапись и расшифровка моего доклада. Примеры из доклада есть на GitHub.

Предлагаю ознакомиться с расшифровкой доклада Ивана Пономарёва «Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем».

Рефакторинг кода может быть увлекательным, особенно если это код вашей инфраструктуры. К тому же Ansible-роли почему-то имеют тенденцию к быстрому увеличению сложности. И это добавляет «изюминку» в вашу задачу. Иван расскажет, как можно преодолевать сложность Ansible-кода с помощью тестирования. В Docker-контейнерах.
По мере разрастания кодовой базы в Ansible приходят знакомые проблемы: сложность поддержки кода, ошибки и страх изменений. У знакомых проблем есть знакомое решение: автоматическое тестирование и CI. В докладе Иван покажет, как с использованием ряда инструментов решить проблемы «хрупкости» Ansible-кода, выполнить статический анализ, протестировать Ansible-скрипты и настроить CI-системы для публикации ролей в Ansible Galaxy.

Расскажу о нашем опыте автоматического документирования 150+ микросервисов в системе LeanIX Enterprise Architecture Managment. Многое получилось, как мы и хотели, для чего-то пришлось делать специальные доработки, часть вопросов не смогли решить. Но в любом случае мы получили опыт и готовы им поделиться.

• У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
• В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".