CockroachDB — это распределенная РСУБД, написанная на Go. Является представителем так называемых NewSQL баз данных, которые пытаются совместить в себе горизонтальную масштабируемость и высокую доступность NoSQL решений с интерфейсом (SQL) и строгостью (ACID) традиционных РСУБД. Помимо прочего, CockroachDB интересен тем, что реализует протокол PostgreSQL, что упрощает портирование на него существующих приложений. Давайте же попробуем поднять свой кластер CockroachDB и поработать с ним.
При использовании Raspberry Pi в качестве роутера я столкнулся с одной проблемой. Дело в том, что дома иногда отключают свет. По моим наблюдениям, это происходит ненадолго и только в рабочие часы. Видимо, неподалеку идут какие-то ремонтные работы. Так вот, когда это происходит, мне приходится заходить на малину по SSH и запускать все, что в ней крутилось в tmux — как минимум, это OpenVPN. Мне также приходится выставлять время на микроволновке и газовой плите, поскольку в них сэкономили на часах реального времени, но это другая история. Так или иначе, встал вопрос о приобретении UPS для моего роутера.
В рамках поста Быстрое введение в Kubernetes мы познакомились с основами использования кубера, однако для его развертывания было предложено использовать либо Docker Desktop, либо облака. Давайте попробуем заполнить этот пробел, подняв простейший однонодовый кластер Kubernetes на машине под управлением Ubuntu Linux 18.04 LTS.
Так исторически сложилось, что для сохранения сессии при работе по SSH или чего-то такого обычно я использую screen. Но бывает, например, что ты работаешь с машиной, где у тебя нет рутовых прав, и где не установлен screen, но зато есть tmux. Поскольку я плохо помню сочетания клавиш tmux, то решил выписать их для себя в виде небольшой шпаргалки.
Kubernetes (часто сокращают до k8s) — открытая система оркестрации контейнеров, представленная компанией Google в 2014 году. Kubernetes реализует идею, ранее использованную во внутренней системе Google под названием Borg [PDF]. Если вкратце, идея состоят в том, что ваш деплоймент строится на базе контейнеров (например, Docker), а также описании того, сколько этих контейнеров нужно и какие ресурсы они используют. Kubernetes на базе этого описания и доступных физических машин разворачивает контейнеры и делает все возможное для поддержания требуемой конфигурации. В том числе, он перезапускает упавшие контейнеры, перемещает их для выделения ресурсов, необходимых новым контейнерам, и так далее.
Если вы давно читаете этот блог, то можете помнить некоторые старые посты, посвященные мониторингу. В частности, была рассмотрена связка из Graphite, StatsD и CollectD, а также, несколько поверхностно, сервис Datadog. Однако мир не стоит на месте. Приходят новые технологии, некоторые из которых даже оказываются лучше своих предшественников. В качестве таких новых технологий можно привести в пример связку из Prometheus и Grafana.
Беспроводные роутеры имеют несколько неприятных особенностей. Во-первых, они небезопасны, если только не разобраться с установкой OpenWrt. Во-вторых, со временем они перестают выпускаться, а значит, если ваш роутер сломается, вам придется разбираться с установкой OpenWrt на совершенно другой роутер. В-третьих, как правило, они довольно ограничены в ресурсах, а значит возложить на роутер какие-то дополнительные функции может быть проблематично. Между тем, абсолютно любой компьютер под управлением Linux может быть настроен в качестве полноценного Wi-Fi роутера, что решает проблемы безопасности, повторяемости и производительности. Для примера, рассмотрим создание беспроводного роутера на базе одноплатного компьютера Raspberry Pi.
Благодаря заметке Изучаем Ethernet-фреймы с помощью осциллографа теперь мы знаем, как физически осуществляется передача данных по Ethernet-кабелю. Однако описанный в посте подход не слишком удобен для полноценной отладки какого-то устройства, работающего с Ethernet. Есть несколько решений этой проблемы. Например, можно воспользоваться старым Ethernet-хабом (но нынче их не так-то просто найти) или настроить зеркалирование портов на Ethernet-свиче. Но в рамках этого поста мы рассмотрим альтернативное решение, которое заключается в использовании платы Throwing Star LAN Tap.
Как вам может быть известно, я не очень доверяю SaaS-решениям. Причин тому больше одной. SaaS’ы оставляют за собой право менять Terms of Service в любой момент как им вздумается. SaaS’ы сливают персональные данные. SaaS’ы меняют пользовательский интерфейс и функционал на свое усмотрение. Наконец, если вы используете SaaS’ы от какого-нибудь Google, то однажды получив в них бан за любое нарушение ToS (который, напомню, постоянно меняется), назад вы больше никогда не разбанитесь. В прошлой статье мы решали описанные проблемы, поднимая / перенося на VDS свой блог. Сегодня же мы попробуем разобраться, как с нуля поднять собственный почтовый сервер с TLS, спам-фильтром и списками рассылок.
Когда я начинал вести этот блог в 2009 году, хостить сайты, особенно небольшие, на VDS как-то не было принято. (Не говоря уже о том, что сами идеи «посвящать самому себе сайт» / «вести общедоступный дневник» были еще новыми и казались немного дикими.) Главным образом, все использовали shared hosting, потому что он стоил дешевле VDS и решал свою задачу — сайт работал, странички открывались. Сегодня, конечно же, все сильно изменилось. Не только VDS стали дешевле, но и современные браузеры стали ругаться на сайты, не использующие HTTPS. А за сертификаты хостинг-провайдеры берут деньги. Еще бы, ведь у клиентов нет на сервере рутовых прав, а значит Let’s Encrypt они прикрутить не могут. В любом случае, в современных реалиях держать сайт на шаред хостинге иначе как зашкваром не назовешь. Поэтому я решил рассказать о своем опыте переноса сайта на VDS, на примере этого самого блога.