Добавьте, пожалуйста, конкретики. Почему об «универсальности тарантула не может быть и речи»? Я не понимаю, и хотелось бы почитать развёрнуто, что не так в статье? С сабжем дела не имел вообще.
Первое и самое главное, я так понимаю, вы уже сделали — нашли работу и получаете боевой опыт. Здесь главное — признавать свои ошибки и находить лакуны в собственных знаниях. Конечно, идеально было бы обзавестись старшим коллегой, который делился бы опытом на примере вашего общего проекта. Такой шеринг знаний всегда более эффективен, нежели объяснения на картошке и на пальцах. Если честно, я до сих пор не люблю работать один. Нет, всегда нужен напарник, хотя бы для ревью.
Полагаю, при работе с DRF следует обратить внимание на подход RESTful API. Поищите на хабре, почитайте, если ещё не. Ну и, конечно, берите официальную документацию DRF, штудируйте её по пунктам (там, кажется, в меню прямо так и было: Serializers, Views и так далее). Лично я, помнится, в своё время несколько раз перечитывал её и постоянно возвращался к ней во время работы. При чтении у вас обязательно отложится часть знаний, а затем при появлении незнакомой задачи вы вдруг вспомните, что вроде бы что-то такое уже видели, найдёте и реализуете уже менее костыльно.
Про Docker Compose можете почитать у меня во второй статье. Ознакомьтесь, почитайте комменты и погружайтесь глубже во всё, что не понятно. Гуглите, читайте туториалы.
По поводу типовых задач... Знаете, может, я давно уже не сталкивался просто, но что-то у меня возникает ощущение, что нет никаких типовых задач. Некоторые только кажутся таковыми из-за своей похожести друг на друга, но на деле всегда выясняется, что там нюансов вагон и маленькая тележка. Сразу скажу: не существует такой Библии питониста или программиста, после прочтения которой навык решения задач вырастает на +N. Только практика, только опыт, подкреплённый параллельным изучением теории.
Как оценить оптимальность решения? Для этого и нужны товарищи-напарники. Самому в моменте, увы, никак. Пройдёт год-два, и тогда вы обязательно поймёте, что код не оптимален, и надо было делать по-другому. А потом через год-два это повторится с новым кодом. И так по кругу, если вы будете продолжать расти.
Прошу прощения за абстрактный ответ без конкретики, но у меня действительно нет ничего иного, кроме доброго напутствия. :)
Думаю удобнее не прописывать значения переменных окружения прям в docker-compose. Если их оставить там без значений, то они будут проброщены с хоста или с файла .env
Это как вам будет угодно. Думаю, здесь никаких железобетонных правил нет. По большому счёту, смысл всего остального не меняется — используете вы мой вариант или ваш. Лично я не люблю .env, использую его редко. Не люблю из-за появляющихся через полгода-год test.env, test2.env, stage.env и т. д. Мне удобнее сразу в docker-compose энвы наблюдать и переопределять их в override.
----
Что касается второй части комментария, то мой ответ сильно зависит от того, что именно вы предлагаете взамен. Предположу, что CMD с некой дефолтной командой без использования docker-entrypoint.sh и аналогичным docker-compose.yml, где вместо моих command будет что-то вроде: command: "python <api/consumer>.py".
создан немного для другого — инициализация там всякая или предварительная проверка и ожидание доступности необходимых сервисов
Да. Видел, что для этого его в основном и используют, тут с вами не поспоришь. И я, признаться, не знаю, есть ли где-то скрижали, запрещающие иное предназначение.
Свой вариант я предложил отчасти из эксперимента, отчасти из эстетических соображений (увидел в одной компании, проникся, стал использовать) и отчасти из соображений некой абстракции, о которой в уроке, к сожалению, не упомянул. Пожертвовал ради упрощения, как и многим другим.
Эта конфигурация послужит точкой входа вообще для любых команд. То есть вы можете через docker-compose run запускать оба инстанса и пробрасывать любую другую допустимую команду:
docker-compose run --rm service api
docker-compose run --rm service consumer
docker-compose run --rm service tests
docker-compose run --rm service bash ...
# et cetera
В этом случае docker-entrypoint.sh становится сугубо декларативным элементом.
В моём подходе имеется дублирование смыслов, согласен. То есть я объявляю типы запуска одновременно и в docker-entrypoint.sh, и в docker-compose.yml, что является избыточным.
Именно поэтому я и написал в статье то, что написал. Нынче на PyCon был доклад по поводу alpine. И там на примере pydantic было показано, что не стоит.
Второй урок уже готов. В связи с творящимся вокруг... кхм... белым пушным зверьком, пока руки не дошли опубликовать на хабре. Но в ближайшие дни я это сделаю.
Добавьте, пожалуйста, конкретики. Почему об «универсальности тарантула не может быть и речи»? Я не понимаю, и хотелось бы почитать развёрнуто, что не так в статье? С сабжем дела не имел вообще.
Спасибо за комментарий.
Первое и самое главное, я так понимаю, вы уже сделали — нашли работу и получаете боевой опыт. Здесь главное — признавать свои ошибки и находить лакуны в собственных знаниях. Конечно, идеально было бы обзавестись старшим коллегой, который делился бы опытом на примере вашего общего проекта. Такой шеринг знаний всегда более эффективен, нежели объяснения на картошке и на пальцах. Если честно, я до сих пор не люблю работать один. Нет, всегда нужен напарник, хотя бы для ревью.
Полагаю, при работе с DRF следует обратить внимание на подход RESTful API. Поищите на хабре, почитайте, если ещё не. Ну и, конечно, берите официальную документацию DRF, штудируйте её по пунктам (там, кажется, в меню прямо так и было: Serializers, Views и так далее). Лично я, помнится, в своё время несколько раз перечитывал её и постоянно возвращался к ней во время работы. При чтении у вас обязательно отложится часть знаний, а затем при появлении незнакомой задачи вы вдруг вспомните, что вроде бы что-то такое уже видели, найдёте и реализуете уже менее костыльно.
Про Docker Compose можете почитать у меня во второй статье. Ознакомьтесь, почитайте комменты и погружайтесь глубже во всё, что не понятно. Гуглите, читайте туториалы.
По поводу типовых задач... Знаете, может, я давно уже не сталкивался просто, но что-то у меня возникает ощущение, что нет никаких типовых задач. Некоторые только кажутся таковыми из-за своей похожести друг на друга, но на деле всегда выясняется, что там нюансов вагон и маленькая тележка. Сразу скажу: не существует такой Библии питониста или программиста, после прочтения которой навык решения задач вырастает на +N. Только практика, только опыт, подкреплённый параллельным изучением теории.
Как оценить оптимальность решения? Для этого и нужны товарищи-напарники. Самому в моменте, увы, никак. Пройдёт год-два, и тогда вы обязательно поймёте, что код не оптимален, и надо было делать по-другому. А потом через год-два это повторится с новым кодом. И так по кругу, если вы будете продолжать расти.
Прошу прощения за абстрактный ответ без конкретики, но у меня действительно нет ничего иного, кроме доброго напутствия. :)
Спасибо! Имеется уже вторая статья. Добро пожаловать)
Это как вам будет угодно. Думаю, здесь никаких железобетонных правил нет. По большому счёту, смысл всего остального не меняется — используете вы мой вариант или ваш. Лично я не люблю
.env, использую его редко. Не люблю из-за появляющихся через полгода-годtest.env,test2.env,stage.envи т. д. Мне удобнее сразу в docker-compose энвы наблюдать и переопределять их вoverride.----
Что касается второй части комментария, то мой ответ сильно зависит от того, что именно вы предлагаете взамен. Предположу, что
CMDс некой дефолтной командой без использованияdocker-entrypoint.shи аналогичнымdocker-compose.yml, где вместо моихcommandбудет что-то вроде:command: "python <api/consumer>.py".Да. Видел, что для этого его в основном и используют, тут с вами не поспоришь. И я, признаться, не знаю, есть ли где-то скрижали, запрещающие иное предназначение.
Свой вариант я предложил отчасти из эксперимента, отчасти из эстетических соображений (увидел в одной компании, проникся, стал использовать) и отчасти из соображений некой абстракции, о которой в уроке, к сожалению, не упомянул. Пожертвовал ради упрощения, как и многим другим.
В общем, можно определить только сервис:
Эта конфигурация послужит точкой входа вообще для любых команд. То есть вы можете через
docker-compose runзапускать оба инстанса и пробрасывать любую другую допустимую команду:В этом случае
docker-entrypoint.shстановится сугубо декларативным элементом.В моём подходе имеется дублирование смыслов, согласен. То есть я объявляю типы запуска одновременно и в
docker-entrypoint.sh, и вdocker-compose.yml, что является избыточным.Именно поэтому я и написал в статье то, что написал. Нынче на PyCon был доклад по поводу alpine. И там на примере pydantic было показано, что не стоит.
Спасибо за замечание и участие.
Спасибо за разумные дополнения. Плюсанул.
Спасибо на добром слове!
Второй урок уже готов. В связи с творящимся вокруг... кхм... белым пушным зверьком, пока руки не дошли опубликовать на хабре. Но в ближайшие дни я это сделаю.
Это конфиги моделей. Данная конструкция предусмотрена контрактом библиотеки Pydantic. Внутри можно указать массу дополнительных настроек.