Уровни журнала

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

Прим. перев.: автор данного исследования — Marc Richards, Solutions Architect и DevOps-инженер — продемонстрировал потрясающую настойчивость и тщательность в тотальной оптимизации производительности веб-приложения. Получившийся материал — кладезь полезных знаний для расширения своего кругозора в области оптимизации, особенностей сетевого стека в Linux и не только, даже вне зависимости от практической заинтересованности в конечном результате автора. Приготовьтесь к по-настоящему длинному техническому путешествию с обилием терминологии, увлекательных графиков и полезных ссылок.

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

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

Это расшифровка выступления на DevOps-40 2020-03-18:

Начиная со второго коммита любой код становится legacy, т.к. изначальные задумки начинают расходиться с суровой реальностью. Это не хорошо и не плохо, это данность с которой сложно спорить и необходимо уживаться. Частью этого процесса является рефакторинг. Рефакторинг Infrastructure as Code. Да начнется история как отрефакторить Ansible за год и не слететь с катушек.

Это расшифровка выступления на DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

Это история проекта, на котором использовалась самописная система управления конфигурациями и почему переезд на Ansible затянулся на 18 месяцев.

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

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

• использование меток (labels) для хранения данных
• потребление малого количества ресурсов

Несколько слов о Prometheus

Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

Предлагаю ознакомиться с расшифровкой доклада Дениса Яковлева "Автоматизация инфраструктуры. Зачем мы это делаем?"

Сам доклад 2016 года. Доклад специально расшифровал для тех, которые создают виртуальные машины руками.

Доклад о том, как мы в компании 2ГИС автоматизировали работу с инфраструктурой.

«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее» (Алиса в стране чудес).

Что эта фраза означает для нас? В условиях жесткой конкуренции, компании должны стремиться доставлять свои продукты до пользователей максимально быстро. Уменьшение параметра time to market — задача многоуровневая. Чтобы ее решить надо менять как процессы разработки, так и инструменты. Важной основой всего процесса разработки является инфраструктура. Чем больше инфраструктура, тем больше с ней проблем, use case'ов и т.д. Если все операции с ней не автоматизированы, то число проблем увеличивается. Одной из них является время, которое разработчик тратит на инфраструктурные вопросы вместо того, чтобы писать бизнес логику.

Поговорим о том:

• Какие проблемы с инфраструктурой стояли перед командами;
• Как от этого страдали процессы разработки и тестирования;
• Как мы внедрили OpenStack;
• Какие у нас есть сценарии использования OpenStack;
• Как автоматизация получила дополнительный толчок в развитии и начали появляться новые внутренние продукты;
• Какие аспекты у нас остались не автоматизированы.