RUN chmod -Rf 777 . можено в докерфайле добавить =)

почему то ругается что no such file or directory

почему то ругается что no such file or directory

https://stackoverflow.com/questions/45972608/how-to-give-folder-permissions-inside-a-docker-container-folder

https://stackoverflow.com/questions/45972608/how-to-give-folder-permissions-inside-a-docker-container-folder

проблема в том что я ничего не копирую. просто volume с хоста подключается

видимо в этом дело

Если я не ошибаюсь то volume подключается в момент старта. И тянет за собой ещё и пермишены с хоста

В докер файле вы можете только регламентировать что такой volume возможен

Подскажите как можно настроить автоматическое обновление образа и при этом обновление контейнера?) какие есть инструменты или связки инструментов?

Вы из :latest деплоите на прод?

Вы из :latest деплоите на прод?

Хреновый подход.

Вы из :latest деплоите на прод?

да, но не на прод

Я к тому, чтобы уточнить кейс) Так то, настраиваешь авто-деплой в вашей CD системе, что используете для ручных деплоев, например, по ночам)). Или авто-деплой после загрузки образа в регистри

Я к тому, чтобы уточнить кейс) Так то, настраиваешь авто-деплой в вашей CD системе, что используете для ручных деплоев, например, по ночам)). Или авто-деплой после загрузки образа в регистри

Диплой образа в регистры понятно, а обновление контейнера получается скриптовать нужно?)

Все точно также, как вы делаете вручную - - пулл образа с форсем, - перезапуск контейнера из этого образа Только по событию (загрузка в регистри)

Контейнер - низкий уровень, он даёт интерфейсы, а как за них дергать - у всех свои хотелки)

Контейнер - низкий уровень, он даёт интерфейсы, а как за них дергать - у всех свои хотелки)

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

Хреновый подход.

Обоснуй

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

Сделай одним плейбуком всё

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

А как ты билдишь и загружаешь в регистри? На локалхосте, или в Дженкинсе.?

А как ты билдишь и загружаешь в регистри? На локалхосте, или в Дженкинсе.?

Drone.io ну почти тоже самое

Обоснуй

А что обосновывать? Ты готов катить на прод неизвестную версию приложения из реджистри? Ну, как напорешься — расскажи.

А что обосновывать? Ты готов катить на прод неизвестную версию приложения из реджистри? Ну, как напорешься — расскажи.

тесты не слышал?

А что обосновывать? Ты готов катить на прод неизвестную версию приложения из реджистри? Ну, как напорешься — расскажи.

Что значит неизвестную? Это моё приложение, протестированое

тесты не слышал?

При чём тут тесты?

Drone.io ну почти тоже самое

Не работал с ним, но поищи триггеры на запуск сборки (после завершения другой), или веб-хуком дёрнуть другую сборку

При чём тут тесты?

Вы в компании не тестируете?

При чём тут тесты?

При том что ты цепляешь свой образ, тестируешь и льёшь)

Тесты в разные моменты могут выполнятся. Вот разраб прислал комит, собрался , улетел в регистри, запустились тесты дальше в пайплайне, и упали. При этом образ уже в регистри, и параллельно кто-то выкатил на прод это

Или нужно уточнить что разные репы для дева и прода

Тесты в разные моменты могут выполнятся. Вот разраб прислал комит, собрался , улетел в регистри, запустились тесты дальше в пайплайне, и упали. При этом образ уже в регистри, и параллельно кто-то выкатил на прод это

Тесты это управляемый процесс, никто не делает в таком порядке, как ты написал

Я про то, что лить конкретный имедж намного проще, чем подкладывать себе потенциальные грабли. Тесты — оно хорошо, но по закону Мерфи то, что может сломаться, сломается, и лениться, указывая :latest довольно глупое занятие.

Когда маленькая команда, возможно

Или нужно уточнить что разные репы для дева и прода

Не разные, тестится бранч, который уйдёт в мастер, проверили всё ок, смерджилм, собрали latest, разлили

Я про то, что лить конкретный имедж намного проще, чем подкладывать себе потенциальные грабли. Тесты — оно хорошо, но по закону Мерфи то, что может сломаться, сломается, и лениться, указывая :latest довольно глупое занятие.

У меня 20 микросервисов, разные команды и деплой каждый день, тут нельзя договориться за версию, только мастер - совместимость и latest

