Category: мода

Category was added automatically. Read all entries about "мода".

Book

Обзор решений vmWare и Citrix

Официальные сайты - это какие-то сепульки-сепулькарии-сепуление, там написано всё с расчётом на то, чтобы впаривать роговолосым боссам за стейком и стрипперами.

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

Скажем, у VMware есть всего 2 гипервизора:
- Type-1 называется ESXi
- Type-2 называется Workstation

И дальше маппинг:

- VMware vSphere Hypervisor Free - бесплатная версия ESXi, включающая:
- сам гипервизор (довольно маленький!)
- аналог Xen Dom0, он:
- рисует прогресс загрузки и желто-серый туй, чтобы IP поменять или откатиться на прошлый имидж при неудачном обновлении
- предоставляет веб-гуй, через которого создавать DomU и аплоадить для них установочные iso/готовые vmdk-имиджи
- Предоставляет ссш к этому Dom0

- VMRC, VMware Remote Console - отдельное приложение для доступа к гостям ESXi, если нужно например больше возможностей по перехвату спецклавиш, чем позволяет HTML5

Итогдалие.
Book

Особенности серверов HPE

1. Платные обновления биоса и фирмварей контроллеров
2. Платная лицензия на встроенный IP KVM aka iLO
3. Выпускаются официальные имиджи ESXi, но реже адвисорис на ESXi
4. Есть отдельные биосы на случай установки ESXi, и версии биоса привязаны к версиям имиджей с которыми они тестировались.
5. Есть имиджи pre-gen9 и gen9 plus. Но это не значит что если сервер pre-gen9 - то можно брать pre-gen9 имидж. Надо смотреть с какими версиями ESXi конкретная модель сервера совместима, и брать pre-gen9 для этой версии.
6. Если обновлять ESXi по адвисорис - то обновляются только компоненты, которые мейнтейнит VMware
7. Если обновлять по офимиджам - то консистентно обновляются и компоненты HPE, и компоненты VMware, но редко. Редко - например для моего сервера последние дрова от HPE вышли в 2018 году, и с тех пор вышло более десятка обновлений от vmware, из которых 7 содержат адвисорис.
8. Если в принципе ставить обновления, выходящие не из HPE - то может случиться ситуация, в которой часть компонентов новее, чем в обновлении от HPE. Учитывая, что VMware говорит, что обновления кумлятивные, страшно подумать как будет обрабатываться.
9. Сейчас на сервере каша по сравнению с последним имиджем от HPE. Некоторые версии новее, некоторые старее. Есть пакеты типа собственно ESXI, которых нет в обновлении от HPE. В обновлении есть пакет hptestevent 6.0.0.01-01.00.5.2494585 vs testevent 6.0.0.02-00.00.8.2494585 на сервере, и ещё 5 пакетов в том же духе. Это hptestevent переименовали в testevent судя по версиям? Если да - то получается, что при установке hptestevent система обновления должна догадаться, что это старая версия testevent.
Book

Прожект-2

Я тут приболел гриппом, так что вернулся в боевое состояние только сегодня.

Из прошлых 4 пунктов:

1. Компиляция
2. Копирование в чрут
3. strace
4. Cборка имиджа

1 сделал до болезни, а 2 и 4 сегодня. Скрипт на 3 строчки, но падало то одно то другое. То копировал билд продукты не в ту папку в чруте, и имидж конструировался из устаревших билд продуктов, то оказалось, что моя трасса была неполной - один модуль сука он подгружает в рантайме, соответственно эту подгрузку надо было воспроизвести при трассировке. Ещё немного замедлили процесс пуши между виндой и линуксом - я рано обрадовался, и замержил скриптик в "апстрим".

Теперь очередь за перловым клиентом.. Вся затея заключается в том, что старый перловый клиент вис, так как использовал доморощенный догирмановский протокол, поэтому переделал серверную часть, и заодно на ноду, а теперь осталась клиентская. Пока серверная часть - "пустышка", которая ничего не делает, просто логирует приходящие от клиента сообщения.Но задача как раз протестировать минимальные клиент и сервер на предмет зависаний.
Book

Прожект

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

1. Проектик делал в Студии, ну и делал в отдельной от монорепы папочке. Так что задача для начала смержить его в монорепу.

2. Затем надо написать скриптик, компилирующий TS -> JS и копирующий JS в чрут будущего имиджа с нужными для деплоймента пермишенами.

3. Скриптик запуска strace в чруте

4. Скриптик лепления имиджа по strace и чруту

Вторым этапом переделка этого всего на докер, через docker cp -a, buildah или source-to-image.
Book

Огороженный хероку без говна для ноды

Это очередные мысли о том, как нам реорганизовать https://github.com/nponeccop/vz

Во-первых, OpenVZ (и в значительной мере Xen) в значительной степени умерли на рынке говнохостингов http://lowendbox.com/ и заменились на KVM.

Во-вторых, появился CentOS 8 c systemd

В-третьих, выросла инфраструктура для альтернативных докеров - типа runc и соответствующей инфраструктуры имиджей

В-четвертых, Redhat отдался IBM, то есть по идее со временем станет ещё более дубовым.

В связи с этим нужно портировать vz c CentOS 6 на CentOS 8

Если кто не помнит, суть vz токова: это система для запуска контейнеров, устойчивая ко взлому. Устойчивость достигается отсутствием каких-либо демонов, реестров и менеджмент-соединений. Система почти airgapped - вся менеджмент-активность идёт через Ansible, который работает через SSH.

а) нет ни входящих ни исходящих соединений
б) нет постоянно запущенного говнокода - запущены только приложения и systemd, который запускает sshd по требованию

Ну то есть в некотором смысле это возврат к старому подходу (до devops и автодеплоймента), при которой всё конфигурирование выполняется только админом и только вручную, за исключением того, что у нас не вручную, а посредством Ansible. Ansible выбран по 4 причинам:
- Redhat/IBM
- работоспособность на голом CentOS
- работа только в момент реконфигурации
- работа только через входящее SSH-соединение

В частности:
- отсутствие какой-либо активности, если реконфигурации не происходит и админ спит (условно, отсутствие пулла манифестов по таймеру)
- как следствие, отсутствие демонов и management-related servers,
- отсутствие отдельных входящих и исходящих коннекшенов и

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

1. В отличие от условной CoreOS, в которой есть etcd. И где можно взломать сам etcd c вероятностью большей чем взлом OpenSSH, после чего рут на всём кластере, или взломать любой сервер, у которого by design есть доступ к etcd то есть легко получить список всех серверов и имиджей на них запущенных.

2. В отличие от докера, где есть реестры и dockerd голой жопой в ынете, прикрытые только написанной мальчиками-дебилами схемой авторизации вокруг HTTPS (недебилами аутентификация и крипта, я надеюсь, но всё равно говно-го не так непробиваем, как OpenSSH). Взлом реестра в случае ноды позволяет получить сорцы всей системы как на ладони. Не говоря о возможности подменить имиджи своими (я надеюсь, схема подписей имиджей оффлайн-ключами там есть, но скажем, реестра с end-to-end шифрованием имиджей, который был бы не менее устойчив, чем моя схема с пушем, нету).

Кстати о пушах. В связи с тем, что соединения запрещены, мы можем только передавать имиджи через SSH в момент обновления, что не исключает схем с SSH port forwarding на машину админа, но варианта с аплоадом тарболлов через SFTP средствами Ansible оказалось достаточно.

Ортогональна к схеме работы с имиджами-контейнерами-релизами схема с парсингом вывода strace и созданием "минимальных" имиджей, что делает скажем, пуш на десяток серверов через мегабитное соединение, реальностью. Селф-контейнед тарболл без использования уменьшенных libc, стат.линковки или дельта-слоёв выходит в 17 метров (правда i686). Думаю можно отказаться от этого в пользу стандартных имиджей и-или сделать гибридную модель с пуллом базового имиджа с докер-хаба.

Но по большому счёту в сборке имиджей конь не валялся и там есть где фантазии разгуляться. Так что можно считать это отдельным подпроектом и первое время не париться (но например, вытягивать наши сорцы с реестра ни в коем случае нельзя). В любом случае, какой-то черновой вариант имиджей-без-реестров у нас есть, и можно его и оставить на первое время.

Далее ввиду требования к отсутствию демонов хорошо бы использовать не докер, а какого-то из его младших братьев, типа runc. Текущие имиджи (точнее, бандлы в которые имиджи распаковываются) у меня соответствуют спецификации, которую требует runc, так что он их прекрасно запускает (не считая потенциальных проблем с PID 1 zombie reaping).

Основной объём работ - это перевод vzexec на рельсы systemd и замена ручной работы с vzmaster push/vzmaster start/vzmaster kill, который внутри дёргает ansible, на полноценную ansible-конфигурацию. Ну то есть, надо писать кастом-роли ансибла, которые сами будут пушить то, что нужно. Сейчас иногда доходит до абсурда - vzmaster не понимает групп серверов, и выполняет операцию для всех серверов из /etc/ansible/hosts, так что я постоянно комменчу одни и раскомментирую другие. Что на практике оказывается не error prone, но утомительно и концептуально детский сад и/или ад.

Заодно полечится отсутствие персистенса - сейчас, если сервер перезагружается, то все контейнеры падают и надо раскомментировать этот сервер в hosts и делать на нём vzmaster start для примерно 5 контейнеров. Тьфу!

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

