суббота, 9 февраля 2019 г.

Миграция сообщений в очередях RabbitMQ с помощью Shovel

У RabbitMQ существует возможность миграции сообщений между очередями, как в пределах одной ноды, так и между различными нодами.
Для этого можно использовать плагин Shovel (вообще кроме Shovel полезно будет знать про федерацию и кластеризацию в RabbitMQ, в некоторых кейсах можно использовать и их).

Установка плагина Shovel:
rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management

Пример использования Shovel для миграции очереди celery с ноды node1 на node2:
rabbitmqctl set_parameter shovel celery-migration \
'{"src-uri": "amqp://node1user:[email protected]/node1vhost", "src-queue": "celery", "dest-uri": "amqp://node2user:[email protected]/node2vhost", "dest-queue": "celery"}'

Для того чтобы node1 могла подключиться к node2, на второй должен быть открыть порт 5672.
Помимо использования CLI можно и использовать веб-интерфейс, пример можно посмотреть тут.

среда, 23 января 2019 г.

Пробрасываем реальный IP-адрес в Nginx Ingress

По умолчанию установленный Nginx Ingress с помощью HELM в AWS не пробрасывает реальный IP-адрес внутрь балансера, поэтому в логах ингресс-контроллера будут присутствовать логи с внутренних адресов сети.

В каком случае нам нужно иметь реальный адрес? Например если мы хотим на уровне ингресса или приложения анализировать адреса или для их блокировки.
Делается это несложно.

Включаем аннотацию для прокси в сервисе контроллера:
kubectl edit svc nginx-ingress-controller -n kube-system
metadata:
...
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'

Разрешаем в конфигмапе использование прокси:
kubectl edit configmap nginx-ingress-controller -n kube-system
data:
...
  use-proxy-protocol: "true"

Собственно говоря после этого все.
Идем в логи контроллера и смотрим адреса с которого приходят запросы:
kubectl logs -f nginx-ingress-controller-56f4bf4dc9-5pqjn
1.1.1.1 - [1.1.1.1] - - [22/Jan/2019:18:58:23 +0000] "GET /ping HTTP/1.1" 503 197 "-" "Wget" 85 0.000 [-]

вторник, 15 января 2019 г.

Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

Описал в статье как мы настраивали аутентификацию для кубера.
На хабре: https://habr.com/ru/post/436238/
На медиуме (англ): https://medium.com/preply-engineering/k8s-auth-a81f59d4dff6

Пока мы все это настраивали, много раз выстрелили себе в ноги. Однако таки удалось добить ее, сейчас успешно используем это на паре-тройке куберовских кластеров.
И да, подписывайтесь на телеграм-канал моего коллеги Юры: https://t.me/catops именно он добил эту аутентификацию, пока я мучался с ней тонну времени.
Он вместе с Максимом практически ежедневно выкладывает ссылки на годное чтиво, о том что связано с DevOps и смежными IT-темами.