Доброго времени суток, создал модель с TextField'ом, теперь хочу вовыдить только часть текста из того, что хранится в базе, вопрос: как порезать TextField чтобы выводить часть текста?(например с 0 до 30 символа)

{{ value|truncatechars:9 }}

{{ value|truncatechars:9 }}

оу спасибо)

https://djangoforbeginners.com/

Уже два часа не могу запустить Django на локальном Apache2 ( я знаю о встроенном dev-сервере ), пишет ошибку 500. error.log - https://gist.github.com/SunRaccoon/be3f5b4d91484a8229c02424ce369a62.

Все так делаешь? https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/modwsgi/

Именно

Не может быть

Недавно по нему делал - все ок было

Значит что то не так все же

Попробую значит ещё раз.

Та ну блин, стандарный даже не ставится

Может сразу как белый человек?

https://habrahabr.ru/post/226419/

Этот гайд точно рабочий, на прошлой неделе проверял

в современных условиях наиболее продвинутый способ доставки сервиса в продакшен - с помощью контейнеров

если вы ещё не умеете пользоваться Docker’ом или другими системами такого рода (rkt, CRI-O) - научитесь

думаю, через некоторое время неумение работать с контейнерами будет означать профнепригодность

Kubernetes захватывает мир

думаю, через некоторое время неумение работать с контейнерами будет означать профнепригодность

там где эти контейнеры реально нужны, есть дев опсы или накрайняк лид который может их наладить, остальным не нужны

контейнеры нужны чтобы можно было откатиться назад, например, если ты обновил uWSGI при обновлении Ubuntu, а оно сломалось и не хочет запускать больше проекты, это реальная история

а в случае с контейнерами же откатываться очень просто, нет страха сломать что-либо обновлениями

контейнеры нужны чтобы можно было откатиться назад, например, если ты обновил uWSGI при обновлении Ubuntu, а оно сломалось и не хочет запускать больше проекты, это реальная история

что-то очень специфичное, контейнер при правильной настройке и так не обновится если оно там на сборке с ерором падает

ну, почему, собраться может нормально вот кейс из реальной жизни, в эпоху до контейнеров - я обновлял Ubuntu, после обновления упал uWSGI из-за каких-то либ не тех версий, система обновилась ок, uWSGI стартовался ок, но была ошибка, он фактически не работал

то есть он не то что не билдился, билдился, он даже стартовался

но при этом фактически “кино не показывал”

ну я и говорю что-то прямо такое специфическое

контейнеры нужны чтобы можно было откатиться назад, например, если ты обновил uWSGI при обновлении Ubuntu, а оно сломалось и не хочет запускать больше проекты, это реальная история

Есть мысль, что этим полезность контейнеризации не органичивается)

Есть мысль, что этим полезность контейнеризации не органичивается)

конечно, просто это достаточная причина, чтобы вообще всем переходить на контейнеры, даже если 1 сервер, а не 100, то есть вообще всем, а не только крупным компаниям

контейнеры убирают страх перед обновлениями на 99%

Дженкинс убирает страх перед обновлениями на 100%.

Или какого рода обновления имеются в виду?

обновления системы

конечно, просто это достаточная причина, чтобы вообще всем переходить на контейнеры, даже если 1 сервер, а не 100, то есть вообще всем, а не только крупным компаниям

причина честно говоря никакая, с трудом представляю что там такое могло произойти если в рекваременте все пакеты с фиксированными версиями

Ubuntu в данном случае

А, ок

Контейнеры не панацея. И там можно всяких дел наворотить. Да и без них можно жить.

собственно, система чистая, там только Docker, ну то есть обновления уже кроме докера сломать ничего не могут, а ломают они докер или нет - легко проверить, есть ли совместимость или нет, это просто 1 набор пакетов

а сам проект, разумеется, надо тестировать на CI

и тут тоже могут помочь контейнеры, чтобы 100% воспроизвести среду выполнения

причина честно говоря никакая, с трудом представляю что там такое могло произойти если в рекваременте все пакеты с фиксированными версиями

кроме пакетов питона есть системные пакеты, пакеты питона так или иначе с ними связаны

например, тот же Pillow зависит много от чего в системе

кроме пакетов питона есть системные пакеты, пакеты питона так или иначе с ними связаны

ну как бы контейнер не таскает за собой какую-то зафриженную версию оси

тупо запускается поверх и юзает все из шареда хоста

контейнер запускается из образа, а образ это и есть зафриженная версия оси)

в том-то и дело, что нет ?

от хоста только ядро и всё

абсолютно все версии либ в контейнере свои, они из образа

и никаким образом не связаны с либами, которые на сервере

в этом и фишка, у проекта всегда те же самые либы, и на CI, и у разработчика на компе и на продакшене

