Доброе утро Ребят, есть чаты где можно спросить базовые вещи по ci, не обязательно докер? Т.е. бывают затыки типа как более правильно организовать пайплайн, что хранить как артефакт а что лучше налету, как быть с имеджами - один образ для всех окружений или для локал лучше без образа и в таком роде

Доброе утро Ребят, есть чаты где можно спросить базовые вещи по ci, не обязательно докер? Т.е. бывают затыки типа как более правильно организовать пайплайн, что хранить как артефакт а что лучше налету, как быть с имеджами - один образ для всех окружений или для локал лучше без образа и в таком роде

по какому конкретно сиай?

"базовые" у всех свои

Доброе утро Ребят, есть чаты где можно спросить базовые вещи по ci, не обязательно докер? Т.е. бывают затыки типа как более правильно организовать пайплайн, что хранить как артефакт а что лучше налету, как быть с имеджами - один образ для всех окружений или для локал лучше без образа и в таком роде

@devops_ru

чтобы сразу не брать ентерпрайз уровня проект (который в очереди на автоматизацию), взял потренироваться простую ситуацию (относительно). Тестовый стенд Новый джанго апп, миграции, база с данными, несколько окружений - локал, стейджинг, прод. Как услугу для всего необходимого взял gitlab, стейджинг на heroku, прод наверное без докера для более красивого случая. Разработка распределенная (т.е. не один человек и не все в транк пушат - гитфлоу к примеру), стадии тестирования релизов. сразу несколько вопросов 1. при инициализации нового окружения возникает необходимость создавать пользователей (данные приложения/окружения), как или откуда их брать? Описывать в код (инфраструктура как код) как-то не очень красиво, это ведь данные работы, не фикстуры, описывать отдельный пайп и запускать руками - тоже как-то избыточно. Делать все руками - где CI? Таскать дамп - уже не очень все в коде. 2. локальное окружение. Обычно описываю мейкфайл который билдит, ранает что надо (докер композы), открывает шелы контейнеров - все чтонадо для разработки есть. Но не совсем понятно как быть с имеджами которые билдятся на CI - принято чтобы они имели отношение к локальной разработке или это только для рабочих окружений? т.е. указать и имедж и докерфайл, имедж (с тегом :latest) как кеш использовать или что-то в этом роде. 3. как быть с бекапами и миграциями данных которые как данные приложения, не окружения. К примеру если это сайт и там статьи как часть приложения (к примеру CMS, где вроде как и контент но это часть приложения, статик страницы), как это мержится? тут схожу вывод - выносить в код но не всегда есть такая возможность. Помню еще во времена друпулов/вордпресов было вообще страшно (если такой подход еще актуален) вот такие вопросы периодическо возникают и отнимают многосил/времени на поиски/чтение блогов и не всегда информация полезна и актуальна

@devops_ru

спасибо, похоже то что надо)

дык какой сиай то(

тебя и там тоже самое спросят

Gitlab/Jenkins/TeamCity?

да, гитлаб, CD скорее, но может есть в закладках какие-то книги/наборы практик которые покрывают такие вопросы? Много кних описывают или корпоративную культуку и взаимодействие между отделами (что тоже важно но пока не про это), ли куча воды как настроить и установить докер/дженкинс и возможно где-то будет полезное (но найти не всегда получается). А вот такие практические вопросы периодически возникают, это как пример

да, гитлаб, CD скорее, но может есть в закладках какие-то книги/наборы практик которые покрывают такие вопросы? Много кних описывают или корпоративную культуку и взаимодействие между отделами (что тоже важно но пока не про это), ли куча воды как настроить и установить докер/дженкинс и возможно где-то будет полезное (но найти не всегда получается). А вот такие практические вопросы периодически возникают, это как пример

https://t.me/ru_gitlab а вообще по любой системе есть своя документация как бы, где все рассказано

спасиб, наверное практики лучше относительно конкретной системы брать, тонкости могут отличаться (к прмеру bitbucket pipelines не имеют своего registry и тд) и от этого напрямую меняется флоу. Видимо я сильно не того боку смотреть начал

=)

еще один, как и я, ньюфаг прибыл

мне пока рано в CI, у меня другой мозголюбли хватает, с докером

https://a.d-cd.net/ca6aea4s-960.jpg

Как перезапустить pod?

Как перезапустить pod?

Тебе в чат по кубернетам, наверное. В описании ссылка

Тебе в чат по кубернетам, наверное. В описании ссылка

Спасибо.

Вот кстати полностью соглашусь тоже куча траблов была https://www.webhive.ru/2018/06/13/what-is-wrong-with-coreos/

Пока ничего лучше Centos в проде для докеров не вижу

Никто не юзал для прода https://blog.selectel.ru/budet-ispolneno-gospodin-admiral/ ?

Вот кстати полностью соглашусь тоже куча траблов была https://www.webhive.ru/2018/06/13/what-is-wrong-with-coreos/

надо коллегу позвать, который плотно работает

@magnaZ

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

«Установку Kubernetes я проводил с помощью kubeadm. Первым начал ругаться kubelet заявивший при старте, что версия docker-а слишком новая и типа «используйте на свой страх и риск». Блин — это немного не то, чего я ожидал от стабильной системы заточенной на запуск kubernetes.» подтвержу. Но это проблема и не системы, и не куба

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

Вот кстати полностью соглашусь тоже куча траблов была https://www.webhive.ru/2018/06/13/what-is-wrong-with-coreos/

