-
ActiveRecord Connection Pool требует к себе внимания
Любому, кто работает с Rails продолжительное время, известно, что ActiveRecord управляет соединениями с базой данных через пул (Connection Pool). Пул соединений синхронизирует доступ потока к лимитированному числу соединений к БД. Базовая идея такая, что каждый поток берет соединение из пула, использует его и кладет обратно. Сам ConnectionPool полностью потокобезопасный и исключает ситуацию использования одного и того же соединения двумя потоками в одно и тоже время. Также в его обязанности входит обработка случаев, когда потоков больше соединений. Т.е. если соединения в пуле закончились, но в текущем потоке требуется новое, то поток блокируется до тех пор, пока какой-нибудь другой поток не освободит соединение или не истечет таймаут.
-
Ньюансы AWS CloudTrail Events и CloudWatch Events
Возможно кому-то это сразу показалось очевидным, но я только спустя некоторое время осознал (после вдумчивого изучения документации), что у CloudTrail Events и CloudWatch Events разные назначения и смысл. Однажды у меня возникло желание получать уведомления об использовании AWS API в Slack, т.к. это позволяет быть в курсе изменений в инфраструктуре, пока она вся не представлена в виде кода (infrastructure as as code). Со своей развесистой платформой интеграций Slack прекрасен для ChatOps и мониторинга как никто другой, чего уж там скромничать.
-
Docker Data Management
Docker позволяет иметь персистентное хранилище в виде томов (volume) в противовес эфемерному слою контейнера в рамках слоевой файловой системы. Строго говоря есть еще bind mounts и tmpfs, но они встречаются достаточно редко в повседневной практике. Я лишь отмечу только, что данные volume хранятся в строго определенном месте (
/var/lib/docker/volumes/), данные bind mounts хранятся где угодно на файловой системе, а данные tmpfs располагаются исключительно в памяти. Я буду использовать термины “том” или “volume” здесь как взаимозаменяемые. -
AWS Fargate
В прошлом году я начал использовать AWS ECS как основное средство развертывания Docker контейнеров в облаке. Основной площадкой для запуска Docker хостов как можно догадаться является EC2. ECS представляет собой распределенное key/value хранилище (транзакционное журналируемое распределенное основанное на PAXOS) хранящее информацию о всех кластерах и являющееся единственным достоверным источником правды о текущем состоянии ваших кластеров. На каждом ECS инстансе запущен ECS агент (написанный на Go), который регулярно синхронизирует информацию о текущей машине с менеджером кластера. По умолчанию все машины находятся в AutoScaling Group (вероятно в разных AZ) для обеспечения эластичности кластера. После настройки кластера пользователю выдаются абстракции сервиса (Service) и задачи (Task). Фактически задачи – это и есть контейнеры, параметры и связи между которыми описываются в специальных определениях (Task Definition). Сервисы же представляют входную точку в контейнейры посредством балансировщика (Application Load Balancer) и следят за их жизненным циклом. Т.е. если один из контейнеров сдох, то сервис может его переподнять и такми образом поддерживать желаемое кол-во вычислительных мощностей. В ECS я плачу за время использования инстансов, пока запускаю на них контейнеры, а также за входящий/исходящий трафик. Так вот ребята из AWS запустили новый вид абстракции над вычислительными мощностями по имени Fargate. По сути это переход от управления виртуальными машинами к управлению контейнерами (задачами).
-
Правильный вопрос
С детства мама говорила мне, чтобы я не стеснялся задавать вопросы на уроках. “Не так страшно показаться глупым, как оставаться глупым и далее”, – говорила она. С тех пор я всегда чувствовал себя правым задавать вопросы до тех пор, пока на них кто-то может ответить. Более того, я сам часто люблю отвечать на вопросы, т.к. именно в этот момент я убеждаюсь, что таки обладаю знаниями и способен их продемонстрировать.