думаю, многие скептически относятся к контейнерам потому что не до конца понимают, принцип их работы, тут всё просто) 1. у вас есть некий конфиг/скрипт, который билдит образ контейнера, в докере это Dockerfile в нём вы указываете некий начальный образ, например, образ чистой ОС, например, дебиана или альпин линукса (примерно то же самое, что у вас на сервере после установки системы) дальше идут некий шаги, RUN apt-get install … && python3 -m pip install … дальше идёт указание того, что именно нужно запустить после создания контейнера из этого образа, CMD [“uwsgi”, …] 2. вы делаете docker build (или не вы, а CI) и у вас идёт сборка образа, то есть скачивается образ с чистой операционной системой, туда ставятся все ваши зависимости, системные и питона, туда копируется содержимое вашего проекта 3. вы запускаете новый контейнер из образа, указываете всякие настройки, доступы к базе данных, порты, которые нужно открыть, монтируете некие директории с хоста 4. вы тестируете код, запустив свои тесты внутри контейнера 5. если зелёный статус вы вешаете некий тег на этот образ и пушите его в репозиторий образов, по аналогии с git’ом 6. где-то на сервере этот образ скачивается и из него запускается контейнер, можно запустить сразу несколько контейнеров из 1 образа или несколько контейнеров из образов разных версий и легко переключаться между ними с помощью балансировщика (то есть сначала запускаем контейнер с новой версией, только потом уже переключаем туда трафик, чтобы люди шли в контейнер с новой версией)

и обратите внимание, в случае с контейнерами у вас просто нет ситуации, когда обновления что-то ломают неожиданным для вас образом, ваши зависимости они не обновляются, они каждый раз ставятся с нуля на образ с чистой системой

и обратите внимание, в случае с контейнерами у вас просто нет ситуации, когда обновления что-то ломают неожиданным для вас образом, ваши зависимости они не обновляются, они каждый раз ставятся с нуля на образ с чистой системой

выше речь шла о обновлениях на хосте

то есть обновили убунту, обновилось ядро

я сам пользуюсь докером, плюс еще с обвязками потипу хироку

то есть вместо [чистая ОС] -> пакет версии 1.0 -> пакет версии 1.1 будет [чистая ОС] -> пакет версии 1.0, а потом [чистая ОС] -> пакет версии 1.1

ядро если обновили

докер же не запускает свои ядра

докер выпускает совместимые с Ubuntu LTS версии

как только такая версия есть, вы можете смело обновляться

и тупо какая-то утилита со старого образа не хочет не может работать с новым

нет спасибо

проблем с ядром нет

ERROR: S client not available

ну, я в реальной практике с ними не сталкивался

lts на убунте начинается с c 3-4 ревизии

у убунты есть 2 типа версий - обычная и LTS, можно использовать только LTS и вообще не обновлять её на другие LTS, там лет 5 вроде поддержка, обновляться только в пределах 1 выпуска ядра двух типов - GA и HWE, HWE - это ядра от более новых версий, бэкпорты своего рода, можно юзать GA

ну и вот Ubuntu LTS с GA-ядрами и докер из их репозитория, обновляться можно не сразу, а через, ну, несколько месяцев после релиза новой версии докера

тогда будет довольно стабильно

вот, а все остальные пакеты они будут в образах, собираться и тестироваться на CI

тогда будет довольно стабильно

ну вот, а выше говорили про то что докер прямо повышает отказоустойчивость

так да, повышает, за счёт переноса пакетов с сервера внутрь образа

на сервер ставится только докер и всё

ну, мб системы мониторинга ещё и прочее такое

ядро и фс все равно хостовая

да

но часто проблема не с ними, а с тем, кто кто-то накосячил с апгрейд скриптом какого-нибудь пакета

ну обновляем убунту с lts на lts процентов 70% что докер крякнет после такого маневра

перед обновлением Ubuntu с LTS на LTS необходимо обновить Docker и убедиться, что новая версия Docker’а поддерживает новую LTS

если да, то ничего не крякнется

просто тормозим контейнеры и обновляем

и всё ок

как же его обновишь если в текущей репе он вот такой версии, новые будут в новом lts

обновиться до последней доступной версии для данной LTS

в репозитории Docker’а

(не в репозитории Ubuntu)

да, а какая разница, если там ядро и фс ломает что-то в новой

таких ситуаций не было, там ничего не ломается

сначала получается надо обновится до новой lts и возможно оно проапдейтит докер, возможно он даже запуститься, но тут 50 на 50

смотри, всё просто

у Ubuntu поддерживаются 2 LTS версии

текущая и старая LTS

и новый докер будет работать и под ту, и под другую версию

он будет в обеих репозиториях