-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entrypoint doesn't seem to be executed #12
Comments
Small addition: |
Hi, describe command('/usr/local/bin/gosu 6000:6000 id -u') do
its(:stdout) { should match /6000/ }
end This works. So this is not a "gosu" problem :/ I tried many things with serverspec and docker-api directly, but cannot create a successful test... |
Hi, Dockerspec depends on Serverspec, which depends on SpecInfra. As you can see, it calls Docker.exec command. After some Googling, I found this issue : It's not the same problem, but this sentence challenged me :
So, when the container is already started, launch an "exec" command on it does not re-call the entrypoint, and in my case, the "gosu" script does not precede the "exec" command. The only "bad" solution I see is to preceed by myself the command tested with the entrypoint, but it's not really a good practice I think... Do you have any better idea ? At least, how to get dynamically the entrypoint to add it before the commands tested ? Thanks ! |
Hi @wibimaster, First of all, thanks for making such a detailed report 😉 As you have deduced, the problem is that I can think of two possible solutions to your problem:
describe command('/usr/local/bin/entrypoint.sh id -u') do
its(:stdout) { should match /6000/ }
end Maybe adding a simple
describe process('bash') do
it { should be_running }
its(:user) { should eq 'user' }
end |
Thanks, I see multiple possibilities :
An The best way to achieve this is to get the capability to test commands at run and not with exec in the container. Because, what my problem expose, is the 2 ways we can use a Docker image, and if the test hadn't show me the difference between "run" and "exec", I could have had the problem in production. I mean, if I used my docker image with commands at run, or if I run a shell and exec commands after, I have 2 distincts workflows with, in my case, 2 differents users. Is there a way to do this : # id -u at run
describe docker_run(described_image, env: {"LOCAL_USER_ID" => "6000:6000"}, cmd: ['id -u']) do
its(:stdout) { should match /6000/ }
end
# id -u in exec
describe docker_run(described_image, env: {"LOCAL_USER_ID" => "6000:6000"}, cmd: ['bash']) do
describe command('id -u') do
its(:stdout) { should match /0/ }
end
end |
Maybe you could create multiple
See the Anyway, you can also use a shell command to check its uid: describe command('ps -o uid $(pidof bash)') do
its(:stdout) { should match /6000/ }
end
But this seems to be more a limitation of Docker than something that can be implemented in this gem, sorry 😞
There could be a way to implement it, but currently is not possible to change those values in the |
Hi, I like this way you wrote : describe command('ps -o uid $(pidof bash)') do
its(:stdout) { should match /6000/ }
end :) For my particular case, I found another solution provided by SpecInfra : set :docker_container_exec_options, {'User' => '6000:6000'} But if we want a more generic patch, it's possible but we need to patch SpecInfra itself ; not so complicated, but not sure the owner would accept a patch like this... For the moment, the "User" trick is sufficient for me :) |
Dockerspec Version
0.4.1
Ruby Version
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]
Platform Details
Alpine Linux v3.4
Scenario
Try to build and test a Dockerfile with an entrypoint that create a user with Gosu.
Steps to Reproduce
Dockerfile:
entrypoint.sh:
spec/image_spec.rb:
Expected Result
id -u
command should returns 6000 (or, if env fail, 9001)Actual Result
id -u
command returns 0 (root)The text was updated successfully, but these errors were encountered: