Вы всерьёз предлагаете каждый день в 5 утра таскать по SSH с Foreman (который, судя по архитектуре, находится в одной DMZ с oVirt) на бастионный хост в интернете, таскать оттуда закрытый ключ сертификата (privkey.pem) в открытом виде по сети на oVirt-engine, распаковывать его и перезапускать сервисы?
То есть вы сознательно превращаете автоматическое обновление сертификата в регулярный перенос privkey между хостами, нарушая главный принцип: «Закрытый ключ не покидает тот хост, где он был сгенерирован». А если при этом ещё и scp без защиты от перехвата (например, пароль по ssh или незащищённый ключ), то это не «улучшение инфраструктуры», а систематическая утечка ключей шифрования.
Почему это очень плохо:
Ключ жил на бастионе → его скопировали на oVirt → теперь он есть в двух местах, включая внутренний хост, который может быть скомпрометирован через веб-интерфейс.
Автоматический scp по расписанию означает, что любой, кто получит доступ к Foreman или oVirt, найдёт свежий приватный ключ в файловой системе.
Никакого упоминания шифрования канала при передаче ключа (используется ли scp с ключами без пароля? Это ещё хуже).
Бэкап ключа (архивирование папки) тоже остаётся лежать на Foreman — ещё один компромат.
Правильный путь: бастион должен быть reverse proxy (nginx с proxy_pass), который сам терминирует TLS, а oVirt вообще не знать про приватный ключ Let's Encrypt. Или использовать certbot с DNS-челленджем, чтобы не таскать ключи между серверами.
Отличная статья, Юрий! Вы очень наглядно разложили два подхода и их компромиссы. Особенно ценно, что вы поделились практическим опытом перехода от server-side к client-side.
В статье вы упомянули, что при Client-side Load Balancing клиент получает список подов через DNS (headless service) или Kubernetes API. Но что происходит в реальных боевых условиях с высокой нагрузкой и частыми перескалированиями (autoscaling/horizontal pod autoscaler)?
Мои вопросы:
Когнитивная нагрузка на DNS / API — если у вас 1000 микросервисов, каждый из которых общается с 100 другими, и каждый делает запросы к API или DNS для обновления списка эндпоинтов, как вы боретесь с «эффектом стадности» (thundering herd) при частых редеплоях или масштабированиях?
Задержка обновления — при использовании headless service + DNS, клиент может кешировать DNS-запись на 30 секунд (TTL). Как вы решаете проблему, когда под умер, а клиент всё ещё шлёт трафик на мёртвый IP? Используете ли вы retry с другой нодой, или полагаетесь на health checks на уровне LoadBalancer?
И чтобы не заниматься "непрозрачной бухгалтерией" берем железные сервера, которые стоят fix-price, трафик полностью бесплатный и строим свою виртуализацию, контейнеризацию и оркестрацию сами. Получается еще дешевле, и как показала практика, надежнее и отказоустойчивые. Облака это маркетинг по цене 3Х.
Спасибо за статью, вопрос "Какие проблемы возникли при отражении организационной структуры компании в инструментах разработки, и какие шаги команда рассматривает для улучшения структуры проектов в GitLab в будущем?"
Статья понятная и представление у меня уже 15 лет именно такое же. Хотелось бы увидеть аналитику в разрезе (стоимость хранения 1 единицы данных)/(надежность) для разных типов рейда и моделей современных дисков. Тогда можно было бы ответить на вопрос: а какой мне рейд собирать с какими дисками чтобы я мог гарантированно сохранить свои данные N часов с вероятностью Х%.
Нестандартное мышление и ассоциации это всегда классно! Спасибо за позитив)) Надеюсь что в "Гнев богов etcd" /backups это PVC на удаленном бэкап сервере в другой игровой локации).
Спасибо за статью! Проект действительно интересный, и как мне видится, с точки зрения экологии. Огромное количество устройств с экранами и аккумуляторами выкидывается ежедневно, а на них можно запустить RetroArch без каких либо проблем. Перерабатывать эти устройства достаточно дорого, а вот трансформировать их в игровые консоли с использованием вот таких вот китов стоит копейки, особенно если это промышленное решение. Выпустить пачку таких консолей и выложить на конференции для всех желающих, если кто и заберет себе то только во благо. В детдома отдать, у детишек пытливые умы, пусть развиваются.
Перепробовал много всего. У электричек два плюса - это динамика на "низах" и тишина (хотя шины так же шумят). Больше плюсов нет вообще. Дальше идут минусы: долгая зарядка, неразвитая сеть зарядных станций, дороговизна батарей (правда я не видел ни одну закончившуюся батарею, уставшие видел). Как вариант гибрид, но и они намного дороже бензинок/дизелей.
Это не проблема удаленки, это проблема человека. Этот разработчик и в офисе так же себя будет вести, если только не сидеть рядом с ним за соседним столом. Задачи нужно контролировать и ставить определенные сроки на их выполнение. В данном случае 1 день, не справился - дальше к руководству объяснительную и увольнение.
Удаленка это лучшее что есть у меня за более чем 25 лет моей карьеры: 1. Нет шума, никто не мешает думать. Никто не бегает с кофе и печеньками рядом. 2. Слушаю в фоне музыку которую я люблю никого не раздражая. 3. Рабочее место с удобным столом, стулом и микроклиматом который я хочу, а на который обеспечил мне работодатель. 4. Не трачу 3 часа не дорогу. Кстати, за это, я как минимум 1-2 часа перерабатываю добровольно, принося больше пользы компании.
Понятно что сразу нужно:
Создать себе полноценное рабочее место. Никаких кроватей, диванов и кухонных столов! Благо живу в доме и одну комнату смог выделить под кабинет.
Обязательно одеваться как на работу! Никаких пижам и прочего за рабочим столом.
Планировать свое время, активно работать с 9 до 13, обед с 13 до 14, с 14 до 19 второй этап. Как вариант, можно после отдыха еще сделать небольшой рывок.
Насчет физкультуры, тут обязательно или спортзал или дом с участком как у меня.
Есть мнение что офис это полный контроль, но по мне это не так. Много раз видел в офисах людей которые малоэффективны. Руководство им делаем замечания, но ни к чему хорошему это не приводит. Психология человека должна быть правильная.
Полностью согласен, но бывает и другой эффект когда директор стартапа совершенно не "дотягивает" до директора огромной компании. Все зависит от знаний, желаний развиваться и амбиций. В большой компании, я считаю, расти легче.
Делай своими делами компанию и людей работающих в ней успешней и богаче и тогда топ-менеджмент не будет заинтересован тебя топить. Смысл резать курицу которая несет золотые яйца?
Вы абсолютно правы, в крупных компаниях действительно много "материальных" бонусов. Однако, для меня также очень важно развитие. В небольших компаниях, с которыми мне довелось иметь дело, я никогда не встречал, например, инструментов безопасности энтерпрайз уровня, отсутствие собственного IP-пула и автономной системы, отсутствие полноценной защиты от DDoS-атак, не всегда есть резервный датацентр и т.п.
Спасибо Игорю Емельяненко @mig_25 за столь познавательную экскурсию, 14 часов в поезде, целый день на конференции, но после этого был очень счастлив что "вспомнил детство". Большинство ЭВМ в рабочем состоянии, было приятно их включить, и даже кое что потрогать. РИКОР попал в нужные руки, я счастлив!
Данный экземпляр мне принес брат со словами: "На, детям покажи, но он не работает)". А показывать-то как-то надо, пришлось чинить. Действительно, вещь уникальная. Очень рад что данный компьютер не оказался на помойке.
Вы всерьёз предлагаете каждый день в 5 утра таскать по SSH с Foreman (который, судя по архитектуре, находится в одной DMZ с oVirt) на бастионный хост в интернете, таскать оттуда закрытый ключ сертификата (
privkey.pem) в открытом виде по сети на oVirt-engine, распаковывать его и перезапускать сервисы?То есть вы сознательно превращаете автоматическое обновление сертификата в регулярный перенос
privkeyмежду хостами, нарушая главный принцип: «Закрытый ключ не покидает тот хост, где он был сгенерирован». А если при этом ещё иscpбез защиты от перехвата (например, пароль по ssh или незащищённый ключ), то это не «улучшение инфраструктуры», а систематическая утечка ключей шифрования.Почему это очень плохо:
Ключ жил на бастионе → его скопировали на oVirt → теперь он есть в двух местах, включая внутренний хост, который может быть скомпрометирован через веб-интерфейс.
Автоматический scp по расписанию означает, что любой, кто получит доступ к Foreman или oVirt, найдёт свежий приватный ключ в файловой системе.
Никакого упоминания шифрования канала при передаче ключа (используется ли
scpс ключами без пароля? Это ещё хуже).Бэкап ключа (архивирование папки) тоже остаётся лежать на Foreman — ещё один компромат.
Правильный путь: бастион должен быть reverse proxy (nginx с
proxy_pass), который сам терминирует TLS, а oVirt вообще не знать про приватный ключ Let's Encrypt. Или использоватьcertbotс DNS-челленджем, чтобы не таскать ключи между серверами.Отличная статья, Юрий! Вы очень наглядно разложили два подхода и их компромиссы. Особенно ценно, что вы поделились практическим опытом перехода от server-side к client-side.
В статье вы упомянули, что при Client-side Load Balancing клиент получает список подов через DNS (headless service) или Kubernetes API. Но что происходит в реальных боевых условиях с высокой нагрузкой и частыми перескалированиями (autoscaling/horizontal pod autoscaler)?
Мои вопросы:
Когнитивная нагрузка на DNS / API — если у вас 1000 микросервисов, каждый из которых общается с 100 другими, и каждый делает запросы к API или DNS для обновления списка эндпоинтов, как вы боретесь с «эффектом стадности» (thundering herd) при частых редеплоях или масштабированиях?
Задержка обновления — при использовании headless service + DNS, клиент может кешировать DNS-запись на 30 секунд (TTL). Как вы решаете проблему, когда под умер, а клиент всё ещё шлёт трафик на мёртвый IP? Используете ли вы retry с другой нодой, или полагаетесь на health checks на уровне LoadBalancer?
И чтобы не заниматься "непрозрачной бухгалтерией" берем железные сервера, которые стоят fix-price, трафик полностью бесплатный и строим свою виртуализацию, контейнеризацию и оркестрацию сами. Получается еще дешевле, и как показала практика, надежнее и отказоустойчивые. Облака это маркетинг по цене 3Х.
Во все времена были и трудоголики и бездельники. Нельзя это обобщать "поколениями" или "типажом".
Спасибо за статью, вопрос "Какие проблемы возникли при отражении организационной структуры компании в инструментах разработки, и какие шаги команда рассматривает для улучшения структуры проектов в GitLab в будущем?"
Статья понятная и представление у меня уже 15 лет именно такое же. Хотелось бы увидеть аналитику в разрезе (стоимость хранения 1 единицы данных)/(надежность) для разных типов рейда и моделей современных дисков. Тогда можно было бы ответить на вопрос: а какой мне рейд собирать с какими дисками чтобы я мог гарантированно сохранить свои данные N часов с вероятностью Х%.
Что с гулом и вибрациями в доме? Шасси с АСИКами закреплены к стенам жестко или через демфера-аммортизаторы?
Нестандартное мышление и ассоциации это всегда классно! Спасибо за позитив))
Надеюсь что в "Гнев богов etcd" /backups это PVC на удаленном бэкап сервере в другой игровой локации).
Вопрос "моноблочности".
Спасибо за статью! Проект действительно интересный, и как мне видится, с точки зрения экологии. Огромное количество устройств с экранами и аккумуляторами выкидывается ежедневно, а на них можно запустить RetroArch без каких либо проблем. Перерабатывать эти устройства достаточно дорого, а вот трансформировать их в игровые консоли с использованием вот таких вот китов стоит копейки, особенно если это промышленное решение. Выпустить пачку таких консолей и выложить на конференции для всех желающих, если кто и заберет себе то только во благо. В детдома отдать, у детишек пытливые умы, пусть развиваются.
Перепробовал много всего. У электричек два плюса - это динамика на "низах" и тишина (хотя шины так же шумят). Больше плюсов нет вообще. Дальше идут минусы: долгая зарядка, неразвитая сеть зарядных станций, дороговизна батарей (правда я не видел ни одну закончившуюся батарею, уставшие видел). Как вариант гибрид, но и они намного дороже бензинок/дизелей.
Это не проблема удаленки, это проблема человека. Этот разработчик и в офисе так же себя будет вести, если только не сидеть рядом с ним за соседним столом. Задачи нужно контролировать и ставить определенные сроки на их выполнение. В данном случае 1 день, не справился - дальше к руководству объяснительную и увольнение.
Удаленка это лучшее что есть у меня за более чем 25 лет моей карьеры:
1. Нет шума, никто не мешает думать. Никто не бегает с кофе и печеньками рядом.
2. Слушаю в фоне музыку которую я люблю никого не раздражая.
3. Рабочее место с удобным столом, стулом и микроклиматом который я хочу, а на который обеспечил мне работодатель.
4. Не трачу 3 часа не дорогу. Кстати, за это, я как минимум 1-2 часа перерабатываю добровольно, принося больше пользы компании.
Понятно что сразу нужно:
Создать себе полноценное рабочее место. Никаких кроватей, диванов и кухонных столов! Благо живу в доме и одну комнату смог выделить под кабинет.
Обязательно одеваться как на работу! Никаких пижам и прочего за рабочим столом.
Планировать свое время, активно работать с 9 до 13, обед с 13 до 14, с 14 до 19 второй этап. Как вариант, можно после отдыха еще сделать небольшой рывок.
Насчет физкультуры, тут обязательно или спортзал или дом с участком как у меня.
Есть мнение что офис это полный контроль, но по мне это не так. Много раз видел в офисах людей которые малоэффективны. Руководство им делаем замечания, но ни к чему хорошему это не приводит. Психология человека должна быть правильная.
Полностью согласен, но бывает и другой эффект когда директор стартапа совершенно не "дотягивает" до директора огромной компании. Все зависит от знаний, желаний развиваться и амбиций. В большой компании, я считаю, расти легче.
Делай своими делами компанию и людей работающих в ней успешней и богаче и тогда топ-менеджмент не будет заинтересован тебя топить. Смысл резать курицу которая несет золотые яйца?
Вы абсолютно правы, в крупных компаниях действительно много "материальных" бонусов. Однако, для меня также очень важно развитие. В небольших компаниях, с которыми мне довелось иметь дело, я никогда не встречал, например, инструментов безопасности энтерпрайз уровня, отсутствие собственного IP-пула и автономной системы, отсутствие полноценной защиты от DDoS-атак, не всегда есть резервный датацентр и т.п.
Спасибо Игорю Емельяненко @mig_25 за столь познавательную экскурсию, 14 часов в поезде, целый день на конференции, но после этого был очень счастлив что "вспомнил детство". Большинство ЭВМ в рабочем состоянии, было приятно их включить, и даже кое что потрогать. РИКОР попал в нужные руки, я счастлив!
<хост в этих ваших европах>
sudo docker pull elasticsearch:7.2.0
7.2.0: Pulling from library/elasticsearch
8ba884070f61: Pull complete
2211b14f8b24: Pull complete
617ccdb47f3d: Pull complete
915ee6b2c338: Pull complete
b414b7f29a7d: Pull complete
547bfdd35d62: Pull complete
8353a2ed248c: Pull complete
Digest: sha256:84b5bc2fd15b0f1f5bf78c8c6ee34b6ae5a46ab81be1c2cfa678eea0c6457a46
Status: Downloaded newer image for elasticsearch:7.2.0
docker.io/library/elasticsearch:7.2.0
<наш хост через https://huecker.io/ >
7.2.0: Pulling from library/elasticsearch
8ba884070f61: Pull complete
2211b14f8b24: Pull complete
617ccdb47f3d: Pull complete
915ee6b2c338: Pull complete
b414b7f29a7d: Pull complete
547bfdd35d62: Pull complete
8353a2ed248c: Pull complete
Digest: sha256:e560b0675f0b9fec164db801627cf36a0d9ff73934076b43114a701725b07c6d
Status: Downloaded newer image for elasticsearch:7.2.0
docker.io/library/elasticsearch:7.2.0
обращайте внимание на Digest
Тоже это заметил, т.к. дома лежит программируемый калькулятор с таким же точно блоком питания. Но разъем на конце другой.
Данный экземпляр мне принес брат со словами: "На, детям покажи, но он не работает)". А показывать-то как-то надо, пришлось чинить. Действительно, вещь уникальная. Очень рад что данный компьютер не оказался на помойке.