Целью оптимизации является сокращение разницы между получаемыми образами от сборки к сборке
Дело как раз в дополнительных модулях: они являются источниками постоянных изменений для слоя, даже если вы не вносите в код модуля никаких правок
На правах рекламы: попробуйте сборку werf-ом (https://github.com/flant/werf), в ней можно указать зависимость сборки от изменений в файлах в git. Поменялись исходники модуля — будет собираться, не поменялись, возьмётся из кэша. Была статья про сборку именно Java приложений https://habr.com/ru/company/flant/blog/348436/. Это ещё старая версия программы (dapp), но идеи почерпнуть можно.
если что, схему вы получаете сразу после ввода исходных данных
Как-то не очевидно работает кнопка Показать/Скрыть, но по полосе прокрутки видно, что ниже что-то появляется. А после Отправить надо прокрутить вверх за результатом.
Все 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). Удобен тем, что можно одновременно поднять разные версии куба.
На правах рекламы: попробуйте сборку werf-ом (https://github.com/flant/werf), в ней можно указать зависимость сборки от изменений в файлах в git. Поменялись исходники модуля — будет собираться, не поменялись, возьмётся из кэша. Была статья про сборку именно Java приложений https://habr.com/ru/company/flant/blog/348436/. Это ещё старая версия программы (dapp), но идеи почерпнуть можно.
Такого репозитория я не видел. Пока есть getting started документация от flux: https://github.com/weaveworks/flux/blob/master/site/get-started.md. Но там нет конфигов для развёртывания самого куба.
А было бы круто прям с нуля сделать git clone, start.sh и уже готовый куб поднялся где-то в AWS, остаётся только коммиты пушить для изменений.
Github давно зовут, но к сожалению пока не идёт что-то. :(
Это вирусная реклама статей про восстановление файлов.
На Архстоянии было такое: https://youtu.be/GEtBua9hl50?t=179
Как-то не очевидно работает кнопка Показать/Скрыть, но по полосе прокрутки видно, что ниже что-то появляется. А после Отправить надо прокрутить вверх за результатом.
поправил
Тем не менее, в issue и pr exporter-ов приходит Brian Brazil и рассказывает как нужно делать exporter-ы, чтобы было prometheus-way© ;)
Все 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). Удобен тем, что можно одновременно поднять разные версии куба.