MS
а если проверка в уровне приложения, а реализация в уровне хранения, то ты размазал ответственность и будешь огребать, скорее всего
Size: a a a
2017 August 04
MS
Антон, привет
AD
Ну вроде похож :)
MS
За ханами нам рассказывать будешь?
AD
Не, зачем?
MS
ну энивей добро пожаловать
СС
https://ru.stackoverflow.com/q/701915/242768
кто-то уже сталивался с таким? как решал?
кто-то уже сталивался с таким? как решал?
AD
ну энивей добро пожаловать
👋
KO
Ну вроде похож :)
2017 August 07
AK
@SVIATOSLAV1SUDYLOVSKYI
>ошибка в геме sprokets при прекомпиляции ресурсов на Rails
у меня был немного др. прикол со sprokets -- гнал, но втихую - оказалось, ему одна PNG картинка не нравилась. При этом конвернтул эту картинку через Photoshop в др. PNG картинку - все заработало. Как у Вас ошибки не выдавал.
На счет Вашего случая - хотя и понятно, что парсер не должен такую ошибку выдавать, но можно попытаться локализовать проблему --- попробуйте кусками закомментировать части своего css - может получится найти тот sass/scss код, который валит парсер. Кстати, попробуйте Ваш sass/scss скомпилить каким-нибудь online-сервисом, может ошибка всплывет?
Также как вариант -- залезть в сам sass_processor, и попробовать поставить точку останова binding.pry\byebug и по-отлавливать -- потом bugfix и PR заплите в sprokets ;-). На счет временного модифицирования гемов - у bundle есть какой-то ключ, который потом окатывает назад гемы (pristine вроде), ну или временно gem-папку
>ошибка в геме sprokets при прекомпиляции ресурсов на Rails
у меня был немного др. прикол со sprokets -- гнал, но втихую - оказалось, ему одна PNG картинка не нравилась. При этом конвернтул эту картинку через Photoshop в др. PNG картинку - все заработало. Как у Вас ошибки не выдавал.
На счет Вашего случая - хотя и понятно, что парсер не должен такую ошибку выдавать, но можно попытаться локализовать проблему --- попробуйте кусками закомментировать части своего css - может получится найти тот sass/scss код, который валит парсер. Кстати, попробуйте Ваш sass/scss скомпилить каким-нибудь online-сервисом, может ошибка всплывет?
Также как вариант -- залезть в сам sass_processor, и попробовать поставить точку останова binding.pry\byebug и по-отлавливать -- потом bugfix и PR заплите в sprokets ;-). На счет временного модифицирования гемов - у bundle есть какой-то ключ, который потом окатывает назад гемы (pristine вроде), ну или временно gem-папку
/home/leetsworker/.rvm/gems/ruby-2.4.1/gems/sprockets-3.7.1 в git локальный занести, чтобы не забыть потом, все откатить назад.DO
Хочу переставать деплоить вручную. Держать отдельный докер контейнер для каждого приложения это нормально? Чтобы для дева и продакшене были разные набор конфигураций.
2017 August 08
KO
Хочу переставать деплоить вручную. Держать отдельный докер контейнер для каждого приложения это нормально? Чтобы для дева и продакшене были разные набор конфигураций.
Вручную это как?
KO
Капистрану рассматривал?
AK
@denis_oster
здравствуйте,
>и продакшене
https://thehftguy.com/2017/02/23/docker-in-production-an-update/
я в проде его не пробовал, но локально (в деве, макось, пару мес. назад) поглюкивал периодически, имхо в прод рано его еще...
>Хочу переставать деплоить вручную
а что значит в ручную? Разве не пользуете capistrano, CI/CD ? (CircleCi, Travis, Bitbucket, GitLab, ... - последний так вообще халява)
Например, на CircleCI билдится все довольно шустро, они кэшируют использованные гемы, кэшируют сам репозиторий и пр, можно билд поотлаживать через SSH.
Если проект на github-е (в том числе приватный) - можо CircleCI заюзать бесплатно без всяких докеров.
Поскольку у меня проект на GitLab - circleci бесплатно не получилось заюзать, - настроил GitLab CI (первый раз без докера)
-- хотя канал у DigitalOcean и хороший (они хостят GitLab-воркеров), билд без кэша проходил намного дольше, в сравнении с тем же CircleCI.
+ поотлаживать через SSH не получается - нет такой фитчи у GitLab CI.
чтобы билды на GitLab CI ускорить - сделал docker-контейнер для прогона тестов и деплоя.
Положил в этот docker-контейнер все, что нужно для проекта - билды стали шустрее - т.е. теперь GitLabCI берет docker-контейнер, который запушен в gitlab и по факту локальный для него,
запускает его, а там уже установлены linux-пакеты, гемы и какая-то версия git-репозитория проекта -- потом git pull && bundle install ---> потом тесты --> потом автодеплой, если ветка == production или staging.
Тут да, докер пригодился, стало намного шустрее.
>для дева
а у Вас проект прям большой большой? переключаетесь между кучей проектов \ окружений за день? зачем Вам на dev-е лишний гемор с дополнительным слоем абстракции в виде docker-а?
Конечно, сильно зависит от ситуации, но имхо, пока проект и команда не выросли (https://youtu.be/nqGxzUGtkNw) - staging-сервера, который максимально окружением приближен к продакшену,
выше крыши для ручных тестов перед деплоем в прод. На стейдж можно положить жирную копию прод-базы, копию аттачментов - на дев-машину это не всегда влазит.
А отлаживать проект напрямую на своей машине, имхо намного приятнее, чем это делать внутри какого-то контейнера, если Вы только уже не пользуете какой-то Vagrant - тогда да, уже привычно... :)
здравствуйте,
>и продакшене
https://thehftguy.com/2017/02/23/docker-in-production-an-update/
я в проде его не пробовал, но локально (в деве, макось, пару мес. назад) поглюкивал периодически, имхо в прод рано его еще...
>Хочу переставать деплоить вручную
а что значит в ручную? Разве не пользуете capistrano, CI/CD ? (CircleCi, Travis, Bitbucket, GitLab, ... - последний так вообще халява)
Например, на CircleCI билдится все довольно шустро, они кэшируют использованные гемы, кэшируют сам репозиторий и пр, можно билд поотлаживать через SSH.
Если проект на github-е (в том числе приватный) - можо CircleCI заюзать бесплатно без всяких докеров.
Поскольку у меня проект на GitLab - circleci бесплатно не получилось заюзать, - настроил GitLab CI (первый раз без докера)
-- хотя канал у DigitalOcean и хороший (они хостят GitLab-воркеров), билд без кэша проходил намного дольше, в сравнении с тем же CircleCI.
+ поотлаживать через SSH не получается - нет такой фитчи у GitLab CI.
чтобы билды на GitLab CI ускорить - сделал docker-контейнер для прогона тестов и деплоя.
Положил в этот docker-контейнер все, что нужно для проекта - билды стали шустрее - т.е. теперь GitLabCI берет docker-контейнер, который запушен в gitlab и по факту локальный для него,
запускает его, а там уже установлены linux-пакеты, гемы и какая-то версия git-репозитория проекта -- потом git pull && bundle install ---> потом тесты --> потом автодеплой, если ветка == production или staging.
Тут да, докер пригодился, стало намного шустрее.
>для дева
а у Вас проект прям большой большой? переключаетесь между кучей проектов \ окружений за день? зачем Вам на dev-е лишний гемор с дополнительным слоем абстракции в виде docker-а?
Конечно, сильно зависит от ситуации, но имхо, пока проект и команда не выросли (https://youtu.be/nqGxzUGtkNw) - staging-сервера, который максимально окружением приближен к продакшену,
выше крыши для ручных тестов перед деплоем в прод. На стейдж можно положить жирную копию прод-базы, копию аттачментов - на дев-машину это не всегда влазит.
А отлаживать проект напрямую на своей машине, имхо намного приятнее, чем это делать внутри какого-то контейнера, если Вы только уже не пользуете какой-то Vagrant - тогда да, уже привычно... :)
AK
@kalys прикольно, пока писал, Вы меня немного опередили с тем же вопросом :)
MS
Хочу переставать деплоить вручную. Держать отдельный докер контейнер для каждого приложения это нормально? Чтобы для дева и продакшене были разные набор конфигураций.
Путаешься в понятиях. Для дева и продакшена по-любому будет разный контейнер, но образ один. Просто ты этот образ стартуешь с разными переменными окружения и конфигами. Так достигается запуск приложения в правильной среде.
MS
Докер образ — клеше, докер контейнер — то, изделие, которое получается по форме клеше
KO
Для дева и прода образы разные будут