"я бы не рекомендовал использовать CoreOS для серьёзных применений" - я бы не стал руководствоваться мнением человека, который даже не понял use-case CoreOS

Соглашусь. ТОлько я думаю что можно было хотя бы ansible там оставить в system image 😉

чтобы даже через REST API работать

зачем ансибл, если у них ignition?

переходный период увы, много старого от RHEl like шаблонов развертывания

я ссылочку на человека с кореос в проде дал

есть еще отдельная телеграм группа

в общем-то я ничего гипер-криминального не увидел

ничего скро кореос будет в рхеле по самые уши)

ничего скро кореос будет в рхеле по самые уши)

Я думаю что у IBM будет что то свое 😉

у них свой рхел :)

Я думаю что у IBM будет что то свое 😉

неа)

не зря кореось уже начали в шифт засовывать

аааа....вот оно что !

ну так уже и панелька от туда переехала так что кореос будет жить

зато умрет atomic 😉

его уже пару лет депрекейтнуть хотят

Как все начиналось ведь хорошо https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership

привет всем. давно не копался в докере и походу что-то упустил в изменениях. когда я запускаю контейнер docker run --rm -t -i -v /path/to/project:/var/www php:7.0 bash а затем внутри php -S 0.0.0.0:80 -t /var/www то зная IP контейнера, я могу постучатся на этот сервер с хост машины или даже из другого контейнера (будь он в том же default сети). вопрос: что же тогда делает --expose 80 как опция команде run? что с ней, что без нее - я могу достучатся до сервера.

привет всем. давно не копался в докере и походу что-то упустил в изменениях. когда я запускаю контейнер docker run --rm -t -i -v /path/to/project:/var/www php:7.0 bash а затем внутри php -S 0.0.0.0:80 -t /var/www то зная IP контейнера, я могу постучатся на этот сервер с хост машины или даже из другого контейнера (будь он в том же default сети). вопрос: что же тогда делает --expose 80 как опция команде run? что с ней, что без нее - я могу достучатся до сервера.

expose в докерфайле? Это тупо аннотация

нет нет) я специально уточнил, как опция команде run

я пока что наблюдаю лишь одно отличие с этой опцией: в колонце PORTS при выводе docker ps я вижу этот порт. без опции - не вижу. но доступ есть что так, что эдак. не понимаю её (опции) истинного предназначения

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

я пока что наблюдаю лишь одно отличие с этой опцией: в колонце PORTS при выводе docker ps я вижу этот порт. без опции - не вижу. но доступ есть что так, что эдак. не понимаю её (опции) истинного предназначения

у тебя есть опция -p. Зачем —expose - не могу понять

вероятно, рудимент от старых времен, имхо

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

https://docs.docker.com/engine/reference/builder/#expose The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

у тебя есть опция -p. Зачем —expose - не могу понять

> у тебя есть опция -p. это разные вещи. мне не нужно паблишить порты контейнера на хост. > Зачем —expose - не могу понять я с этим вопросом пришел сюда. зачем эта опция. вдруг кто-то мне обьяснит

https://docs.docker.com/engine/reference/builder/#expose The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

это обьяснение EXPOSE из докер файла. я спрашиваю про опцию команде run

https://docs.docker.com/engine/reference/builder/#expose The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

ну, документация == аннотация

> у тебя есть опция -p. это разные вещи. мне не нужно паблишить порты контейнера на хост. > Зачем —expose - не могу понять я с этим вопросом пришел сюда. зачем эта опция. вдруг кто-то мне обьяснит

читни выше практичски используется только с опцией -P для открытия всего что экспозед

это обьяснение EXPOSE из докер файла. я спрашиваю про опцию команде run

документация есть на сайте

это обьяснение EXPOSE из докер файла. я спрашиваю про опцию команде run

невнимательно читаешь

https://docs.docker.com/engine/reference/run/#expose-incoming-ports

т.е. ВРОДЕ как expose нужен, когда у тебя есть частная сеть МЕЖДУ контейнерами и ты хочешь, чтобы один контейнер ходил в другой, но не через хостовый интерфейс

но фактически, по-моему, это никогда не работало. Оно не настраивает правила файрволла, селинукса и прочего. Но может у меня дистрибутивы линукса были не те

а линкование контейнеров сейчас вообще депрекейтед

невнимательно читаешь

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

т.е. ВРОДЕ как expose нужен, когда у тебя есть частная сеть МЕЖДУ контейнерами и ты хочешь, чтобы один контейнер ходил в другой, но не через хостовый интерфейс

о, благодарю

это кажется то, что мне нужно было

спасибо за внимание

ну, если есть что добавить - добавляй )

может и я тоже неправ )

@pyToshka а ты что скажешь за expose?

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

эм а что за него сказать он есть))

может и я тоже неправ )

насколько я помню, контейнеры внутри одной докер-сети и без экспоуза видят друг друга полностью... Или я ошибаюсь?

насколько я помню, контейнеры внутри одной докер-сети и без экспоуза видят друг друга полностью... Или я ошибаюсь?

вот это я проверил и это так.

насколько я помню, контейнеры внутри одной докер-сети и без экспоуза видят друг друга полностью... Или я ошибаюсь?

о чем и речь! никогда не видел необходимость экспоузить

потому и задался вопросом "а expose тогда зачем?"

expose это вообще не про внутренюю сеть

expose это вообще не про внутренюю сеть

расскажи свою точку зрения

потому и задался вопросом "а expose тогда зачем?"

похоже только как заметки тем кто будет саппортить твои докера, и как указание чо экспозить для -P :)