в целом весь рассказ и был про то, что тащить в куб\облако\куда-то еще без понимания зачем вообще это надо не стоит, в том числе без уверенности, что это принесет позитивный результат как для самого приложения, так и для команды. В статье я выделил несколько пунктов, по которым стоит пройтись для принятия такого решения, прежде чем вообще что-то делать.
Расскажем о двух самых раскрученных на сегодняшний день: Pulumi и Crossplane. Обе системы позволяют превращать инфраструктуру в код. Но надо иметь в виду, что под капотом у них все равно используется Terraform, — настолько это удобный инструмент.
Подскажите, разве Pulumi как-то использует TF внутри?
Про SOA есть внутри, я про это тоже упоминал, а именно в формате батла было специально выбрано 2 разных подхода, просто чтобы не уходить в дебри архитектурных подходов.
Немного личного опыта — очень отталкивают вакансии, которые не соответствуют описанию на самом интервью, начиная с неверной информации о зп (что вроде начало уходить в небытие хотя бы в крупных городах), до неверного указания обязанностей на новом рабочем месте — встречалось даже полное несоответствие описанию (ищут по названия условный DevOps, а на деле требуется DBA)
К тому же в почти уходящем году уменьшается практически до нуля важность офиса — почти все удаленно, а какие то компании меняют офисы на более маленькие
С другой стороны, а в данном году как раз участвовал в поиске работы как соискатель, обратил внимание что график работы стал выходить на более приоритетное место — вместо полностью свободного начала, часы присутствия сместились в более жесткие рамки, что становится более критично, чем красивый офис или территориальное местоположение
Мы работаем по 7 часов эффективного времени в день. Время начала рабочего дня каждый выбирает для себя сам, но без крайностей: в диапазоне с 8.00 до 10.00
я вообще про это
os.remove(os.path.join(deploy_path, "%s.deployed" % deployment))
но на самом деле это один из подходов, жаль, что такое решение проблемы вызвало столько негатива у вас
например при 10 имеющихся wf будет занято место в 10 раз больше с модулем copy
Так же надо тогда следить за нагрузкой на сервере, если модуль делает все шаг за шагом, то после copy придется описывать в скрипте логику старта — часто именно процесс деплоя дает высокую нагрузку на CPU, которая в дальнейшем не будет такой и создавать сервер с большим количеством CPU исключительно для процесса деплоя невыгодно.
в случае если делать копирование а потом лезть в разные консоли, остается много ручного труда, либо всю эту обработку необходимо описывать каким либо скриптом, что избыточно в данном моменте на мой взгляд.
на данный момент у меня на сервере 36 WF инстансов работает, таких серверов несколько, ansible является единой точкой деплоя без каких либо сторонних костылей, что облегчает управление и поддержку приложения
на мой взгляд это более удобно, использовать данный модуль с его подходом использования единой директории, ну и это позволяет использовать общий воркфло для всего деплоя
принципиальное отличие в том, что можно ear положить в одну директорию для хоть 10 wf и дальше ansible задеплоит во все необходимые сервера
с учетом, что например бывает сложно что-то отправить на прод, это облегчает процесс деплоя
Так же использование ansible помогает делать проверки разные, задача часто строится не только из копирования, но так же из добавления хост зависимых переменных например, проверок и тд, что может привести к сложному bash\python скрипту, в случае с ansible может быть немного проще кмк
Хорошие вопросы :) тут уже на заучивании теории не выехать на мой взгляд, про локальную разработку интересно, какие подходы кто использует — можно оценить кругозор
да, хороший вопрос
Есть компании, которые предоставляют шифт как сервис, такие компании знаю :)
То есть выдается неймспейс, туда можно деплоить, можно создавать сущности, но нет доступа до кластер админа, нет доступа к ингресу, нет доступа к созданию неймспейсов. Нет возможности конфигурировать сам OpenShift, что-то еще ограничено.
Вполне жизнеспособный вариант, у всех процессы построенны различно. Естественно, соискатель может прочитать документацию, поэкспериментировать локально с k8s или k3s — но тут упор на узкий взгляд на опыт больше.
Согласен, не все так просто :)
на первое я бы сказал стоит как то внимательнее слушать, что говорит, возможно распросить по какому то кейсу, таких встречал соискателей, обычно они валятся на распросе подробном как что сделать, но да, тут все неоднозначно
на второе и соглашусь и нет, иногда, на мой взгляд бывает потребность в технаре, который вот может решить сложные проблемы, готов много дизайнить и экспериментировать, но например, с взаимодействием у него сложно, для такого человека всегда можно найти и место и ему задачи подобрать. Так же есть мнение, что такой человек может со временем например вырости в хорошего ТехЛида, архитектора и это будет всем плюс, либо научиться взаимодействовать.
Соглашусь, пока читал, задавался вопросом — «Почему latest?». Это накладывает ограничения и менее явно показывает, что на данный момент в продакшн среде стоит.
в целом весь рассказ и был про то, что тащить в куб\облако\куда-то еще без понимания зачем вообще это надо не стоит, в том числе без уверенности, что это принесет позитивный результат как для самого приложения, так и для команды. В статье я выделил несколько пунктов, по которым стоит пройтись для принятия такого решения, прежде чем вообще что-то делать.
Расскажем о двух самых раскрученных на сегодняшний день: Pulumi и Crossplane. Обе системы позволяют превращать инфраструктуру в код. Но надо иметь в виду, что под капотом у них все равно используется Terraform, — настолько это удобный инструмент.
Подскажите, разве Pulumi как-то использует TF внутри?
К тому же в почти уходящем году уменьшается практически до нуля важность офиса — почти все удаленно, а какие то компании меняют офисы на более маленькие
С другой стороны, а в данном году как раз участвовал в поиске работы как соискатель, обратил внимание что график работы стал выходить на более приоритетное место — вместо полностью свободного начала, часы присутствия сместились в более жесткие рамки, что становится более критично, чем красивый офис или территориальное местоположение
Без шуток делал похожее полтора — два года назад, да и ходят слухи, в подвалах сбера он ещё жив.
Кровавый энтерпрайз не быстр на изменения.
Достаточно жесткие рамки :)
Жуткое слово, почему то только из энтерпрайз среды такое слышится
os.remove(os.path.join(deploy_path, "%s.deployed" % deployment))
но на самом деле это один из подходов, жаль, что такое решение проблемы вызвало столько негатива у вас
Так же надо тогда следить за нагрузкой на сервере, если модуль делает все шаг за шагом, то после copy придется описывать в скрипте логику старта — часто именно процесс деплоя дает высокую нагрузку на CPU, которая в дальнейшем не будет такой и создавать сервер с большим количеством CPU исключительно для процесса деплоя невыгодно.
в случае если делать копирование а потом лезть в разные консоли, остается много ручного труда, либо всю эту обработку необходимо описывать каким либо скриптом, что избыточно в данном моменте на мой взгляд.
на данный момент у меня на сервере 36 WF инстансов работает, таких серверов несколько, ansible является единой точкой деплоя без каких либо сторонних костылей, что облегчает управление и поддержку приложения
с учетом, что например бывает сложно что-то отправить на прод, это облегчает процесс деплоя
Так же использование ansible помогает делать проверки разные, задача часто строится не только из копирования, но так же из добавления хост зависимых переменных например, проверок и тд, что может привести к сложному bash\python скрипту, в случае с ansible может быть немного проще кмк
Есть компании, которые предоставляют шифт как сервис, такие компании знаю :)
То есть выдается неймспейс, туда можно деплоить, можно создавать сущности, но нет доступа до кластер админа, нет доступа к ингресу, нет доступа к созданию неймспейсов. Нет возможности конфигурировать сам OpenShift, что-то еще ограничено.
Вполне жизнеспособный вариант, у всех процессы построенны различно. Естественно, соискатель может прочитать документацию, поэкспериментировать локально с k8s или k3s — но тут упор на узкий взгляд на опыт больше.
на первое я бы сказал стоит как то внимательнее слушать, что говорит, возможно распросить по какому то кейсу, таких встречал соискателей, обычно они валятся на распросе подробном как что сделать, но да, тут все неоднозначно
на второе и соглашусь и нет, иногда, на мой взгляд бывает потребность в технаре, который вот может решить сложные проблемы, готов много дизайнить и экспериментировать, но например, с взаимодействием у него сложно, для такого человека всегда можно найти и место и ему задачи подобрать. Так же есть мнение, что такой человек может со временем например вырости в хорошего ТехЛида, архитектора и это будет всем плюс, либо научиться взаимодействовать.