Created
November 10, 2016 23:37
-
-
Save wtcross/288a6d7c52dd98de9eac4da0491aa93f to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ######################################## | |
| # # | |
| # ANSIBLE CONTAINER DEMO: # | |
| # ELK STACK # | |
| # # | |
| ######################################## | |
| ######################################## | |
| # # | |
| # brought to you by: # | |
| # # | |
| # Tyler Cross # | |
| # @wtcross # | |
| # # | |
| # also, vim and bad ascii art # | |
| # # | |
| ######################################## | |
| ######################################## | |
| # # | |
| # We're going to walk through # | |
| # # | |
| # ANSIBLE CONTAINER # | |
| # # | |
| # ...and describe what we're doing # | |
| # and why, step by step. # | |
| # # | |
| # Feel free to follow along at home. # | |
| # # | |
| ######################################## | |
| ############################################################################# | |
| # # | |
| # First, make sure that docker-machine is running and our environment # | |
| # is set up properly: # | |
| # # | |
| # $ docker-machine stop # note that we expect Docker 1.11 currently # | |
| # $ docker-machine start default # | |
| # $ docker-machine ls # make sure default is actually running # | |
| # $ eval "$(docker-machine env default)" # set up environment # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Next, we're going to get rid of old containers and images, so we can # | |
| # demonstrate that we're building from scratch. (Don't feel obliged to # | |
| # do this yourself; it's just for demo purposes.) # | |
| # # | |
| # $ docker rm $(docker ps -a -q) # remove all containers # | |
| # $ docker rmi --force $(docker images -q) # remove all images # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Next, let's make sure that the latest version of ansible-container is # | |
| # installed. I've installed using "pip install ansible-container" as # | |
| # root, but you can feel free to use virtualenv if you like. # | |
| # # | |
| # NOTE: Ansible itself does __not__ need to be installed, because all # | |
| # of Ansible's work is done within your Ansible Build Container, which # | |
| # is downloaded by Ansible Container when you first run it. # | |
| # # | |
| # $ ansible-container version # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # OK, now let's make a working directory: # | |
| # $ mkdir a-c-project; cd a-c-project # | |
| # # | |
| # And now we're going to initialize our new project, using a Galaxy # | |
| # role as our basis: # | |
| # $ ansible-container init chouseknecht.elk-stack-container # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Ansible Container just downloaded a new, special kind of Galaxy role. # | |
| # We call this new kind of Galaxy role a "container app". # | |
| # # | |
| # Let's take a closer look at the components it installed. # | |
| # # | |
| # First, let's look at the playbook that __defines__ and __launches__ # | |
| # the containers: # | |
| # # | |
| # $ vi ansible/container.yml # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # container.yml specifies the components of the Ansible Container # | |
| # application that you'll be building. Each service describes: # | |
| # # | |
| # * The name of the service, which will match the "hosts" entry you'll # | |
| # be using in your Ansible playbook; # | |
| # * The base image you'll be building from; # | |
| # * Any other information that will be required to launch your container, # | |
| # like ports, networking, user data, environment variables, data # | |
| # volumes, etc. # | |
| # # | |
| # This looks similar to Docker Compose, OpenCompose, and similar # | |
| # formats. # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Now, let's look at the playbook that __builds__ on top of those # | |
| # container hosts: # | |
| # # | |
| # $ vi ansible/main.yml # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Looking closely, ansible/main.yml does basically two things: # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # 1. It specifies the hosts where the plays will run. Which is just # | |
| # like a regular Ansible playbook; the only difference is where we # | |
| # get inventory. # | |
| # # | |
| # In Ansible Container, the containers specified in container.yml # | |
| # __are__ the inventory. # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # 2. For each host, it specifies the plays to be run -- and in this case, # | |
| # each play consists of a single Galaxy role. # | |
| # # | |
| # That's by design! Ansible roles are perfectly structured to describe # | |
| # microservices. A role can be written in such a way that it can be # | |
| # invoked either in a container context, or in a regular VM context. # | |
| # We call these "container-ready roles". # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Now for the main event -- let's build some containers! # | |
| # # | |
| # $ ansible-container build # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # First, we pull the images -- and the first image we pull is the # | |
| # Ansible Container Builder image, followed by the base images of the # | |
| # containers we'll be building. # | |
| # # | |
| # This builder container will be the actual Ansible control host. All # | |
| # Ansible tasks will be run from this host. Instead of connecting to our # | |
| # target containers via ssh, we will use the Docker connection plugin # | |
| # (which basically runs commands via 'docker exec' instead.) # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Next, we start the builder container. # | |
| # # | |
| # We haven't found any local containers corresponding to the ones we # | |
| # specify in container.yml, so we assume they need to be rebuilt. # | |
| # Ansible Container will now launch and build those containers. # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Note that we're seeing several role dependenices here. This is one of # | |
| # the strengths behind Ansible Container -- the ability to leverage the # | |
| # existing ecosystem of roles. # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # The builder container stops, we snapshot all of our containers and # | |
| # turn them into images, and we're done! # | |
| # # | |
| # Now it's time to run our project: # | |
| # # | |
| # $ ansible-container run # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # OK, we see our services running. Let's take a look at Kibana in our # | |
| # browser: # | |
| # # | |
| # open http://$(docker-machine ip default):5601 # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # We have a running ELK stack! With no data, mind you; for details on # | |
| # how to populate this with sample data, see the README for this role. # | |
| # # | |
| ############################################################################# | |
| ############################################################################# | |
| # # | |
| # Resources: # | |
| # # | |
| # * Containerized ELK stack on Galaxy: # | |
| # https://galaxy.ansible.com/chouseknecht/elk-stack-container/ # | |
| # # | |
| # * Ansible Container documentation: # | |
| # https://docs.ansible.com/ansible-container/ # | |
| # # | |
| # * Questions about Ansible Container: # | |
| # https://groups.google.com/forum/#!forum/ansible-container # | |
| # # | |
| ############################################################################# |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment