Skip to content
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

Update Kitchen tests to use Docker #126

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

danielkza
Copy link
Contributor

I was having a really unpleasant time with Vagrant and slow installation times (including Chef in the images and all), so I set up Kitchen to use Docker instead. I'm not sure if that's interesting - if it is not, feel no remorse in closing this

It does run much faster than Vagrant for me.

@DavidWittman
Copy link
Owner

Fuck yes. I've been meaning to do this for a while now. I'll mess around with this later and get it marged.

@DavidWittman
Copy link
Owner

@danielkza have the sys.vm.overcommit tests been failing for you in Docker? I'm considering adding the following to the serverspec to avoid the issue:

diff --git a/test/integration/service-name/serverspec/redis_spec.rb b/test/integration/service-name/serverspec/redis_spec.rb
index 75e7050..f606228 100644
--- a/test/integration/service-name/serverspec/redis_spec.rb
+++ b/test/integration/service-name/serverspec/redis_spec.rb
@@ -22,8 +22,11 @@ describe 'Redis' do
     its(:size) { should > 0 }
   end
 
-  describe file('/proc/sys/vm/overcommit_memory') do
-    it { should be_file }
-    it { should contain '1' }
+  # Ignore this test in Docker-land
+  unless File.exist?("/.dockerenv")
+    describe file('/proc/sys/vm/overcommit_memory') do
+      it { should be_file }
+      it { should contain '1' }
+    end
   end
 end

@danielkza
Copy link
Contributor Author

@DavidWittman I think I ran some tests with privileged containers, so that's why they didn't fail. I think you can do something like test("w", "/proc/sys/vm/overcommit_memory") instead of just checking whether we're inside Docker, so privileged tests can still be run manually.

@DavidWittman
Copy link
Owner

@danielkza Thanks. I'll add that to the tests, or just set privileged: true in kitchen.yml to get around that.

I'm also having issues running the tests on systemd, even with privileged containers. It looks like systemd isn't actually running because of the way kitchen-docker configures the entrypoint to the container. Did you have this issue as well?

@danielkza
Copy link
Contributor Author

@DavidWittman I actually had hit that already and forgot to update the PR, I'll do so in a minute.

@danielkza
Copy link
Contributor Author

That was more than a minute, but I hit some puzzling issues with systemd on CentOS 7. See if it's good now.

@DavidWittman
Copy link
Owner

@danielkza thanks again. This makes the testing cycles much faster and I'm excited to get this working.

There's a lot of wizardry going on here which will make it difficult for me to maintain. The provision commands and driver configs we're setting up within the .kitchen.yml make sense to me, but I'd like to better understand the motivation behind why they are configured that way. I almost feel like some of these things should be addressed upstream in kitchen-docker or within the Docker images themselves. I'd be happy to help with that if you can assist in identifying why exactly these configurations need to exist.

Also, I'm not sure if it's limited to my setup or you were experiencing these issues as well, but all of the systemd tests are failing waiting for SSH to come online. E.g.

$ kitchen test default-centos-7
...
       Successfully built 2c83a912f059
       f367804244c7f709b8c8e1890cccc7122cbe75500de96c3e0f3fcf030d36c573
       0.0.0.0:32801
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds
       Waiting for SSH service on localhost:32801, retrying in 3 seconds

Same goes for Ubuntu 16.04. Logging into the container it looks like sshd was installed, but is not running.

@danielkza
Copy link
Contributor Author

@DavidWittman You are completely right, unfortunately kitchen-docker (and even Docker itself) does not deal well at all with systemd, and workarounds are necessary. My first idea was to use images for Docker with systemd, but I haven't found any that seemed to be clean enough and not break some part of systemd functionality (such as systemd-logind).

For my own projects I have been using an image built with the same commands I used in the Kitchen config. I will publish it to Docker hub, and I can replace the provision commands with them (or you can make your own fork of them, if you feel more comfortable).

About the provision commands themselves: their whole purpose is to disable systemd units that handle things that should not be handled in containers, such as kernel modules, system parameters, device setup, etc. The custom run parameters (the cgroupfs mount, and the sandboxing exceptions) are necessary for systemd to work inside Docker.

Also, can you tell me more about your host setup? I ran the tests with Fedora 25 and OS X 10.11, but you might have something setup differently from me.

@DavidWittman
Copy link
Owner

Sorry for the delay. I've been running on Ubuntu Trusty and Xenial, both with frustratingly similar results. I'll hopefully have some more time this weekend to get some more testing on this.

@danielkza
Copy link
Contributor Author

danielkza commented Dec 17, 2016 via email

@DavidWittman
Copy link
Owner

@danielkza I was going to try this with Jeff Geerling's docker images... He seems to be using them with some amount of success. https://hub.docker.com/u/geerlingguy/

@danielkza
Copy link
Contributor Author

danielkza commented Dec 17, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants