Может быть, вы новичок в докере и задаетесь вопросом: «Как мне передать свои переменные в процесс сборки?», «Как мне передать свои секреты работающему приложению в моем контейнере?» или вам просто искренне интересно, как все сочетается друг с другом? ; если это так, эта статья может быть тем, что вы ищете.
Contents
Инструменты
Аргументы сборки и аргументы времени выполнения, что подходит именно вам? Возможно оба?
Аргументы сборки существуют, чтобы вы могли передавать аргументы во время сборки, которые проявляются как переменные среды для использования в процессе сборки образа докера:
$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 .
Некоторые варианты использования могут быть следующими: передать значение одному или нескольким шагам сборки, изменяя способ выполнения; другой может заключаться в том, чтобы запечь значение в образ, чтобы оно было доступно как для ваших шагов сборки, так и для запуска контейнера.
Аргументы времени выполнения передаются, когда вы запускаете докер или запускаете свой контейнер:
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG…]
Они позволяют вам отправлять переменные в ваше приложение, которое будет работать в вашем контейнере, как определено в вашем файле докеров вашими определениями CMD или ENTRYPOINT .
Строить аргументы
https://docs.docker.com/engine/reference/builder/#arg
Хотя вы можете использовать аргументы сборки для запекания значений, которые будут доступны во время выполнения, лучше всего использовать их исключительно для целей сборки; поскольку запекание секретных значений может привести к нарушению безопасности, если кто-либо когда-либо завладеет вашим изображением. Это также усложняет управление секретами и значениями во время выполнения, потому что затем вам придется перестраивать свои образы, чтобы обновлять их.
Имея это в виду, давайте углубимся в то, как мы можем безопасно использовать аргументы сборки.
Скажем, у нас есть приложение, и мы хотим предоставить версию сборки каждый раз, когда мы делаем новую сборку образа, чтобы мы могли внутренне отслеживать, какой версии соответствует образ. Для этого мы могли бы указать аргумент сборки следующим образом:
$ docker build — build-arg VER=0.0.1 . $ docker build — build-arg VER=0.0.2 .
Затем переменная среды VER будет доступна для всех наших команд RUN , определенных в нашем файле докеров, поэтому мы можем затем использовать эту переменную или встроить ее в наш образ в той или иной форме (это нормально, если это не секрет).
Для каждого определяемого вами аргумента сборки вам необходимо убедиться, что вы обновили свой файл докеров , чтобы определить его; с необязательным параметром по умолчанию, например:
ARG <name>[=<default value>]
В нашем случае это может быть:
ARG VER=0.0.0
Большой! Но что, если у нас есть много значений, которые мы хотим предоставить, значения, которые различаются для каждой сборки, но необходимы для сборки нашего приложения:
$ docker build --build-arg
VER=0.0.3
LIBRARY_GIT_HASH=1bdb374cf477ecb8e7c6dc338a4e4ea3d4838fd7
GCC_VERSION=7.2.1
MULTI_THREADING=1
EXPERIMENTAL_FEATURE=1
ADDITIONAL_ARGS…
.
В какой-то момент этим становится сложно управлять, и если вы используете одни и те же переменные в других сборках, может быть сложно синхронизировать все; к счастью, есть несколько инструментов, и если вы можете простить мою вилку и принять мое предложение. Manifold CLI может помочь решить эту проблему; Я покажу вам, как в конце статьи.
Аргументы времени выполнения и переменные среды
Итак, теперь, когда вы понимаете варианты использования аргументов сборки и немного о том, почему их запекание может вызвать проблемы как с управлением, так и с безопасностью; давайте поговорим о том, почему вы можете предпочесть передавать некоторые из этих аргументов во время выполнения.
Есть два веских аргумента в пользу использования аргументов времени выполнения: безопасность и управление.
Возможно, ваши аргументы содержат конфиденциальную информацию, которую не следует запекать в вашем образе, возможно, они связаны с тем, как и где запускается образ, или, возможно, они еще не существуют или просто не могут быть переданы во время сборки. .
Вот пример того, как они работают:
$ docker run my-awesome-image $SECRET_KEY $BACKEND_URL
Единственным недостатком здесь является то, что ваши аргументы будут передаваться непосредственно в вашу программу ENTRYPOINT в качестве аргументов командной строки, а не переменных среды, как мы видели с аргументами сборки.
ENTRYPOINT amazing-program
Эти аргументы командной строки может быть трудно отсортировать, и они зависят от порядка, если вы не выполняете какой-либо расширенный анализ, но возможно, что вы запускаете чью-то другую программу, и у них действительно есть хорошее определение аргументов командной строки, и этого будет достаточно.
Хотя имейте в виду, что CMD не является ENTRYPOINT , если у вас есть определение CMD и нет ENTRYPOINT и предположим, что мой пример `docker run` выше передаст аргументы программе, определенной в вашем определении CMD , вы можете быть удивлены, обнаружив что первый аргумент заменит вашу программу и попытается запустить программу, соответствующую ее строке (определяемой `$SECRET_KEY`).
Теперь, возможно, аргументы командной строки просто не для вас; может быть, вы хотите передавать вещи не только вашей точке входа в течение всего срока службы вашего контейнера; возможно, вам нужны переменные среды. Точно так же, как аргументы сборки используются в качестве переменных среды во время сборки, вы также можете передавать переменные среды в контейнеры во время выполнения:
$ docker run my-awesome-image -e VAR_FROM_ENV -e "MYVAR=2"
Но как только у вас будет несколько, эти переменные будут доступны для вашей программы и ее подпроцессов (при совместном использовании), что очень удобно. Вы также можете использовать аргумент -env-file для запуска docker, который позволяет вам указать все ваши переменные среды из файла, поэтому вы не получите большой встроенный список, подобный случаю аргументов сборки, который я показал вам в предыдущий раздел.
В конечном итоге вы можете захотеть совместно использовать эти переменные и секреты и управлять ими вне кода приложения, чтобы вашей операционной группе было проще менять ключи, или чтобы вы могли использовать один и тот же код приложения для разных развертываний. Если это так, то вам может подойти Manifold CLI.
Использование интерфейса командной строки манифольда
Я надеюсь, что теперь вы понимаете несколько различных подходов, которые вы можете использовать для использования ваших переменных с вашими образами докеров .
рекомендую вам хотя бы запустить множественную регистрацию , после того как ваша учетная запись будет проверена, вы можете начать создавать ресурсы.
Ресурсы и переменные
Давайте сначала начнем с пользовательского ресурса для хранения ваших переменных и секретов:
$ manifold create -c
После выполнения вышеуказанного вам будет предложено выбрать проект (если он не установлен в вашем текущем контексте). А пока давайте выберем No Project , чтобы создать ресурс на уровне вашей учетной записи. Затем вам будет предложено ввести имя ресурса, все имена ресурсов должны быть в нижнем регистре с дефисами для разделения слов, например: my-first-resource , является допустимым именем.
После того, как ваш пользовательский ресурс создан, мы можем добавить к нему некоторые данные:
$ manifold config set -r my-first-resource VER=0.0.1
Это добавит ключ с именем VER к пользовательскому ресурсу со значением 0.0.1 , затем вы можете запустить:
$ manifold export
Который покажет вам все ваши ресурсы уровня пользователя и все их ключи и значения. Поэкспериментируйте с этим немного и установите некоторые переменные, которые могут быть более значимыми для вас. Вы можете использовать
команду config unset
, чтобы удалить любые переменные из вашей конфигурации.
Теперь поговорим о проектах и командах, работающих либо:
$ manifold export --help
Или же
$ manifold run --help
Покажет вам, что каждый из них принимает необязательные аргументы команды и проекта . И команды , и проекты функционируют как контейнеры для ресурсов в Manifold , хотя команды отличаются от проектов тем, что позволяют контролировать доступ. В командах есть участники, и у каждого члена есть роль, которая определяет, что им разрешено делать. Такие команды, как Users, также могут иметь проекты для дальнейшей организации ресурсов.
Команды и токены
Когда дело доходит до создания токена доступа ( MANIFOLD_API_TOKEN ); каждый токен доступа может быть создан на уровне пользователя или группы , предоставляя ему доступ к ресурсам с точки зрения этого пользователя или группы .
А пока давайте начнем с создания команды; создание нового пользовательского ресурса в качестве этой команды, а затем маркер доступа для чтения значений ресурса.
$ manifold teams create
Вам будет предложено ввести название команды; как и ресурс, используйте строчные буквы с дефисами для разделения слов ( my-first-team является допустимым именем ).
Теперь вы можете запустить следующее, чтобы создать пользовательский ресурс в команде:
$ manifold create -c -t my-first-team
Затем, как и раньше, введите имя; Я назову свой my-team-resource . Затем давайте сохраним секретное значение в ресурсе:
$ manifold config set -t my-first-team -r my-team-resource SECRET=42
В настоящее время:
$ manifold export -t my-first-team
Покажет только СЕКРЕТ , указанный в командном ресурсе.
Теперь вы готовы создать токен доступа:
$ manifold tokens create -t my-first-team
Просто введите описание, затем выберите роль, для нашего случая использования этого ключа в докере или где-либо еще давайте просто используем read-credentials ; это требуется для чтения токенов в нашем случае использования, иначе вы можете увидеть некоторые ошибки при попытке прочитать свои учетные данные.
Затем токен будет напечатан на вашем терминале, вы можете скопировать и вставить его в любое место, где хотите его сохранить; описание, как вы можете вспомнить, какая клавиша где используется:
$ manifold tokens list -t my-first-team
Покажет вам все ваши токены в вашей команде, вы также можете удалить их с помощью множественного удаления токенов .
Теперь вы можете установить переменную среды MANIFOLD_API_TOKEN для только что созданного токена. Тогда вы сможете запустить:
многообразный экспорт -t моя-первая-команда и многообразный запуск -t моя-первая-команда
без многократного входа в систему .
Вы можете использовать многократный выход из системы или новый пользовательский контекст на вашем компьютере, чтобы проверить это!
Для получения дополнительной информации обратитесь к документации на нашем веб-сайте: https://docs.manifold.co/docs/cli-quickstart-6JMEw1CD6wguwIYymUuAQ6 или к встроенной справке инструмента CLI:
коллектор --help или коллектор %SUBCOMMAND --help для получения дополнительной информации.
Интерфейс командной строки Manifold с Docker
Теперь, когда вы знаете основы использования Manifold CLI для установки и использования ваших переменных и секретов, давайте рассмотрим пару предложений о том, как вы можете использовать его с docker .
Изображения зданий
$ docker build --build-arg "MANIFOLD_API_TOKEN=abc123def456ghi" .
Приведенная выше команда передаст ваш токен, который можно сгенерировать из Manifold CLI для доступа к определенному набору переменных и секретов, которые вы определили через Manifold . Таким образом, вы можете управлять всеми своими ключами и переменными в одном месте; даже если они могут быть реплицированы в нескольких процессах сборки. Вам просто нужно убедиться, что вы предоставили MANIFOLD_API_TOKEN в качестве аргумента сборки и обернули каждую команду, которую вы хотите иметь, чтобы иметь доступ к вашим переменным с помощью многообразия запуска в вашем файле докеров :
RUN коллектор запустить мою команду
Это также позволяет вам хранить любые секреты подальше от других команд сборки, которые могут иметь нежелательные побочные эффекты, что должно сделать использование ваших секретов при необходимости в процессе сборки более удобным.
Однако имейте в виду, что все, что передается в процессе сборки, может быть закэшировано в образе или его слоях; даже если переменные поступают из CLI Manifold , программа, в которую они передаются, может каким-то образом кэшировать их.
Как описано выше в разделе « Использование интерфейса командной строки Manifold », «manifold» также можно использовать для группировки различных наборов учетных данных в пользовательских ресурсах, проектах и командах; что полезно для разделения значений для разных процессов в одной сборке или разных образах.
Запуск изображений
Для запуска CLI Manifold при запуске образа; вам просто нужно добавить его в свою точку входа, завершив выполнение вашей программы. Например, в вашем файле докеров вы можете сделать следующее:
Коллектор ENTRYPOINT запускает удивительную программу
Затем, чтобы запустить образ, просто убедитесь, что вы передали свой MANIFOLD_API_TOKEN :
$ docker run my-awesome-image -e "MANIFOLD_API_TOKEN=abc123def456…"
И ваша удивительная программа теперь будет иметь все переменные среды, которые вы настроили для нее через Manifold.
Вывод
Я надеюсь, что теперь вы видите, как все это сочетается друг с другом, и лучше понимаете, как управлять своими переменными и секретами, добавлять их в свои сборки докеров, а также обеспечивать их доступность во время выполнения, когда это необходимо. Что еще более важно, я надеюсь, что вы также поняли, когда ваши секреты могут оказаться под угрозой, как часть процесса, и начали думать о том, как вы могли бы лучше управлять ими.
Приятного обмена учетными данными!
Эта статья является переводом с сайта medium.com
