s3fs в docker работает, проверил.
Только словил странную ошибку о том, что точка монтирования /mnt/s3 занята, когда два контейнера одновременно запустили бэкап при запуске… видимо это из-за того что /dev/fuse прокинут в контейнеры для корректной работы FUSE.
Про «по всем канонам CI/CD» — а автотестов то в репозитории нет, они где-то в другом месте находятся? Если их нет, то CI/CD становится опасной штукой, которая может распространять беду.
Интересная утилита, но про настройку хранилища S3 ничего нет в документации.
В документации отмечено, что пользователю надо самостоятельно настраивать s3fs, напишите хотя бы вкратце что и как. Особенно интересно как подключиться не к AWS серверам S3, а к сторонним.
Разберёмся конечно, но как-то «волшебство» утилиты начинает биться об реальность :)
И я так понимаю, что нельзя настроить внешний SMTP аккаунт для отправки E-mail оповещений?
Расскажите нам пожалуйста о реальных случаях когда клиенту пришлось этим воспользоваться и что из этого получилось.
Если бы вы были «Корп софт» и из-за вас на 3 дня упал Битрикс24, вы бы им оплатили маркетинговую компанию для поддержания репутации?
Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно.
Да вы сами все данные отдадите когда попросят, сделаете из «облака» обычный HDD и отдадите.
Что-то маркетологи ваши перестарались в статье… перегнули.
Я не о том, вы бы ещё клиентам предложили Windows Server в виртуализации Linux запустить, если они сервера на Windows не хотят. Вы им тогда и лицензии на vmware продадите, и саппорт виртуализации, и саппорт на Windows сервер в виртуализации… уже я даже сбился со счёт на сколько надо profit множать в таком случае.
Это всю шутки конечно, но с долей правды.
И всё же «масло масляное» — от Microsoft вы так заказчиков не сбережете, «они» всёравно будут руководить вами :)
Microsoft всегда имел хороший маркетинг для программистов и это вот «ВСЁ» с open source и linux на фоне прошлых «неудачных» и выгодных для Microsoft технологий, должно насторожить тревожного разработчика.
А у вас СУБД «правильная»?
И только не говорите заказчику, что вы используете технологии Microsoft.
В «не только в госсекторе» мне кажется импортозамещение началось уже сразу с появлением этого «не только в госсекторе» :)
Из собственной личной практики:
1. Использую несколько лет docker версии 1.12 и 17 в нескольких проектах.
Везде Ubuntu 14 или 16 с 4 версией ядра.
Один проект так вообще динамически создаёт контейнеры и постоянно их останавливает, запускает… порядка 1000 контейнеров динамически создаваемых.
Везде aufs.
Всё работает… если и бывают какие-то проблемы именно со сотороны докера, то они очень редки.
2. Удаление образов… не сталкивался с такой проблемой, места на одном сервера впритык а контейнеры бывало часто перестраивались… удаляется всё нормально.
3. AUFS нестабилен? Не заметил.
4. Про кривые ключи и мировое падение это перегиб какой-то. Ну уберите репозиторий из иточников, ставьте напрямую из файлов docker… Автоматиеский деплой на то и нужен, чтобы легко можно было всё поправить.
5. Про свой реестр образов не скажу ничего, не пользовался.
6. Релизный цикл у докера нормальный, всё живо, ошибки бывают но исправляются.
7. Хранение данных в докере — даже мыслей никогда не возникало хранить какие-то данные в контейнерах докера, все данные на хосте, а в докер только volume пробрасывается. Кто им посоветовал данные в докере вообще хранить…
Такое чувство, что авторы статьи просто не особо задумывались когда начали применять docker… и наступили на грабли, которые можно найти везде.
1. А наличие интерфейсов для всех свойств статически проверяется разве? Тоже только при запуске. Или вы о чём?
Про не нравится бессмыслено что-либо писать, вкус и цвет…
2. Как ошибиться? Кто-то намеренно скроет свойство от рефлексии?
3. В том, что не надо копипастить интерфейсы и добавлять стратегии в массив. Поди вспомни через Н недель где там этот интерфейс найти.
И не надо прописывать строкой название свойства… это утомительно :)
4. С производительностью не будет проблем только если вы сгенерируете динамически код IsEquivalent, который рефлексию не будет трогать (динамически сгенерируете всё то, что вы предложили с интерфейсами).
5. А ещё кодогенерацию можно использовать, которая все эти интерфейсы по IOrderHistoryItem сгенерирует. А методы Is{property}Equivalent будут выкидывать исключения, пока не будту вручную реализованы. Тут вообще «откиньте спинки ваших кресел».
А ещё в сообщении исключения об отсутствии Is{property}Equivalent разработчику можно было бы давать шаблон для релазиции в виде текста. Скопировал его и реализовал, даже руками название метода писать не надо.
Ещё как варинт можно реализовать тест, который через метаданные проверит, что у класса для каждого свойства есть метод Is{property}Equivalent.
И так же реализовать метод IsEquivalent, который все эти методы будет дёргать.
Понимаю, что рефлексию как-то не принято использовать, но потом будет проще поддерживать этот зоопарк.
Ну и вроде бы о высокой производительности тут речи не было.
И ещё IsEquivalent можно будет научить ругаться, если всё же кто-то не запуская тестов выложил сборку на продакшн.
Каждый раз глядя на своё программное решение с регулярными выражениями для разбора строк, чувствую, что единственное полезное выражение это «что-то (\d+)» и ничего другого лучше не писать.
Очень сложно поддерживать регулярные выражения в программе, всегда в первоначальный «простой» вариант вносятся изменения и усовершенствования. В итоге получается мини-монстр.
Как ящик пандоры — такие надежды всегда, а получается не совсем то.
На мой взгляд сама история появления регулярных выражений определяет их пределы использования. Они же родились в научной среде как некое теоретическое изыскание вылившееся в такой вот язык (утрирую конечно) и на практике оно впервые появилось в текстовом редакторе, чтобы можно было делать более сложные текстовые замены. И это стихия регулярных выражений.
Ты сделал замену регулярным выражением и сразу оценил результат, если он тебя устроил то регулярное выражение может кануть в забытие, т.к. оно выполнило свою роль. Это действительно бывает полезно.
Ну я конечно про Python говорю в большей степени, неужени в PHP так всё плохо?
Одних только готовых компонент к Django целый вагон, комплексное решение можно сделать много быстрее.
Просто есть готовые, качественные, open-source решения, которые ты можешь взять и использовать.
Вы не написали о своём опыте работы на .NET, это сильно меняет контекст статьи.
И почему вы решили сменить стек.
Разница в языках мне кажется совершенно не важна — важно что вы перешли на стек где большое open-source комьюнити. В сравнении с .NET это огромный плюс, т.к. для .NET попробуй нади хороший сторонний компонент (пусть платный), который решит твою задачу.
Потоков дейстивтельно нехватает после C#, но всё решаемо если с головой подходить.
Я правда говорю с точки зрения перехода .NET C# (9 лет) -> Python (3 года).
А в причине не разобрались?
Очень похоже, что без нормализации (а вы вроде бы её не делаете после перемешивания) функции активации не отрабатывают так как прежде.
Выложите полный код пожалуйста.
Непонятно, обучение происходит на исходных нормализованных данных, а потом вы сети скармливаете ненормализованные данные?
Всё замечательно, но с осторожностью отнеситесь к продуктам Microsoft.
Много лет работал на стеке .NET и знаю что они работают в стиле Паниковского: «я вас всех продам, куплю, и снова продам, но уже по более дорогой цене».
За последние годы они конечно одумались и сильно ломанулись в сторону Linux и Open Source, но не очень верится что это они делают для людей.
Есть другие проверенные решения, например pydevd и его поддерживает не одно IDE.
Итого в вашем решении есть плюсы, которых нет в обозначенных готовых решениях:
1. Реализован доступ «Видеть» с поддержкой в админке (чего я не нашел в своё время в уже готовых решениях).
2. Унифицировано решение для фильтрации объектов в ModelAdmin.changelist_view на основе доступов (через ModelAdmin.get_query_set).
Но настораживает ваше решение сделать свой слой управления доступами поверх стандартного механизма Джанго, механизм управления доступами Джанго подключается к вашему, а не наоборот. Это может привести к сложностями при использовании других готовых решений для Джанго… если стороннее приложение будет проверять доступ через has_perm Джанго, оно ведь пролетит мимо доступа заданного правилами в вашем решении?
Так уже есть Django-rules https://github.com/dfunckt/django-rules, который как раз предоставляет возможность управления доступами используя правила заданные в коде.
rules + guardian дают гибкую связку для доступов, просто не надо в guardian задавать явный доступ на все имеющиеся объекты.
Из статьи кажется, что ваш проект может управлять доступом на уровне полей модели, хотя это не так (поправьте, может ошибаюсь). В вашем примере, на странице проекта и в репозитории, вы используете стандартный рецепт с модифицированными get_list_display и get_fieldsets в UserAdmin именно для вашего случая:
def get_fieldsets(self, request, obj=None):
fieldsets = list(super(AccessUserAdmin, self).get_fieldsets(request, obj)) or []
if request.user.is_superuser:
return fieldsets
if not obj:
return fieldsets
if obj.pk != request.user.pk:
return self._fieldsets_exclude(fieldsets,['password', 'email'])
return self._fieldsets_exclude(fieldsets,['is_superuser'])
2. nginx ведь не вернет ошибку, он внутри обработает запрос на доступный uwsgi. Клиент увидит только результат того uwsgi, который работает. Ошибки не увидит.
Попытка коннекта на закрытый порт это мне кажется всего несколько миллисекунд, а то и меньше.
А в случае не идемпотентных запросов, что может произойти?
Два инстанса сразу не должны быть доступны для запросов от клиента.
Но получается, что всёравно надо будет портами играться… надо ждать пока новый инстанс запустится, гасить порт старого, открывать порт нового.
В общем понятно.
3. Хранение исходных кодов в data volume (или в host директории) или в контейнере это разные стратегии применяемые в разных условиях (проект, команда, организация, куда идёт развертывание и т.п.).
virtualenv vs docker? Да ну его этот virtualenv…
uwsgi прекрасно работает, зачем гонять образы, если можно заменить только код и пользоваться его возможностями.
Тут варианты:
1. nginx+uwsgi в одном контейнере — да, тут кластер или маршрутизацией управлять.
2. nginx отдельно (отдельный контейнер или непосредственно на сервере) от uwgi — в этом случае можно ведь настроить nginx failover с proxy_next_upstream и нулевым timeout?
Спрашиваю, потому что на практике не делал, но думаю что работает.
3. Исходные коды храняться в data volume (а не в инстансе как в пп.1 и 2), который цепляется в инстанс uwsgi — тут можно использовать возможность uwsgi последовательно перезагружать воркеры, у них довольно подробная инструкция есть на эту тему.
Всё это конечно с допусками:
— Нет изменений в БД, которые не позволяют использовать предыдущую кодовую базу с новой версией БД.
— Время простоя на перезагрузку конфигурации nginx считаем незначительной и отдельный балансировщик делать не будем :)
В шагах .gitlab-ci.yml можно выбирать, при коммите в какой бранч выполнять шаг.
И соответственно разные шаги для разных бранчей с разными скриптами.
Вот тут подробно https://habrahabr.ru/company/softmart/blog/310502/
Вот тут официальная документация https://docs.gitlab.com/ce/ci/yaml/README.html#only-and-except
«через переменные, шаблоны и dockerize» — немного непонятно.
Если мне надо деплоить вместе с кодом проекта конфиг nginx сайта проекта, то как оно должно быть устроено правильнее?
И где должна храниться конфигурация?