Re[26]: Docker - для релиза или для разработки?
От: Sheridan Россия  
Дата: 14.05.20 08:58
Оценка:
Здравствуйте, Farsight, Вы писали:

S>>Да, верное решение.

F>Угу. Уже половину вывели из контейнеров. Закончим, отпишусь. Жди.
Держи нас в курсе.
Matrix has you...
Re[15]: Docker - для релиза или для разработки?
От: Mamut Швеция http://dmitriid.com
Дата: 14.05.20 10:57
Оценка: 2 (1) +3 :)
S>>>Да-да. Рассказывай мне про секундное генерирование образов.
M>>причем тут генерация?
S>А, то есть вы в прод запихиваете образа сразу с докерхаба? Мо-лод-цы.

— Шеридан даже близко не представляет, что на докерхабе есть приватные хабы aka docker hub enterprise
— Шеридан даже близко не представляет, что не обязательно все заливать на докерхаб, а можно развернуть собственный приватный реестр
— Шеридан даже близко не представляет, что, например, Google предоставляет собственный приватный реестр aka Google Container Registry

Хотя можно было бы просто остановиться на

— Шеридан даже близко не представляет

Потому что это стандартная ситуация для Шеридана.


dmitriid.comGitHubLinkedIn
Re[16]: Docker - для релиза или для разработки?
От: Vetal_ca Канада http://vetal.ca
Дата: 14.05.20 13:37
Оценка:
Здравствуйте, Mamut, Вы писали:



M>- Шеридан даже близко не представляет, что на докерхабе есть приватные хабы aka docker hub enterprise

M>- Шеридан даже близко не представляет, что не обязательно все заливать на докерхаб, а можно развернуть собственный приватный реестр
M>- Шеридан даже близко не представляет, что, например, Google предоставляет собственный приватный реестр aka Google Container Registry

M>Хотя можно было бы просто остановиться на


M>- Шеридан даже близко не представляет


M>Потому что это стандартная ситуация для Шеридана.



Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.

Печальное зрелище вот так человека гонять, чтобы получить ответы на главные вопросы.

Как произошла фиксация и закостенение около 5+ лет назад. Что этому способствовало. И осознает ли он сам, до конца.

Или как трехногий кот, "ощущающий" несуществующую конечность. Хотя, учитывая этот "Розгами этих, розгами тех, розгами-розгами всех", какая-то воспалительная реакция есть. Но, тем не менее, не двигает в продуктивном направлении.
Re[17]: Docker - для релиза или для разработки?
От: Mamut Швеция http://dmitriid.com
Дата: 14.05.20 13:56
Оценка:
V_>Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.

Я лет десять тому назад с ним голосо-чатился, а потом просто чатился. Уже не помню в деталях, про что мы там говорили, он согласился с процентов 90 доводов в итоге Не прошло и пары месяцев, и все пошло по кругу.


dmitriid.comGitHubLinkedIn
Re[18]: Docker - для релиза или для разработки?
От: Vetal_ca Канада http://vetal.ca
Дата: 14.05.20 14:36
Оценка:
Здравствуйте, Mamut, Вы писали:


V_>>Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.


M>Я лет десять тому назад с ним голосо-чатился, а потом просто чатился. Уже не помню в деталях, про что мы там говорили, он согласился с процентов 90 доводов в итоге Не прошло и пары месяцев, и все пошло по кругу.


Я про ознакомление с Ansible
Re[21]: Docker - для релиза или для разработки?
От: Cyberax Марс  
Дата: 14.05.20 17:30
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

C>>Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов.

S>Вот и ансибл — не совсем.
Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.

C>>>>он сам ничего не чистит.

S>>>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
C>>
C>>--
C>>- name: CleanForSure
C>>  command: dd if=/dev/urandom bs=10 of=/clean count=10
C>>


C>>И как и что оно будет чистить?

S>У тебя команда не выполнится. Ну, разве что /clean это блочное устройство.
cyberax@CybMac:~/aurora/circleci-slim$ dd if=/dev/urandom bs=10 of=/tmp/clean count=10
10+0 records in
10+0 records out
100 bytes transferred in 0.000142 secs (704925 bytes/sec)
cyberax@CybMac:~/aurora/circleci-slim$ ls -la /tmp/clean
-rw-r--r--  1 cyberax  wheel  100 14 май 10:26 /tmp/clean


