During docker build I need to run a bash script, which sets up some environment variables.
The script looks something like this:
#!/bin/bash
export ENVVAR=TEST
export HOST=local
export PORT=port
I try to call this script in my dockerfile in different ways but none of them are working. I tried these:
ADD ./myscript.sh
RUN chmod +x /myscript.sh;\
/bin/bash -c 'source ./myscript.sh';\
/bin/bash -c 'source /myscript.sh';\
/bin/bash -c source ./myscript.sh;\
/bin/bash -c source /myscript.sh;\
source ./myscript.sh;\
source /myscript.sh;\
/myscript.sh;\
./myscript.sh;\
ENTRYPOINT ["/bin/bash"]
Of course I only had one of these commands in my RUN and I just put them here grouped.
If I run the container and use source ./myscript.sh it works as expected.
Because of multiple restrictions and other reasons it is not possible for me to use docker compose, the -e argument, ENV KEY VALUE in dockerfile or similar approaches. I need to set up the environment variables during the docker build process.
You're simply not sourcing the shell that is specified in your ENTRYPOINT. Just add your myscript.sh to your image (use COPY instead of ADD).
COPY myscript.sh /usr/local/bin
Then source it on the shell that is actually started by your entrypoint.
docker run myimage source /usr/local/bin/myscript.sh
btw, myscript.sh is pretty non descriptive. You could use env.sh for instance.
Related
To simplify test execution for several different container I want to create an alias to use the same command for every container.
For example for a backend container I want to be able to use docker exec -t backend test instead of docker exec -t backend pytest test
So I add this line in my backend Dockerfile :
RUN echo alias test="pytest /app/test" >> ~/.bashrc
But when I do docker exec -t backend test it doesn't work, otherwise it works when I do docker exec -ti backend bash then test.
I saw that it is because alias in .bashrc works only if we use interactive terminal.
How can I get around that?
docker exec does not run the shell, so .bashrc is just never used.
Create an executable in PATH, most probably in /usr/local/bin. Note that test is a very basic shell command, use a different unique name.
That alias will only work for interactive shells, if you want that alias to work on other programs:
RUN echo -e '#!/bin/bash\npytest /app/test' > /usr/bin/mypytest && \
chmod +x /usr/bin/mypytest
I'm running a set of commands on an ubuntu docker, and I need to set a couple of environment variables for my scripts to work.
I have tried several alternatives but none of them seem to solve my problem.
Alternative 1: Using --env or --env-file
On my already running container, I run either:
docker exec -it --env TESTVAR="some_path" ai_pipeline_new_image bash -c "echo $TESTVAR"
docker exec -it --env-file env_vars ai_pipeline_new_image bash -c "echo $TESTVAR"
The content of env_vars:
TESTVAR="some_path"
In both cases the output is empty.
Alternative 2: Using a dockerfile
I create my image using the following docker file
FROM ai_pipeline_yh
ENV TESTVAR "A_PATH"
With this alternative the variable is set if I attach to the docker (aka if I run an interactive shell), but the output is blank if I run docker exec -it ai_pipeline_new_image bash -c "echo $TESTVAR" from the host.
What is the clean way to do this?
EDIT
Turns out that if I check the state of the variables from a shell script, they are set, but not if check them directly in bash -c "echo $VAR". I would really like to understand why this is so. I provide a minimal example:
Run docker
docker run -it --name ubuntu_env_vars ubuntu
Create a file that echoes a VAR (inside the container)
root#afdc8c494e8a:/# echo "echo \$VAR" > env_check.sh
root#afdc8c494e8a:/# chmod +x env_check.sh
From the host, run:
docker exec -it -e VAR=BLA ubuntu_env_vars bash -c "echo $VAR"
(Blank output)
From the host, run:
docker exec -it -e VAR=BLA ubuntu_env_vars bash -c "/env_check.sh"
output: BLA
Why???????
I revealed my noobness. Answering my own question here:
Both options, --env-file file or -env foo=bar are okay.
I forgot to escape the $ character when testing. Therefore the correct command to test if the variable exists is:
docker exec -it my_docker bash -c "echo \$MYVAR"
Is a good option design your apps driven to environment variables at the runtime(start of application)
Don't use env variables at docker build stage.
Sometimes the problem is not the environment variables or docker, the problem is the app who reads the environment variables.
Anyway, you have these options to inject environment variables to a docker container at runtime:
-e foo=bar
This is the most basic way:
docker run -it -e foo=bar ubuntu
These variables will be available since the start of your container.
remote variables
If you need to pass several variables, using the -e will not be the best way.
Or if you don't want to use .env files or any kind of local file with variables, you should:
prepare your app to read environment variables
inject the variables in a docker entrypoint bash script, reading it from a remote variables manager
in the shell script you will get the remote variables and inject them using source /foo/bar/variables. A sample here
With this approach you will have a variables manager for all of your containers. These variables manager has these features:
login
create applications
create variables by application
create global variables if a variable is required for two or more apps
expose an http endpoint to be used in the client (apps) in order to get the variables
crypt
etc
You have these options:
spring cloud
zookeeper
https://www.vaultproject.io/
https://www.doppler.com/
Configurator (I'm the author)
Let me know if you want to use this approach to help you.
I am new to Linux stuff and would like to know how to run command while opening the shell through /bin/bash?
Eg the steps that I want to perform:
Step1: Run the docker exec command to start the quickstart virtual machine.
$ docker exec -it 7f8c1a16e5b2 /bin/bash
Step2: The above command gives the handle of the quickstart vm on the console. Now I want to run the below command by default when ever some one starts the docker quickstart console (step 1)
cd
. ./.bash_profile
I need some guidance on how to do this. Obviously, putting all these statements in one shell script isn't helping as the commands of Step2 are to be executed in the newly opened shell (of quickstart vm). The idea is to put all these statements in a single shell script and execute it when we want to get hold of the session within the VM console.
You can pass the commands you want to be executed inside the container to bash with the -c option.
That would look something like this:
docker exec -it 7f8c1a16e5b2 /bin/bash -c "cd && . ./.bash_profile && /bin/bash"
I am new to the linux world and trying to learn Docker.
I have two examples:
#example 1
$ docker run -ti ubuntu:latest bash
#example 2
$ docker run -ti ubuntu:latest
In example 1 it would allow me access to the terminal and example 2 is the same outcome. I understand that adding bash creates a bash session, and if that means being able run bash scripts, I am able to do echo on both examples, so I do not really see the difference.
What exactly does adding bash to docker run do? Given this context, what is the difference of having and not having a bash argument?
Specifying an explicit command overrides the default command given in the Dockerfile.
If the default CMD in the Dockerfile is already bash, then specifying bash on the command line has no effect.
If you look at the ubuntu Dockerfile on github, you can see that that is the case here:
CMD ["bash"]
Thus, you're just explicitly asserting the command that is already run by default anyhow.
thank you for reading my post.
Problem:
# docker ps
CONTAINER ID IMAGE COMMAND
35c8b832403a ubuntu1604:1 "sh -c /bin/sh"
# docker exec -i -t 35c8b832403a type type
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:262: starting container process caused "exec: \"type\": executable file not found in $PATH"
# Dockerfile
FROM ubuntu:16.04
ENV PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUN apt-get update && apt-get -y upgrade
ENTRYPOINT ["sh", "-c"]
CMD ["/bin/bash"]
Description:
My objective is to get "type" shell builtin been execute in a way of writing docker exec as below
docker exec -i -t 35c8b832403a type type (FAILED)
NOT
docker exec -i -t 35c8b832403a sh -c "type type" (PASSED)
I have googling around, do some modification in the container (change /etc/profile, /etc/environment, bashrc) but failed.
From the docker documentation itself, it has state that:
COMMAND will run in the default directory of the container. It the
underlying image has a custom directory specified with the WORKDIR
directive in its Dockerfile, this will be used instead.
COMMAND should be an executable, a chained or a quoted command will
not work. Example: docker exec -ti my_container "echo a && echo
b" will not work, but docker exec -ti my_container sh -c "echo a &&
echo b" will.
But seem it IS POSSIBLE when I able to get the right output FROM DOCKER FEDORA (Dockerfile: FROM fedora:25)
# docker ps
CONTAINER ID IMAGE COMMAND
2a17b2338518 fedora25:1 "sh -c /bin/sh"
# docker exec -i -t 2a17b2338518 type type
type is a shell builtin
Question:
Is there any way to enable this on Ubuntu docker? Image/Container tweaks? Vagrantfile Configuration? Please help.
Others:
Using docker run, I able to get the right output because of the "ENTRYPOINT" in the Dockerfile. However the image need to be save instead of export.
Just in case, to be able to execute type as you expect, it would need to be part of the path. Being a shell builtin wouldn't help because as you said, you don't want to execute /bin/bash -c 'type type'
If you want to have type executed as a builtin shell command, this means you need to execute a shell /bin/bash or /bin/sh and then execute 'type type' on it, making it /bin/bash -c 'type type'
After all, as #Henry said, docker exec is a the full command that will be executed and there is no place for CMD or ENTRYPOINT on it.
CMD and ENTRYPOINT are meaningless if you run docker exec. The remaining arguments are taken as the command and executed inside the already existing container.
Maybe you wanted to use docker run?