В этой статье мы рассмотрим из чего состоит Terraform, а также поэтапно запустим собственную инфраструктуру на облаке с VMware — подготовим три VM для разных целей: прокси, файловое хранилище и CMS.

Мы все знаем, что большинство DBA очень консервативны и предпочитают, чтобы их базы жили исключительно на выделенных серверах. В современном мире с микросервисами, Kafka и Kubernetes количество баз начинает расти прямо пропорционально размеру организации и очень быстро выходит за пределы комфортного ручного или полуавтоматического управления.

Чуть больше года назад я столкнулся с тем, что на внутреннем проекте совсем не айтишной компании вырос целый отдел веб-разработки, которым мне и довелось руководить. Рабочий процесс вроде как устаканился и всех устраивал, но оставались проблемы:

• Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
• Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

• типовой рабочий процесс от постановки задач до релиза;
• инфраструктурное решение для построения любого современного процесса разработки с использованием минимального количества инструментов;
• пример для часто встречающегося кейса: разработка веб-приложения;
• видеозапись доклада, где вживую показывается результат.

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

На заре MySQL понимание всех тонкостей и нюансов использования памяти было трудным и включало очень много догадок. Быть может, для выполнения некоторых запросов требуется большая временная таблица или выделение больших объемов памяти для сохраненных пользовательских переменных? Может, какие-либо хранимые процедуры занимают неожиданно большой объем памяти? Причиной чрезмерного использования памяти MySQL могло оказаться что угодно, но у вас не было легких путей понять и быть уверенным, что именно.

Все это изменилось в MySQL 5.7, который добавил инструментарий для отслеживания памяти в Performance Schema, а в MySQL 8.0 этот инструментарий стал включен по умолчанию, поэтому вы можете получить эти данные практически с любого работающего инстанса.

Один из способом сделать доступным некоторые внутренние (домашние) сервисы из Интернета является VPN. Можно, конечно, отдельные порты опубликовать и через ssh, но для более полноценной связи лучше использовать другие решения. Я уже писал и про ZeroTier, и про OpenVPN, и получил упреки, что незаслуженно забыл про Wireguard…

Так или иначе, мне стало не хватать VPN клиента (в т.ч. и Wireguard) на отдельно стоящем серверочке, потребовалось связать (в данном случае с vNet в Azure, хотя это не принципиально) всю домашнюю сеть с несколькими ресурсами. И я решил, что пора уже сделать это через роутер, для полноценного site-to-site.

Хотя Keenetic и научился поддерживать Wireguard на новых прошивках, для старенькой Ultra я такой не нашел. С OpenWRT тоже не срослось (для Ultra II есть, а моя моедль старовата). Так что я решил, что пора проапгрейдиться. И, поскольку Mikrotik RouterOS выкатила бету 7 версии с Wireguard, я решил, что пора изучить это чудо.

Действительность оказалась несколько сложнее, чем я рассчитывал, однако все получилось. И сейчас опишу основные моменты, которые нигде не смог найти, и до которых пришлось доходить самому.

Мы в okmeter.io в какой-то момент поняли, что нам тоже нужен k8s в production, хотя у нас нет даже CI/CD, но есть задача делить общий пул серверов между приложениями и достаточно легко добавлять мощности в кластер. При этом был ряд обстоятельств, которые усложняли внедрение k8s:

• мы очень заботимся об отказоустойчивости (мы не притаскиваем новые технологии в prod, пока не разберемся в них на достаточном уровне);
• у нас есть сервисы со временем ответа меньше 10ms;
• у нас очень мало человеческих ресурсов на эту задачу (узнать 10 новых терминов ОК, 50 — уже нет).

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

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

В начале была технология и называлась она BPF. Мы посмотрели на нее в предыдущей, ветхозаветной, статье этого цикла. В 2013 году усилиями Алексея Старовойтова (Alexei Starovoitov) и Даниэля Боркмана (Daniel Borkman) была разработана и включена в ядро Linux ее усовершенствованная версия, оптимизированная под современные 64-битные машины. Эта новая технология недолгое время носила название Internal BPF, затем была переименована в Extended BPF, а теперь, по прошествии нескольких лет, все ее называют просто BPF.

Грубо говоря, BPF позволяет запускать произвольный код, предоставляемый пользователем, в пространстве ядра Linux и новая архитектура оказалась настолько удачной, что нам потребуется еще с десяток статей, чтобы описать все ее применения. (Единственное с чем не справились разработчики, как вы можете видеть на кпдв ниже, это с созданием приличного логотипа.)

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

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

Огромное множество игр на самом деле содержат тайлы - так просто проще представлять игровой мир. Такая упорядоченность помогает геймдизайнерам строить игровые механики, упрощает жизнь художников и делает код программистов понятнее. Самих видов тайлов тоже огромное количество - сегодня поговорим о прямоугольных и изометрических.

Бывают ситуации, когда нужно упаковать Python пакет c его зависимостями в rpm пакет.

В этом посте будут рассмотрены 2 варианта: fpm и rpmvenv.

fpm — программа для простой упаковки программ в rpm, deb и другие пакеты.

rpmvenv — программа для упаковки virtualenv программ в rpm.

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

Добрый день, Хабр! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ и сжать в короткие рекомендации и выводы.

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