Итак, дано:

Настройка сервисов:

user = rootgroup = root

group_authorization {    if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {            update reply {                &Fortinet-Group-Name = "vpn_admins" }            update control {                &Auth-Type := PAM                &Reply-Message := "Welcome Admin"                }        }    else {        update reply {        &Reply-Message := "Not authorized for vpn"            }        reject        }}

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

ldap {        server = 'domain.local'        identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'        password = "SupeSecretP@ssword"        base_dn = 'dc=domain,dc=local'        sasl {        }        user {                base_dn = "${..base_dn}"                filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"                sasl {                }                scope = 'sub'        }        group {                base_dn = "${..base_dn}"                filter = '(objectClass=Group)'                scope = 'sub'                name_attribute = cn                membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"                membership_attribute = 'memberOf'        }}

client fortigate {    ipaddr = 192.168.1.200    secret = testing123    require_message_authenticator = no    nas_type = other}

#%PAM-1.0auth       sufficient   pam_google_authenticator.soauth       include      password-authaccount    required     pam_nologin.soaccount    include      password-authpassword   include      password-authsession    include      password-auth

• Freeradius проверяет наличие пользователя в домене и в определенной группе и, в случае успеха, производится проверка OTP токена.

[root@freeradius ~]# yum install -y shellinabox

[root@freeradius ~]#systemctl enable --now shellinaboxd

• Пользователь логинится на машину через браузер.
• Проверяется доменный ли пользователь. Если нет, то никаких действий не предпринимается.
• Если пользователь доменный, проверяется принадлежность к группе администраторов.
• Если не админ, проверяется настроен ли Google Autheticator. Если нет, то генерируется QR-код и logout пользователя.
• Если не админ и Google Authenticator настроен, то просто logout.
• Если админ, то опять проверка Google Authenticator. Если не настроен, то генерируется QR-код.

# .bash_profile# Get the aliases and functionsif [ -f ~/.bashrc ]; then        . ~/.bashrcfi# User specific environment and startup programs# Make several commands available from user shellif [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]  then    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep  # Set PATH env to <home user directory>/bin    PATH=$HOME/bin    export PATH  else    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin    export PATHfiif [[ -n $(id $USER | grep "domain users") ]]  then    if [[ ! -e $HOME/.google_authenticator ]]      then        if [[ -n $(id $USER | grep "admins") ]]          then            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."          else            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password to VPN."            logout        fi      else        echo "You have already setup a Google Authenticator"        if [[ -z $(id $USER | grep "admins") ]]          then          logout        fi    fi  else    echo "You don't need to set up a Google Authenticator"fi

Настройка Fortigate:

• Создаем Radius-сервер
  
  
• Создаем необходимые группы, в случае необходимости разграничения доступа по группам. Имя группы на Fortigate должно соответствовать группе, которая передается в Vendor Specific Attribute Fortinet-Group-Name.
  
  
• Редактируем необходимые SSL-порталы.
  
  
• Добавляем группы в политики.
  
  

• Есть возможность аутентификации по OTP на Fortigate опенсорс решением.
• Исключается ввод доменного пароля пользователем при подключении по VPN, что несколько упрощает процесс подключения. 6-цифровой пароль ввести проще, чем тот, который предусмотрен политикой безопасности. Как следствие, уменьшается количество тикетов с темой: Не могу подключиться к VPN.

1. ADlogin, ADPasswordGoogleAuth (логин из AD, паролем выступает склееная фраза из пароля в AD и цифр от GoogleAuth )
2. ADlogin, ADPassword (стандартный вариант логина и пароля от AD, по сути чисто технический вариант, но нужен для Anyconnect)
3. ADLogin, GoogleAuth ( логин из AD, пароль цифры GoogleAuth. Так сказать GoogleAuthenticator в чистом виде)

#yum install ntp

#systemctl enable now ntpd

#ntpq p

#yum install y sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

#realm join pbu.icb --user=имя-пользователя-домена

#realm list

my.domen
type: kerberos
realm-name: MY.DOMEN
domain-name: my.domen
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U
login-policy: allow-permitted-logins
permitted-logins:

use_fully_qualified_names = False
simple_allow_groups = GroupLinuxAdmins@my.domen, GroupUseVPN@my.domen
ad_gpo_ignore_unreadable = True

#chown root.root /etc/sssd/sssd.conf&&chmod 600 /etc/sssd/sssd.conf#systemctl restart sssd

#id  имя-пользователя-домена

#echo "%GroupLinuxAdmins@my.domen ALL=(ALL) ALL" > /etc/sudoers.d/sudoadmin#chown root.root /etc/sudoers.d/sudoadmin&&chmod 600 /etc/sudoers.d/sudoadmin

PermitRootLogin no
AllowGroups grouplinuxadmins

#systemctl restart sshd

#yum -y install freeradius freeradius-utils#ln -s /etc/raddb/mods-available/pam /etc/raddb/mods-enabled/pam

# pam

# radtest userVPN password_for_userVPN localhost 0 testing123

Received Access-Accept

Received Access-Reject

(0) -: Expected Access-Accept got Access-Reject

client ftd {
ipaddr = 10.10.10.5
secret = secretFTD
}

#systemctl enable --now radiusd

user = radiusd
group = radiusd

user = root
group = root

#systemctl stop radius#radiusd -Xx

SELINUX=enforcing

SELINUX=permissive

#setenforce 0

#yum install y epel-release#yum install y google-authenticator

pam radius11812{
pam_auth = radiusd_ad
}

pam radius21812{
pam_auth = radiusd_ga
}

#ln s /etc/pam.d/password-auth-ac /etc/pam.d/radiusd_ad

#%PAM-1.0
#
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth

# cp /etc/raddb/sites-enabled/default /etc/raddb/sites-enabled/radius11812# cp /etc/raddb/sites-enabled/default /etc/raddb/sites-enabled/radius21812

pam

Auth-Type pam {
radius11812
}

pam

Auth-Type pam {
Radius21812
}

#yum install y shellinabox#yum enable now shellinabox

#echo . /usr/local/etc/radius_user_profiles.sh >> /etc/skel/.bash_profile

#!/bin/bash# Set groups for vpn, etc. ##   !!! Names of groups without caps letters !!!#VPNissuer="MyCompany"GROUP_VPN="groupusevpn"# Get the aliases and functionsif [ -f ~/.bashrc ]; then        . ~/.bashrcfi# User specific environment and startup programs# Make several commands available from user shell# for group VPN that use 2FA Google authenticatorif [[ -n $(id $USER | grep $GROUP_VPN) ]]  then     clear    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep  # Set PATH env to <home user directory>/bin    PATH=$HOME/bin    export PATH    if [[ ! -e $HOME/.google_authenticator ]]      then        figlet -t -c -f $HOME/bin/rebel.tlf "Welcome to $VPNissuer GAuth setup portal"        sleep 1.5        echo "Please, run Google Autheticator to setup OTP and prepare to scan QR code.If you don't have, please download that from market:AppStore    - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en"        sleep 1.5        google-auth -f -t -w 3 -r 3 -R 30 -d -e 1 -l "$VPNissuer" -i "$USER"        echo "Congratulations, now you can use an OTP token from application as a password to VPN."        logout    else        echo "You have already setup a Google Authenticator        "        logout    fifi

#chmod 755  /usr/local/etc/radius_user_profiles.sh

• в скрипте /usr/local/etc/radius_user_profiles.sh заменить строки
  

  if [[! -e $HOME/.google_authenticator ]]
  google-auth -f -t -w 3 -r 3 -R 30 -d -e 1 -l "$VPNissuer" -i "$USER"

  
  на
  

  if [[! -e /path_secrets/${USER} ]]
  google-auth -f -t -w 3 -r 3 -R 30 -d -e 1 -l "$VPNissuer" -i "$USER" --secret=/path_secrets/$USER

• и в модулях PAM /etc/pam.d/radiusd и /etc/pam.d/radiusd_ga
  везде после pam_google_authenticator.so добавить параметр secret=/path_secrets/${USER}
  

  auth required pam_google_authenticator.so secret=/path_secrets/${USER} nullok

• создать каталог
  

  #mkdir /path_secrets#chmod 777 /path_secrets
  

#cp /usr/lib/systemd/system/sshd.service /usr/lib/systemd/system/sshd_web.service#cp /etc/ssh/sshd/sshd_config /etc/ssh/sshd_web_config

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_web_config $OPTIONS

port 2022
MaxAuthTries 3
MaxSessions 1
AllowGroups groupusevpn

OPTS=" -s /:SSH:localhost:2022"

#yum install y nginx

PORT=8443

#systemctl daemon-reload#systemctl enable now sshd_web#systemctl enable now shellinabox

#systemctl enable now nginx

firewall-cmd --new-zone=radius permanentfirewall-cmd --zone=radius --add-source=10.10.10.5 --permanentfirewall-cmd --zone=radius --add-port=1812/udp --permanentfirewall-cmd --zone=radius --add-port=11812/udp --permanentfirewall-cmd --zone=radius --add-port=21812/udp --permanentfirewall-cmd --reload

#radtest userVPN password_for_userVPNXXXXXX localhost 0 testing123

#radtest userVPN password_for_userVPN localhost:11812 0 testing123

#radtest userVPN XXXXXX localhost:21812 0 testing123 

• Смена пароля при истечении времени жизни пароля через FreeRadius. Буду благодарен за советы.
• SELINUX и GoogleAuthenticator.
• Хотелось бы более красивого, аккуратного и, главное, более управляемого варианта генерации GoogleAuth токена, чем банальный шелл-скрипт.

1. Изменяем конфигурацию на существующих серверах в логическом сегменте/ЦОД. Иногда не за один день требования к доступности и закон больших чисел не позволяет применять все изменения разом. А некоторые изменения потенциально деструктивны и требуют перезапуск чего-либо от служб до самой ОС.
2. Исправляем в Ansible
3. Исправляем в Cobbler
4. Повторяем N раз для каждого логического сегмента/ЦОД

• Рефакторинг ansible кода, конфигурационных файлов
• Изменение внутренних best practice
• Изменения по итогам разбора инцидентов/аварий
• Изменение стандартов безопасности, как внутренних, так и внешних. Например, PCI DSS каждый год дополняется новыми требованиями

1. Автоматизация. Насколько возможно, нужно избегать человеческого фактора в повторяющихся операциях.
2. Повторяемость. Управлять инфраструктурой намного проще, когда она предсказуема. Конфигурация серверов и инструментов для их подготовки должна быть везде одинаковой. Это так же важно для продуктовых команд приложение должно гарантированно после тестирования попадать в продуктивную среду, настроенную аналогично тестовой.
3. Простота и прозрачность внесения изменений в configuration management.

• Копирование серверов из золотого образа зло!
  
  Из основных недостатков вы точно не знаете, в каком состоянии образы сейчас, и что все изменения придут во все образы во все фермы виртуализации.
• Используйте дефолтные файлы конфигурации по минимуму и договоритесь с другими подразделениями, что за основные системные файлы отвечаете вы, например:
  
  
  1. Оставьте /etc/sysctl.conf пустым, настройки должны лежать только в /etc/sysctl.d/. Ваш дефолт в один файл, кастом для приложения в другой.
  2. Используйте override файлы для редактирования systemd юнитов.
• Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
• Рефактория код системы управления конфигурациями:
  
  
  1. Разбейте задачи на логические сущности и перепишите монолит на роли
  2. Используйте линтеры! Ansible-lint, yaml-lint, etc
  3. Меняйте подход! Никакого bashsible. Нужно описывать состояние системы
• Под все Ansible роли нужно написать тесты в molecule и раз в день генерировать отчёты.
• В нашем случае, после подготовки тестов (которых больше 100) нашлось около 70000 ошибок. Исправляли несколько месяцев.
  
  

- name: create1.yml - Create a VM from a template  vmware_guest:    hostname: "{{datacenter}}".domain.ru    username: "{{ username_vc }}"    password: "{{ password_vc }}"    validate_certs: no    cluster: "{{cluster}}"    datacenter: "{{datacenter}}"    name: "{{ name }}"    state: poweredon    folder: "/{{folder}}"    template: "{{template}}"    customization:      hostname: "{{ name }}"      domain: domain.ru      dns_servers:        - "{{ ipa1_dns }}"        - "{{ ipa2_dns }}"    networks:      - name: "{{ network }}"        type: static        ip: "{{ip}}"        netmask: "{{netmask}}"        gateway: "{{gateway}}"        wake_on_lan: True        start_connected: True        allow_guest_control: True    wait_for_ip_address: yes    disk:      - size_gb: 1        type: thin        datastore: "{{datastore}}"      - size_gb: 20        type: thin        datastore: "{{datastore}}"

• 17 ansible-ролей для настройки сервера. Каждая из ролей предназначена для решения отдельной логической задачи (логирование, аудит, авторизация пользователей, мониторинг и т.д.).
• Тестирование ролей. Molecule + TestInfra.
• Собственная разработка: CMDB + Оркестратор.
• Время создания сервера ~30 минут, автоматизировано и практически не зависит от очереди задач.
• Одинаковое состояние/именование инфраструктуры во всех сегментах плейбуки, репозитории, элементы виртуализации.
• Ежедневная проверка состояния серверов с генерацией отчётов о расхождениях с эталоном.

Истоки OKD

Особенности релиза

В чем отличия OKD от OCP

Как приступить к работе с OKD4

Уже пользуетесь OKD?

Включайтесь в работу

Вступайте в наши ряды

• Страница регистрации в сообществе OpenShift Commons
• Прошедшие и предстоящие мероприятия сообщества
• Список участников сообщества OpenShift Commons

Почему Docker отсутствует в стандартной поставке CentOS 8

• Podman непосредственное взаимодействие с контейнерами и хранилищем образов через процесс runC;
• Buildah сборка и загрузка в реестр образов;
• CRI-O исполняемая среда для систем оркестрации контейнеров (например, Kubernetes).

Как развернуть Kubernetes на CentOS 8 с использованием среды CRI-O

1. На первом шаге настроим ОС, установим и настроим предварительные зависимости для CRI-O.
   
   • Обновим ОС:
     
     

     dnf -y update
     

   
   
   • Далее требуется настроить файрволл и SELinux. Здесь у нас всё зависит от окружения, в котором будут работать наш хост или хосты. Вы можете либо настроить файрволл по рекомендациям из документации, либо, если находитесь в доверенной сети или применяете сторонний файрволл, изменить зону по умолчанию на доверенную или выключить файрволл:
     
     

     firewall-cmd --set-default-zone trustedfirewall-cmd --reload
     

     
     Чтобы выключить файрволл можно использовать следующую команду:
     
     

     systemctl disable --now firewalld
     

     
     SELinux требуется выключить либо перевести в режим permissive:
     
     

     setenforce 0sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
     

   
   
   • загрузим необходимые модули ядра и пакеты, настроим автоматическую загрузку модуля br_netfilter при старте системы:
     
     

     modprobe overlaymodprobe br_netfilterecho "br_netfilter" >> /etc/modules-load.d/br_netfilter.confdnf -y install iproute-tc
     

   
   
   • для активации форвардинга пакетов и корректной обработки трафика сделаем соответствующие настройки:
     
     

     cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOFnet.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward = 1net.bridge.bridge-nf-call-ip6tables = 1EOF
     

     
     применим сделанные настройки:
     
     

     sysctl --system
     

   
   
   • зададим необходимую версию CRI-O (мажорная версия CRI-O, как уже упоминалось, совпадают с требуемой версией Kubernetes), так как последняя стабильная версия Kubernetes на данный момент 1.18:
     
     

     export REQUIRED_VERSION=1.18
     

     
     добавим необходимые репозитории:
     
     

     dnf -y install 'dnf-command(copr)'dnf -y copr enable rhcontainerbot/container-selinuxcurl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_8/devel:kubic:libcontainers:stable.repocurl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION/CentOS_8/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo
     

   
   
   • теперь мы можем установить CRI-O:
     
     

     dnf -y install cri-o
     

     
     Обратите внимание на первый нюанс, который мы встречаем в процессе инсталляции: необходимо отредактировать конфигурацию CRI-O перед запуском сервиса, так как требуемый компонент conmon имеет отличное от указанного место размещения:
     
     

     sed -i 's/\/usr\/libexec\/crio\/conmon/\/usr\/bin\/conmon/' /etc/crio/crio.conf
     

     
     
     Теперь можно активировать и запустить демон CRI-O:
     
     

     systemctl enable --now crio
     

     
     
     Можно проверить статус демона:
     
     

     systemctl status crio
     

   
   
2. Установка и активация Kubernetes.
   
   • Добавим требуемый репозиторий:
     
     

     cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearchenabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpgexclude=kubelet kubeadm kubectlEOF
     

     
     Теперь мы можем установить Kubernetes (версии 1.18, как уже указывалось выше):
     
     

     dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
     

   
   
   • Второй важный нюанс: так как мы не используем демон Docker, а используем демон CRI-O, до запуска и инициализации Kubernetes требуется внести соответствующие настройки в конфигурационный файл /var/lib/kubelet/config.yaml, предварительно создав нужный каталог:
     
     

     mkdir /var/lib/kubeletcat <<EOF > /var/lib/kubelet/config.yamlapiVersion: kubelet.config.k8s.io/v1beta1kind: KubeletConfigurationcgroupDriver: systemdEOF
     

   
   
   • Третий важный момент, с которым мы сталкиваемся при установке: несмотря на то, что мы указали используемый драйвер cgroup, и его настройка через аргументы передаваемые kubelet устарела (на что прямо указано в документации), нам необходимо добавить в файл аргументы, иначе наш кластер не инициализируется:
     
     

     cat /dev/null > /etc/sysconfig/kubeletcat <<EOF > /etc/sysconfig/kubeletKUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock'EOF
     

   
   
   • Теперь мы можем активировать демон kubelet:
     
     

     sudo systemctl enable --now kubelet
     

     
     Чтобы настроить control-plane или worker ноды за считанные минуты, вы можете воспользоваться этим скриптом.
     
   
   
3. Пора инициализировать наш кластер.
   
   • Для инициализации кластера выполните команду:
     
     

     kubeadm init --pod-network-cidr=10.244.0.0/16
     

     
     Обязательно запишите команду присоединения к кластеру kubeadm join ..., которой предлагается воспользоваться в конце вывода, либо, как минимум, указанные токены.
   
   
   • Установим плагин (CNI) для работы Pod network. Я рекомендую использовать Calico. Возможно, более популярный Flannel имеет проблемы с совместимостью с nftables, да и Calico единственная реализация CNI, рекомендуемая и полностью протестированная проектом Kubernetes:
     
     

     kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
     

   
   
   • Для подключения worker ноды к нашему кластеру её требуется настроить по пунктам инструкции 1 и 2, либо воспользоваться скриптом, затем выполнить команду из вывода kubeadm init ..., которую мы записали на предыдущем этапе:
     
     

     kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN \    --discovery-token-ca-cert-hash $TOKEN_HASH
     

   
   
   • Проверим, что наш кластер инициализирован и начал работу:
     
     

     kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
     

   
   Готово! Вы уже можете размещать на вашем K8s кластере полезную нагрузку.

Что нас ждёт впереди

• Раздел о Container runtimes в документации Kubernetes
• Странице проекта CRI-O в сети Internet
• Статьям в блогах Red Hat: вот этой, этой и многим другим

Перевод статьи подготовлен в преддверии старта курса Администратор Linux. Виртуализация и кластеризация

Балансировка нагрузки это распространенное решение для горизонтального масштабирования веб-приложений по нескольким хостам с предоставлением пользователям единой точки доступа к сервису. HAProxy является одной из самых популярных программ для балансировки нагрузки с открытым исходным кодом, которая также обеспечивает высокую доступность и функциональность проксирования.

HAProxy стремится оптимизировать использование ресурсов, максимизировать пропускную способность, минимизировать время отклика и избежать перегрузки каждого отдельно взятого ресурса. Она может быть установлена на множестве дистрибутивов Linux, таких как CentOS 8, на котором мы остановимся в этом руководстве, а также в системах Debian 8 и Ubuntu 16.

HAProxy особенно подходит для веб-сайтов с очень высоким трафиком и поэтому часто используется для повышения надежности и производительности конфигураций веб-служб с несколькими серверами. В этом руководстве изложены шаги по настройке HAProxy в качестве балансировщика нагрузки на облачном хосте CentOS 8, который затем направляет трафик на ваши веб-серверы.

В качестве необходимого условия для достижения наилучших результатов у вас должно быть как минимум два веб-сервера и сервер для балансировки нагрузки. На веб-серверах должна быть запущена хотя бы базовая веб-служба, такая как nginx или httpd, для того чтобы можно было проверить балансировку нагрузки между ними.

Установка HAProxy на CentOS 8

В силу того, что HAProxy быстро развивающееся приложение с открытым исходным кодом, дистрибутив, доступный вам в стандартных репозиториях CentOS, может оказаться не самой последней версией. Чтобы узнать актуальную версию, выполните следующую команду:

sudo yum info haproxy

HAProxy всегда предоставляет на выбор три стабильные версии: две самые последние поддерживаемые версии и третью, более старую, которая все еще получает критические обновления. Вы всегда можете проверить самую последнюю стабильную версию, указанную на сайте HAProxy, а затем решить, с какой версией вы хотите работать.

В этом руководстве мы будем устанавливать самую последнюю стабильную версию 2.0, которая еще не была доступна в стандартных репозиториях на момент написания руководства. Вам нужно будет установить ее из первоисточника. Но сначала проверьте, выполнены ли у вас необходимые условия для загрузки и компиляции программы.

sudo yum install gcc pcre-devel tar make -y

Загрузите исходный код с помощью команды ниже. Вы можете проверить, существует ли более новая версия, доступная на странице загрузки HAProxy.

wget http://www.haproxy.org/download/2.0/src/haproxy-2.0.7.tar.gz -O ~/haproxy.tar.gz

После завершения загрузки распакуйте файлы с помощью приведенной ниже команды:

tar xzvf ~/haproxy.tar.gz -C ~/

Перейдите в распакованный каталог с исходниками:

cd ~/haproxy-2.0.7

Затем скомпилируйте программу под вашу систему:

make TARGET=linux-glibc

И, наконец, установите саму HAProxy:

sudo make install

Теперь HAProxy установлена, но для ее работы требуются некоторые дополнительные манипуляции. Продолжим настройку программного обеспечения и сервисов ниже.

Настройка HAProxy под ваш сервер

Теперь добавьте следующие каталоги и файл статистики для записей HAProxy:

sudo mkdir -p /etc/haproxysudo mkdir -p /var/lib/haproxy sudo touch /var/lib/haproxy/stats

Создайте символьную ссылку для двоичных файлов, чтобы вы могли запускать команды HAProxy от имени обычного пользователя:

sudo ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy

Если вы хотите добавить прокси-сервер в систему в качестве службы, скопируйте файл haproxy.init из examples в свой каталог /etc/init.d. Отредактируйте права доступа к файлу, чтобы скрипт выполнялся, а затем перезагрузите демон systemd:

sudo cp ~/haproxy-2.0.7/examples/haproxy.init /etc/init.d/haproxysudo chmod 755 /etc/init.d/haproxysudo systemctl daemon-reload

Вам также необходимо разрешить службе автоматическую перезагрузку при запуске системы:

sudo chkconfig haproxy on

В целях удобства также рекомендуется добавить нового пользователя для запуска HAProxy:

sudo useradd -r haproxy

После этого вы можете еще раз проверить номер установленной версии с помощью следующей команды:

haproxy -vHA-Proxy version 2.0.7 2019/09/27 - https://haproxy.org/

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

Наконец, файрвол в CentOS 8 по умолчанию довольно рестриктивен для этого проекта. Используйте следующие команды, чтобы разрешить необходимые службы и перезагрузить файрвол:

sudo firewall-cmd --permanent --zone=public --add-service=httpsudo firewall-cmd --permanent --zone=public --add-port=8181/tcpsudo firewall-cmd --reload

Настройка балансировщика нагрузки

Настройка HAProxy довольно простой процесс. По сути, всё, что вам нужно сделать, это сообщить HAProxy, какие соединения он должен прослушивать и куда следует их ретранслировать.

Это делается путем создания файла конфигурации /etc/haproxy/haproxy.cfg с определяющими настройками. Вы можете почитать о параметрах конфигурации HAProxy на странице документации, если хотите узнать об этом больше.

Балансировка нагрузки на транспортном уровне (layer 4)

Начнем с базовой настройки. Создайте новый файл конфигурации, например, используя vi с командой ниже:

sudo vi /etc/haproxy/haproxy.cfg

Добавьте в файл следующие разделы. Замените server_name тем, что должно вызывать ваши сервера на странице статистики, а private_ip приватными IP-адресами серверов, на которые вы хотите направлять веб-трафик. Вы можете проверить приватные IP-адреса на панели управления UpCloud и на вкладке Private network в меню Network.

global   log /dev/log local0   log /dev/log local1 notice   chroot /var/lib/haproxy   stats timeout 30s   user haproxy   group haproxy   daemondefaults   log global   mode http   option httplog   option dontlognull   timeout connect 5000   timeout client 50000   timeout server 50000frontend http_front   bind *:80   stats uri /haproxy?stats   default_backend http_backbackend http_back   balance roundrobin   server server_name1 private_ip1:80 check   server server_name2 private_ip2:80 check

Это определяет балансировщик нагрузки транспортного уровня (layer 4) с внешним именем http_front, прослушивающий порт 80, который затем направляет трафик к бэкенду по умолчанию с именем http_back. Дополнительная статистика /haproxy?stats подключает страницу статистики по указанному адресу.

Различные алгоритмы балансировки нагрузки.

Указание серверов в разделе бэкенда позволяет HAProxy использовать эти серверы для балансировки нагрузки в соответствии с алгоритмом циклического перебора, когда это возможно.

Алгоритмы балансировки используются для определения того, на какой сервер в бэкенде передается каждое соединение. Вот некоторые из полезных опций:

• Roundrobin: каждый сервер используется по очереди в соответствии со своим весом. Это самый плавный и честный алгоритм, когда время обработки серверами остается равномерно распределенным. Этот алгоритм является динамическим, что позволяет регулировать вес сервера на лету.

  
  

• Leastconn: выбирается сервер с наименьшим количеством соединений. Циклический перебор выполняется между серверами с одинаковой нагрузкой. Использование этого алгоритма рекомендуется для длинных сеансов, таких как LDAP, SQL, TSE и т. д., но он не очень подходит для коротких сеансов, таких как HTTP.

  
  

• First: первый сервер с доступными слотами для подключения получает соединение. Серверы выбираются от самого низкого числового идентификатора до самого высокого, который по умолчанию соответствует положению сервера в ферме. Как только сервер достигает значения maxconn, используется следующий сервер.

  
  

• Source: IP-адрес источника хешируется и делится на общий вес запущенных серверов, чтобы определить, какой сервер будет получать запрос. Таким образом, один и тот же IP-адрес клиента будет всегда доставаться одному и тому же серверу, в то время как серверы остаются неизменными.

  
  

Настройка балансировки нагрузки на прикладном уровне (layer 7)

Еще одна доступная возможность настроить балансировщик нагрузки для работы на прикладном уровне (layer 7), что полезно, когда части вашего веб-приложения расположены на разных хостах. Это может быть достигнуто путем регулирования передачи соединения, например, по URL.

Откройте файл конфигурации HAProxy с помощью текстового редактора:

sudo vi /etc/haproxy/haproxy.cfg

Затем настройте сегменты фронтенд и бэкенд в соответствии с примером ниже:

frontend http_front   bind *:80   stats uri /haproxy?stats   acl url_blog path_beg /blog   use_backend blog_back if url_blog   default_backend http_backbackend http_back   balance roundrobin   server server_name1 private_ip1:80 check   server server_name2 private_ip2:80 checkbackend blog_back   server server_name3 private_ip3:80 check

Фронтенд объявляет правило ACL с именем url_blog, которое применяется ко всем соединениям с путями, начинающимися с /blog. Use_backend определяет, что соединения, соответствующие условию url_blog, должны обслуживаться бэкендом с именем blog_back, а все остальные запросы обрабатываются бэкендом по умолчанию.

Со стороны бэкенда конфигурация устанавливает две группы серверов: http_back, как и раньше, и новую, называемую blog_back, которая обслуживает соединения с example.com/blog.

После изменения настроек сохраните файл и перезапустите HAProxy с помощью следующей команды:

sudo systemctl restart haproxy

Если при запуске вы получили какие-либо предупреждения или сообщения об ошибках, проверьте конфигурацию на их наличие и убедитесь, что вы создали все необходимые файлы и папки, а затем снова попробуйте перезапустить.

Тестирование настройки

Когда HAProxy настроен и запущен, откройте публичный IP-адрес сервера балансировщика нагрузки в браузере и проверьте, правильно ли вы подключились к бэкенду. Параметр stats uri в конфигурации создает страницу статистики по указанному адресу.

http://load_balancer_public_ip/haproxy?stats

Когда вы загружаете страницу статистики, если все ваши серверы отображаются зеленым, то настройка прошла успешно!

Страница статистики содержит некоторую полезную информацию для отслеживания ваших веб-хостов, включая время работы/простоя и количество сеансов. Если сервер помечен красным, убедитесь, что сервер включен и что вы можете пропинговать его с машины балансировки нагрузки.

Если ваш балансировщик нагрузки не отвечает, убедитесь, что HTTP-соединения не блокируются файрволом. Также убедитесь, что HAProxy работает с помощью команды ниже:

sudo systemctl status haproxy

Защита страницы статистики с помощью пароля

Однако, если страница статистики просто указана во фронтенде, то она открыта для всеобщего обозрения, что может оказаться не очень хорошей идеей. Вместо этого вы можете назначить ей собственный номер порта, добавив приведенный ниже пример в конец вашего файла haproxy.cfg. Замените username и password на что-нибудь безопасное:

listen stats   bind *:8181   stats enable   stats uri /   stats realm Haproxy\ Statistics   stats auth username:password

После добавления новой группы слушателей удалите старую ссылку на stats uri из фронтенд группы. Когда закончите, сохраните файл и перезапустите HAProxy.

sudo systemctl restart haproxy

Затем снова откройте балансировщик нагрузки с новым номером порта и войдите в систему с именем пользователя и паролем, которые вы указали в файле конфигурации.

http://load_balancer_public_ip:8181

Убедитесь, что все ваши серверы по-прежнему отображаются зеленым, а затем откройте только IP балансировщика нагрузки без каких-либо номеров портов в вашем браузере.

http://load_balancer_public_ip/

Если на ваших внутренних серверах есть хотя бы какое-то разнообразие целевых страниц, вы заметите, что каждый раз, когда вы перезагружаете страницу, вы получаете ответ от другого хоста. Вы можете попробовать различные алгоритмы балансировки в разделе конфигурации или ознакомиться с полной документацией.

Заключение: балансировщик нагрузки HAProxy

Поздравляем с успешной настройкой балансировщика нагрузки HAProxy! Даже с базовой настройкой балансировки нагрузки вы можете значительно повысить производительность и доступность вашего веб-приложения. Это руководство является лишь введением в балансировку нагрузки с помощью HAProxy, которая способна на гораздо большее, чем то, что можно описать в краткой инструкции по настройке. Мы рекомендуем поэкспериментировать с различными конфигурациями с помощью обширной документации, доступной для HAProxy, а затем приступить к планированию балансировки нагрузки для вашей производственной среды.

Используя несколько хостов для защиты вашего веб-сервиса с помощью запаса мощности, сам балансировщик нагрузки все равно может представлять точку отказа. Вы можете еще больше повысить высокую доступность, установив плавающий IP между несколькими балансировщиками нагрузки. Вы можете узнать больше об этом в нашей статье о плавающих IP-адресах на UpCloud.

Подробнее о курсе Администратор Linux. Виртуализация и кластеризация***

Molecule призван помочь в разработке и тестировании ролей Ansible, и способствует внедрению подхода, результатом которого являются комплексно проработанные роли, которые хорошо написаны, просты в понимании и поддержке.

Что нам понадобится

Приступаем

$ mkdir molecule-blog$ cd molecule-blog$ python3 -m venv molecule-venv$ source molecule-venv/bin/activate(molecule-venv) $ pip install "molecule[lint]"

$ molecule --versionmolecule 3.0.4   ansible==2.9.10 python==3.6

Инициализируем новую роль Ansible

$ molecule init role mywebapp --driver-name=podman--> Initializing new role mywebapp...Initialized role in /home/ricardo/molecule-blog/mywebapp successfully.

$ cd mywebapp$ tree. defaults    main.yml files handlers    main.yml meta    main.yml molecule    default        converge.yml        INSTALL.rst        molecule.yml        verify.yml README.md tasks    main.yml templates tests    inventory    test.yml vars     main.yml 10 directories, 12 files

$ cat molecule/default/molecule.yml ---dependency:  name: galaxydriver:  name: podmanplatforms:  - name: instance    image: docker.io/pycontribs/centos:7    pre_build_image: trueprovisioner:  name: ansibleverifier:  name: ansible

$ vi molecule/default/molecule.yml...verifier:  name: ansiblelint: |  set -e  yamllint .  ansible-lint .

$ molecule lint

$ vi meta/main.ymlgalaxy_info:  author: Ricardo Gerardi  description: Mywebapp role deploys a sample web app   company: Red Hat    license: MIT    min_ansible_version: 2.9   platforms:  - name: rhel    versions:    - 8   - name: ubuntu    versions:    - 20.04   galaxy_tags: [] dependencies: []

$ molecule lint--> Test matrix     default     dependency     lint    --> Scenario: 'default'--> Action: 'dependency'Skipping, missing the requirements file.Skipping, missing the requirements file.--> Scenario: 'default'--> Action: 'lint'--> Executing: set -eyamllint .ansible-lint . 

Создаем тестовый инстанс

$ vi molecule/default/molecule.yml---dependency:  name: galaxydriver:  name: podmanplatforms:  - name: rhel8    image: registry.access.redhat.com/ubi8/ubi-init    tmpfs:      - /run      - /tmp    volumes:      - /sys/fs/cgroup:/sys/fs/cgroup:ro    capabilities:      - SYS_ADMIN    command: "/usr/sbin/init"    pre_build_image: true  - name: ubuntu    image: geerlingguy/docker-ubuntu2004-ansible    tmpfs:      - /run      - /tmp    volumes:      - /sys/fs/cgroup:/sys/fs/cgroup:ro    capabilities:      - SYS_ADMIN    command: "/lib/systemd/systemd"    pre_build_image: trueprovisioner:  name: ansibleverifier:  name: ansiblelint: |  set -e  yamllint .  ansible-lint .

sudo setsebool -P container_manage_cgroup 1

provisioner:  name: ansible  config_options:    defaults:      interpreter_python: auto_silent      callback_whitelist: profile_tasks, timer, yaml    ssh_connection:      pipelining: false

$ molecule create

$ molecule listInstance Name    Driver Name    Provisioner Name    Scenario Name    Created    Converged---------------  -------------  ------------------  ---------------  ---------  -----------rhel8            podman         ansible             default          true       falseubuntu           podman         ansible             default          true       false

$ podman psCONTAINER ID  IMAGE                                                   COMMAND               CREATED             STATUS                 PORTS  NAMES2e2f14eaa37b  docker.io/geerlingguy/docker-ubuntu2004-ansible:latest  /lib/systemd/syst...  About a minute ago  Up About a minute ago         ubuntu2ce0a0ea8692  registry.access.redhat.com/ubi8/ubi-init:latest         /usr/sbin/init        About a minute ago  Up About a minute ago         rhel8

Заключение

• Ansible Whitepaper Achieving Rolling Updates & Continuous Deployment
• Ansible Whitepaper Ansible in Depth
• Getting Started Guide Molecule documentation
• ansible-community/molecule: Molecule aids in the development and testing of Ansible roles
• Roles in the official Ansible documentation
• Galaxy Developer Guide

Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.

Итак, предположим, что у нас есть сервер, который должен работать без перебоев. Его нельзя просто так взять и выключить посреди рабочего дня клиенты или пользователи не поймут. Тем не менее любой сервер время от времени надо обслуживать, ставить обновления, менять аппаратную конфигурацию или сетевые настройки. Кроме того, нужно быть готовым к росту нагрузки, когда мощности сервера перестанет хватать. У сервера должна быть предусмотрена возможность быстрого масштабирования. Если вы озаботились этими проблемами, то вам нужно организовать отказоустойчивый кластер.

Чаще всего такие задачи приходится делать с HTTP-серверами. Я сегодня покажу сборку кластера на примере DNS, потому что опробовал технологию именно на нем, но с минимальными изменениями то же самое можно сделать и с серверами, работающими по TLS или HTTP.

Лирическое отступление о проблемах DNS

В принципе, DNS задуман так, чтобы необходимости городить огород с кластерами не возникало. В каждой зоне можно прописать множество NS-записей, в каждой сети можно раздать список DNS-серверов с помощью DHCP. DNS-сервера умеют реплицировать зоны, поэтому они хорошо масштабируются. Однако на практике это плохо работает. Когда я попробовал добавить 2-й DNS-сервер, то обнаружил, что

1. Половина пользователей сидят со статическими настроенными адресами DNS-серверов. Ставят себе 4 восьмерки в качестве primary и локальный DNS в качестве secondary.
2. Многие Linux-сервера не умеют из коробки корректно обновлять настройки DNS. Там такой зоопарк из glibc, nsswitch.conf, resolv.conf, NetworkManager, resolvconf, systemd-resolved, hosts, dhclient.conf и т. п., которые конфликтуют между собой, что рассчитывать на автоматическое обновление по DHCP просто не приходится.
3. Windows шлет запросы одновременно на все сервера, но обязательно дожидается ответа или таймаута от 1-го
4. Linux сначала обращается к 1-му DNS в списке и только в случае ошибки переходит к следующему.

Если долгое время в сети используется DNS-сервер с определенным IP, то он оказывается прописан в десятках разных мест. Например:

• Директива resolver в nginx.conf
• daemon.json в docker
• В настройках docker-контейнеров
• В конфигах модных нынче систем вроде kubernetes или openshift во внутренних файлах на каждой ноде и еще там же в конфигах dnsmasq.
• В конфигах почтовых серверов.
• В настройках VPN-серверов.

Никакими плейбуками и DHCP-декларациями это все обновить просто нереально. Поэтому было бы очень хорошо, если бы собираемый кластер можно было повесить на 1 уже существующий IP. Тогда для пользователей ничего не изменится, и софт перенастраивать не понадобится.

Поэтому я выбрал решение с keepalived и протоколом VRRP.

Подготовка

Собирая кластер из нескольких серверов, желательно уметь их различать на стороне клиента, чтобы не бегать искать по логам серверов, какой запрос, куда попал. Я для этого в bind9 завел вот такую зону.

$ORIGIN load.balance.$TTL 1hload.balance. 86400 IN SOA ns.mydomain.ru. dnsmaster.mydoamin.ru. (     1603065098 3600 1800 604800 30)load.balance. IN NS ns.mydomain.ru.health IN TXT =nameserver-1=

На 1-м сервере ресурсная запись TXT для health.load.balance содержит текст =nameserver-1=, на 2-м сервере =nameserver-2=, и т. д. Таким образом, отправляя запрос в кластер, я по ответу могу определить, какой сервер мне ответил, что очень удобно для отладки.

Если у вас HTTP-сервер, то поместите эту информацию в HTTP-заголовок. Например, для nginx я использую вот такую директиву

add_header serega-trace "$hostname" always;

Убедитесь, что ваши сетевые файерволлы не блокируют IP-трафик протокола 112 по адресу 224.0.0.18. Этот адрес будут использовать ваши сервера, чтобы договариваться между собой о том, кто из них MASTER, а кто BACKUP.

iptables -t filter -I INPUT -p vrrp -d 224.0.0.18 -j ACCEPTiptables -t filter -I OUTPUT -p vrrp -d 224.0.0.18 -j ACCEPT

При организации DNS нужно выделить мастер-сервер, на который не будут идти клиентские запросы. DNS-мастер используется только для управления. Он реплицирует свои зоны на slave-сервера, которые уже видны пользователям, и именно на них идет нагрузка. Далее речь будет идти о кластеризации именно DNS-slave.

Уровень 1 (Easy)

Если вам просто достаточно резервирования на случай аварии, то рекомендую рассмотреть самый быстрый и простой вариант. 2 одинаковых сервера разделяют между собой общий виртуальный IP (далее буду называть его VIP). У кого в данный момент в сетевом интерфейсе прописан VIP, тот сервер и работает. 2-й сервер следит за мастером (имеется в виду мастер VRRP, а не DNS), и как только обнаруживает, что он перестал вещать, сразу объявляет мастером себя и поднимает VIP на своем сетевом интерфейсе.

Меня приятно удивило то, как быстро удалось поднять кластер по такому варианту. Несмотря на то, что раньше я никогда не имел дело с keepalived, уже через час все работало. Так что если вам нужно решить задачу быстро, то уровень 1 вам подойдет в самый раз.

Сбор информации

Для успешного развертывания вам понадобится собрать следующую информацию. Здесь я привожу значения для примера. У вас эти значения должны быть свои.

Установите keepalived и snmpd. SNMP ставить необязательно, но мне кажется, что, если серверов с виртуальными IP будет много, он будет полезен.

setenforce 0 # если вдруг у вас selinuxdnf install -y keepalived nmap-ncat net-snmp net-snmp-utilssystemctl enable keepalivedsystemctl enable snmpd

Netcat нужен для диагностики и healthcheck-ов.

В файл /etc/sysconfig/keepavlied добавьте опцию -x. Она нужна для взаимодействия keepalived с snmpd. Если вы не собираетесь поднимать SNMP, то этот шаг можете пропустить.

Отредактируйте файл /etc/snmp/snmpd.conf следующим образом:

master agentxrocommunity public

В /etc/keepalived положите вот такой скрипт keepalived-notify.sh:

#!/bin/shumask -S u=rwx,g=rx,o=rxexec echo "[$(date -Iseconds)]" "$0" "$@" >>"/var/run/keepalived.$1.$2.state"

Этот скрипт будет вызываться демоном keepalived при изменении состояния кластера. Он запишет в каталог /var/run статусный файл, который удобно использовать для диагностики.

Отредактируйте основной конфигурационный файл keepalived.conf следующим образом:

global_defs {    enable_script_security}vrrp_script myhealth {    script "/bin/nc -z -w 2 127.0.0.1 53"    interval 10    user nobody}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }    track_script {        myhealth    }}

Блок global_defs содержит единственную необходимую настройку enable_script_security, которая по умолчанию отключена.

Блок vrrp_script описывает скрипт, который демон keepalived будет использовать для определения работоспособности своего сервера. Если этот скрипт вернет ошибку, то демон перейдет в состояние FAIL, и не будет претендовать на роль MASTER. В этом же блоке описывается периодичность выполнения healthchek-ов и указывается пользователь, от имени которого запускается скрипт. В нашем случае используется утилита netcat, которая устанавливает соединение c локальным DNS-сервером по TCP-порту 53. Можно использовать разные проверки, например, прозвонить UDP-порт 53 утилитой dig.

В блоке VRRP_INSTANCE задаются настройки 1 экземпляра сервера с виртуальным IP.

• state задает начальное состояние сервера BACKUP или MASTER. В режиме nopreempt единственное допустимое значение BACKUP.
• interface указывает, на каком сетевом интерфейсе будет поднят VIP
• virtual_router_id уникальный идентификатор роутера VRRP. Возможные значения от 1 до 255. У всех узлов кластера это значение должно быть одинаковым. Рекомендуется в качестве router_id использовать последний байт VIP, чтобы не запутаться, когда у вас таких виртуальных адресов будет много.
• priority задает приоритет данного экземпляра при выборе мастера. Мастером назначается сервер, у которого значение параметра priority выше. Если у нескольких серверов priority одинаковый, то мастер будет выбран случайным образом.
• advert_int определяет, с какой периодичностью мастер должен сообщать остальным о себе. Если по истечению данного периода сервера не получат от мастера широковещательное уведомление, то они инициируют выборы нового мастера.
• nopreempt означает, что если мастер пропал из сети, и был выбран новый мастер с меньшим приоритетом, то по возвращении старшего мастера, он останется в состоянии BACKUP. Т. е. если вы перезагрузили мастер, то он больше мастером не станет, пока новый мастер не отвалится. Если вы предпочитаете, чтобы мастером был какой-то конкретный сервер, то замените настройку nopreempt на preempt_delay.
• notify задает хук-скрипт, который будет вызываться при каждом изменении состояния сервера, и имя пользователя, от имени которого данный скрипт будет выполняться.
• authentication задает пароль, длиной до 8 символов, который будет защищать кластер от случайных коллизий с другими серверами в локальной сети.
• virtual_ipaddress задает VIP
• track_script указывает на описание скрипта, осуществляющего healthcheck.

Выполните указанные настройки на обоих серверах кластера и запустите сервисы:

systemctl start snmpdsystemctl start keepalived

Проверьте логи и статусные файлы на наличие ошибок.

journalctl -u snmpdjournalctl -u keepalivedtail /var/run/keepalived.INSTANCE.VI_1.state

Если у вас используется selinux, не забудьте по данным audit.log обновить политики и вернуть enforcing mode командой set enforce 1.

Проверка

Если в логах ошибок нет, можно проверять. Поскольку мы кластеризовали DNS, то будем использовать dig. Для проверки HTTP-сервера подойдет curl.

Запустите на клиенте такой скрипт

while true; do    dig -4 +short +notcp +norecurse +tries=1 +timeout=1 \        -q health.load.balance. -t txt @10.2.1.5;     sleep 1;done

Этот скрипт будет раз в секунду выдавать ресурсную запись health.load.balance/IN/TXT, которая содержит идентификатор сервера. В нашей конфигурации это будет тот сервер, который сейчас VRRP-мастер.

Зайдите на этот сервер и убедитесь, что в файле /var/run/keepalived.INSTANCE.VI_1.state в последней строке указано MASTER.

Перезапустите на мастере сервис keepalived. Если у вас все сделано правильно, то мастер поменяется. На 1-м сервере в файле keepalived.INSTANCE.VI_1.state появятся строки STOP и BACKUP, на втором сервере в этом же файле появится строка MASTER, а клиентский скрипт станет выдавать ресурсную запись с идентификатором нового мастера.

