Reference an environment variable stored in text

I have a file on a server that contains my access token for github. I’d like to store the access token in a text file that is called on when building a Dockerfile

Here’s some psuedo code that I was thinking:

  • Block external access to docker containers
  • Prevent skip in docker-compose
  • Why does docker overwrite everything I've installed?
  • Starting Docker containers from PHP
  • From inside of a Docker container, how do I connect to the localhost of the machine?
  • Docker using mysql
  • creds.sh

    export GITHUB_CREDS mylongcred
    

    Dockerfile

    FROM some/image
    RUN ../path/to/creds.sh
    RUN install_github("my/repo", "$GITHUB_CREDS")
    

    Obviously this isn’t working. In theory, is there anything wrong with what you see here?

    Is it RUN, or perhaps some other command directive that I should be using to accomplish this?

    Updates:

    • The credential file is outside of the scope of the build (one directory behind)
    • The dockerfile is being run with a call that I can’t change directly because it’s being called by a jenkins plugin

  • orientdb docker can't connect or remove database of type 'memory'
  • mysql in docker container can't run through a mounted volume on os x
  • containerized nginx log rotation with logrotate
  • Running docker-containers structured as modules using fabric8
  • What is the best way to append to /etc/hosts within Dockerfile
  • Forced logout when i run a docker container
  • One Solution collect form web for “Reference an environment variable stored in text”

    There are several possible solutions to this (however none of them ideal).

    1. Export and run in a single step

    As noted in comments by @STLMikey, exported environment variables will not persist from one RUN steps to the next, as they will be run in two different intermediate containers. You can circumvent this by using a single build step:

    RUN path/to/creds.sh && install_github("my/repo", "$GITHUB_CREDENTIALS")
    

    Remember that path/to/creds.sh needs to contain something like export GITHUB_CREDENTIALS=<insert credentials here> (mind the = which was not present in the original file in your question).

    Caveat: Note that path/to/creds.sh will be included in your image and visible to anyone who uses it. This is most probably not what you want. Also remember that rm‘ing the file in this step or a later step will not help, as the credentials file will still be present in the parent layer. This leads us to…

    2. Step 1 + Image squashing

    Use a tool like docker-squash to combine all layers in your image into a single one. This allows you to remove secret files that have been added during the build process without leaving a trace of them in one of the parent layers:

    $ docker save <image-id> | docker-squash -t squash -verbose | docker load
    

    However, when doing this, you will lose all of your filesystem layers, making the resulting image difficult to push and pull efficiently. Even the tiniest change will result in an entirely new image with just one big layer. This might also not be ideal. Which again leads us to…

    3. Build-time variables

    This solution is discouraged in the official documentation, and there’s also an ongoing discussion about this in the Docker issue tracker. Use this at your own discretion.

    Warning: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.

    You can use build-time variables for this, using the --build-arg flag. For this, start by defining the argument in your Dockerfile using the ARGstatement:

    FROM some/image
    
    ARG GITHUB_CREDENTIALS
    RUN install_github("my/repo", ${GITHUB_CREDENTIALS})
    

    Then pass the argument on docker build:

    docker build --build-arg GITHUB_CREDENTIALS=<insert credentials here>
    
    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.