ansible-redis icon indicating copy to clipboard operation
ansible-redis copied to clipboard

Update Kitchen tests to use Docker

Open danielkza opened this issue 8 years ago • 12 comments

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.

danielkza avatar Nov 15 '16 22:11 danielkza

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 avatar Nov 15 '16 22:11 DavidWittman

@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

DavidWittman avatar Nov 26 '16 18:11 DavidWittman

@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.

danielkza avatar Nov 26 '16 18:11 danielkza

@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?

DavidWittman avatar Nov 27 '16 02:11 DavidWittman

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

danielkza avatar Nov 27 '16 02:11 danielkza

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

danielkza avatar Nov 27 '16 06:11 danielkza

@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.

DavidWittman avatar Dec 10 '16 23:12 DavidWittman

@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.

danielkza avatar Dec 11 '16 01:12 danielkza

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.

DavidWittman avatar Dec 17 '16 17:12 DavidWittman

Great coincidence, I also happen to have some time myself. I'll publish the systemd image to Docker Hub and update this PR.

Em sáb, 17 de dez de 2016 15:28, David Wittman [email protected] escreveu:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DavidWittman/ansible-redis/pull/126#issuecomment-267775184, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtnTtpwg6sE70Nqk6fQgokH_9r27EoCks5rJBungaJpZM4KzGEj .

danielkza avatar Dec 17 '16 17:12 danielkza

@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/

DavidWittman avatar Dec 17 '16 17:12 DavidWittman

I just took a look at the 16.04 Dockerfile, and it seems to be missing some of the customizations for systemd to work well, such as disabling the units that should not start in containers, and installing dbus so that logind and journald work. I'm not sure if they would actually cause any trouble, but the environment will certainly be different from a "regular" installation.

Em sáb, 17 de dez de 2016 15:32, David Wittman [email protected] escreveu:

@danielkza https://github.com/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/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DavidWittman/ansible-redis/pull/126#issuecomment-267775441, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtnTg4GgHWjIHn5ifiVVyu2x--ypy48ks5rJBzCgaJpZM4KzGEj .

danielkza avatar Dec 17 '16 17:12 danielkza