stanislavvv

Спустя 10 лет существования внутреннего CA таки решили, что нужны и промежуточные CA.
Допилил https://github.com/stanislavvv/ca-na (голая копия рабочего CA).
Удивлён, что заработало практически сразу, чего из моего опыта не ожидалось.

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

P.S. На первое декабря был поставлен шароварный Doom. Как ни странно - отлично работает и играбелен даже в окошке.

На работе обозвали аристократом.
Причина: посылаю подальше без мата.

Запустили технопревью следующей версии шаред хостинга, с изоляцией сайтов и контейнерами. Точнее, всё в контейнерах, включая ssh-сессию.

Бесплатно до тех пор, пока не допилим до конца (планируется до 15 марта доделать, но с учётом того, что сей хостинг хотели выкатить ещё осенью - хз).
Кому надо - регистрируйтесь на netangels.ru и пишите в техподдержку про то, что хотите протестировать "облачный хостинг".

Главное - пишите на info@netangels.ru о багах и недофичах :-)

Небольшая задачка: получать top10 клиентов и top10 доменов, жрущих место на почте. Графит как источних сих данных для графаны в целом справляется, но есть некоторые но:
- статистика складывается в influxdb, который не умеет сортировать по чему-либо кроме времени. Для получения топов приходится раз в 5 минут запускать по селекту на каждый вид статистики и пихать получившиеся значения в графит.
- графит хранит данные э... не совсем эффективно. То есть, если количество метрик увеличится ещё раза в три, то он перестанет справляться даже с записью.

Попробовал https://github.com/InfluxGraph/influxgraph в качестве источника данных. В теории всё нормально. На практике при количестве клиентов в статистике порядка полутора-двух тысяч (отдельно взятый сервер) создаётся запрос к influxdb объёмом килобайт в 30-40, чем сей influxgraph успешно давится, не доводя запрос до influxdb и выдавая 500-ю ошибку графане.

Пока смотрим в сторону яндексового кликхауса, но там есть нюансы типа того, что это не time series database и вообще нечто новое...

Чтоб не забыть, если вдруг чего - запишу, чего делал.

1) docker registry - обычный контейнер registry.
Проброшены тома certs:/certs и data:/var/lib/registry
Установлены следующие переменные:
REGISTRY_AUTH_TOKEN_REALM=https://dreg.domain.tld/api/auth
REGISTRY_AUTH_TOKEN_SERVICE=dreg.domain.tld:5000
REGISTRY_AUTH_TOKEN_ISSUER=dreg.domain.tld
REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE=/certs/dreg.crt # на самом деле - такой же, как и следующий
REGISTRY_HTTP_TLS_CERTIFICATE=/certs/dreg.domain.tld.crt
REGISTRY_HTTP_TLS_KEY=/certs/dreg.domain.tld.key
REGISTRY_STORAGE_DELETE_ENABLED=true # для удаления ненужных образов

поскольку я таки лентяй - оставил реестр на порту 5000

2) docker-registry-web - вебморда к докеру, осуществляет авторизацию, раздачу ролей и позволяет удалять контейнеры, если в реестре это разрешено.
конфиг registry-web.yml:

registry:
  # Docker registry url
  url: https://dreg.domain.tld:5000/v2
  # Docker registry fqdn
  name: dreg.domain.tld:5000
  # To allow image delete, should be false
  readonly: false
  # Trust any SSL certificate when connecting to registry (self-sign too)
  trust_any_ssl: true
  auth:
    # Enable authentication
    enabled: true
    # Token issuer
    # should equals to auth.token.issuer of docker registry
    issuer: 'dreg.domain.tld'
    # Private key for token signing
    # certificate used on auth.token.rootcertbundle should signed by this key
    key: /conf/dreg.key

Дополнительно ставится переменная REGISTRY_TRUST_ANY_SSL=true (почему-то установленное в конфиге не является убедительным)
Пробрасываются следующее:
a) conf/registry-web.yml:/conf/config.yml:ro - конфиг
b) conf/dreg.key:/conf/dreg.key - ключ для авторизации (соответствует dreg.crt из конфига реестра)
c) db:/data - каталог под БД вебморды

используется версия контейнера hyper/docker-registry-web:v0.1.2 (более новая 0.1.3 таки не заработала как надо)

3) вебморда на nginx. Чисто для https к вебморде.

А всё почему? Потому что разрекламированный Portus не делает архивных копий своих _работающих_ версий, отчего в один прекрасный момент у них оказались разломанными не только контейнеры, но и rpm. А пересобирать нечто на ruby, да ещё зависящее от хз какой версии мне как админу сильно влом.

Притащили мне токен:

и говорят человеческим голосом:
- Хотим мы получать данные из сбербанка автомагически и загружать в свою систему! А то сейчас оно через ж только руками через копипасту!

Пришлось делать.
Сделалось следующее:
1) десктоп на lxde на базе Debian/Jessie
2) поставлена неофициальная бета-версия софтины с официального форума разработчика. Поставлена неофициальным путём - после пересборки пакета.
3) поставлен сервер x2go, дабы не ходить ногами или через яву в iLO до десктопа ради единственного клика в меню.
4) сей "десктоп" об одном юните был поставлен в датацентр на белом ip.

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

Теперь данный сервер запускается так:
1) после загрузки заходим через x2goclient и вводим пин в предлагаемую форму
2) отваливаемся по таймауту, так как несмотря на галочки, софтина таки отрубает соединения
3) снова заходим через x2goclient и убеждаемся, что сбербанковский фтп доступен.