После мерджа тестировать то надо снова, потому что пока тестили, кто-то влить уже мог другой бранч. Неконфликтующие по Гиту, но ломающие друг друга изменения. +Интеграционное тестирование с другими системами

Ну если команда одновременно делает только 1фича-ветку, это тоже доп.условие

@friendly_zika интересно послушать про флоу, CI/CD и мониторинг, тестирование, как все связано вместе

У меня 20 микросервисов, разные команды и деплой каждый день, тут нельзя договориться за версию, только мастер - совместимость и latest

Мда. В том же дженкинсе есть такая штука, как переменные окружения. Собрал app:$BUILD_NUMBER, выкатил app:$BUILD_NUMBER. Это лишь один из способов.

Изменения попадают в мастер атомарно и льётся состояние мастера проверенное разумеется. Артефакт latest проверяется не в проде разумеется и льётся в прод АРТЕФАКТОМ который прошёл интеграционные

Мда. В том же дженкинсе есть такая штука, как переменные окружения. Собрал app:$BUILD_NUMBER, выкатил app:$BUILD_NUMBER. Это лишь один из способов.

Я ничё не понял, какой смысл?

А как отличить артефакт, который с фичей и прошёл тесты, от того что только что собран (новая фича) и ещё не прошел?)

Я ничё не понял, какой смысл?

Ну ок, что я могу сказать? Лей дальше лэйтест. Ты попросил обосновать, я обосновал, в дальнейшем споре на тему не вижу смысла, каждый дрочит как он хочет.

@friendly_zika интересно послушать про флоу, CI/CD и мониторинг, тестирование, как все связано вместе

Ты же Site Reliability Engineer, для тебя гугл книжку написал, чё меня слушать

А как отличить артефакт, который с фичей и прошёл тесты, от того что только что собран (новая фича) и ещё не прошел?)

Это в тимсити написано всё, какие там комиты и прошли ли тесты

Могу заскринить и у натариуса заверить

Тогда это вручную все, а не автоматически ж?

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

Ну ок, что я могу сказать? Лей дальше лэйтест. Ты попросил обосновать, я обосновал, в дальнейшем споре на тему не вижу смысла, каждый дрочит как он хочет.

Ты не объяснил зачем

Мда. В том же дженкинсе есть такая штука, как переменные окружения. Собрал app:$BUILD_NUMBER, выкатил app:$BUILD_NUMBER. Это лишь один из способов.

Могу понятно объяснить тебе почему это говно

Ребят, вот это я затронул тему) прям горячо стало в чате)

Ты не объяснил зачем

Я объяснил. Вот здесь. https://t.me/docker_ru/61532

Могу понятно объяснить тебе почему это говно

Давай.

Давай.

вот у меня продукт целиковый из микросирсов. Команда 1 написала киллерфичу, гдет чёт напишила и собрала твой офигенный app:BUILD_NUMBER33 в своём дженкинсе. Команда 17 тоже должна обновить свой сервис для киллерфичи и им надо забрать сервис команды 1 с последними изменениями, им придётся знать, что это именно BUILD_NUMBER33, откуда им это. блин, знать?

вот у меня продукт целиковый из микросирсов. Команда 1 написала киллерфичу, гдет чёт напишила и собрала твой офигенный app:BUILD_NUMBER33 в своём дженкинсе. Команда 17 тоже должна обновить свой сервис для киллерфичи и им надо забрать сервис команды 1 с последними изменениями, им придётся знать, что это именно BUILD_NUMBER33, откуда им это. блин, знать?

А при чём тут команды? Команды пускай latest пулят. Речь-то была о деплое на прод.

Допустим они даже узнали, что это именно 33 билд в слаке (что конечно никак с автоматизацией не вяжется), что им делать с остальными 5 зависимости от других команд, они даже человека не знают кто там работает именно. А если команда 17 тупит и долго интегрируется с 33 билдом команды 1, тем временем у команды 1 уже 35 билд, им каждый раз в слак писать, поцаны, обновитесь!! ??

А при чём тут команды? Команды пускай latest пулят. Речь-то была о деплое на прод.

все latest пулили пулили, тестили тестили, а выкатывать каждый микросервис будем из BUILD_NUMBERXXX , шо за нах?