"Я тут нашёл имейл от августа там нас биллят за 2.3.4.5. Мы это ещё используем?"

Это можно решить, используя конфиг ансибла для конфигурации приложения (DRY) и положив конфиг под сурс-контрол, дабы было понятно, что в нём мы переставляли и с какой целью (конфиг приложения сейчас под сорс контролом, но он независим от vz). Но для этого надо отказаться от ада с vzmaster, см. выше.

Ещё назрела система автоматических билдов - сейчас vzbuild просто собирает базовый имидж по списку файлов, собранному strace. Хорошо бы сделать типа хероковских релизов - ну то есть чтобы vzbuild release привязывал имиджи к ревизии, из которой они были собраны, и работал через pull - то есть чтобы нельзя было зарелизить что-то незакоммиченое.

Ну и я постоянно посматриваю на https://github.com/openshift/source-to-image в надежде на то, чтобы весь билд выполнять в изолированных имиджах, а не на хост-тачке. Я начал было это лепить, используя docker hub в качестве соплей, но застрял на том, что на докерхабе нету нужной для работы strace капабилити. Но если отказаться от говноедства с strace, или отказаться от докерхаба, или заниматься трассировкой после сборки имиджа, в отдельной фазе "облегчения", может получиться.

Ещё одна необходимая фича - это апгрейд и даунгрейд релизов. Ну то есть сейчас все имиджи независимые - и можно пустить (на одном хосте) несколько разных версий одного имиджа параллельно. Ну и при апгрейде надо помнить id старого и нового имиджа. Что на практике более error prone, чем раскомментирование хостов. Соответственно в ansible надо будет сделать, что если мы хотим версию foo имиджа bar - то все остальные версии надо тушить, или как-то так.
Book

ArchLinux i686 Docker images

https://hub.docker.com/r/nponeccop/archlinux-microcontainers/~/dockerfile/

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

nponeccop/archlinux-pacstrap-i686 обошелся почти без приседаний: mkrootfs.sh. Интересно, что там лжеприседания, которые не работают. Также обнаружил, что официальный аналог debootstrap tarball у нас в i686-версии отсутствует.

В-общем есть пакет arch-install-tools, в котором утилита pacstrap может собирать чруты, и это имидж из неё.

Но оказалось, см. archlinux-base-i686/Dockerfile, что наступает несколько жоп, из-за которых голый pacstrap не работает, и надо приседать:

- в группе base в Арче лежат заведомо дебильные пакеты типа cryptsetup и e2fstools, которые в контейнере не нужны. Кроме того, pacman -Qg base перечисляет все-все пакеты из группы, а не только топовые. Короче чем перечислять список пакетов, которые НЕ надо ставить, оказалось проще перечислить то, что НАДО
- в триггере установки gpgme, который зависимость pacman, наблюдалась двойная жопа: а) в pacstrap-имидже нет coreutils, б) он генерирует какие-то ключи, а энтропии в urandom не хватало, поэтому пришлось поставить и запустить haveged
- без setarch pacstrap пытается искать 64-битный арч на зеркалах 32-битного арча, а его там нет и нам нужен именно 32-битный
- сам setarch идет в util-linux, которых внезапно нет в base
- pacstrap в процессе хочет монтировать в НОВУЮ rootfs специальные файловые системы, что не работает в докере

В-общем, завтра будет вторая итерация.
Book

Блядские будни

Надо наверное дневник вести, чо я такого леплю.

Вчера занимался подъёмом докера на ClearLinux. Отличается от арча тем, что нет еботни, не считая добавления статического адреса и переключения докерд на слушание на 0.0.0.0 (без авторизации, Карл, ибо всё равно в презервативе)

Докер-билд из арча на клеарлинукс работает норм, не надо никаких файловых шар лепить, всё по докер-протоколу шлют (карл!)

Однако тут же поломал всё нахуй: оказалось, что pacstrap (это аналог debootstrap для арча) не работает под докером ввиду того что proc монтировать внезапно запрещено. Недоработали! Один проц же и так есть, почему нельзя его же примонтировать и в другом месте?

"лечится" путём запуска docker run --add-caps CAP_MEGAADMIN или как-то так, что полная хуета, но вроде это почти единственный вариант (второй - это монтировать всё что нужно в конфе контейнера и переписать pacstrap так, чтобы использовал уже заранее готовые манутпоинты).

Но и это ещё не всё! При запуске с --add-caps оказалось, что мой 32-битный pacman сетапит 64-битные пекеджи, так как запущен под 64-битным ядром. Что правильно, но не то, что мне нужно.

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

Но старый имидж я собирал на говне и палках, так что новый решил по-прямому. Для чего попробовал суперпарсер strace на питоне вместо моего на седе. Но он оказался а) на регулярках б) бракованным. Короче зарепортил багу и решил писать свой.

