Wireguard-wall

Wireguard - Настройка vpn-сервера

Wireguard - отличное решение, если нужно быстро организовать доступ к закрытому скоупу. Вот и ко мне прилетела задача, организовать доступ к exsi через vpn. Сам хост стоит в дата центре и имеет прямой доступ. После реализации vpn-сети, вырубим доступ. (Схема vpn-сети) Я поднял небольшую виртуалку, на которой поднимем wireguard-сервер, далее на микроте (который используется как фаервол/роутер) прокинем порт к vpn серверу. Установка WireGuard Подключаемся к серверу и ставим репозитории epel и eprepo: ...

February 16, 2023 · 6 min · 1123 words · Tony

Zabbix - мониторинг памяти на AIX

В процессе добавления на мониторинг aix серверов в zabbix, заметил что в стандартном шаблоне нету метрик собирающих данные по памяти. Сервера мониторятся через агентов, поправить это будет не сложно. Для начала напишем скриптец, который дергает нужные данные, и добавим скрипт на выполнение заббикс-агенту. Сам сниппет: #!/bin/bash totalmem=`lsattr -El sys0 -a realmem | awk {'print $2'}` usedmem=`svmon -G -O unit=KB | head -4 | tail -1 | awk {'print $3'}` freemem=`expr $totalmem - $usedmem` case $1 in "--free") echo "$freemem" ;; "--used") echo "$usedmem" ;; "--total") echo "$totalmem" ;; *) echo "Flags:" echo " --free - Free mem" echo " --used - Used mem" echo " --total - Total mem" esac В переменную totalmem, записывается результат выполнения команды (lsattr). Команда lsattr отобразит все атрибуты определенного объекта или устройства системы, в нашем случаи мы дергаем все аттрибуты устройства sys0, ключ -a отобразит определенный аттрибут, мы берем значение аттрибута - realmem. В переменную usedmem, также указывается результат выполнение команды svmon. Команда svmon, отобразит информацию о текущем состоянии памяти. В значение переменной freemem, вычесляется из переменных $totalmem и $usedmem. (Кстати говоря, эту метрику можно сделать средствами заббикса) Далее идет условный оператор case, в котором перечисляются ключи. В зависимости от ключа, будет пролистено значение одной из трех переменных. Сам скрипт можно разместить в домашнем каталоге пользователя - zabbix, обычно это - /var/lib/zabbix или /home/zabbix: ...

December 19, 2022 · 3 min · 591 words · Tony
k8s-svc-endpoint-pic

K8s - Service, Endpoints

Ранее для доступа к нашему поду, мы через утилиту kubectl реализовывали проброс портов во внутрь пода. Эта история хоть и работает, но вообще не годиться для ежедневной эксплуатации. Так как состояние пода эфемерно, то есть под может сломаться или перезапуститься, изчезнуть или появиться на другой ноде. Соответствено, kubernetes назначает поду новый ip, и клиенты нашего приложения даже не догадываются об изменениях. В дополнение у нашего приложения может быть несколько его реплик. ...

December 15, 2022 · 5 min · 892 words · Tony
k8s-configmaps-schemes

K8s - ConfigMap, Secrets

ConfigMap В kubernetes есть объект ConfigMap, который хранит конфигурации для других объектов куба. ConfigMap может быть использован в случаях, когда мы хотим: Во внутрь контейнера прокинуть файл с конфигурацией для нашего приложения, через read-only volume; Добавить переменные окружения во внутрь контейнера; Передать в контейнер агрументы командной строки. Мы можем хранить любую информацию в манифесте конфигмапы (кроме паролей и etc..), в кластере создаем новый configmap-объект и описываем его конфигурацию, в поле data. Далее включаем объект в деплоймент, поле template: -> containers:. При запуске пода, кубернетес примонтирует конфигмап как volume. ...

December 8, 2022 · 9 min · 1794 words · Tony
k8s-probes-resources

K8s - Probes, Resources

В этом посте хотелось бы поделиться заметками относительно использования Probe в кубернетес. И предоставить понимание того, на чем строиться ресурс менеджмент - реквесты и лимиты, QoS-классы. Probes В kubernetes реализован механизм проверки доступности нашего приложения. Существую 3 типа проверок: Liveness Probe - выполняет контроль за состоянием приложения в процессе его жизни. Liveness проверки выполняются постоянно. В случаи, если выполнение liveness пробы завершилось с результатом - failed, то kubernetes перезапустил приложение (под). Readiness Probe - выполняют проверки за состоянием контейнеров, для того что бы понять готов ли под принимать клиентский трафик. В случаи неудачного выполнения readiness проды, приложение убирается из балансировки. Так же как и с liveness, readiness пробы выполняются постоянно, с некой переодичностью. Startup Probe - с помошью startup пробы мы можем проверить, что наше приложение действительно проинициализировалось и готово принимать принимать запросы. Startup проба выполняется только до последнего успешного выполнения, после чего разблокирует выполнение других проб (liveness и readiness). Такой механизм может быть полезен, когда наш контейнер долго запускается, и чтобы избежать преждевременного убийства контейнера другими пробами они блокируются. Теперь напишем деплоймент, и будем разбираться с настройками проб. apiVersion: apps/v1 kind: Deployment metadata: name: deployment-with-probes spec: replicas: 2 selector: matchLabels: app: my-app strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template: metadata: labels: app: my-app spec: containers: - image: nginx:1.12 name: nginx-web ports: - containerPort: 80 readinessProbe: failureThreshold: 3 httpGet: path: / port: 80 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 livenessProbe: failureThreshold: 3 httpGet: path: / port: 80 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 initialDelaySeconds: 10 startupProbe: httpGet: path: / port: 80 failureThreshold: 30 periodSeconds: 10 Пробы указываются в контексте - containers. И могу быть сконфигурированы полями: ...

December 3, 2022 · 5 min · 981 words · Tony