Всё. Остальным занимается крон, скрипты и sshd.

Написал на работе микросервис для данных о бекапах. Рад, щаслив, горд (С)

Посмотрел, что ещё даже непонятно, куда и как их деплоить.
Уже не щаслив.

Посмотрел, сколько мест, где потребуется переписывать только с моей стороны (собственно, скрипты бекапов/восстановления как на серверах, так и на хранилищах).
Уже не рад.

Спросил у программистов, когда, они смогут заняться - аж весной. Уже не горд.

Расставил по ранжиру в разных категориях.

Urls:
ceph - http://ceph.com
sx/libres3 - http://www.skylable.com/
riak/riak-cs - http://basho.com/ (они переименовали riak в riak kv, а riak-cs в riak s2, но софт от этого не поменялся), доки - http://docs.basho.com/

Сложность архитектуры (для случая использования протокола S3):

I. ceph - три вида узлов (или четыре, если выделить админский узел в отдельный) - хранилище, монитор, шлюз, общение между собой по ключам
II-III. riak/riak-cs и sx - по два вида узлов - бекенд (riak - БД, sx - файлохранилище) и фронтенд (riak-cs - умный фронтенд, который и реализует хранение файлов, libres3 - более-менее тупой конвертер протокола s3 в протокол хранилища)

Сложность установки:

I. ceph - связано со сложностью архитектуры и некоторой запутанностью документации, которая не столько документация, сколько справочник. Плюс не всегда очевидные расчёты параметров.
II. riak/riak-cs - можно всё сделать по документации, но без расчёта некоторых параметров можно получить либо кластер, который либо не сможет полностью использовать текущее железо, либо будет расчитан на бОльшее количество узлов и будет жрать память больше, чем требуется.
III. sx - тупо apt-get install и немного ответов на вопросы в sxsetup

Возможность донастройки:

I. ceph - практически всё, что может понадобиться настроить - можно настроить.
II. riak/riak-cs - часть настроек неочевидна, часть недокументирована, мне для некоторых приходилось лазить по спискам рассылки и по эрланговским исходникам. Часть настроек, которые вообще говоря, предназначены для riak, пишутся в настройки riak-cs.
III. sx - тупо нечего настраивать в конфиге. От слова вообще. Можно перераспределить место в кластере или ещё что-нибудь такое. Но сказать "дай открыть больше соединений, будет афигительная нагрузка" - нельзя.

Требования к железу (на тестовом кластере с репликацией 2x):

I. sx - пойдёт практически на чём угодно
II. ceph - в узлах osd хочет 1Гб памяти на каждый терабайт места, остальным - просто по гигабайту достаточно (вероятно, radosgw под нагрузкой захочет большего, но не факт)
III. riak/riak-cs - жрёт память. Процессора хочет немного - не больше пары-тройки ядер на узел даже в продакшне.

Достоинства:
sx/libres3 - простота установки и конфигурации
riak/riak-cs - работает практически сразу после установки, если нет особых требований - довольно удобен.
ceph - можно настроить всё, обладает довольно-таки приличным быстродействием

Недостатки:
sx/libres3 - практически не тюнится, имеет базы sqlite в качестве бекенда, виснет на несколько минут при срабатывании gc на любом из узлов.
riak/riak-cs - жрёт память на фронтенде непонятно куда, жрёт память на бекенде, жрёт место на диске в процессе нормальной работы (потом отдаёт обратно, но если места не хватило - падает), не может посчитать статистику объёма бакета, если в бакете несколько сот тысяч файлов (у меня для рабочего кластера проблемы начинались где-то на 600-800 тысячах файлов в зависимости от нагрузки), иногда riak-cs ни с того ни с сего говорит "all workers busy" и это до его рестарта.
ceph - хранит каждый чанк/объект в отдельном файле, что на рекомендуемом ими xfs чревато проблемами, и если там всё можно настроить, то вы таки будете всё настраивать.

На работе в качестве хранилища поставлен кластер из RiakCS + Riak.
В целом работает, но кой-чего там не устраивает (в частности, скорость работы при большом количестве файлов в бакетах).
Решили протестировать связку Sx+LibreS3. Поставили два идентичных по железу кластера + по одному фронтенду и потестили.
Итоги:
1) тест с миллионом файлов в бакете.
Riak - шустренько залил миллион, но зато чтение корня бакета заняло почти 7 минут и потребовало увеличения таймаута в конфиге s3cmd
Sx - за выходные так и не залил миллион, но чтение корня бакета при 700 тысячах - порядка 30 секунд.

В процессе залития у Sx наблюдаются глобальные тормоза на несколько минут при запуске gc на одном из узлов бекенда.

2) тест с крупным файлом
Сохранение:
Riak - тихо и мирно залил на скорости 3Мбайт/сек (у виртуалок ограничение по сети - 100Мбит, так что в сеть не упиралось)
Sx - начал заливать на скорости 10Мбайт/сек, но после залития последнего чанка затупил так, что время на операцию оказалось больше, чем в случае riak.

Скачивание:
Riak - отдал на скорости 6Мбайт/сек
Sx - отдал на сокрости 10Мбайт/сек

3) поддержка ACL и политик
Riak ACL поддерживает, политики - аналогично.
Sx не поддерживает ACL вообще, но поддерживает некоторые политики. И, похоже, отсутствие поддержки ACL таки даёт бОльший результат, чем результаты тестов производительности в смысле принятия решения.

Посмотревши на документацию ceph - там с ACL аналогично, так что, скорее всего, тоже отпадёт.