5 votos

Amazon AWS EC2 + Puppet, obtener Puppet para saber etiquetas de la instancia de AWS

Estoy teniendo un problema con mi AWS implementación, bastante nuevo a AWS y de Puppet.

Así que venir a mi pregunta - se puede distinguir de la marioneta de los nodos con AWS máquina de etiquetas o CNAME dominios?

Un poco de historia sobre el plan:

  • tiene varios grupos de máquinas, uno de php clúster, un legado de php clúster, uno java clúster, un perl de clúster
  • configuración de control con títeres - todavía bastante nuevo para títeres, pero como desarrollador me gusta la idea de ser capaz de controlar la versión de configuración de servidores
  • han autoescala habilitado en esos grupos - obviamente el principal beneficio de la nube que hace que el muy alto costo cuando se trata de cualquier razonable de rendimiento de la pena (los de amazon son las máquinas más lento que mi teléfono...)
  • implementación controlada por Capistrano, esto hace las cosas mucho más fáciles

Así, en AWS a obtener esos super desagradable público/privado, máquina de dns... no hay manera que usted puede identificar las máquinas en los. En el fin de la pascua el problema, las costuras como AWS quiere que la etiqueta de todo - y así lo hice. Encontrado un script que hace un registro CNAME para cada máquina con la etiqueta de "ShortName" gracias a la Route53 de la API.

Cada máquina tiene un ShortName etiqueta que se convierte en su CNAME, por desgracia títere todavía resuelve el privado de nombre dns.

Me gustaría tener

node 'perl-cluster'{}

en marioneta de nadie ninguna pista ho para lograr esto?

Gracias

8voto

Sirch Puntos 2763

La manera que yo he hecho es escribir un custom hecho por el servidor para identificar su papel a partir de los datos del usuario, el cual puede ser consultado en 169.254.169.254, ver sus propios datos de usuario...

AWS datos de usuario de la documentación

curl http://169.254.169.254/latest/

así que cuando yo escriba facter role ill get 'dbserver', 'web' de lo que sea, a continuación, utilizarlo para definir un nodo, que es importante no tener autoescala de los grupos de cuidado el más mínimo acerca de cuál es el nombre del servidor.

/etc/puppet/manifiestos/nodos.pp

node default{
  include nodes::type
}

/etc/puppet/modules/nodos/manifiestos/init.pp

import "type.pp"

/etc/puppet/modules/nodos/manifiestos/tipo.pp

class nodes::type{
   case $role {
     "dbserver" : {
       include mysql
     }
   }
   case $role {
      "webserver" : {
       include httpd
     }
   }
}

/etc/puppet/manifiestos/módulos.pp

 import nodes

Yo no quiero decirte exactamente cómo hacerlo en tu caso, pero aquí voy a mostrar cómo crear un personalizado hecho a informe de la instancia de EC2 ID.

Facter, curl, están instalados.

mkdir -p /home/ec2-user/lib/ruby/facter
export FACTERLIB=/home/ec2-user/lib/ruby/facter

cat > /home/ec2-user/lib/ruby/facter/instance_id < EOF
# instance_id.rb
#
require 'facter'
Facter.add("instance_id") do
    setcode "/usr/bin/curl -s http://169.254.169.254/latest/meta-data/instance-id"
    end
EOF

Y he aquí una de encargo hecho de que fue escrito.

Ahora que lo puedo usar para obtener la instancia de ec2 id:

$ facter instance_id
i-a1c0ffee

No tengo títere instalado en esta máquina, pero si quería a disposición de títeres, id de poner en /var/lib/títeres/lib/facter, y para distribuirlo a los clientes de identificación de garantizar pluginsync=true en la marioneta.conf.

Tenga en cuenta, todo lo que he dicho, es muy subjetivo, su justo como yo lo hago, si hay una mejor manera, yo estaría interesado.

3voto

Craig Watson Puntos 3702

Como de facter 1.7 (lanzado en abril de 2013), no están incorporados en los hechos que informan de varios detalles de la instancia de EC2.

Referencia: http://docs.puppetlabs.com/facter/1.7/core_facts.html#ec2ec2-instance-data

1voto

Jeff Williams Puntos 11

Estoy de acuerdo con Sirch que en este punto personalizados hechos parecen ser el camino a seguir. AWS describir el uso de la formación de nubes hechos en:

https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithPuppet.pdf

Lo que es interesante, aunque difícil de leer. La costumbre hecho de que es:

# cfn.rb 
require 'rubygems' 
require 'json' 
filename = "/var/lib/cfn-init/data/metadata.json" 
if not File.exist?(filename) 
 return 
end 
parsed = JSON.load(File.new(filename)) 
parsed.default = Hash.new 
parsed[\"Puppet\"].each do |key, value| 
 actual_value = value 
 if value.is_a? Array 
  actual_value = value.join(',') 
 end 
 Facter.add(\"cfn_\" + key) do 
  setcode do 
   actual_value 
  end 
 end 
end

Que, a continuación, configurar sus nodos como:

node basenode { 
 include cfn 
} 
node /^.*internal$/ inherits basenode { 
 case $cfn_roles {
   ...cloud formation include...
 } 
} 

Yo estoy más inclinado a implementar a través de este hiera como:

---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hiera
:hierarchy:
  - "roles/%{::cfn_roles}"
  - common

A continuación, tener algo como común.yaml:

classes: cfn # or whatever your custom fact class is

funciones/dbserver.yaml:

classes: mysql

funciones/servidor web.yaml:

classes: httpd
httpd::port: 8080
...

Jeff

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X