[2020-10-13T10:48:00+00:00] /etc/keepalived/keepalived-notify.sh INSTANCE VI_1 BACKUP 100[2020-10-13T11:26:29+00:00] /etc/keepalived/keepalived-notify.sh INSTANCE VI_1 MASTER 100

"=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-2=""=nameserver-2="

Все, кластер готов. Теперь можно перезагружать сервера по одному в любое время, не нужно откладывать обновления на выходные, не нужно работать по ночам, не нужно рассылать пользователям предупреждения о том, что возможны перебои в связи с регламентными работами.

Если у вас все получилось, значит вы успешно прошли 1-й уровень кластеризации. Он обладает следующими плюсами:

• очень легко и быстро настраивается,
• практически невозможно что-либо сломать,
• на всех узлах кластера одинаковая конфигурация, что сильно сокращает трудоемкость администрирования.

Однако есть у данного варианта развертывания и существенный минус. В один момент времени в кластере работает только один сервер, а остальные, что называется, курят бамбук. Во-первых, это неэффективно с точки зрения использования вычислительных ресурсов. Во-вторых, если ваш сервер перестанет справляться с нагрузкой, то такой простенький кластер вам не поможет.

Чтобы обеспечить не только отказоустойчивость, но и масштабирование, переходите на следующий уровень кластеризации, о котором я расскажу прямо сейчас.

