VS
Современные не работаю с 80386
а, возможно
Size: a a a
2020 October 02
VZ
80386 убрали в 4 ядре Точную версию не скажу
VS
я помню что недавно какое-то совсем старье, ну пару лет как примерно
VS
но мне казалось там до 486 включительно было
VZ
Нет
VS
значит ошибся
ЕО
В 12'ом приняли решение дропнуть 386
LB
Alexander
Кстати, а много кто делает IaaC, и при этом не коммитит изменения в мастер как мудак, раскатывая оттуда на прод? Т.е. делает feature/bugfix-бранчи, тестит их на CI автотестами, тегает версии и выкатыват через стейдж?
нет, это всё очень дорого. IaaC проблема не в том, чтоб апи подёргать, а что б апи подёргать из нужного состояния. что б так текстить нужно:
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
LB
основываясь на своём достаточно продолжительным опыте CI/CD могу сказать, что у баша есть один весьма веский плюс - он практически не протухает. джобы, написанные 10 лет назад просто работают
ага, и потом разработчики ifconfig трясуться над отступами вывода, иначе миллионы трудочасов на планете уйдут на починку поломавшихся скриптов :)
AS
нет, это всё очень дорого. IaaC проблема не в том, чтоб апи подёргать, а что б апи подёргать из нужного состояния. что б так текстить нужно:
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
С учётом что никто меня особо не поддержал с remco и consul-template я тоже сделал вывод что всем пох на такое. А это основа динамических конфигов.
AS
нет, это всё очень дорого. IaaC проблема не в том, чтоб апи подёргать, а что б апи подёргать из нужного состояния. что б так текстить нужно:
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
- раскатать текущий мастер в какое-то временное окружение. тут уже сложность, что всё должно быть динамически без хардкодов имён окружений
- раскатать приложения на эту инфраструктуру. тут опять сложность, что во первых раскатывалка приложений должна уметь катать куда угодно и дергать её надо уметь не по пушу, а по какому-то вызову, что многие CI не умеют или умеют очень криво (при вызове не по пушу генерируется другой пайплайн и ничего никуда не катает). и вторая сложность, что сами конфиги приложений должны уметь в динамические окружения. да и надо еще откуда-то знать все зависимости приложения чтобы их тоже раскатать иначе не взлетит
- запустить чекалку приложения, что б поймать возможные разрывы при накатке нового IaaC
- накатить обновление IaaC из бранча
- проанализировать разрывы - где ожидаемо, где нет. если ожидаемо то соответствует ли глубина и длительность даунтайма ожиданиям от бранча. всё это надо в каком-то наколенном DSL формализовать
- погасить все это дело
- переповторить при любой проблеме.
Уверен, никто там не заморачивается. максимум свежее окружение из бранча поднимут, что бы самые просты ошибки отловить.
Ну и ты тоже забыл. Самое сложное в схеме это секреты. С ними болит больше всего
SP
С учётом что никто меня особо не поддержал с remco и consul-template я тоже сделал вывод что всем пох на такое. А это основа динамических конфигов.
consul-template - костыль, чтобы не пилить полноценную поддержку консула.
DS
ага, и потом разработчики ifconfig трясуться над отступами вывода, иначе миллионы трудочасов на планете уйдут на починку поломавшихся скриптов :)
Так это же не в баше дело, в других яп ты точно также будешь парсить ifconfig как в баше =). Недавно смотрел реализацию того, как facter узнает основной сетевой интерфейс. Оно на си , парсит вывод ip route, и берет сетевой инерфейс дефолтного маршрута =)
SP
Так это же не в баше дело, в других яп ты точно также будешь парсить ifconfig как в баше =). Недавно смотрел реализацию того, как facter узнает основной сетевой интерфейс. Оно на си , парсит вывод ip route, и берет сетевой инерфейс дефолтного маршрута =)
На 8.8.8.8, стопудово (так в Ансибле сделано)
AS
consul-template - костыль, чтобы не пилить полноценную поддержку консула.
Например в сквид да? Или в постфикс...
DS
Почему до сих пор базовые линуксовые тулзы, не выводят инфу в форматах json/yaml, вот эта загадка
AS
Почему до сих пор базовые линуксовые тулзы, не выводят инфу в форматах json/yaml, вот эта загадка
Smartctl уже выводит
SP
Например в сквид да? Или в постфикс...
Ну чего ты с козырей-то сразу?
DS
Smartctl уже выводит
в 7 версии =). Знаю
DS
Но я больше про iproute2 и тому подобное