Postgres — Запрет записи в базу данных

Чтобы перевести базу данных в read-only, нужно задать флаг «default_transaction_read_only» в значение «true»

ALTER DATABASE dababase_name SET default_transaction_read_only = true;

 

Где «dababase_name» — имя необходимой базы данных

 

Возвращаем возможность записи в БД:

ALTER DATABASE dababase_name SET default_transaction_read_only = false;

 

Посмотреть текущее значение флага можно так:

SELECT name, setting FROM pg_settings WHERE name = 'default_transaction_read_only';

AWS AMI Linux 2 — Redis CLI

 

Для AMI Linux 2 нужно Redis-CLI собирать из исходников

Ссылка на скрипт, который был взят за основу.

 

redis-cli.sh:

#!/bin/bash

sudo yum install -y gcc wget
wget http://download.redis.io/redis-stable.tar.gz
tar -xf redis-stable.tar.gz
cd redis-stable
make
sudo cp -a src/redis-cli /usr/local/bin/
cd ..
rm -rf redis-stable.tar.gz
rm -rf redis-stable

 

Подключаемся к Redis‘у:

redis-cli -h redis.artem.services -p 6379

Kubernetes — Монтирование секрета как файл

Создадим Secret с содержимым существующего JSON файла «app-config.json» и примонтируем внутрь пода как JSON файл.

 

Создаем Secret:

kubectl create secret generic app-config --from-file=app-config.json

 

Монтируем Secret в Pod:

spec:
  template:
    spec:
      containers:
      - image: "my-image:latest"
        name: my-app
        ...
        volumeMounts:
          - mountPath: "/var/app"
            name: app-config
            readOnly: true
      volumes:
        - name: app-config
          secret:
            secretName: app-config

Kubernetes — Dashboard через service по HTTPS (AWS EKS)

Задача:

Получить доступ к Kubernetes Dashboard по доменному имени, а не используя «kubectl proxy«. Так же подключение должно осуществляться по HTTPS, но при этом вести на внутренний локальный адрес, доступный только через VPN, и не используя для этого никаких Ingress‘ов.

 

Редактируем деплоймент «kubernetes-dashboard«:

kubectl edit deployments.apps -n kubernetes-dashboard kubernetes-dashboard

 

Приводим аргументы к следующему виду:

    spec:
      containers:
      - args:
        - --namespace=kubernetes-dashboard
        - --enable-insecure-login
        - --insecure-port=8443

 

А так же для «livenessProbe» меняем «scheme: HTTPS» на «scheme: HTTP«:

        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 8443
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 10

 

Теперь дашборд будет доступен по HTTP.

В консоли AWS переходим в «Certificate Manager«, выбираем регион, в котором развернут EKS и делаем запрос на сертификат для нужного домена. После того, как сертификат валидирован, копируем его ARN.

 

Создаем манифест с Kubernetes сервисом.

kubernetes-dashboard-internal.yaml:

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: 'arn:aws:acm:<AWS_REGION>:<ACCOUNT_ID>:certificate/<CERTIFICATE_ID>'
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "*"
  name: kubernetes-dashboard-internal
  namespace: kubernetes-dashboard
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard
  sessionAffinity: None
  type: LoadBalancer

 

Применим его:

kubectl apply -f kubernetes-dashboard-internal.yaml

 

Теперь остается только создать ALIAS запись в Route53 на внутреннее имя созданного LoadBalancer‘а, посмотреть его имя можно так:

kubectl get svc -n kubernetes-dashboard kubernetes-dashboard-internal

 

Теперь из внутренних сетей AWS или используя VPN, по доменному имени будет доступен Kubernetes Dashboard.

Kubernetes — NFS provisioner

 

Установим NFS provisioner в Kubernetes кластер, для существующего NFS сервера

 

Дано:

  • 192.168.1.1 — IP адрес NFS сервера
  • /var/lib/nfs — путь NFS директории на сервере

 

Устанавливаем используя HELM:

