Abstract the conductor image from service images

ymansour commented 6 years ago

ISSUE TYPE

Feature Idea
Documentation Report

Consider a scenario where an application needs to be deployed on multiple images of different base operating systems for testing purposes. Specifying the conductor image of one base will cause the build process for service images using a different base to fail. Scanning through current issues, these might be related: #807, #812, #847, #904, as I have experienced the same or very similar errors when building service images that do not match or partially match the conductor image.

The documentation is clear about the fact that service images should be of the same family as the conductor image. This might be limiting as the potential workarounds include creating and maintaining a separate project for each base image. The other option is to use the docker_image to build from Dockerfiles, and then run them with docker_containter. What is not clear in the documentation is how run tasks on the created containers afterwards, if this approach is to be taken.

For example, the build for the below configuration and related role(s) will fail.

container.yml

version: '2'
settings:

  conductor:
    base: 'centos:7'

services:
  centos-server:
    from: 'centos:7'
    roles:
    - role: common

  ubuntu-server:
    from: 'ubuntu:16.04'
    roles:
    - role: common

roles/common/tasks/main.yml

---
- name: Install package
  package:
    name: wget
    state: present

or

roles/common/tasks/main.yml

- name: Install package on Ubuntu
  apt:
    name: wget
    state: present
  when:
    ansible_distribution is match('Ubuntu')

- name: Install package on CentOS
  yum:
    name: wget
    state: present
  when:
    ansible_distribution is match('CentOS')

Depending on the service images used that do not match the conductor image, the build will error out with a different error message. Using the multi-container example did not help either. What I noticed is that when using service images which do not match the conductor image and do not use any roles, the build process succeeds, for example a configuration file such as below will build successfully.

container.yml

version: '2'
settings:

  conductor:
    base: 'centos:7'

services:
  centos-server:
    from: 'centos:7'
    roles:
    - role: common

  ubuntu-server:
    from: 'ubuntu:16.04'

I am not sure how practically feasible to abstract the conductor image from the service images. Would the enhancement in #777 help overcome such concerns?

wilmardo commented 6 years ago

As a workaround I use the Ansible template module as described in #454 See my Ansible test image build repository for an example, see the travis.yml for the build steps.

This conductor and container service split would be awesome and I think this also removes most of the need for templating the conductor base like #732 suggests.

viveksaiaws commented 6 years ago

I have same error with kubectl plugin error ``

hosts: localhost

tasks:
- name: Cassandra Hostnames shell: "kubectl get po ulterior-skunk-mysql-ccdcd8566-smtml -o json | jq -r '.status.podIP'" register: cassandraHostname
- name: "add container to inventory" add_host: name: cassandra ansible_connection: kubectl ansible_host: "{{ cassandraHostname }}" kubectl_kubeconfig: ~/.kube/conig ansible_user: root
- name: create directory for ssh keys shell: echo hello delegate_to: cassandra``

output: `` TASK [add container to inventory] *** task path: /Users/viveksairamagiri/Documents/Devloper/test/test.yml:20 creating host via 'add_host': hostname=cassandra changed: [localhost] => { "add_host": { "groups": [], "host_name": "cassandra", "host_vars": { "ansible_connection": "kubectl", "ansible_host": "10.1.1.54", "ansible_user": "root", "kubectl_kubeconfig": "~/.kube/conig" } }, "changed": true }

TASK [create directory for ssh keys] **** task path: /Users/viveksairamagiri/Documents/Devloper/test/test.yml:28 <10.1.1.54> ESTABLISH kubectl CONNECTION <10.1.1.54> EXEC ['/usr/local/bin/kubectl', 'exec', '-i', '10.1.1.54', '--', '/bin/sh', '-c', "/bin/sh -c 'echo ~root && sleep 0'"] <10.1.1.54> EXEC ['/usr/local/bin/kubectl', 'exec', '-i', '10.1.1.54', '--', '/bin/sh', '-c', '/bin/sh -c \'echo "pwd" && sleep 0\''] <10.1.1.54> EXEC ['/usr/local/bin/kubectl', 'exec', '-i', '10.1.1.54', '--', '/bin/sh', '-c', '/bin/sh -c \'( umask 77 && mkdir -p \"echo ~/.ansible/tmp/ansible-tmp-1535566637.768967-63772081524957\" && echo ansible-tmp-1535566637.768967-63772081524957=\"echo ~/.ansible/tmp/ansible-tmp-1535566637.768967-63772081524957\" ) && sleep 0\''] fatal: [localhost]: UNREACHABLE! => { "changed": false, "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"echo ~/.ansible/tmp/ansible-tmp-1535566637.768967-63772081524957\" && echo ansible-tmp-1535566637.768967-63772081524957=\"echo ~/.ansible/tmp/ansible-tmp-1535566637.768967-63772081524957\" ), exited with result 1", "unreachable": true } to retry, use: --limit @/Users/viveksairamagiri/Documents/Devloper/test/test.retry``

and ansible.cfg [defaults] hostfile = hosts remote_tmp = ~/.ansible/tmp deprecation_warnings=False local_tmp = /tmp

ansible / ansible-container