Я вообще мимопроходил, просто решил откомментить про дороговизну домена. Сайты визитки/личные блоги - для любого. Ценники, которые я привёл взяты из личного проекта, никакого ИП там нет, естественно. Для контекста, я на своём домене держу почту *@mydomain.ru, ваулт, впн и пачку сервисов, во внутренней сети.
.ru домен стоит +-400р стабильно на большинстве регистраторов, пример. Управляю доменом на Ya.Облаке, там весь днс сервис мне встаёт примерно ещё в 50 (это за 19 записей, среди которых почта на домене и пачка поддоменов)
Это ложь. ТДД не подразумевает какой-то конкретный тип тестов. Особенно при написании оконечных слоёв, которые взаимодействуют с внешней средой, без интеграционных тестов никуда.
Понял, просто локальные зависимости обычно решаются на стороне тулинга. Например, poetry умеет собирать зависимости локальные (тоесть делается всё тот же poetry install), не только из pypi/git. В node существует lerna для монореп.
В общем кажется, что четвёртый стейдж, о котором вы говорите, скорее не повсеместный, а частный случай. Как и сказал выше, естественно бывают частности и стейджей может быть гораздо больше, я описал скорее базовый случай.
Честно сказать я вообще не большой фанат монореп как подхода для разработки именно приложений. Базовые образы - да. Пакеты - не всегда, но тоже да. Приложения - скорее нет. Это холиварная тема, предлагаю в неё не пускаться, может в последующих статьях :D
Если речь про стейдж, то всё ещё не понимаю зачем четвёртый, если честно.
Что б предметно говорить приложу абстрактный пример для Python-приложения того о чём говорил (для ноды всё плюс минус то же самое, только npm вместо poetry):
FROM ghcr.io/ovsds-example-organizaton/python-dev:3.10-jammy-0.3.1 as builder
# копируем всё, что нам нужно для сборки окружения
COPY pyproject.toml /pyproject.toml
COPY poetry.lock /poetry.lock
COPY poetry.toml /poetry.toml
# сборка
RUN poetry install
FROM ghcr.io/ovsds-example-organizaton/python:3.10-jammy-0.3.1 as base
# много слоёв разнообразной локально донастройки
RUN apt-get update && \
apt-get install -y \
libpq5 \
&& rm -rf /var/lib/apt/lists/* \
&& apt-get clean
RUN mkdir --parents /opt/app
RUN useradd --create-home --home-dir /opt/app appuser
RUN chown -R appuser:appuser /opt/app
...
# отдельный стейдж, что б и были кэши разбитые по слоям, но и в рантайме был один слой
FROM base as runtime
# копируем окружение
COPY --from=builder /.venv /opt/app/.venv
# копируем приложение
COPY bin /opt/app/bin
COPY lib /opt/app/lib
WORKDIR /opt/app
USER appuser
ENTRYPOINT [".venv/bin/python", "-m", "bin.main"]
PS: это не значит, что не может быть четвёртого слоя, ещё как может, просто пытаюсь понять о чём именно вы.
Немного путаница случилась, видимо. Зависимостями, которые ставит base, я называю системные пакеты например, а не окружение самого приложения, как например node_modules, это уже вотчина билдера.
И да, моя ошибка, перечисление выше - это не слои, а именно стейджи, слои могут быть какие угодно в каждом слое, кроме разве что последнего, где мы минимизируем их количество.
Всё верно, сборку образов приложений мы именно так и организовываем. Только я бы ещё добавил, что разбиваем минимум на три слоя:
Builder: в нём мы делаем компиляцию или подготавливаем окружение, если это Python, например
Base: стейдж в котором мы ставим на базовый образ все частные зависимости, тут как раз можно не стесняться разбивать на слои
Runtime: делаем FROM из стейджа сборки зависимостей, упаковывая в единый слой, а потом делаем COPY --from из нашего builder'а уже собранного приложения.
В приложении это оправдано, поскольку в наших пайплайнах сборка образа может триггериться на каждый коммит в каждый ПР репозитория приложения. Это зачастую очень большой объем срабатываний, требующий к тому же минимальное время (поскольку на нём завязан цикл обратной связи), а потому требуется максимальное кэширование.
В базовых образах частотность гораздо ниже, что позволяет нам не так сильно беспокоиться о времени сборки. Но что более важно, кэши порой бывают только вредят, поскольку блокируют обновление на свежие версии незакреплённых зависимостей, а значит если запустить пересборку, произойдёт кэшхит и мы останемся со старыми версиями. В образе приложения такой проблемы нет, поскольку мы привязываемся к конкретной версии базового образа, а значит и версии пакетов, которые с ним приезжают по факту закреплены на момент его релиза.
Нет, всё верно, всё упаковывается в один единый большой слой. И да, никакого раздельношо кэша в таком случае не будет, образ по сути будет пересобираться целиком. В первую очередь это оптимизирует толщину образа, если слои работают с общими файлами.
Плюс, пайплайн базовых образов не так часто триггерятся на практике, потому кэширование не проблема, я бы даже сказал наоборот, его отсутствие позволяет обновлять версии пакетов до актуальных в апстриме каждый релиз, а не только когда меняется код. Обратите внимание, что в моём CI не используется кэширование вовсе, так что полная пересборка гарантирована в любом случае на каждом релизе.
Раскройте мысль, почему единый слой - не очень хорошо, кроме кэширования? Обычно это наоборот классическая рекомендация - уменьшение количества слоёв в итоговом образе. Особенно при установке зависимостей из apt. Либо так, либо мультистейдж, который слепит все слои в один при использовании инструкции FROM на следующем шаге (для образов приложений, когда мы будем их рассматривать, я рекомендую именно такой подход).
Лонгполлинг не обязательно использовать, можно обойтись запрос-ответами.
Девайс код не поможет, если сервер поднимать на локолхосте
Весь этот усложненный путь стоит использовать ТОЛЬКО, если OAuth-провайдер не реализовал уже за вас расширение device-code, тогда нужно использовать его (ссылки в других ветках комментариев).
Дополню: многие адекватные OAuth по причине безопасности запрещают в качестве урла указывать локалхост. "Правильная" схема будет использовать внешний сервер, который будет ждать редирект:
CLI инициирует авторизацию и встаёт в лонгполлинг на внешний сервер приложения с таймаутом с некоторым генеренным на стороне клиента идентификационным токеном
В браузере открывается ОАуф сессия, которая редиректит в конце на внешний сервер приложения, передавая наш идентификационный токен
Внешний сервер отвечает на лонгполл, если находится с нужным id токеном, передавая данные авторизации oauth
В идеале, чтоб ещё исключить man-in-the-middle, пользователь на стороне нашего внешнего сервера на форме должен ввести какой-то код, который ему сгенерит CLI в процессе, тот же идентификационный токен и только после этого наш сервер отвечает на лонгполл. Это стоит делать и в вашей схеме, если вы не хотите, что б злоумышленник попытался прикинуться вами и украсть данные пользователя от имени вашего приложения, точно так же подняв локальный сервер.
Да, стоит не забывать, что если возникает несколько лонгполлов на одном ID токене, то лучше сбросить все.
Найм отражает коллектив. Если вы нанимаете людей, которые обладают определёнными качествами, то и коллектив закономерно будет ими обладать.
Если вы нанимаете разработчиков, которые в первую очередь умеют хорошо писать тексты - ваше право. Если вы ищете разработчиков, которые приукрашивают свои умения - ваше право. Если вы ищете художников/копирайтеров вместо разработчиков - всё ещё ваше право.
Если вам ещё и потом действительно комфортно работать с этой командой - вообще замечательно. Если ещё и работа спорится - так вообще отлично.
Но! Это всё вопрос приоритетов. Мне лично , да и многим в найме, важнее другие качества, например профессиональные. Потому и проверять и смотреть я буду именно на них.
Я не говорю, что CV не важно, я говорю, что ставить его в красный угол и молиться на него - немного сбитый прицел, как по мне. Но если эта схема для вас работает - да и пусть, уверен, что хватает кандидатов, которые хотели бы чтоб их оценивали по качеству составления резюме, а не по умениям, именно с ними вы и найдёте друг друга.
Простите, но если так всё просто по графе Программист, то "пройдите говнокурс, прочитайте старый учебник" и дальше по списку. Будете получать 300к/секунду, не будете зависеть от ЗП в авторстве и будете писать в своё удовольствие сколько захотите. Раз вы ещё не там, то предположу, что возможно мир немного отличается от вашего о нём представления.
Не скажу за спорт тематику, но когда открываешь статью на техническую тему, то достаточно быстро заметно когда она написана GPT, поскольку от неё за километр разит дважды переваренным бредом. Особенно если есть хотя бы минимальная экспертиза в том, что читаешь. На это откровенно больно смотреть. И речь не про рекламные ресурсы помойки, которые фишат трафик с поисковиков, речь об уважаемых изданиях и крупных UGC ресурсах типа хабра.
Я не говорю, что GPT бесполезен, но это инструмент коррекции, прегенерации. Про убирание человека из этого уравнения сейчас крайне рано говорить. Соавторство - да, авторство модели - пока нет.
Есть "авторы" промышляющие написанием десятка статей в месяц, наполненных ошибками, несуразицами и по сути являющиеся откровенными вредными советами.
PS: речь не про умение скомпоновать текст, речь именно про фактуру.
Я вообще мимопроходил, просто решил откомментить про дороговизну домена. Сайты визитки/личные блоги - для любого. Ценники, которые я привёл взяты из личного проекта, никакого ИП там нет, естественно. Для контекста, я на своём домене держу почту *@mydomain.ru, ваулт, впн и пачку сервисов, во внутренней сети.
.ruдомен стоит +-400р стабильно на большинстве регистраторов, пример. Управляю доменом на Ya.Облаке, там весь днс сервис мне встаёт примерно ещё в 50 (это за 19 записей, среди которых почта на домене и пачка поддоменов)Нехватка высокогрейдовых специалистов, в статье же речь про джунов, максимум мидлов. Хотя сильных мидлов тоже нехватка ощущается в ряде отраслей.
Это ложь. ТДД не подразумевает какой-то конкретный тип тестов. Особенно при написании оконечных слоёв, которые взаимодействуют с внешней средой, без интеграционных тестов никуда.
PS: простите, промахнулся мимо треда.
Понял, просто локальные зависимости обычно решаются на стороне тулинга. Например, poetry умеет собирать зависимости локальные (тоесть делается всё тот же poetry install), не только из pypi/git. В node существует lerna для монореп.
В общем кажется, что четвёртый стейдж, о котором вы говорите, скорее не повсеместный, а частный случай. Как и сказал выше, естественно бывают частности и стейджей может быть гораздо больше, я описал скорее базовый случай.
Честно сказать я вообще не большой фанат монореп как подхода для разработки именно приложений. Базовые образы - да. Пакеты - не всегда, но тоже да. Приложения - скорее нет. Это холиварная тема, предлагаю в неё не пускаться, может в последующих статьях :D
Вопрос почему этот модуль не в зависимостях другого, или зачем нам два приложения в одном контейнере?
Если же это какая-то глобальная зависимость, которую нам нужно собрать, то делаем обычно такое в
base, не забыв почистить исходники.Если речь про стейдж, то всё ещё не понимаю зачем четвёртый, если честно.
Что б предметно говорить приложу абстрактный пример для Python-приложения того о чём говорил (для ноды всё плюс минус то же самое, только npm вместо poetry):
PS: это не значит, что не может быть четвёртого слоя, ещё как может, просто пытаюсь понять о чём именно вы.
Немного путаница случилась, видимо. Зависимостями, которые ставит base, я называю системные пакеты например, а не окружение самого приложения, как например node_modules, это уже вотчина билдера.
И да, моя ошибка, перечисление выше - это не слои, а именно стейджи, слои могут быть какие угодно в каждом слое, кроме разве что последнего, где мы минимизируем их количество.
Всё верно, сборку образов приложений мы именно так и организовываем. Только я бы ещё добавил, что разбиваем минимум на три слоя:
Builder: в нём мы делаем компиляцию или подготавливаем окружение, если это Python, например
Base: стейдж в котором мы ставим на базовый образ все частные зависимости, тут как раз можно не стесняться разбивать на слои
Runtime: делаем FROM из стейджа сборки зависимостей, упаковывая в единый слой, а потом делаем COPY --from из нашего builder'а уже собранного приложения.
В приложении это оправдано, поскольку в наших пайплайнах сборка образа может триггериться на каждый коммит в каждый ПР репозитория приложения. Это зачастую очень большой объем срабатываний, требующий к тому же минимальное время (поскольку на нём завязан цикл обратной связи), а потому требуется максимальное кэширование.
В базовых образах частотность гораздо ниже, что позволяет нам не так сильно беспокоиться о времени сборки. Но что более важно, кэши порой бывают только вредят, поскольку блокируют обновление на свежие версии незакреплённых зависимостей, а значит если запустить пересборку, произойдёт кэшхит и мы останемся со старыми версиями. В образе приложения такой проблемы нет, поскольку мы привязываемся к конкретной версии базового образа, а значит и версии пакетов, которые с ним приезжают по факту закреплены на момент его релиза.
Нет, всё верно, всё упаковывается в один единый большой слой. И да, никакого раздельношо кэша в таком случае не будет, образ по сути будет пересобираться целиком. В первую очередь это оптимизирует толщину образа, если слои работают с общими файлами.
Плюс, пайплайн базовых образов не так часто триггерятся на практике, потому кэширование не проблема, я бы даже сказал наоборот, его отсутствие позволяет обновлять версии пакетов до актуальных в апстриме каждый релиз, а не только когда меняется код. Обратите внимание, что в моём CI не используется кэширование вовсе, так что полная пересборка гарантирована в любом случае на каждом релизе.
Раскройте мысль, почему единый слой - не очень хорошо, кроме кэширования? Обычно это наоборот классическая рекомендация - уменьшение количества слоёв в итоговом образе. Особенно при установке зависимостей из apt. Либо так, либо мультистейдж, который слепит все слои в один при использовании инструкции FROM на следующем шаге (для образов приложений, когда мы будем их рассматривать, я рекомендую именно такой подход).
/sarcasm_mode on
Речь, видимо, про США, не знал, что там коммунизм.
/sarcasm_mode off
FYI, автор оригинала - Jason Godesky, закончил University of Pittsburgh.
Немного подумав дополню сам себя:
Лонгполлинг не обязательно использовать, можно обойтись запрос-ответами.
Девайс код не поможет, если сервер поднимать на локолхосте
Весь этот усложненный путь стоит использовать ТОЛЬКО, если OAuth-провайдер не реализовал уже за вас расширение device-code, тогда нужно использовать его (ссылки в других ветках комментариев).
Дополню: многие адекватные OAuth по причине безопасности запрещают в качестве урла указывать локалхост. "Правильная" схема будет использовать внешний сервер, который будет ждать редирект:
CLI инициирует авторизацию и встаёт в лонгполлинг на внешний сервер приложения с таймаутом с некоторым генеренным на стороне клиента идентификационным токеном
В браузере открывается ОАуф сессия, которая редиректит в конце на внешний сервер приложения, передавая наш идентификационный токен
Внешний сервер отвечает на лонгполл, если находится с нужным id токеном, передавая данные авторизации oauth
В идеале, чтоб ещё исключить man-in-the-middle, пользователь на стороне нашего внешнего сервера на форме должен ввести какой-то код, который ему сгенерит CLI в процессе, тот же идентификационный токен и только после этого наш сервер отвечает на лонгполл. Это стоит делать и в вашей схеме, если вы не хотите, что б злоумышленник попытался прикинуться вами и украсть данные пользователя от имени вашего приложения, точно так же подняв локальный сервер.
Да, стоит не забывать, что если возникает несколько лонгполлов на одном ID токене, то лучше сбросить все.
Найм отражает коллектив. Если вы нанимаете людей, которые обладают определёнными качествами, то и коллектив закономерно будет ими обладать.
Если вы нанимаете разработчиков, которые в первую очередь умеют хорошо писать тексты - ваше право. Если вы ищете разработчиков, которые приукрашивают свои умения - ваше право. Если вы ищете художников/копирайтеров вместо разработчиков - всё ещё ваше право.
Если вам ещё и потом действительно комфортно работать с этой командой - вообще замечательно. Если ещё и работа спорится - так вообще отлично.
Но! Это всё вопрос приоритетов. Мне лично , да и многим в найме, важнее другие качества, например профессиональные. Потому и проверять и смотреть я буду именно на них.
Я не говорю, что CV не важно, я говорю, что ставить его в красный угол и молиться на него - немного сбитый прицел, как по мне. Но если эта схема для вас работает - да и пусть, уверен, что хватает кандидатов, которые хотели бы чтоб их оценивали по качеству составления резюме, а не по умениям, именно с ними вы и найдёте друг друга.
Автор злоупотребляет автогенерацией без особой редактуры, особенно видно по техническим статьям, если пролистать историю публикаций.
Речь не про решение старых задач, а именно про переизобретение уже существующих решений. Кажется вы смешивание понятие задачи и решения.
По определению "изобретать велосипед" противоречит "никто не додумался". Изобретать велосипед - переизобретение уже существующих решений.
PS: форточку сам открою.
Простите, но если так всё просто по графе Программист, то "пройдите говнокурс, прочитайте старый учебник" и дальше по списку. Будете получать 300к/секунду, не будете зависеть от ЗП в авторстве и будете писать в своё удовольствие сколько захотите. Раз вы ещё не там, то предположу, что возможно мир немного отличается от вашего о нём представления.
Не скажу за спорт тематику, но когда открываешь статью на техническую тему, то достаточно быстро заметно когда она написана GPT, поскольку от неё за километр разит дважды переваренным бредом. Особенно если есть хотя бы минимальная экспертиза в том, что читаешь. На это откровенно больно смотреть. И речь не про рекламные ресурсы помойки, которые фишат трафик с поисковиков, речь об уважаемых изданиях и крупных UGC ресурсах типа хабра.
Я не говорю, что GPT бесполезен, но это инструмент коррекции, прегенерации. Про убирание человека из этого уравнения сейчас крайне рано говорить. Соавторство - да, авторство модели - пока нет.
Есть "авторы" промышляющие написанием десятка статей в месяц, наполненных ошибками, несуразицами и по сути являющиеся откровенными вредными советами.
PS: речь не про умение скомпоновать текст, речь именно про фактуру.
Linux - это считай коммунизм.