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
On Tue, 24 Jan 2017 at 05:27 Sonny Heer <sonnyh...@gmail.com> wrote:
> do you have examples of using lxd/lxc in this use case? initial start -
> provision - subsequent starts have provisioning
>
>
> On Monday, January 23, 2017 at 7:23:27 AM UTC-8, Pshem Kowalczyk wrote:
>
> 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
>
>
> On Mon, 23 Jan 2017 at 14:24 Sonny Heer <sonn...@gmail.com> 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:
> 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...
>
> On Sunday, January 22, 2017 at 4:41:48 PM UTC-8, James Beake wrote:
>
> 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
>
> > On 21 Jan 2017, at 1:58 AM, Sonny Heer <sonn...@gmail.com> wrote:
> >
> > 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
> >
> >
> > --
> > 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.
>
> --
> 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/27bfdb17-ab57-48b0-8378-fa7e0486caec%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/27bfdb17-ab57-48b0-8378-fa7e0486caec%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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-project+unsubscr...@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/2483b144-7fa7-4c75-b251-1bca2aafc557%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/2483b144-7fa7-4c75-b251-1bca2aafc557%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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-project+unsubscr...@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/CAEaZiRW39VXrOVSMornawb7qypfPQVK0CtjZ00%3DDvUTgHrtcLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