helm install nfs-client-provisioner --set fullnameOverride=nfs-client-provisioner --set nfs.server=192.168.1.1 --set nfs.path=/var/lib/nfs stable/nfs-client-provisioner

 

Опцией «fullnameOverride» перезапишем полное имя чарта, так как он после имени все равно добавит «nfs-client-provisioner«

 

Делаем NFS типом хранилища по умолчанию:

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

 

Теперь можно создать PVC, NFS provisioner сам отследит запрос и создаст PV

 

test-pv-claim.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
  labels:
    app: test-app
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

 

Создаем PVC:

kubectl apply -f test-pv-claim.yaml

 

Проверяем созданный PVC и PV:

kubectl get pvc
kubectl get pv

Systemd — Монтирование NFS директории через OpenVPN

Так как все что перечислено в «fstab» монтируется при запуске системы, еще до запуска сети, то примонтировать директорию получится если добавить опцию «_netdev«. Но если NFS директория доступна только через VPN, который уже стартует после запуска сети то остается вариант «rc.local» или смонтировать диск используя Systemd.

В данном примере дано следующее:

  • [email protected] — имя OpenVPN сервиса
  • 192.168.1.1 — адрес удаленного NFS сервера
  • /var/www/html — путь на удаленном сервере
  • /home/artem/web — локальный путь для монтирования

 

Загружаем модуль NFS:

modprobe nfs

 

Создаем Systemd mount service с именем «home-artem-web.mount»

 

vim /usr/lib/systemd/system/home-artem-web.mount

 

Важно, чтобы имя было основано на пути, куда монтируется NFS директория, иначе сервис не запустится. Слеши заменяются тире.

 

Со следующим содержимым:

[Unit]
Description=Mount NFS Share
After=network.target [email protected]

[Mount]
What=192.168.1.1:/var/www/html
Where=/home/artem/web
Type=nfs
Options=_netdev,auto

[Install]
WantedBy=multi-user.target

 

Перечитываем список демонов:

systemctl daemon-reload

 

Запускаем и ставим в автозагрузку:

systemctl start home-artem-web.mount
systemctl enable home-artem-web.mount

 

Ansible — Копирование файла с одного хоста на другой

Пример Ansible Playbook‘а для копирования файла конфигурации с одного хоста на другой, в данном случае с «openvpn_server» на «openvpn_client»

- hosts: openvpn_client
  tasks:
    - name: Transfer client.conf from OpenVPN server
      synchronize:
        src: /etc/openvpn/client.conf
        dest: /etc/openvpn/client.conf
      delegate_to: openvpn_server

 

Для этого на всех хостах должен быть установлен пакет «rsync«

Ansible — Отключить Swap

Данный Playbook отключает Swap и удаляет его из файла «/etc/fstab»

 

swap_disable.yaml

---
- name: Disable Swap
  gather_facts: No
  hosts: localhost

  tasks:
    - name: Disable SWAP
      shell:
        cmd: |
          swapoff -a
      args:
        executable: /bin/bash

    - name: Remove Swap from fstab
      mount:
        name: swap
        fstype: swap
        state: absent

 

Применяем Playbook:

ansible-playbook docker.yaml

Kubernetes — Horizontal pod autoscaler на основе кастомных метрик

Спасибо Daniel Vaughan за данную статью.

Для горизонтального автоскалирования подов (HPA) на основе кастомных метрик, нам понадобятся:

Все это, мы будем устанавливать используя Helm. Установку Helm‘а можно посмотреть тут.

 

Создадим директорию для хранения Helm values:

mkdir helm-values

 

Создадим values файл для Prometheus Operator‘а:

cat <<EOF >helm-values/prometheus-operator-values.yaml
# This configuration means all ServiceMonitors in the namespace will be picked up
# Use with caution!
prometheus: 
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelector: {}
EOF

 

Устанавливаем Prometheus Operator:

helm install stable/prometheus-operator -n prom \
    -f helm-values/prometheus-operator-values.yaml

 

Читать далее «Kubernetes — Horizontal pod autoscaler на основе кастомных метрик»