Бросился было к перлу, но тут на меня нашло что вроде как нода уже давно рабочий инструмент. Нашёл panda-grammar под ноду и второй час с ним ебусь. Такие дела! К счастью, багов не обнаружил, просто недоделано.
Book

Ещё о деплойменте

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

- Взаимодействие аналитиков со стейкхолдерами, извлечение информации из чатов в трекер
- Документирование инцидентов. Сервер упал пришлось переподнять, в очередной раз произошел редкий креш (залогировано редкое событие и т п). Некие объективные данные для оценки серьёзности проблем. Часто бывает недооценка приоритетов в духе "я думал, что этот креш происходит раз в месяц, а вы оказывается каждый день руками переподымаете а мне ничего не говорите". Наоборот тоже бывают - требуют починики редких крешей. Это аналогично случаю, когда хотят ускорения компонента, который почти не влияет на общую производительность. Только не про производительность, а про надёжность.
- Статистика по логам, стектрейсам и креш-дампам. Фактически то же самое что выше, но если восстановление от отказа автоматическое или отказы некритические и невидимые. Своего рода автоматически документируемые инциденты и автоматически собираемая дополнительная информация по вручную задокументированным инцидентам.
- Secure by design система архивирования и бекапов. Скажем, взломанная система не может незаметно затереть или подменить свои бекапы, сделанные до момента взлома (всякие бекапы-на-шару этим свойством не обладают). А если даже взломана система где лежат эти бекапы, взломщик не может их прочитать поскольку они зашифрованы публичным ключом, приватный ключ к которому знает только HSM который сам его сгенерировал и никому не говорит и вообще лежит в сейфе и никогда из него до момента форенсик-анализа инцидента не доставался. Хеши старых бекапов лежат в блокчейне, так что даже если доступ на затирание таки получен, мы это увидим. И те пе, тут можно много напридумывать.
- Мониторинг с алертами и обнаружением аномалий (скажем, автоматически строится статистическая модель текста логов, over 9000 пейперов по anomaly detection ). On-premises https://anomaly.io/ без демонстрации своего очка третьим лицам, с устойчивой системой архивации в стиле предыдущего пункта, т.е. взломщик не может прочитать или подделать метрики собранные до момента получения доступа даже если сломал сервер метрик
- Сорс-контрол: как хостить сорс-контрол, какие бранчи, как сквошить, как называть коммиты, как помечать версии которые попадали на стейджинг и продакшон, как интегрировать с багтрекером ("в какой версии это было пофикшено"), как составлять юзер-визибл ченжлог.
- CI/CD, reproducible builds, обеспечение идентичности стейджинга и продакшена путем техник наподобие имиджей или rpm-ostree. Опять же невозможность подделки имиджа задним числом.
- ...
Book

CoreOS всё?

У меня тут попадали непотопляемые дроплеты CoreOS. Нарвался на баг https://github.com/coreos/bugs/issues/1649 , своего рода ахиллесову пяту, т.к. оказалось, что кореос непотопляем, не считая бутлоадера, и потопить можно только при несчастливом стечении обстоятельств:

- стабле ветка
- пропустили несколько обновлений
- большая задержка в консоли, отображающей бутлоадер

В-общем, полечил, а потом стёр кластер нах. Поскольку оказалось, что они задепрекейтили fleet в пользу kubernetes, и надо всё задеплоивать с нуля. А это и так был пилотный кластер, который особо не эксплуатировался, т.к. наколенное говнище оказалось удобнее™.

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

Практика обновления системы на продакшене

А как нынче правильно™ обновлять промышленный™ продакшон?

Напридумывать можно много чего, но есть ли какие-то готовые бест практисы?

Примеры того, как делать не надо:

- Руками ходить по 20 серверам и делать там условный yum update && reboot
- Обновлять неконсистентно (например, рассинхронизировавшиеся мирроры реп или обновления опубликованные в момент, когда обновилась половина серверов)
- Забывать перегружать сервисы и систему (как вообще понять, когда надо, а когда нет. Очевидно, например, что ведро и libc требуют)
- Обновлять непротестированным набором обновлений
- Обновлять без возможности отката в будущем

Таких хотелок можно придумать ещё 100500 при желании, и они нинужны™. Поэтому вопрос больше о реалиях и вендоронезависимых и руконезависимых общих знаменателях.

Например, "тестировать на стейджинге ami-имиджи и затем старый кластер убивать, а новый провижонить из имиджей" - решает все 5 хотелок выше (но помните что это рандомные 5 хотелок из параллельной вселенной с радугой и единорогами). Но это

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

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

Также интересно понять набор тру-хостингов. Куда, понятно, входит AWS, GCE и Azure. А что ещё? DigitalOcean? RackSpace?