DevOps, SRE
at ManageBac

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

Железо

• Процессор - Intel(R) Pentium(R) CPU G3260 @ 3.30GHz
• Материнская плата - AsRock H81M-VG4 R4.0
• Операционная система установлена на SSD Intel 120GB
• Хранилище - 3x3TB WD Blue/Red собранный в RAID-5
• Память - 16ГБ

Операционная система

В качестве операционки я использую на данный момент Ubuntu 18.04.4 с планом мигрировать на 20.04. Раньше была 16.04 и я переехал простым апгрейдом без особых проблем.

Софт, установленный прямо в системе

• Minidlna раздает скачанное медиа на телевизоры (хотя в нем нет уже особого смысла, почти полностью его заменил Plex)
• rsnapshot делает бэкапы удаленных серверов
• haproxy выступает лоадбалансером для проброса портов в k8s
• openvpn в качестве клиента для обхода некоторых блокировок

Итого по софту, установленному в системе: уже можно отказаться от minidlna и заменить haproxy на MetalLB. Останется только две простые утилиты и чистая система. Потом можно упаковать rsnapshot в docker и вообще будет огонь. Все остальное развернуто в docker или kubernetes.

Софт, развернутый с docker-compose

• timecapsule для бэкапов маков
• qbittorrent для автоматического скачивания торрентов
• jackett для поиска по треккерам
• radarr для отслеживания появившихся релизов и добавления в закачки
• plex для просмотра сериальчиков и фильмов
• zoneminder пишет видеопотоки с камер наблюдения на даче
• несколько баз данных для проектов и тестов

Kubernetes

k8s развернут с помощью kubeadm этим способом. Список того, что там крутится:

• несколько простых проектов
• drone agent для DroneCI
• librespeed для тестирования канала в интернет
• piwigo для просмотра архива фоточек
• registry для хранения образов билдов
• smokeping для отслеживания состояния каналов связи
• searx персональная поисковая система

Пока это все, что задеплоено. Но есть еще идеи, что добавить. Например, paperless-ng.

В планах обновить железо до AMD Ryzen и 32 гигов оперативки.

30 мая истёк 20-летний срок действия корневого сертификата AddTrust, который применялся для формирования перекрёстной подписи (cross-signed) в сертификатах одного из крупнейших удостоверяющих центров Sectigo (Comodo). Перекрёстная подпись позволяла обеспечить совместимость с устаревшими устройствами, в хранилище корневых сертификатов которых не был добавлен новый корневой сертификат Sectigo.

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

Что нужно сделать

На веб-серверах перевыпустите ваши сертификаты. С 90% долей вероятности вам будет выдан новый бандл с корректным сертификатом.

Для Ubuntu-сервер нужно сделать следующее:

$ sudo sed -i 's/mozilla\/AddTrust_External_Root.crt/\#\ mozilla\/AddTrust_External_Root.crt/' /etc/ca-certificates.conf 
$ sudo update-ca-certificates -v -f

После этого все начинает работать как положено.

Довольно часто надо сделать так, чтоб при старте сервера запустился какой-либо скрипт. Это довольно просто и очень многие это знают. Просто добавляем запуск этого скрипта в /etc/rc.local и он будет запущен. Но что делать, если надо запустить скрипт при выключении сервера? Например, загрузить логи перед уничтожением облачного сервера.

Решение простое, если знаешь, как устроена система запуска Linux.

Надо всего-то положить скрипт в /etc/rc6.d.

Имя скрипта должно начинаться с K99 и дальше само имя.

Так же надо установить execute права на скрипт:

$ chmod +x /etc/rc6.d/K99example

При выключении этот скрипт отработает.

Иногда, так случается, что надо расширить диск для какого-то EC2 инстанса. Это можно сделать не останавливая сам инстанс, чтоб не прерывать работу сервиса.

Для этого заходим в веб-консоль AWS, находим нужный volume и увеличиваем его размер.

Потом нужно увеличить раздел и саму файловую систему на этом разделе. Заходим по ssh на инстанс и расширяем раздел:

$ sudo growpart /dev/xvda 1

Получаем что-то типа:

CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=41940959,end=41943007

Теперь даем понять ядру, что надо перечитать новую таблицу разделов:

$ sudo partprobe

И расширяем файловую систему:

$ sudo resize2fs /dev/xvda1

Результат:

resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242619 (4k) blocks long.

on-line resizing required говорит о том, что файловая система была расширена.

Иногда на бетах MacOS Catalina ломается python3 и все, что с ним связано. Просто показывается ошибка «Abort trap: 6» и все. Тот же pip3 не запускается совсем.

Я довольно не мало перерыл статей в поисках причины и нашел, что это связано с библиотеками OpenSSL. Фикс довольно простой:

ln -s /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libcrypto.dylib /usr/local/lib/libcrypto.dylib
ln -s /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libssl.dylib /usr/local/lib/libssl.dylib

Эта заметка скорее для себя самого, чтоб не забыть, если оно опять сломается.

Концепция бастиона не нова и давно используется для доступа в охраняемый периметр. Но вот как получить доступ к внутренним серверам в прозрачном режиме? Тут мы это и рассмотрим.

ProxyJump

Опция командной строки

Начиная с версии SSH 7.3 есть настройка конфигурации клиента ProxyJump или -J флаг:

ssh -J <bastion-host> <remote-host>

Так же можно указать разные имена пользователей и порты:

ssh -J bastionuser@<bastion-host:port> user@<remote-host:port>

Так же, можно указать несколько бастионов:

ssh -J <bastion1>,<bastion2>,<bastion3> <remote-host>

SSH config

### The Bastion Host
Host bastion-host-nickname
  HostName bastion-hostname

### The Remote Host
Host remote-host-nickname
  HostName remote-hostname
  ProxyJump bastion-host-nickname

А дальше как обычно:

ssh remote-host-nickname

Альтернативный метод: форвардинг stdin и stdout

Если ваш ssh клиент более старый, чем 7.3, то можно использовать такой подход:

ssh -o ProxyCommand="ssh -W %h:%p bastion-host" remote-host

Собственно, это все так же можно оформить в конфиг, чтоб не запоминать:

Host remote-host
  ProxyCommand ssh bastion-host -W %h:%p

А дальше опять просто:

ssh remote-host

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

В случае с python pip это можно сделать так:

mkdir ~/.pip
cat <<EOF > ~/.pip/pip.conf
 [global]
 trusted-host =  mirrors.aliyun.com
 index-url = http://mirrors.aliyun.com/pypi/simple
EOF

После этого пакеты будут ставиться сильно быстрее.

Когда у вас достаточно нагруженный проект на RoR и для запуска вы используете Passenger, то рестарт приложения может вызывать небольшой (а иногда и простой) простой. Это не есть хорошо.

Passenger имеет две версии - Open Source и Enterprise. Так вот в Enterprise версии есть опция --rolling-restart, которая и позволяет не перезапускать сразу все инстансы приложения, а делать это поочереди.

В Capistrano это настраивается элементарно:

set :passenger_restart_options,
  -> { "#{deploy_to} --ignore-app-not-running --rolling-restart" }

Мониторим перезапуск вот так:

passenger-status

Не так часто, но бывает надо сделать деплой на, скажем, 20 хостов, которые находятся за bastion'ом.

Если у вас 5 хостов и все работает как часы, то нет проблем, казалось бы. Увеличиваем количество хостов, запускаем деплой, profit.

Но чаще всего вы получите ошибку и будете очень долго удивляться, как же так...

Ошибка будет вида:

cap aborted!
Errno::EPIPE: Broken pipe
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:44:in `write'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:44:in `negotiate!'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:32:in `initialize'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/session.rb:84:in `new'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/session.rb:84:in `initialize'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh.rb:232:in `new'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh.rb:232:in `start'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/connection_pool.rb:59:in `call'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/connection_pool.rb:59:in `with'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/netssh.rb:155:in `with_ssh'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/netssh.rb:49:in `upload!'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/capistrano-3.6.1/lib/capistrano/tasks/git.rake:24:in `block (3 levels) in <top (required)>'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/abstract.rb:29:in `instance_exec'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/abstract.rb:29:in `run'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
The deploy has failed with an error: Broken pipe
** Invoke deploy:failed (first_time)
** Execute deploy:failed


** DEPLOY FAILED
** Refer to log/capistrano.log for details. Here are the last 20 lines:

И дальше еще большой стэк-трейс, который вам ровным счетом ничего не даст.

Опытным путем вы прийдете к тому, что 10 хостов деплоятся нормально, а вот 11 уже нет. И дело тут совсем не в Capistrano, а в вашем ssh сервере на bastion'е.

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

Итак, было:

# MaxStartups 10:30:60

Стало:

MaxStartups 30:30:60

Если вы получаете ошибку типа:

Error installing mysql2: ERROR: Failed to build gem native extension.

то решение очень простое. Сначала ставим openssl

brew install openssl

А потом ставим gem необходимой версии:

gem install mysql2 -v '0.5.2' -- --with-ldflags=-L/usr/local/opt/openssl/lib --with-cppflags=-I/usr/local/opt/openssl/include

Версию gem'a поправьте под свою.