Уровень 2 (c балансировкой нагрузки)

Чтобы задействовать все сервера кластера, нужно научить VRRP-мастер, на сетевом интерфейсе которого прописан VIP, не только принимать трафик для своих локальных сервисов, но и направлять часть трафика на остальные сервера. Демон keepalived как раз умеет это делать.

Отредактируйте конфиг keepalived.conf, приведя его к следующему виду:

global_defs {    enable_script_security}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }}virtual_server 10.2.1.5 53 {    protocol UDP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.2 53 {        DNS_CHECK {            type txt            name health.load.balance.        }    }    real_server 10.2.1.3 53 {        DNS_CHECK {            type txt            name health.load.balance.        }    }}virtual_server 10.2.1.5 53 {    protocol TCP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.2 53 {        TCP_CHECK {            connect_timeout 3        }    }    real_server 10.2.1.3 53 {        TCP_CHECK {            connect_timeout 3        }    }}

Начало конфигурации аналогично предыдущему варианту без балансировки, только из блока vrrp_instance исчез track_script, соответственно за ненадобностью был удален блок vrrp_script.

Главное отличие в новой конфигурации заключается в блоках virtual_server. Для DNS требуется 2 виртуальных сервера, для 53-го порта TCP и для 53-го порта UDP. В случае HTTP-сервера аналогично потребуются сервера для 80-го и 443-го портов TCP.

Каждый виртуальный сервер идентифицируется 3 значениями: IP, порт и протокол. IP и порт через пробел указываются в заголовке блока virtual_server, а протокол определяется параметром protocol внутри блока. Допустимые протоколы TCP и UDP. В случае DNS как раз нужны оба.

Параметр delay_loop задает периодичность, с которой балансировщик опрашивает бэкенды для определения их состояния.

Самые важные параметры в виртуальном сервере это lvs_sched и lvs_method. lvs_sched задает алгоритм, по которому балансировщик определяет, куда отправить очередной IP-пакет. lvs_method задает механизм, который использует балансировщик для направления пакетов в выбранный пункт назначения.

В приведенном примере lvs_sched равен rr, что означает round robin, т. е. балансировка равномерно по очереди. lvs_method используется NAT. Кроме NAT доступны также механизмы DR (direct routing) и TUN (tunneling). На мой взгляд, NAT единственный рабочий вариант. Остальные методы работают только в очень специфических условиях.

Каждый виртуальный сервер состоит из нескольких реальных серверов, что отражено в соответствующих вложенных блоках real_server. Внутри блока real_server надо описать способ опроса его состояния, т. е. healthcheck.

После такой настройки keepalived работает следующим образом:

1. Принимает IP-пакет с адресом получателя равным VIP.
2. Выбирает real_server, куда необходимо направить пакет, анализируя протокол, порт, lvs_sched и результаты healthcheck-ов.
3. Заменяет в IP-пакете адрес получателя на IP-адрес выбранного реального сервера и отправляет его дальше.

Только для работы этого недостаточно. Выбранный реальный сервер отправит ответный IP-пакет, в котором адрес отправителя будет равен его собственному IP-адресу. Клиент дропнет такой пакет, потому что он отправлял запрос на VIP и ожидает ответы от VIP, а не с IP-адреса реального сервера.

Чтобы решить эту проблему, нужно заставить реальный сервер отправить ответ не на IP клиента, а на IP мастера, чтобы тот выполнил обратную подстановку реального IP на виртуальный.

Для этого понадобится itpables и некоторые настройки ядра.

dnf -y install iptables iptables-servicessystemctl enable iptablessystemctl start iptables

echo "net.ipv4.ip_forward=1" >>/etc/sysctl.d/99-sysctl.confecho "net.ipv4.vs.conntrack=1" >>/etc/sysctl.d/99-sysctl.confsysctl -w net.ipv4.ip_forward=1sysctl -w net.ipv4.vs.conntrack=1

Добавьте в iptables следующее правило:

iptables -t nat -I POSTROUTING 1 -d 10.2.1.0/24 -j SNAT --to-source 10.2.1.5service iptables save

Действие SNAT означает, что после маршрутизации в IP-пакете IP-адрес источника будет заменен на IP-адрес to-source. Вместо SNAT можно также использовать действие MASQUERADE, которое делает то же самое, только определяет исходящий IP автоматически.

Поскольку были внесены изменения в такие вещи как iptables и параметры ядра, рекомендуется перезагрузить сервер и убедиться, что ничего из этого не потерялось.

Выполните описанные действия на обоих серверах кластера. Проверьте логи и статусные файлы. Если ошибок нет, то выполните проверку работы кластера способом, описанным выше. Теперь должен получиться вот такой вывод:

"=nameserver-1=""=nameserver-2=""=nameserver-1=""=nameserver-2=""=nameserver-1="

Поскольку в балансировщике задан алгоритм round robin, то сервера отвечают строго по очереди друг за другом.

Остановите named на 2-м сервере, и получите:

"=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-1="

Снова запустите на 2-м сервере named, и на клиенте снова начнется чередование ответов.

Не забудьте про корректировку политик selinux, о которой рассказано выше.

Поздравляю. Только что мы с вами прошли 2-й уровень кластеризации.

Теперь наш кластер не только отказоустойчивый, но и масштабируемый.

Тем не менее, данная конструкция имеет и большой минус. Из-за трансляции адресов на подчиненные сервера запросы приходят с VIP, и невозможно по логам определить, какой запрос от какого клиента пришел. Возможность вычислить клиента по IP очень полезна для решения различных проблем. Поэтому, мой совет не останавливаться на 2-м уровне и, по возможности, перейти на 3-й.

Уровень 3 (Expert)

3-й уровень кластеризации подразумевает, что вы уже находитесь на 2-м, и все у вас работает как надо. Необходимо только обеспечить проброс клиентского IP-адреса до реальных серверов.

Принцип проброса следующий: все пакеты, приходящие на сервер, содержат IP реального клиента, а ответы на них отправляются на VIP. Т. е. VIP для реального сервера является шлюзом по умолчанию. Причем на этот шлюз направляются даже те пакеты, получатель которых находится в локальной подсети.

Но у серверов уже есть шлюз по умолчанию, и заменить его нельзя. Если убрать стандартный шлюз по умолчанию, то балансировка может быть и будет работать, однако все остальное сетевое взаимодействие у сервера сломается, и на него нельзя будет даже зайти по SSH.

Решение заключается в создании на сервере 2-го сетевого интерфейса. На 1-м сетевом интерфейсе будет производиться стандартный сетевой обмен, а на 2-м как раз и будет настроен VIP в качестве шлюза по умолчанию. Соответственно, у серверов вместе с дополнительным сетевым интерфейсом должен будет появиться и дополнительный IP-адрес.

Итак, добавьте на сервера кластера дополнительные сетевые интерфейсы и назначьте им IP-адреса.

Соберите информацию, необходимую для дальнейшей настройки. В нашем примере будут использоваться следующие значения:

Скорректируйте конфигурацию keepalived по указанному образцу.

global_defs {    enable_script_security}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }}virtual_server 10.2.1.5 53 {    protocol UDP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.6 53 {        DNS_CHECK {            connect_ip 10.2.1.2            type txt            name health.load.balance.        }    }    real_server 10.2.1.7 53 {        DNS_CHECK {            connect_ip 10.2.1.3            type txt            name health.load.balance.        }    }}virtual_server 10.2.1.5 53 {    protocol TCP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.6 53 {        TCP_CHECK {            connect_ip 10.2.1.2            connect_timeout 3        }    }    real_server 10.2.1.7 53 {        TCP_CHECK {            connect_ip 10.2.1.3            connect_timeout 3        }    }}

От предыдущей конфигурации новая отличается тем, что для реальных серверов указаны IP с дополнительных сетевых интерфейсов, но healthcheck-и отправляются на IP основных сетевых интерфейсов. Обратите внимание на этот момент. Все сервера кластера опрашивают друг друга, но на дополнительных сетевых интерфейсах будут настроены маршруты на VIP, поэтому узлы, которые сейчас в состоянии BACKUP, не смогут получить ответ от новых IP-адресов.

Теперь необходимо прописать правильные маршруты для дополнительных сетевых интерфейсов.

Добавьте в файл /etc/iproute2/rt_tables 2 новых таблицы маршрутизации. В примере ниже добавлены таблицы table0 и table1.

## reserved values#255     local254     main253     default0       unspec## local##1      inr.ruhep20      table021      table1

По документации к NetworkManager и CentOS 8 статические маршруты и правила следует помещать в файлы /etc/syconfig/network-scripts/route-eth0 и rule-eth0. На многих моих серверах именно так и сделано. Только почему-то на серверах, поднятых из одного и того же образа, формат этих файлов оказался разным. На большинстве серверов route-eth0 выглядит так:

192.168.1.0/24 via 192.168.1.1172.10.1.0/24 via 172.10.1.1

но почему-то на моих серверах DNS эти же файлы содержат вот это:

ADDRESS0=192.168.1.0NETMASK0=255.255.255.0GATEWAY0=192.168.1.1ADDRESS1=172.10.1.0NETMASK1=255.255.255.0GATEWAY1=172.10.1.1

Формат понятен, только совершенно непонятно, как в него поместить имя таблицы маршрутизации. Я не смог разобраться в этом вопросе. Если кто-то знает, в чем дело, поделитесь, пожалуйста, информацией в комментариях.

Поскольку сохранить маршруты в специальных системных файлах не удалось, пришлось сделать костыль.

#!/bin/sh# https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.htmlvip="10.2.1.5"dev0="eth0"ip0="10.2.1.2" # "10.2.1.3"dev1="eth1"ip1="10.2.1.6" # "10.2.1.7"ip route add 10.2.1.0/24 dev "$dev0" src "$ip0" table table0ip route add default via 10.2.1.1 table table0ip rule add from "$ip0" table table0ip route add "$vip/32" dev "$dev1" src "$ip1"ip route add default via "$vip" table table1ip route add "$vip/32" dev "$dev1" src "$ip1" table table1ip rule add from "$ip1" table table1

В комментарии в скрипте указаны значения, которые надо скорректировать при переносе скрипта на другой сервер.

Данный скрипт я добавил в автозапуск вместе с сервисом keepalived.

systemctl edit keepalived

[Service]ExecStartPre=/etc/keepalived/routes.sh

Не самое элегантное решение, но работает нормально, поэтому можете спокойно использовать, если не знаете, как можно сделать лучше.

Принципы задания правил маршрутизации описаны в Linux Advanced Routing & Traffic Control HOWTO. Идея заключается в том, что создается 2 независимые таблицы маршрутизации, в каждой свой шлюз по умолчанию. В зависимости от того, с какого сетевого интерфейса отправляется пакет, с помощью правил ip rule выбирается либо одна таблица, либо другая.

Удалите из iptables правило SNAT в цепочке POSTROUTING, добавленное при прохождении 2-го уровня. Сохраните состояние iptables.

iptables -t nat -D POSTROUTING -d 10.2.1.0/24 -j SNAT --to-source 10.2.1.5service iptables save

Проверьте результат. Клиент должен получать ответы от каждого сервера поочередно, в логах на серверах должны писаться реальные IP клиентов.

Теперь имеется отказоустойчивый кластер, в котором все живые узлы принимают нагрузку и видят IP-адреса своих клиентов. Единственный небольшой минус у этой конфигурации заключается в том, что есть 1 скрипт, который на разных серверах должен иметь разные параметры. Небольшое усложнение администрирования, которое с лихвой окупается полученными преимуществами.

Содержание

1. Лучшие дистрибутивы для начинающих
   
2. Лучшие дистрибутивы для опытных специалистов
   
3. Самые легковесные варианты для старых машин x86
   
4. Опрос

Лучшие дистрибутивы для начинающих

• Ubuntu
  
• Linux Mint
  
• Elementary OS
  
• Manjaro
  
• Zorin OS

Ubuntu

Linux Mint

Elementary OS

Manjaro

Zorin OS

Лучшие дистрибутивы для опытных специалистов

• Gentoo Linux
  
• Arch Linux
  
• Debian
  
• Fedora
  
• Slackware

Самые легковесные варианты для старых машин x86

• Lubuntu
  
• Linux Lite
  
• Puppy Linux
  
• TinyCore
  
• Ubuntu MATE

Lubuntu

Linux Lite

Puppy Linux

TinyCore

Ubuntu MATE

На правах рекламы

Что известно о новом дистрибутиве AlmaLinux

• Основа пакетная база Red Hat Enterprise.
• Полная бинарная совместимость с RHEL.
• Простая и прозрачная миграция с CentOS 8.
• Поддерживаемые обновления до 2029 года.
• Free-модель для пользователей.
• Функции принятия решений делегируют сообществу по аналогии с платформой Fedora.

Какие еще есть альтернативы для CentOS?

• 100% совместим с RHEL на бинарном уровне;
• разработан для гибридного облака;
• автоматическое обновление Linux без перезагрузки;
• оптимизирован для работы программного обеспечения Oracle.

Хроника пикирующего дистрибутива: зачем убили CentOS?

1. Часть пользователей из числа представителей крупного бизнеса наверняка предпочтет перейти на RHEL, что обеспечит дополнительную прибыль;
2. Те, кто рискнет мигрировать на CentOS Stream, пополнят ряды бета-тестеров, а это поможет эффективнее обкатывать новые технологии и быстрее выявлять уязвимости в новых версиях пакетов;
3. Освободившиеся ресурсы можно использовать для дальнейшего развития Red Hat Enterprise Linux, оставаясь в рамках прежнего бюджета на разработку.

Куда пойти, куда податься?

1. CentOS Stream

1. Подключаем репозиторий CentOS Stream

1. Указываем новый репозиторий в качестве дефолтного

1. Синхронизируем установленные пакеты

2. Oracle Linux

1. Скрипт обрабатывает только основные репозитории операционной системы. Подключение внешних репозиториев вроде EPEL для получения обновлений ранее установленных пакетов придется производить вручную;
2. Совместимость с пакетами, полученными из сторонних репозиториев, не гарантируется. В частности, Oracle указывает на возможные конфликты, вызванные наличием файла /etc/oracle-release;
3. После миграции могут перестать работать пакеты, использующие сторонние модули ядра и/или модули ядра с закрытым исходным кодом (к таковым относятся, например, коммерческие антивирусные приложения);
4. Скрипт не поддерживает системы, в которых используются сторонние инструменты централизованного управления наподобие Foreman, Spacewalk или Uyni.

1. Дистрибутив полностью бесплатен и может использоваться в коммерческих проектах без каких-либо ограничений или дополнительного лицензирования;
2. Бесплатная и коммерческая версии Oracle Linux отличаются друг от друга только наличием технической поддержки от специалистов корпорации, сами же дистрибутивы полностью идентичны и используют единый репозиторий, одновременно получая все выходящие обновления;
3. Изменения в ядре Unbreakable Enterprise Kernel публикуются в Git-репозитории с разделением на отдельные патчи и детализацией внесенных изменений, что повышает прозрачность и предсказуемость поведения системы при ее обновлении;
4. Oracle Linux поддерживает высокопроизводительную сетевую файловую систему Oracle Cluster File System 2 (OCFS2), позволяющую создавать разделяемые хранилища, используемые одновременно несколькими Linux-системами, что делает Oracle Linux весьма удобной для построения масштабируемых веб-серверов, кластерных баз данных, виртуализации и других аналогичных сценариев.

3. AlmaLinux

4. Rocky Linux

• Разработку Rocky Linux возглавляет компания Ctrl IQ стартап основателя CentOS Грегори Курцера;
• Компания заручилась поддержкой инвесторов в лице венчурного фонда IAG Capital Partners и одного из крупнейших поставщиков гипермасштабируемых систем хранения данных OpenDrives, по итогам переговоров с которыми на разработку операционной системы удалось привлечь $4 млн;
• В число ключевых спонсоров проекта входят корпорация Amazon, предоставившая команде Ctrl IQ необходимые для разработки и сборки дистрибутива вычислительные мощности в облаке AWS, и MontaVista Software, имеющая более, чем 20-летний опыт разработки программного обеспечения с открытым исходным кодом, ориентированного на нужды корпоративных клиентов.