все latest пулили пулили, тестили тестили, а выкатывать каждый микросервис будем из BUILD_NUMBERXXX , шо за нах?

Коллега, у тебя всё хорошо с логикой? Ещё раз: в процессе разработки можно пулить последнюю версию. На прод и препрод для тестов надо катить фиксированную.

Допустим они даже узнали, что это именно 33 билд в слаке (что конечно никак с автоматизацией не вяжется), что им делать с остальными 5 зависимости от других команд, они даже человека не знают кто там работает именно. А если команда 17 тупит и долго интегрируется с 33 билдом команды 1, тем временем у команды 1 уже 35 билд, им каждый раз в слак писать, поцаны, обновитесь!! ??

Без обид, просто интересно, Вы давно в профессии?

Коллега, у тебя всё хорошо с логикой? Ещё раз: в процессе разработки можно пулить последнюю версию. На прод и препрод для тестов надо катить фиксированную.

я тебе не коллега, приятель. А выкатывать будем фикс версию всем микросервисам ?

Без обид, просто интересно, Вы давно в профессии?

ты давно дурачок, только без обид?

я тебе не коллега, приятель. А выкатывать будем фикс версию всем микросервисам ?

Оно и видно, что не коллега. Да, всем. А что мешает-то? Процесс должен быть одинаков для всех.

ты давно дурачок, только без обид?

Привет родителям.

Оно и видно, что не коллега. Да, всем. А что мешает-то? Процесс должен быть одинаков для всех.

а ничего что они деплоятся не одновременно?

Оно и видно, что не коллега. Да, всем. А что мешает-то? Процесс должен быть одинаков для всех.

как это возможно, если сервис 1 деплоится в два раза чаще сервиса 17 ?

Мне больше интересно ещё вот что --- если нашли багу на проде после релиза. что-то упустили и т.п. Откатываться назад - на какую версию?

Мне больше интересно ещё вот что --- если нашли багу на проде после релиза. что-то упустили и т.п. Откатываться назад - на какую версию?

это не автоматический процесс, да и не факт, что будем откатываться, а не хотфиксить. Я не предлагаю отказываться от версий, я лишь о том, что катится на прод, под капотом есть версии и откатиться можно на предыдущую (с явной версией)

как это возможно, если сервис 1 деплоится в два раза чаще сервиса 17 ?

Слушай, ты полез в залупу, доказывая, что не надо фиксировать версии приложения в деплое и начал приводить примеры из собственной инфраструктуры, которая явно нетипична. Если человек рулит такой инфрой, он явно не будет задавать такие вопросы. В большинстве случаев делать это нужно, потому что это потенциальная и очень явная точка отказа, а ты занимаешься хернёй, натягивая сову на глобус и пытаясь доказать, что твой конкретно подход правильный. Я тебе уже сказал, что каждый дрочит как он хочет. Не надо подавать дурной пример другим, если у вас сделано через жопу (возможно вынужденно). Если ты готов пойти на риск сломать прод — твоё право. Я нет. На этом пикировку предлагаю завершить.

Слушай, ты полез в залупу, доказывая, что не надо фиксировать версии приложения в деплое и начал приводить примеры из собственной инфраструктуры, которая явно нетипична. Если человек рулит такой инфрой, он явно не будет задавать такие вопросы. В большинстве случаев делать это нужно, потому что это потенциальная и очень явная точка отказа, а ты занимаешься хернёй, натягивая сову на глобус и пытаясь доказать, что твой конкретно подход правильный. Я тебе уже сказал, что каждый дрочит как он хочет. Не надо подавать дурной пример другим, если у вас сделано через жопу (возможно вынужденно). Если ты готов пойти на риск сломать прод — твоё право. Я нет. На этом пикировку предлагаю завершить.

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

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

>РРРЯЯЯЯ НИПРАВ НИПРАВ Я ЛУЧЧИ ЗНАЮ

Ещё раз: прекращай свой опыт экстраполировать на всех. «Реальная жизнь» бвает разная, а «серьёзные проекты» не всегда архитектурно бывают через жопу.

Ещё раз: прекращай свой опыт экстраполировать на всех. «Реальная жизнь» бвает разная, а «серьёзные проекты» не всегда архитектурно бывают через жопу.

микросервисы с независимыми командами это "через жопу" или что именно тебе кажется у меня не так сделано как нужно?

