Сложилась практика передавать параметры в докер через переменные окружения (environment variables). Понятно, что приложение в докере изолировано и переменные окружения не влияют на другие приложения. Но мне все равно это кажется костылем.

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

Какие плюсы и минусы разных подходов. Что использовать для передачи параметров приложения в докер?
И отдельный вопрос про передачу секретов в докер, уже устоялась какая-то практика или нет?

Здравствуйте, Буравчик, Вы писали:


Б>Какие плюсы и минусы разных подходов. Что использовать для передачи параметров приложения в докер?
Б>И отдельный вопрос про передачу секретов в докер, уже устоялась какая-то практика или нет?

Про плюс переменных окружения:

Их можно проставлять в системах CI/CD, чтобы, например не хранить в исходниках всякие пароли и явки. В CI/CD доступ к этим данным можно раздавать или закрывать.

Здравствуйте, Буравчик, Вы писали:

Б>Сложилась практика передавать параметры в докер через переменные окружения (environment variables). Понятно, что приложение в докере изолировано и переменные окружения не влияют на другие приложения. Но мне все равно это кажется костылем.

Б>Более правильно, на мой взгляд, передавать параметры через аргументы командной строки. В некоторых случаях также можно передавать параметры в конфиг-файлах. Но их уже чуть сложнее передавать в докер.

Б>Какие плюсы и минусы разных подходов. Что использовать для передачи параметров приложения в докер?
Б>И отдельный вопрос про передачу секретов в докер, уже устоялась какая-то практика или нет?

Переменные окружения. Основной довод в том, что их не нужно парсить, в отличие от командной строки. Второй довод — это безопасность. Если переменные окружения передаются в докер через файл --env-file=/restricted/directory/app/env, то их невозможно прочитать без прав рута, а параметры командной строки видны в ps ax.

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

scf>Здравствуйте, Буравчик, Вы писали:

Б>>Сложилась практика передавать параметры в докер через переменные окружения (environment variables). Понятно, что приложение в докере изолировано и переменные окружения не влияют на другие приложения. Но мне все равно это кажется костылем.

Б>>Более правильно, на мой взгляд, передавать параметры через аргументы командной строки. В некоторых случаях также можно передавать параметры в конфиг-файлах. Но их уже чуть сложнее передавать в докер.

Б>>Какие плюсы и минусы разных подходов. Что использовать для передачи параметров приложения в докер?
Б>>И отдельный вопрос про передачу секретов в докер, уже устоялась какая-то практика или нет?

scf>Переменные окружения. Основной довод в том, что их не нужно парсить, в отличие от командной строки. Второй довод — это безопасность. Если переменные окружения передаются в докер через файл --env-file=/restricted/directory/app/env, то их невозможно прочитать без прав рута, а параметры командной строки видны в ps ax.

Разве в /proc не видно переменные окружения?

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

vsb>Разве в /proc не видно переменные окружения?
Только свои.

$ ps 3941
   PID TTY      STAT   TIME COMMAND
  3941 ?        Sl     0:07 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
$ cat /proc/3941/environ
cat: /proc/3941/environ: Permission denied

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

scf>>Переменные окружения. Основной довод в том, что их не нужно парсить, в отличие от командной строки. Второй довод — это безопасность. Если переменные окружения передаются в докер через файл --env-file=/restricted/directory/app/env, то их невозможно прочитать без прав рута, а параметры командной строки видны в ps ax.

vsb>Разве в /proc не видно переменные окружения?

у /proc/xxx/environ права 400. т.е. видно только владельцу процесса и руту.