Все 3 нокии, которыми пользовался, тоже имели лимит на количество смс. Это вам похоже повезло с конкретными моделями, если больше чем 5 лет назад не встречались с ограничием.
РПН разошлёт ультиматумы додо, пападжонс, яндекс.еде, деливери клаб и прочим. Регистрироваться в реестре юридических лиц — ответственных производителей и организаторов оперативной доставки пицц никто не станет, все перейдут на выпечку и доставку «открытой кулебяки».
P.S. По опросам левады и вциома внесение пиццы с ананасом в реестр запрещённых пицц поддержит 91,42%.
Всё просто — размер цифр. ИН-18 — 40мм, ИН-14 — 18мм.
Так-то более-менее доступны Z568 с цифрами 50мм. Есть оригинальные на ebay, есть от Далибора. Дальше вопрос либо соглашаться на 600-800 евро за 4 лампы, либо искать подешевле. ИН-18 для подарка — отличный выбор.
Так по-моему это и есть один из посылов доклада: современный мониторинг это не изолированный компонент, а неотъемлимая часть самого приложения и у разработчиков в плане должно быть заложено время на реализацию источников метрик.
С опцией --docker-run всё ясно-понятно: из образа будет запущен контейнер, который заместит контейнер в кластере.
А вот про «без опции» что-то не до конца въеду. Локальная машина будет якобы контейнером в кластере, так? Что будет, если таких команд несколько запустить, начнут мешать друг другу?
metacontroller создаёт deployment с nginx и initContainer, который выкачивает с s3 и распаковывает.
Я правильно понимаю, что логику создания и логику выкачивания надо в js/py скрипте сделать? Сам metacontroller только за событиями следит и запросы к скрипту делает?
CR… не rocket science
Имел в виду, что rocket science это всё, что стоит за CR — для организации этой машинерии надо обладать каким-то опытом. Пока инженер поймёт, чем CompositeController отличается от DecoratorController, а ему надо всего лишь за лейблами на подах следить и kubectl apply сделать, да он всё бросит и крончик напишет.
Но вообще согласен, если умно выделить типы часто встречающихся задач и оформить в виде sync скриптов и CRD с документацией аргументов, то конечно проще будет CR написать нужный.
MyDevEnvironment, который создаст namespace и secret наверное было бы круто и красиво… Но это дополнительная сущность в кластере, для которой придётся описать CRD, где-то её задокументировать, донести до всех участников процесса, что мы теперь почему-то не создаём обычный Namespace, а делаем только MyDevEnvironment.
Дальше нужно будет описать контроллер в yaml и sync скрипт, чтобы следить за референсным секретом и за новыми MyDevEnvironment.
В целом это конечно проще, чем ребят в командах обучить писать на Go и OperatorSDK, но всё равно это будет непонятный rocket science для задач, которые решаются запуском пары kubectl команд и выражением для jq.
Но за ссылку спасибо, надо будет изучить подробнее. И кстати есть план добавить поддержку CRD, чтобы хуки могли по onStartup определить свой CRD и в дальнейшем следить за событиями от создаваемых CR.
Фам Нювен несколько лет провел, обучаясь программировать и исследовать.
Программирование восходило к началу времен. Как та навозная куча за замком
отца. Когда ее промыло ручьем на десять метров вглубь, обнаружились
искореженные корпуса машин — летающих машин, как говорили крестьяне, еще от
тех великих дней колонизации Канберры. Но та навозная куча была чистой и
свежей по сравнению с тем, что лежало в локальной сети "Репризы". Были
программы, написанные пять тысяч лет назад, когда человечество еще не
покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то,
что, в отличие от бесполезных обломков прошлого Канберры, эти программы все
еще работали! И через миллион миллионов запутанных нитей наследования многие
из старейших программ все еще выполнялись во внутренностях системы Кенг Хо.
Например, методы слежения за временем у торговцев. Поправки вносились
неимоверно сложно — но на самом дне лежала крошечная программа, которая
гоняла счетчик. Секунду за секундой отсчитывала система Кенг Хо с того
момента, как нога человека ступила на Луну Старой Земли. Но если
приглядеться еще пристальнее… начальный момент был миллионов на сотню
секунд позже; момент "ноль" одной из первых компьютерных операционных систем
Человечества.
Значит, под всеми интерфейсами верхнего уровня лежат уровни поддержки,
слой на слое. Какая-то часть этих программ была создана для совершенно иных
ситуаций. То и дело несоответствие рождало фатальные инциденты. Вопреки всей
романтике космических полетов, чаще всего катастрофы вызывались древними
забытыми программами, которым удавалось взять реванш.
Спасибо, ещё один проект в копилку. Пока для разработки внутренних утилит используем https://github.com/kubernetes-sigs/kubeadm-dind-cluster (упомянут среди альтернатив kind). Удобен тем, что можно одновременно поднять разные версии куба.
There is one cool feature that exists on some IoT boards but lacks on PCs: USB client mode and software defined USB hardware. Adminbook can be used as a CD drive, a keyboard, a mouse or even as a videocard and these devices can be combined into hybrid usb device.
Логично было бы применять те самые якоря из yaml, но в случае массивов в итоге получаются массивы массивов и совет в случае RoR простой — делать flatten при разборе yaml-а. Но разработчики gitlab пока не спешат говорить «Да» этой фиче: https://gitlab.com/gitlab-org/gitlab-ce/issues/24235
Другого универсального и красивого решения этой проблемы пока нет, тоже костылим в зависимости от задачи. :(
Подкину несколько замечаний из опыта борьбы с GOPATH кутерьмой:
Если держать в GOPATH один путь, то в GOPATH/src перемешаны «свои» и «чужие» исходники и чем больше либ подключаешь, тем хуже становится.
Можно полечить двумя путями в GOPATH, что-то типа GOPATH=/home/user/work/go-imports:/home/user/work/project-name. go get будет скачивать зависимости в первый путь, а «свои» исходники лежат по второму пути. При желании можно переносить исходники из первого во второй, чтобы поправить что-то чужое и чтобы go get не затирал изменения master-ом.
GOPATH не дружит с форками. То есть как не дружит… Обычно на github-е жмёшь Fork и делаешь clone проекта своего пользователя и логично его склонировать в GOPATH/src/github.com/user/forked-repo. Бум, бах, тут-то всё и сломалось.
Приходится применять другой алгоритм: клонировать основной проект и потом править его git remote-ы.
Можно в GOPATH указывать даже 3 пути: в первый путь go get будет качать проектные зависимости, второй — глобальный, туда можно будет перемещать зависимости, чтобы несколько проектов их использовали и третий путь к директории со «своими» исходниками.
Мульти-GOPATH не такая уж и страшная штука. Во-первых можно сделать env файл, которому делать source при переключении на другой проект (аля virtualenv). Во-вторых можно посмотреть в сторону менеджеров окружений, например, smartcd — помимо изменения GOPATH при переходе в директорию с проектом они дают ещё много возможностей.
Ещё одна фишка Go и аргумент за начало всей этой движухи с переписыванием — кросскомпиляция. Компилятор Go умеет кросскомпилировать статические бинарники без дополнительных телодвижений. Одним заданием в travis ci можно собрать бинарники под несколько платформ (linux+macos+windows).
У Crystal с этим туговато, похоже это не его основное предназначение:
NOTE: Building statically-linked executables is currently only supported on Alpine Linux.
Статические бинарники только под alpine linux. Для сборки динамического бинарника нужно произвести линковку на той платформе, под которую кросс-компилируешь. Не звучит невыполнимо, но заметно сложнее, чем сборка для Go.
Похожее впечатление было от pyqt. Как бы молодцы, биндинги с классами нагенерили, а за решением проблем всё равно лезешь в C++-ную доку и потом как-то транслируешь примеры кода из C++ в python. В итоге два языка используешь, а не 1. Плюс автодополнение не всё автодополняет, потому что часть свойств в бинаре — удобной разработки! ;)
У нас было 5 дисков usb3, Raspberry Pi Model B, CubbieBoard 1, Banana Pi M1, а ещё нетбук HP и Fire TV. Не то, чтобы это всё нужно было для разработки «домашних» задач, но раз начал коллекционировать отладочные платы, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это Raspberry Pi. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек c k8s control plane на Raspberry Pi. И я знал, что довольно скоро мы в это окунёмся.
Все 3 нокии, которыми пользовался, тоже имели лимит на количество смс. Это вам похоже повезло с конкретными моделями, если больше чем 5 лет назад не встречались с ограничием.
Если интересует именно вклад в Prometheus, то были PR в exporter-ы. Вот, например, https://github.com/prometheus/statsd_exporter/pull/164.
РПН разошлёт ультиматумы додо, пападжонс, яндекс.еде, деливери клаб и прочим. Регистрироваться в реестре юридических лиц — ответственных производителей и организаторов оперативной доставки пицц никто не станет, все перейдут на выпечку и доставку «открытой кулебяки».
P.S. По опросам левады и вциома внесение пиццы с ананасом в реестр запрещённых пицц поддержит 91,42%.
Всё просто — размер цифр. ИН-18 — 40мм, ИН-14 — 18мм.
Так-то более-менее доступны Z568 с цифрами 50мм. Есть оригинальные на ebay, есть от Далибора. Дальше вопрос либо соглашаться на 600-800 евро за 4 лампы, либо искать подешевле. ИН-18 для подарка — отличный выбор.
Так по-моему это и есть один из посылов доклада: современный мониторинг это не изолированный компонент, а неотъемлимая часть самого приложения и у разработчиков в плане должно быть заложено время на реализацию источников метрик.
С опцией --docker-run всё ясно-понятно: из образа будет запущен контейнер, который заместит контейнер в кластере.
А вот про «без опции» что-то не до конца въеду. Локальная машина будет якобы контейнером в кластере, так? Что будет, если таких команд несколько запустить, начнут мешать друг другу?
Я правильно понимаю, что логику создания и логику выкачивания надо в js/py скрипте сделать? Сам metacontroller только за событиями следит и запросы к скрипту делает?
Имел в виду, что rocket science это всё, что стоит за CR — для организации этой машинерии надо обладать каким-то опытом. Пока инженер поймёт, чем CompositeController отличается от DecoratorController, а ему надо всего лишь за лейблами на подах следить и kubectl apply сделать, да он всё бросит и крончик напишет.
Но вообще согласен, если умно выделить типы часто встречающихся задач и оформить в виде sync скриптов и CRD с документацией аргументов, то конечно проще будет CR написать нужный.
MyDevEnvironment, который создаст namespace и secret наверное было бы круто и красиво… Но это дополнительная сущность в кластере, для которой придётся описать CRD, где-то её задокументировать, донести до всех участников процесса, что мы теперь почему-то не создаём обычный Namespace, а делаем только MyDevEnvironment.
Дальше нужно будет описать контроллер в yaml и sync скрипт, чтобы следить за референсным секретом и за новыми MyDevEnvironment.
В целом это конечно проще, чем ребят в командах обучить писать на Go и OperatorSDK, но всё равно это будет непонятный rocket science для задач, которые решаются запуском пары kubectl команд и выражением для jq.
Но за ссылку спасибо, надо будет изучить подробнее. И кстати есть план добавить поддержку CRD, чтобы хуки могли по onStartup определить свой CRD и в дальнейшем следить за событиями от создаваемых CR.
https://drive.google.com/drive/folders/1H8VT9UcX0UsWWIIiXh5O19C_FryArFYC
Таблица от паблика https://vk.com/chemistryeasyru
Вот да, хакатон по IoT без обещания предоставить осциллограф и логический анализатор каждой команде это что-то странное.
Фам Нювен несколько лет провел, обучаясь программировать и исследовать.
Программирование восходило к началу времен. Как та навозная куча за замком
отца. Когда ее промыло ручьем на десять метров вглубь, обнаружились
искореженные корпуса машин — летающих машин, как говорили крестьяне, еще от
тех великих дней колонизации Канберры. Но та навозная куча была чистой и
свежей по сравнению с тем, что лежало в локальной сети "Репризы". Были
программы, написанные пять тысяч лет назад, когда человечество еще не
покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то,
что, в отличие от бесполезных обломков прошлого Канберры, эти программы все
еще работали! И через миллион миллионов запутанных нитей наследования многие
из старейших программ все еще выполнялись во внутренностях системы Кенг Хо.
Например, методы слежения за временем у торговцев. Поправки вносились
неимоверно сложно — но на самом дне лежала крошечная программа, которая
гоняла счетчик. Секунду за секундой отсчитывала система Кенг Хо с того
момента, как нога человека ступила на Луну Старой Земли. Но если
приглядеться еще пристальнее… начальный момент был миллионов на сотню
секунд позже; момент "ноль" одной из первых компьютерных операционных систем
Человечества.
Значит, под всеми интерфейсами верхнего уровня лежат уровни поддержки,
слой на слое. Какая-то часть этих программ была создана для совершенно иных
ситуаций. То и дело несоответствие рождало фатальные инциденты. Вопреки всей
романтике космических полетов, чаще всего катастрофы вызывались древними
забытыми программами, которым удавалось взять реванш.
Вернор Виндж. «Глубина в небе»
Спасибо, ещё один проект в копилку. Пока для разработки внутренних утилит используем https://github.com/kubernetes-sigs/kubeadm-dind-cluster (упомянут среди альтернатив kind). Удобен тем, что можно одновременно поднять разные версии куба.
There is one cool feature that exists on some IoT boards but lacks on PCs: USB client mode and software defined USB hardware. Adminbook can be used as a CD drive, a keyboard, a mouse or even as a videocard and these devices can be combined into hybrid usb device.
Логично было бы применять те самые якоря из yaml, но в случае массивов в итоге получаются массивы массивов и совет в случае RoR простой — делать flatten при разборе yaml-а. Но разработчики gitlab пока не спешат говорить «Да» этой фиче: https://gitlab.com/gitlab-org/gitlab-ce/issues/24235
Другого универсального и красивого решения этой проблемы пока нет, тоже костылим в зависимости от задачи. :(
Подкину несколько замечаний из опыта борьбы с GOPATH кутерьмой:
Если держать в GOPATH один путь, то в GOPATH/src перемешаны «свои» и «чужие» исходники и чем больше либ подключаешь, тем хуже становится.
Можно полечить двумя путями в GOPATH, что-то типа
GOPATH=/home/user/work/go-imports:/home/user/work/project-name. go get будет скачивать зависимости в первый путь, а «свои» исходники лежат по второму пути. При желании можно переносить исходники из первого во второй, чтобы поправить что-то чужое и чтобы go get не затирал изменения master-ом.GOPATH не дружит с форками. То есть как не дружит… Обычно на github-е жмёшь Fork и делаешь clone проекта своего пользователя и логично его склонировать в GOPATH/src/github.com/user/forked-repo. Бум, бах, тут-то всё и сломалось.
Приходится применять другой алгоритм: клонировать основной проект и потом править его git remote-ы.
Можно в GOPATH указывать даже 3 пути: в первый путь go get будет качать проектные зависимости, второй — глобальный, туда можно будет перемещать зависимости, чтобы несколько проектов их использовали и третий путь к директории со «своими» исходниками.
Мульти-GOPATH не такая уж и страшная штука. Во-первых можно сделать env файл, которому делать source при переключении на другой проект (аля virtualenv). Во-вторых можно посмотреть в сторону менеджеров окружений, например, smartcd — помимо изменения GOPATH при переходе в директорию с проектом они дают ещё много возможностей.
Ещё одна фишка Go и аргумент за начало всей этой движухи с переписыванием — кросскомпиляция. Компилятор Go умеет кросскомпилировать статические бинарники без дополнительных телодвижений. Одним заданием в travis ci можно собрать бинарники под несколько платформ (linux+macos+windows).
У Crystal с этим туговато, похоже это не его основное предназначение:
Статические бинарники только под alpine linux. Для сборки динамического бинарника нужно произвести линковку на той платформе, под которую кросс-компилируешь. Не звучит невыполнимо, но заметно сложнее, чем сборка для Go.
Похожее впечатление было от pyqt. Как бы молодцы, биндинги с классами нагенерили, а за решением проблем всё равно лезешь в C++-ную доку и потом как-то транслируешь примеры кода из C++ в python. В итоге два языка используешь, а не 1. Плюс автодополнение не всё автодополняет, потому что часть свойств в бинаре — удобной разработки! ;)
В момент прочтения этих слов в голове прокрутился звук «О-оу».
Ещё вариант оформить kubedog плагином к kubectl — это какая-то прям элементарная вещь из разряда переименовать бинарь.