Design ideas ansible provision with docker compose

165 wyświetleń
Przejdź do pierwszej nieodczytanej wiadomości

Sonny Heer

nieprzeczytany,
20 sty 2017, 13:10:1320.01.2017
do Ansible Project
Goal:

1. use same roles regardless of container, VM, bare metal, swarm, or other cloud provider
2. easily add/remove nodes (containers)
3. use existing docker-compose files

I can't seem to find an example of docker_service which has ansible provisioning after container is up.   e.g. I want to keep the containers very basic (bare centos), and use ansible to install all packages/configure.  I'm assuming this happens first by defining the containers and then connecting to those containers from host machine (in my case a unix VM).   Let me know if this makes sense or if more info is needed...

Thanks

James Beake

nieprzeczytany,
22 sty 2017, 19:41:4822.01.2017
do ansible...@googlegroups.com
If you are trying to use containers this way ( ansible provisioning inside running container) you are pushing against the philosophy behind containers. My suggestion is to use ansible to construct the files used to create containers. That way you get the control / power of ansible without trying to shoehorn it into the docker world.

For example I have a Dockerfile.j2 template that I pump a list of packages I want to install into it using ansible. Then I just run docker build.

eg
(partial <role>/templates/Dockerfile.j2)

RUN DEBIAN_FRONTEND=noninteractive apt-get -y update && apt-get -y install \
{{ container_packages | join (" ") }} \ <<<< Magic happens here
&& rm -rf /var/lib/apt/lists/*

and
(<role>/vars/mail.yml)
container_packages:
- apache2
- curl
- git
- mysql-client
- php5
- php-apc
- php5-curl
- php5-gd
- php5-json
- php5-mysql
- php5-sqlite
- sqlite
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/a8b37474-d921-47e5-94d5-a5196cba7e8d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Sonny Heer

nieprzeczytany,
22 sty 2017, 20:24:3422.01.2017
do Ansible Project
Thanks for that info.  I do see what you mean.  I'd like to reuse existing ansible roles if possible.  Assuming I'm only doing basic things like setting up a yum repo and installing packages on groups of nodes.  Here is the lifecycle of what I'm thinking:
1. start up a configurable set of base containers (base os only).
2. run ansible to setup repos/ install yum packages
3. commit changes to snapshot the "configured images"
4. all the above is for initial setup - subsequent calls would call another play book to simply start the set of containers.

sample of testing this use case:

    - name: Create a network
      docker_network:
        name: dev
    - name: test out docker service
      docker_container:
        image: centos:7
        name: "node{{ item }}"
        state: started
        interactive: yes
        networks:
          - name: dev
      with_sequence: count=2
----
- name: provision shtuff
  hosts: node1
  connection: docker
  tasks:
    - name: run some echo cmd
      shell: mkdir foobar

-- stop containers and exit initial setup.  this is all done with vagrant / ansible provisioning.

is this still considered an antipattern?  The key is I'd like to separate out the creation x #of containers, base provisioning, and runtime.  by doing this it allows new nodes to be added with simple plays to the network.  I may go with your suggestion of templating the Dockerfile if this proves to be too much of a pain.  I actually started out with templating a Dockerfile - then moved to docker_service (compose), and finally back to docker_container.  docker_service seemed to have too many issues with version mismatches between docker-compose/ docker-py...

Johannes Kastl

nieprzeczytany,
23 sty 2017, 05:19:0423.01.2017
do ansible...@googlegroups.com
On 23.01.17 02:24 Sonny Heer wrote:
> Thanks for that info. I do see what you mean. I'd like to reuse
> existing ansible roles if possible. Assuming I'm only doing basic
> things like setting up a yum repo and installing packages on groups
> of nodes. Here is the lifecycle of what I'm thinking:

You are describing system containers, while docker does represent
application containers. Docker containers only contain the one
application that you want them to run. System containers are full
systems running with init and sshd and whatnot.

You might want to checkout lxc and the lxc_container module of ansible...

Johannes

signature.asc

Sonny Heer

nieprzeczytany,
23 sty 2017, 10:00:4823.01.2017
do Ansible Project
Each container will probably be running a single application or a few services.  the dependencies to run said application need to be installed and configured.  this is the part I'd like to provision via ansible.  I am leaning towards a templatized dockerfile (not ansible, but still close).  I didn't know about lxc_containers - i will check those out as well.  although I believe what I'd like to do with containers is within docker's ability.

Pshem Kowalczyk

nieprzeczytany,
23 sty 2017, 10:23:2723.01.2017
do ansible...@googlegroups.com
Hi,

If you want to run containers, but not necessarily docker - have a look at lxd/lxc. I currently use it exactly the way you mentioned - reusing roles and configs and simply pointing to different environments. 

kind regards
Pshem


Sonny Heer

nieprzeczytany,
23 sty 2017, 11:27:4623.01.2017
do Ansible Project
do you have examples of using lxd/lxc in this use case?   initial start - provision - subsequent starts have provisioning 

Pshem Kowalczyk

nieprzeczytany,
23 sty 2017, 14:14:4323.01.2017
do Ansible Project
Hi,

LXC containers that I use have cloud-init build in, so that the main way of configuring them. 

All example below use LXD as the 'hypervisor'. I spin up a container with one basic profile ('bootstrap') (bound to a network that has full internet access), configure the container (i.e. apply all my roles) and then reconfigure it to the target profile (which usually means different network/IP) and restart.

Tasks to create a container profile:
- name: create a service profile
  lxd_profile:
    name: service
    description: "used for services containers"
    state: present
    devices:
      eth0:
       name: eth0
       nictype: bridged
       parent: vlan3
       type: nic

- name: create a bootstrap profile
  lxd_profile:
    name: bootstrap
    description: "used for bootstrapping of containers"
    state: present
    config: { "user.user-data": "#cloud-config\nssh_authorized_keys:\n  - ssh-rsa AAAAB3xxxxx\npackages:\n  - openssh-server"}
    devices:
      eth0:
       name: eth0
       nictype: bridged
       parent: vlan2
       type: nic

Playbook to spin up a container  and configure it. I pass the final role as a parameter. "gather facts" is off since the container images don't have python by default and I install it manually using role "common".

- name: create container
  hosts: "{{ lxdhost | default(t1) }}"
  connection: ssh
  user: pshemk
  become: true
  tasks:
  - name: build container
    register: result
    lxd_container:
      name: "{{ lxcname }}"
      state: started
      source:
        type: image
        properties:
          os: "ubuntu"
          release: "xenial"
          architecture: "amd64"
      profiles: ["bootstrap"]
      timeout: 600
      wait_for_ipv4_addresses: true

  - name: update local inventory
    delegate_to: 127.0.0.1
    connection: local
    become: false
    copy: content="[{{ lxcname }}]\n{{ result.addresses.eth0[0] }} type=lxc" dest="./inventory/dyn-{{ lxcname }}"

  - meta: refresh_inventory
  - pause: seconds=60

- name: setup container
  hosts: "{{ lxcname }}"
  connection: ssh
  user: ubuntu
  become: true
  gather_facts: false
  roles:
    - common
    - resolver
    - "{{ lxcrole }}"

- name: restart container
  hosts: "{{ lxdhost }}"
  connection: ssh
  user: pshemk
  become: true
  tasks:
   - name: reasign profile
     register: result
     lxd_container:
       name: "{{ lxcname | default(totara) }}"
       state: restarted
       profiles: ["{{ hostvars[inventory_hostname]['hosts'][lxcname]['profile'] }}"]
       timeout: 600
       wait_for_ipv4_addresses: true

   - name: update local inventory
     delegate_to: 127.0.0.1
     connection: local
     become: false
     copy: content="[{{ lxcname }}]\n{{ result.addresses.eth0[0] }} type=lxc" dest="./inventory/dyn-{{ lxcname }}"


kind regards
Pshem



Sonny Heer

nieprzeczytany,
23 sty 2017, 18:14:5823.01.2017
do Ansible Project
Thanks Pshem - lots of details.   I think after thinking over this with a colleague, I plan to go with docker mainly because of future usage (compose / swarm / existing container projects within company).

Curious on how to best utilize a docker jinji template in ansible workflow of starting containers. any ideas welcome.

Sonny Heer

nieprzeczytany,
23 sty 2017, 18:25:0323.01.2017
do ansible...@googlegroups.com
j2 template (jinja2)*

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/BCuoU7md27A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/36147ff6-ab78-4ddf-84a3-7022ef68a6f0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--


Pushpinder S. Heer
Senior Software Engineer
m: 360-434-4354 h: 509-884-2574
Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż
Nowe wiadomości: 0