Раннее мне не доводилось сталкиваться с k3s, в частности с traefik, но обстоятельства вынуждают к ресурсам относиться бережно.
Ситуация заключается в том, что кластер у меня находится за nginx, и тут началось разное-прекрасное, в частности не долетают хэдеры… Пришлось потратить достаточно времени что бы разобраться, как итог - создаем манифест в каталоге /var/lib/rancher/k3s/server/manifests и примерно таких содержимым:
Для надежности, можно сделать ему apply, и будет счастье…
А для проверки, на просторах интернета, рандомно нашел следующий docker-image -(latest не завелся) при обращении к нему, он возвращает все полученные хэдеры, очень удобно для проверки.
Обычно, я не использую какие-то подобные непонятные images, стараюсь все собирать сам используя за основу OSS или Verify-Projects, однако тут вроде и репо в гите у них есть, да и сил уже изобретать особо не было, а продебажится наверняка надо было…
Ситуация заключается в том, что кластер у меня находится за nginx, и тут началось разное-прекрасное, в частности не долетают хэдеры… Пришлось потратить достаточно времени что бы разобраться, как итог - создаем манифест в каталоге /var/lib/rancher/k3s/server/manifests и примерно таких содержимым:
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
externalTrafficPolicy: Local
additionalArguments:
- "--entryPoints.web.proxyProtocol.insecure"
- "--entryPoints.web.forwardedHeaders.insecure"
Для надежности, можно сделать ему apply, и будет счастье…
А для проверки, на просторах интернета, рандомно нашел следующий docker-image -
brndnmtthws/nginx-echo-headers:patch-1 Обычно, я не использую какие-то подобные непонятные images, стараюсь все собирать сам используя за основу OSS или Verify-Projects, однако тут вроде и репо в гите у них есть, да и сил уже изобретать особо не было, а продебажится наверняка надо было…
К Новости о том, что Docker заблокировал своей Registry в РФ и не только..
Вариантов несколько:
- Использовать зеркала, например
- Ставить прокси, на машинах с VPN, используя например этот образ:
- Загружать образы на свой Docker Registry. Так же есть и Российские Docker-Registry, например redos
~# docker pull alpine
Using default tag: latest
Error response from daemon: pull access denied for alpine, repository does not exist or may require 'docker login': denied: <html><body><h1>403 Forbidden</h1>
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/
</body></html>Вариантов несколько:
- Использовать зеркала, например
"registry-mirrors": ["https://daocloud.io", "https://c.163.com/", "https://registry.docker-cn.com"]
- Ставить прокси, на машинах с VPN, используя например этот образ:
rpardini/docker-registry-proxy:0.6.4
- Загружать образы на свой Docker Registry. Так же есть и Российские Docker-Registry, например redos
👍1
Для подключения зеркал к containerd используем следующий блок:
/etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io", "https://mirror.gcr.io"]Я впервые принял участие в видеоподкасте, и мне понравилось!
Это был познавательный опыт в команде слерм.
Ссылка на эфир - https://www.youtube.com/live/y5x3LH0aUso?si=tCqaDIYKlfl4o1be
Это был познавательный опыт в команде слерм.
Ссылка на эфир - https://www.youtube.com/live/y5x3LH0aUso?si=tCqaDIYKlfl4o1be
Статус всех публичных репозиториев GPDB (международный проект с открытым исходным кодом Greenplum) на GitHub изменен на архивный.
Как сообщают издание у Greenplum появился новый правообладатель - компании Broadcom который и будет заниматься дальнейшим развитием этого проекта, однако происходить это будет рамках коммерческой версии VMware Tanzu Greenplum.
Есть ребята из Arenadata, которые предлагают продукт ADB - по сути это форк того-же Greenplum, который поддерживает все плюшки что и Greenplum (особенно нравится pxf)
В ближайшее время, буду поднимать на своем проекте, в проде как раз ADB (на тесте у нас Greenplum 6), так что в скором времени дам фидбэк, и какие-то инструкции.
Ранее я не однократно сталкивался с ним, результаты на 1ТБ+ базе были довольно внушительные, в среднем на 30% быстрее MSSQL’я получилось, причем из коробки без какого-либо тюнинга🤯
👍1
В последние недели большую часть времени мне приходится заниматься мониторингом PostgreSQL.
Типичные болевые точки:
- Запросы выполняются долго
- Код написан не нами, и переписывем "по возможности"
Куда смотреть понимания нет, поэтому хотел бы рассказать о своем опыте, и том минимуме который стоит замониторить.
В первую очередь необходимо мониторить кол-во соединений к БД, как активных, так и idle.
Общее кол-во соединений в целом можно и через кол-во процессов мониторить, а активные через представление
Через это же представление мониторим кол-во записей по типам(тут могу немного ошибаться в терминологии, или не правильно выразиться, но речь идет о tuples), кол-во commit rollback операций.
Эти метрики позволят нам оценить как минимум нагрузку и кол-во операций в БД, так же понадобятся в сравнительном анализе(при выполнении определенных изменений в конфигурации, в рамках нескольких итераций отследить например кол-во операций и сопоставить с остальными матриками)
Следующим показателем у нас будут блокировки по типам, эти данные берем из
И последним будет представление pg_stat_statements, из которого мы берем информацию о кол-ве промахов мимо кэша или work_mem например - это прям явные сигналы к тому что необходимо оптимизировать те или иные параметры в
И чуть не забыл - это представление
Типичные болевые точки:
- Запросы выполняются долго
- Код написан не нами, и переписывем "по возможности"
Куда смотреть понимания нет, поэтому хотел бы рассказать о своем опыте, и том минимуме который стоит замониторить.
В первую очередь необходимо мониторить кол-во соединений к БД, как активных, так и idle.
Общее кол-во соединений в целом можно и через кол-во процессов мониторить, а активные через представление
pg_stat_database.Через это же представление мониторим кол-во записей по типам(тут могу немного ошибаться в терминологии, или не правильно выразиться, но речь идет о tuples), кол-во commit rollback операций.
Эти метрики позволят нам оценить как минимум нагрузку и кол-во операций в БД, так же понадобятся в сравнительном анализе(при выполнении определенных изменений в конфигурации, в рамках нескольких итераций отследить например кол-во операций и сопоставить с остальными матриками)
Следующим показателем у нас будут блокировки по типам, эти данные берем из
pg_locks, по этим метрикам больше вопросов будет к разработчикам, в плане оптимизации запросов с целью избегания блокировок.И последним будет представление pg_stat_statements, из которого мы берем информацию о кол-ве промахов мимо кэша или work_mem например - это прям явные сигналы к тому что необходимо оптимизировать те или иные параметры в
postgresql.confИ чуть не забыл - это представление
pg_stat_all_tables из которого можно получить информацию о кол-ве последовательных сканирований и сканирований таблице по индексу, тоже очень важный параметр на который стоит заострять внимание разработчиков(или DBA если они у Вас есть. Хотя если они у Вас есть - представленная мною информация не очень пригодится, т.к. они и так лучше меня знают что надо делать и куда смотреть)🔥1
Так же прикладываю скриншоты как это выглядит у меня в конечном итоге, в графане базовые показатели по БД, а в заббиксе про'discovery'нные таблицы.
Тут сразу видна проблема с индексами,
Тут сразу видна проблема с индексами,
shared_buffer и work_mem🥰1
Привет, малость мое здоровье подкосилось и по правде говоря состояние желало оставлять лучшего, одалело ОРВИ по мнению врачей с противной температурой 37.4-37.8 которую и не собьешь, и состояние жуткое, в общем не в состоянии был пилить контент... Готовлю цикл статей на тему "Основы DevOps: что нужно знать новичку"
Но сегодня есть поговорим о наболевшем в последнюю неделю(или две).
Интересный баг обнаружил при настройки отправки логов на rsyslog сервер при помощи logstash.
Я указываю в настройках
Как оказалось есть баг на который даже issue в github имеется:
Решением оказалось добавить +2 к facility, и это решило проблему, сообщения начали доходить куда надо...
Используемая версия logstash 8.4.2 - как обстоят дела с другими не знаю...
Но сегодня есть поговорим о наболевшем в последнюю неделю(или две).
Интересный баг обнаружил при настройки отправки логов на rsyslog сервер при помощи logstash.
Я указываю в настройках
facility => "local3" однако сообщения приходят на сервер и попадают в /var/log/syslog, хотя у меня настроено что бы local3 попадал в другой каталог.Как оказалось есть баг на который даже issue в github имеется:
Then on the remote rsyslog server I've noticed that the logs are send with severity 3.
If I want them to be send to remote server as local5 then I need to configure logstash with facility == "local7". This is not scalable since if we want to send to the remote host as facility 'local7', then it's not clear which value to use in the config.
Решением оказалось добавить +2 к facility, и это решило проблему, сообщения начали доходить куда надо...
Используемая версия logstash 8.4.2 - как обстоят дела с другими не знаю...
❤1
Итак, как говорил в предыдущем посте - начинаю цикл статей.
Сегодня вводная часть, в которой мне хотелось бы устроить просто "полет фантазий", и озвучить свое мнение касаемо DevOps.
🚀DevOps — это не просто модное слово, а целая философия в разработке программного обеспечения.
Я вообще убежден, что в странах СНГ понятие DevOps как специалиста и его обязанностях очень сильно извращено - бизнес в большинстве своем считает что это "Админ на стероидах", или чувак который причесывает деплой.
Я всегда старался продвигать "культуру как культ", что бы заострить внимание на том, что DevOps не просто "мальчик который настроит CI". Это больше - это как архитектор, идеолог, он снимает множество болевых точек, делает удобно всем автоматизируя различные участки (например развертывание ВМ для нужд разработчиков что-то потестить, с различным сроком жизни и ресурсами по средствам телеграм бота). Однако часто приходится сталкиваться с сопротивлением со стороны бизнеса, и понятно почему - разные категории мышление..ведь это не приносит прибыли...
Но все-же, мне хотелось бы рассмотреть основные векторы в этой области, с которыми я встречаюсь и работаю повседневно и как-то их прокомментировать.
И так , спросим у интернета что такое DevOps?
В целом соглашусь с этим утверждением, однако в начале сообщения, я описал свою позицию.
В следующей статье верхнеуровнево расскажу про ключевые навыки которыми стоит обладать.
Сегодня вводная часть, в которой мне хотелось бы устроить просто "полет фантазий", и озвучить свое мнение касаемо DevOps.
🚀DevOps — это не просто модное слово, а целая философия в разработке программного обеспечения.
Я вообще убежден, что в странах СНГ понятие DevOps как специалиста и его обязанностях очень сильно извращено - бизнес в большинстве своем считает что это "Админ на стероидах", или чувак который причесывает деплой.
Я всегда старался продвигать "культуру как культ", что бы заострить внимание на том, что DevOps не просто "мальчик который настроит CI". Это больше - это как архитектор, идеолог, он снимает множество болевых точек, делает удобно всем автоматизируя различные участки (например развертывание ВМ для нужд разработчиков что-то потестить, с различным сроком жизни и ресурсами по средствам телеграм бота). Однако часто приходится сталкиваться с сопротивлением со стороны бизнеса, и понятно почему - разные категории мышление..
Но все-же, мне хотелось бы рассмотреть основные векторы в этой области, с которыми я встречаюсь и работаю повседневно и как-то их прокомментировать.
И так , спросим у интернета что такое DevOps?
DevOps — это подход, который соединяет разработку и операционные процессы. Основная идея: автоматизировать все, что можно, чтобы ускорить процесс разработки и выпуска программ. Это значит, что команды работают в едином пространстве, используют одни и те же инструменты и стремятся к быстрой доставке кода пользователю.
В целом соглашусь с этим утверждением, однако в начале сообщения, я описал свою позицию.
В следующей статье верхнеуровнево расскажу про ключевые навыки которыми стоит обладать.
❤1
А что нужно уметь?
Чтобы стать девопсом👨💻, тебе понадобятся следующие навыки🛠:
- Принципы разработки ПО: понимание основ и теории, нужно понимать что делают разрабы в своей IDE, Еще могу посоветовать изучить еще такие вещи как - Семантическое версионирование(release-it в CI использую), Соглашение о коммитах и методологию приложения двенадцати факторов.
- Инструменты автоматизации: как минимум тебе надо знать, что происходит под капотом у гита, изучи GitlabCI - я считаю что это самое лучше. Но можно и TeamCity(Начинал с него) или Jenkins(он был у меня перед GitlabCI)
- Системное администрирование: нужно знать, как работают серверы и как их настраивать, а самое важное это понимать что происходит под капотом у ОС, уметь находить проблему и знать где(и как) ее искать. Тут не обойтись "продвинутый пользователь ПК"
- Контейнеризация: работа с Docker и Kubernetes, тут ничего не скажешь.. Моветон не знать эти продукты сегодня. Не хочу сказать что я как Сергей Бондарев например(недавно попадалась новость с его вебинаром у слерма) который прям под капотом тюнит этот k8s и что-то для него разрабатывает, но тем не менее - я знаю объекты, умею с ними работать, умею дебажить, понимаю принипы работы сети в кубах, Helm-Chart сюда же, как сделать процесс CD в различных реалиях, как юзать RBAC и прочее-прочее-прочее
- Базы данных: знание реляционных и нереляционных баз, так чисто - на минималках. Пойми зачем нужны индексы, что такое буфер и зачем он, индексы...
В следующей части рассмотрим еще несколько навыков.
Чтобы стать девопсом👨💻, тебе понадобятся следующие навыки🛠:
- Принципы разработки ПО: понимание основ и теории, нужно понимать что делают разрабы в своей IDE, Еще могу посоветовать изучить еще такие вещи как - Семантическое версионирование(release-it в CI использую), Соглашение о коммитах и методологию приложения двенадцати факторов.
- Инструменты автоматизации: как минимум тебе надо знать, что происходит под капотом у гита, изучи GitlabCI - я считаю что это самое лучше. Но можно и TeamCity(Начинал с него) или Jenkins(он был у меня перед GitlabCI)
- Системное администрирование: нужно знать, как работают серверы и как их настраивать, а самое важное это понимать что происходит под капотом у ОС, уметь находить проблему и знать где(и как) ее искать. Тут не обойтись "продвинутый пользователь ПК"
- Контейнеризация: работа с Docker и Kubernetes, тут ничего не скажешь.. Моветон не знать эти продукты сегодня. Не хочу сказать что я как Сергей Бондарев например(недавно попадалась новость с его вебинаром у слерма) который прям под капотом тюнит этот k8s и что-то для него разрабатывает, но тем не менее - я знаю объекты, умею с ними работать, умею дебажить, понимаю принипы работы сети в кубах, Helm-Chart сюда же, как сделать процесс CD в различных реалиях, как юзать RBAC и прочее-прочее-прочее
- Базы данных: знание реляционных и нереляционных баз, так чисто - на минималках. Пойми зачем нужны индексы, что такое буфер и зачем он, индексы...
В следующей части рассмотрим еще несколько навыков.
❤1
Сегодня завершающий пост цикла статьи о ключевых навыках DevOps🚀
Рассмотрим еще несколько ключевых навыков:
- Веб-серверы: понимание их работы и настройки. Может тебе и не придется возиться с NGINX с утра до ночи, но вот с ingress-controller попотеть придется точно(кстати, первая моя статья была именно об этом)
- Языки программирования: многие говорят - хорошо бы знать python, но я его не знаю, зато про меня есть байка: увидел bash -еб@шь(читай
- Управление конфигурацией: Знать - обязательно, так что изучаем Terraform(что бы оперативно по коммиту выкатывать инфраструктуру) и Ansible(куда без него) или Salt-Stack
- Мониторинг систем: сбор данных о нагрузке и ошибках. Тут у нас прям стек инструментов - Zabbix(незаменимый помощник для мониторинга почти всего, главное не переусердствовать), Prometheus(с его помощью собираем различные метрики из сервисов, но можно и что-то из вспомогательного ПО), Jaeger, ELK, Grafana
Если ты хочешь погрузиться в мир DevOps🚀, начинай с изучения этих основ.
Это не только откроет перед тобой новые возможности, но и сделает тебя ценным специалистом в команде👨💻
Рассмотрим еще несколько ключевых навыков:
- Веб-серверы: понимание их работы и настройки. Может тебе и не придется возиться с NGINX с утра до ночи, но вот с ingress-controller попотеть придется точно(кстати, первая моя статья была именно об этом)
- Языки программирования: многие говорят - хорошо бы знать python, но я его не знаю, зато про меня есть байка: увидел bash -
/bin/bash), ну вы поняли.. И я хочу сказать, что чувствую себя довольно не плохо и с этим(хотя отрицать не буду, несколько итераций к питону у меня были. Хотя кажется - парадокс, читать могу чуть ли не любой язык и понимать что там происходит. Я считаю что как минимум уметь "понимать" что там написано - необходимо(иногда надо помочь разрабу помочь найти проблему, или найти что-то спрятанное, например то что стоит вынести в переменные).- Управление конфигурацией: Знать - обязательно, так что изучаем Terraform(что бы оперативно по коммиту выкатывать инфраструктуру) и Ansible(куда без него) или Salt-Stack
- Мониторинг систем: сбор данных о нагрузке и ошибках. Тут у нас прям стек инструментов - Zabbix(незаменимый помощник для мониторинга почти всего, главное не переусердствовать), Prometheus(с его помощью собираем различные метрики из сервисов, но можно и что-то из вспомогательного ПО), Jaeger, ELK, Grafana
Если ты хочешь погрузиться в мир DevOps🚀, начинай с изучения этих основ.
Это не только откроет перед тобой новые возможности, но и сделает тебя ценным специалистом в команде👨💻
👍1