Проблему с путями до сих пор не решили, тикет все еще в открытом статусе.
Кроме того, появилась еще одна новая проблема.
Мы развернули в Serverless Containers сервис, который должен динамически поднимать ВМ в Yandex Cloud. Сервис использует SA, который генерирует IAM-токен. Примерно раз в месяц стабильно получаем в логах сервиса ошибку: он не может сгенерировать IAM-токен из-за того, что API Яндекса недоступен с данной инфраструктуры.
Error: connect ETIMEDOUT 84.201.181.26:443
Навесили ретраи, но даже это не помогает. Все приходит в норму, когда делаешь передеплой контейнера. Видимо, после этого он попадает на другую ноду, и все начинает работать прекрасно :D
Похожая проблема была с Cloud Function, которая успешно работала в продакшене месяц, а потом внезапно начала писать в логи ошибку 499, как будто клиент разорвал с ней соединение. Возможно, клиент действительно рвет соединение, но, судя по всему, не с нашей стороны, а их Gateway, который располагается поверх Cloud Function. И снова, простой редеплой функции решил проблему.
Про саппорт даже писать не буду — их “очень полезные” рекомендации известны.
К сожалению, бессерверные сервисы, такие как Serverless Containers и Cloud Function, я не рекомендую использовать в вашей продакшен-среде. Это какое-то лол, кек, чебурек.
Либо обкладывайте эти сервисы со всех сторон механизмами полной отказоустойчивости.
Настоятельно не рекомендую развёртывать в Serverless Containers критически важные компоненты системы.
На текущий момент сервис имеет множество багов, а поддержка работает неудовлетворительно: мой тикет остаётся без обновлений уже четыре месяца.
Первая проблема, с которой мы столкнулись — это развертывание приложения на Next.js. Прокси данного сервиса некорректно обрабатывает пути, содержащие специальные символы. В моём случае в URL используются квадратные скобки:
Даже если передавать путь в base64, как это автоматически делает клиент, до сервера доходит некорректный URL, в результате чего возникает ошибка “файл не найден”, хотя он действительно присутствует на сервере. Эту проблему до сих пор не решили.
Вторая проблема появилась на этой неделе. Наше приложение, которое работает с базой данных, стало периодически терять соединение с БД. На стороне приложения и базы данных проблем не было, так как простой редеплой на обычную виртуальную машину решил проблему. Однако саппорт настаивает, что на их стороне всё функционирует в штатном режиме.
Под блокируется вы имеется в виду экран ожидания?
У нас это происходит за считанные секунды, поэтому дискомфорта от этого не испытываем.
Поделитесь, пожалуйста, кейсом, когда это действительно очень долго, очень интересно :)
Ну а по поводу pipeline — я считаю у каждого типа задач есть свое применение, и не стоит, например, создавать pipeline, если вам нужно выполнить пару команд из bash.
У нас используется более сложный интерфейс (таблицы, в которых чек боксы и прочее), поэтому без HTML никак.
Если говорить про данный пример, то я полностью с вами согласен, но хотелось раскрыть побольше возможностей, поэтому решил и тут такой тип параметров показать.
Это точно!
А вообще, есть еще плагин, который позволяет не просто html отрисовывать, как показано в статье, а прям писать UI с помощью React.
Но, к сожалению, я пока им не пользовался, поэтому ничего не могу сказать.
Ссылка на плагин.
Да, это удобно для пользователя джобы.
Мы тоже делаем на этапе деплоя и при использовании каких-то системных джобов.
Как я уже писал в статье, это просто учебный пример, который было легко сделать на примере CI :)
Я тоже так первое время думал, пока не столкнулся с развертыванием платформы, в которой более 100 микросервисов и огромное количество различных настроек.
Для CI процесса я полностью согласен, что каждая команда должна отвечать за сборку своего дистрибутива и проще делать, как вы говорите.
Вы про виндовые контейнеры, которые только под виндой можно запустить?
У нас все на rhel запускается, так как это OpenShift, поэтому контейнер кастомный.
Сижу, строчу комментарии в надежде, что автор поста их прочтет и сможет повлиять на улучшение качества сервиса, а он уже ушел в МТС cloud строить :D
UPD: по комментарию выше
Проблему с путями до сих пор не решили, тикет все еще в открытом статусе.
Кроме того, появилась еще одна новая проблема.
Мы развернули в Serverless Containers сервис, который должен динамически поднимать ВМ в Yandex Cloud. Сервис использует SA, который генерирует IAM-токен. Примерно раз в месяц стабильно получаем в логах сервиса ошибку: он не может сгенерировать IAM-токен из-за того, что API Яндекса недоступен с данной инфраструктуры.
Error: connect ETIMEDOUT 84.201.181.26:443
Навесили ретраи, но даже это не помогает. Все приходит в норму, когда делаешь передеплой контейнера. Видимо, после этого он попадает на другую ноду, и все начинает работать прекрасно :D
Похожая проблема была с Cloud Function, которая успешно работала в продакшене месяц, а потом внезапно начала писать в логи ошибку 499, как будто клиент разорвал с ней соединение. Возможно, клиент действительно рвет соединение, но, судя по всему, не с нашей стороны, а их Gateway, который располагается поверх Cloud Function. И снова, простой редеплой функции решил проблему.
Про саппорт даже писать не буду — их “очень полезные” рекомендации известны.
К сожалению, бессерверные сервисы, такие как Serverless Containers и Cloud Function, я не рекомендую использовать в вашей продакшен-среде. Это какое-то лол, кек, чебурек.
Либо обкладывайте эти сервисы со всех сторон механизмами полной отказоустойчивости.
Настоятельно не рекомендую развёртывать в Serverless Containers критически важные компоненты системы.
На текущий момент сервис имеет множество багов, а поддержка работает неудовлетворительно: мой тикет остаётся без обновлений уже четыре месяца.
Первая проблема, с которой мы столкнулись — это развертывание приложения на Next.js. Прокси данного сервиса некорректно обрабатывает пути, содержащие специальные символы. В моём случае в URL используются квадратные скобки:
https://bbaf8tb78s5rlihchhof.containers.yandexcloud.net/_next/static/chunks/app/(dashboard)/(examination)/[status]/[id]/layout-f329483a4f450c33.js
Даже если передавать путь в base64, как это автоматически делает клиент, до сервера доходит некорректный URL, в результате чего возникает ошибка “файл не найден”, хотя он действительно присутствует на сервере. Эту проблему до сих пор не решили.
Вторая проблема появилась на этой неделе. Наше приложение, которое работает с базой данных, стало периодически терять соединение с БД. На стороне приложения и базы данных проблем не было, так как простой редеплой на обычную виртуальную машину решил проблему. Однако саппорт настаивает, что на их стороне всё функционирует в штатном режиме.
У нас это происходит за считанные секунды, поэтому дискомфорта от этого не испытываем.
Поделитесь, пожалуйста, кейсом, когда это действительно очень долго, очень интересно :)
Ну а по поводу pipeline — я считаю у каждого типа задач есть свое применение, и не стоит, например, создавать pipeline, если вам нужно выполнить пару команд из bash.
Если говорить про данный пример, то я полностью с вами согласен, но хотелось раскрыть побольше возможностей, поэтому решил и тут такой тип параметров показать.
А вообще, есть еще плагин, который позволяет не просто html отрисовывать, как показано в статье, а прям писать UI с помощью React.
Но, к сожалению, я пока им не пользовался, поэтому ничего не могу сказать.
Ссылка на плагин.
Мы тоже делаем на этапе деплоя и при использовании каких-то системных джобов.
Как я уже писал в статье, это просто учебный пример, который было легко сделать на примере CI :)
Для CI процесса я полностью согласен, что каждая команда должна отвечать за сборку своего дистрибутива и проще делать, как вы говорите.
У нас все на rhel запускается, так как это OpenShift, поэтому контейнер кастомный.
P.S. Это у вас в пункте 2 написано.