Add ssh-enabled image variants

[yajo]

It seems I just came along with the same problem as everybody else: CI on ansible roles without VMs, so thanks for this hard work!

However, although this is actually great, I find it to be a bit unhelpful in the testing paradigm it encompasses.

The Problem

This is the current paradigm encouraged by this project:

• Write your role.
• Mount your role in a server with the OS you want.
• Run the role locally.
• Repeat all of the above, once per OS.

... and it's OK, but it's not the paradigm one usually uses with Ansible:

• Write your role.
• Create an inventory which configures SSH access to all of your servers.
• Run your playbook simultaneously.

Why the change is needed

I'm developing a role that tries to set up a docker swarm; per design, testing such role needs a cluster of servers, that need to be interconectable, need to be booted separately, and need to have diferent roles, because the process is:

1. Enter one of the managers and init the swarm.
2. Enter the other managers and join the swarm as manager.
3. Enter the workers and join the swarm as workers.

Thus, cluster-wide roles need this kind of testing workflow to assure delegation works. Another possible examples:

• Kubernetes
• Ceph
• GlusterFS
• Etcd

The solution

So I personally think this project needs to go the next step further: providing an sshd version for each OS that bundles sshd preinstalled and preconfigured with:

1. Listening on port 22
2. 3 users (username will be the same as password):
   1. root
   2. unprivileged
   3. privileged (normal user with sudo enabled)

The new paradigm

With this set up on place, you finally are able to mimic the real workflow of an ansible playbook in your CI. Your CI should look like this now:

# .travis.yml, your CI definition
sudo_required: true
language: python
services:
- docker
install:
- pip install ansible
- ansible-galaxy install requirements.yml
script:
- ansible-playbook test.yml -i test.cfg

# test.cfg, your test inventory

localhost ansible_connection=local

[all:vars]
host=127.0.0.1

# I'll use the swarm example here, but it could be anything
[manager]
server0 ansible_port=220
server1 ansible_port=221
server2 ansible_port=222

[worker]
server3 ansible_port=223
server4 ansible_port=224
server5 ansible_port=225

# test.yml, your actual test playbook
- hosts: localhost
  # My suggestion is that this step should be instead: role=ansiblecheck.cluster,
  # a new project under this namespace that uses some variables to boot a ready-to-test cluster
  tasks:
    docker_service:
      project_name: testcluster
      definition:
        version: "2.2"
        services:
          server0:
            image: ansiblecheck/ansiblecheck:centos-7-sshd
          ports:
            - "220:22"
          server1:
            image: ansiblecheck/ansiblecheck:ubuntu-16.04-sshd
          ports:
            - "221:22"
          server2:
            image: ansiblecheck/ansiblecheck:ubuntu-14.04-sshd
          ports:
            - "222:22"
          server3:
            image: ansiblecheck/ansiblecheck:debian-wheezy-sshd
          ports:
            - "223:22"
          # you can imagine the rest...

- hosts: manager
  roles:
  - role: .
    vars:
      manager: true

- hosts: worker
  roles:
  - role: .
    vars:
      manager: false

The benefits

I see many:

1. New CI paradigm mimics the one you'll find when deploying to production.
2. Instead of complex .travis.yml files, we'd have now a simple one.
3. Simpler testing in CIs without matrix, such as Gitlab's.
4. You can test parallelism in your roles, which is important to ensure many of Ansible features work, such as delegation (essential in my case).
5. Ansible is the one that takes care on the underlying OS of the target server (container), NOT travis. That's what should happen in production.

The questions

1. Most important: Do you agree with this change?

2. Should we add the -sshd variants to current images, or is it better to add a new GH+DockerHub project called i.e. ansiblecheck/sshd, which creates new images based on this ones?

3. Do you agree on creating a Galaxy role to deploy a test cluster with just this?:

   - hosts: localhost
    roles: ansiblecheck.cluster

   This would be yet another GH repo called i.e. ansiblecheck/ansible-role-cluster, and of course some Ansible Galaxy integraton.

   One cool thing is that this role could parse the main role metadata file and issue a failure if some OS from that file is not being deployed in the cluster.

4. Can I help? :blush:

[yajo]

For those interested:

1. SSH is not needed because Ansible already supports the docker driver.
2. OTOH, I just started https://github.com/Tecnativa/ansible-test-playground, where you can see a very simple testing framework, entirely ansible-based, that applies this idea. I'll publish in galaxy soon.

Closing due to being fixed there. Thanks!