Давай поспорим на деньги, скажем на $1000?

S>Разберись уже как работает ансибл и поймёшь что оно чистит за собой.

Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой.

S>>>Ансибл за собой тоже ничего на хосте не оставляет после деплоя.

C>>Не надо врать.
S>Более того, ансибл не нужен на целевом хосте для деплоя.
Естественно, так как анзибль — это просто выполнялка команд, которая может и через SSH работать.

C>>Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что.

S>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.
Ну так как Ansible будет магически предотвращать мусор после удаления софта?

C>>В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах.

S>Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях.
Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.

S>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.

Ну так и защита памяти тогда не нужна.

C>>PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять.

S>Видимо использовал-использовал но так и не разобрался. Впрочем, тебе то простительно, ты программист а не админ/девапс.
Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.
Sapienti sat!
Re[22]: Docker - для релиза или для разработки?
От: Sheridan Россия  
Дата: 14.05.20 17:48
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>>>Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов.

S>>Вот и ансибл — не совсем.
C>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.
Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду?

S>>У тебя команда не выполнится. Ну, разве что /clean это блочное устройство.

C>
C>cyberax@CybMac:~/aurora/circleci-slim$ dd if=/dev/urandom bs=10 of=/tmp/clean count=10
C>10+0 records in
C>10+0 records out
C>100 bytes transferred in 0.000142 secs (704925 bytes/sec)
C>cyberax@CybMac:~/aurora/circleci-slim$ ls -la /tmp/clean
C>-rw-r--r--  1 cyberax  wheel  100 14 май 10:26 /tmp/clean
C>

А, clean это файл а не каталог. Мой косяк, не распарсил.

S>>Разберись уже как работает ансибл и поймёшь что оно чистит за собой.

C>Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой.
Угу, ага. За собой он очень хорошо чистит.
Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.
Так что твои слова про 13й год и знание ансибла выглядят ниочччень.


S>>>>Ансибл за собой тоже ничего на хосте не оставляет после деплоя.

C>>>Не надо врать.
S>>Более того, ансибл не нужен на целевом хосте для деплоя.
C>Естественно, так как анзибль — это просто выполнялка команд, которая может и через SSH работать.
Ну хоть это ты знаешь.


C>>>Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что.

S>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.
C>Ну так как Ansible будет магически предотвращать мусор после удаления софта?
Тасками, друг мой, тасками.


C>>>В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах.

S>>Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях.
C>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.
Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.


S>>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.

C>Ну так и защита памяти тогда не нужна.
Чего уж ты мелко ходишь, давай уже так: Да и вообще защита не нужна. Выкомпилить секурити и прочие ацл из ядра, затереть ssl!!11


C>>>PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять.

S>>Видимо использовал-использовал но так и не разобрался. Впрочем, тебе то простительно, ты программист а не админ/девапс.
C>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.
Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил.
Matrix has you...
Re[23]: Docker - для релиза или для разработки?
От: Cyberax Марс  
Дата: 14.05.20 18:28
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>>>Вот и ансибл — не совсем.

C>>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.
S>Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду?
Есть Nix — они там реально гарантируют чистоту исполнения, есть Puppet — там описывается логическая структура и Puppet пытается построить план для достижения этого состояния. Это как пример структурированного исполнения.

S>>>Разберись уже как работает ансибл и поймёшь что оно чистит за собой.

C>>Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой.
S>Угу, ага. За собой он очень хорошо чистит.
Я уже привёл контр-пример.

S>Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.

S>Так что твои слова про 13й год и знание ансибла выглядят ниочччень.
Ты реально не понимаешь ничего, ок.

S>>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.

C>>Ну так как Ansible будет магически предотвращать мусор после удаления софта?
S>Тасками, друг мой, тасками.
Как? Я уже привёл пример, когда Ansible не очистит файл.

C>>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.

S>Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
Именно так.

S>>>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.

C>>Ну так и защита памяти тогда не нужна.
S>Чего уж ты мелко ходишь, давай уже так: Да и вообще защита не нужна. Выкомпилить секурити и прочие ацл из ядра, затереть ssl!!11
[quote]
Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
[/quote]