микросервисы с независимыми командами это "через жопу" или что именно тебе кажется у меня не так сделано как нужно?

Слушай, что ты ко мне приебался? Доказать, что твоё кунг-фу лучше моего? Лучше, лучше. В твоей ситуации так, в моей эдак.

Слушай, что ты ко мне приебался? Доказать, что твоё кунг-фу лучше моего? Лучше, лучше. В твоей ситуации так, в моей эдак.

Хочу понять в чём я не прав, ты же знаешь видимо, просто объяснить не получается

про дрочильню, проект через жопу, привет родителям и РРЯЯЯЯ - это явно не аргументация

про дрочильню, проект через жопу, привет родителям и РРЯЯЯЯ - это явно не аргументация

Соскочить на быдланство вместо ответа про стаж на фоне джуновых вопросов в чат - это да %)

Соскочить на быдланство вместо ответа про стаж на фоне джуновых вопросов в чат - это да %)

какой вопрос был джуновский ?

какой вопрос был джуновский ?

Про передачу номера версий между сервисами, конечно.

Про передачу номера версий между сервисами, конечно.

и что в нём джуновского?

Хочу понять в чём я не прав, ты же знаешь видимо, просто объяснить не получается

Да ты же до последнего усираться будешь. Что толку? Я не собираюсь учить тебя работать. Ещё раз: в твоей ситуации это, возможно, оправдано. но не у всех так. За сим дискуссию на тему прекращаю, не вижу смысла топтаться на одном месте.

Эээ, а версионирование API у микросервисов, не?

Да ты же до последнего усираться будешь. Что толку? Я не собираюсь учить тебя работать. Ещё раз: в твоей ситуации это, возможно, оправдано. но не у всех так. За сим дискуссию на тему прекращаю, не вижу смысла топтаться на одном месте.

ты можешь ответить на вопрос? По-твоему неправильно, что сервис 1 деплоится в два раза сервиса 17, с которым у него есть связь?

Эээ, а версионирование API у микросервисов, не?

ты это к чему?

ты это к чему?

это я к тому, что один сервис о версии другого знать не должен

это я к тому, что один сервис о версии другого знать не должен

я согласен

ты можешь ответить на вопрос? По-твоему неправильно, что сервис 1 деплоится в два раза сервиса 17, с которым у него есть связь?

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

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

очевидно деплой происходит при появлении нового кода только (смена версии), разве это не логично?

очевидно деплой происходит при появлении нового кода только (смена версии), разве это не логично?

Ну да, и что? Какое это отношение имеет к latest?

я согласен

в сочетании с этим, при отказе от выкатывания latest в прод и на стейджи (что хорошо, так как образ с этим тегом может поменяться в любой момент), все будет как надо

Ну да, и что? Какое это отношение имеет к latest?

» А выкатывать будем фикс версию всем микросервисам ? » Да, всем. А что мешает-то? Процесс должен быть одинаков для всех. при том, что это и мешает, то что версии у них разные

» А выкатывать будем фикс версию всем микросервисам ? » Да, всем. А что мешает-то? Процесс должен быть одинаков для всех. при том, что это и мешает, то что версии у них разные

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

» А выкатывать будем фикс версию всем микросервисам ? » Да, всем. А что мешает-то? Процесс должен быть одинаков для всех. при том, что это и мешает, то что версии у них разные

Да пускай будут разные, в чём смысл? Это же имеет значение только в рамках деплоя. А вообще, ты серьёзно споришь, что версионирование не нужно? Рили?

Да пускай будут разные, в чём смысл? Это же имеет значение только в рамках деплоя. А вообще, ты серьёзно споришь, что версионирование не нужно? Рили?

если они разные, как следить за тем, какая подходит, а какая нет?

если они разные, как следить за тем, какая подходит, а какая нет?

вот тут мы и подходим к версионированию API

и что в нём джуновского?

Ты задаешь вопрос, который демонстрирует полное непонимание микросервисной архитектуры.

Ты задаешь вопрос, который демонстрирует полное непонимание микросервисной архитектуры.

ты свяжи два слова хоть, воду только льёшь

ты свяжи два слова хоть, воду только льёшь

В чем моя выгода тебя учить?

В чем моя выгода тебя учить?

тогда ничего не пиши просто, мешаешь