Skip to content

Instantly share code, notes, and snippets.

@metaxis
Created December 9, 2010 06:36
Show Gist options
  • Save metaxis/734406 to your computer and use it in GitHub Desktop.
Save metaxis/734406 to your computer and use it in GitHub Desktop.
full stack lab

Chef Fundamentals Labs

Lab 5 Create a Web Stack with a Load Balancer

Exercise 1 - Modify Haproxy Cookbook

b. Download a copy of the haproxy cookbook if you haven't already.

 knife cookbook site vendor -d haproxy

See ( http://wiki.opscode.com/display/chef/Chef+Repository#ChefRepository-cookbooks ) for an explanation of the vendor branch pattern used in this command.

c. Find the metadata.rb and list the supported OS's for this cookbook

d. Update the the default.rb recipe in the ../cookbooks/haproxy/recipes directory

In this step we are going to create modify the haproxy cookbook default recipe to make it data driven using the "search" api. Modify the existing default.rb to include the following code.

package "haproxy" do
  action :install
end

template "/etc/default/haproxy" do
  source "haproxy-default.erb"
  owner "root"
  group "root"
  mode 0644
end

service "haproxy" do
  supports :restart => true, :status => true, :reload => true
  action [:enable, :start]
end

pool_members = search(:node, "role:#{node[:haproxy][:pool_role]}") || []

template "/etc/haproxy/haproxy.cfg" do
  source "haproxy.cfg.erb"
  owner "root"
  group "root"
  mode 0644
  variables :pool_members => pool_members
  notifies :restart, resources(:service => "haproxy")
end

Make sure you understand the relationship of the search API call and the variables used in the template. We will see later when we build the role for this example how the attribute "haproxy" sets the pool_role that gets resolved in the erb template.

e. Modify the the erb template for the haproxy cookbook.

In this step we are going to modify the default template erb template to match the updates made in the haproxy recipe. At this point you should know how to find the template file. Modify the existing haproxy.cfg template file to include the following code.

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        #log loghost    local0 info
        maxconn 4096
        #debug
        #quiet
        user haproxy
        group haproxy

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        redispatch
        maxconn 2000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

# Set up application listeners here.
listen application 0.0.0.0:80
      balance roundrobin

      <% @pool_members.each do |member| %>
      <% server_ip = member.has_key?("ec2") ? member.ec2.public_ipv4 : member.ipaddress %>
      server <%= member.hostname %> <%= server_ip %>:80 weight 1 maxconn 1 check
      <% end %>

listen admin 0.0.0.0:22002
      mode http
      stats uri /

In this example we are using the public IP address of the web servers. If the haproxy server and all of the web servers are on Amazon's cloud it is more efficient to use the private IP addresses. The following code is an example of using the the private IP addresses.

# Set up application listeners here.
listen application 0.0.0.0:80
      balance roundrobin

      <% @pool_members.each do |member| %>
      server <%= member.hostname %> <%= member.ipaddress %>:80 weight 1 maxconn 1 check 
      <% end %>

f. Upload the updated haproxy

knife cookbook upload haproxy

g. Modify the LB role

Add the haproxy attribute to the role you created...

$EDITOR roles/lb.rb 

name "lb"
description "load balancer"
override_attributes(
  :haproxy => {:pool_role => "<input the correct value here>"}
)
run_list(
  "recipe[haproxy]"
)

In this step you need to input the correct value for the override_attributes to coordinate with the previous code specified in the haproxy recipe and template. This is not easy. Remember the search API in the default.rb recipe will use this value to find all of the launched webservers. If you are not sure about this complete process please take this time to talk to your instructor for clarification.

h. Load the modified lb.rb role up to the Chef server

knife role from file lb.rb 

i. Show the loaded role

knife role show lb

j. get an instance and make it a lb server

knife bootstrap NEWSERVER -r "role[lb]" -x ubuntu --sudo -i ~/.ssh/aaron

k. List your running instances and launch the web page using the following commands.

knife ec2 server list

knife status --run-list

knife status "role:lb" --run-list

curl <the public IP of the lb instance>

Note: The IP address displayed from the page should match the IP address of your webserver instance.

Also display the haproxy admin interface.

curl <the public IP of the lb instance>:22002

l. Create one more EC2 instances of the webserver to add the the haproxy pool.

__ yes, ask aaron for another!__

knife bootstrap NEWSERVER -r 'role[webserver]' -x ubuntu --sudo -i ~/.ssh/aaron

m. Rerun the chef-client on the haproxy server to update the load balance pool with the new servers.

knife ssh "role:lb" "sudo chef-client" -x ubuntu -a ec2.public_hostname

n. List all of your running instances and launch the web page using the following commands.

knife ec2 server list

knife status --run-list

knife status "role:webserver" --run-list

knife status "role:lb" --run-list

curl <the public IP of the lb instance>

Note: The IP address displayed from the page should match the IP address of your webserver instance.

Also display the haproxy admin interface.

curl <the public IP of the lb instance>:22002

This output should display the three webserver instances.

More Knife Fu

status of our infrastructure

knife status --run-list
knife status "role:lb" --run-list
knife status "role:webserver" --run-list

explore node commands

knife node list
knife node show <supply an instance id for the for the lb instance>
knife node show <supply an instance id for the for the lb instance> --run-list

let's issue some commands in parallel using knife ssh

uptime

knife ssh "role:web" "uptime" -x ubuntu -a ec2.public_hostname

Exercise 2 - Using knife to bootstrap an already running instance

__ Get a new instance from Aaron __

__ Use the knife command to bootstrap the new instance.__

knife bootstrap <Public IP Address of the new server> --sudo -x ubuntu

__ Verify the status of the bootstrapped instance.__

knife status --run-list

__ Add a role to the new instances run_list.__

knife node run_list add ip-10-195-111-34.ec2.internal "role[webserver]"

Use the node name displayed in the first field of the "knife status". Notice the default name of the bootstrapped node is not the instance id.

__ Use the "knife ssh" to re-drive the chef-client on all webserver nodes.__

knife ssh "role:webserver" "sudo chef-client" -x ubuntu -a ec2.public_hostname

__ Rerun the chef-client on the haproxy server to update the load balance pool with the new servers.__

knife ssh "role:lb" "sudo chef-client" -x ubuntu -a ec2.public_hostname

__ List all of your running instances and launch the web page using the following commands.__

knife ec2 server list

knife status --run-list

knife status "role:webserver" --run-list

knife status "role:lb" --run-list

curl <the public IP of the lb instance>

Note: The IP address displayed from the page should match the IP address of one of your your webserver instances.

Also display the haproxy admin interface.

curl <the public IP of the lb instance>:22002

The output should install all of the servers listed from the following command:

knife status "role:webserver" --run-list
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment