Kubernetes. Установка Minikube на MacOS

На MacOS, Minikube использует VirtualBox как гипервизор по-умолчанию, который мы будем использовать в данной статье. Однако, если вы желаете использовать xhyve гипервизор для запуска Minikube VM, тогда, при запуске, вам нужно будет добавить –vm-driver=xhyve

Далее, мы научимся как устанавливать Minikube на MacOS:

  • Установите VirtualBox на MacOS.
  • Установите Minikube
  • Мы можем скачать последнюю версию с официальной страницы minikube. Однажды скачав, нам нужно сделать ее исполняемой и скопировать в PATH.

    curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.24.1/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
    

    Установка и настройка сертификатов Let’s Encrypt

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

    До недавних пор большой популярностью пользовались сертификаты от SlartSSL и WoSign, однако, многие браузеры перестали им доверять и большинство сайтов оказалось с нерабочими, но валидными SSL-сертификатами. Толку от них нет, если пользователь видит ошибку при открытии сайта, если бы не решение от Let’s Encrypt, то в нашем арсенале остался бы только один вариант – покупать сертификат :)

    Итак, приступим к установке и настройке Let’s Encrypt:

    rpm -ihv http://rpms.southbridge.ru/southbridge-rhel6-stable.rpm
    yum clean all
    yum install letsencrypt -y
    

    CentOS: udev renamed network interface eth0 to em1

    Подобная проблема часто встречается при настройке брендовых серверов, таких как DELL. Если вас не устраивает вид сгенерированных интерфейсов, он бывает и более затейливым, например eth0 -> p3p1, вы можете все вернуть «как было», для этого потребуется выполнить несколько шагов.

    Проверено на системе CentOS release 6.9. Для начала, добавим в загрузчик (grub.conf) директивы net.ifnames=0 и biosdevname=0

    kernel /boot/vmlinuz-2.6.32-696.el6.x86_64 ro
    root=UUID=357f2c79-f7eb-4318-be69-da573fab5198
    rd_NO_LUKS ...
    net.ifnames=0 biosdevname=0 crashkernel=auto ...
    

    Далее переименуем конфиг и обновим имя интерфейса:

    mv /etc/sysconfig/network-scripts/ifcfg-em1 /etc/sysconfig/network-scripts/ifcfg-eth0
    sed -i 's/em1/eth0/g' /etc/sysconfig/network-scripts/ifcfg-eth0
    

    Удаляем файл:

    rm -f /etc/udev/rules.d/70-persistent-net.rules
    

    Перезагружаем сервер и видим наш eth0!

    Nginx: автоматическая защита от парсинга и DDoS-атак

    В своей прошлой статье я писал о возможности применения данного способа защиты от атак с помощью модуля Nginx testcookie. Сегодня мы более подробно остановимся на реализации скрипта, который автоматически будет включать защиту, обновляя конфиг и отправляя уведомление на email при срабатывании.

    Устанавливаем и включаем модуль:

    yum install nginx-module-testcookie
    
    # /etc/nginx/module.inc.conf
    load_module modules/ngx_http_testcookie_access_module.so;
    

    Скрипт /srv/scripts/check_ddos.sh выглядит следующим образом и работает довольно просто. Он мониторит LA и количество коннектов к nginx. При превышении установленных порогов LA_ACTIVATE или NGINX_CONNECT включает тесткуку и отправляет письмо на email. При снижении LA ниже порога LA_DEACTIVATE, скрипт выключает тесткуку:

    #!/bin/sh
    
    NGINX_CONF=/srv/www/nagg.ru/conf/nginx.conf
    MAIL="" # true is enable send mail
    MAILTO=root
    LA_ACTIVATE=17
    LA_DEACTIVATE=5
    NGINX_CONNECT=1000
    
    ########################################################
    TMPLOG=/tmp/testcookie_module.tmp
    NGINXCONN=`curl -s http://localhost/nginx-status | grep "Active" | awk '{print($3)}'`
    LA=`cat /proc/loadavg | awk -F '.' '{print($1)}'`
    
    function e {
        echo -en $(date "+%F %T"): "$1"
    }
    
    if [ ! -f $TMPLOG ];then echo 0 > $TMPLOG; fi
    LASTRESULT=`cat $TMPLOG`
    
    if [ -n "$NGINXCONN" ]; then
      if [ $NGINXCONN -gt $NGINX_CONNECT ]; then
        ALERT1="1"
      fi
    fi
    
    if [ -n "$LA" ]; then
      if [ $LA -gt $LA_ACTIVATE ]; then
        ALERT2="1"
      fi
    fi
    
    ALERT=$ALERT1$ALERT2
    
    if [ -n "$ALERT" -a $LASTRESULT -eq 0 ]; then
        e; printf "Nginx connect: %-4s LA: %-3s | Activate testcookie\n" "$NGINXCONN" "$LA"
        sed -i 's/.*##-AUTO-DDOS-LABEL-##/\ttestcookie on; ##-AUTO-DDOS-LABEL-##/g' $NGINX_CONF
        /sbin/service nginx reload >/dev/null 2>&1
        echo 1 > $TMPLOG
        if [ "$MAIL" = "true" ];then
            echo "Nginx connect $NGINXCONN, LA $LA. Nginx test-cookie enable" | mail -s "`hostname` DDOS detected. Nginx test-cookie enable" $MAILTO
        fi
    fi
    
    if [ $LA -le $LA_DEACTIVATE -a $LASTRESULT -eq 1 ]; then
        e; printf "Nginx connect: %-4s LA: %-3s | Dectivate testcookie\n" "$NGINXCONN" "$LA"
        sed -i 's/.*##-AUTO-DDOS-LABEL-##/\ttestcookie off; ##-AUTO-DDOS-LABEL-##/g' $NGINX_CONF
        /sbin/service nginx reload >/dev/null 2>&1
        echo 0 > $TMPLOG
    fi
    

    Docker + Consul. Начало

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

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

    Для начала работы нам потребуется дистрибутив Centos7-minimal.
    Далее переходим к установке и настройке Docker. Внимание, инструкция работает только для Docker версии 1.12 и выше (это на будущее :)!

    Как в Linux найти и рекурсивно заменить строку во всех файлах?

    Допустим нам требуется заменить email: root@mail.domain.ru на sf@nagg.ru во всех файлах в каталоге /home/www.
    Наиболее оптимальным вариантом выглядит следующая конструкция:

    find /home/www -type f -print0 | xargs -0 sed -i 's/root@mail\.domain\.ru/sf@nagg.ru/g'
    

    В данной конструкции используется print0, ниже выдержка из man find:

    -print0 (GNU find only) tells find to use the null character (\0)
    instead of whitespace as the output delimiter between pathnames found.
    This is a safer option if you files can contain blanks or other special character.
    It is recommended to use the -print0 argument to find if you use -exec command or xargs
    (the -0 argument is needed in xargs.).
    

    После выполнения, мы можем проверить что root@mail.domain.ru более нигде не прописан (файлов в выводе не должно быть):

    grep -rl 'root@mail.domain.ru' /home/www/
    

    Supervisord – как запустить PHP воркер?

    Довольно часто встречаются ситуации, когда необходимо запускать PHP воркеры, слушающие определенный порт. В случае падения скрипта или перезагрузки бэенда, а иногда и сервера, воркер приходится запускать руками, что совсем неудобно и не совсем правильно.
    Рекомендую пользоваться популярной утилитой: Supervisord, которая позволяет организовать работу фоновых PHP процессов. Рассмотрим настройку на практике.

    Установка Supervisord на CentOS:

    yum install supervisor -y
    chkconfig supervisord on
    

    Настройка Supervisord:

    В файле конфигурации (/etc/supervisord.conf), можно не вносить никакие правки, обычно настроек по-умолчанию достаточно.
    Создаем наш конфигурационный файл в подключенной директории: /etc/supervisord.d/

    /etc/supervisord.d/php-queue-worker.ini
    [program:worker]
    command=/usr/bin/php /srv/www/application/push-server.php
    numprocs=1
    directory=/srv/www/application/
    stdout_logfile=/var/log/supervisor/push-server.log
    autostart=true
    autorestart=true
    user=apache
    stopsignal=KILL
    

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

    Решил собрать все в одном месте, потому что часто что-то начинаешь искать и не находишь :)
    В продолжение статьи OpenVZ: полезные команды на заметку пишу дополнения!

    Установить для контейнера c CTID 10 512МБ ОЗУ и 1G SWAP:

    vzctl set 10 --ram 512M --swap 1G --save
    

    Установить для контейнера с CTID 10 2 ядра CPU:

    vzctl set 10 --cpus 1 --save
    

    Скрипт проброса портов: OpenVZ + iptables

    Один из механизмов автоматизации, когда на твоем сервере очень много OpenVZ-контейнеров с серыми IP, чаще всего им требуется не только доступ к интернет, но и проброс портов, чтобы извне заходить в сами контейнеры по SSH / FTP или любому другому протоколу, не важно. Конечно, как вариант, подходит ручная правка /etc/sysconfig/iptables и reload сервиса, но это не очень удобно и все-таки допускает «человеческий фактор», в данному случае скрипты автоматизации помогают нам.
    Недавно наткнулся на интересную реализацию скрипта iptables, который смотрит запущенные контейнеры OpenVZ и автоматически пробрасывает порты на каждый контейнер, это очень удобно!

    Рассмотрим его работу на примере, допустим у нас есть 3 контейнера OpenVZ:

    # vzlist
          CTID      NPROC STATUS    IP_ADDR         HOSTNAME
            20         11 running   10.11.0.20      test1
            21         11 running   10.11.0.21      test2
            22         11 running   10.11.0.22      test3
    

    Далее нам надо проверить, что у нас включен NAT на физической машине, так выглядит ситуация когда все в порядке:

    # iptables -t nat -nvL
    Chain PREROUTING (policy ACCEPT 19 packets, 1451 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain POSTROUTING (policy ACCEPT 12 packets, 947 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
    

    Git push fails: RPC failed; result=22, HTTP code = 411

    If you attempt to push a large set of changes to a Git repository with HTTP or HTTPS, you may get an error message such as error: RPC failed; result=22, HTTP code = 411. This is caused by a Git configuration default which limits certain HTTP operations to 1 megabyte.
    To change this limit run within your local repository

    git config http.postBuffer *bytes*
    

    where bytes is the maximum number of bytes permitted. For exmaple, set 500MB:

    git config http.postBuffer 524288000
    

    If you are using gitlab, you may need to change your nginx config too (/etc/nginx/sites-available/gitlab). More info: https://github.com/gitlabhq/gitlabhq/issues/3099