C>>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.

S>Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил.
Т.е. все 4 года не можешь настроить Ansible. Понятно.

Ну ладно, я иду обратно плакать от горя. Я всего-то построил инфраструктуру компании, работающей на 3 континентах. Вся инфраструктура в виде кода, для десятка самых разных приложений. И для этого не нужен был Ansible
Sapienti sat!
Re[5]: Docker - для релиза или для разработки?
От: baxton_ulf США  
Дата: 14.05.20 18:44
Оценка: +2
Здравствуйте, SkyDance, Вы писали:

N>>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.


не доступно != работает не правильно
Re[24]: Docker - для релиза или для разработки?
От: Sheridan Россия  
Дата: 14.05.20 21:10
Оценка: :)
Здравствуйте, Cyberax, Вы писали:


S>>>>Вот и ансибл — не совсем.

C>>>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.
S>>Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду?
C>Есть Nix — они там реально гарантируют чистоту исполнения, есть Puppet — там описывается логическая структура и Puppet пытается построить план для достижения этого состояния. Это как пример структурированного исполнения.
У ансибла ещё больше свободы. Значит на нём можно добиться чего угодно.
Практика показывает что чем умнее инструмент, тем сложнее реализовывать решение, выходящее за рамки тривиального.


S>>Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.

S>>Так что твои слова про 13й год и знание ансибла выглядят ниочччень.
C>Ты реально не понимаешь ничего, ок.
Это ты привык думать контейнерами и тебе кажется что кроме контейнеров нет ничего и кубернетес пророк их.


S>>>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.

C>>>Ну так как Ansible будет магически предотвращать мусор после удаления софта?
S>>Тасками, друг мой, тасками.
C>Как? Я уже привёл пример, когда Ansible не очистит файл.
Пишем таск "очистить файл, вот так". Файл очищается.
При необходимости следом еще пишем таск "а хорошо мы файл очистили, может ещё раз?"


C>>>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.

S>>Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
C>Именно так.
Ну хоть в чём-то ты со мной согласился.


C>>>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.

S>>Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил.
C>Т.е. все 4 года не можешь настроить Ansible. Понятно.
Конечно не могу! А что это такое, кстати?...


C>Ну ладно, я иду обратно плакать от горя. Я всего-то построил инфраструктуру компании, работающей на 3 континентах. Вся инфраструктура в виде кода, для десятка самых разных приложений. И для этого не нужен был Ansible

Ну я поменьше наверное... За 4 года реализовал разные хотелки десятка компаний, среди которых в том числе и такие вот "межконтинентальные".
Контейнеры были только для разработки. Но ты продолжай верить.
Matrix has you...
Re[15]: Docker - для релиза или для разработки?
От: mogadanez Чехия  
Дата: 14.05.20 23:43
Оценка:
Здравствуйте, Sheridan, Вы писали:

M>>причем тут генерация?

S>А, то есть вы в прод запихиваете образа сразу с докерхаба? Мо-лод-цы.

во первых уже два или три раза тут писали про base-image. который меняется редко

во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает
деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами
Re[17]: Docker - для релиза или для разработки?
От: mogadanez Чехия  
Дата: 14.05.20 23:51
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Твоя аргументация: разрабаам лень разбираться, поэтому докер.

S>Предотвращая бесполезный спор — разрабы и не должны разбираться. Это должен делать девапс/админ.

докер это быстро, надежно и в сумме дешевле
Re[16]: Docker - для релиза или для разработки?
От: Sheridan Россия  
Дата: 15.05.20 00:01
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает

M>деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами

Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост.
Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage.
По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".

С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.

Разве что выигрыш будет если прод это 100500 совершенно однотипных машин, в которые грузится один и тот же образ. Впрочем и с ансиблом почти то же самое, только грузим в хосты не всё сразу, а только диффы. То есть может даже и быстрее получиться.

Matrix has you...
Re[18]: Киллер-фичи докера
От: Sheridan Россия  
Дата: 15.05.20 00:03
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>докер это быстро, надежно и в сумме дешевле


Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?
Matrix has you...
Re[17]: Docker - для релиза или для разработки?
От: mogadanez Чехия  
Дата: 15.05.20 00:12
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, mogadanez, Вы писали:


