В /etc/environment указал переменные. Когда захожу под attach, то переменные эти видит, но если попробовать выполнить команду через exec, то видит только старый $PATH (все что было до редактирования) и больше ничего
UPD:
пока вариант такой: вручную указывать экспорт переменных (source файла, например) под bash -c, но тогда нужно знать об этом и строка команды может быть существенно больше, что не хорошо.
Все что находил, так это то, что bash -c выполняет команды незалогинено, и берет переменных оттуда, откуда вызывается (в моем случае их основного хоста, а не из контейнера)
Потомучто docker exec просто запускает процесс внутри работающего контейнера и что там у тебя надо грузить знать не знает.
Что значит "до редактирование" не совсем понятно, но телепатически думаю, что это править надо не в инстансе контейнера а в Dockerfile. Тогда и exec будет все видеть как надо
> до редактирования
то что было изначально в файле, но по факту эти переменные берутся из среды, из которой вызывается docker exec, а не из самого контейнера. Все что накопал в сети, так это то, что причина в bash -c (что-то связано с неинтерактивностью, поэтому и не берет внутренние переменные)
Если бы я знал наперед все что нужно в этом контейнере, то через Dockerfile собирал бы контейнеры, а так часто изменения вносятся и каждый раз пересобирать образ было бы слишком долго. Или есть какие-то удобные способы?
Виталий Столяров, переменные хоста в docker exec не транслируются (за исключением явного "проброса"). новый процесс запускается с переменными pid 1 контейнера - тоесть с переменными взятыми из Dockerfile.
и то что в файле совершенно не тождественно тому что в переменных. чтобы то что в файле появилось в переменных надо или явно загрузить, или чтобы проиложение _само_ загрузило.
rustler2000,
> переменные хоста в docker exec не транслируются (за исключением явного "проброса").
если выполнить docker exec cont-name bash -c "echo $PATH", то выводится значение переменной с моего хоста, а не то, которое внутри контейнера.
Тоесть с переменными взятыми из Dockerfile.
так создаю я контейнер и сохраняю в образ на основе другого образа, а не через Dockerfile
Виталий Столяров, 0) потому что при ```docker exec cont-name bash -c "echo $PATH"``` на хосте шел сначала разворачивает $PATH а потом передает строчку в контейнер. правильно будет ```docker exec cont-name bash -c "echo \$PATH"```
1) если ты образ собираеш из контейнера (docker commit), то это адовейше не правильно. и скорее всего переменные среды сохраянются только че, что через докер в инстасе поменяны а не через export
rustler2000, как тогда обновлять образ с возможностью отката изменений без получасовых ожиданий? Например, если я хочу что-то добавить в контейнере, то делаю это и проверяют, в случае чего могут удалить контейнер и создать новый из последнего образа. А если через Dockerfile, если что-то нужно подправить (редактировать файл например), то это не совсем очевидно, когда наперед не знаешь сработает эта команда или нет, и нужно пересобирать весь образ, что очень долго. Какой тогда выход?
Виталий Столяров, во время docker build не использовать --no-cache. стараться не использовать однострочники (по типу RUN apt update && apt install nginx && apt clean && apt autoremove && rm -rf /tmp/*). если копируешь в образ и запускаешь скрипт "настройки" - то лучше так не делать. точечный тюнинг сдвигать к концу файла.
докер по слойно собирает итоговый образ и предидущие может спокойно переиспользовать.
опять же стоит посмотреть, может чего ты не допонимаешь сильно и не правильно используешь - в hub.docker.com есть практически все.
rustler2000, что докер делает с теми слоями, с которых удаляется что-то? Он их заново пересобирает? Наверное поэтому сама команда docker build жутко долго выполняется при малейших изменениях такого рода
> в hub.docker.com есть практически все.
там не всегда то что нужно вовремя обновляется, и может чего-то не хватать, все равно самому тогда доделывать
Виталий Столяров, >что докер делает с теми слоями, с которых удаляется что-то
Создается новый слой, без удаленных файлов. Проблема в том - что если у тебя 30х RUN и ты меняешь чтото в первой RUN то все последующие слои будут меняться.
[rustler2000@KOPOBA zzz]$ echo "FROM ubuntu
> RUN apt update
> RUN touch /file1
> ENTRYPOINT bash
> " > Dockerfile
[rustler2000@KOPOBA zzz]$ docker build -t test:local .
Sending build context to Docker daemon 2.048kB
Step 1/4 : FROM ubuntu
---> dd6f76d9cc90
Step 2/4 : RUN apt update
---> Running in 5a163961a255
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Get:1 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]
Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:4 http://security.ubuntu.com/ubuntu xenial-security/universe Sources [52.0 kB]
Get:5 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [490 kB]
Get:7 http://archive.ubuntu.com/ubuntu xenial/universe Sources [9802 kB]
Get:8 http://security.ubuntu.com/ubuntu xenial-security/restricted amd64 Packages [12.9 kB]
Get:9 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [224 kB]
Get:10 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 Packages [3479 B]
Get:11 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages [1558 kB]
Get:12 http://archive.ubuntu.com/ubuntu xenial/restricted amd64 Packages [14.1 kB]
Get:13 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages [9827 kB]
Get:14 http://archive.ubuntu.com/ubuntu xenial/multiverse amd64 Packages [176 kB]
Get:15 http://archive.ubuntu.com/ubuntu xenial-updates/universe Sources [224 kB]
Get:16 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [851 kB]
Get:17 http://archive.ubuntu.com/ubuntu xenial-updates/restricted amd64 Packages [13.7 kB]
Get:18 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [700 kB]
Get:19 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages [18.5 kB]
Get:20 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages [5176 B]
Get:21 http://archive.ubuntu.com/ubuntu xenial-backports/universe amd64 Packages [6354 B]
Fetched 24.5 MB in 5s (4844 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
5 packages can be upgraded. Run 'apt list --upgradable' to see them.
---> 890a058de0f1
Removing intermediate container 5a163961a255
Step 3/4 : RUN touch /file1
---> Running in 55f005da5cbf
---> c8c203fbef4f
Removing intermediate container 55f005da5cbf
Step 4/4 : ENTRYPOINT bash
---> Running in f9af0ded79c1
---> 2250d82c196a
Removing intermediate container f9af0ded79c1
Successfully built 2250d82c196a
Successfully tagged test:local
[rustler2000@KOPOBA zzz]$
[rustler2000@KOPOBA zzz]$
[rustler2000@KOPOBA zzz]$
[rustler2000@KOPOBA zzz]$ sed -i 's/file1/file2/' Dockerfile
[rustler2000@KOPOBA zzz]$ cat Dockerfile
FROM ubuntu
RUN apt update
RUN touch /file2
ENTRYPOINT bash
[rustler2000@KOPOBA zzz]$ docker build -t test:local .
Sending build context to Docker daemon 2.048kB
Step 1/4 : FROM ubuntu
---> dd6f76d9cc90
Step 2/4 : RUN apt update
---> Using cache
---> 890a058de0f1
Step 3/4 : RUN touch /file2
---> Running in 2e6ab256c3f8
---> 9803943a0f6b
Removing intermediate container 2e6ab256c3f8
Step 4/4 : ENTRYPOINT bash
---> Running in 24e05136ee7f
---> 382c1931ca77
Removing intermediate container 24e05136ee7f
Successfully built 382c1931ca77
Successfully tagged test:local
Заметь, что при втором запуске apt update не вызывается а используется сделанный на прошлом шаге слой (в кэше лежит)
rustler2000, короче получается такой вариант удобный если уже знаешь что в контейнере нужно, и можно ли потом спокойно просто в конец добавлять RUN'ы. А если нужно обновить версию чего-то? То заново все RUN'ы после этой команды будут выполняться, что отразится на времени ожидания, пока почти весь образ пересоберется!?
Виталий Столяров, эээ - версию чего к примеру? одно приложение - один контейнер. если ты и апачь и мускул и ноду в один контейнер суешь - то точно не верно это.
rustler2000, версию библиотеки (.so). Использую контейнеры для сборки приложения под разные платформы (то есть один контейнер под Web, другой под Android и третий под Desktop), то есть это не для работы приложения, а для его разработки
Виталий Столяров, нее - чтото не так у тебя в консерватории раз для сборок продуктов надо образы билд контейнеров по 30 минут пересобирать, да и вообще пересобирать часто.
у нас есть несколько базовых образов (включая снятые с дико старых серверов). потом под каждый продукт свои билд образы собираются на их основе. чтобы образы пересобирать такое ну раз в месяце, и то если чтото добавить по мелочам.
rustler2000, так я и не пересобираю по 30 минут, если использовать не Dockerfile, а делать изменения в самом контейнере, и то это пока на начальном этапе подготовки toolchain'ов (нужна какая-то библиотека - собрал в контейнере, в образ за каждым разом конечно нет смысла коммитить).
П.С. В каком еще консерватории? Я пока только для себя с этим, так сказать, играю
rustler2000, а что тогда делать со сборками, которые в уже готовом весят, ну пусть по 100-200 мб, а на то чтобы каждую собрать, потребуется пару часов? Тогда на новой машине очень долго придется ждать пока соберется все (зачастую используя cmake/make). К примеру одна OpenCV очень долго собирается
Виталий Столяров, заливать свои образы на докерхаб или поднять своё регистри и заливать туда из ci/cd.
Вообще беспокоиться надо, что что-то забудешь задокументировать, и имиджи между машинами расползутся или не сможешь повторить - типа магия утеряна
Простой
Средний