M>>во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает

M>>деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами

S>Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост.

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

S>Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage.

S>По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".

нет это ты пытаешься подогнать под свое мировозрение. создание образов это именно билд. причем не факт что он потом вообще кудато пойдет или будет задеплоен
БД с этим вообще никак не связана и лежит в другой плоскости


S>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.


хуяк хуяк и в продакшен?
Re[19]: Киллер-фичи докера
От: mogadanez Чехия  
Дата: 15.05.20 00:15
Оценка:
Здравствуйте, Sheridan, Вы писали:


S>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?


для меня — это дешевле чем любым другим способом из тех что я пробовал.
обойтись могу — например фронтенд не в докере лежит
Re[17]: Docker - для релиза или для разработки?
От: Cyberax Марс  
Дата: 15.05.20 00:16
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.



Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях. Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд.

А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.
Sapienti sat!
Re[18]: Docker - для релиза или для разработки?
От: SkyDance Земля  
Дата: 15.05.20 04:58
Оценка: 2 (1)
C>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.

Парни, вы спорите о совсем разных вещах.

Один говорит "вот если бы все программисты в мире понимали, что они делают, то контейнеры для изоляции одних непонимающих программистов от других были бы не нужны". И он прав.

Другой говорит "у меня нет задачи сделать мир во всем мире и научить программистов всего мира думать головой, и понимать, что они делают, а не тупо копировать со стекОверфлоу". И он тоже прав.

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

Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.

Просто разные виды дискомфорта. Кому-то попа, кому-то попадью, кому-то дочку.
Re[19]: Docker - для релиза или для разработки?
От: Mamut Швеция http://dmitriid.com
Дата: 15.05.20 05:16
Оценка: -1
SD>Просто каждый о своем. Первого надо ближе к железу, на низкоуровневое системное программирование. Там да, надо делать очень точные, тонкие, надежные и по-своему прекрасные решения. Со скоростью "десять строчек кода в день", если повезет, и ни одной, если нет нужного состояния.

SD>Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.


SD>Просто разные виды дискомфорта. Кому-то попа, кому-то попадью, кому-то дочку.


С единственной поправкой: Шеридан — это второй, с претензией на первый. Его оппоненты — весь спектр между первым и вторым и почти никогда — строго вторые. Более того, его оппоненты как совокупно так и по отдельности имеют в разы больше опыта. В том числе с теми же инструментами, о которых он высокопарно вещает.

Потому что блин. Тту рядом Шеридан даже понять не может, что ему Киберакс говорит про чистку окружения на хосте в случае чего. Почитай подтред
Автор: Cyberax
Дата: 14.05.20
, весьма показтелен.


dmitriid.comGitHubLinkedIn
Отредактировано 15.05.2020 5:18 Mamut [ищите в других сетях] . Предыдущая версия .
Re[18]: Docker - для релиза или для разработки?
От: Sheridan Россия  
Дата: 15.05.20 05:39
Оценка: :)
Здравствуйте, mogadanez, Вы писали:

S>>Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост.

M>образы не монолитны, по факту при новой версии копируется только "разница" чаше всего это именно код, при некоторых оптимизациях даже часть кода. остальное в кеше
Значит от ансибла недалеко ушли.


S>>Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage.

S>>По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".


M>нет это ты пытаешься подогнать под свое мировозрение. создание образов это именно билд. причем не факт что он потом вообще кудато пойдет или будет задеплоен

Билд это код->бинарник, код->другой код. Ну то есть когда берется код, написанный программистами и из него сооружается то, что можно запускать.
А софт->диск (виртульный диск, контейнер) это деплой. То есть когда сбилденый софт укладывается так, чтобы при своём запуске он нашол всё что ему нужно для работы там, где он ожидает это найти.
С языками типа питона шаг сборки отсутствует, сразу идёт шаг деплоя.


M>БД с этим вообще никак не связана и лежит в другой плоскости

Да, тут ты прав. БД на втором шаге деплоя, при разворачивании на прод, после рестарта образа.


S>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.

M>хуяк хуяк и в продакшен?
Печально если вы так делаете.
Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."?
Matrix has you...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.